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

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.

Re: x11.trm terminal options

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

Ethan A Merritt wrote:

>garbage in -> garbage out.
>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.
>

And what of "reset"?  I think as it is "set term x11 reset noraise 19"
is different than "set term x11 noraise 19 reset" because the order
of appearance matters.  I think it would be better that options have
a precedence say

"reset"  (first)
number (second)
order of remaining options doesn't really matter

That is, the user would be able to enter them in any order but they will
be processed in order above.  That would be changing Gnuplot's
behavior a bit, but I don't think users have come to realize that
order matters in the x11 options string.

Dan




-- 

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

x11.trm terminal options

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

Here is an observation in x11.trm that technically isn't
a bug, but there is a small issue with consistency.  I'm
working on a short patch right now that highlights this
issue.  I'm debating a work around but it might be nice
for the list to think whether a small alteration should be
made for consistency, in which case I wouldn't have to
do a work around.

If one starts up gnuplot and issues a

set term x11 3

the X11_ipc to gplt_x11 is not valid yet.  That means
that anything in the X11_options() routine that checks
if X11_ipc is valid  will not send information to gplt_x11 at that
point in time.  There currently is some code there, but
it has no real effect because what would have been
sent over is something
saved internal to x11.trm code and gets resent.
(You can probably guess
I'd like to put something there that won't be saved
necessarily.  But don't let that sway you, I'm arguing
consistency here.)

Once something is plotted, say

plot sin(x)

X11_ipc is up and running and all things are hunky dory.

So, the consistency issue... The ramification of the
above is that

set term x11 3

will cause the x11 window to appear on the desktop,
_unless no plots have been created yet_.  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.

Any comments on this?

Thanks,

Dan

Re: x11.trm terminal options

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

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/

Re: x11.trm terminal options

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

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/

Re: CVS source tree problem

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

Hans-Bernhard Broeker wrote:

>On Tue, 21 Oct 2003, Daniel J Sebald wrote:
>
>  
>
>>Daniel J Sebald wrote:
>>    
>>
>
>  
>
>>>>Correct. prepare works fine with autoconf 2.57f.
>>>>        
>>>>
>
>  
>
>>>I downloaded the latest version of autoconf and it doesn't
>>>compile on my system because of dependency problems.
>>>      
>>>
>
>Someone might be able to help you with those if you detailed them. In my
>experience, automake and autoconf don't really need much in terms of other
>programs, if you start off a reasonably complete Unix-ish system.
>

Perhaps I will give it a try later; just debating if I should put
effort into that or update to a new snapshot release.

>>Never mind.  I can just download the individual source files and place
>>them in an old source tree.
>>    
>>
>
>That won't work --- the change to AC_PREREQ() wasn't done just for fun.
>We actually need it.  You risk missing important bugfixes because latest
>source files can no longer work with outdated configure & friends.
>

I understand.  I've conceded on the latest version of Gnuplot
for now.  But for some patches, so long as I have the latest
C file and diff against only those, it should be fine.

Thanks,

Dan


-- 

Dan Sebald
email: d a n i e l  . s e b a l d  @ i e  e e . o  r g
URL: ht tp://acer-access.c om/~dsebald @ acer-access.co m/

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

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

On Wednesday 22 October 2003 04:04, Hans-Bernhard Broeker wrote:
> On Wed, 22 Oct 2003, Petr Mikulik wrote:
> > On my machine, the 2 patches pass the two problems. However, there is
> > a new one: the Octave script below works differently whether the firs=
t
> > Octave command was "gset mouse"
>
> That's not at all new.  That's exactly the problem that patch by
> Johannes was made to fix, in the first place:  quick cut-n-paste with
> mousing on will loose large quantities of input and find them again as
> soon as you press a key.

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 t=
he
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.

However, in case someone does want to use an awk script,
perhaps there could be an option
=09set 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.=20

Would that be an acceptable work-around?

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

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

On Wed, 22 Oct 2003, Petr Mikulik wrote:

> On my machine, the 2 patches pass the two problems. However, there is a new
> one: the Octave script below works differently whether the first Octave
> command was "gset mouse"

That's not at all new.  That's exactly the problem that patch by Johannes
was made to fix, in the first place:  quick cut-n-paste with mousing
on will loose large quantities of input and find them again as soon as
you press a key.

We're running in circles, here.

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

Re: CVS source tree problem

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

On Tue, 21 Oct 2003, Daniel J Sebald wrote:

> Daniel J Sebald wrote:

> >> Correct. prepare works fine with autoconf 2.57f.

> > I downloaded the latest version of autoconf and it doesn't
> > compile on my system because of dependency problems.

Someone might be able to help you with those if you detailed them. In my
experience, automake and autoconf don't really need much in terms of other
programs, if you start off a reasonably complete Unix-ish system.

> Never mind.  I can just download the individual source files and place
> them in an old source tree.

That won't work --- the change to AC_PREREQ() wasn't done just for fun.
We actually need it.  You risk missing important bugfixes because latest
source files can no longer work with outdated configure & friends.

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

Re: CVS source tree problem

[Lars H. <lhe...@us...>]

Daniel J Sebald writes:
 
[Please stop CC'ing me. You are defeating the purpose of a mailing list.]

> I downloaded the latest version of autoconf and it doesn't
> compile on my system because of dependency problems.
> I realize I should have an up-to-date system, but I can
> see a cascade of updates coming.  Is there a way to work
> around this momentarily?  I'd like to update my whole system
> with a new set of binaries eventually, but not right now.
 
 A new snapshot release would help ...

Re: arrowheads too long in PostScript terminal

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

Alan G Isaac wrote:
  

> A picture is worth a thousand words.  How can the sript
> below be considered to produce desirable output for these
> script commands?


A couple comments.  First, I see Alan's point from
his example.  That top arrowhead does seem to have
the feel of not ending in the right spot.  It looks like the
increased thickness of the line causes the front tip
of the arrowhead to be a little ways past the point.
In other words, if you think of the outside edges of
the lines, those thin edges criss-cross not at the "to"
point, but somewhere beyond it.

It seems to me that a nice behavior would be that no
matter what type of butt/rounding style is used those
outer edges should criss-cross right at the "to" point.
Even if the tip is rounded, I'm guessing that would still
look nice.  (There would probably be a little bit of
white space between the rounded tip and the "to"
point.)  It shouldn't be too difficult to write a little
routine to compensate for that sort of thing.  It is
probably something involving vector math and trig.
(To get the rounded tip to stop right at the point would
require a bit more tricky computations.)  Draw two
extremely wide lines on a sheet of paper criss-crossing.
The vector relationships should become clear from
that.

The second comment is that yes, user expectations
are something to consider.  But also you should weigh
in any preceding standards.  My guess is that there
have been long discussions amongst graphics people
about the topic and some standard may have emerged
over the years.  I would consider using that as a guide.
Of course, I don't know where one would look for that.
Perhaps a PostScript manual.

Dan


Alan G Isaac wrote:

>>On Monday 20 October 2003 23:14, Alan G Isaac wrote:
>>    
>>
>>>Basic user interface issue:
>>>set arrow from ptA to ptB
>>>will be expected to do precisely that:
>>>start at ptA and end at ptB.
>>>      
>>>
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>Gnuplot does that now.  What we are disagreeing about is the
>>meaning of the word "precisely".
>>    
>>
>
>Actually I think we are disagreeing on the more basic words
>'start' and 'end'.  I have not been able to understand your
>apparent suggestion (?) that the user will expect ink past
>ptB (in the direction of the arrow).
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>You may not like the behavior, but that doesn't mean it
>>is ambiguous.
>>    
>>
>
>I think you are giving a programmer's perspective rather 
>than a user's perspective on ambiguity here.  Of course,
>the code says what it says.  But a user has no simple
>way to tell where an arrow will end. (I.e., where the
>ink will end.)
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>think of line segments in gnuplot as a
>>connect-the-dots process:  place a dot at the "from"
>>position, place another at the "to" position, then connect
>>them.
>>    
>>
>
>I accept that if I draw several independent (i.e., unjoined)
>line segments end to end that round caps will produce a
>better looking line.  But this is not how people use arrows.
>Or rather, I don't know anyone using arrows this way.
>And those who do have a round caps option available to them.
>
>  
>
>>I personally think that rounded ends are best.
>>But it should be left up to the user, as it is now.
>>    
>>
>
>No, it isn't.  Not for arrows with heads.  Selecting butt
>caps does not cause arrowhead ink to terminate at the
>specified end point.
>
>
>  
>
>>But they don't.   They extend exactly to the specified
>>endpoint *** to the resolution of the pen used ***.
>>    
>>
>
>  
>
>>>What is more, with
>>>this behavior it is essentially impossible for me to make an
>>>arrow terminate precisely where I wish it to.
>>>      
>>>
>
>  
>
>>I don't see why.  Can't you just specifiy a very thin
>>pen width and a filled arrowhead?  Stroke the tail of
>>the arrow separately if you want that part thicker.
>>    
>>
>
>Stroke the tail to where, exactly?  (That is the 
>user interface issue!)
>
>A picture is worth a thousand words.  How can the sript
>below be considered to produce desirable output for these
>script commands?  I still say the key issue is: what will
>users expect, and what makes it easiest for them to achieve
>precisely what they desire in a predictable fashion?  When
>the user wants an arrow from ptA to ptB, that really ends at
>ptB (i.e., no ink past ptB), s/he should not have to make
>length adjustments everytime s/he changes the linewidth or
>arrowhead angle.  Yet that is the current situation.  I
>cannot see that this behavior (in the sample script) can
>meet the goal of being predictable for the user.  And I add
>to that a personal query: thinking back over your own use of
>arrows in gnuplot, can you really claim that your *intent*
>when you first think of drawing an arrow from ptA to ptB
>is for the ink to extend past ptB?
>
>Alan Isaac
>
>##############################################################
>set term post eps color solid butt
>set output 'c:\temp3.eps'
>set xrange [0:4]
>set yrange [0:5]
>set style arrow 1 front head size 0.2,15 nofilled lt -1
>set style arrow 2 front nohead lt -1
>set style arrow 3 front nohead lw 5 lt -1
>set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1
>set arrow from  1,1 to 3,1 as 1
>set arrow from  1,2 to 3,2 as 2
>set arrow from  1,3 to 3,3 as 3
>set arrow from  1,4 to 3,4 as 4
>plot '-' with points ps 1 pt 7 lt 1
>3 1
>3 2
>3 3
>e
>##############################################################
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN developer relations
>Here's your chance to show off your extensive product knowledge
>We want to know what you know. Tell us and you have a chance to win $100
>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: d a n i e l  . s e b a l d  @ i e  e e . o  r g
URL: ht tp://acer-access.c om/~dsebald @ acer-access.co m/

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

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

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

On my machine, the 2 patches pass the two problems. However, there is a new
one: the Octave script below works differently whether the first Octave
command was "gset mouse"

#gset mouse

n=30;
x=linspace(100,5000,30);
y=x+100;
title('first plot')
plot(x,y);
title('second plot')
plot(1-x,log10(y),x,log10(y),'b*');
title('third plot')
plot(1000-x,1000-y,x,y,'g*');


If there is no "gset mouse", then it displays all 3 plots.
If there is "gset mouse", it displays only the 1st plot, and waits until you
do whatever "gset ..." command -- then it displays all the rest. Seems like
something is waiting in the buffer.

---
Petr Mikulik

Re: CVS source tree problem

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

Daniel J Sebald wrote:

>>
>> Correct. prepare works fine with autoconf 2.57f.
>>
>
> I downloaded the latest version of autoconf and it doesn't
> compile on my system because of dependency problems.
> I realize I should have an up-to-date system, but I can
> see a cascade of updates coming.  Is there a way to work
> around this momentarily?  I'd like to update my whole system
> with a new set of binaries eventually, but not right now. 


Never mind.  I can just download the individual source
files and place them in an old source tree.

Dan