[Geany-Devel] Let's use Vala

[Lex Trotman]

[...]

> 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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131111/d0683ca2/attachment-0001.html>