Right now I’m at the GCC Steering Committee Q&A panel at the summit. There’s a new draft out of the GCC runtime license (used by libgcc, libgcj, etc). The latest text allows for the development of GCC plugins — folks are already talking about review of the patch and how soon it can be merged (answer: after the license is finalized).
This is great stuff!
You can see this year’s unofficial GCC t-shirt here. As it turns out, it fit in nicely with Ian’s second (surprise) talk about using C++ in GCC.
A couple weeks ago I upgraded my laptop to Fedora 9. This went mostly smoothly.
I used the new preupgrade tool. This downloads data needed for the upgrade while your system remains functional. Then, after the download is complete, you can reboot into anaconda for an upgrade. I gather the benefit of this is that upgrade-via-anaconda is actually supported, unlike yum upgrade. Also, it means you don’t have to burn a CD — nice.
There was some minor glitch during this process — but minor enough that I forgot what it was when the time came to report it. Whoops.
After upgrading, some programs would not start. For instance, gnome-terminal did, but Emacs didn’t. After a while I found bug #430416 — a bug causing an X server error when certain fonts are requested. Removing xfs is the quick workaround. This problem was a pain.
Next, I found that the cursor in gnome-terminal was blinking again. Argh! I dislike blinking cursors. I find them very distracting.
I had a surprisingly hard time figuring out how to disable this. It used to be available on the gnome-terminal options page, but this was removed. For some reason I did not think to look on the Gnome-wide “keyboard” properties page — what does this have to do with the keyboard? So, in the end, I resorted to searching and ran some obscure gconftool-2 command line. Yay. In the meantime I found this nice page on disabling cursor blinks.
I am disappointed with the Gnome upgrade experience. Almost every time I have upgraded my OS, I’ve had to spend a bit of time fixing my desktop to reassert customizations I’ve already made. This is no good! My changes matter a lot to me!
In this particular case, gnome-terminal could have noticed my earlier setting and offered to upgrade it. Or, Gnome could adopt a friendlier policy — simply accept that some mistakes were made in the past, and choose to value my experience over consistency. After all, we’re talking about the terminal here, a tool unlikely to be used by the inexperienced audience that is the apparent target of this sort of change.
I have become generally skeptical of arguments based on consistency of UI. People seem to have little trouble navigating the web, where no two sites are the same. Also, every desktop release seems to come with a new default theme and plenty of experience-breaking changes — that is, there is no consistency over time.
I love patches like this one. This is a change to libstdc++ to reflect changes made at the lastest standard committee meeting. I think the meeting ended yesterday… a little slow, perhaps; I think last time I saw commits immediately after a vote concluded.
Next week is the GCC Summit, in Ottawa. I’ll be giving a talk there about my work on the incremental compiler. That will be fun, but what I’m really looking forward to is seeing all the other GCC hackers I know. There are plenty of interesting talks on the schedule, and some cool BOFs; plus there is an informal gdb meetup (this should be especially interesting, as there are many cool developments in gdb-land).
In keeping with my Emacs mania, this year I wrote a special presentation mode. My presentation is just a text file, in Emacs “outline mode” format; my new mode displays it nicely in a screen-filling frame. I should say, “nicely”, since some kinds of rendering are a pain to do in Emacs, and I couldn’t be bothered.
Someday we’ll write a Buddhist AI who will know that its self-awareness is an illusion.
Usually a movie with just one joke gets old halfway through. Not so with Lars — this was a sweet, quiet, funny movie that I enjoyed thoroughly. I recommend it.
Thanks to Elyn, my t-shirt design from last year’s GCC Summit is now available.
I made a new GCC t-shirt yesterday, but you’ll have to wait for the summit to see it.
I was reading about PEG recently, and thinking “that is pretty interesting” — and of course it turns out that there is an Emacs implementation.
It is a bit odd how primitive parsing support is in Emacs. It is one of those mysteries, like how window configuration and manipulation support can be so weak. Peculiar.
CEDET includes a parser generator, called wisent. That is long overdue… though even it is a bit odd, apparently preferring a yacc-ish input syntax. I don’t know about you, but when I have a lisp system just sitting there, I reflexively reach for sexp-based formats. Well, ok, it is a port of bison. But still.
I did a little parser hacking in gdb recently. In gdb, if you complete an expression involving a field lookup, it will currently print every matching symbol in your program — when all you really wanted was the completion of a field name. This is what I set out to fix.
My first idea was: hey, the parser knows what tokens are valid. I can just ask it! But, I don’t think there’s a way to do that with bison parsers. At least, no documented way — boo. And anyway, as it turns out, this is not what you want.
For instance, consider the simple case of “p pointer->field“. This is syntactically valid as-is, so the parser would indicate that the desired completions are whatever can come next — say, an operator. But if the cursor is just after the “d”, you want to continue completing on the field name. So, you have to differentiate this case based on whitespace.
I ended up hacking the lexer as well as the parser. The lexer can now return a special COMPLETE token, which it does depending on the previous tokens and the presence or absence of whitespace. I also added some new productions like:
expression: expression '.' name COMPLETE expression: expression '.' COMPLETE
From here it is pretty simple to solve the rest of the problem.
I don’t remember reading about this anywhere, but I’m sure it has been done before. I thought it was a pretty fun hack 
- I love problems that start with the user experience and end up someplace much deeper.
Thursday night I finally made it to a BLUG meeting. Stormy Peters from OpenLogic gave a talk titled “Would you do it again for free?”
Her talk covered some familiar ground — intrinsic versus extrinsic motivation, a list of motivations that free software developers claim (or that are claimed by others), the various methods of payment. Her slides were beautiful; she seemed a bit nervous though not overly so.
She also talked a bit about inequality in projects. She claimed that 40% of developers on free software projects are paid to do so; a show-of-hands at the meeting showed similar results.
OpenLogic is running the Open Source Census — kind of a cross-platform popcon. If you read her blog a bit you’ll see that she uses this information when talking to VCs and the like. That’s a smart idea and I’m generally in favor of hard data over speculation anyhow.
She was using an Asus, kinda cool. And Neil, sitting next to me, was using an XO. Weird times we live in.
Motivation, of course, is a psychological phenomenon, one with which we all have direct experience. That is, everybody has an opinion… so one commenter from the audience rejected most of her list of motivations in favor of — you guessed it — his. I suppose this is the bikeshed effect in a different form.
I didn’t agree with everything in Stormy’s talk. At one point she gave a sort of economic history of mankind which, I think, was badly mistaken on the facts, though perhaps not our experience of them.
After the talk I asked her about the pretty photos and consistent palette in her presentation. She said they were CC-licensed works from flickr and from some stock photo site… nice. (Also I noticed her slowly backing away while we talked. Whoa! Like, I’ve always been afraid of being that person. And now … hard data. Crap.)
She also talked a bit about the relationship developers have with open source. One idea was that a hacker might leave a project (suppose the project dies) — but will just switch projects and keep working. Also, supposedly nowadays open source developers make more money than proprietary developers; but, conversely, often claim that they would take a pay cut to work on open source (the intrinsic motivation thing). Let’s hope our bosses stop midway through that sentence.
I’m fascinated by the social dimension of programming. Partly this is defensive; over the years I’ve developed some heuristics that I use to evaluate developers (sorry. But it is true. And of course I like you.) and projects, mostly to try to keep away from painful experiences. But, I’m also interested in a more general taxonomy of projects — my suspicion is that many of the things we think we know about running projects either aren’t so, or are “don’t care” boxes in the Karnaugh map of administration. What is cool is that the free software movement is so big, now, that we have an excellent laboratory in which to study.