Older blog entries for tromey (starting at number 27)


Still trying to get Eclipse to work with gcj and/or gij. This is a slow process. libgcj has some bugs, and some missing features, and unfortunately Eclipse seems to touch them all. I do think I've finally run into a bug in Eclipse and not libgcj, though it is still too soon to tell.

Eclipse is still a weird parallel universe. They do everything backwards and then explain why. For instance, builds don't stop when they hit an error. They just keep going, and the build exits with status 0. This is explained as "we have too many plugins to stop if one gets an error". Ok. So, you write a script to work around the problem...

Build Stuff

Alexandre is releasing the new automake today. I haven't worked on my new build tool in more than a week now. Bummer. I'll start again once Ben gets the subversion server set up.

Last week I did start the C tool factory. I also wrote a couple new variable types. So now the CC variable is used to find the C compiler, and then the tool factory instantiates the correct tool (currently only gcc exists). So, the prototype has already eliminated the need for depcomp.


My second class started last week. It turns out that the first class didn't cover enough material. So now I'm behind.

Build Tool

Not much work this week. However, I have done some thinking about the front end. My current plan is to build things so that all work -- not simply the work of running the build instructions, but also the work of elaborating the tree -- will be done in parallel. This requirement is a consequence of allowing one step of the build fill in new dependencies for a subsequent step. I've also thought a bit about requirements for the lexical structure of the input files.


What's Up Doc?. Watched this again, probably the 5th or 6th time. I love this movie. It is a nice homage to the early screwball comedies, and is hilarious besides. Some people I know won't watch it since it starts Barbra Streisand; fortunately I'm not victim to that particular ideological narrowness.

Il Mostro. Another Benigni comedy. This one wasn't as funny as Johnny Stecchino.

Eclipse and gcj

As often happens, someone sent in a patch for one of the gcj bugs I was planning to fix. That's some odious debugging I don't have to do :-).

SWT, as it turns out, is not 64-bit clean. And changing it to be so looks to be a fair amount of work (which, eventually, I'll probably have to do). I find this irritating; it isn't hard to write 64-bit clean code from the start.


Blood Work. This movie was entertaining enough, but not one of Eastwood's better efforts. I did enjoy the fact that he owned up to his age and played an aging cop in poor health -- a nice touch of reality rarely seen in Hollywood films (yesterday I saw in The Onion: "Woody Allen's Third Wife Born").

In one scene, Eastwood is interviewing a computer programmer in his cubicle. On the shelf behind the programmer is a copy of RHL 6.1. That's nice, but even nicer is that there is also a copy of the autobook. It is blurry, but I like to think that's what it is.

American Astronaut . I went to see this again last night. This time Cory McAbee was in town to promote it. He also gave a concert (I didn't attend). He's an interesting and charismatic guy. Anyway, I learned some things about the movie, and I always like hearing from the directors and learning about their processes.


There's Something About Mary. Saw this (again) at the outdoor theater this week. It was funny, though not as funny as the first time I saw it.


More work on making Eclipse build. I fixed a few random bugs and made stack traces print interpreted frames nicely. There's nothing like compiling a large application to shake out the bugs. Next we have to fix class loading. At last.

Last night I looked at AWT again, a little. I didn't have time to make any progress; I was just reorienting myself.

Build Tool

I've started on the logging interface and I've done some more internal cleanups. I've also started thinking about the front end design (not syntax, but available functionality).

Eventually I'm going to want someone to read through the design and the ideas and help me see if something obvious is missing. I frequently prefer working in a collaborative mode, where I have someone to help with decisions and tradeoffs.


Tadpole. I loved this movie and laughed out loud quite a bit. (I'm a sucker for movies shot on DV.)

Build Tool

Last night I looked into making the build tool impervious to comment and indentation changes in C source. This turns out to be quite easy conceptually: you simply base the file's signature on a tokenized form of the source file. This is feasible if your tokenizer is relatively fast. I'm putting off writing this code, since it isn't entirely trivial and there are more important things that must be done first. I imagine it would be most useful to enable this by default for .h files in the project, and use a (presumably) more efficient text-based scanner for other sources.

I've also figured out how to make "config.h" files work well. The idea here is to change cpp to output more dependency information. Then config.h can compute its signature based on the defines actually inspected by a given compilation. This means that, say, adding a test to config.h will only cause a rebuild of those files which actually use the new define. Something like this would be nice for large projects.

Both these ideas are easy to implement in the current framework.

I've been re-reading the Odin paper again. I always forget how different this approach really is. Odin doesn't put intermediate files like a .o into the build tree. They exist only in the cache. I doubt I'll be going that route. For one thing, I've found that I occasionally look at the .o files to debug some problem or another. Also it feels "too different".

Tonight I'm just working on general cleanup.

Build Tool

A couple nights ago I added derived object caching (about 20 lines of Python code) and command file dependency tracking (if /usr/bin/gcc changes, your program is recompiled). Last night I changed the gcc tool to know how to do automatic dependency tracking.

Derived object caches are a bit funny to work with. For instance, rm *.o doesn't cause a rebuild. It just pulls things in from the cache. This "feels weird", perhaps due to my long history with make. Signatures also are a bit odd. For instance, the build tool is impervious to touch. Another example is if I add whitespace to a C source file, the resulting executable isn't relinked (since the object file doesn't change). (This stuff all works right now with my prototype.)


Recently I've been trying to build Eclipse with gcj. This is an adventure, since Eclipse has 75 jar files (for now I'm compiling from bytecode) and uses all kinds of packages, including things it shouldn't like com.sun.tools (hiss). I've also tried getting Eclipse to run with gij; this has shown me that working out the library issues is only the start of my problems.


Austin Powers 3. Better than I thought it would be. I found the opening sequence particularly interesting, and inventive. Parts lagged, though, and by the end I was ready to leave.

Build Tool

raph brings up some interesting points regarding language choices in a new build tool. There are a few points here that I'd like to address.

First, in automake we always separated the implementation language of the tool from the language the user used to make things happen. There have been many requests over the years to blur this barrier, but I never regretted being firm here. Blurring this line basically means you must be very confident in your particular implementation, since giving access to it means it will be much, much harder to change.

My earlier questions were really ones about the implementation language of the tool. Is it ok to have a dependency on some other, larger project (Python or Perl or ...)? Of course that isn't a question with a fixed answer. It depends on what you want to accomplish. One of my goals is wholesale replacement of the auto* tools. This makes the question particularly hard.

The user's language is of course extremely important. We've all seen how autoconf's quoting and mix of m4 and sh is confusing and limited. We've all seen make's many syntax problems.

The tension comes because in some situations the user language has to have some power, and it is tempting to just use the same language for both. For instance, expressing autoconf-style configuration requires expressive power.

This is all "front end" stuff. I still haven't really started the front end design beyond kicking a few ideas around.

raph, I'd be interested in seeing rebar. How about sending me a tar file?

Today I finally put Advo on my personal toolbar in Mozilla. I find I really enjoy reading the Advo diary entries, and I look forward to them. I think it is because some people put real thought into their entries, so they can be good reading. Also it is interesting to see what other people are working on or thinking about.

Today I did something I ordinarily dislike, which was rewiring so that I could boot the alpha box I have here. Honestly I think Red Hat forgot they ever sent it to me. It's nice for testing gcc; today I'm using it to test a gcj patch for a bug that occurs only on 64-bit architectures. What I really need to do is move that box plus the other old one to the basement and run wiring down there. Then the noise won't bug me so much. Given my general level of hardware procrastination, I think it is safe to say that will never happen.

Build Tool Rambling

Last night I did some hacking on a build tool prototype. Basically I'm trying to test some of my plans against reality; earlier hacking in this vein led me to revise how the database is laid out. Sometimes I find it easier to follow logic in the code, while I'm writing it, than I do if I try to plan everything about ahead of time. In situations like this I just consider the prototype code as part of the design process.

Anyway, the prototype tool is smart enough to avoid re-running a rule when the output won't be different. And since it is using signatures and not timestamps it is impervious to touch.

It is awfully daunting to have 500 LOC in a project and know you need 10,000 LOC.

There's a fire in Steamboat today and here in Boulder the sky has been yellow and the air smells of smoke. Ugh. It's almost enough to make me look forward to winter.

Today was pretty slow. I need to make some kind of change here.


Saw XXX today. This movie somehow managed to fall below my already low expectations. Amazing.

I'm finally back from my vacation. It was wonderfully relaxing and made me want to hack again. Nice.

Build Tool Vapors

I've done a lot more thinking about a replacement build tool. True to form, I thought about it a lot on vacation. I've written some design docs for the back end, and started thinking about the front and "middle" ends, but so far nothing suitable for public viewing.

One implementation issue I struggle with is what language to use. I wonder whether people will be willing to give up the portability of the current auto* tools in order to have a somewhat cleaner build environment. My current preference would be to write a new tool in one of the common scripting languages, probably Python (I don't know it, therefore I can't dislike it :-). Luckily implementation is a long way off, potentially infinitely long.


My Big Fat Greek Wedding. I finally saw this because several friends reported back enthusiastically. I thought it was quite boring. Also it espoused a very stereotypical view of Greek-Americans, on the borderline of offensively so. I guess I didn't see the humor in it that other people did.

A few weeks ago, before vacation, I saw The Sting at the outdoor theatre. Even though I had seen it just a couple months before, I enjoyed it again. Some movies I can see over and over.

18 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!