[Geany-Devel] Let's use Vala

[Matthew Brush]

On 13-11-10 12:09 AM, Lex Trotman wrote:
> [...]
>
>> Reference counting, not memory management, ie non-cyclic structures only,
>>> fine for GTK GUI structures, but not any old structures.  And of course it
>>> only applies to structures that support reference counting, not simple
>>> types as used in most of Geany.
>>>
>>>
>> Reference counting is a valid memory management strategy used in many
>> languages like C++ or Python. Vala handles this fine and provides ways to
>> break cycles or such as expected, and more often than not it's not even a
>> concern while programming in Vala itself.
>
>
> C++ does not have memory management, and Python has a cycle breaker :) vala
> is fine by itself, but needs great care in the presence of existing *simple
> structures* (not gobjects) shared with C code as existing Geany uses.
>

C++ uses "smart pointers" and RAII for memory managment, both are 
available or equal to Vala's rendition of it. I'm not sure it has an 
automatic cycle-breaker but it has unowned vs owned references to break 
the tie.

> [...]
>
>>
>> Vala exceptions, as mentioned used GError result/out parameters, so
>> there's no change from existing code.
>>
>>
> 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.

>
>> [...]
>> It means users who are only compiling Geany don't have to install valac,
>> even though it's quite widely available. As usual, if they want to hack on
>> Geany they will need a full development environment including current
>> sources from Git.
>
>
> Yes, so long as the version in the repos or for windows works fine its not
> a problem.
>

Yep, same as current dependencies although probably slightly more 
specific versions.

> [...]
>> Which is partially the point of this discussion, simple Gobjectification
>> of Geany's code, without the crufty boilerplate of Gobject/C, moving
>> forward.
>>
>>
> Which point you failed to mention :)
>

It follows with discussions on ML and IRC about writing more 
GObject/bindable/cleaner/less crazy code. It helps to have a full 
toolbox, instead of making your own buggy toolbox and using it despite 
the runtime you already have available which dwarves your little toolbox.

> I'm still to be convinced that gobjectification is automatically going to
> do much for us, but doing it in vala not C is definitely better.
>
> [...]
>
>>
>>>   * Has Autotools and Waf support already, and using from plain GNU Make is
>>>> trivial.
>>>>
>>>>
>>> How well does the windows version work, is it up to date, since it
>>> includes
>>> Glib and GTK which versions are they, and do they match ours?  The
>>> binaries
>>> for windows vala available seem to be 0.12, even my LTS Linux has 0.14,
>>> 0.16 and 0.18 valac available, more version hell and windows issues :(
>>>
>>>
>> See current issues WRT Windows binaries, not much change with Vala, just
>> one more binary application to track version of.
>
>
> 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.

> [...]
>
>>
>>> More version hell, just what we don't need.
>>>
>>>
>> Not much/any worse than current situation, just more of an excuse not to
>> care about pre-historic, deprecated, unsupported versions of stuff we
>> shouldn't be targetting for new code :)
>
>
> I would prefer to make it *better* than the current situation rather than
> just replace one problem with another.
>

It's to facilitate writing *Better* code, no at the expense of.

> [...]
>
>> So long as its a version thats in LTS repos and has available binaries for
>>> windows that doesn't matter.
>>>
>>>
>> For developement version, IMO who the hell cares about old pre-historic
>> LTS versions, we aren't coding for them, but for their newer counterparts.
>> IME Windows support is not bad, at least no worse than existing G* stuff.
>
>
> So you propose that Geany only ever work on bleeding edge distros?  You
> were one of those who strongly argued against dropping windows support, but
> now you want to drop many of the commercial Linux users who have LTS
> distros?
>

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

I argue that without using C directly for the most part we can be on-par 
with existing portability that was using same dependencies.

> [...]
>
>>
>>> Well, you already have done that for the plugin API IIUC, but still would
>>> be needed for the rest of Geany.
>>>
>>>
>> No, the rest of Geany would (eventually) be (re)written in modern
>> GObject-style (vala-style) C thus elimitating this problem altogether (as
>> well as the need for hand-coded bindings like we have currently). In the
>> meantime, it's no worse than currently.
>
>
> No it adds another layer of complexity in the meantime with very little
> upside, tahts why I suggested below that the new design needs to be done
> first.
>

Massive upsides including less leaks, bugs, clearer syntax more 
expressive syntax, more high-level syntax, easier to make abstraction 
layers, etc.

> [...]
>
>> I don't think it matters how many know it, how many are willing to
>>> contribute is the issue, and with a mixed language application it needs
>>> two
>>> languages.
>>>
>>> And that leads to what I consider is the biggest problem with the
>>> proposal,
>>> having a project with parts in one language and parts in another.
>>>    Maintaining assumptions between them, some made by the vala compiler,
>>> some
>>> made by C coders, is going to be hard and a source of extra problems and
>>> bugs.  That alone is enough reason to not just start piling vala onto the
>>> existing Geany.
>>>
>>
>> But the languages are directly related and directly compatible. It's
>> almost impossible to know one without the other and gradually our source
>> could move towards the other. There's no way around this without just
>> saying "no", no matter which language you choose (including proper
>> GObject-style C code).
>>
>>
> Ok, so I'm saying "No".  Geany doesn't need another language and more
> complexity, it needs to be properly designed and then progressed to that
> design.  Using another language to do that is a detail only.
>

I don't believe you have ever learned or used Vala, so your "no" carries 
less weight. Althought I know you are in favour of C++ which is yet 
another higher-level language, and since you don't have to expend any 
effort you automatically agree with that, so consider Vala to be C++ for 
C/Gobject code, like C++ is for normal non-GObject code and we can be happy.

> [...]
>>
>>
>> The beauty of Vala is that it does allow for this. You can integrate
>> existing C libraries (ex. TM or Scintilla) with or without changing
>> everything to Vala and even just to small parts of new code in Vala and
>> have it be completely compatible and callable from existing C code that
>> hasn't/isnt' to be changed yet. It's like the best of all worlds.
>>
>>
> Which is why I suggested it.
>
>
>>
>>   Cheers
>>> Lex
>>>
>>> PS we discussed the inappropriateness of +-1 as a reply to something this
>>> complex on IRC, won't repeat here.
>>>
>>>
>> Just to keep down in-depth discussions before higher-level concensus is
>> reached :)
>
>
> Its not consensus if you don't know what you are agreeing to :)
>

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.

Is it fair to consider Lex to be a +/-1 for the sake of keeping 
discussions on-track?

Cheers,
Matthew Brush