Re: gnuplot slow on BIG files

[Ethan M. <merritt@u.washington.edu>]

On Saturday 11 June 2005 03:53 am, Robert Hart wrote:
> You seem to be implying that we shouldn't be making any kinds of changes
> to the core of gnuplot without being sure they will work on all of the
> platforms that gnuplot has *historically* supported.

We dropped support of 16-bit DOS when we released version 4.0.
And that's an OS that everyone has heard of, and many of us probably
still have distro floppies for it gathering dust in a file drawer.
Furthermore, we knew how to fix the build problems but chose not to.

I have no problem with that; I think dropping it was the right thing
to do.  But then why go even one step out of our way to avoid maybe,
possibly, triggering a bug on a totally obscure OS that no-one has
heard of?  It's absurd!  If OSK or some other relic of an OS has a bug
in a system library, let someone who cares about that OS fix it.

Robert hit the nail on the head when he quoted the recent article
on "the burden of (extreme) minority architectures on open source
software".  I regret even wasting the time it took to track down
the fact that this bug probably disappeared when gcc/glibc was ported
to OSK *eleven years ago*! If someone is still using a pre-1994 buggy
libc on OSK, too bad for them.

Let's drop any special-casing for OSK right now.

Let's also issue a call to any Amiga users, and if none turn up
let's remove all the special casing for Amiga as well.

I'd be willing to bet that the Next/OpenStep special-case
PostScript drivers are no longer worth keeping either, in the sense
that they don't support the features added since version 3.7 so
it would be pointless for anyone using them to upgrade to a newer
gnuplot.

I propose that our guiding principle should be:

 Support for obsolete platforms will be frozen at the last
 gnuplot release for which there was evidence of an active user
 community. People running archaic hardware should not be surprised
 if they have to run less than state-of-the-art software on it.

> The fact is:
> a) we've checked this on all the platforms we have access to.

Err. That's not quite true.  I checked half a dozen platforms,
but I could double or triple that if it were strictly necessary.
And I did so before the 4.0 release, at least to the extent of
building from source and running "make check".

> FYI: Known strtod bugs, I can find:
>
> On mac OSX, "NaN" is not recognised.

We test for it elsewhere, so I don't think this would affect us.
But that is clearly an OSX bug.  Let them fix it.

> Under Solaris 2.4, strtod returns the wrong value for the
> terminating character under some conditions.

At worst that would fail to handle the Fortran D/Q format
case.  This also is clearly an OS bug, and not something we
should have to code around.

> Also, on Compaq's Tru64 Unix 5.0,
> strtod(" ") returns 0.0 instead of a failure to convert.

That could, indeed, have been a problem. On the other hand, the 
existing non-scanf code paths in datafile.c strip away leading whitespace
so it would not in fact have bitten us.  Anyhow, it seems to have been
fixed, or at least my lab machines running Tru64 do not behave that way.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742