If you like a tool, never look at its headers.

Following hot on the heels of this astonishing header from Boost, here are some excerpts from the module defining tuples in the Glasgow Haskell Compiler 7.4.1:

data (,) a b = (,) a b
    deriving Generic
data (,,) a b c = (,,) a b c
    deriving Generic

(If you can’t read Haskell: (,) a b is another notation for (a, b). This defines types for two- and three-element tuples, with a default implementation of the Generic interface.) Okay so far? The file proceeds to define 4-tuples, 5-tuples, and so on until we get to the 8-tuple definition:

data (,,,,,,,) a b c d e f g h = (,,,,,,,) a b c d e f g h
    -- deriving Generic

Surprise commented-out deriving clause! But it’s all plain sailing from here… until we get to 63-tuples:

data (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p q r s t u v w x y z a_ b_ c_ d_ e_ f_ g_ h_ i_ j_ k_ l_ m_ n_ o_ p_ q_ r_ s_ t_ u_ v_ w_ x_ y_ z_ a__ b__ c__ d__ e__ f__ g__ h__ i__ j__
 = (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p q r s t u v w x y z a_ b_ c_ d_ e_ f_ g_ h_ i_ j_ k_ l_ m_ n_ o_ p_ q_ r_ s_ t_ u_ v_ w_ x_ y_ z_ a__ b__ c__ d__ e__ f__ g__ h__ i__ j__
    -- deriving Generic
{- Manuel says: Including one more declaration gives a segmentation fault.
data (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p q r s t u v w x y z a_ b_ c_ d_ e_ f_ g_ h_ i_ j_ k_ l_ m_ n_ o_ p_ q_ r_ s_ t_ u_ v_ w_ x_ y_ z_ a__ b__ c__ d__ e__ f__ g__ h__ i__ j__ k__
 = (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p q r s t u v w x y z a_ b_ c_ d_ e_ f_ g_ h_ i_ j_ k_ l_ m_ n_ o_ p_ q_ r_ s_ t_ u_ v_ w_ x_ y_ z_ a__ b__ c__ d__ e__ f__ g__ h__ i__ j__ k__

…followed by commented-out definitions of everything up to 100-tuples.

Spreadsheet party

I spent most of last week holed up in a meeting room at Collabora Towers with Michael Meeks (of SUSE) and Eike Rathke (of Red Hat), working on a prototype of collaborative spreadsheet editing in LibreOffice Calc, using Telepathy tubes to start editing sessions with your IM contacts. Michael’s got a much more extensive and eloquoent post about where we got to, and here’s a quick screencast of the prototype in action!

Looking around Wayland

My new adventure at Collabora involves Wayland, like all the cool kids. I was distraught to learn that, since Wayland only provides clients with pointer position information to the surface currently under the pointer, and only relative to that surface, xeyes no longer works. We’ll see about that…

A bunch of eyes following the mouse in Weston

Watch a phone-cam video of the eyes in action ((with unintentional soundtrack by Marco, Jo and Daniel)) in your choice of WebM or freedom-hating H.264! (I apologise for the shakes, but it yielded smoother results than the GNOME Shell screencast thing.)

The pointer’s position is provided to clients which request it, relative to a surface of their choosing. Thanks to the way surface transformations work in Weston, the eyes still work when rotated without any further effort:

A bunch of ROTATED eyes following the mouse in Weston

Ready for the desktop!

Joking aside, I don’t really expect my branch to be merged any time soon, not least because it’s very much a proof-of-concept and is pretty easy to break. But it was a useful exercise in learning my way around the Wayland and Weston code-bases. The work involved was actually pretty small in the end:

  • Implement a pair of eyes which only work when the cursor is over them;
  • Define a protocol extension allowing clients to ask to track the pointer position relative to a surface;
  • Plumb it into the compositor and client.

Now onto something a little more useful…