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'

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.

Moving text messages between Android phones

I recently got a new Android phone secondhand, and after resetting it I wanted to move the text message archive over from my old phone. It turns out that you can do this easily if you have root access. Well, technically you can do anything easily if you have root access, but the trick is knowing how. I hope that by putting this out on the internet, other people will be able to know how too.

I had root access on both phones, as they were flashed with CyanogenMod. The new phone is a Nexus 4, and the old phone is an HTC G1 (Android 2.2 is the highest that could run on it.)

On both (and as far as I know, all) versions of Android, all the text messages are stored in this file, which you need root access to read:


Getting the file off the G1 was easy; I entered the Terminal Emulator app (I think it’s installed automatically when you flash CyanogenMod) and copied the file to the SD card:

cp /data/data/com.android.providers.telephony/databases/mmssms.db /sdcard/

(su requests superuser permissions, which you have to grant.) Then I connected the G1 to my computer with its USB cable and transferred the file off of it.

Getting the file onto the Nexus 4 was harder. What I did not know is that the Nexus 4 can’t mount its SD card as USB Mass Storage (see the explanation), so I ended up using my Apple laptop to do the transfer, and had to download a program called Android File Transfer. Still, I got it onto the phone’s SD card.

Since the newer version of Cyanogenmod comes with a file manager app, I decided to use that to put the file into the correct place, instead of Terminal Emulator (typing shell commands on a phone is no joke.) The file manager is set to “Safe mode” by default which means it won’t request root access. I changed it to “Prompt User mode” in the settings, then navigated to the above databases/ folder and made a backup copy of the old (empty? 100 KB? It’s a sqlite DB so maybe there are still deleted records in there, but I don’t care to check) database. Then I copied the G1’s mmssms.db file over top of it. Unlike on the G1, there was also a mmssms.db-journal file there, which I hoped wouldn’t mess with things…

I couldn’t see my text messages after going into the messaging app, but after rebooting the phone, they were there.

Geek tip: Malloc debugging on OSX

I’ve been trying to chase down an annoying bug that I suspected to be a case of using uninitialized memory. The problem is, it only shows up about 1 in 30 times (I was lucky to notice it in the first place), and never in a debugger.

Fortunately I found that there’s a library on OSX that tweaks malloc() to help you debug:

DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib MallocPreScribble=1 ./myprogram

Or, to do this in LLDB, since due to System Integrity Protection, your linker-affecting environment variables get wiped when you execute a system program:

lldb -- ./myprogram
env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
env MallocPreScribble=1

This triggered the bug every time, both inside and outside the debugger.

For more information about what you can do with libgmalloc, see this documentation. It only tells how to use that facility in Xcode, though, so the above instructions should help if you’re on the command line.

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.)

Hacking the context menu on Windows

I use Gedit, my favorite text editor, even on Windows. Often I just want to use it to see what’s inside some text file that doesn’t have a “.txt” extension, but the way to do that on Windows XP is just simply brain-dead:

  • Right click.
  • “Open”.
  • See a dialog claiming that “Windows cannot open this file.” LIES! ALL LIES!
  • Click “Select the program from a list.”
  • Scroll scroll scroll through a huge-ass list until you get to Gedit.

This is one of those little annoyances that make working with computers unpleasant, so the other day I resolved to fix it. The information in the first Google screenful was sketchy and I had to patch it together, so I know for certain that next time I have to do it, I won’t remember what I did. Hence this post. Of course, it will work with any other program than Gedit too, so hopefully this will be helpful to somebody.

The easiest way is to put a link to the Gedit executable in C:\Documents and Settings\<username>\SendTo. That way, Gedit will show up in the Send To menu when you right-click on a file. But there’s a better way for even lazier people:

Open Regedit (Windows+R, regedit, enter) and go to HKEY_CLASSES_ROOT/*/shell. The “shell” key didn’t exist at first, so I had to create it. Then under the “shell” key, just create a new key and call it “Open with Gedit” or whatever you want the menu item to be.

Then create a new key under “Open with Gedit” and call it “command”, with a lowercase ‘c’. Double click on the “(Default)” value in it, and enter

C:\Program Files\Gedit\bin\gedit.exe "%1"

or wherever your Gedit executable is located. I found that leaving out the quotes around “%1” also works, but then the filename displayed in Gedit is mangled to fit 8.3, like “ELECTR~5.CSV”.

After reciting this incantation, you can right-click on any file and there it is, “Open with Gedit”. Wow, that was the easiest, and not at all obscure, piece of cake ever!