Vala Programming Language

ValaBot: an AI coding assistant fine-tuned for Vala

2024-05-09T00:00:00+00:00

Enhancing AI Coding Assistants for Vala Developers#</a> </h2>
As a programmer, I've been impressed by AI coding assistants like GitHub Copilot and Codeium, which have significantly boosted my productivity. These tools excel at reducing disruptive interruptions, saving time on typing, and often completing lines of code accurately. However, I've encountered limitations with Copilot while working with the Vala programming language. Its suggestions often get muddled with similar languages like Java and C#, and it lacks training on the more common Vala libraries.
Like many other developers, I'm also dissatisfied with the dominance of Github Copilot and that open source code has been monetized without attribution or consideration for the original authors (some of whom now pay for the service).
This challenge inspired me to enhance the Copilot concept by creating an AI coding assistant that is finely tuned to provide a viable and superior alternative that caters for the specific needs of Vala developers. I began with an open-source Large Language Model that had been trained on source code - the powerful Deepseek Coder 6.7b model. This model has been trained from scratch by Deepseek AI on 2 trillion tokens sourced from GitHub. Deepseek Coder significantly outperforms other open-source coding models, such as Codellama.
I chose the Deepseekcoder-6.7b-base model as the foundation for fine-tuning because of its great benchmark performance and also because it was trained on Java and C# – languages syntactically close to Vala. This allowed me to build upon its existing capabilities and adapt it to the specific needs of Vala.
Fine-Tuning for Vala #</a> </h2>
I fine-tuned the model on Vala programming language datasets. This involved downloading as many Vala projects as I could find from GitHub, extracting the Vala source files, and splitting them into ~40 line segments. I then used Llama3 to create logical and predictable "holes" in each segment, which were then used to create the FIM (fill-in-the-middle) dataset. This data preparation process took 96 hours of GPU time using my quad-RX6800 machine over a weekend. The resulting dataset was cleaned to remove non-code elements, such as license headers, and personal identifiable information.
The Training #</a> </h2>
The fine-tuning process took 10 hours on an RTX 3090. The result was a LoRA, which was merged back into the base model, converted to GGUF, and quantized to q8_0, which is the format required by TabbyML.
The Result #</a> </h2>
The outcome was a model that is more helpful and productive for Vala-related projects. By fine-tuning Deepseek Coder, I was able to create a more accurate and effective AI coding assistant that understands the nuances of the Vala programming language. The model is hosted on Huggingface (https://huggingface.co/scowen/deepseek-coder-6.7b-vala/tree/main</a>). It can be used in VSCode, VIM, and other popular IDEs with TabbyML. The complete instructions, training scripts, and dataset are available on GitHub (https://github.com/supercamel/ValaBot</a>).
Licensing and Fair Use #</a> </h2>
As a project rooted in the principles of Free and Open-Source Software (FOSS), I believe in promoting freedom, community, and sharing knowledge. To facilitate collaboration and innovation, I've made the following resources publicly available:

The fine-tuned model weights are hosted on Hugging Face for anyone to access and utilize in a TabbyML or other deployment.</li>
The training scripts and dataset preparation process are open-sourced on GitHub, providing a transparent and reproducible framework for others to build upon.</li>
A comprehensive list of repositories used during the fine-tuning process is available on GitHub, ensuring that contributors and users can easily identify and explore the sources that made this project possible.</li> </ul>
I hope that this openness will pave the way for further advancements and refinements, ultimately benefiting the Vala developer community as a whole.
Conclusion #</a> </h2>
In this blog post, I've shared my experience with fine-tuning the Deepseek Coder for the Vala programming language, demonstrating how targeted adjustments can significantly enhance AI coding assistants. This project is just the beginning. I aim to continue developing models specifically optimized for Vala to support the Vala developer community. With the release of new base models, such as CodeQwen 7B, there are exciting possibilities for further advancements. Through this work, I hope to highlight the potential of AI fine-tuning in creating more effective coding assistants and inspire others to explore the possibilities of AI-assisted coding.
Get started with ValaBot here: https://github.com/supercamel/ValaBot</a>

Vala: the smoothest C off-ramp

2024-04-22T00:00:00+00:00

Hi! I’m Reuben, a long-time free software maintainer and author. One of my specialities is taking on mature projects from their original authors and maintaining them long-term.

In this post, I want to talk about how I’ve rewritten entire projects in Vala, to make them easier, more productive and more fun to maintain.

Vala works well with C—that’s one of its primary features and design choices. But these abilities can be used for another purpose: to provide a “smooth off-ramp” for C, converting old code step-by-step to more-maintainable Vala, without an “all or nothing” rewrite, and with the ability to reimplement C libraries in Vala, so that existing C code can still call them.

Over the few years, I have rewritten two small–to–medium-sized C code bases in Vala: the minimal Emacs clone GNU Zile</a> and the spell-checking meta-library Enchant</a>, which has been used by GNOME for years, most recently by libspelling</a>, which provides spell-checking in the GNOME Text Editor</a>. In the rest of this post, I’ll focus on the challenges I faced doing these rewrites, how Vala helped me, and discuss whether such a drastic move (of rewriting entire code bases) was in fact a good idea.

Vala is good at talking to C #</a> </h2>
Vala is designed to work well with C, and a nice consequence of this is that often one doesn’t have to think about C at all, because so many useful libraries are already conveniently bound to Vala “out of the box”. It’s impressive the degree to which some of Vala’s basic abilities, such as its “built-in” container types are “just” clever binding of GLib functions plus some syntactic sugar.
But Vala’s binding abilities are very powerful: it’s not just GLib and GObject APIs that it can bind successfully; it can bind almost any C API. Later I will also show some examples that test its limits.
Further, Vala can implement C APIs just as well as it can consume them.
Allowing C to talk back#</a> </h2>
Why would you want to implement C APIs in Vala? I have three answers for you. Firstly, maintaining a typical C code-base is a horrible experience. I just wanted to not have more memory management errors, especially to do with strings (which both Zile and Enchant are big on). It’s so easy to corrupt memory, to get lifetimes wrong, or simply get the wrong answer with C’s primitive string manipulation routines.
Secondly, implementing an existing C API in Vala gives an easier-to-maintain codebase that can be used by existing consumers, which don’t need to be C programs: they can be written in Python, Rust, JavaScript or, of course, Vala!
Thirdly, and perhaps less obviously, you can use this ability to rewrite a C program in Vala incrementally, one module (say) at a time. The result is a pure Vala application (no C APIs are being implemented), but at each step one has a complete working application, partly written in C and partly in Vala; and where C needs to call Vala, the Vala code must implement the right C APIs.
Before we start, a sanity check #</a> </h2>
I’m talking about rewriting mature code-bases. Zile dates from the late 1990s, and I rewrote it into Vala in 2020. Enchant was written starting around 2003, and I rewrote it in Vala this week (in 2024). So:

Isn’t that an awful lot of work?</li>
Won’t it introduce lots of new bugs?</li> </ul>
In other words, is it worth it? Or am I just being quixotic?
It’s not that hard #</a> </h2>
As I said above, I rewrote Enchant in Vala this week. Actually, that’s not quite true: I rewrote the core, about 2,000 lines of C. Enchant is, as I said above, a meta-library: that is, it doesn’t do spell-checking itself, but delegates to a number of libraries that do. Each one needs an adaptor plugin, which Enchant calls a “provider”, and these providers are written in C, C++ and even Objective C. I haven’t touched those (yet!).
But still, 2,000 lines of code in a week is not bad.
GNU Zile was about 8,000 lines of C, and that took me about a month.
Avoiding a plague of new bugs #</a> </h2>
Vala is well matched to C #</a> </h3>
Any time you touch code you can introduce bugs, of course: the slightest adjustment can be risky. How much more so rewriting in another language?
The good news here is that because Vala is so close to C, it is relatively easy to translate code without introducing new bugs. The syntax is sufficiently similar that code can be easily translated with some search and replace (e.g. `NULL</code> in C becomes null</code> in Vala) plus light editing (e.g. adding missing comparisons in conditions to make them boolean, so that if (ptr)</code> in C becomes if (ptr != null)</code> in Vala). C APIs can be used directly via Vala bindings, and C data structures can be replicated precisely. Vala’s static typing also helps.`
`Here’s an example of a struct in C from Zile:`
struct Region { #define FIELD(ty, name) ty name; #include "region.h" #undef FIELD }; #define FIELD(ty, field) \ GETTER (Region, region, ty, field) \ SETTER (Region, region, ty, field) #include "region.h" #undef FIELD </code></pre> The file region.h</code> contained:
`FIELD(size_t, start) FIELD(size_t, end) </code></pre> Here’s the translation into Vala:`
`public class Region { public size_t start { get; set; } public size_t end { get; set; } // …methods go here } </code></pre>`
Compare and contrast: around 2009, I translated Zile into Lua</a>. I completed the translation, but I did not release it, as I found that Lua’s lack of static type-checking made it too easy to introduce new bugs. While I was translating it I was forever finding off-by-one errors caused by Lua counting arrays and string positions from 1, while C is 0-based (as is Vala, of course). Don’t get me wrong: Lua is a great language; indeed, I have successfully written other, smaller programs from C into Lua, though I wouldn’t now recommend that; its strengths lie elsewhere.
With Vala, I recommend making the initial translation as “light” as possible: don’t use lots of Vala’s features to rewrite code. Translate `char </code> pointers to string offsets (that is, an integer string index). Make sure the translated code works first, then start simplifying. Even the “light” translation will contain simplifications, anyway: no more malloc</code> or free</code>, for example.`
`You already have a test suite, of course`#</a> </h3> The other way you avoid a plague of new bugs is with a good test suite. Sorry! There’s no way around that. If you want to alter, let alone completely rewrite code, you need to have tests. Fortunately, I had already added a fairly extensive test suite to Zile years ago, when I was trying to make sure that it really behaved exactly like Emacs. The situation with Enchant was even better: it has an exhaustive (and sometimes exhausting) test suite that checks every aspect of its API, added a few years after Enchant was written, by a commission from SIL International</a>. (A big shout-out to those who commission work on libre software, especially this sort of important under-the-hood work. These tests have saved me from introducing bugs time and time again.) Again, you have to be disciplined: no turning off the tests, or changing them as you go. Complete the translation without changing them, as far as possible. Your existing build tool is probably supported#</a> </h3> Many Vala projects these days are using the Meson</a> build system, which is very popular in the GNOME space. But Vala is also supported well by older tools, such as CMake</a> and GNU Autotools</a>. Both of the projects I translated were using GNU Autotools, and I stuck with it, for two main reasons: I use the excellent gnulib</a> portability library to ensure that my POSIX-compliant code runs on most systems without problems. Unfortunately, gnulib is tied to GNU Autotools. But then, few build systems work on as many platforms as the Autotools in any case.</li> Automake</a> not only has Vala support, but allows you to ship the generated C sources, so that users can build your code without a Vala compiler. This means that your translated project has exactly the same build dependencies as it had before, which can help with users and packagers who haven’t heard of Vala and don’t want to learn. With Zile, previously a pure-POSIX project, I added GLib as a build-time dependency, but of course that’s so widely used that it’s unlikely to be a problem. Enchant already used GLib.</li> </ol> The Vala experience#</a> </h2> I will now describe the process of translating the two code-bases. Although they were a bit different (Zile an application, Enchant a library), and I made the translations a few years apart, I was pleasantly surprised to find the second time that the process was much the same as the first. Add Vala to the build system#</a> </h3> With Autotools, this is a matter of adding a couple of configure.ac</code> lines to detect the Vala compiler and check for GNU Make (which is required to build from Vala sources), and then adding a test Vala source file to a Makefile.am</code>. Translating the code#</a> </h3> I typically translate one file at a time. The code will of course usually call functions from other parts of the program: I add a private VAPI file with suitable bindings. You can usefully pre-populate the VAPI file with the commented-out contents of relevant C header files, then just uncomment the APIs you need in Vala, and edit them suitably. The excellent Manual bindings</a> guide from the Wiki is my constant companion. To translate a file, I copy foo.c</code> to foo_vala.vala</code>. (The _vala</code> bit ensures that the Vala-generated C won’t overwrite the original file, which I will keep for reference.) I translate the code, possibly in multiple steps, commenting out the bits I have translated in foo.c</code>. Compile, test, fix, rinse, repeat. I find that I get a nice rhythm with my translation, of doing the obvious basic syntactic stuff, as mentioned above, then finding the equivalent Vala APIs where necessary, then tackling any hard bits, such as binding third-party APIs that Vala does not yet know about. For Zile I leaned heavily on the POSIX VAPI, and added a new GNU VAPI for some GNU-specific APIs, which I have also used and extended while translating Enchant. Enchant was easier on the whole, because it was already GLib-based, so I just had to search valadoc.org</a> for the Vala versions of the GLib APIs. For Zile, I found libgee</a> invaluable, with its superior collections that are both richer than GLib’s and allows extra use cases, such as collections of unboxed simple types (e.g. ArrayList<int></code>). For Enchant, it so happened I didn’t need this extra functionality; Enchant’s use of collections is mostly limited to singly-linked lists of objects and hash tables with string keys. Stumbling blocks…#</a> </h3> Documentation and API coverage#</a> </h4> Vala is a small ecosystem, even after all these years. Hence, I found bugs, mostly in the documentation. I took the time to submit fixes</a>, and this past week reaped the rewards! Some of these fixes went as far as GLib itself; many were to the Vala wiki. As I noted above, I also made additions to the VAPIs, in particular adding a complete binding for the POSIX, GNU and BSD regex APIs (Zile only needed the GNU API, but since the GNU regex module implements all three, I thought I might as well!), as well as getopt_long()</code>. I added freopen</code> to the POSIX VAPI (as FILE.reopen()</code>), upgraded the curses VAPI to improve its Terminfo coverage and add key-codes for function keys, and added return codes to GLib’s FileStream.putc</code> and puts</code>. I was also able to offer my old-school expertise to the Vala project itself: I converted the test suite to use Automake’s relatively recent ability to run tests in parallel. Falling between two stools#</a> </h4> Vala itself mostly insulates you from the memory-management woes that bedevil C, but mid-translation there is still C code, so you have to be careful if you want to keep a working program. It’s always tempting to just plough on with the translation and hope that crashes will disappear, but I try not to give in, as that can bury bugs deeper and make them harder to find later. So, expect to spend some time studying valac</code>-generated C, and revising your knowledge of owned</code> and other esoteric Vala features. For me, this is particularly relevant to Enchant, as a C library whose API and ABI I want to maintain. I am happy to report that I have been mostly successful, and at the time of writing I am tracking down some problems with object lifetime management, but otherwise the Vala implementation seems to perfectly replicate the C. Another area of awkwardness is strings: as I hinted above, C often uses pointers to refer to string positions, whereas in Vala it’s usual to use integer offsets. This code is fairly easy to convert once you get the hang of it. Since C can use offsets instead of pointers, you can always rewrite the code in two stages, first changing the C to use offsets, and then translating it into Vala. Here’s an example of the translation from pointers in C to offsets in Vala. The C version refers to positions in strings with pointers: char enchant_iso_639_from_tag (const char const dict_tag) { char new_tag = strdup (dict_tag); if (new_tag == NULL) return NULL; char needle = strchr (new_tag, '_'); if (needle != NULL) needle = '\0'; return new_tag; } </code></pre> In Vala, we use string offsets: static string iso_639_from_tag(string dict_tag) { return dict_tag.substring(0, dict_tag.index_of_char('_')); } </code></pre> The comparison here is perhaps obscured by the simplification obtained in Vala from automatic memory management, which is nothing to do with string handling per se. Binding challenges#</a> </h4> I had a number of particular challenges. Some of them may be relevant to other developers, but I detail them here mostly to illustrate that Vala can bind just about anything if you try! config.h</code>#</a> </h5> Like any Autoconf-based build system, mine produce a config.h</code> header of various #define</code>d symbols, some of which my C code uses. These I simply replicate in a Config</code> module</a> One could imagine generating this automatically from config.h</code>, but since I didn’t need more than a handful of values in my projects, I didn’t bother. relocate</code>#</a> </h5> This is a GNU API that returns a string that may or may not be malloc</code>ed. You can tell which easily enough: if the return value is different from the argument, then it is a newly-allocated string. The problem is getting Vala to do the right thing. Even in C, I wrote my own wrapper function that would always return a malloc</code>ed string. Here’s the Vala VAPI definition: [CCode (cheader_filename = "relocatable.h", cname = "relocate")] private unowned string _gnulib_relocate(string path); </code></pre> I use the name _gnulib_relocate</code> because I am about to add a Vala wrapper which uses the original name. We tell Vala that the return value is unowned</code>, to prevent Vala thinking that it must free</code> it. Here’s the wrapper, which I also put in the VAPI: [CCode (cname = "_vala_relocate")] public string relocate(string path) { unowned string newpath = _gnulib_relocate(path); // If relocate malloced, then return the value, defeating Vala's attempt // to (re-)strdup it. GLib.return_val_if_fail(newpath.data == path.data, newpath); // Otherwise, allow Vala to strdup the non-malloced return value. return newpath; } </code></pre> This is tricky. First, it calls the “real” relocate</code> (but using its Vala name), and stores the result in an unowned</code> string. So far, valac</code> will not allocate any memory. We then test the value returned, and if it is unequal to the original argument, return it. Because we use the return_if_fail</code> macro, valac</code> will not insert memory allocation code at this point, but that’s OK, because relocate</code> has already malloc</code>ed in this case, so the return value is an allocated string</code> as indicated. Otherwise, we simply return</code> the un-malloc</code>ed value. In the generated C, valac</code> will insert a g_strdup</code> at this point, so again the return value is an allocated string. Phew! strfreev</code>#</a> </h5> Rather surprisingly, while g_strfreev</code> takes char </code> (because it frees a list of strings), strfreev</code> takes string </code>. Why? Well, Vala uses one level of pointer indirection to indicate that a value is not managed by Vala. So we have the following set of equivalences: string</code> = char </code> (generates char </code>; as we expect, a string is a pointer to char</code>)</li> string </code> = char </code> (generates char </code>; this is just a string</code> that Vala does not manage)</li> string </code> = char </code> (generates char </code>; now we have a list of string</code>)</li> </ul> This was a problem for me because I wanted to use strfreev</code> to free a “real” char </code> passed in from C. But valac</code> gives a type error. I got sufficiently confused that I submitted a merge request</a>, and Rico had to de-confuse me. In the end, all I needed was a cast: strfreev((string *)c_string_list); </code></pre> The cast placates valac</code>, and the generated C ends up calling g_strfreev</code>, which expected a char **</code> all along. [s]size_t</code> is not really [s]size_t</code>#</a> </h5> When compiling my Vala version of Enchant on Windows, I accidentally tried compiling it in a flavour of Windows I don’t normally test, namely Mingw MSYS (I normally build for Mingw64-x86_64 and Mingw64-i686). To my surprise, I got a compilation error: GCC complained that one 8-byte signed integer type (long int</code>) was incompatible with another 8-byte signed integer type (long long int</code>). Yes, these are both 64-bit types on this system, and yes, they are nonetheless incompatible. But why did I have this problem in the first place? I was using Vala’s ssize_t</code>, and Vala maps this to GLib’s gsize</code>. I don’t know why, but it’s a problem, because in some cases, like mine, these two types end up with different fundamental types in the C compiler, and an error results. I filed an issue</a> and found a workaround, which was to copy the definition of size_t</code> and ssize_t</code> from posix.vapi</code>, which are normally only used when valac</code> is used with --profile posix</code> and the GLib definitions are not used. The posix.vapi</code> definitions correctly map size_t</code> in Vala to size_t</code> in C. …and helping hands#</a> </h3> I mentioned above that Vala is a small ecosystem. An up-side to this is that it’s friendly and usually quick to get things done. The fixes I offered were mostly triaged and applied by the indefatigable Rico Tzschichholz, who was often able to suggest more elegant solutions, mostly for my VAPI bindings. I ended up using a pre-release of valac</code> for Zile, but I could release the code, since you didn’t need valac</code> to build it, and within a few months, Vala 0.52 was released with all the fixes I needed. With Enchant I have had help from Rico again, and also from Lorenz Wildberg; many thanks to both of them, and to everyone else in the community to has both helped me with my projects, and welcomed my own contributions, which, I hope, improve things for everyone else. Was it worth it?#</a> </h2> With GNU Zile I can say: probably, yes. I found one “brown-paper bag” bug in the initial stable release, but that’s it: I have made only two non-alpha releases of the Vala version. On the other hand, the C version was already very stable, and I suspect it’s not widely used any more (I myself have encouraged users to migrate to Emacs for some years!). But then, it was a low-risk project to try out this new technique. And a few years on, the code still builds with no problems: unlike some language ecosystems, Vala seems very stable, and code does not rot fast. For Enchant, it’s too early to say. It’s a much more widely-used package, and though it is quite mature, I have steadily improved and developed it over the past few years, and intend to continue in future. I hope that the switch to Vala will not annoy packagers (it shouldn’t, as they shouldn’t have to change their recipes at all if they don’t want to), and that developers should not notice (because the library remains API and ABI compatible), nor users (because the functionality should be identical, and the performance much the same). Certainly, I expect it will make my future work more productive and fun! Is this a good idea?#</a> </h2> My projects are old-school: highly portable, low-level C. This is not an area that Vala is particularly aimed at, although it does pretty well here. For projects that are firmly in the GLib world, and especially when they use related libraries such as Gtk, rewriting C in Vala seems an excellent option to me. While I completely rewrote my projects before releasing them, I think I’ve shown there’s no need to do that. When I rewrote Zile in Lua, the intermediate steps had horrible performance, because the Lua/C interface I used was very inefficient (Lua has an efficient-but-complex C API; I chose to use some simple-but-slow home-grown macros instead). When I rewrote Zile in Vala, the performance was much the same at every stage of the process, and I could easily have translated just half of the code and released the project. Many projects, particularly larger ones, might benefit from such an approach. After completing the translation, the code was already significantly shorter and more readable than in C. This in turn unlocked further simplifications: able to “see the wood for the trees” it was much easier to refactor and further simplify the code. With Zile, I eventually reduced 8,000 lines of C to 6,000 of Vala, a 25% reduction; in Enchant the percentage saving was more like 35%, largely because of a reduction in GLib boilerplate, such as argument validation, which Vala mostly automates. One final thought: I hope that Vala will continue to flourish for many years, but if it doesn’t, then all is not lost: in the worst case, I or my successor could salvage the generated C code, which is ugly but far from impossible to read (and C, I think we can confidently say, will be around for many decades yet); and Vala is also a relatively “neutral” language that would be easy to translate again, into Rust, say; indeed, it would be easier to do that starting from Vala than from C, largely because the Vala code is easier to read and understand. You are always invited to join our matrix chat #vala:gnome.org</a> and ask questions about Vala or how to contribute. Until then, have a nice time and build great apps with Vala!

print("Hello Planet GNOME"); 2023-10-11T00:00:00+00:00 Hello to all of you reading Planet GNOME</a> right now! This is the first post from the Vala Blog</a> now appearing in the big wide world of GNOME. Big thanks to the Planet GNOME team and Felipe Borges for making this possible! This blog is operated by the Vala project and we are posting here once in a while about new Vala releases, noteworthy changes like new features and how to use them, interesting projects using Vala and their experience with it and other stuff related to the Vala programming language. If you have an idea to write about something that fits one of the categories above, reach out to us and we are sure eventually a great article will be released! (Talk to us here</a>) Stay tuned for the next posts coming out! :) Vala 0.56 2022-03-18T00:00:00+00:00 After 4 months of work we are proud to announce a new release of Vala. This time it contains lots of new language features and advancements and of course also the usual bug fixes and binding updates. Asynchronous Main Function#</a> </h2> With the new release the main function can now be defined as async</code>. This has multiple advantages. For example is it now possible to call asynchronous functions with yield</code>: async int main (string[] args) { string dir = args.length == 2 ? args[1] : "."; var file = File.new_for_commandline_arg (dir); try { FileEnumerator enumerator = yield file.enumerate_children_async ( "standard::*,time::*", FileQueryInfoFlags.NOFOLLOW_SYMLINKS ); List<FileInfo> children = yield enumerator.next_files_async (int.MAX); print ("total %lu\n", children.length ()); foreach (var info in children) { // <file-type> <access-date> <size> <name> print ("%26s %24s %10"+int64.FORMAT+" B %s\n", info.get_content_type (), info.get_access_date_time ().to_string (), info.get_size (), info.get_name ()); } } catch (Error e) { printerr ("failed to enumerate files - %s\n", e.message); return 1; } return 0; } </code></pre> In main blocks (experimental feature that allows it to write code in a file without putting in a main function) invoking functions with yield</code> is also supported by making the main block automatically asynchronous. Merge Request #226</a> Nested functions#</a> </h2> A simple but very useful feature is to be able to nest functions inside of other functions or methods. These functions are then only visible to the code in the function that contains the nested one. But on the other way the code in the nested function has access to variables in the upper method. Actually they are only lambdas assigned to a local variable. Use cases are to structure very complicated functions into multiple smaller ones, without exposing them publicly. In this example the same asynchronous callback is used for two invocations, in which you otherwise would use lambdas: void write_streams (OutputStream stream1, OutputStream stream2, uint8[] data) { void nested_function (Object object_source, AsyncResult result) { OutputStream stream = object_source as OutputStream; try { ssize_t size = stream.write_async.finish (result); stdout.printf (@"Written $size bytes\n"); } catch (Error e) { stderr.printf ("Error writing to stream: %s", e.message); } } stream1.write_async (data, nested_function); stream2.write_async (data, nested_function); } </code></pre> Merge Request #203</a> Redesign of error and warning output#</a> </h2> If programming errors are outputted at compile time in a pretty way and provide as much information as possible, they massively help and speed up finding the mistakes and correcting them. In the new release this part got an update. Look at the differences yourself: Before Vala 0.56: int foo = bar(); ^^^ </code></pre> Vala 0.56: 2 | int foo = bar(); | ^~~ </code></pre> What looks better? :) Issue #764</a> Dynamic invocation of Signals#</a> </h2> Libraries using the GObject type system are providing usually documentation about their API so other languages can use them. However sometimes some parts are missing. With the dynamic</code> keyword an object can be treated as not having all properties or signals specified and they can be accessed dynamically without checking: dynamic Gst.Element appsink = Gst.ElementFactory.make ("appsink", "my_src"); appsink.max_buffers = 0; appsink.eos.connect (on_eos); Gst.Sample? res = appsink.pull_sample.emit (); </code></pre> As you can see, signals are now also callable with .emit ()</code>. This is necessary to differentiate between a method or a dynamic signal. But this syntax can be also used with non-dynamic variables if wanted. Merge Request #227</a> Partial classes#</a> </h2> In rare cases, if a class is so huge and complex, it can be now split up into multiple pieces even into multiple files. All parts of the class only need the partial keyword in front of it. public partial class Foo : Object { public double bar { get; set; } } public partial class Foo : Initable { public virtual bool init (Cancellable? cancellable = null) { stdout.printf ("hello!\n"); this.bar = 0.56; return true; } } </code></pre> Merge Request #200</a> Length-type for Arrays#</a> </h2> The length of an array is usually specified by an 32bit integer. However in some cases, especially in bindings to other libaries, sometimes the length of an array is given by a different type of integer. We now have support for that: string[] list = new string[10:uint8]; </code></pre> Issue #607</a> Foreach support on Glib.Sequence and Glib.Array#</a> </h2> This small change will be a big improvement for users of these data structures. Instead of manually looping with for, they are now ready to be used with a foreach loop over the items in the sequence or array. Merge Request #234</a> New Bindings#</a> </h2> A bunch of new bindings to libraries got added this release. Here is a list: libsoup is now also available in version 3.0 and webkit2gtk in version 4.1 and 5.0 so you can start porting you Vala apps to the new releases of these libraries</li> linux-media can now be used from Vala. There were also lots of more additions and fixes in other linux kernel interface bindings.</li> During the port of the gnome-desktop library it was splitted up into gnome-desktop-4, gnome-rr-4 and gnome-bg-4. They are all now available to use in your new app.</li> The GLib vapi was updated to version 2.72, including the new Signal- and BindingGroups and DebugController</li> </ul> GNOME Getting started tutorial#</a> </h2> The GNOME developer documentation has besides other stuff a excellent section on getting started with GTK and app development. Most of the tutorials</a> there have now code examples in Vala. So read it and write your first Vala application! :) Vala Flatpak Sdk Extension#</a> </h2> You can find on flathub now the org.freedesktop.Sdk.Extension.vala</code> Extension. It contains the Vala compiler, language server and more tooling. You can use it either for compiling your Vala app, or if you need for example the language server at runtime, like an IDE. Instructions can be found at the flathub repository</a>. Google Summer of Code#</a> </h2> We have proposed a project idea for the Google Summer of Code for working on Vala. If you are interested, check out the project ideas page</a> on GNOME discourse. You are always invited to join our matrix chat #vala:gnome.org</a> and ask questions about Vala or how to contribute. Until then, have a nice time and build great apps with Vala!

Foreach support on Glib.Sequence and Glib.Array #</a> </h2>
This small change will be a big improvement for users of these data structures. Instead of manually looping with for, they are now ready to be used with a foreach loop over the items in the sequence or array.</p>
Merge Request #234</a></p>

GNOME Getting started tutorial #</a> </h2>
The GNOME developer documentation has besides other stuff a excellent section on getting started with GTK and app development. Most of the tutorials</a> there have now code examples in Vala. So read it and write your first Vala application! :)</p>

Vala Programming Language

ValaBot: an AI coding assistant fine-tuned for Vala

Vala: the smoothest C off-ramp

print("Hello Planet GNOME");

Vala 0.56

Vala Programming Language

ValaBot: an AI coding assistant fine-tuned for Vala

Vala: the smoothest C off-ramp

Before we start, a sanity check#</a> </h2> I’m talking about rewriting mature code-bases. Zile dates from the late 1990s, and I rewrote it into Vala in 2020. Enchant was written starting around 2003, and I rewrote it in Vala this week (in 2024). So:</p> Isn’t that an awful lot of work?</li>

print("Hello Planet GNOME");

Vala 0.56