Re: Calling all Atari geezers - Hello, anyone there?

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

On Thursday 13 March 2008 02:41, Daniel wrote:
> Hi,
> 
> A bit off topic but what are the things that change between platforms?  
> What's the need for the ifdefs. In a naïve voice I say "Code is just  
> code right"?

Examples:

- Age of C compiler+library.  E.g. Ancient libc may not provide strncmp()
  and friends, but we really want to use these if possible.

- File handling.  E.g. MS Windows requires (or at least it used to)
  special treatment of binary files.

- Standards compliance. E.g. does the platform support pipes or not?
  If it does support pipes, do they work reasonably (MSWin: no).
  Does it support internationalization via LOCALE?
  Signal handling?

- Floating point support.  Gnuplot dates back to a time when different
  hardware implemented different representations for floating point
  numbers, with corresponding differences in precision and range.
  Even today there are differences in floating point exception handling
  and support for Inf and Nan.  Large chunks of code and data in
  specfun.c exist to deal with these idiosyncrasies.  One the one hand
  they are probably outdated, but on the other hand they are pretty well
  hidden from the rest of the code so it doesn't bother me that much.

- Mousing support. This is probably the worst tangle.  The mousing
  support offered by x11, windows, pm, OSX, and wxWidgets all use different
  mechanisms.  We try to deal with all of them using shared code, but it
  requires a lot of conditional code.  As a historical side note, there
  were well-intentioned projects like GIGI that aimed to provide a unified
  platform-independent API for graphics interaction. None of them ever
  gained much traction in the real world. Gnuplot has a GIGI driver too:-)

- Not platform-dependence, but another source of #ifdef tangles:
  New features (the ones marked EXPERIMENTAL) have been added to CVS with
  their code bracketed by #ifdef FEATURE_NAME ... #else ... #endif.
  This makes it a bit easier to debug problems, and allows people to
  save a [small] bit of space when compiling the program if they don't
  need the feature.  However, to my knowledge none of the individual
  selectable features makes even 1% difference in program size, so I
  don't find that particular rationale very compelling.

	Ethan


> On 13 Mar 2008, at 03:35, Allin Cottrell <cot...@wf...> wrote:
> 
> > On Wed, 12 Mar 2008, Ethan Merritt wrote:
> >
> >> We could lighten the gnuplot codebase by 2800+ lines if we drop
> >> our current pretense of atari support.  I am dubious that the
> >> current CVS tree would compile on this platform...
> >
> > You're the one doing the great bulk of the work here, but in
> > looking at the gnuplot code I'm struck by how difficult to read
> > many sections are, on account of the multiple ifdefs for various
> > seriously archaic OSes.  Getting rid of atari seems like a good
> > start.
> >
> > Allin Cottrell
> >
> > --- 
> > ----------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742