GNOME's Git Tool Has Been Ported To Vala

[phoronix]

Phoronix: GNOME's Git Tool Has Been Ported To Vala

GitG v0.3.1 has been announced as their first release under the code's major rewrite...

http://www.phoronix.com/vr.php?view=MTU2MTA

[Annabel]

Why?

[BlackStar]

Because it's easier to write a UI in Vala than in C. It really makes a difference, especially in projects with a small developer base.

[Annabel]

Because it's easier to write a UI in Vala than in C. It really makes a difference, especially in projects with a small developer base.

Yes but they alrealy had the UI, they didn't start a new project
I don't know, I think rewriting the codebase from C to Vala would be more difficult than just working with gtk+ in C

Another question: why not some other language? Some gnome projects already use javascript, C# (I think) and Python. Why vala over them?

[BlackStar]

Yes but they alrealy had the UI, they didn't start a new project
I don't know, I think rewriting the codebase from C to Vala would be more difficult than just working with gtk+ in C

You'd be surprised

For low-level code, the difference is not so significant, but for a UI it's huge. Given that they were planning to rewrite the core, anyway, to use libgit2 instead of system("git blah") commands, someone did the crazy step of rewriting the whole thing in a simpler language.

Now that this is done, I expect GitG development to speed up considerably.

[ncopa]

Another question: why not some other language? Some gnome projects already use javascript, C# (I think) and Python. Why vala over them?

My guess is that it is because it gives best performance, lowest memory usage, fewest runtime dependencies compared to the others, while still being a nice (enough) high level language for UI coding.

I have the impression that those who would have picked javascript, C# or python would have done that because that is what they are familiar with.

I would have picked vala too for this job.

[anda_skoa]

For low-level code, the difference is not so significant, but for a UI it's huge.

I would even say for low-level code, especially if we are talking about libraries.

You get to work with a nice high-level language, yet your result is ultimately a library with a C API.

Cheers,
_

[BlackStar]

I would even say for low-level code, especially if we are talking about libraries.

You get to work with a nice high-level language, yet your result is ultimately a library with a C API.

Cheers,
_

Can you actually create a library in Vala and consume it from C without jumping through too many hoops? Like, can you create a C header to describe a Vala interface in some sort of automated fashion?

If so, then that's massively impressive.

[anda_skoa]

Can you actually create a library in Vala and consume it from C without jumping through too many hoops? Like, can you create a C header to describe a Vala interface in some sort of automated fashion?

Yes
If you create a library in Vala, the build process will generate both a Vala API description as well as a "public" C header (public as in "will be installed on make install").

If so, then that's massively impressive.

Indeed! If I had vote for a single feature for "the best feature", that would be it.

Once you understand how the name mapping works (how Vala namespace/class/function names are translated into C symbol names) you could use Vala to write drop-in replacements for bascially any GObject library.

Cheers,
_

[BlackStar]

Yes
If you create a library in Vala, the build process will generate both a Vala API description as well as a "public" C header (public as in "will be installed on make install").



Indeed! If I had vote for a single feature for "the best feature", that would be it.

Once you understand how the name mapping works (how Vala namespace/class/function names are translated into C symbol names) you could use Vala to write drop-in replacements for bascially any GObject library.

Cheers,
_

I'm intrigued.

GObject is a tad too heavy for my current C projects (massively parallel, real-time embedded stuff), but I'll definitely have to take a closer look to Vala now. A tool that generates a proper C API from higher level code sounds mighty attractive.

Indeed, roughly one-third of the code in these projects is boilerplate code: API headers, parameter contracts, argument validation, variable initialization, logging, namespace_object_create(), namespace_object_destroy() etc etc. Maintaining all these by hand is awkward, but you have to be extremely defensive or you won't get far in such a complex project without an operating system to protect you.

Other than memory overhead, Vala appears to hit all the right spots so far!