Older blog entries for zw (starting at number 5)

Bugs, bugs, and more bugs. All of the "this can't ever have worked" variety. Of course they only showed up after I committed the changes, so they inconvenienced everyone instead of just me. Bleah.

Had to stop work abruptly when the power-supply fan began emitting hideous grinding noises. I have the worst luck with fans... As it was 7PM on a Saturday, I had no option but to attempt to repair the thing myself. Fortunately, if you don't mind ignoring the stickers on the outside of the PSU:

it is quite straightforward to extract the fan from the power supply, dismantle it, and clean out the grit which causes the hideous grinding noise. The worst part of the whole exercise was figuring out how to test it. ATX power supplies don't turn on when you flip the switch, you have to plug them back into the motherboard and push the software on button. (Presumably it's possible to put a jumper across some pins in the big fat connector, instead, but they don't label them.) Don't plug the hard drives back in, or it will try to boot.

I'm paranoid, so I pulled everything off the motherboard before testing: CPU, memory, ribbon cables, video card, etc. But I didn't unplug the speaker. The chipset noticed it didn't have a CPU and started beeping angrily. Scared the cat out of the room.

How does grit get in the fan bearings, you ask? Being as how my computer sits on the floor, which is covered with gritty dust, which the fan sucks into the computer, I'm surprised it didn't happen earlier. I wonder if you can get air filters for a computer case.

Still taking a break from work. Yesterday I drove down to Sunnyvale for a lunch meeting, then back up to help my grandparents move. This mainly consisted of hauling boxes full of trash downstairs and out to the Dumpster.

Commute advice: to get from Berkeley to Sunnyvale by car, take the 13 to the 580 to the 680 to the 237. Do not take the 980 and 880. The 880 has Huge Trucks driving at 70mph on it, and it's packed bumper to bumper except in this tiny window from 10AM to 2PM. The 580 and 680 don't clog up until after 5. Also, the drive is much nicer; you go behind the hills and up through this less-developed region.

I'm still looking for a way to avoid the 237, which also clogs up around 3 PM going east.

Today, committed some patches that have been mouldering for a while, and chased a bootstrap failure which was caused by an experimental patch of mine. I should stay the heck out of the back end.

Heard a performance of Mozart's Requiem Mass at Cal in the evening. This is about an hour of continuous music which grabs you and doesn't let go. Truly awe inspiring. I can still hear the chorals to 'Dies Irae, dies illa' echoing in the back of my head.

Took the day off. Rode around on my bicycle postering for the Douglas Hofstadter talk. He is speaking at UC Berkeley on the 21st of April, from 6 to 8 PM, in 2050 VLSB (Valley Life Sciences Building). If you're in the Bay Area, you should come. More info at the UC Cognitive Science Students' Association, which is sponsoring the talk.

My replacement burner arrived. I can cook dinner again without worrying about blowing myself up.

Update to previous entry: making the directive scanner consume newlines breaks absolutely everything. Have implemented a disgusting kluge (decrement line counter before calling the printer) instead. This works.

The ancient stove in this house has decided that its right front burner will not light unless a match is applied. If you just turn it on, it floods the area with gas which then explodes, setting fire to the house. Well, I assume that's what would happen, so far I have managed to catch it in time.

A few hours' driving around in Oakland found me an appliance store with a Wise Old Mechanic who managed to locate and order me a replacement burner for only $50. I was tempted to buy a whole new stove, but I doubt the landlord would appreciate it.

Today I reworked the generation of linemarkers. The output of CPP has lines in it that look like

# 12 "foobar.h"

that tell the compiler where each chunk of the preprocessed file came from. If you don't intend to generate a preprocessed file, these are useless - you can grab the info straight from CPP's data structures. But they are generated deep down in the guts of the preprocessor and you can't get rid of them...

...well, now you can. The "reader" library interface doesn't generate them anymore, and there's a new "printer" interface that sticks them in right before output.

Structurally, this is a good deal cleaner than what we had. It works great too, except that it gets all the line numbers wrong. This is not really the fault of the "printer", but a bad interaction with a whole different area of the code.

There's a special internal routine to scan directive lines. Among other things, it refuses to scan past the end of a line - except what it really does is refuse to consume the end of a line. The "printer" has to emit a linemarker at the beginning of each #included file. It will not get a chance to do so unless it's invoked before the #include processor returns. But at that point, the newline ending the #include line has not been consumed. Therefore that newline will be counted twice.

It's even worse than that - the only place the "printer" can get control can't distinguish between #include and anything else, which means every single directive line will be counted twice for line-numbering purposes.

The fix is to make the directive scanner consume newlines. That will be tricky. The various directive handlers count on being able to read that newline multiple times and not get messed up; works fine when it's never consumed, but if we want it to be consumed exactly once... harder.

So today I'm working on token lists. CPP has always been strictly textual, but C the language is based on tokens. Now CPP is going to have the same concept.

The basic idea is that we scan one line at a time and convert it to tokens. These are as close as possible to the C front end's concept of tokens. We try to make this have no context sensitivity, and we can do it except for directive lines. Then macro expansion and directive processing happens on the pretokenized line, which produces another line. Then we convert that back to text and feed it to the compiler. (Longer term, the converting back to text won't happen either, but one step at a time.)

But for today, all I implemented was the basic data structure and helper functions. The next step will be to wrap the existing lexer in this - that will hopefully happen by Wednesday. Then I will begin bashing on the macro expander.