[Geany-Devel] Let's use Vala

Matthew Brush mbrush at xxxxx
Sun Nov 10 21:21:04 UTC 2013


On 13-11-10 01:44 AM, Lex Trotman wrote:
> [...]
>
>> Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and
>>> anything that can throw through C code can cause leaks since the C code
>>> doesn't clean up.  Same as C++, you can't use exceptions mixed with C
>>> code.
>>>
>>>
>> Trust me, I generated lots of C code from Vala, when you throw an
>> exception, in the CCode it throws on a GError out/result argument as you'd
>> expect in C Code.
>
>
> 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?

> [...]
>
>>
>>> Yeah, but its a binary which includes Glib and GTK IIUC, so we have to
>>> match those.  I agree its not much worse than we have now but its not very
>>> comforting that the last binaries are 2011 vala version 0.12 when even LTS
>>> Linux distros have 0.18.
>>>
>>>
>> 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).

> [...]
>>
>
>
>> 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).

> [...]
>
>> Said the fellow who have never programmed a line of Vala code in his life
>> and who likes a language like C++ which is basically the equivalent to Vala
>> for C/Gobject based applictaions.
>>
>> Ad hominem attacks have no place in this discussion list.
>

I didn't mean as an attack, just pointing out the irony that of all 
people, surprisingly, you seem to be against it the most, being someone 
who is a strong proponent of a quite similar language, good programming 
paradigms, and good language design in general :)

>
>>
>> Is it fair to consider Lex to be a +/-1 for the sake of keeping
>> discussions on-track?
>
>
> 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? Or you honestly don't 
think Vala is a good fit at all for new/re-written parts of Geany code?

> 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].

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.

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.


More information about the Devel mailing list