gnuplot-beta — Developers and beta testers of new gnuplot code

Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> On Thursday 14 July 2005 10:09 am, Dave Denholm wrote:
> 
>>I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
>>referring to issuing a prompt during multiplot at all.

> Furthermore, the code segment that tests it can never be reached.

For that I'd like to see proof.

>>Ah - non-interactive read means from stdin without 
>>prompting.  

Or from a file.  Anything but "from stdin with a prompt", really.

Re: terminal API: Intent of multiplot suspend/resume?

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

On Thursday 14 July 2005 10:09 am, Dave Denholm wrote:
> 
> I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
> referring to issuing a prompt during multiplot at all.

I don't know what it was intended to mean, but there is no driver in 
the current code base which uses it. Furthermore, the code segment that
tests it can never be reached.

> Ah - non-interactive read means from stdin without 
> prompting.  Presumably  interactive means isatty(stdin)  or something
> like that.

It means
   (1)   no files on shell command line and isatty(fileno(stdin))
or (2)   we are inside a load command and the filename is '-'
or (3)   (AMIGA && IsInteractive(Input()) == DOSTRUE)


Note that (1) and (2) potentially contradict each other.
I'm not sure which one wins out :-)


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: terminal API: Intent of multiplot suspend/resume?

[Dave D. <dde...@es...>]

Hans-Bernhard Broeker <br...@ph...> writes:

> Ethan Merritt wrote:
>> While I was trying to use the term->suspend() and term->resume()
>> API to implement Harald Harders' treatment of front/back text labels
>> in epslatex, I discovered that it is pretty much useless.
>
> I strongly suspect that to be a premature conclusion.
>
>> The suspend() and resume() functions are only called if you are
>> in interactive mode.
>
> Not so.
>
> Here's the relevant snippet from term.c:term_check_multiplot_ok(),
> reindented for legibility.
>
>      if (!f_interactive
> 	|| (term->flags & TERM_CAN_MULTIPLOT)
> 	|| ((gpoutfile != stdout)
> 	    && !(term->flags & TERM_CANNOT_MULTIPLOT)
> 	   )
>         ) {
>          /* it's okay to use multiplot here, but suspend first */
>          term_suspend();
>          return;
>      }
>

I think the comment just above that block is possibly even more
legible :

    /* make sure that it is safe to issue an interactive prompt
     * it is safe if
     *   it is not an interactive read, or
     *   the terminal supports interactive multiplot, or
     *   we are not writing to stdout and terminal doesn't
     *     refuse multiplot outright
     */



> So term->suspend, if it exists, will be called on entering multiplot
> mode, in each of the following cases:
>

Don't think so. This function is called just before attempting to
issue a prompt while already in multiplot mode. It is there to decide
if it is safe to issue a prompt while in multiplot mode, or if the
display driver cannot preserve graphics content across a switch to
text mode.


I think the point is that the following will work with *any* terminal
driver :

 set multi ; plot sin(x) ; plot cos(x) ; unset multi

because we enter graphics mode once, issue a sequence of calls, then
leave. The terminal driver need never know it has done a multiplot.

This is why the checks are deferred until we try to issue a prompt,
because it is only then that things can go wrong.

I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
referring to issuing a prompt during multiplot at all. (Many direct
graphics drivers don't honour the output redirection. Eg X11, linux
vga)



It's not clear why we call suspend at all for a non-interactive
read. Ah - non-interactive read means from stdin without
prompting.  Presumably  interactive means isatty(stdin)  or something
like that.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: terminal API: Intent of multiplot suspend/resume?

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

On Thursday 14 July 2005 07:04 am, Hans-Bernhard Broeker wrote:
> > The suspend() and resume() functions are only called if you are
> > in interactive mode.  
> 
> Not so.
> 
> Here's the relevant snippet from term.c:term_check_multiplot_ok(), 
> reindented for legibility.

Yes.  But term_check_multiplot_ok()  itself is only called in
interactive mode.  Try it and see :-)


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Hans-Bernhard B. <br...@ph...>]

Robert Hart wrote:

> In particular is anybody actively testing the CVS version on non-POSIX
> platforms? 

Yes.  There may not be terribly many of them, but they exist.

> Do we have a release schedule in mind for the next version?

As long as I've been active in this project, there's never really been 
any kind of "schedule" other than the "Let's suit up for a release 
*now*" variety.

Re: terminal API: Intent of multiplot suspend/resume?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> While I was trying to use the term->suspend() and term->resume()
> API to implement Harald Harders' treatment of front/back text labels
> in epslatex, I discovered that it is pretty much useless.

I strongly suspect that to be a premature conclusion.

> The suspend() and resume() functions are only called if you are
> in interactive mode.  

Not so.

Here's the relevant snippet from term.c:term_check_multiplot_ok(), 
reindented for legibility.

     if (!f_interactive
	|| (term->flags & TERM_CAN_MULTIPLOT)
	|| ((gpoutfile != stdout)
	    && !(term->flags & TERM_CANNOT_MULTIPLOT)
	   )
        ) {
         /* it's okay to use multiplot here, but suspend first */
         term_suspend();
         return;
     }

So term->suspend, if it exists, will be called on entering multiplot
mode, in each of the following cases:

*) if non-interactive
*) if the terminal driver says it wants it to be called (even in 
interactive mode), by setting the "TERM_CAN_MULTIPLOT" mode.
*) if the terminal driver supports multiplot at all.

> On terminals that actually need use routines (amiga svga pm vgagl),

That list appears to be missing aquaterm, ggi, linux, mac, windows and 
x11.  Now, ggi and linux could perhaps be subsumed under "svga", but the 
others are for real: they actually do something in term->suspend(): they 
update the partially finished multi-plot to the canvas.

> has mulitplot never worked in scripts or via load commands?

It has worked.

> I had never imagined this was meant to imply that a terminal could
> *not* multiplot if the output *is* redirected.

That's not what it implies.  It only implies that such a terminal
driver needs special attention to implement interactive multiplot in a
sensible manner.

In a nutshell, the terminals that strictly need these functions are 
those where the interactive command prompt and the graph must not be 
output to the default device simultaneously: the full-screen terminals 
that alternate between text and graphic modes, and possibly some others 
that output graphic as a metafile to stdout by default (unixplot and GNU 
libplot output).

The calls are also useful for interactive GUI terminals where people
would naturally expect to see the first plot in the graph window while
they compose the second.  These calls may not be wanted in 
non-interactive mode on such terminals, though, because they slow down 
operation by causing redundant re-draws (i.e. time for a multiplot of N 
individual plots becomes O(N^2)).

Re: terminal API: Intent of multiplot suspend/resume?

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> While I was trying to use the term->suspend() and term->resume()
> API to implement Harald Harders' treatment of front/back text labels
> in epslatex, I discovered that it is pretty much useless.
>
> The suspend() and resume() functions are only called if you are
> in interactive mode.  That makes them pretty much worthless,
> so far as I can see.  
>
it was probably me that added them.

IIRC it was for things like linux vga mode, or kermit tektronix
mode, where there is one physical display, but separate logical
text and graphics displays (whose contents are maintained
independently). Switching to text mode does not clear the graphics,
just selects the text mode. This allows the user to type in the
next command without clearing the graphics that have been rendered so
far (which is required for multiplot mode).



> On terminals that actually need use routines (amiga svga pm vgagl),
> has mulitplot never worked in scripts or via load commands?
>

sure. Since it doesn't need to prompt the user for more input, it can
just stay in graphics mode and continue generating graphics.

definitely worked when I added that feature, but that would have been
a long time ago (3.6 era).


> Documentation in term/README is not very enlightening. It says
>
>   TERM_CAN_MULTIPLOT - driver can do multiplot fully-interactively
>                        when output is not redirected.
>
> I had never imagined this was meant to imply that a terminal could
> *not* multiplot if the output *is* redirected.
>

No. My assumption was that if the output is redirected to a file, it
does not conflict with interactive mode.

eg postscript :

gnuplot> set term post
gnuplot> set multi
lots of output generated, followed by

showpage
         Must set output to a file or put all multiplot commands on one input line

gnuplot>

because postscript cannot suspend the graphics when the output is
going to stdout.

But if I do

gnuplot> set multi ; plot sin(x) ; plot cos(x) ; unset multi

I get the whole (useless) graph on stdout, because there was no need
to collect more input during the generation of the output.


> Is there any reason we should not correct this oversight, and
> call suspend/resume regardless of whether the interactive flag
> is set?   

Well, with linux vga, it would mean the monitor switching back and
forth to text mode, which ISTR was rather unpleasant.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Robert H. <en...@no...>]

On Wed, 2005-07-13 at 15:24 -0700, Ethan Merritt wrote:
>  
> > I believe the new code is active by default in the CVS version and
> > people have been using it for a year or more.
> 
> Do you really have a handle on how much use it has seen?
> 

In particular is anybody actively testing the CVS version on non-POSIX
platforms? 

I had to compile the windows version the other week for a colleague who
had a need for features not in 4.0 - it surprised me how much has
changed since the last release. I could probably look at this in more
depth if needed (I had to leave out png, gif, and pdf terms because I
didn't have time to download pdflib and zlib)

Do we have a release schedule in mind for the next version?

Rob
 
-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Robert H. <en...@no...>]

On Wed, 2005-07-13 at 17:17 +0200, Hans-Bernhard Broeker wrote:

> I'm not --- I still haven't fully given up revitalizing the 16-bit 
> builds yet (I've got DOS16 to link with OW, a third-party linker and 
> some serious modifications...). These 10 percent of extra load could 
> easily kill those.

You're kidding right? Why?! Is there any demand for this at all? or is
it just for fun?

By all means do this if you really want to - but I can't see any
justification for letting this hold back *real* gnuplot development.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Robert H. <en...@no...>]

On Wed, 2005-07-13 at 14:34 -0700, Ethan Merritt wrote:

> Which reminds me... I did some small amount of such cleanup recently.
> You might have a look and see how much of the special-casing of the
> BINARY code is not necessary.

There was some investigation about Mircrowave OS9 support (which is
special cases in some of the data reading code) - I posted a message on
comp.os.os9 newsgroup. The replies I've got (and my impression from
reading other posts on the groups is that)

- if any new version of gnuplot were to be built it would be with gnu
tools, and therefore special cases probably wouldn't be needed (and
certainly not for the same functions)

- nobody is still using gnuplot on that platform (in fact very few
people are using the platform at all - and mostly for extreme legacy
stuff - i.e. I can't see them upgrading anyway)

- the last version of gnuplot to be built was early in the 3.x series
(possibly 3.1)

Therefore I think we can drop any #define OSK that are "in the way" -
and maybe throughout the codebase if somebody feels there is something
to be gained by that.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: terminal API: Intent of multiplot suspend/resume?

[Robert H. <en...@no...>]

On Wed, 2005-07-13 at 15:07 -0700, Ethan Merritt wrote:

> The suspend() and resume() functions are only called if you are
> in interactive mode.  That makes them pretty much worthless,
> so far as I can see.  

I was bitten by this early on when writing my opengl terminal --
whatever the original purpose of these commands doesn't seem to fit well
with whatever it was I was trying to do.

I think I now have it that GL_graphics calls GL_resume and GL_suspend
calls GL_text (yes I know this is odd, but GL_graphics does some stuff
before calling GL_resume that only needs to be done once). This seems to
work for both interactive and scripted operation.

Rob


-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Petr M. <mi...@ph...>]

> But please have a look at the patch for more versatile key placement before 
> doing the mods because I'm guessing it would cause some hunks to fail.

The patch is fine with me. I think it can go to cvs right now.

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Petr M. <mi...@ph...>]

>> I believe the new code is active by default in the CVS version and
>> people have been using it for a year or more.
>
> Do you really have a handle on how much use it has seen?

No number of users, but:
- It is used in Octave image drawings and it works OK.
- I use it for edf files.

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Petr M. <mi...@ph...>]

>> The problem with loadable files is there to install them. Gnuplot supports
>> too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW
>> users do not have any idea about setting environmental variables.
>
> That was the objection raised before.
> Where is the help file kept on these platforms?  I would have thought we
> could put these extra files in the same directory as the help file.

Yes, it is in the same dir as the executable, so your approach will work.

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 13 July 2005 03:07 pm, Daniel J Sebald wrote:
> 
>>>>After that, I'd propose making the BINARY_DATA_FILE permanent too.  
>>>
>>>I am opposed to removing the EXPERIMENTAL warnings on that one.
>>>The binary data file code is still very messy, and having it set off
>>>by conditional flags is the only way anyone will ever be able to find
>>>pieces for cleanup.
>>
>>I believe the new code is active by default in the CVS version and
>>people have been using it for a year or more.
> 
> 
> Do you really have a handle on how much use it has seen?

There are some demo programs that utilize binary.  They all work.  I use binary data for images in Gnuplot (but that is only new code, not old).

> 
> I think it is more fair to say that people have been using the
> non-binary data path of the new code.

Sure.  Is there an alternative?  I mean, the idea is do the best you can initially to find all bugs and anticipate any problems.  Then, if people using the code find bugs you fix them (for free, mind you).

> As to the actual binary
> data path, I've been finding bugs in it even though I don't actually
> use it for anything. I just trip over them while working on other
> code parts, or when I hit compiler warnings.

I missed something then, my bad.

> 
>>Once people are comfortable with the idea of discarding the old bits, it is easy cleanup.  
>>
>>#ifdef BINARY_DATA_FILE
>>  <keep this portion>
>>#else
>>  <all this code gets tossed along with the ifdef's>
>>#endif
> 
> 
> But there is something strange about having that sort of code in the
> first place.  If the BINARY_DATA_FILE code were properly integrated,
> that second code segment would be empty.  The common functionality
> should be factored out and removed from the conditional brackets
> altogether.  Ideally there would be no #else sections to remove.

No.  The thinking was "OK, this is a fairly big change that I'm sure people won't be comfortable with; so I had better keep the old behavior around so that people who thing something is wrong can switch over to the old code and verify if that is or isn't the case."  It's experimental as indicated when configured.  Find a problem?  Turn back on the old code.

Dan

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

On Wednesday 13 July 2005 03:07 pm, Daniel J Sebald wrote:
> >>After that, I'd propose making the BINARY_DATA_FILE permanent too.  
> > 
> > I am opposed to removing the EXPERIMENTAL warnings on that one.
> > The binary data file code is still very messy, and having it set off
> > by conditional flags is the only way anyone will ever be able to find
> > pieces for cleanup.
> 
> I believe the new code is active by default in the CVS version and
> people have been using it for a year or more.

Do you really have a handle on how much use it has seen?

I think it is more fair to say that people have been using the
non-binary data path of the new code. As to the actual binary
data path, I've been finding bugs in it even though I don't actually
use it for anything. I just trip over them while working on other
code parts, or when I hit compiler warnings.

> Once people are comfortable with the idea of discarding the old bits, it is easy cleanup.  
> 
> #ifdef BINARY_DATA_FILE
>   <keep this portion>
> #else
>   <all this code gets tossed along with the ifdef's>
> #endif

But there is something strange about having that sort of code in the
first place.  If the BINARY_DATA_FILE code were properly integrated,
that second code segment would be empty.  The common functionality
should be factored out and removed from the conditional brackets
altogether.  Ideally there would be no #else sections to remove.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

terminal API: Intent of multiplot suspend/resume?

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

While I was trying to use the term->suspend() and term->resume()
API to implement Harald Harders' treatment of front/back text labels
in epslatex, I discovered that it is pretty much useless.

The suspend() and resume() functions are only called if you are
in interactive mode.  That makes them pretty much worthless,
so far as I can see.  

On terminals that actually need use routines (amiga svga pm vgagl),
has mulitplot never worked in scripts or via load commands?

Documentation in term/README is not very enlightening. It says

  TERM_CAN_MULTIPLOT - driver can do multiplot fully-interactively
                       when output is not redirected.

I had never imagined this was meant to imply that a terminal could
*not* multiplot if the output *is* redirected.

Is there any reason we should not correct this oversight, and
call suspend/resume regardless of whether the interactive flag
is set?   

If that would for some reason make one of these old drivers unhappy,
we could add a new terminal flag TERMINAL_ALWAYS_MULTIPLOTS
to indicate that multiplot mode is possible in both interactive
and non-interactive mode.

Alternatively, the terminal drivers themselves could make the
decision whether to ignore suspend() if not in interactive mode.
The caller would not have to guess the drivers preference.

Or more radically, can we remove suspend() and resume() altogether?
The small number of terminals that use them could be modified to
instead implement the same new API call I blocked out for epslatex.
I previously used the name term->sync(), but it could as well be
term->private() or term->miscellaneous or term->layer() or whatever.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 13 July 2005 02:25 pm, Daniel J Sebald wrote:
> 
>>After that, I'd propose making the BINARY_DATA_FILE permanent too.  
>>It would unify the code flow for ASCII, binary, 2D, 3D.  
>>I can put together a patch for that down the road.  
> 
> 
> I am opposed to removing the EXPERIMENTAL warnings on that one.
> The binary data file code is still very messy, and having it set off
> by conditional flags is the only way anyone will ever be able to find
> pieces for cleanup.

What I am proposing is pulling out the mess.  I think what I have done (when the new binary data file is active) is just what you propose.  You suggested a while back that ASCII and binary be kept as separate functions.  I did that, yet retained the same "flow"... similar function calls; in fact, in the new setup the 2D/3D portions of the code don't even know what type of data file the data has come from.  That wasn't the case in the old code; limiting in 2D from what I recall.

In that patch, I've left all the old code for binary exactly as it was so that when BINARY_DATA_FILE is deactivated the code is just as it always was.  That means one would not only remove the BINARY_DATA_FILE flags, but all the extraneous old code.

Also, the "bin_hook.c" will get tossed.  That was only for the purpose of including or excluding the binary code that is compiled into a special test program.  The old routines could be dedicated to that program and not used in gnuplot anymore.

> 
> Which reminds me... I did some small amount of such cleanup recently.
> You might have a look and see how much of the special-casing of the
> BINARY code is not necessary.
> 
> What I really hope to see is gradual cleanup and consolidation of
> the binary and ascii code, to the point that there are hardly any
> special BINARY_DATA_FILE pieces remaining.  At that point removing
> the warning and the conditional coding would make sense.

I believe the new code is active by default in the CVS version and people have been using it for a year or more.  Once people are comfortable with the idea of discarding the old bits, it is easy cleanup.

#ifdef BINARY_DATA_FILE
  <keep this portion>
#else
  <all this code gets tossed along with the ifdef's>
#endif

Dan

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>>> Candidates for being always in gnuplot are:
>>
>>
>>> #define EAM_DATASTRINGS 1
>>> #define EAM_HISTOGRAMS 1
>>> #define GP_MACROS 1
>>> #define GP_STRING_VARS 2
>>> #define GP_FIT_ERRVARS 1
>>> #define PM3D 1
>>
>>
>> On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote:
>>
>>>
[...]
>> In particular PM3D is now so integral to many new features that I
>> think it would make no sense for anyone to upgrade past version 4.0
>> and *not* include PM3D.  Why go out of our way to support a
>> combination of options that doesn't make any sense?
>>
>> So yes, I think the PM3D code should be made unconditional.
> 
> 
> I will do this change within one week if there is no really strong 
> objection.

Do you mean strip out all the PM3D flags?  I'm OK with that.  It does add a little bit, but I think as time goes on it might be condensed slightly through clean up.  Also, Gnuplot doesn't seem to be too bloated compared to other programs.  Plotting a sufficiently large plot will use up more memory than the executable anyway.

But please have a look at the patch for more versatile key placement before doing the mods because I'm guessing it would cause some hunks to fail.

After that, I'd propose making the BINARY_DATA_FILE permanent too.  It would unify the code flow for ASCII, binary, 2D, 3D.  I can put together a patch for that down the road.

Dan

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

On Wednesday 13 July 2005 02:25 pm, Daniel J Sebald wrote:
> 
> After that, I'd propose making the BINARY_DATA_FILE permanent too.  
> It would unify the code flow for ASCII, binary, 2D, 3D.  
> I can put together a patch for that down the road.  

I am opposed to removing the EXPERIMENTAL warnings on that one.
The binary data file code is still very messy, and having it set off
by conditional flags is the only way anyone will ever be able to find
pieces for cleanup.

Which reminds me... I did some small amount of such cleanup recently.
You might have a look and see how much of the special-casing of the
BINARY code is not necessary.

What I really hope to see is gradual cleanup and consolidation of
the binary and ascii code, to the point that there are hardly any
special BINARY_DATA_FILE pieces remaining.  At that point removing
the warning and the conditional coding would make sense.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

On Wednesday 13 July 2005 09:14 am, Petr Mikulik wrote:
> > If you like, I can resurrect the earlier patch pulling the PostScript
> > prolog and character-encoding text blocks out of the driver and make
> > them separately loadable files.
> 
> The problem with loadable files is there to install them. Gnuplot supports 
> too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW 
> users do not have any idea about setting environmental variables.

That was the objection raised before.
Where is the help file kept on these platforms?  I would have thought we
could put these extra files in the same directory as the help file.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Petr M. <mi...@ph...>]

>> Candidates for being always in gnuplot are:
>
>> #define EAM_DATASTRINGS 1
>> #define EAM_HISTOGRAMS 1
>> #define GP_MACROS 1
>> #define GP_STRING_VARS 2
>> #define GP_FIT_ERRVARS 1
>> #define PM3D 1
>
> On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote:
>>
>> I still haven't fully given up revitalizing the 16-bit
>> builds yet (I've got DOS16 to link with OW, a third-party linker and
>> some serious modifications...). These 10 percent of extra load could
>> easily kill those.
>
> I think that effort would be a total and utter waste of your time.
> Anyone runinng 16-bit DOS can just live with version 3.7

I think so too. Those old PC's are not used for image processing anyway, so 
they have no reason to switch to gnuplot >= 4.0.

> I have not looked at GP_FIT_ERRVARS in detail, and don't have an
> opinion on it.  The rest of them should go in IMHO.

We should avoid having too many gnuplot versions depending on ./configure 
options. It's better to on/off these features by some "set ..." switches.

Was there any report of a broken script?

> In particular PM3D is now so integral to many new features that I
> think it would make no sense for anyone to upgrade past version 4.0
> and *not* include PM3D.  Why go out of our way to support a
> combination of options that doesn't make any sense?
>
> So yes, I think the PM3D code should be made unconditional.

I will do this change within one week if there is no really strong 
objection.

> If you like, I can resurrect the earlier patch pulling the PostScript
> prolog and character-encoding text blocks out of the driver and make
> them separately loadable files.  That should gain about half of the
> PM3D size back right there, and it has other benefits unrelated to
> 16-bit support.

The problem with loadable files is there to install them. Gnuplot supports 
too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW 
users do not have any idea about setting environmental variables.

---
PM

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

 Petr Mikulik wrote:
> Candidates for being always in gnuplot are:

> #define EAM_DATASTRINGS 1
> #define EAM_HISTOGRAMS 1
> #define GP_MACROS 1
> #define GP_STRING_VARS 2
> #define GP_FIT_ERRVARS 1
> #define PM3D 1

On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote:
> 
> I still haven't fully given up revitalizing the 16-bit 
> builds yet (I've got DOS16 to link with OW, a third-party linker and 
> some serious modifications...). These 10 percent of extra load could 
> easily kill those.

I think that effort would be a total and utter waste of your time.
Anyone runinng 16-bit DOS can just live with version 3.7

Surely the effort is better spent supporting current operating
environments than it is retro-fitting to obsolete ones.

I have not looked at GP_FIT_ERRVARS in detail, and don't have an
opinion on it.  The rest of them should go in IMHO.

In particular PM3D is now so integral to many new features that I
think it would make no sense for anyone to upgrade past version 4.0
and *not* include PM3D.  Why go out of our way to support a
combination of options that doesn't make any sense?

So yes, I think the PM3D code should be made unconditional.

If you like, I can resurrect the earlier patch pulling the PostScript
prolog and character-encoding text blocks out of the driver and make
them separately loadable files.  That should gain about half of the
PM3D size back right there, and it has other benefits unrelated to
16-bit support.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> Candidates for being always in gnuplot are:

> #define EAM_DATASTRINGS 1
> #define EAM_HISTOGRAMS 1
> #define GP_MACROS 1
> #define GP_STRING_VARS 2
> #define GP_FIT_ERRVARS 1
> 
> They do not change "too many" places of the code.

Careful with this conclusion, please.  Changing few or many places of 
the code is only one side of the issue.  The other is possible 
incompatibility with existing user scripts.  That's e.g. why I made 
FIT_ERRVARS optional in the first place: it intrudes on the namespace 
for user-defined variables by creating new ones previous versions of 
gnuplot didn't touch.  Now that there's also "set fit noerrorvariables", 
this is no longer an issue, so this option can go away.

By the same reasoning, I'm quite sure it would be premature to make the 
string variables and macros stuff unconditional right now.  It would at 
least require a run-time switch that turns off all options that may 
break existing scripts, before the compile-time option can be disposed of.

> Next candidate is
> #define PM3D 1
> It appears in many places of the code, but anyway, I'm in favor to 
> remove this #define as well.

I'm not --- I still haven't fully given up revitalizing the 16-bit 
builds yet (I've got DOS16 to link with OW, a third-party linker and 
some serious modifications...). These 10 percent of extra load could 
easily kill those.

What might make more sense it so collect several existing options into a 
single new one.  I.e. PM3D could be subsumbed under the ancient "small 
gnuplot" option, #define LITE.  This won't make the source code any 
prettier, but reduce the complexity of the build process (less 
--enable/--disable switches in configure).

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Petr M. <mi...@ph...>]

>  904447    83428    34048  1021923  gnuplot_nostrings      -0.8%
>  893205    83188    34144  1010537  gnuplot_noimage        -2%
>  817009    78380    30912   926301  gnuplot_nopm3d        -10%

Candidates for being always in gnuplot are:
#define EAM_DATASTRINGS 1
#define EAM_HISTOGRAMS 1
#define GP_MACROS 1
#define GP_STRING_VARS 2
#define GP_FIT_ERRVARS 1

They do not change "too many" places of the code.

Next candidate is
#define PM3D 1
It appears in many places of the code, but anyway, I'm in favor to remove 
this #define as well.

Shall we do it?

---
PM