Do not link against PulseAudio and JSON-GLib < 0.16

this is a public announcement.

if you link against PulseAudio, whether you want it or not, you’ll get an automatic dependency on json-c, a small C library that parses JSON and doesn’t have any dependency1. sadly, json-c leaks symbols all over the place, and one of them is called json_object_get_type2.

JSON-GLib, the library that yours truly wrote about 6 years ago to parse JSON using a decent C library as a base, also has a type called json_object_get_type3.

if you link against PulseAudio and JSON-GLib4 then you’ll get a segmentation fault with a weird stack trace, like this one and its duplicates5.

the solution is to use a version of JSON-GLib greater than 0.16.1, which builds JSON-GLib with the -Bsymbolic linker flag6.

that would be all.

  1. which is arguably a plus for a system daemon []
  2. which returns an integer for I don’t know which reason []
  3. which returns a GType for the JsonObject boxed structure, so that you can use them in properties and signal marshallers; as it happens, GType is a long lookalike []
  4. or any other library that depends on JSON-GLib, like Clutter []
  5. since both return values and arguments of the functions above are compatible, the linker won’t moan about it, so you won’t see any warning or error when building your code []
  6. another solution is to statically link json-c inside PulseAudio instead of dynamically linking it; another solution is to link json-c with -Bsymbolic; yet another solution would be for PA to not use a dependency to parse JSON – or drop JSON entirely because I can’t for the life of me understand why an audio server is dealing with JSON at all []
Posted in Uncategorized | Comments Off

The King is Dead

I guess a lot of you, kind readers, are pretty well-acquainted with the current idiomatic way to write a GObject type. it’s the usual boilerplate, plus or minus a bunch of macros:

// header
typedef struct _MyObject MyObject;
typedef struct _MyObjectPrivate MyObjectPrivate;
typedef struct _MyObjectClass MyObjectClass;

struct _MyObject {
  GObject parent_instance;
  MyObjectPrivate *priv;
};

struct _MyObjectClass {
  GObjectClass parent_class;
};

GType my_object_get_type (void);

// source
struct _MyObjectPrivate
{
  int foo;
};

G_DEFINE_TYPE (MyObject, my_object, G_TYPE_OBJECT)

static void
my_object_class_init (MyObjectClass *klass)
{
  g_type_class_add_private (klass, sizeof (MyObjectPrivate));
}

static void
my_object_init (MyObject *self)
{
  self->priv = G_TYPE_INSTANCE_GET_PRIVATE (self,
                                            my_object_get_type (),
                                            MyObjectPrivate);
  self->priv->foo = 42;
}

boring stuff that everyone had to remember1. the last big change in the way people write GObject happened 10 years ago, and it was the addition of per-instance private data. it seems to me like a good way to celebrate that occasion to change this stuff all over again. ;-)

at the latest GTK+ hackfest, Alex and Ryan had a very evil, and very clever idea to solve a problem in how the per-instance private data is laid out in memory. before that, the layout was:

[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]

as you can see, the offset of the private data for each type changes depending at which point in the class hierarchy initialization we are, and can only be determined once the whole class hierarchy has been initialized. this makes retrieving the pointer of the private data a pretty hard problem; one way to solve it is storing the private pointer when we initialize the instance, and we spare ourselves from type checks and traversals. the main problem is that, in order to get to the private data faster, we need to rely on a specific layout of the instance structure, something that is not really nice if we want to have generic accessors to private data2. for that, it would be really cool if we could only have offsets to through to G_STRUCT_MEMBER().

well, it turns out that if you’re doing memory allocations for the instance you can overallocate a bit, and return a pointer in the middle of the memory you allocated. you can actually allocate the whole private data in a decent layout, and only deal with offsets safely — after all, the type information will store all the offsets for safe access. so, here’s the new layout in memory of a GObject3:

[TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]

that’s neat, isn’t it? now all private data can be accessed simply through offsets, and accessing it should be just as fast as a private pointer.

I can already see people using Valgrind preparing torches and pitchforks — but fear not, my fellow developers: GLib now detects if you’re running under Valgrind, and it will communicate with it4 about this new memory layout, as well as keeping a pointer to the beginning of the allocated region, so that you won’t get false positives in your report.

this was the state at the end of the hackfest. on top of that, I decided to contribute a bunch of “syntactic sugar”5 to cut down the amount of lines and things to remember6, as well as providing a good base towards making GProperty work better, and with fewer headaches.

so, here’s how you create a new GObject type in the Brave New World:

// header
typedef struct _MyObject MyObject;
typedef struct _MyObjectClass MyObjectClass;

struct _MyObject {
  GObject parent_instance;
};

struct _MyObjectClass {
  GObjectClass parent_class;
};

GType my_object_get_type (void);

// source
typedef struct {
  int foo;
} MyObjectPrivate;

G_DEFINE_TYPE_WITH_PRIVATE (MyObject, my_object, G_TYPE_OBJECT)

static void
my_object_class_init (MyObjectClass *klass)
{
}

static void
my_object_init (MyObject *self)
{
  MyObjectPrivate *priv = my_object_get_instance_private (self);

  priv->foo = 42;
}

the my_object_get_instance_private() function is generated by G_DEFINE_TYPE, so you can forget about G_TYPE_INSTANCE_GET_PRIVATE and all that jazz. also, no more g_type_class_add_private() — one less thing to remember is one less thing to screw up. you can still store the private pointer in your instance structure — and if you care about ABI compatibility, you really should — but for new code it’s not necessary. you can finally hide the private data structure inside your source code, instead of having the typedef in your header, sitting there, taunting you. finally, everything is just as fast as it was, as well as backward compatible.

stay tuned for the next blog post, because it’ll finally be about GProperty…

  1. or commit to a script to autogenerate it []
  2. say, for instance, if we’re re-implementing the way properties are handled in GObject []
  3. well, of any GTypeInstance, really []
  4. yes, you can do that, and it’s an impressive amount of crack, luckily for us hidden behind the valgrind.h header provided by the Valgrind folks []
  5. i.e. pre-processor macros []
  6. the port of GIO to the new macros lost around 900 lines []
Posted in Uncategorized | Tagged , , , | Comments Off

California One Youth and Beauty Brigade

now, that was a title of a Decemberists song that I’d have never expected to use as a blog post title

I did announce it on foundation-list, given that it impacts my position on the Board of Directors of the GNOME Foundation, and I did a sneaky tweet as well, but I guess the blog (and Planet GNOME) is still the Old Fashioned Way™ to do these things — and seeing that Cosimo beat me to a punch, it’s worth saying that I have joined Endless Mobile as well.

my last blog post about my work life was a bit depressing, I guess; I received a ton of support and encouragement from many, many people — too many to thank effectively in the narrow margins of this blog. I did take the announced month off, and I was already on my way to recovery; then I met Matt, who told me about Endless, and what they were trying to do with GNOME, and I felt the absolute need to help them as much as I could. after all, aren’t we trying to make GNOME a viable proposition for OEMs and OSVs to take and put on their own devices? I’m sure we’ll be able to start telling the community at large more details about what we want to achieve, and how.

in the meantime, I expect to see people in San Francisco a bit more often (though I’m still going to be based on London for the foreseeable future), and I’ll obviously be at GUADEC in Brno.

Posted in Uncategorized | Tagged , , | Comments Off

GTK+ Hackfest 2013/Day 1 & 2

Day 1

it turns out that this week wasn’t the best possible to hold a hackfest in Boston and Cambridge; actually, it was the worst. what was supposed to be the first day passed with us hacking in various locations, mostly from home, or hotel lobbies. nevertheless, there were interesting discussions on experimental work, like a rework of the drawing and content scrolling model that Alex is working on.

Day 2

or Day 1 redux

with the city-wide lockdown revoked, we finally managed to meet up at the OLPC offices and start the discussion on Wayland, input, and compatibility; we took advantage of Kristian attending so we could ask questions about client-side decorations, client-side shadows, and Wayland compatibility. we also discussed clipboard, and drag and drop, and the improvements in the API that will be necessary when we switch to Wayland — right now, both clipboard and DnD are pretty tied to the X11 implementation and API.

after lunch, the topic moved to EggListBox and EggFlowBox: scalability, selection, row containers, CSS style propagation, and accessibility.

we also went over a whole set of issues, like positioning popups; high resolution displays; input methods; integrating the Gd widgets into GTK+, and various experimental proposals that I’m sure will be reported by their authors on Planet GNOME soon. :-) it was mostly high level discussion, to frame the problems and bring people up to speed with each problem space and potential/proposed solutions.

we’d all want to thank OLPC, and especially Walter Bender, for being gracious hosts at their office in Cambridge, even on a weekend and the GNOME Foundation.

Posted in Uncategorized | Comments Off

GUADEC is coming

this is a PSA: if you’re thinking about submitting a talk for GUADEC 2013 in Brno, you have a week to do so. :-)

Posted in Uncategorized | Comments Off

I’ve been asked to review the GNOME 3 Application Development Guide for Beginners; I went through the book in about half a day and wrote this somewhat short review afterwards, and published on G+; sadly, I used a limited distribution, and G+ does not allow changing that without resharing your own post. given that I wanted to push it on the blog, I took the chance to review some of the stuff I wrote, and expand it.

my initial impression of the GNOME 3 Application Development Guide for Beginners book is fairly positive: the topics covered are interesting, and the book never loses itself in them, so that beginners will not feel utterly stranded after the first three chapters, as it too often happens with “for beginners” books. I appreciated the “pop quiz” sections, as well as the small sections that recommended improvements to the example code.

obviously, writing a book enshrines a certain set of requirements and APIs, and that is problematic when there is high churn – like what happens in GNOME 3, especially in terms of development tools (libraries and applications) and overall experience. for instance, the section on Clutter (which is the one I can immediately give feedback on, given my position) still uses the deprecated “default stage”, and yet it uses the new ClutterActor easing state for animations; the default stage was deprecated at long last in Clutter 1.10, but its use was not recommended since the days of 1.0; the actor easing state API was introduced in the same release that deprecated the default stage. also, the example code published in the Clutter section does not use any of the layout managers provided by Clutter, preferring the fixed positioning of the actors, which is perfectly fine on its own; the book, though, then proceeds to mention the amount of code necessary to get something on the screen, compared to the equivalent code in GTK, that uses boxes and grids. in general, that’s an utterly fair thing to say: Clutter sits at a lower-level than GTK, and it doesn’t have complex constructs like GTK does; I’m pretty sure, though, there are better examples than a row of boxes that could have used a BoxLayout, or a FlowLayout, or a GridLayout, or a TableLayout; or better examples than using an explicit PangoFontDescription instance with a ClutterText to set a specific font name and size, instead of using the ClutterText:font-name property which wraps the whole thing for the developer’s convenience. in short: Clutter is more “raw” than GTK, but there are convenience APIs for developers.

it’s been a long time1 since I started off as a beginner in developing with (and) GNOME, so all I can say about book for beginners is whether they are using what I write in the way I think it’s supposed to be used; as far as I’m concerned, apart from a couple of issues, this book is indeed providing a solid base for people that want to begin developing for GNOME and with GNOME.

the price is pretty accessible, compared to the cost of similar books: I’ve paid much, much more for an introductory book on Core Animation, or on Perl books; the ebook version, if you dislike the dead tree version, comes in various formats, including PDF and Kindle.

I’m not going to give votes or anything: it’d be a pointless number on an equally pointless scale; but if you’re a beginner, I think this book may be fairly interesting to you, if you want to start coding with GNOME technologies.

  1. this year is actually my 10th bug-versary []
Posted in Uncategorized | Tagged , , , , , | Comments Off

Everything hits at once

conferences
sadly, this year I missed FOSDEM — and I saw from the blog posts on PGO that the DX hackfest was also amazing — but I had a good excuse, as I had to give a talk about Unicorns and Rainbows at linux.conf.au, in Canberra. I had the chance to explain what are the plans for the toolkit(s) used in GNOME in the coming future, as well as (obviously) enjoying one of the best free and open source software conferences, so all in all, I think that it was a good trade off. plus, I didn’t have to deal with the FOSDEM flu, apparently, so: good stuff all around. the video of the talk is already available on the LCA website1 so if you weren’t there, you can still watch it. I’d put the slides somewhere, but I’ll have to make sure that the notes are up to date first2.
life
after LCA, I took a week off in Sydney with Marta; the city was really enjoyable, and we had a great time exploring it. when I say “a week off” I don’t mean a week off of work, given that I’m currently not working: January 22nd was my last day at Mozilla. I detailed a why I left, and what my current plans are, on G+, so I won’t repeat them here — the executive summary is that I burned out pretty badly before leaving Intel, and I made the mistake of not taking a clean break before starting to work for Mozilla. right now, I’m trying to get back in a productive groove, so I’m looking around for cool stuff to do, as well as fulfilling my roles in the GNOME community as best as I can.
happenings
while in Sydney, I got a notification from my VPS hosting, the kind of notification that you really don’t want to receive when you’re on holiday and on a hotel wifi connection: apparently, my WordPress installation got hacked, and it started serving malware. cue various profanities that I clearly cannot repeat on a family-friendly website. I learned some valuable lessons from the first security breach I’ve ever experienced in years, but the main one is definitely the old adage from the Hitchhikers Guide to the Galaxy: don’t panic3.
beers
apropós of events, there’s a new GNOME London Beers meet up scheduled for celebrating the 3.8 release — or, at least, that’s the main excuse for meeting up, drinking beer, and having pizza with the GNOMErs in (and around) London. if you are in the area on March 1st, sign up on the wiki!
  1. and, seriously: how come the GUADEC videos are always, always late or not available even when we do record them? it makes us look really bad; GUADEC teams: fix this crap. it should be a hard requirement []
  2. I had my notes on the tablet, to avoid the focus back and forth when I had to advance them []
  3. the other, and equally important one is: never trust a pile of PHP brain damage []
Posted in Uncategorized | Comments Off

The Queen’s Rebuke

news of my death abandonment of the GNOME community have been greatly exagerated.

seriously: I’m still here at GUADEC (typing this from the common area); I’m still on the Board of the GNOME Foundation; and I’m still working on GNOME tech, like Clutter, GLib, and GTK+.

I am also working at Mozilla (and we’re hiring! :-)), but I also worked at OpenedHand and at Intel, and that never stopped me from actually doing stuff on the side; lots of people in this community do this — you don’t need to be full time employed with a company to contribute to GNOME, or to try and give the projects goals and direction.

on Sunday, I tweeted this:

[tweet https://twitter.com/ebassi/status/229551373044305920]

if it doesn’t show up, here’s what I wrote: we were always a bunch of friends working on stuff we loved in the face of unsurmountable odds. here’s to 15 more years.

it’s very true that we lack resources. we always did. it’s also true that we are competing in a space that does not leave us much room. we didn’t get 20% of the desktop market either, though. we’re doing what we do not because of the market share, or because of the mind share, or because we want to be paid. we write GNOME, we document GNOME, we design GNOME, we translate GNOME because we love GNOME. you would need to pay us not to work on GNOME.

everyone here at GUADEC is aware that hard times are upon us; we (presumably, though we don’t have any real metric to define that) have lost users. we definitely have lost sponsors. it’s not the first time, and I suspect it won’t be the last. what we haven’t lost are our passion for what we do; our mission, to provide a free environment for users to work with; and our willingness to drain all the swamps we have in the Free Software world.

if you want to work with us, join the GNOME Foundation — both as a member or on the advisory board if you are interested in sponsoring the project. help out in one of the many teams, not just with code, but with design, documentation, translation, marketing, web development, and mentoring.

we have so much work to do ahead of us to not only stay relevant, but to fullfill our mission, and blaze the trail to the future of Free and Open Source Software — we’ve got to get to it.

Posted in Uncategorized | Tagged , | 2 Comments

The Legionaire’s Lament

I have an idea of where the app developers are.

they are in an ecosystem that put up with a language that calling niche 10 years ago was flattering.

or they are in an ecosystem that is so fragmented that you can forget complaining about three or four major distros, when you have to deal with five different major versions on dozens of devices and form factors, all with minimal or no upgrade paths.

more importantly, though, I think that the app developers are where stuff looks cool and where the community leaders don’t eat their children in constant whining on public venues.

Posted in Uncategorized | Tagged , , , | Comments Off

Rox in the Box

public service announcement — I just revoked my trusty GPG key, which I also used to sign Clutter releases:

pub   1024D/A4320FF4 2000-09-18
      Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4
uid                  Emmanuele Bassi 

the size of the key was ultimately too small to be trusted indefinitely. it’s been superceded by the following key:

pub   4096R/EA11BBB7 2012-06-22
      Key fingerprint = 53EF 3DC3 B63E 2899 271B  D263 22E8 091E EA11 BBB7
uid                  Emmanuele Bassi (GNOME) 
uid                  Emmanuele Bassi 

which will (hopefully) last at least as long as the old one, and possibly more.

Posted in Uncategorized | Tagged , , | Comments Off