Re: Gnumeric 0.76 experiences (long)

[Jody Goldberg <jody gnome org>]

> 1. A crash which occurs only when loading certain XLS file(s) directly
> from the command line. I do not own the file in question and I don't
> remember where I found it, but I think giving it to one person for the
> purpose of finding/fixing the crash would be OK. The crash is 95%
> reproducible (once it didn't happen - race condition?)
Bugzilla the crash and send me the file. 
 
> The XLS file is about 240kb, and I'll mail it to whoever wants to fix
> this crash, here's a stacktrace, I am assuming that "libgnomeole2" is
> owned by Gnumeric, if not then please tell me who to forward it to.
>
> #0  0x401a82a0 in ms_ole_stream_open () from /usr/lib/libgnomeole2.so.0
Yes this is the libole2 module, we are the effective maintainers of
it for now.  Make sure that you have the latest version.  Morten
fixed several bugs in 0.2.4

> 2. 1904 date system
>
> The console window shows that Gnumeric knows it can't handle 1904 dates
> properly, but the user isn't warned in the GUI. It would be nice to have
> such a warning by version 1.0 (especially for Mac Excel users)
Not really feasible before 1.0.  We have frozen the UI and all user
visible strings.  I'll ask the translation teams

> Interestingly Gnumeric seems to use pre-calculated answers when loading
> XLS files (that's a guess) and initially it gets 100% on my 1904 tests,
> but hitting F9 means most test results change and Gnumeric scores poorly.
> Am I right that these pre-calculated results are from Excel? Or is there
> some other Voodoo at work which I don't understand?
Yes, XL saves the result of the calculations.  So we use them.
 
> 3. CRITICAL assertions
>
> ** CRITICAL **: file sheet.c: line 4456 (sheet_freeze_panes): assertion `unfrozen->col > frozen->col' 
> failed.
This is importing a sheet with horizontal or vertical only freezes.
Nothing to worry about.

> Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject'
Unknown, possibly a graph with no Guppi installed ?

> ** WARNING **: No small block file, but small block depot start block exists!: ignore depot, since there's 
> no small block files after all.
libole2 magic. 

> ** CRITICAL **: file sheet.c: line 2275 (sheet_col_get): assertion `pos < SHEET_MAX_COLS' failed.
> ** CRITICAL **: file sheet-control-gui.c: line 2291 (scg_colrow_distance_get): assertion `to <= 
> SHEET_MAX_COLS' failed.
EEEK!  This indicates a corrupt sheet, or a parse error on our part.

> ** WARNING **: EXCEL: color index (16777343) is out of range (0..56). Defaulting to black
ditto.

> 4. Parsing
> =datevalue("21-Dec-1975") 
This is a tricky problem.  The XL format specifier strings are a
mess and mapping from unix style locale info to them is non-trivial.
At present all we support is to guess
    d/m/y vs m/d/y
I have not found a decent way to find which separator to use.
Any have any ideas ?

> When saving a document with a duff formula, Excel seems to save and restore
> it correctly (ie it's still broken exactly the same way), but Gnumeric
> pointedly says e.g. "Incorrect number of parsed formula arguments" and
> replaces the nearly-correct formula with =WrongArgs(blah) and thus the
> error code (which in Excel might be #REF! or #NUM! or something) becomes
> #NAME? because the function name is lost.
Hmm, the difference is that XL is storing it's own format for
expressions, we need to translate.  If we can't parse it we can't
export it.  I'll think about this later.
 
> 5. Function compatibility
>
> PERCENTRANK() with values {11.5 12.3 66.3 23.9 } x = 21.5 sig = 1
> Excel returns 0.5, Gnumeric says 0.6
Bugzilla please.
 
> Unlike most other function help, the documentation for PERCENTRANK doesn't
> say that it is Excel compatible. Is this an intentional compatibility gap
> for Gnumeric? Will users (eventually) be warned when their sheets contain
> unsupported/ incompatible Excel functions?
Interesting notion, Bugzilla it.

> X. Early (non OLE) XLS files, not for 1.0
>
> I understand that these files can still be created today, and that there
> might be many millions of them out there. I don't know how seamlessly
> they load them into Excel XP, but presumably it can salvage at least the
> data (text, grid of float values) and simple formulae.
Doing this is not impossible, but there are lots of other things to
work on first.  Consider it an available project.