More on syntax checking vala - and a nice video

Unfortunately the vala compiler had never really been tested compiling code multiple times. So when I tried it i discovered that it leaked memory on every compile. From my breif email with Florian it apparently related to circular references that are not freed, even applying the tricks from this bug report https://bugzilla.gnome.org/show_bug.cgi?id=712694 did not help.

So for the parsing I had no other option than to spawn of another process to do the parsing and report back the results. Rather than creating another binary to handle the parsing. I decided to incorporate the parsing process into the main builder.

In this way the builder spawns itself with a few command line arguments, indicating which project/target and files to compile.

When the builder is run in this "compile mode" it outputs the results as a json string. Indicating success or failure, along with all the lines that caused errors, warnings or deprecated notices.

The code for spawning a process is based on the code originally in gitlive, which in turn is very similar to the original JavaScript code I wrote in seed. As this vala code was one of my early masterpieces, I thought I would apply some of the knowledge I had gained writing the builder.

The first change was to get rid of the spawn config class. That was a throwback to universal constructors in JavaScript, which do not really suit vala code style. When I sketched out the revised api I initially intended to use signal handlers to handle the complete/finish signal to indicate the spawn process has completed. However using a delegate as the argument for the run method seemed cleaner. This later turned I to be a source of pain.

It appears that vala and glib have a few issues passing delegates around. In the hash that had grown to be the syntax checker. There are c about three layers of methods that are called between the key up signal and the spawn process. This means that the c delegate callback was was de-referenced and segfaulted. I eventually went back to my original design of having signal handlers which was far safer.

From there I could run compiles continually while typing or changing properties. The next step was to work out how to incorporate this new feature into the UI design.

My initial concept was to have a Popover on the footer menu, that popped up and showed you a tree of the different compiler notices (Errors/Warnings and Depreciated warnings). From there you could expand it out and see the file, and work out what to change. As I tried using this, it became clear that the workflow was not really usable. I could not keep the popover up, and find the error location and sort out the fix very easily. So that UI idea got thrown out the window.

My next idea was to make the Gtk Preview Frame into a notebook, where one tab is the Gtk preview and the other is the generated source. This is what the video shows, when you double click on the file or error message in the popup, the popup disappears, the editor loads the UI component, and you can see the Generated source code in the right hand panel. From there clicking on the line (or nearby) it will work out which Tree element that that part of the code corresponds with, highlight that node. (then in turn it grey's out the source code not related to that Node). 

Most of the errors that I fix in the video are depreciated warning relating to Gtk.HBox/VBox, you can see from the video that the property editor on the left, now has knowledge of Enums, and allows you to pick values for the orientation.

There are still some issues with this part of the editor, like the code generator keeps a map of line numbers now, however it sometimes get's the numbers a little off. But the general effect is that it's fast and simple to fix code errors, warning and all other parts of the code.

This improvement has made me consider the next steps for development