October 17th, 2007 by mortenw
I installed OpenSUSE 10.3 the other day and these are my first impressions.
Installation went smoothly — a few packages had to be manually added as usual. Emacs, for example, was not part of the default install whereas Freeciv was. I would like someone to explain that some day.
I am pretty happy with it so far, but of course I have notice something that could deserve improvements.
- Package manager
- I find the new gui with installed and available in different columns quite unintuitive. The old layout with one list and a install/uninstall/etc marker used much less screen real estate and left meaningful space for package description. Unrelatedly, it starts with gtk assertions:
(y2controlcenter-gnome:4204): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path: assertion `g_path_is_absolute (local_full_path)' failed
(y2controlcenter-gnome:4204): libgnomevfs-CRITICAL **: gnome_vfs_monitor_add: assertion `text_uri != NULL' failed
...
which probably is not a good idea.
- f-spot
- The new version is nice, but when I first installed it, it would not start. Investigation showed that its dependency, sqlite2, was not installed, whereas sqlite3 was. I suspect a packaging problem.
- Network manager
- Where to start? Hmm… It still crashes left and right. I hope I don’t have to see anything about connection to network “(null)” anymore. Why does it have to wake up every second and do nothing?
- Login screen
- The tab key used to work to switch from login to password. Now it just selects the login name. I am not sure what that change was meant to improve.
- Beagle
- Utterly unsuited for a machine like this. Why does Novell push this cpu/battery vacuum cleaner so hard?
Posted in General | Comments Off
September 11th, 2007 by mortenw
I had a look at “OOXML is defective by design” and, quite frankly, I am not impressed.
On my surface it is a comparison of OOXML and ODF and it comes out as a landslide victory to ODF. But anyone who has worked with spreadsheet file formats will easily see that it was written by someone who, intentionally or otherwise, is deaf, dumb, and blind to the shortfalls of ODF. And if that is where you start, then what is the point?
For example, OOcalc suffers from exactly the same rounding issue that Excel does. How could it be any different when both are based on floating point numbers? (An in neither case is that a file format issue, but rather an implementation issue.)
For example, the reason that he can happily declare that ODF has backwards compatibility is that he choses a graph sample. And OOcalc’s graphing system has not, shall we say, seen a lot of improvement since the version he tried with.
Don’t complain that “ECMA 376 documents just do not exist” when the same can be said for ODF. As-of version 1.1 of the specification there still seems to no syntax for 2+2.
One could also ask a question such as “how well can legacy spreadsheet files be represented in either format?” A very reasonable question, in my humble opinion, given the number of sheet out there. Of course, since ODF doesn’t actually have non-trivial formulas, we should probably just interpret it with respect to OOcalc’s format. I do not think ODF would fare well here.
Disclaimer: I have not, and I probably will not, read the full OOXML spec.
Posted in Gnumeric | Comments Off
August 31st, 2007 by mortenw
I am struggling with the concept of being a part-time vegetarian. What exactly does that mean? Perhaps even I can be considered a part-time vegetarian when I eat my corn-on-the-cob between my lobster and my steak. Trust me, I am not easily mistaken for a vegetarian!
Posted in General | Comments Off
August 4th, 2007 by mortenw
I found this sign in a park in Beijing:
I tried to follow it to see what it meant, but it turned out to be a dangling pointer.
Posted in Stuff | Comments Off
May 27th, 2007 by mortenw
…although I am willing to entertain the idea that they are a necessary
evil.
Themes in GTK+ land are, simplified, arbitrary pieces of dynamically
loaded code that is hooked into the drawing layers of widgets. There
is no fault isolation, so when (not if) a theme does something naughty,
the application crashes. Then the user curses a few times and blames
the usual suspects: the screen/keyboard and the application.
Have a look at bug 438456. Theme code used in, for example, the industrial theme released various
kind of memory allocated by GTK+ using the wrong function, in this case g_free. Result: instant memory corruption in all GTK+ applications! Not good.
I do not think it is realistic to redesign the theming of GTK+ at
this point in time, but we really need to do something about
stability.
- Theme authors need to be extremely careful with their coding.
- Theme authors should use the full range of automated testing
at our disposal: running under Valgrind and separately with G_SLICE=debug-blocks during some kind of theme torture test is a bare minimum. For every release.
I realize that I am asking other people to do some work. I do not feel too bad about that, though, because it is theme code that is causing my application to crash, causing people to lose data, and the blame is sent my way.
Ok, go ahead and tell me how wrong I am.
Posted in Gnome | Comments Off
March 31st, 2007 by mortenw
When your four-year old asks you to shave and your six-year old asks
you to dress up, there is some kind of hidden message.
Posted in Kids | Comments Off
February 20th, 2007 by mortenw
I have spent a few evenings working on Gnumeric’s number formatting,
i.e., the process that takes a value (3.14, “xyz”, TRUE, …) and
a format (an object initialised from a string like “[red]0.00″)
and use them to produce the string displayed in a spreadsheet cell.
Format strings are, if the user gets near them, an unmitigated GUI
disaster. How about this beau?
dd-mmmm-yyyy[$-40b]/dd-mmmm-yyyy[Whitestone"76]*;;0/128[Blue]
(Which means typeset a non-negative number, representing a date, twice, once with month in the current langugage and once in Finnish. If there is room leftover in the cell, fill on the right side with semicolons. Oh,
and make it all white. Negative numbers, however, should be written in blue as the nearest 128th, without the minus. Non-numbers should be left as-is.)
Excel actually exposes hexadecimal numbers there! And
the parsing rules are really complicated and very much undocumented.
Well, it is documented in a variety of places, but the documentation is always combinations of wrong and incomplete.
I doubt anyone currently at Microsoft knows the details at this point
in time, but they can at least look at the source code. And format
strings can be translated (back and forth) in undocumented ways too.
Ick.
Anyway, I have been compiling a test workbook for formats. It uses the TEXT function which conveniently exposes most of the formatting logic. (Note: you must run in the US locale as many tests depend on that.)
Think of the file as a collection of horrors.
With my (unpublished) code, the score is:
Gnumeric: Pass: 606; Fail: 0
Excel: Pass 594; Fail: 12
OOo: Pass: 221; Fail: 69788
It is important to understand somethings here:
- Excel can be wrong even though it is nominally defining the semantics. Most of the failures are avoidable overflows in fraction formats.
- The workbook was not written to make Gnumeric look good. It was written as a tool to help Gnumeric become good. And, in fact, if you loaded the file in older Gnumerics, you would see less than stellar results. Prior to version 1.7.7, Gnumeric would even read memory beyond the end of strings and thus possibly crash or, more likely, produce bogus results.
- The workbook was not written to make OO look bad. The fact that Gnumeric appears better is not only that I fixed Gnumeric, but also that I can only test the things I can think of. There might very well be formats that OO handles and Gnumeric does not. That is the problem with a basically undocumented language. Further, one problem might very well result in five or ten tests failing — things are not independent.
- The weird failure count for OO comes from array formulas that OO cannot handle.
At least one failure comes from incorrectly loading the constant to check against.
Posted in Gnumeric | Comments Off
January 21st, 2007 by mortenw
A shark, a lot of little fish, and a few trees in one picture:
Taken at “Atlantis”, Paradise Island, The Bahamas.
Posted in Stuff | Comments Off
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