Older blog entries for tromey (starting at number 29)

Build Tool

Discussion on the build tool is proceeding nicely. Ben's class is ending, so hopefully soon he'll have more time to work on it; it will be nice once the subversion server is set up and people can play with the prototype. Currently we're mostly talking about front end issues, but also some use cases. Also, Ben's going to give a talk on our plans in Australia (I don't know exactly where).

Movies

Super Troopers. I rented this on advice from a person at Video Station. Video Station, btw, is an awesome local video store here in Boulder. The employees are very knowledgeable. I talked to someone who applied for a job there; they give you a movie quiz that most people fail. Anyway, this movie struck my funny bone in a way few movies do. I had to pause the tape since I was laughing too hard. It literally hurt, and tears were coming out of my eyes. Still, I suspect the movie isn't really as funny as I thought; sometimes you happen to see a movie when you're in exactly the mood required to fully appreciate it. Nevertheless, I enjoyed it, especially the character played by the director (who I thought was a fine actor).

Secretary. This is an odd movie; I'm not quite sure what to write about it. I found the ending a bit unsatisfying, since it seemed to be a very mundane, happily-ever-after ending for what had been up until then an anything-but-usual relationship. It absurdly reinforces the dominant cultural values, against its own apparent logic. It is worth seeing, though I probably won't ever see it again. (Watching a movie twice is a real test for it.)

Movies

The Transporter. This movie has laughably bad dialog. I literally laughed out loud, probably to the irritation of the mostly adolescent audience. Parts of it were creative, though shot in an over-the-top style reminiscent of The Brotherhood of the Wolf. I enjoyed it the appropriate amount.

Build Tool

Not much work lately. Still thinking, doing some reading, running through various scenarios in my head. Currently I'm composing a message with a strawman for one approach (the "new language") to a front end. Later I may write up another approach (the "reuse" approach). This phase has taken on a sort of circular, conclusion-free flavor that I am not enjoying.

After playing more with ant, I've decided I definitely don't like it. Perhaps I'm missing something, but to me ant seems in many ways less useful and capable than make.

Eclipse

For now I've stopped trying to get Eclipse to work with gcj, and am instead looking at fixing bugs important to a Linux audience. For instance, the Ecilpse cvs plugin doesn't preserve the executable bit on checkout.

Eclipse

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.

Italiano

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.

Movies

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.

Movies

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.

Movies

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.

gcj

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.

Movies

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.)

gcj

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.

Movies

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.

20 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!