Older blog entries for zw (starting at number 14)

To blizzard: If you're going to improve gmon/mcount, please teach it that if there's an existing gmon.out in the working directory, then it should augment that file instead of clobbering it. That way, if you want to profile a program that runs for a short time, you could just run it a few thousand times in a shell loop. Right now you have to do that, plus rename the reports so they all get saved, and then crunch them together at the end. This takes much longer than it has to, and throws your results off because disk cache is wasted on the huge gmon.out files which all have to stay around until the end.

To make this change safely, you should probably save the identity of the executable in gmon.out, and start over if it changes. (This should be done anyway.)

I'd also like to see better kernelside support for profiling. setitimer(2) has a lot of overhead, and the ticks don't come nearly often enough. SVR4 has a profil(2) system call that pushes the histogram updates into the kernel, which gets rid of the overhead but doesn't help with the granularity. Also, I don't think it can handle gaps in the region to be profiled, so your program has to be statically linked.

I'd rather not add system calls. Instead, I envision a pseudo-device which you map several different times, specifying the window of the address space to profile. It can use the high-resolution timer in the RTC to get ticks more often than the normal timer interrupt. Updates happen in the driver, so no more 30% of execution time spent in __mcount_internal.

GCC/i386 has a stupid bug where it clobbers %edx on every function entry, when compiling with profiling. This breaks -mregparm. Okay, that doesn't affect very many people - it still needs to get fixed.

I have heard two different things about Unicode:

  1. It is the One True Character Set, and the answer to all our problems, or at least the ones having to do with text encoding. Advocates of this position usually have a specific format that they prefer - UTF8 or UCS2.
  2. It is an abomination in the sight of God, and must be stamped out wherever it occurs. The usual reason given is that it's not a strict superset of all existing encodings. E.g. the conversion from various Chinese/Japanese charsets to Unicode and back is said to lose information.

The truth, as usual, will be somewhere in the middle. I don't know enough about the issues to judge. I would appreciate it if anyone who does know enough to judge would contact me and give me some clues. Email: zack@wolery.cumb.org.

Neil Booth came through with the new lexer for cpplib. It's much, much cleaner than the old one, and ~500 lines shorter to boot. Now I just have to knock together a glue layer so it will talk to the rest of the program, which expects a completely different interface. Then I can convert the old code to the new design over the next couple weeks instead of all at once.

The todo list is way out of date. I'd post a link, but it's so outdated it's actively misleading. Updating it goes on this week's queue, right after the glue works.

All the routines in cpp that I haven't gotten around to rewriting (there aren't too many left, thank ghod) look remarkably similar. They are at least five hundred lines long. They have at least ten levels of nested braces. They have at least ten variables that are used all over the entire function, plus at least twenty more declared in the inner blocks. And they have obvious places where they can be broken into smaller functions with ease.

I would like to know who it was wrote all the functions like that. They're not just in the preprocessor. They're everywhere in gcc. I mean, everywhere. And it's not like a monster function gets optimized better than four reasonable ones; in fact, just the opposite. Nor is it easier to debug a monster function, or profile it. And it is certainly not easier to edit it. So someone must have been absolutely in love with the things. And I want to know who, and why.

I have been notified that no, I may not remove support for grotty pre-ANSI macro tricks from the preprocessor. It turns out that the ickiness can be confined in a few small places, which is better than we had it before. But I really wanted it to go away entirely. *grumble*

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.

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