[...]
Yes, I understand how the "throws" are implemented in vala, but as I said,
the existing C code isn't designed to handle that.


Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions).

Maybe I misunderstand your point still?

No, you said it exactly right, the concern is we can't use Vala "exceptions" without changing the existing C code, which somewhat negates the benefits of Vala.  
 
[...]
We could compile own if we need to embeded release, otherwise using
something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or
billions of other possibilities for creating cross-platform code as well as
we do now.


Sure we *can* do anything, but "somebody" has to do it and maintain it.


I'm volunteering. We keep saying "somebody" has to do it, and I'm proposing a way that seems the most sane/best and least time-wasting to do it, and being the "somebody" in this case (although I'm hardly a build system expert).


Look forward to its appearance on github.com/codebrainz/geany :)
 

[...]



Nope, I propose *new* Geany release will only work on *new* dependencies,
which are release in *new* distros, which are using *non-deprecated* APIs.


So you want the extra work of backporting bugfixes, or just forget about
older platforms?


I guess (according to Columban's message) this is a non-issue, we can target same versions of stuff as before, and even RHEL supports recent Valac, so it should be same old (in theory at least).

Makes sense that it should work on Linux, and if you make a Windows bundle as above then fine.
 
[...]
I would have thought that "no" above was obvious.


Is that "no" because you want to focus on re-design and not getting an in principle agreement on a good language to use?

Correct.

 
Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code?

Not yet convinced, and TBH not really convinced about a progressive change to C++ either (my original mention that sparked the thread was meant to be a sarcastic throwaway comment :).  I understand your desire to keep the discussion high level, but the devil is in the annoying little details for languages, and their implementations, so you can't make a decision without examining those details.

 


To be clear, tinkering with what language is used to tack more bandages on
to the current Geany design is a waste of time.  Choosing a better language
to implement a better design might be worthwhile.


That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2].

As I said, choosing the language first is putting the cart before the horse.  As I said in reply to Colomban, I'll start a different thread about the way we want to move, lets see where that goes.
 

P.S. Sorry if I was snarky/sarcastic in the last message, it's only because I know roughly your sentiments on the subject from our previous discussions, and could insert any topic for Vala and you'd find some points to disagree about (see most/all RFCs in ML archives) :) I just get frustrated because you're generally against every idea anyone (especially me) has, and it's hard to tell if you're being genuine or just disagreeing for the sake of disagreeing, or you think I'm too stupid to understand what I'm talking about or something.

There is definitely nothing personal about any disagreement over things.  I guess you see most disagreements simply because you post the most proposals, and thats a positive not a negative.  As I said above the devil is usually in the details, and after having been bitten many times I tend to focus on the things that might cause problems, because the things that are right will look after themselves.   I guess that can look negative, but its simply trying to prevent issues I see before they happen.

Cheers
Lex
 

Cheers,
Matthew Brush


[1]: I'd also be willing to do in plain GObject/C but it'd be a lot more boring/long/bug-prone and would result in the exact same code as Valac would generate (or likely worse), and then you'd be pointing out about how it's too much churn, boilerplate, or how G*/C sucks, etc.

[2]: Yes, the design part is fairly independent of the language part, of course we could do it ASM if we wanted, but certain tools make things a lot easier to express/organize, especially when you can type 20 lines of clean readable Vala code instead of 200 lines of organized but boring GObject code, or 150 lines of unstructured, bug/leak-prone, hard-to-follow plain C code[3].

[3]: And yes, it is possible to write structured, non-buggy/leaky, easier to follow code in plain C, but it's a heck of a lot harder, and as shown in existing Geany code, it's easier to be less rigorous when the proper "framework" of the code isn't in place.

_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel