January 21st, 2007 by mortenw
I wanted to know when a certain identifier was introduced in goffice.
It turned out that it was fairly simple:
git grep -w GO_FORMAT_MARKUP `git tag -l 'GOFFICE*'` -- '*.h'
That commands searches all .h files from all Goffice releases.
It is very fast: about 0.5s (cpu time) on a fairly slow machine.
How do I do that with SVN?
Posted in Gnome | Comments Off
January 7th, 2007 by mortenw
I wanted to create an archive of all released Gnumeric versions.
Gnumeric’s CVS tree saw a lot of hacking on the ,v files so neither
CVS nor the derived SVN tree are useful for reconstructing past
releases. They are useful for tracking a given file’s history
minus the renames it went through.
So I hacked up a script to create a git archive for me. (You cannot actually run that script, though: it hits a “tar” bug — ick! And after hacking that, beware that it takes a long, long time to run.)
Total size of 172 tar files: 1508026377 bytes.
Total size of git archive: 139733921 bytes
Ratio: 10.8
Not too shabby, eh? Even if the corpus is pretty special.
Seeing what changed between releases is as
simple as git diff -u GNUMERIC_1_7_0..GNUMERIC_1_7_1
and very fast.
Posted in Gnumeric | Comments Off
December 26th, 2006 by mortenw
I’ll happily add myself to the chorus: switching to SVN? Someone must
have been drinking out of the potty.
If we are going to suffer the pain of a conversion, then we have better get a lot out of it.
- Retraining. We all know cvs’ quirks. (And my fingers like to type c-v-s.)
- Lost history. None of the conversion tools are perfect.
- Recoding. Custom scripts will have to be recoded.
These apply to all systems (except cvs). The trouble with SVN
is that it is hard to see it as more than a stepping stone.
Dave, if the only argument that people have against it is that “everyone knows that distributed’s better” is what you believe, then you have not been listening. Start with KeithP’s write-up saying, in part, that (1) SVN lacks corruption detection,
(2) Git is a whole lot faster than SVN, and (3) SVN is a space pig compared to Git.
By the way, why is it relevant whether most distributions include the system by default? We expect, from time to time, that developers have HEAD versions of various off-site libraries, so surely we can get the same developers to obtain a recent copy of Git (etc.), right?
So can we please have git and gitweb running somewhere on gnome.org
with access to, say, ~user/public_git/ directories? I promise that I will not complain too much about SVN if that happens.
Posted in Gnome | Comments Off
December 5th, 2006 by mortenw
I have been trying out f-spot recently and I must say that using
it gives me one of those rare warm fuzzy feelings inside.
It has well designed interface with relatively little clutter.
It by and large does what I want it to.
And it does not crash or hang for me.
It does not even spew a lot of scary warnings in my session log file.
I can find nits, sure I can. In fact I just filed a pile of them, but we are talking the would-be-nice department here.
Nice job on this, guys!
Posted in Gnome | Comments Off
November 22nd, 2006 by mortenw
I released Gnumeric 1.7.3
only to discover that a little too much editing killed evaluation in
very common situations. Bad me! 1.7.4 is out.
That is not going to happen again.
I sat down and spent a few hours automating most of our tests. Then
I added a valgrind run and the beginning of tests of our importers.
It is part of “make distcheck”, so testing is now mandatory and automatic.
The workhorse of these tests is ssconvert, our handy little command-line utility that converts from one format to another.
By forcing evaluation of all cells between import and export,
we end up exercising quite a large part of the core. As well
as a few importers and exporters. No GUI tests are currently performed, but I suspect we can add that
too somehow.
Posted in Gnumeric | Comments Off
November 16th, 2006 by mortenw
My company is hiring. Note, that
the jobs have nothing to do with open software and that we are rather
picky.
Posted in Stuff | Comments Off
November 14th, 2006 by mortenw
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.
Posted in Gnome | Comments Off
September 13th, 2006 by mortenw
It looks like every geographic area has its own version of duct tape
in the used-far-outside-its-intended-domain sense when it comes to
home repair.
In the neighbourhood of Home.1 it is paint. There is nothing that
cannot be fixed with an extra coat of paint. Door is scratched?
Paint it! Floor is not level? Paint it! Roof leaks? Paint it!
Window broken? That has not actually happened to me, but I am sure it
will get painted.
Near Home.2, things are different. The material of choice is sealant
of the type properly used for sealing around the tub. It is
everywhere. Cracked marble? Seal it! Lose tile? Seal it! Crack
between floor board and floor? Seal it! Need to make wall paper
stick at floor board? Seal it!
It could be worse, I guess. Maybe some places use floor wax or drain
opener to get through the day.
A public service announcement: anyone who suggests going furniture
shopping to me in the near future (i.e., months if not years) risks
getting whacked over the head with a corner sofa in his or her choice
of beige or red fine, Italian leather.
Posted in Stuff | Comments Off
September 13th, 2006 by mortenw
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?
Posted in Gnome | Comments Off
September 12th, 2006 by mortenw
In classical multi-lane traffic, cars travel in one lane or
another. When a driver wants to change to a different lane, he or she
does so quickly and order is maintained. However, in quantum
multi-lane traffic, it is quite common to observe a car that is, say,
70% in one lane and 30% in the next. The precise meaning of such a
state is unclear, probably ranging from “I think I want to be in this
lane, but I might need this other one later” to “My ego is too big for
just one lane.” Either way, it is rather unnerving for classically
trained drivers. You can find quantum multi-lane traffic all
over Beijing.
Speaking of Beijing traffic, one cannot help marvel at the city-wise
art show put on display for drivers in the city. I refer here to what
looks similar to the traffic lights you can find in most western
cities. It is only looks that are alike, though, because the Beijing
ones seem to have no traffic regulating function. Instead you can
imagine drivers admire yet another masterpiece from the artist’s “red”
period while proceeding at full throttle.
(To be fair, I’m sure there are rules. Some of them even written down, but clearly they are different from what I am used to. Then
again, I find the Pittsburgh left turns scary.)
Posted in Stuff | Comments Off