Builder Happenings

Over the last couple of weeks I’ve started implementing Run support for Builder. This is somewhat tricky business since we care about complicated manners. Everything from autotools support to profiler/debugger integration to flatpak and jhbuild runtime support. Each of these complicates and contorts the problem in various directions.

Discovering the “target binary” in your project via autotools is no easy task. We have a few clever tricks but more are needed. One thing we don’t support yet is discovering bin_SCRIPTS. So launching targets like python or gjs applications is not ready yet. Once we discover .desktop files that should start working. Pretty much any other build system would be easier to implement this.

So much work behind the scenes for a cute little button.

Screenshot from 2016-07-17 22-09-21

While running, you can click stop to kill the spawned application’s process group.

Screenshot from 2016-07-17 22-10-38

But that is not all that is going on. Matthew Leeds has been working on search and replace recently (as well as a whole bunch of paper cuts). That work has landed and it is looking really good!

Screenshot from 2016-07-17 22-12-45

Also exciting is that thanks to Sebastien Lafargue we have a fancy new color picker that integrated with Builder’s source editor. You can visualize colors in your source files and change them using the dropper or numerous sliders based on how you’d like to tweak the color.

Screenshot from 2016-07-17 22-11-38

I still have a bunch of things I want to land before GUADEC, so back to the hacker den for me.

Builder 3.20 development underway

I’ve been busy working on the plumbing for what will become Builder 3.20. We have a really ambitious cycle ahead of us, so getting these core changes in place as soon as possible will help give us time to stabilize.

From the early design phase of Builder, we knew we wanted multi-process plugins. Easier said than done. This cycle we are starting to follow through on that design goal by making it simple for plugins to achieve this.

I just landed the multi-process plumbing and ported our Jedi auto-completion engine to use it. Previously we were using Jedi from Python threads. It would occasionally cause the main loop to stall (likely due to GIL) as we have plugins written in Python inside the UI. Now that the work is being done in a worker process, we simply receive a large GVariant of the result set from the worker process over a private GDBus connection. This allows us to allocate/free large memory chunks instead of so many small strings which is nice. There are still a lot of strings created when sizing the completion window, but we can address that later.

Since we require GDBus, and PyGObject support for GDBus is not very convenient, we ported some of Martin Pitt’s work into the Builder G-I overrides. This means you can quickly create a GDBus service in Python with a few lines of code. It’s still not ideal, but again, we can iterate now. One thing I’d like to see is the ability to use yield to wait until an asynchronous operation completes. Python Twisted has been doing this for nearly a decade, and it’s quite pleasant to use. Also, we had to go out of our way to use GVariant from Python without unwrapping the variants. We want to avoid doing that until absolutely necessary.

The next big step in multi-process is to port the clang and vala plugins to use the same plumbing. After that, we need to get the plugins to recycle when they hit various thresholds such as undue memory consumption.

I think our story with plugins is going to become pretty compelling this cycle. Being able to write a single plugin that can take advantage of multiple-processes without destroying your code is an area where we can really shine above the competition.

I’ve also started work on distributing Builder as an Xdg-App. We have some unique constraints that will help us push Xdg-App to support some very difficult corner cases. Psuedo terminal support landed last week, so the terminal now works. Although, your terminal is inside of the mount namespace, so it won’t match your host system. That might feel a bit odd at first.

Additionally, we need to come up with a good design that allows Builder to run in one xdg-app, while building/running/testing your application from another xdg-app/runtime/sdk.

As always, lots to do! If you are interested in contributing to Builder or Xdg-App, this is a great time to get started! Come join us on in #gnome-builder and we’ll find a way for you to contribute.