Posted on by Emmanuele Bassi

Remember to breathe

summit: my second GNOME Summit was a great experience. being a small, hack-oriented conference makes it possible to have a lot of work done — or discussed; I must thank everyone that helped organize it: it was great. I also have to thank Paul for letting me attend it even with a looming deadline at work. :-)

the Clutter 1.2 requests session was pretty good: I got nice feedback from the current users of Clutter in the GNOME platform, both for the planned features and for what is needed. I also was able to talk about GTK+ 3.0 planning outside of the IRC meetings — which started again, so make sure to watch the Wiki page and attend every other Tuesday.

clutter: most of the Clutter discussion has already been summed up by Jason. I’m going to start releasing snapshots of the 1.1 development cycle by the end of this week, to let people test drive the new APIs; feedback is much appreciated.

autotools: I had to catch a red-eye flight to go back from Boston, and I had only 22% of battery left on my laptop, so I decided to go easy on the plane hacking side of things; I just got around to split out the GLib marshallers and enumeration GType generation rules that everyone is copying between projects; those rules now live in two files that you can copy and include at your heart’s content. they work like this:

# glib-genmarshal rules
glib_marshal_list = $(srcdir)/clutter-marshal.list
glib_marshal_prefix = clutter_marshal
include $(top_srcdir)/build/autotools/Makefile.am.marshal

# glib-mkenums rules
glib_enum_h = clutter-enum-types.h
glib_enum_c = clutter-enum-types.c
glib_enum_headers = $(source_h)
include $(top_srcdir)/build/autotools/Makefile.am.enums

and they will also handle the clean and dist rules for you. it would be good to have something like this in gnome-common as well.

json-glib: a couple of weeks ago I released version 0.8; it contains a “fix” for the fact that integers in JSON are defined (or, well, undefined) as machine integers; this allowed braindamaged web services to overflow 32 bits and expect that stuff would not break. nice one. unfortunately, C is a little bit more concerned — and I’d never thought I’d say this — about types and their sizes, so suddenly stuff would start to break; I automatically promoted every integer to 64 bits internally, so this should give us a little bit of wiggle room, at least for the time being. but seriously: incremental integers for unique id without a known length limit? not good design.

5 Replies to “Remember to breathe”

  1. incremental integers for unique id without a known length limit? not good design.

    Why so? How long would your program have to run, uninterrupted, to overflow 64 bits? Theoretically it might matter — but even the longest-running programs aren’t going to run anywhere near long enough to encounter those limits.

    (This isn’t merely an idle question; I have one project that relies on unique-id integers for correctness, although as the project’s JS it’s really IEEE doubles which don’t lose precision until 2**52 or thereabouts. I figured it would take a few thousand years or so to overflow, so I didn’t bother worrying further.)

  2. @Jeff: if you have a site with 10 millions of users who bang out at least 10 status messages per day you’ll overflow a signed 32 bits integer in 429 days. 10 status messages per user is a ridiculous number, if we start factoring in the celebs and the spammers. no wonder Twitter already went through a twitpocalypse and has spilled over to 64 bits. but, all in all, if you just want to assume a monotonic number you should be using a string to hold it, not use a native type that has no defined size and defaults to machine size. because we don’t have 128 bit architectures widely deployed on the entire planet (yet).

  3. I wasn’t suggesting insufficiency at 32 bits; there are all sorts of natural quantities computers might measure which overflow 32 bits (wealth of several hundred people in the world in dollars, for example). If you change 32 to 64 in your example, tho, suddenly 43 days (I think you misplaced a decimal point) changes into five hundred million years. At that scale, who cares about the vanishingly rare twitpocalypse?

  4. Hey,

    Used your Makefile.am.enum and ended up making a couple changes to make distcheck happy.

    === modified file ‘Makefile.am.enum’
    — Makefile.am.enum 2009-10-16 17:59:39 +0000
    +++ Makefile.am.enum 2009-10-16 19:50:10 +0000
    @@ -24,10 +24,11 @@
    EXTRA_DIST += $(enum_tmpl_h) $(enum_tmpl_c)

    stamp-enum-types: $(glib_enum_headers)
    + $(QUIET_GEN)mkdir -p `dirname $(builddir)/$(glib_enum_h)`
    $(QUIET_GEN)$(GLIB_MKENUMS) \
    – –template $(enum_tmpl_h) \
    + –template $(srcdir)/$(enum_tmpl_h) \
    $(glib_enum_headers) > xgen-eh \
    – && (cmp -s xgen-eh $(glib_enum_h) || cp -f xgen-eh $(glib_enum_h)) \
    + && (cmp -s xgen-eh $(builddir)/$(glib_enum_h) || cp -f xgen-eh $(builddir)/$(glib_enum_h)) \
    && rm -f xgen-eh \
    && echo timestamp > $(@F)

    @@ -35,9 +36,10 @@
    @true

    $(glib_enum_c): $(glib_enum_h)
    + $(QUIET_GEN)mkdir -p `dirname $(builddir)/$(glib_enum_c)`
    $(QUIET_GEN)$(GLIB_MKENUMS) \
    – –template $(enum_tmpl_c) \
    + –template $(srcdir)/$(enum_tmpl_c) \
    $(glib_enum_headers) > xgen-ec \
    – && cp -f xgen-ec $(glib_enum_c) \
    + && cp -f xgen-ec $(builddir)/$(glib_enum_c) \
    && rm -f xgen-ec

Comments are closed.