search

Spydr06 / CSpydr

A static typed low-level compiled programming language inspired by Rust and C
MIT License
84 stars 2 forks source link

The gtk bindings (WIP) #20

Closed hexaredecimal closed 1 year ago

hexaredecimal commented 1 year ago

This is the "real" GTK binding commit. I'm still getting a hang of using git btw so yeah bare with me here (sorry for the fake pull request)

Spydr06 commented 1 year ago

This is awesome, tysm!

Spydr06 commented 1 year ago

We might be able to simplify some stuff with the new [export("")] compiler directive from https://github.com/Spydr06/CSpydr/issues/15#issue-1698767835, but great work nevertheless!

Spydr06 commented 1 year ago

I'm still getting a hang of using git btw

No problem, git can be hard :)

I merged the code, which means it's in the main branch now. To continue development, you should pull all changes from this repository.

Its-Kenta commented 1 year ago

Is it a good idea to bundle up bindings into the std lib? I honestly don't think it's a solid idea to be placing them there, alongside other bindings. I think any bindings to C libraries should be kept separate from the std lib and standalone.

This is adding up to additional maintenance if the binding needs to be updated, requiring users to recompile the language just for that benefit?

Is there any chance this could be reconsidered?

Spydr06 commented 1 year ago

Of course it's not perfect, but what other options do we have?

I'm not very keen on implementing a packaging system for CSpydr, as this language is used by "only" 3 people to date (still, that's 2 more than I ever expected xD).

And until there is really a problem (like continuous breaking of the bindings) I think it's okay to keep stuff as it is.

requiring users to recompile the language just for that benefit

no recompilation is needed to update the std lib. When installed, the source files live in /usr/share/cspydr/std as plain source files. Updating them only takes replacing them with newer ones. Maybe that's something the compiler could do in the future.

Its-Kenta commented 1 year ago

Of course it's not perfect, but what other options do we have?

Can the bindings not be kept on a separate repositories by the creators and downloaded by users and imported into their code if need be? This is one option, and imo potentially the only one that is needed for now.

CSpydr, as this language is used by "only" 3 people to date (still, that's 2 more than I ever expected xD).

I think it's worth looking into the future, rather than at the present and tailoring to it (the future itself). A continuous development, unless CSpydr is a not to be intended to be used for anything else than hobby.

Spydr06 commented 1 year ago

I agree, having a package manager (or sth comparable) would be very nice, but it's too much work for me currently, as I have other projects that are on a higher priority right now (since they have deadlines...)

unless CSpydr is a not to be intended to be used for anything else than hobby

I don't want to disappoint you, but getting CSpydr out of the "hobby" category is (at least for me alone) impossible. CSpydr has so many issues, compatibility problems and missing features you'd have to be crazy to write production code with it.

(As in: we only suppot x86_64-gnu-linux platforms (not even musl/busybox or any bsd), there are basically no compiler optimizations, features are not fully implemented or very buggy (take the regex implementation for example))

You can write smaller programs/applications (like the text editor @hexaredecimal mentioned) that work on most mainstream linux distros, but definitely not the next cross-platform dominating web browser.

CSpydr started as a hobby and will, I'm afraid, continue being a hobby project.

Can the bindings not be kept on a separate repositories by the creators and downloaded by users and imported into their code if need be?

That's an option of course, which needs no implementation. While I'm fine with anyone doing it, I myself favor not scattering all libraries and keeping them in one place for now.