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

unlimited windows patch

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

Folks,

I've updated some patches on SourceForge (with much of Petr's help)
that I'd like people to test and consider for integration into Gnuplot.  One
is a moderate length patch for unlimited X11 windows.  The other is the
longer patch for image and binary data file support.  I will briefly discuss
the two in separate emails...

Patch 774822 Unlimited plot windows for X11 terminals.

linked_list_103003.diff

The unlimited X11 windows patch consists of the one file listed above.
The strategy here was to take the large table containing information
about the window and add a few pointers for a doubly-linked list and
an identifier (the window #).  Then there is a large chunk of code to
support the linked list.  It actually is fairly straightforward with a few
short routines like "Add_To_List", "Remove_From_List", etc.  The only
tricky part was robustly cleaning up plots that are deleted via the OS,
e.g., pressing the close button of the window.  That requires a queue
for deleting plots because otherwise the OS error handler could delete
a plot that gnuplot_x11 is currently accessing.  In any case, it has been
very robust and I can't recall ever seeing gnuplot_x11 go defunct with
this strategy.  I've also run this through Octave to generate a couple
hundred plots on the screen and it works fine.

So, in summary, the structure of 16 plots has been replaced by a linked
list.  Petr has tested the patch and also gave some good suggestions
for additions.  Also, the issue of closing a window has come up on the
list, so I added a "close", although there may be an issue with the
different pipes.  (Try it, see if it suitable.)  The X11_options() routine
has been cleaned up to do reasonable sanity checks and to not change
anything unless a valid "set term" command is entered.  This is more
in line with the manner in which "plot" and "splot" behave.

There is documentation in Gnuplot, but some examples are

set term x11 145 title "Hello World"
plot sin(x)
set term x11 close

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: show palette palette <n> savergb

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

On Thursday 30 October 2003 01:07, Hans-Bernhard Broeker wrote:
> On Thu, 30 Oct 2003, Petr Mikulik wrote:
>
> And if you really suspect confusion, you could still use a different
> name than 'palette' to distinguish it from 'show palette'.  Say 'save
> rgbpalette'.

I like that option best of the ones mentioned so far.
However, logically if you can
    'save rgbpalette <filename>'
you would expect to be able to restore it later using
    'load <filename>'
This suggests to me that the output of the save command
should be formatted such that it is acceptable to 'load'.

Also, would it not be equally (or even more) useful to have a
    'test rgbpalette'
that displays in the plot window an indexed array of the
palette colors?

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

Re: show palette palette <n> savergb

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

On Thu, 30 Oct 2003, Petr Mikulik wrote:

> > If you're going to 'save' it to a file, wouldn't the most sensible place
> > be a sub-option of the 'save' command?  So IMHO it should be something
> > like
> >
> > 	save palette '<filename>' ncolors <n>
>
> That could confuse user whether it is saving "set palette" or the discrete
> r,g,b values of the current palette.

I strongly doubt it'll be less confusing than breaking the existing
tradition that 'show' shows, and 'save' writes to file.

And if you really suspect confusion, you could still use a different name
than 'palette' to distinguish it from 'show palette'.  Say 'save
rgbpalette'.

> I find it more logic to be able to save
> the rgb table to a file at the same place it can write it to screen.

But the problem is you're planning to write to screen something different
than what you would save to file, anyway.  If you want the actual
'show' output in a file, there's always 'set print' for that, right?

> > > show palette palette <n> {savergb {<scale> {int}} 'filename'}
> >
> > The doubling of 'palette' in there feels wrong, to me.
>
> It's OK -- there are more "show palette" print options, see "help palette".

Sure --- but that still doesn't make 'palette' a good sub-option name. If
you worry about confusing the user, this should have you pretty worried,
IMHO.

> > I seriously doubt that all that scaling is worth the hassle.  Either write
> > out floats, or ints scaled up to the usual 8-bit range.
>
> I think it is worth it: some apps loading rgb palettes require integer range
> 0..255, others float range 0..1.

Exactly --- and those are the *only* ones I've ever seen anybody use.
Which means there's hardly any point offering a selection much more
general than that.  A simple option {int | float} would be sufficient.
For plotting the colour profiles from gnuplot, you wouldn't need it all,
of course...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: show palette palette <n> savergb

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

> > Currently gnuplot can print colour palette table on screen by 'show
> > palette palette <n>'. I made a patch which can save it to a file, just 3
> > columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> > The syntax proposed is below. Does somebody propose any other addition?
> > (E.g. how to save lut files?)
>
> If you're going to 'save' it to a file, wouldn't the most sensible place
> be a sub-option of the 'save' command?  So IMHO it should be something
> like
>
> 	save palette '<filename>' ncolors <n>

That could confuse user whether it is saving "set palette" or the discrete
r,g,b values of the current palette. I find it more logic to be able to save
the rgb table to a file at the same place it can write it to screen.

> > show palette palette <n> {savergb {<scale> {int}} 'filename'}
>
> The doubling of 'palette' in there feels wrong, to me.

It's OK -- there are more "show palette" print options, see "help palette".

> I seriously doubt that all that scaling is worth the hassle.  Either write
> out floats, or ints scaled up to the usual 8-bit range.

I think it is worth it: some apps loading rgb palettes require integer range
0..255, others float range 0..1.

---
Petr Mikulik

Re: show palette palette <n> savergb

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

On Wed, 29 Oct 2003, Petr Mikulik wrote:

> Currently gnuplot can print colour palette table on screen by 'show
> palette palette <n>'. I made a patch which can save it to a file, just 3
> columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> The syntax proposed is below. Does somebody propose any other addition?
> (E.g. how to save lut files?)

If you're going to 'save' it to a file, wouldn't the most sensible place
be a sub-option of the 'save' command?  So IMHO it should be something
like

	save palette '<filename>' ncolors <n>

> show palette palette <n> {savergb {<scale> {int}} 'filename'}
[...]

The doubling of 'palette' in there feels wrong, to me.

I seriously doubt that all that scaling is worth the hassle.  Either write
out floats, or ints scaled up to the usual 8-bit range.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

show palette palette <n> savergb

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

Currently gnuplot can print colour palette table on screen by 'show palette
palette <n>'. I made a patch which can save it to a file, just 3 columns of
r,g,b, to be easily plotted by gnuplot as colour profiles. The syntax
proposed is below. Does somebody propose any other addition? (E.g. how to
save lut files?)


show palette palette <n> {savergb {<scale> {int}} 'filename'}

`show palette palette <n>` shows RGB triplets for the current settings and a
palette having <n> discrete colors. This table can be saved into a
`filename` (accepting also '-' and '|pipe_command'), optionally scaled by
'<scale>' and rounded to integer values.


---
Petr Mikulik

Re: again: x11 is eating one character from stdin pipe

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

> So now we have a problem:  octave scripts only work with the call
> to setvbuf(), while awk scripts only work without it.  Octave is likely the
> more important application, and anyway people have been using the
> setvbuf() version for almost 2 years now.  So we should leave the
> default the way it is.

I.e., there are some applications which call setvbuf(gp,NULL,_IOLBF,0); or
do fflush(gp) after each command, and those which don't. Fortunately,
interactive programs should not be affected unless they "set mouse"
explicitly. However, this applies only to X11 terminal.


I think it would be worth to add some text about the necessity of using
	setvbuf(f,NULL,_IOLBF,0); /* set unbuffered output */
into "help x11_mouse".


> However, in case someone does want to use an awk script,
> perhaps there could be an option
> 	set mouse [no]buffered
> The default would be nobuffered, implemented by the existing call
> to setvbuf(). Specifying 'set mouse buffered' instead would bypass
> the call to setvbuf() and allow awk to work.
>
> Would that be an acceptable work-around?

Isn't this just X11 specific? Does it set both stdin/stdout to application
and to terminal to non-buffer, or only for one end?


Maybe, in the next fool-proof reincarnation of X11 terminal, it would be
worth to do it like in gnuplot for OS/2 -- named pipe terminal->gnuplot,
with gnuplot having a thread waiting for pipe events (or semaphores +
shared memory).

---
Petr Mikulik

Re: demos

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

On Tuesday 21 October 2003 03:21, Petr Mikulik wrote:
>
> There are still many *.dem which use "set no" instead of "unset", and
> "set data/func style" instead of "set style data/func". Could somebody
> have a look, update and test *.dem for the new 3.8 syntax?

Done.
I used:
sed -e 's/unset key/set key off/' \
       -e 's/set no/unset /' \
       -e 's/^set key *$/set key on/' \
       -e 's/set data style/set style data/' \
       -e 's/set function style/set style function/'
--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: again: x11 is eating one character from stdin pipe

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

Ethan Merritt wrote:

>Daniel J Sebald <dan...@ie...> wrote>
>  
>
>>That is some strange code, however.  
>>    
>>
>
>I will choose to take that as a compliment :-)
>

Why, of course I meant it that way.  :-)

>>Maybe a handshaking scheme is needed.  Perhaps x11.trm
>>    
>>
>
>Handshaking didn't help.
>

Yes, sometimes it just pushes the problem to some other
obscure location.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: again: x11 is eating one character from stdin pipe

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

On Monday 27 October 2003 07:04, Petr Mikulik wrote:
> I'd a look to the patch of June 21 which made the break; even though I
> don't understand it, I've found that commenting out the
> "X11_waitforinput();" call does not produce the forgetting-pipe error:
>
>    /* Force default font at start of plot */
> #ifdef USE_MOUSE
>     /* EAM June 2003 - Flush the set font command through the pipe */
>     /* to gnuplot_x11, then wait for it to return the resulting    */
>     /* font size information (v_char and h_char).                  */
>     if (!default_font_size_known) {
>         X11_set_default_font();
>         FFLUSH();
>         X11_waitforinput();
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         default_font_size_known =3D TRUE;
>     }
> #else
>     X11_set_default_font();
> #endif
>     X11_set_font("");
> }
>
>
> Does that command have to be there?

Well yes.  That is the whole point of the excercise.
The idea is to give X11 a chance to initialize the window data
structure and send back sizing and font information before
proceeding.  That way the plot can be laid out correctly.

Daniel J Sebald <dan...@ie...> wrote>
>That is some strange code, however. =20

I will choose to take that as a compliment :-)

>Does anyone know what the basic concept is here?

See above.=20

> Maybe a handshaking scheme is needed.  Perhaps x11.trm

Handshaking didn't help.  What was needed was an interlock.
I added that to CVS on 23 Oct.  You should not (I hope!!) be
seeing problems with Octave any more.   If you are then=20
please send me another sample script that generates the
error.

As I previously noted, there is a separate problem with
buffered/unbuffered input streams.   Awk is not happy=20
with the unbuffered stream.  I don't know why, and I don't
know what other scripting environments might suffer from
the same problem.

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

Re: again: x11 is eating one character from stdin pipe

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

Petr Mikulik wrote:

>I'd a look to the patch of June 21 which made the break; even though I don't
>understand it, I've found that commenting out the "X11_waitforinput();" call
>does not produce the forgetting-pipe error:
>
>
>   /* Force default font at start of plot */
>#ifdef USE_MOUSE
>    /* EAM June 2003 - Flush the set font command through the pipe */
>    /* to gnuplot_x11, then wait for it to return the resulting    */
>    /* font size information (v_char and h_char).                  */
>    if (!default_font_size_known) {
>        X11_set_default_font();
>        FFLUSH();
>        X11_waitforinput();
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        default_font_size_known = TRUE;
>    }
>#else
>    X11_set_default_font();
>#endif
>    X11_set_font("");
>}
>
>
>Does that command have to be there?
>

My guess would be "yes" if the size of the font is to be correct
when used in Gnuplot formatting.

That is some strange code, however.  Does anyone know what
the basic concept is here?  Is this using a single pipe to have
traffic in both directions?  If so, I might speculate that x11.trm
is sending information through the pipe then looking to get
something back perhaps grabbing characters that it just sent
into the pipe because gplt_x11 hasn't yet pulled them out.(????)

Maybe a handshaking scheme is needed.  Perhaps x11.trm
should send a command through the pipe.  The gplt_x11
font command doesn't send stuff immediately but waits for
another special character to be sent.  On the other end,
x11.trm first sits waiting for the pipe to be completely empty.
Then it knows that gplt_x11 has received the font command
and is waiting to send something back.  x11.trm then sends
the special character.  But still that doesn't seem fool proof,
unless there is some way for x11.trm to know the pipe has
grown bigger than the one character it sent, say.  That might
be a way of knowing that what is in the pipe came from
gplt_x11 and not its own self.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: again: x11 is eating one character from stdin pipe

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

> > > With the setvbuf() in place, running the awk script causes the
> > > first 120+ plot commands to be lost in transit!!!!!!
> > >
> > > Without the setvbuf() command, only a single character is
> > > dropped - the first one following the first plot command.
> >
> > I've tried it with Octave, but there is no change with or without
> > setvbuf. Gnuplot mostly looses the first character.
>
> Last night I built Octave 2.1.50 so that I could test this
> myself. What I found is that the Octave problem and the awk
> problem are not the same.
>
> The Octave problem can, I believe, be solved with the first
> patch attached below (ipc_lock.patch).  This one causes
> X11_waitforinput() to refuse to read any more characters
> using getc(stdin) while it is waiting for a response from the
> mousing pipe.
>
> This still leaves awk losing many lines of input, which is
> fixed only if I also remove the call to setvbuf() as in the
> second patch below (setvbuf.patch).
>
> Applying these two patches makes both the awk and octave
> test scripts run on my usual desktop machine under linux.
>
> I've tested both with gnu libreadline and with the builtin
> readline. But I have not yet tested on other machines, and
> I would not like to commit either patch to CVS without more
> extensive testing.
>
> In particular I am concerned that if the response from the
> mouse pipe is lost altogether, then the first patch will cause
> gnuplot will hang.  I need to add some sort of timeout or
> upper limit of attempts to read from the mouse pipe.


I'd a look to the patch of June 21 which made the break; even though I don't
understand it, I've found that commenting out the "X11_waitforinput();" call
does not produce the forgetting-pipe error:


   /* Force default font at start of plot */
#ifdef USE_MOUSE
    /* EAM June 2003 - Flush the set font command through the pipe */
    /* to gnuplot_x11, then wait for it to return the resulting    */
    /* font size information (v_char and h_char).                  */
    if (!default_font_size_known) {
        X11_set_default_font();
        FFLUSH();
        X11_waitforinput();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        default_font_size_known = TRUE;
    }
#else
    X11_set_default_font();
#endif
    X11_set_font("");
}


Does that command have to be there?

Petr

Re: x11.trm terminal options

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

Ethan A Merritt wrote:

>On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote:
>  
>
>>Point 1 is simply a matter of breaking
>>out of a loop when a number change code 'N' is seen
>>by Gnuplot.  It is then possible to resize all windows
>>after a "set term x11".
>>    
>>
>
>OK. That sounds like a pure bug-fix.  Did you check the
>rest of that loop to see if all the other options have proper
>exit code also?
>

There are one or two others, but they are ones for which
following commands (always sent by gnuplo)t kick it out of
the loop.  For example, the 'G' always has other commands
immediately following it.  The 'N' was the only one where
a single command would be issued.

But if I remember correctly, just changing the 'N' case so
that it kicks out of the loop for the current CVS raises a
different problem, one address with the mods I made.

>>2c below I've ruled out as an alternative.  It is confusing
>>when the windows behave that way.  This is accomplished
>>by doing an X11_init() in the X11_options() of x11.trm.
>>    
>>
>
>Are you saying this is only needed for (c)?  Or are you
>proposing to do this for (a) also?
>
>  
>
>>[But really, the proper thing to do would be to check the
>>sanity of the "plot->window" variable before using it.
>>    
>>
>
>Or maybe to set this to point at a dummy structure when
>a window is destroyed, instead of setting it to NULL.
>
>  
>
>>The alternatives 2a and 2b are achieved by a simple
>>mod of:
>>    
>>
>
>(b) is to pop up a blank window as soon as the terminal
>type is set, right?   I do not like that idea at all.
>

Based upon the feedback from you and Hans, the 2a/b/c cases
now boil down to "no window appear until when something is
plotted."

>I'd like to have a look at the proposed code changes
>before offering a final opinion.
>

No problem.  I'll make the patch available in a couple days after
Petr and I agree it behaves as designed.  I think you'll like it.

Dan

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 15:22, Daniel J Sebald wrote:
>  
>
>>As for the issue with different processes, I'm wondering
>>how this situation comes about.
>>    
>>
>
>Minimal example from command line:
>
>set term x11 1 persist
>plot something()
>set term x11 reset
>set term x11 2 persist
>plot somthingelse()
>set term x11 1 close
>^^^^^^^^^^^ will fail
>
>window 1 is still on the screen and still responding to
>mouse events, but is being controlled by a different
>gnuplot_x11 process than window 2.
>

Oh yeah, persist.  I forgot about that.  Well, that is sort of above
and beyond a normal driver anyway...

>In practice I would expect this to be more of an 
>issue with scripts and automated drivers.
>

but yes, I guess for scripts the persist finds a use, e.g., a script
that launches gnuplot, plots, then exits gnuplot but wants to
retain the windows.

>I don't know exactly what goes on inside Octave,
>but if it ever sends a 'set term reset' at all, I should
>think this could happen fairly easily.
>

I don't think the issue is with 'set term reset' unless Octave puts
Gnuplot into persist mode.

>From looking at the code, I also think it can happen
>if a non-tty process switches from nomouse to mouse
>within a session.  Opening a new X11 term with nomouse
>and non-tty causes it to shut down the back_ipc,
>and then the next open _with_ a mouse starts a
>whole new gnuplot_x11 so it can get a mousing
>channel.  But I don't have a real-world example of
>that.
>

Hmm... that seems like something that would be fixable.

>>So if there are multiple pipes each
>>one running a version of gplt_x11, what would be the
>>sense of having built a multiwindow gplt_x11 in the first
>>place?
>>    
>>
>
>Good question.  I wouldn't have done it this way.
>
>  
>
>> x11.trm could have handled the various windows
>>on its own.  
>>    
>>
>
>Yup.  And I think that would be better. 
>But it would be a lot of work to change over.
>

Of course, gplt_x11.c would serve as a good basis.  The storing
of "commands" sent across the pipe as code words could be
replaced by the storing of gnuplot internal commands.  In the long
run, my guess is that the two manners of storing a plot boil down
to roughly the same amount of memory usage per plot.

But I'm not totally put off by the gplt_x11 scheme of things.  There
are only a couple of complaints for me:  One, the use of ASCII to store
all the information bloats memory.  Two, there is no way to send what
is appearing in an X11 window to a printer or file.  That is, say someone
generates ten plots on the screen and wants to print any one of them.
[I tend to avoid this sort of development approach, opting to do almost
everything from script files so I can repeat what I did.]  The person
would need to retrace all his or her commands to get back to the
plot they want and then use the PostScript driver.

So, in some sense it would be nice have a system where instead of
storing the code letter commands, the terminal function calls are
saved and can be directed to PostScript.  But, as you pointed out
this might be a lot of work because Gnuplot does different things
in a few spots based upon the type of terminal.  An alternative might
be for gplt_x11 to have some mode where it can generate PostScript
from its code letter commands.

>I'm hoping that someone will write a multi-window
>Qt driver and we can just switch over to using that instead
>of x11.trm
>

I'm not familiar with Qt.  What part of the system commands
for describing the plot would be stored?  Internal Gnuplot?
Gnuplot terminal commands?  

Dan

Re: x11.trm terminal options

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

On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote:
> Point 1 is simply a matter of breaking
> out of a loop when a number change code 'N' is seen
> by Gnuplot.  It is then possible to resize all windows
> after a "set term x11".

OK. That sounds like a pure bug-fix.  Did you check the
rest of that loop to see if all the other options have proper
exit code also?

> 2c below I've ruled out as an alternative.  It is confusing
> when the windows behave that way.  This is accomplished
> by doing an X11_init() in the X11_options() of x11.trm.

Are you saying this is only needed for (c)?  Or are you
proposing to do this for (a) also?

> [But really, the proper thing to do would be to check the
> sanity of the "plot->window" variable before using it.

Or maybe to set this to point at a dummy structure when
a window is destroyed, instead of setting it to NULL.

> The alternatives 2a and 2b are achieved by a simple
> mod of:

(b) is to pop up a blank window as soon as the terminal
type is set, right?   I do not like that idea at all.

I'd like to have a look at the proposed code changes
before offering a final opinion.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: x11.trm terminal options

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

I believe I have a few simple mods to address points
1 and 2 below.  Point 1 is simply a matter of breaking
out of a loop when a number change code 'N' is seen
by Gnuplot.  It is then possible to resize all windows
after a "set term x11".

2c below I've ruled out as an alternative.  It is confusing
when the windows behave that way.  This is accomplished
by doing an X11_init() in the X11_options() of x11.trm.
The ramification of doing this is that the X11 window
must be created even if just a "set term x11" is called.
Why?  Looking through the gplt_x11.c code there are
many many places where a pointer in the plot table
called "plot->window" of type Window is used without
testing first if it is valid.  Rather than touch up all these
occurrences, I've just made sure the windows are
initialized whenever a new window number is used in some way.
[But really, the proper thing to do would be to check the
sanity of the "plot->window" variable before using it.
The reason is that if the plot being drawn to is destroyed
in some way and "plot->window" gets set back to
zero, gplt_x11 will not crash.  E.g., if a slow graph is
drawing and the "destroy" button is pressed.]

The alternatives 2a and 2b are achieved by a simple
mod of:

#define DISPLAY_WINDOW_UPON_CREATION 0
#if DISPLAY_WINDOW_UPON_CREATION
    XMapWindow(dpy, plot->window);
#endif

inside the pr_window() routine of gplt_x11.c.  If the defined
value is 0 the window is not made visible until something
is actually plotted to it.  If the defined value is 1, the empty
window is displayed upon creation, i.e., a "set term x11"

As for issue 3, I may go through and make sure some
reasonable tests for duplicated options is done.

Dan



Daniel J Sebald wrote:

> My original message must have been lost by SF, but I
> don't think it needs resending to clarify the issue.  The
> points up to this point are
>
> 1)  I think the problem of x11 windows getting stuck
> when only a "set term x11 #" should be fixed at some
> point.  Nobody needs to change this, I can do so with
> Petr's help.  But, feel free to comment.
>
> 2)  If you think the above problem should be modified,
> do you feel that
>
> a) graphics windows should not appear until something
> is actually plotted to them
>
> b) graphics windows should _always_ appear when
> "set term x11 ..." is entered
>
> c) the first x11 window should not appear until something
> is actually plotted, but after that "set term x11 ..." will
> cause a new blank window to appear.
>
> With regard to 2, note that if one types "set output 'name'"
> followed by no plot commands, but then "set output", the
> file 'name' will be created.  Is there an analogy here between
> a file and a window?
>
> The next point is
>
> 3)  Looking at the X11_options() in x11.trm it is very similar
> to other parsing/interpretting schemes, however it doesn't have
> the many checks for repeated entry, valid entry, etc.  Some
> commands are sent to gplt_x11 even before the end of parsing.
> So even if there is something bogus in the "set term x11"
> command, a portion of the command could have been processed.
> Should it do that?  Or should it wait until it is known that the whole
> command is valid?  For example,
>
> "set term x11 3 "TimesFont""
>
> will show an error message because "font" is missing before
> the font name, but it will in fact change the x11 window to 3.
>
> If you feel point 2b above should be the case, then
>
> "set term x11 1 2 noraise"
>
> where someone mistypes the 12 will cause window 1 and window
> 2 to show on the desktop.  In fact, as it currently is
>
> "set term x11 1 2 noraise reset 3 4 raise"
>
> is fine by Gnuplot.  Should there be some checks to prevent
> this kind of thing?
>
> Dan
>
>
> Daniel J Sebald wrote:
>
>>
>>
>> Daniel J Sebald wrote:
>>
>>> In other words, from a fresh invocation
>>>
>>> set term x11 3
>>>
>>> creates no window. But
>>>
>>> plot sin(x)
>>> set term x11 3
>>>
>>> creates _two_ windows. 
>>
>>
>>
>>
>> You are probably wondering what I mean because the
>> current version doesn't do this, as I just realized. What
>> I am speaking of the system's behavior after an alteration
>> to the 'N' option for changing the X11 window via
>>
>> "set term x11 5"
>>
>> [If you type the following, you'll notice you are unable
>> to resize the first plot... that should be fixed at some
>> point.
>>
>> plot sin(x)
>> set term x11 4
>> {try resizing first plot}]
>>
>> I guess the question boils down to should the command
>>
>> set term x11 7
>>
>> cause an empty X11 window to appear on the desktop
>> if it didn't already exist? Or should it be until after something
>> is actually plotted to the window that it appears on the
>> desktop?
>>
>> Dan
>>
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/





-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Hans-Bernhard Broeker wrote:

>On Thu, 23 Oct 2003, Daniel J Sebald wrote:
>
>[...]
>  
>
>>2)  If you think the above problem should be modified,
>>do you feel that
>>
>>a) graphics windows should not appear until something
>> is actually plotted to them
>>    
>>
>
>Yes.  A gnuplot X11 graph window serves no purpose whatsoever until a
>graph is plotted into it, so there's no point displaying it until that
>point in time.
>

OK.  Seems agreement is emerging on that.  So, gplt_x11 will
create the window in memory (because of all the plot->window
references) but not display it until something is plotted.  An
alternative can be investigated later, e.g.,  waiting until 'G'
(prepare plot) is sent to do the actual individual plot update.

>>With regard to 2, note that if one types "set output 'name'"
>>followed by no plot commands, but then "set output", the
>>file 'name' will be created.  Is there an analogy here between
>>a file and a window?
>>    
>>
>
>Not really.  Arguably, that behaviour of 'set output' is wrong itself.
>

I will check if that can be modified easily.  It may not
be as entwined as gplt_x11.c.

>>3)  Looking at the X11_options() in x11.trm it is very similar
>>to other parsing/interpretting schemes, however it doesn't have
>>the many checks for repeated entry, valid entry, etc.  Some
>>commands are sent to gplt_x11 even before the end of parsing.
>>    
>>
>
>That's a bug, then.  But AFAICS, the only command sent to gplt_x11.c
>before parsing of the options is finished is an update of the window
>number.
>  
>

But why even update that?  How about the precedence idea
of waiting until the line is verified as valid, then if "reset", reset;
if "number", number; the rest?  That way
"set term x11 reset 19 noraise" is the same as
"set term x11 noraise 19 reset".  Also, "reset" should set the
number back to 0, unless a number is also given.  This is a
cleaner and easier way of doing things I think.  Should take
ten minutes.

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 14:01, Daniel J Sebald wrote:
>  
>
>>Ethan Merritt wrote>
>>    
>>
>>>I did try to add that feature a while ago, but it turned out to
>>>be harder than it sounded at first blush.  So it remains on the
>>>list of things that would be nice but are non-trivial.
>>>      
>>>
>>It did take a while to figure out exactly where to
>>put the code, but after that not bad.  From gplt_x11's
>>perspective it would be one line of code to close
>>the window in question.
>>    
>>
>
>You are missing the hard part.  The gplt_x11
>process you currently have a pipe to may or may not
>be the same process that opened the window you
>want to close.  How do you communicate with the
>original gnuplot_x11 process to tell it to close the
>window?
>
>Of course it's possible. You could keep a list of old
>pipe descriptors, being careful of course never to
>close any of them.  But it's non-trivial.
>
>Or you could just give up and not handle this case,
>but it seems a pity to do a half-baked job.
>

Well, I've programmed a simple close statement and it works
fine over a single pipe, i.e., single instance of gplt_x11.  On the
x11.trm side of things it is

    if (set_number && !set_close && X11_ipc) {
        fprintf(X11_ipc, "N%d\n", X11_plot_number);
        fflush(X11_ipc);
    } else if (set_close && X11_ipc) {
        fprintf(X11_ipc, (set_number ? "C%d\n" : "C\n"), X11_plot_number);
        fflush(X11_ipc);
    }

[Any objection to using the conditional inside the fprintf
in that way?  I think the argument is just ignored if
set_number is not true.]

As for the issue with different processes, I'm wondering
how this situation comes about.  That would mean the
user is opening different pipes intentionally.  (Let's
rule out the accidental destroying of the pipe and a
new one being created...)  So if there are multiple pipes each
one running a version of gplt_x11, what would be the
sense of having built a multiwindow gplt_x11 in the first
place?  x11.trm could have handled the various windows
on its own.  Also, if this is an issue with "close", it is also
an issue with the current "set term x11 #" because that
could be other pipes as well.

 From gplt_x11's side of things, everything is fine, I believe.
I'd say it is worth having because in most situations it will
work as expected.  So instead of half-baked, it's
nine-tenths-baked.  :)

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>>#if NOT_PROCESS_IF_DUPLICATION
>>
>Let's not proliferate conditional code.  Go for one or the
>other (error or warning).
>

I'd vote for error then simply because that is
the way "plot" and "splot" behave.  Nothing
is done if you don't have valid syntax.

>>So it works fine.  But I recall something now.  I believe there
>>was a discussion a while back about the ability to close a
>>single X11 graph from the command line.  So perhaps if both
>>a "reset" and a number appear in the options, only the plot
>>associated with that number could be closed.  Right now it
>>will reset the whole thing (i.e., close all windows) and then
>>switch to plot number.  How does that sound?
>>    
>>
>
>I think that should be a separate command.  "reset" and
>"close" do not mean the same thing to me.
>

So you would want a syntax

set term x11 close 5

(or set term x11 5 close is the equivalent)

?  That seems just fine to me and it makes
sense too.  It is just adding one more case
in the case statement.  Easy.

>I did try to add that feature a while ago, but it turned out to
>be harder than it sounded at first blush.  So it remains on the
>list of things that would be nice but are non-trivial.
>

It did take a while to figure out exactly where to
put the code, but after that not bad.  From gplt_x11's
perspective it would be one line of code to close
the window in question.  That would effectively
wipe out any attributes to that window.  The next
time the user plots to that window, the window's
attributes will have been reset.  I could add a code
word 'C' or 'c' (not used, surprisingly) inside
gplt_x11.c.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 12:06, Daniel J Sebald wrote:
>  
>
>>I've looked at the code in term.c regarding opening the file.
>>It looks like the terminal initialization is very safely done with
>>appropriate checks of a variable "term_initialised".  I'm
>>wondering if the actual "fopen()" can't be held off until the
>>function "term_start_plot()".
>>    
>>
>
>Apparently you are not the first one to think so.  The comment
>in term_init (term.c line 406) reads:
>        /* this is nasty - we cannot just term_set_output(outstr)
>         * since term_set_output will first free outstr and we
>         * end up with an invalid pointer. I think I would
>         * prefer to defer opening output file until first plot.
>         */
>

Well, I'm going to leave what to do (if anything) up to you.
The end of this comment, however... isn't "term_start_plot()"
called upon first plot?


>>and in graph3d.c at the start of the "do_plot3d()" routine is
>>
>>    term_start_plot();
>>[Why there isn't a term_init() there also, I don't know.]
>>    
>>
>
>The first thing term_start_plot() does is call term_init().
>So it isn't really necessary in graphics.c at all.
>

Ah, I see.

>>So, it would mean keeping track of the output file name using
>>a character pointer and realloc() and keeping track of the
>>binary/ascii file type.  In term_start_plot(), check if the file
>>name is non-NULL, and if so open the file and free()
>>the memory for the name and set the pointer back to NULL.
>>
>>Does it seem like that would work?
>>    
>>
>
>It could be made to work, but I see several problems.  
>
>The first is that if the output file is illegal it makes far more sense
>to get that error message immediately from the 'set output' command.
>If you defer trying to open the file until later, the error message
>becomes decoupled from the command that caused it.
>

I agree, but I'm not sure that is a major transgression.
If Gnuplot were to instead display a message at the
time of attempted plotting "can't open <filename>", that
is just as good I think.  Say for example there is an
existing file of the name specified but it is write protected.
The user then deletes the file from the OS.  They wouldn't
need to retype 'set output "XYZ"', s/he could just reissue
the plot command.

>Also, remember that some terminal types can put multiple plots
>into a single file, while others cannot.  I would have
>to delve into the code to see if moving the file open to 
>term_start_plot() would trip over that difference or not.
>

I think the closing of the file would remain exactly the
way it is.  When "set output" is called it should be closed.
No changes there.

The strategy I would argue for in "term_start_plot()" is if
there is a valid output file string then attempt opening.
If there is a valid output string and gpoutfile is currently
valid, close that gpoutfile before attempting to open.
Only when the open is successful should gpoutfile
be set and the string cleared.  If not successful at
opening then do not clear the file name.  That way if
the user tries to plot time and again, the same message of
"can't open XYZ" will appear.

If you think the behavior above is preferred, then I would
say remove any opening of a file from set_term_output()
and things would naturally fall into place.  In other words,
the only thing that set_term_output() can do is modify the
file output string or close an open file.  (It should always
close an open file, even if the file name is the same as
the file name that was given previously.)

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

On Friday 24 October 2003 12:06, Daniel J Sebald wrote:

> I've added the necessary checks for duplicate entry.  At
> the end is a #define switch:
>
>     if (duplication) {
> #if NOT_PROCESS_IF_DUPLICATION
>         int_error(c_token-1, "duplicated or contradicting arguments in
> X11 term options");
> #else
>         if (!shown_warning)
>             int_warn(c_token-1, "duplicated or contradicting arguments
> in X11 term options");
>         shown_warning =3D TRUE;
> #endif
>     }

Let's not proliferate conditional code.  Go for one or the
other (error or warning).

> So it works fine.  But I recall something now.  I believe there
> was a discussion a while back about the ability to close a
> single X11 graph from the command line.  So perhaps if both
> a "reset" and a number appear in the options, only the plot
> associated with that number could be closed.  Right now it
> will reset the whole thing (i.e., close all windows) and then
> switch to plot number.  How does that sound?

I think that should be a separate command.  "reset" and
"close" do not mean the same thing to me.

I did try to add that feature a while ago, but it turned out to
be harder than it sounded at first blush.  So it remains on the
list of things that would be nice but are non-trivial.



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

Re: x11.trm terminal options

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

On Friday 24 October 2003 12:06, Daniel J Sebald wrote:
> I've looked at the code in term.c regarding opening the file.
> It looks like the terminal initialization is very safely done with
> appropriate checks of a variable "term_initialised".  I'm
> wondering if the actual "fopen()" can't be held off until the
> function "term_start_plot()".

Apparently you are not the first one to think so.  The comment
in term_init (term.c line 406) reads:
        /* this is nasty - we cannot just term_set_output(outstr)
         * since term_set_output will first free outstr and we
         * end up with an invalid pointer. I think I would
         * prefer to defer opening output file until first plot.
         */

> and in graph3d.c at the start of the "do_plot3d()" routine is
>
>     term_start_plot();
> [Why there isn't a term_init() there also, I don't know.]

The first thing term_start_plot() does is call term_init().
So it isn't really necessary in graphics.c at all.

> So, it would mean keeping track of the output file name using
> a character pointer and realloc() and keeping track of the
> binary/ascii file type.  In term_start_plot(), check if the file
> name is non-NULL, and if so open the file and free()
> the memory for the name and set the pointer back to NULL.
>
> Does it seem like that would work?

It could be made to work, but I see several problems. =20

The first is that if the output file is illegal it makes far more sense
to get that error message immediately from the 'set output' command.
If you defer trying to open the file until later, the error message
becomes decoupled from the command that caused it.

Also, remember that some terminal types can put multiple plots
into a single file, while others cannot.  I would have
to delve into the code to see if moving the file open to=20
term_start_plot() would trip over that difference or not.

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

Re: x11.trm terminal options

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

Hans-Bernhard Broeker wrote:

>>With regard to 2, note that if one types "set output 'name'"
>>followed by no plot commands, but then "set output", the
>>file 'name' will be created.  Is there an analogy here between
>>a file and a window?
>>    
>>
>
>Not really.  Arguably, that behaviour of 'set output' is wrong itself.
>

I've looked at the code in term.c regarding opening the file.
It looks like the terminal initialization is very safely done with
appropriate checks of a variable "term_initialised".  I'm
wondering if the actual "fopen()" can't be held off until the
function "term_start_plot()".  In graphics.c at the start of
the "do_plot()" routine is

    term_init();        /* may set xmax/ymax */
    term_start_plot();

and in graph3d.c at the start of the "do_plot3d()" routine is

    term_start_plot();

[Why there isn't a term_init() there also, I don't know.]

So, it would mean keeping track of the output file name using
a character pointer and realloc() and keeping track of the
binary/ascii file type.  In term_start_plot(), check if the file
name is non-NULL, and if so open the file and free()
the memory for the name and set the pointer back to NULL.

Ethan, right before the term_init() call is a note you left
regarding font sizes.  Perhaps you are familiar with the
sequence of events and can tell if a simple change is possible.
Does it seem like that would work?

[Different topic below.]

>>3)  Looking at the X11_options() in x11.trm it is very similar
>>to other parsing/interpretting schemes, however it doesn't have
>>the many checks for repeated entry, valid entry, etc.  Some
>>commands are sent to gplt_x11 even before the end of parsing.
>>    
>>
>
>That's a bug, then.  But AFAICS, the only command sent to gplt_x11.c
>before parsing of the options is finished is an update of the window
>number.
>

I've added the necessary checks for duplicate entry.  At
the end is a #define switch:

    if (duplication) {
#if NOT_PROCESS_IF_DUPLICATION
        int_error(c_token-1, "duplicated or contradicting arguments in 
X11 term options");
#else
        if (!shown_warning)
            int_warn(c_token-1, "duplicated or contradicting arguments 
in X11 term options");
        shown_warning = TRUE;
#endif
    }

and nothing is done until after that test.  I set the variable
NOT_PROCESS_IF_DUPLICATION true simply because
there are a number of situations where what the user enters
could error inside parse.c and util.c.  I don't want to modify
anything there in those files to allow continuation.

So it works fine.  But I recall something now.  I believe there
was a discussion a while back about the ability to close a
single X11 graph from the command line.  So perhaps if both
a "reset" and a number appear in the options, only the plot
associated with that number could be closed.  Right now it
will reset the whole thing (i.e., close all windows) and then
switch to plot number.  How does that sound?

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

> >But a warning message would be OK.  At least in the above
> >case it echoes back the actual state that was set.  In your
> >earlier example "set term X11 3 'Times-Roman'" it failed to
> >echo back the state.  It is that failure that I consider a bug,
> >not the fact that it accepted the 3 but rejected the font.

I think X11 should be consistent with other terminals. So: any order of
options allowed; nothing drawn (and no window open) until (s)plot; it should
not do strange things with (mistakenly) duplicating options.

---
Petr Mikulik

Re: x11.trm terminal options

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

On Thu, 23 Oct 2003, Daniel J Sebald wrote:

[...]
> 2)  If you think the above problem should be modified,
> do you feel that
>
> a) graphics windows should not appear until something
>  is actually plotted to them

Yes.  A gnuplot X11 graph window serves no purpose whatsoever until a
graph is plotted into it, so there's no point displaying it until that
point in time.

> With regard to 2, note that if one types "set output 'name'"
> followed by no plot commands, but then "set output", the
> file 'name' will be created.  Is there an analogy here between
> a file and a window?

Not really.  Arguably, that behaviour of 'set output' is wrong itself.

> 3)  Looking at the X11_options() in x11.trm it is very similar
> to other parsing/interpretting schemes, however it doesn't have
> the many checks for repeated entry, valid entry, etc.  Some
> commands are sent to gplt_x11 even before the end of parsing.

That's a bug, then.  But AFAICS, the only command sent to gplt_x11.c
before parsing of the options is finished is an update of the window
number.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.