Vala deadlocks with glib 2.42

Since glib 2.41.2, the mutex/cond implementation on Linux has changed. The code compiled with Vala < 0.26 which targets at least glib 2.32 with --target-glib 2.32 will suffer from deadlocks.

Your options are either:

• Do not --target-glib 2.32
• Update Vala to at least 0.25.2
• Instead of upgrading Vala, pick the bindings for Mutex and Cond from the new glib-2.0.vapi
• Downgrade glib

To clarify, it's not a glib bug. It's an old valac bug in the glib-2.0.vapi bindings of Mutex and Cond  that became now critical after the glib implementation change.

The relevant Vala bug can be found here: https://bugzilla.gnome.org/show_bug.cgi?id=733500

Vala 0.25.1 released

This new release of the Vala programming language brings a new set of features together with several bug fixes.

Changes

• Support explicit interface method implementation.
• Support (unowned type)[] syntax.
• Support non-literal length in fixed-size arrays.
• Mark regular expression literals as stable.
• GIR parser updates.
• Add webkit2gtk-3.0 bindings.
• Add gstreamer-allocators-1.0 and gstreamer-riff-1.0 bindings.
• Bug fixes and binding updates.

The explicit interface method implementation allows to implement two interfaces that have methods (not properties) with the same name. Example:

interface Foo {
 public abstract int m();
}

interface Bar {
 public abstract string m();
}

class Cls: Foo, Bar {
 public int Foo.m() {
  return 10;
 }

 public string Bar.m() {
  return "bar";
 }
}

void main () {
 var cls = new Cls ();
 message ("%d %s", ((Foo) cls).m(), ((Bar) cls).m());
}

Will output 10 bar.

The new (unowned type)[] syntax allows to represent "transfer container" arrays. Whereas it's possible to do List<unowned type>, now it's also possible with Vala arrays.
Beware that doing var arr = transfer_container_array; will not correctly reference the elements. This is a bug that will eventually get fixed. It's better to always specify (unowned type)[] arr = transfer_container_array;
Note that inside the parenthesis only the unowned keyword is currently allowed.

The non-literal length in fixed-size arrays has still a bug (lost track of it) that if not fixed may end up being reverted. So we advice not to use it yet.

Thanks to our Florian for always making the documentation shine, Evan and Rico for constantly keeping the bindings up-to-date to the bleeding edge, and all other contributors.

More information and download at the Vala homepage.

Planet Vala

After a discussion on the mailing list about the wish of having an rss aggregator for Vala, here it comes: http://planet.vala-project.org/
The announcement can be read here: http://www.mail-archive.com/vala-list@gnome.org/msg10337.html

Please visit the home of the Vala programming language for more information.

What to expect from the wip/transform branch

You may be wondering what is it all about the wip/transform branch in the vala git lying around since a couple of years.
It introduces a new layer to the compiler in order to write transformations of Vala code into other Vala code, such that it's easier for the codegen layer to generate C code, and it's easier for us developers to write and maintain such transformations.

The current Vala pipeline is as follows:

You already got it. There are a couple of flaws in this pipeline:

• The semantic analyzer not only checks the code, but also does transformations for simplifying the code that will reach the codegen.
• The flow analyzer does not analyze the original code, rather the transformed code. This leads to loss of information, thus bugs that are fixable only by making the flow analyzer more intelligent or with hacks (see this bug for example)
• At the codegen level, we do complex transformations which are hard to maintain.

The wip/transform branch introduces a pluggable visitor for transforming Vala code into other Vala code, and it sits in between the flow analyzer and the codegen:

So this is what we gain and lose with the new approach:

• Probably this change will hit the compiler performance, but I'm planning to reduce the number of temporary variables used, thus save time at the C compilation stage. Though we always head for correctness before optimization.
• The semantic analyzer and flow analyzer no longer have the issues explained above.
• The C codegen has been extremely simplified, because now the ugly transformations are made simpler in the transformer.
• The flow analyzer needs some more code in order to handle cases that were first simplified, like conditional expressions.

Also the transformer has several cool helpers that let us write transformed Vala code using strings, like a meta language, and that's very convenient.

This new architecture naturally opens for a new feature: Vala plugins. It is possible to specify directories of plugins with --plugindir . A plugin is a file starting with "valaplugin" that is dynamically loadable (a .so, .dll, or whatelse).

There is no system directory for plugins, that's intentional:

• The feature will be experimental.
• The API of libvala is unstable, therefore having system wide plugins would lead to even more breakage for users.

The feature is still useful on the application level. You can create your own plugins to automatically generate code that otherwise requires much boilerplate. Think for example of some rpc protocol, serialization or orm.

Demonstration

Now let's have some fun with a sample plugin for registering unit tests with the glib test framework.

This is how your code would look like now:

We want it to be like this:


So let's write our beloved glib test plugin for Vala:


What we do here is:

• Hook on every method definition
• Check if they have a [Test (name = ...)] attribute
• Then find the return statement in the main() method (context.entry_point) and cache it
• Create a dummy statement placed right before the return statement
• Replace that dummy statement with Test.add_func(...).

Compile the plugin with:

$valasrc/compiler/valac -C $valasrc/vapi/libvala-0.24.vapi valaplugintest.vala
gcc -o valaplugintest.so -shared `pkg-config glib-2.0 gobject-2.0 --cflags --libs` -fPIC -I../vala -I../gee valaplugintest.c

Finally compile newtest.vala with:

$valadoc/compiler/valac --plugindir . test.vala

Status

The current wip/transform branch is usable and very promising. Many complex projects already build and run flawlessly.

* While in the picture I put the gtkmodule as transformer, this is not true yet. The gtkmodule is still in the codegen, but won't take much to port it as a transformer.

Hope the next wip/transform branch will be about a call for testing before the merge :-)

Vala 0.23.2 released

A new development version of the Vala programming language has been released.

Changes

• Bind GDK event structures as compact classes.
• Switch gdk-x11-3.0 bindings to .gir.
• Switch librsvg-2.0 bindings to .gir.
• Bug fixes and binding updates.

First I'd like to thank Rico for the great effort put on updating bindings.

Then, Gdk.EventKey & co have been converted from structs to classes, and this probably broke your code, but that's for a good reason (see this bug comment).

We're aware of this kind of breakage:

Gdk.EventMotion *e = (Gdk.EventMotion *) (&event);

This could be fixed as:

Gdk.EventMotion e = (Gdk.EventMotion) event;

For more information please visit the Vala homepage.