Older blog entries for zw (starting at number 9)

Several people have pointed me at Netscape's app-defaults file, which lists a bazillion things you can usefully tweak. I now have no splash screen, no blinking text, and no useless toolbar buttons. Unfortunately, there doesn't seem to be anything related to the Energizer-bunny bookmarks headers.

Here's how it's done: add this to .X(resources|defaults) and restart X:

Netscape*toolBar.search.isEnabled: false
Netscape*toolBar.destinations.isEnabled: false
Netscape*toolBar.print.isEnabled: false
Netscape*toolBar.myshopping.isEnabled: false
Netscape*toolBar.viewSecurity.isEnabled: false
Netscape*noAboutSplash: true
Netscape*blinkingEnabled: false

I just love the way the toolbar resource names have nothing to do with their visible labels.

"But the Security button is useful!" I hear you scream. Yeah, but you can get the same thing by clicking on the little lock icon in the left corner of the status bar. I want to keep the status bar, it's actually useful...

There are some other interesting resources in there, like *dontForceWindowStacking which may disable javascript's ability to create popup windows that can't be got rid of. (Too bad it doesn't disable javascript's ability to create popups, period.) I have javascript turned off anyway, so it's irrelevant.

The file to dig through is Netscape.ad, which will probably be in /usr/lib/netscape or wherever the installation directory wound up. It has amusing bitter comments by JWZ.

Arrgh. Fscking Netscrape.

I have it set to start by displaying my bookmarks list. There is no way to get rid of either the Personal Toolbar Folder (although you can delete all its entries, thankfully) or the top header; nor can you change the text of the header. Thus both of these things are wasting my VALUABLE VERTICAL SCREEN REAL ESTATE which should be PRODUCTIVELY occupied displaying BOOKMARKS.

I have the same bitch about the menubar, toolbar, location bar, status bar, and title bar (ok, that last is the window manager's fault). An entire inch of my screen is lost to this crap. Mozilla seems to have fixed this, mostly... maybe I should look into that again.

What I want is a version of fvwm2 that can steal the menu bar and shove it up into the title bar. Do this without making me list explicitly every application that gets the special treatment. And it should work on Emacs. GNOMEheads, are you listening?

P.S.: Does anyone know how to get rid of the damn splash screen and go straight to the start page?

Random late-night thought: It should be possible to attach comments to other people's diary entries, in the same way you can reply to an article. The comments should show up on a separate page, in case you didn't want to read them.

Addendum: some threading, for replies to articles and diaries both, would be nice.

Very little code-related activity in the past few days. I hung out with friends, helped my grandparents move, etc. Now I have to play catch-up.

Today, I merged all my recent changes into Cygnus' internal tree, which should make the big merge next week a bit easier. Then I wasted two hours playing nethack. I got much farther than I usually do: finished the first half of the mines, all of the Sokoban levels, and then descended as far as the Quest before succumbing to a death-ray (which instantly kills you unless you have special armor). Sigh. Makes a nice high score entry, though...

  1     118879  Petra died in The Dungeons of Doom on
                level 14 [max 21].  Killed by a death ray.

The frightening bit is that that's about as far as I ever get in this game... and it's only about a fifth of the way through.

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.

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!