So what do you do when distributions (Mandriva, Ubuntu, and Gentoo so far)
send out
security fixes for a non-problem?
Ignore it? Certainly an option.
Spam the security lists with “that’s not a problem”?
So what do you do when distributions (Mandriva, Ubuntu, and Gentoo so far)
send out
security fixes for a non-problem?
Ignore it? Certainly an option.
Spam the security lists with “that’s not a problem”?
Gnumeric’s solver was broken in HEAD and while fixing it, I
updated to the latest version of lp_solve.
Let me tell you, lp_solve is a prime example of how not to make
a library! It looks like there used to be a program and that it
was made into a library by removing main.
There is no concept of namespaces there. When you include the
relevant header file, you get everything used anywhere internally:
EQ, gcd, MALLOC, TRUE, is_int, and about 400-600
other identifiers.
You cannot isolate that problem to just where you use the header,
by the way, as static is practically usused.
I decided to throw a perl script at the problem and combine everything into one
gaint C file. All 44186 lines of it after pruning about 5000 lines.
The script adds tons of statics in the process,
renames the relevant part of the API, and extracts
that API. Extra points for you if you can read the perl script
without losing your breakfast.
…and so is Gnumeric 1.5.3. (Complete with a big ugly, but harmless,
error message on xls save — oops! At least we got it fixed in time
for Debian and the Win32 build.)
Dom,
it is probably not that they are being inefficient or behaving illogically. It is more like that they are optimizing a utility
function somewhat different from the one you would naïvely expect.
(A mathematician takes a walk and comes by a house on fire; he calls
the fire department and they come and put out the fire. The next
day he comes by a house that is not on fire; he sets it on fire and
walks on after thus having reduced the problem to a previously solved
one.)
It turns out that it is moderately common to have large number of
VLOOKUPs (or HLOOKUPs) in the same spreadsheet. Gnumeric is embarrassingly
slow for this. There are several reasons for this.
Profiling where the time
is spent points the blame at g_utf8_collate.
Thinking about the problem, however, suggests a different cause, namely that we are evaluating collate keys for the table every
once for every VLOOKUP. That is simple, easy to understand, and not
prone to obscure problems, but evidently it is not good enough.
Luckily it should be quite easy to add some kind of cache for this.
If I was redesigning the evaluation engine from the ground up, I would
probably compile expressions into some kind of byte code with common
subexpressions explicitly taken care of. But I am not, so the above
cache will have to do for now. That should also handle the case where
the subexpressions are not statically common, but the result of
something like INDIRECT.
INDIRECT, btw., is the single most ugly
feature of spreadsheet semantics. It turns the result of an expression into a cell or name reference and if I was designing
a proposed standard
formula syntax and semantics for spreadsheets I would think
long and hard about INDIRECT and its consequences. But I am not.
(Interestingly, most uses of INDIRECT that I have seen would be
far better handled as INDEX calls.)
Back to g_utf8_collate. It works by converting
both strings, in their entirety, to a normalized format and then
comparing those. In a language like C, as opposed to Haskell, that
is quite wasteful in two ways:
It gets even sillier if you want to do the comparison while ignoring
letter case. Then you first get to case fold the strings in their
entirety before you can call g_utf8_collate.
Federico is bringing up the file chooser’s lack of speed again. Good.
The first step, IMHO, should be to get rid of reloading the folder
of widget mapping. It is wrong to do non-widget, expensive and externally-visible actions in a widget mapping handler. If someone
switches to another virtual screen and back (for example to peek at something),
do we really want to reload the folder? Do we lose the selections
in the process? If The Gimp wants that behaviour, I say it can
install a handler and trigger it itself.
Would things appear to be faster if we installed a single-shot
idle-handler that created a file chooser and threw it away?
(That would be a work-around more than a fix, of course.)
There is more to your item 7 than just performance, btw. It should
not stat() all those parent directories because it may not be allowed
to do so. If you just succeeded in stat(“/foo/bar/baz”) then
it should not be necessary to check that “/foo” and “/foo/bar” are
directories.
It looks like someone took Mr. Bush’s word to the bank and just like
a bad check, it bounced.
Again.
Nat, that is crazy.
You are not exactly 25 years old anymore.
Ok, I have done worse, i.e., I have done 200 miles a couple of times.
That takes about 12 hours, all breaks included. Some things you ought
to know in advance:
For entertainment purposes only:
Evidently someone dumped a feature request for Gnumeric on
comp.os.linux.advocacy and is mildly upset that after a year it has not been implemented.
(Not even an interesting feature, mind you.)
In my humble opinion that is like tattooing an Excel feature request on
your butt, flying off to Redmond and mooning the Microsoft campus on
a dark and rainy winter evening. That is likely to work, for sure.
Bugzilla might not be the world’s best bug reporting interface,
but it sure beats mailing lists and irc in terms on probability
of the bug report not being forgotten forever.
Nat,
here is your chance to recycle a few select quotes from The Incredibles.
I do not recall having a graduation ceremony after my own time in
pre-K.