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

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

Re: CVS source tree problem

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

On Mon, 20 Oct 2003, Daniel J Sebald wrote:

> configure.in: 7: required file `./config.hin' not found
> FATAL ERROR: Autoconf version 2.52 or higher is required for this script

The second line is your real problem, I think.  I upped AC_PREREQ to
version 2.52 two weeks ago.

> In looking back at a version from a couple weeks ago that worked, I see
> that there is no file called "config.h.in", just a "config.hin".  But in
> the latest version, a file is created called "config.h.in", but no
> "config.hin".

When is that file created?  What's creating it?

I guess the problem with config.hin is just a follow-up error, and the
real problem is AS_PREREQ().

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

Re[2]: arrowheads too long in PostScript terminal

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

On Mon, 20 Oct 2003 08:32:53 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
> I thought some more about the issue of where an arrow should
> terminate, and I have decided that I disagree with Alan's premise.
> It is not correct that the tip of the arrowhead should terminate
> immediately before the (x,y) coordinate it is drawn "to".
> I can see two cases to be considered:

> 1)  The arrow exists for the purpose of indicating a certain (x,y)
> point with great precision.  In this case an arrow is entirely the
> wrong visual aid.  Instead one should place a dot, cross, or
> circle on the point being indicated

> 2) The arrow is pointing toward some feature of interest on the plot.
> In this case it is proper for the arrow head to stop well before the
> actual point being indicated, since it is best not to obscure the
> immediate neighborhood of the point itself.

> Arrows are not special. All line segments should have the same
> properties, and all other line segments terminate precisely on
> top of the (x,y) points they connect, where "on top of" means that
> the finite thickness of the line causes it to extend beyond the
> precise (x,y) coordinates in all directions.


If I understand Ethan, he thinks arrows should be shortened
even more than I do.  But I still disagree.

Basic user interface issue:
set arrow from ptA to ptB
will be expected to do precisely that:
start at ptA and end at ptB.
*If* this is the provided behavior,
the user can always adjust these points appropriately
to achieve the effects Ethan mentions in 2).

Basic issue of cooperation: let the user apply arrows
however they desire.  Just make it easy to do so.  (E.g.,
let the user decide if an arrow is an appropriate visual aid
for his/her purpose.)

Example: 'plot with vectors' will be badly screwed up if
the vectors do not start and stop exactly where they should.

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

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.)  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. Ethan seems to be suggesting that choosing a
projecting square cap should be the default.  I cannot
recognize this as a standard practice.

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, so my view is obviously that this is
unexpected and undesirable behavior.  What is more, with
this behavior it is essentially impossible for me to make an
arrow terminate precisely where I wish it to.  This too is
very undesirable.  Finally, with the new flexibility for
arrowheads, the termination of the arrowhead will become
even harder for a user to anticipate since it will change
with the angle used for the arrowhead.

If there were implementation issues that spoke against this,
I would understand some hesitancy.  But implementation is
actually simplified for filled heads.  (And *all* heads
can be filled on capable terminals.)  For nofilled heads
it is basically a matter of computing the mitre to offset the
head and the shaft length.

Cheers,
Alan Isaac

CVS source tree problem

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

The CVS source tree has an error in ./prepare that wasn't there
a week or two ago.

--------

configure.in: 7: required file `./config.hin' not found
FATAL ERROR: Autoconf version 2.52 or higher is required for this script

Some part of the preparation process failed.
Please refer to INSTALL for details.

--------

In looking back at a version from a couple weeks ago that worked, I see
that there is no file called "config.h.in", just a "config.hin".  But in 
the latest
version, a file is created called "config.h.in", but no "config.hin".

Dan

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

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

[apologies if you receive this message twice.  Since I'm not entirely
 sure that the new gnu...@li... is working,
 I have CCed various interested parties directly]

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=20
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()=
=2E
             * 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=20
problem in my tests using the awk script below. =20

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.

Before proceeding any further, I'd like to hear more detail from=20
Johannes about what problem this line was originally fixing.
I have not noticed any dropped paste events or mouse clicks,
but I may not be testing the right combination of events.

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



My test awk script:

BEGIN {
gp=3D"./gnuplot"
print "set term post" |gp
print "set mouse" |gp
print "set term x11" |gp
for (k=3D1; k<500; k++) {
    print "reset"|gp
    print "plot x*x*" k |gp
    }
}

On Friday 10 October 2003 00:57, Petr Mikulik wrote:
>
> This Octave script may show the error earlier than the awk script:
>
> gset mouse
> #do_print=3D1;
> do_print=3D0;
>
> x=3D1:600;
> y=3Dsin(x/3);
> if do_print
>     gset term post lw 2 'Helvetica' 16
>     gset out 'gpbug.ps'
> end
>
> for k=3D1:30
>     gset grid
>     title(sprintf('loop %i',k))
>     plot(x*1e-3,y,';curve;')
>     replot
> end
>
> if do_print
>     gset out
>     gset term pop
> end
>
> ---
> Petr Mikulik

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

Re: save "|gpsavediff >a.gp"

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

On Mon, 20 Oct 2003, Petr Mikulik wrote:

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

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

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.

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

*) 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?

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

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

Do you do such a diff-save in a similar way?
Or do you have a similar script with a different functionality?

Unless there are negative responses, the patch will go to cvs.
But what to do with gpsavediff? Maybe some web page...

---
Petr Mikulik

Re: list migration

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

Lars Hecking wrote:

>Daniel J Sebald writes:
>  
>
>>Me?  :)  Dave is the one who doesn't seem to mind them...
>>    
>>
> 
> See? For some reason missing posts made me miss the context ...
>
> Daniel, kindly, will you refrain from top-posting in the furture?
> It sucks almost as much as spam.
>  
>

Sorry.  No more top-posting... (Had to look that one up in The
Jargon Lexicon.)... or "TOFU".

And thank you Dave for setting the list private, and generally
taking care of list matters.

"Newbie"

(Too much Jargon Lexicon, you say?)

Re: list migration

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

Daniel J Sebald writes:
> Me?  :)  Dave is the one who doesn't seem to mind them...
 
 See? For some reason missing posts made me miss the context ...

 Daniel, kindly, will you refrain from top-posting in the furture?
 It sucks almost as much as spam.

> Anyway, my original point is that Dartmouth list seemed to be
> a real spam target.  There seemed to be about one or two per
> day routed through it.  I just imagine there was a ton of spam
> we didn't see.  I suspect there are spammers out there that

 One or two a day doesn't make that much of a difference if you
 receive 100 or 200 ...

> collect emails by an automated means.  (Would this be
> technically a form of data mining?)  I suspect that collecting
> addresses and selling them is a source of revenue for some.
> (Should be made universally illegal folks, I decree.)
> 
> Call me paranoid, but I'd prefer not having my address on a list
> in which an automated program can "who" it and search for
> @ symbols.  I can't recall a single spam to my alias address
> for about three years until recently.  (I'm not blaming
> gnuplot-info.)  And now I can see the slow increase in amount.
> (Expletive deleted.)
 
 I am pretty sure that SF is protecting email addresses pretty well,
 even in archives. They have even stepped up anti-spam recently, which
 makes a considerable difference (for a while, I was getting most of
 all spam through SF).

 Can we please stop this thread now?

 Thank you.

Re: list migration

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

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

> On Thursday 16 October 2003 11:18, Daniel J Sebald wrote:
>> Dave Denholm wrote:
>> >You can send 'who' requests to majordomo. I send
>> >who info-gnuplot-beta
>>
>> I just verified that this can be done.  I do not like this!!!  Not
>> one bit.  With the amount of spam that was being routed through
>> Dartmouth, it is clear that this facility is/was a spammer target.
>
> Nice catch, Daniel.
>
> I agree that this "feature" ceased being desirable behaviour 
> quite a while back.   Mailing-list subscription lists should not
> be public knowledge.
>

Okay, I think I've changed them all to "list" rather than "open", so that
only people subscribed can ask.

I could set 'closed', but then even the list owner can't find out, and
I need to do that for my script which unsubscribes addresses that bounce.


[
 I do also get sent notifications about subscriptions and unsubscriptions,
 so I could have maintained the list that way, but it's not worth doing
 that now !
]



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

Re: list migration, OT spamassassin

[Andrew B. <aa...@ci...>]

> Once a person's address gets out and starts floating about the
> spammer lists, I suspect the game is over.

Try spamassassin. I get about 400 spams per day (last time I checked)
and SA catches all but 2 or 3. And alot of the 2-3 that get through
are because my email is at the front of the alphabet. When I used to
report missed spams the result was always 'known spam'. By the time
I reported it it had become 'known' due to the reports of others :-)

Andy (who will be named Zachary in the next life)

Re: list migration

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

On Thursday 16 October 2003 11:18, Daniel J Sebald wrote:
> Dave Denholm wrote:
> >You can send 'who' requests to majordomo. I send
> >who info-gnuplot-beta
>
> I just verified that this can be done.  I do not like this!!!  Not
> one bit.  With the amount of spam that was being routed through
> Dartmouth, it is clear that this facility is/was a spammer target.

Nice catch, Daniel.

I agree that this "feature" ceased being desirable behaviour=20
quite a while back.   Mailing-list subscription lists should not
be public knowledge.

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

Re: list migration

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

Dave Denholm wrote:

>You can send 'who' requests to majordomo. I send
>
>who info-gnuplot
>who info-gnuplot-digest
>who info-gnuplot-beta
>who info-gnuplot-beta-digest
>who bug-gnuplot
>
>to majordomo from time to time to keep my local list refreshed (for failure matching)
>

I just verified that this can be done.  I do not like this!!!  Not
one bit.  With the amount of spam that was being routed through
Dartmouth, it is clear that this facility is/was a spammer target.
It is not a far stretch of the imagination that an automated
program would target and query such a list to collect email
addresses.  Please, people's addresses cannot be placed on
a list that is publicly available.  And the sooner the Majordomo
list goes down, the better, as far as I'm concerned.  I've just
been discussing the sudden occurrence of spam with multi-
recipients of certain IEEE alias addressed emails, and I'm not
the only who would find something like the Majordomo "who"
disconcerting.  Please see if the SF email list can be made
private, accessible only to those four of you knowing the password.
Once a person's address gets out and starts floating about the
spammer lists, I suspect the game is over.

Thanks,

Dan