November Bug Squash Month: GJS

Here’s what happened during November Bug Squash Month in GJS.

First off, I didn’t really get on the ball to promote Bug Squash Month and I didn’t take pictures of any bug squashing activity… which I regret. I hope this post can make up for some of that.

During November I finally took the leap and offered to become a maintainer of GJS. My employer Endless has been sponsoring work on bugs 742249 and 751252, porting GJS’s Javascript engine from SpiderMonkey 24 to SpiderMonkey 31. But aside from that I had been getting interested in contributing more to it, and outside of work I did a bunch of maintenance work modernizing the Autotools scripts and getting it to compile without warnings. From there it was a small step to officially volunteering.

With not much of November remaining and a holiday and family visit coming up (life always is more important than bug squashing!) I decided to start out my bug-squashing campaign with what would get me the most results for the time spent: going through GJS’s bug tracker and closing obsolete or invalid bugs. This I managed to do, closing about 1/4 of all open bugs!

Then I made a list of all open bugs with attached patches and intended to review them to see if they still applied and why they hadn’t been committed yet. I got through a few, and had the dubious distinction of fixing up and committing patches from a 7 year old bug yesterday. But as you can see in the list, there are still 54 remaining. A good to-do list for the next Bug Squash Month, or whenever I feel like working on GJS but don’t know what to work on!

Did you know Bugzilla could generate graphs? I didn’t! Here’s a graph of the total bug count in GJS during November Bug Squash Month:

chart

The clunkiness of this chart kills me though…

My plans now that Bug Squash Month is over are to concentrate on fixing things that make it more pleasant to use and contribute to GJS:

  • Find an active co-maintainer so that we can review each other’s patches (could this be you?)
  • Make ES6 Promises available (this work is also being sponsored by Endless)
  • Rework the test suite to use an embedded copy of Jasmine so that writing automated tests becomes less of a pain
  • Find ways to bring in some of the conveniences that Node developers are used to

I’ve also decided to try an experiment: I’ve just made the Trello board public on which I keep track of what I’m working on and what I’d like to work on. Let me know if this is interesting to you and what features you might like to see on there! (It’s made possible by a Chrome extension, Bug 2 Trello.)

All in all November Bug Squash Month was a success, though next time I will get started earlier in the month. Come join me next time!

gnome_bugsquash_nov_2016

 

GJS and Autoconf

Here’s a leftover from the GNOME Developer Experience Hackfest that I participated in back in January: in my last post about it, I mentioned I had worked on some Autoconf macros for GJS that got added to the Autoconf Archive.

My plan was to port an existing GNOME application written in GJS to use the new macros, as an example for other projects to follow. I did so for GNOME Documents a while ago, but then forgot all about it as the patches sat spoiling on my hard drive. Recently I fixed that up and submitted a patch as I should have done long ago.

Here’s the guide to using the new macros in your project:

  • Replace any AC_PATH_PROG([GJS], [gjs]) (or, possibly, pkg-config --variable=gjs_console gjs-1.0; I might add this to the macro) with the shorter AX_PROG_GJS.
  • Use AX_CHECK_GIRS_GJS to check that you have the correct API version of each introspected dependency that you import in your code. Easy rule of thumb in a one-liner: git grep imports\.gi\. | cut -d: -f2 | awk '{$1=$1};1' | sort | uniq will pick out all the GIRs that you import. (Take special note for Cairo: its GIR name starts with a lowercase letter!)
  • Since GIRs don’t have a concept of versions other than the API version, use AX_CHECK_GIR_SYMBOLS_GJS to check for APIs that you use that aren’t available in all versions. For example, if you use the new GtkShortcutsWindow in your code, don’t try to check for GTK 3.20; instead check for the ShortcutsWindow symbol using this macro. (Use this sparingly, of course; there’s no need to check exhaustively for every new API that was added since 3.0, only the latest that you use!)

You might ask “why should I check these dependencies at build-time when they are only necessary at runtime?” You would be correct, it’s not necessary to check them at build time. However, these macros were originally born of the frustration that happens when you “make all install” a tarball only to run it and find out you’re missing GIR dependencies. And especially in the case of using new API, like ShortcutsWindow that I mentioned above, your program might even start up correctly and crash halfway through when you try to open a ShortcutsWindow. It’s a courtesy to your users (not to mention downstream operating system packagers, for whom your runtime dependencies might not be obvious.)

The macros are now also available in your JHbuild setup, through the m4-common module. How that module works is not very discoverable, and Philip W was kind enough to explain it to me when I asked how to get the new macros in. So I’ll explain it again here for future reference.

M4-common contains the agreed-upon set of M4 macros from the Autoconf Archive that GNOME applications use for building. It’s a Git repository that pulls in a known version of the Autoconf Archive as a Git submodule, and installs the M4 macros from it that GNOME applications need to build. If your application uses any of these macros, then it should have a dependency on m4-common in JHbuild.

As written on the GNOME Wiki, if you get an error like

./configure: line 12053: syntax error near unexpected token `GOBJECT_INTROSPECTION_CHECK'
./configure: line 12053: `AX_REQUIRE_DEFINED(GOBJECT_INTROSPECTION_CHECK)'

then you probably need to build m4-common and make sure you have a dependency on it.

Note that you don’t need to care about any of that if you’re building from a released tarball; that’s because Autotools bundles all the macros you use in the tarball when you run “make dist”.

Thanks to Philip Withnall and Cosimo Cecchi for code review and good ideas; and thanks to Endless Computers for allowing me to contribute these macros developed on company time to the Autoconf Archive.

Geek tip: Running Python GUIs in Sublime Text 2

I’m trying out Sublime Text 2 as a code editor on Windows, since there really aren’t any other free ones I like; unfortunately, my favorite free editor, Gedit, is abysmal on Windows. (Although it looks like something may be done about that soon.) Sublime works really well and has a distraction-free mode, and the extensibility is amazing. I’m not convinced yet that it’s worth $60 for a license — I’d probably pay $25, come on, it’s a text editor — but perhaps if I got a job where I needed text editors more often, I’d try to convince my boss to spring for it. (Although in that case, I’d more likely try to convince my boss to let me work on a platform where I could run Gedit.)

One thing that confused me is that I couldn’t get any of my Python GUI code to work on it. For example, when I’m at work in my lab, I often make small changes to my laser beam profiling program (although really it’s more of a camera driver right now; I haven’t found an excuse to actually write any Gaussian profiling code.) As far as I could figure out, I ought to be able to press Ctrl+B in Sublime Text to run the program. However, nothing ever happened, and I thought the feature must be broken.

Then one time I tried running another non-GUI Python script from Sublime Text. To my surprise, it worked! The feature apparently wasn’t really broken, just selective.

The key to this mystery was the following sentence from the Sublime Text 2 reference wiki:

On Windows, GUIs are suppressed.

Wait, what the what? Why would anybody want that? I guess so the console window doesn’t show up. Fortunately, it’s easy to remedy. Go to Preferences→Browse Packages, open the Default directory and then open exec.py in the editor. Around line 26, you’ll see:

# Hide the console window on Windows
startupinfo = None
if os.name == "nt":
    startupinfo = subprocess.STARTUPINFO()
    startupinfo.dwFlags |= subprocess.STARTF_USESHOWWINDOW

Comment out the last line of this block. Now, whenever you start a Python program, the console will be displayed. If you want to get rid of it, make your build system invoke pythonw instead of python. (Tools→Build System→New Build System, then copy Packages/Python/Python.sublime-build and change python to pythonw.)

Geek tip: ImagingSource camera in Python

In my lab there are some ImagingSource cameras that we use for detection. I was trying to get a model DMK 41BU02 to work so that I could control it directly from my measurement program and not have to use the crappy imaging software that comes with it.

Most USB cameras work with the OpenCV computer vision library without any trouble, and this is how I control them in my instrumentation library, which I wrote in Python. If they don’t work, then there is always an ActiveX interface which usually works.

The ImagingSource cameras, however, include their own driver library, IC Imaging Control. I tried to use SWIG to write a quick Python wrapper for it. However, you can only compile your program with this library if you use Visual C++. Fail!

Thankfully, this article (in German) on the blog of one Edgar Klenske tipped me off: the IC Imaging Control library is itself just a wrapper around DirectShow. That also explains why the headers only compile with VC++. Edgar Klenske’s solution is to use the VideoCapture module, which is itself a wrapper around DirectShow, which comes precompiled so you don’t have to use VC++. Luckily for me, he posted that tip just last week!

And so I was able to subclass my Camera module to interface with DirectShow cameras. Perhaps next I’ll try to install the new OpenCV 2.3 to see if their support for DirectShow has improved any.

My verdict is, never buy any camera from ImagingSource. Their slogan is, ironically, “Technology based on standards.” Sorry, but having your drivers only work with one compiler is more like a lack of standards — standards of both technology and decency.