Here’s something I didn’t know: The DEC VT100 turns 40 in August. This factlet comes courtesy of Wikipedia, as I’m not quite old and wise enough to have made its acquaintance outside of a museum. None the less, the VT100 and its extended family of hard-working office furniture has always been with me in terms of the ECMA-48 standard, better known as ANSI X3.64 or simply (and these days, probably as accurately as any formal descriptor) “ANSI codes“, which it helped pioneer.

This pinnacle of 1970s UX is somehow still going strong, and recent developments like lots and lots of colors, ubiquitous Unicode support, good monospace fonts, etc. have opened up some interesting possibilities for creative abuse in a rich tradition that dates all the way back to manual typewriters, if not further. Previous entrants in this category are the venerable aalib and libcaca, and more recently there’s timg and others that use the U+2580 half-block symbol.

I wrote a small tool to further improve on this. It combines a range of Unicode symbols in an attempt to minimize the squared error of the output, and has plenty of bells and whistles besides. Check it out.

After all the fun we had in part 1 of our FreeIPA + DNS series, we now come to a new chapter.

During the move of openSUSE to Let’s Encrypt we used the excellent tool from ssllabs to verify each server after we changed the certificate. One of our coworkers noted “Hey, why don’t you have a CAA record. It would give you an even better score”. CAA records allow the domain owner to specify which certificate authorities are allowed to create certificates for this domain. Which seems to be a nice benefit for little work. For a longer explanation see this blog post from Qualys.

The last code I wrote during the hackfest was the start of code generation for GObject interfaces. This is so that you can do

gobject_gen! {
    interface Foo {
        virtual fn frob(&self);
    }
}

and it will generate the appropriate FooIface like one would expect with the C versions of interfaces.

It turns out that this can share a lot of code from the existing code generator for classes: both classes and interfaces are "just virtual method tables", plus signals and properties, and classes can actually have per-instance fields and such. I started refactoring the code generator to allow this.

I also took a second look at how to present good error messages when the syn crate encounters a parse error. I need to sit down at home and experiment with this carefully.

Back home

I'm back home now, jetlagged but very happy that gnome-class is in a much more advanced a state than it was before the hackfest. I'm very thankful that practically everyone worked on it!

Also, thanks to Alberto and Natalia for hosting me at their apartment and showing me around Madrid, all while wrangling their adorable baby Mario. We had a lovely time on Saturday, and ate excellent food downtown.

Hacking on gnome-class continues apace!

Philippe updated our dependencies.

Alberto made the syntax for per-instance private structs more ergonomic, and then made that code nice and compact.

Martin improved our conversion from CamelCase to snake_case for code generation.

Daniel added initial support for GObject properties. This is not finished yet, but the initial parser and code generation is done.

Guillaume turned gir, the binding generator in gtk-rs, from a binary into a library crate. This will let us have all the GObject Introspection information for parent classes at compilation time.

Antoni has been working on a tricky problem. GTK+ structs that have bitfields do not get reconstructed correctly from the GObject Introspection information — Rust does not handle C bitfields yet. This has two implications. First, we lose some of the original struct fields in the generated bindings. Second, the sizes of the generated structs are not the same as the original C structs, so g_type_register_static() complains that one is trying to register an invalid class.

Yesterday we got as far as reading the amd64 and [ARM][arm] ABI manuals to see what the hell C compilers are supposed to do for laying out structs with bitfields. Most likely, we will have a temporary fix in gir's code generator so that it generates structs with the same layout as the C ones, with padding in place of the space for bitfields. Later we can remove this when rustc gets support for C bitfields.

I've been working on support for GObject interfaces. The basic parsing is done; I'm about to refactor the code generation so I can reuse the parts that fill vtables from classes.

Yesterday we went to the Madrid Rust Meetup, a regular meeting of rustaceans here. Martin talked about WebRender; I talked about refactoring C to port it to Rust, and then Alex talked about Rust's plans for 2018. Fun times.

[arm]: