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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
