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

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

Re: Re[2]: arrowheads too long in PostScript terminal

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

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.

Gnuplot does that now.  What we are disagreeing about is the
meaning of the word "precisely".

> Basic implementation issue:
> there should be no ambiguity about what "from" and "to" mean.
> Additionally, for filled arrows (and on capable terminals
> *all* heads can be drawn as filled) this keeps the drawing
> computations as simple a possible.  (Related to this:
> an arrow without a head should start and stop and the
> same precise location as an arrow with a head!)

But all of this is true right now, so far as I know.
You may not like the behavior, but that doesn't mean it
is ambiguous.

> Finally, on the interpretation of where an arrow goes, I am
> not proposing an idiosyncratic interpretation.  To the
> contrary, I believe it is very standard.  (Compare e.g. the
> LaTeX picture environment.) =20

But TeX conceives of arrows as characters, and as such
they are entirely enclosed within a conceptual character
cell.  If you want to embed TeX/LaTeX arrows in your
gnuplot figure, you can do so using 'set term post enhanced'

By contrast 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.

> And contrary to Ethan's claim,
> I argue that this provide a good match for how lines are
> handled. Lines are generally expected *not* to project
> beyond the path endpoint.  Using PostScript terminology, the
> natural presumption is a butt cap, and this is the natural
> default.=20

People's expectations obviously vary, and this leads to
complaints from time to time. In particular, the PostScript and X11=20
implementation of butt caps causes the line segment to
terminate along a line perpendicular to the direction of the line
segment itself. This means that in general it overshoots the
x-coordinate, the y-coordinate, or both, of the "to" specification.
There was, for example, a recent complaint here that line segments=20
should never extend beyond the x-coordinate specified;
i.e. the line segment fill should always be clipped against
a vertical boundary at the endpoints.

Furthermore, butt caps cause very ugly line joins.
See previous discussions about the use of polylines=20
rather than individual line segments in X11.

> Ethan seems to be suggesting that choosing a
> projecting square cap should be the default.  I cannot
> recognize this as a standard practice.

No. I personally think that rounded ends are best.
But it should be left up to the user, as it is now. =20

> But after all is said and done, they key issue is: what will
> users expect, and what makes it easiest for them to achieve
> precisely what they desire in a predictable fashion?  I was
> personally startled to find that arrows project past their
> assigned end point

But they don't.   They extend exactly to the specified=20
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.

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

Re[4]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

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

Re: Re[4]: arrowheads too long in PostScript terminal

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

On Tuesday 21 October 2003 13:42, 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?
> ##############################################################
> 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
> ##############################################################

If you change that first line to=20
   'set term post eps color solid round'
then it looks just fine to me.
The ugliness comes from requesting butt ends.

Nonetheless, let me suggest a couple of possible code modifications.
Please consider whether these would address your concerns.

1) The tail of a filled-head arrow could be drawn to reach only to
the back of the head, not all the way to the tip. This would make=20
your sample arrow 4 much less ugly

2) There could be an offset parameter, expressed in screen coordinates
I suppose, applied to the tip positioning of arrows.  The arrow would be
shortened by shifting the nominal "to" position back along the direction =
of
the arrow by this amount.  This would allow you to use fat arrows (thick
lines) for emphasis without obscuring the feature being pointed to.

I think both of these could be implemented fairly easily in the
device-independent code, and so would apply to all terminal types.


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

Re: CVS source tree problem

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

Lars Hecking wrote:

>>When is that file created?  What's creating it?
>>    
>>
> 
>AM_CONFIG_HEADER(config.h:config.hin)
>
> It should probably be replaced with AC_CONFIG_HEADERS now.
>
>  
>
>>I guess the problem with config.hin is just a follow-up error, and the
>>real problem is AS_PREREQ().
>>    
>>
> 
> 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.

Thanks

Dan

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

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

On Tuesday 21 October 2003 13:00, Daniel J Sebald wrote:
> I haven't been following too closely, but here's an observation
> that may or may not be related.  I've notice for a while that if
> one uses the mouse to copy text to Gnuplot's command line
> (i.e., the "clipboard" method, or whatever) that whenever there
> is a "pause -1", the first character after the pause is always
> deleted.

OK. I'll chase after that one also.
Neither of my current patches fixes it.

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

I haven't been following too closely, but here's an observation
that may or may not be related.  I've notice for a while that if
one uses the mouse to copy text to Gnuplot's command line
(i.e., the "clipboard" method, or whatever) that whenever there
is a "pause -1", the first character after the pause is always
deleted.  That is, it will interpret all lines up to "pause -1"
correctly, then wait for the keyboard to hit, then the first character
after the keyboard hit is lost.  If it is a non-whitespace character,
Gnuplot will have a syntax error.

Dan



Ethan Merritt wrote:

>On Tuesday 21 October 2003 02:36, Petr Mikulik wrote:
>  
>
>>Ethan Merritt wrote>
>>    
>>
>>>Commenting out this one setvbuf() line solves 99% of the
>>>problem in my tests using the awk script below.
>>>
>>>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.
>
>  
>

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

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

On Tuesday 21 October 2003 02:36, Petr Mikulik wrote:
> Ethan Merritt wrote>
> > Commenting out this one setvbuf() line solves 99% of the
> > problem in my tests using the awk script below.
> >
> > 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.=20

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

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

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.


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

Re: save "|gpsavediff >a.gp"

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

> Exactly, and that's a pain in the lower back we don't need.  The plan is
> to have all code handling a given setting in *one* place.  Be that the

 That was the idea behind variable.c, but I'm not sure whether the
 implementation could serve aas a model for the otehr variables.

Re: save "|gpsavediff >a.gp"

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

On Tue, 21 Oct 2003, Petr Mikulik wrote:

> > *) organize the set/show/save/unset/reset implementations by variable, not
> >    by command, i.e. the set, show, save, unset and reset (default status)
> >    for a given setting should all be in *one* place, not scattered over
> >    4 files (set.c,show.c,unset.c,misc.c).  This would make things a
> >    lot more OO-ish.
>
> That'll be a long file then.

No, it won't --- because it'll still be split up into several files, but
along different lines.

> Currently, one has to edit all the 3 files simultaneously.

Exactly, and that's a pain in the lower back we don't need.  The plan is
to have all code handling a given setting in *one* place.  Be that the
module that implements the effect of that setting, too (pm3d.c for 'set
pm3d', hidden3d.c for 'set hidden3d', etc.), or a special user interface
module for an existing core functionality module (e.g. a setaxis.c to go
with axis.c).

> > *) Add a new method, or a flag to the 'save-variable' method of each
> >    setting, so it saves only the state different from the default.
>
> Would that mean most variables need to have this_variable_default_value =
> {...}?

Yes.  But you need that info for the 'reset' command, anyway, so it's not
exactly a new requirement.

> Another method of the "diff" save would be to write the output into an array
> of strings, then the same for invoking internally "reset", and write out
> only diff's, and finally re-read internally the status before reset.

Overly complicated.  If at all, create an in-memory dump of all settings
immediately after start-up initialization (before reading ~/.gnuplotrc,
that is), and keep that dump around for the whole session.

The sprintf() vs. fprintf() could be relayed to a common s_or_f_printf()
utility routine to be used by all save_foo() functions --- but we'ld
then need vs[n]printf() and vfprintf() on all platforms ;-(

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

Re: CVS source tree problem

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

> When is that file created?  What's creating it?
 
AM_CONFIG_HEADER(config.h:config.hin)

 It should probably be replaced with AC_CONFIG_HEADERS now.

> I guess the problem with config.hin is just a follow-up error, and the
> real problem is AS_PREREQ().
 
 Correct. prepare works fine with autoconf 2.57f.

demos

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

Few days ago, I'd a look into *.dem and fixed use of "reset" commands at the
ends of all of them, and added $Id:$ tags there.

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?

---
Petr Mikulik

Re: save "|gpsavediff >a.gp"

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

> > I wanted to let the "save" command to save to file only differences wrt
> > "reset"  status of gnuplot, so I've patched save_command() + surrounding
> > routines to allow write to pipe. In the attached file, there is that
> > patch + my favourite script "gpsavediff".
>
> I'm somewhat surprised it doesn't already support the "| command" syntax
> already.  Given that, I'm all for integrating this patch ASAP.

I've commited the patch.

> > Do you do such a diff-save in a similar way?
>
> Yes.  I salvaged a script similar to yours ages ago, from a mail to
> info-gnuplot IIRC.  It's called 'reduce-gnuplot-output', it's a
> csh script (of all things), and it only works for named files.

I've been using that mine script for years using REXX, and just recently
rewritten it into shell. BTW, yesterday I've even managed to replace
the pipe "grep | grep -v | sed" into a single sed invocation .. how cool...


> A better approach to the whole task would almost certainly be to integrate
> it into gnuplot itself.  But for that to become feasible, we'ld need a
> massive refactoring of the whole internal status stuff:
>
> *) organize the set/show/save/unset/reset implementations by variable, not
>    by command, i.e. the set, show, save, unset and reset (default status)
>    for a given setting should all be in *one* place, not scattered over
>    4 files (set.c,show.c,unset.c,misc.c).  This would make things a
>    lot more OO-ish.

That'll be a long file then. Currently, one has to edit all the 3 files
simultaneously.

> *) Add a new method, or a flag to the 'save-variable' method of each
>    setting, so it saves only the state different from the default.

Would that mean most variables need to have this_variable_default_value =
{...}?

> *) Add an option to 'save', or a new command 'savediffs' to call that
>    new method.
>
> This would be a ton of work, unfortunately.  I.e. I'd advise to delay this
> until after the 4.0 release we all still agree should happen soon ---
> right?

Yes.

Another method of the "diff" save would be to write the output into an array
of strings, then the same for invoking internally "reset", and write out
only diff's, and finally re-read internally the status before reset. That'd
emulate the need for external "diff" command, but require many sprintf's
instead of fprintf's.

---
Petr Mikulik

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

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

> Petr Mikulik and John Bollinger alerted me to the recurrence of an
> old problem.  When (1) gnuplot is run from a script and (2) mouse
> input is enabled, then characters are dropped from the input
> stream.
>
> I initially thought this was something I had broken with my X11
> initialization patches (revisions 1.71 - 1.74 of term/x11.trm).
> But after backing these out altogether, I still see the problem,
> although possibly with a lower frequency.
>
> After much poking about in the source code, I came
> across this bit in term/x11.trm
>
>             /* apparently multi-character inputs like escape sequences
>              * but also mouse-pasted text got buffered and therefore
>              * didn't trigger the select() function in X11_waitforinput().
>              * Switching to unbuffered input solved this (although I don't
>              * really like this solution 23 Jan 2002 (joze) */
>             setvbuf(stdin, (char *) 0, _IONBF, 0);
>
> Commenting out this one setvbuf() line solves 99% of the
> problem in my tests using the awk script below.
>
> 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.
>
> It would also be good to hear from Petr or some other Octave
> user as to whether removing the setvbuf()  line also fixes
> things in Octave.

I've tried it with Octave, but there is no change with or without setvbuf.
Gnuplot mostly looses the first character.

Probably, there was a thread on this topic around 23 Jan 2002, where
Johanness submitted his patch ...?

What I can confirm, is that I have this problem with gnuplot cvs'ed on June
21 2003 and newer. And, in the version of 21.6.2003, commenting out the
setvbuf command, only the first char written is lost; otherwise many of
them.

---
Petr Mikulik