Re: Gnumeric 0.76 experiences (long)

[Nick Lamb <njl98r ecs soton ac uk>]

On Fri, Dec 14, 2001 at 11:12:28AM -0500, Jody Goldberg wrote:
> > #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

These bug fixes seem to fix the problem, I am unable to reproduce it with
libole2 0.2.4 and Gnumeric 0.99.0. So thanks, Morten.

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

I will write more about graphs another time, I think I have all the features
required to make them, but it doesn't work. So yes, probably a graph with
no working graph support (Guppi is installed).

> > ** 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.

I will re-confirm this with Gnumeric 0.99.0 and file a Bugzilla bug, then
mail Jody the offending file.

> > 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 ?

In en_GB at least we would expect both "-" and "/" to work since both are
commonly in use here, as is ISO yyyy-mm-dd to a lesser extent. Just in
case you were hoping it was easy :)

> > 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.

Looking at the code for this case I see why it's hard but I'm fairly sure
you can recover the same data as Excel. In essence Gnumeric needs to be
willing to programatically create invalid formulae (you can type them in
already, so it's only a small change). Not a vital 1.0 feature anyway I
suppose.

> > 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.

Will do, also PI() has "too much" precision in Gnumeric to match the
explicit definition in Excel. I will file a bug recommending that the
documentation for PI() mention the actual precision used as Excel does.

> > 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.

Considered, see next mail :)

Nick.