Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What are the plans for the language? #8

Open
Its-Kenta opened this issue Jan 21, 2023 · 8 comments
Open

What are the plans for the language? #8

Its-Kenta opened this issue Jan 21, 2023 · 8 comments

Comments

@Its-Kenta
Copy link
Contributor

I see you're also working on a different language and few other repo's that would indicate other interests. Are there plans to focus on this language or move onto something else? IMO the language has a potential, but it's difficult to consider interest in it if it's going to be thrown on a shelf of unwanted projects.

@Spydr06
Copy link
Owner

Spydr06 commented Jan 21, 2023

I've spent the last 2 years writing this language, so no, this won't be 'thrown away' anytime soon :)
In fact, I've used this language to solve some of the Advent of Code 2022 problems.
But yea, as you already guessed I'm currently busy developing other projects so this one is put back a bit.
Since the feature-set of this language is pretty much complete (yes, you could always add stuff), most of the future development this project is going to see will be bugfixes and compatibility improvements (Windows and BSD support would be awesome).

Nevertheless, feel free to improve/work on this language if you want to, I'd be happy to merge some pull requests :)

@Its-Kenta
Copy link
Contributor Author

Sadly I’m not experienced enough to do any PR that would improve this language (apart from bindings 😏)

Are there plans to perhaps expand the documentations e.g on manual memory management and overall?

And ofc Window support anytime?

@Spydr06
Copy link
Owner

Spydr06 commented Jan 24, 2023

yea, you're right, the documentation is not complete at all, I'll have to expand it eventually, I plan to cover all language features and stdlib functions, but won't go in depth about memory management, etc. since that's a thing not specific to this language.

I already tried porting CSpydr to Windows a couple of times in the past, but never even got the compiler to work (Visual CXX being the main problem). The standard library basically needs to be rewritten to support Windows aswell.
Provided the scale of this and my lack of experience developing for windows platforms, I can't really say if/when this is going to be achieved...

When I get back to this project, my main target will be finishing off all of the semi-implemented features (e.g. libcspydr API/Headers), adding unit tests etc.

@Its-Kenta
Copy link
Contributor Author

Unfortunately I’m not that experience to help out, but I hope someone will do or one day you find that pesky reason why it doesn’t work.

Personally as a user I do have to say that Windows & Linux or least Linux & WASM is probably the minimal of what people might need, especially if planning to use a language for game dev (which is what I’m into)

Luckily CSpydr source code is quite easy to read so it also reads a little bit like documentation, but most certainly more documentation would make people be interested in using the language.

Hope you will revisit this project and continue developing it at some point. I might play with it a little bit more, although last time I tried using it with the SDL2 and GLFW bindings provided it seemed to give errors. I will try again and continues I will post an issue

@Its-Kenta
Copy link
Contributor Author

Would there be any guidelines on interoperability with C somewhere as well? If not I will study the bindings a little and try to glue something together

@Spydr06
Copy link
Owner

Spydr06 commented Jan 24, 2023

Would there be any guidelines on interoperability with C somewhere as well?

CSpydr is fully compatible with C. Stuff like the call ABI, struct padding, pointers, etc. is exactly like in C

Defining a C function is done like this:

extern "C" fn c_function_name(arguments: types): ReturnType;

linking with a C library can be done like this

  • for .so libs: [link("yourlibrary")]
  • for .o libs: [link_obj("your_o_file.o")]

Calling CSpydr functions from C is possible, although not officially supported right no (no explicit name-conversion...)

@Spydr06
Copy link
Owner

Spydr06 commented Jan 24, 2023

with the SDL2 and GLFW bindings provided it seemed to give errors. I will try again and continues I will post an issue

Yes! Please do that! :)
The glfw examples work on my machine, the sdl2 one too, but they're not really tested, so I don't know about those

@Its-Kenta
Copy link
Contributor Author

Its-Kenta commented Jan 24, 2023

Would there be any guidelines on interoperability with C somewhere as well?

CSpydr is fully compatible with C. Stuff like the call ABI, struct padding, pointers, etc. is exactly like in C

Defining a C function is done like this:

extern "C" fn c_function_name(arguments: types): ReturnType;

linking with a C library can be done like this

* for .so libs: `[link("yourlibrary")]`

* for .o libs: `[link_obj("your_o_file.o")]`

Calling CSpydr functions from C is possible, although not officially supported right no (no explicit name-conversion...)

Is it possible to link with a static lib? Or would it be the same as dynamic ones?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants