Morten Welinder

Until recently I have been using xterm and twm. Call me a stone-age
throw-back if you like, but those two are fast and lean.

But I am giving gnome-terminal and metacity a spin now. Metacity
suffers somewhat from click-to-focus, even if you set
it to focus-follows-mouse, but that is a story for another day.

Today it is gnome-terminal gripe time. Ok, so it is actually not
too bad, but it feels slow. Starting the first terminal window,
for example, takes a few seconds. Seconds! I want my window to
show up in less than .2 seconds.

A bit of stracing reveals the cause. It is dlopen-ing a zillion modules related to character support.
That is used to populate a, I estimate, rarely used menu. In my humble opinion, the penalty for this kind of thing should not be taken on startup, but when the rarely-used feature is activated. Or in the background while I type away happily. Luckily this does not seem
too hard to fix.

On top of this, Fontconfig is doing a whole lot of work on startup.
It does that for other GTK+ based programs too, so I doubt the
applications are to blame. So what does it do?

• Stats ~200 directories all over the place.
• Feels the need to do things three times:

  access("/etc/fonts/suse-hinting.conf", R_OK) = 0
  stat64("/etc/fonts/suse-hinting.conf", {st_mode=S_IFREG|0644, st_size=6575, ...}) = 0
  open("/etc/fonts/suse-hinting.conf", O_RDONLY) = 18
  

  Are you there? Are you there? Please open! This kind of behaviour
  is fairly cheap on a local file system, but not necessarily so on
  a remote one. And it is wrong: the file could have changed twice between the three calls.

• Zig-zag reading files:

  read(17, "     fd9 78563412    1    4    4"..., 255) = 255
  lseek(17, -136, SEEK_CUR)               = 158
  read(17, "/usr/X11R6/lib/X11/fonts/CID/us"..., 4109) = 3938
  lseek(17, -3909, SEEK_CUR)              = 187
  read(17, "/usr/X11R6/lib/X11/fonts/URW/us"..., 4109) = 3909
  lseek(17, -3880, SEEK_CUR)              = 216
  read(17, "/usr/X11R6/lib/X11/fonts/uni/us"..., 4109) = 3880
  lseek(17, -3851, SEEK_CUR)              = 245
  

  Back-and-forth over the same area again and again. Short of timing
  system call overhead I do not see what it is doing.

I am also having problems with focus in the terminal. I am not entirely sure how I manage, but
somehow the focus ends up on one of the tabs where it has no business being.

If you click on the column header of a regular treeview, the
entries will get sorted by the values in that column.

That works fine for the file chooser, at least if you sort by
filename.

It works horribly for programs like Banshee that display a long
list of (artist,album,song) entries. Sort by artist, according
to the treeview, means something like “sort by artist, and insofar
two entries’ artist values agree, pick a random ordering”.
That is useless! (It is a different matter whether Banshee has
the right interface for its song list. Add a few thousand songs
and I have the feeling the UI will suffer.)

To be useful, one ought to have the option of telling the treeview
that sorting by artist really means to sort by the (artist,album,song)
tuple.

So what am I not seeing?

I have noticed some trends in how the “severity” field in Gnome’s Bugzilla is being
used at the initial bug reporting time. Basically, “enhancement” is being used mostly right (although it has little to do with severity) and the others can be interpreted
in the following way:

Blocker: It happened to me.

Critical: I do not know how I can go on living if
you do not drop everything in your hands and fix the cosmetic problem
I believe I am seeing. Right now.

Major: This might become a problem for me
at some point in the future.

Normal: I did not see the option when I filed the bug.

Minor: Rarely used.

Trivial: I saw it happen to someone else.

Now, if someone could please tell me why we let non-maintainers
set the “priority” field…

Miguel,
I am less impressed by that blog entry.

Let’s see… “In C this causes an array index out of bounds with unpredictable results.” Nope. In C it causes a signed integer overflow and hence unpredictable results. Consequently, casting the sum to unsigned will not fix it.

And if you are going to worry about overflow for one addition, why not
worry about overflow for the others? Line 10 and the subtraction on line 12 look safe, but
line 16 can overflow. That expression should be changed from
-(low + 1) to -low - 1. (I do not actually know if that is needed in Java, but in C it would be.)

Finally, the algorithm still does not work for sizes from 2^31 and up. To fix that, one would start working with unsigned quantities (thus solving the overflow problem as a side effect) and think of some other way of returning “not found”.

I really need to write that patch I have been threatening for while
now: make gcc issue a warning when -Werror is used.
The purpose of -Werror seems to make code not compile on machines
that are different from the one of which -Werror was introduced. My
gcc patch would direct the pain where it belongs.

Case in point: gcc’s warnings about potentially uninitialized
variables come and go with different versions, optimization
levels, OS, etc.

Case in point: alignment requirements differ between archs. Thus
warnings about them will too and in an object system like glib’s
we have a _lot_ of casts that can change alignment requirements.

Case in point: my system libraries like to define the same external
funtions [identically] in several different headers. That’s
perfectly valid, but gcc will warn given enough -Wflags.

Case in point: pragmas in system headers. Warnings I can simply
ignore, but -Werror what am I to do? Fix gcc not to warn?

Case in point: signal handlers. You try dealing with them in a
way that does not produce warnings on some arch.