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?
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.
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.
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!
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?
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.
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.
xorg-redhat-die-ugly-pattern-die-die-die.patch is a perfect example
of a bad we-know-better attitude.
It removes the beautiful grey cross hatch stipple from X. Evidently
because someone knows better what other people like. How does one
get it back, short of tiling a bitmap? If it is anything like
SuSE’s similar patch, you don’t. At least not while the X server
is running.
In summary. Before: you could have a solid-colour background or you
could have a cross hatch background. Just you xsetroot.
After: you get what some monkey with poor eyesight though looked
nice. You cannot change it. After all, he knows better.
Incidentally, the default X pattern also serves to show the poor
state of flatscreen technology. It seems the pattern cannot be
shown over the whole screen without a certain amount of flicker.
DTrace looks nice, but it is not as-if the means to do what it does
haven’t been along for a long time.
My humble contribution: strace-account.
To use…
strace -o ~/ttt top
# q when you get tired
strace-account ~/ttt | less
from which we learn:
Cumulative Syscall Times.
------------------------
Syscall Count Time(s)
-----------------------
select 8 19.42
read 3939 0.06
open 3165 0.04
close 3172 0.03
alarm 2142 0.02
stat 1565 0.02
fcntl 1523 0.01
(other) 336 0.01
Repetitive File Name Usage.
--------------------------
This is a list of files that are accessed, one way or another, at least
twice. Note, that current directory is not being tracked.
Count Filename
----------------------------------
14 /var/run/utmp
8 /proc
8 /proc/1
8 /proc/1/stat
8 /proc/1/statm
...
2 /proc/meminfo
2 /proc/stat
2 /usr/share/terminfo/x/xterm
Small-Chunk File Input/Output.
-----------------------------
This is a list of files that are accessed in small chunks. "Badness" is a
heuristic measure of this. The list is truncated at badness 2.00. A file
can appear more than once if it is opened more than once.
Badness Bytes I/Os File
-------------------------------------------------
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
12.75 38784 102 /var/run/utmp
2.67 2122 8 /usr/share/terminfo/x/xterm
2.26 40878 23 (stdout)
...
My interpretation of this version of top’s output is that it is
opening way too many files way too many times. why is it also
calling stat(2), alarm(2), and fcntl(2) so often? [So it can connect
to /var/run/nscd/socket in non-blocking mode over and over again, if
you must know.] It also likes to read utmp many, many times in little
pieces.
(strace-account is a bit of a hack. An strace with an output format
more suited for machine reading would be nice. It might even have
appeared since whenever I wrote strace-account.)
Bad Behavior has blocked 64 access attempts in the last 7 days.