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

Re: pasting code into gnuplot

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

On Wed, 7 Jan 2004, Ethan Merritt wrote:

> The X11 paste buffer is now working, and piping through awk
> now works too.  I left the call to setvbuf() protected by
> #ifdef X11 but I doubt that it needs to be.  Are any non-X11
> platforms also suffering lost characters in the input stream?  

If so, they've kept themselves remarkably quiet, or haven't even
noticed the problem yet.

There are only a few noteworthy candidates besides X11, to begin with:

*) OS/2
*) MS Windows
    These both use a non-<stdio.h> input scheme, I think, so there's
    no buffering to be worried about.

*) MacOS classic --- not our business, we never made that version
*) MacOS X / OpenStep   --- I've no idea.
*) Full-screen direct VGA drivers for the PC (linuxvga, DOS versions, GGI)
    These rely on a keypress event to switch back and forth between graph
    and command line.  But none of them has mouse or other feedback
    coming from the driver, so they should be safe.

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

Re: pasting code into gnuplot

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

On Wed, 7 Jan 2004, Ethan Merritt wrote:

> So it isn't really a race. It's just that if we are going to
> switch to unbuffered mode we should first make sure the
> buffer is empty, or else store it elsewhere for later execution.

Doing so will *make* it a race, then.  A race between gnuplot going from
'read all that's in the buffer' and 'set to unbuffered' on one side of the
track, and the external program re-filling the buffer on the other.

And that's before we consider that there's no way, AFAIK, to read only
the buffer, for stdin.  You only get to notice the buffer is empty when it
tries to read one past the end --- at which point it blocks, and gnuplot
becomes irresponsive.

I suspect we'll have to avoid stdin buffering and possibly blocking I/O
altogether.  I.e. don't switch off buffering halfway into the program, but
immediately after startup, before the first character is read.

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

Re: pasting code into gnuplot

[Arnd B. <arn...@we...>]

On Wed, 7 Jan 2004, Ethan Merritt wrote:

> The light dawns.  Much that was murky becomes clear.

That's really good news - below is a text I set up before,
parts of it might be obsolete, even though
observation D) seems to relate what you wrote
on the buffered to unbuffered change

[...]

> 	setvbuf(stdin, (char *) 0, _IONBF, 0);
> This command changes from buffered to unbuffered input
> mode, which would be OK, but.....
> The current buffer contents are thrown away, and you lose
> all the characters that have not yet been read in and acted upon.

Commenting this out explains then (I think) why
this contents shows up after a return (see below).

> So it isn't really a race. It's just that if we are going to
> switch to unbuffered mode we should first make sure the
> buffer is empty, or else store it elsewhere for later execution.
>
> I don't yet see a trivial way of doing this, but it can probably
> be done with enough work.

OK - I will stay tuned ;-).

Alright, and here the "results" of some tests:


Hi,

thank you all very much for your replies.

I tested some of the options:

A) ./configure --with-readline=gnu  --disable-mouse
    - copy-and-paste: does work
    - piping from python works

B) ./configure --with-readline=gnu  --enable-mouse  (default)
    - copy-and-paste     : does not work
    - piping             : has problems
    - with `gnuplot -noevents -nofeedback`
      and an unset mouse at the beginning: does not help.

C) ./configure   --enable-mouse  (default)
   results: as for B)

D) ./configure --with-readline=gnu  --enable-mouse  (default)
   + commenting out setvbuf() in x11.trm

   results: same as for B), but
     - for pasting: after pressing enter at the gnuplot> prompt
       the "lost" lines appear and are executed!
     - for piping: sometimes a character at the beginning
       of a line is lost.


I am not sure if the above is helpful ;-) ...

For the "moment" it would be good to have the two options
  a) mouse enabled gnuplot with feedback and all that
  b) mouse disabled, feedback disabled
    + pasting works
    + piping works
via command line options.
(I wonder if b) should be the default for backwards compatibility?).

In the longer run Dan's "tight loop" suggestion
sounds very reasonable to me...

Regards,

Arnd

Re: pasting code into gnuplot

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

On Wednesday 07 January 2004 15:54, Ethan Merritt wrote:
>
> if we are going to
> switch to unbuffered mode we should first make sure the
> buffer is empty, or else store it elsewhere for later execution.
>
> I don't yet see a trivial way of doing this, but ...

Trivial indeed. I was focused on the "or else", but in fact
the first alternative is the easy one.  The buffer is empty=20
when the program starts, so I moved the call to setvbuf()
out of X11_init() and put it right at the start of plot.c where
the other I/O streams are being initialized.

The X11 paste buffer is now working, and piping through awk
now works too.  I left the call to setvbuf() protected by
#ifdef X11 but I doubt that it needs to be.  Are any non-X11
platforms also suffering lost characters in the input stream? =20


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

Re: pasting code into gnuplot

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

The light dawns.  Much that was murky becomes clear.

I have traced down the problem, and it is not quite where I thought
it would be.  It may even be fixable, although I have not yet worked
out how to do it.

On Tuesday 06 January 2004 00:32, Arnd Baecker wrote:
> Marking and pasting (with the middle mouse button)
> into a freshly started gnuplot session
> only the lines until `plot sin(x)` (inclusive)
> are accepted (i.e. pasted)

This is because the whole paste buffer is, ummm, buffered.
That is, all the text is sitting in one buffer somewhere.
Gnuplot starts working through it character by character,
and eventually reaches a point at which it knows that a plot
will be sent to the x11 terminal driver. It calls X11_init()  and
at  x11.trm line 738 we do

=09setvbuf(stdin, (char *) 0, _IONBF, 0);

This command changes from buffered to unbuffered input
mode, which would be OK, but.....
The current buffer contents are thrown away, and you lose
all the characters that have not yet been read in and acted upon.

So it isn't really a race. It's just that if we are going to
switch to unbuffered mode we should first make sure the
buffer is empty, or else store it elsewhere for later execution.

I don't yet see a trivial way of doing this, but it can probably
be done with enough work.

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

Re: pasting code into gnuplot

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

Ethan Merritt wrote:

>On Wednesday 07 January 2004 01:07, arn...@we... wrote:
>  
>
>>Yes this is really nasty (sorry for bringing it up again ;-) -
>>anyway, I am just wondering if there is any chance at all that
>>this can be made to work in a reliable way?
>>    
>>
>
>I do not think it is possible so long as the terminal and
>X11 input streams are intermingled.
>

<snip>

I should have double-checked my email before sending my last note. -- Dan

Re: pasting code into gnuplot

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

arn...@we... wrote:

>On Tue, 6 Jan 2004, Hans-Bernhard Broeker wrote:
>
>  
>
>>On Tue, 6 Jan 2004, Arnd Baecker wrote:
>>
>>    
>>
>>>Redoing the copy and paste a second time it works as expected. (setting
>>>`unset mouse` or -nofeedback did not change anything).
>>>      
>>>
>>That's the original X11 buffering/pasting problem alright, but possibly
>>in a new disguise.  It shouldn't happen in "unset mouse" mode, though.
>>You may have to disable both mouse and feedback now.
>>    
>>
>
>I tried this as well, however, the problem remains.
>
>  
>
>>AFAICS, the problem happens whenever keyboard input arrives while gnuplot
>>is in the process of drawing a plot.  Both font size feedback and mouse
>>command feedback try to feed their input into the same channel as the
>>keyboard, leading to a kind of race-condition.  The process is entirely
>>timing-dependent, and thus quite hard to debug.
>>    
>>
>
>Yes this is really nasty (sorry for bringing it up again ;-) -
>anyway, I am just wondering if there is any chance at all that
>this can be made to work in a reliable way?
>Are there any reasonable alternatives?
>
>Alright, then I tried to re-compile with
>./configure --disable-mouse
>Here the compile ended with
>
>if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
>-DBINDIR=\"/home/python/PYTHON//bin\"
>-DX11_DRIVER_DIR=\"/home/python/PYTHON//libexec/gnuplot/3.8k\"
>-DCONTACT=\"gnu...@li...\"
>-DHELPFILE=\"/home/python/PYTHON//share/gnuplot/3.8k/gnuplot.gih\"
>-I/usr/X11R6/include -I/usr/include/libpng12  -g -O2 -MT term.o -MD -MP
>-MF ".deps/term.Tpo" \
>  -c -o term.o `test -f 'term.c' || echo './'`term.c; \
>then mv -f ".deps/term.Tpo" ".deps/term.Po"; \
>else rm -f ".deps/term.Tpo"; exit 1; \
>fi
>In file included from term.h:267,
>                 from term.c:1043:
>../term/x11.trm: In function `X11_args':
>../term/x11.trm:304: error: `X11_MOUSE_FEEDBACK' undeclared (first use in
>this function)
>../term/x11.trm:304: error: (Each undeclared identifier is reported only
>once
>../term/x11.trm:304: error: for each function it appears in.)
>make[3]: *** [term.o] Error 1
>make[3]: Leaving directory
>`/home/python/INSTALL_PYTHON/CompileDir/gnuplot/src'
>
>I.e., the source of this error are the lines
>if (strcmp(*argv, "-nofeedback") == 0)
>    X11_MOUSE_FEEDBACK = FALSE;
>Commenting out these two lines compilation happily continued to the end.
>
>With this there is no problem with pasting anymore
>(however, all the nice mousing stuff is gone ;-)...)
>
>Two more remarks:
>  1.) I mentioned in my previous mail (in the P.P.S.) that I have
>      some problems when piping commands to gnuplot.
>      Whereas an `unset mouse` did not cure them, the
>      --disable-mouse did.
>      So all this feedback and mousing stuff seems problematic
>      when sending commands to gnuplot via a pipe...
>  2.) I'd really love to have mousing working, even when gnuplot
>      is steered via a pipe.
>      Example:
>         - do a plot (in my case from python)
>         - send a "pause mouse" command
>         - read MOUSE_X and MOUSE_Y back to the calling program
>         - start some program/computation with these coords
>           as input
>         - go to step one with the new data
>      See http://www.physik.tu-dresden.de/~baecker/python/plot.html
>      for a brief example on how to get variables from gnuplot
>      back to python.
>  
>

Arnd,

I will recap my thoughts on this from the discussion a while back as I 
remember this issue.  I think to do this right a new scheme and 
structure for the code would be necessary.  I have a suspicion that the 
approach of feeding mouse data into the keyboard stream has a fatal flaw 
that will show up in one way or another.  That is, combining two input 
streams would not be a problem if there would be some device or code 
included along with the data to distinguish where the input originated 
from.  The devices don't currently work that way and that cannot be changed.

So, in my opinion, the input streams need to be kept separate all the 
way to the Gnuplot core and then there they can be handled separately. 
 I think more versatility is a good idea, as the calling program idea 
you describe is something I would see useful.  My preference would be to 
have a command that instructs how the mouse should be directed.  (I 
think someone, probably Hans, gave a logical argument for this being 
difficult to do.)  That is, the system could be a "handler" gets 
connected to the mouse stream via a pipe or something.  The default 
handler in Gnuplot would be the one that behaves as Gnuplot currently 
does.  Primitives about the button pressed and position (i.e., info that 
Ethan has displayed in his demonstration recently) could be passed to 
the handler.  The handler could be some routine in the calling program.

Regardless if you agree with the scheme I propose (I'm fine with a 
variable approach, I guess), there is still a fundamental flaw with the 
current structure of Gnuplot for keeping the keyboard and mouse 
separate.  If I recall correctly, the core of Gnuplot sort of branches 
off to an input routine where it waits for input from the keyboard. 
 That's not a good programming scheme in my opinion.  Rather, there 
should be a tight loop in the core of Gnuplot that checks if keyboard 
input is available.  If so, then process it by checking if a line is 
completed and ready for interpretation.  Next, it should check if 
primitives are available from the mouse (unless the mouse handler has 
been directed somewhere else).  If so, then process it by checking if it 
represents a valid redraw command, etc.  Program flow should be a tight 
loop as such where it is never really waiting on anything.

In any case, those are my thoughts.  I don't want to make any work for 
Ethan, but I think he is the one who could come up with a better scheme 
and implement it fairly easy.  Perhaps he'd rather put effort into 
revamping the input than dealing with what seems to have become 
frustration with chasing down this problem....  post 4.0, I would say.

Dan


-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: pasting code into gnuplot

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

On Wednesday 07 January 2004 01:07, arn...@we... wrote:
>
> Yes this is really nasty (sorry for bringing it up again ;-) -
> anyway, I am just wondering if there is any chance at all that
> this can be made to work in a reliable way?

I do not think it is possible so long as the terminal and
X11 input streams are intermingled.

> Are there any reasonable alternatives?

Yes, but it would be a major, major change to the existing layout.
So it won't happen any time soon.

> Alright, then I tried to re-compile with
> ./configure --disable-mouse
> Here the compile ended with
>
> In file included from term.h:267,
>                  from term.c:1043:
> ../term/x11.trm:304: error: `X11_MOUSE_FEEDBACK' undeclared (first use
> in this function)

I'll fix that immediately.

>       So all this feedback and mousing stuff seems problematic
>       when sending commands to gnuplot via a pipe...

This is a known problem, but none of us fully understand it.
It seems to depend on the environment from which the pipe
is opened.  For me, it works from C and from octave but fails from awk.
It seems to work from perl also, but my perl scripts are not
normally being run interactively so I'm not sure I would have
seen the failure in practice.

In the case of awk scripts, the problem can be ameliorated by
commenting out the call to setvbuf() in x11.trm as in the=20
following patch:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/term/x11.trm        2003-09-30 13:14:43.000000000 -0700
+++ gnuplot-cvs/term/x11.trm    2003-10-20 17:26:10.000000000 -0700
@@ -599,12 +607,14 @@
            ipc_back_fd =3D fdes_back[0];
            close(fdes_back[1]);        /* the parent doesn't need this *=
/
=20
+#ifdef BROKEN /* EAM Oct 2003 - This has broken awk+gnuplot */
            /* 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);
+#endif=20
        } else {
            /* we do not open a bidirectional communication
             * for non-tty's by default. If this is desired,
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

You may find that the same is true for your python environment.

I say "ameliorated" rather than "fixed" because if you apply this
patch then other peculiarities result - the main one being that
"pause -1" behaves unreliably.=20

>   2.) I'd really love to have mousing working, even when gnuplot
>       is steered via a pipe.
>       Example:
>          - do a plot (in my case from python)
>          - send a "pause mouse" command
>          - read MOUSE_X and MOUSE_Y back to the calling program

For that you need the full-blown feedback loop, not just  --enable-mouse
I did get this working nicely from C code, so the basic idea is
sound.  The problem comes from some difference in the scripting
environment.  I wish I knew exactly what.

>       See http://www.physik.tu-dresden.de/~baecker/python/plot.html
>       for a brief example on how to get variables from gnuplot
>       back to python.

You may find that removing the call to setvbuf() makes your
python example work.  Please let us know.

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

Re: pasting code into gnuplot

[<arn...@we...>]

On Tue, 6 Jan 2004, Hans-Bernhard Broeker wrote:

> On Tue, 6 Jan 2004, Arnd Baecker wrote:
>
> > Redoing the copy and paste a second time it works as expected. (setting
> > `unset mouse` or -nofeedback did not change anything).
>
> That's the original X11 buffering/pasting problem alright, but possibly
> in a new disguise.  It shouldn't happen in "unset mouse" mode, though.
> You may have to disable both mouse and feedback now.

I tried this as well, however, the problem remains.

> AFAICS, the problem happens whenever keyboard input arrives while gnuplot
> is in the process of drawing a plot.  Both font size feedback and mouse
> command feedback try to feed their input into the same channel as the
> keyboard, leading to a kind of race-condition.  The process is entirely
> timing-dependent, and thus quite hard to debug.

Yes this is really nasty (sorry for bringing it up again ;-) -
anyway, I am just wondering if there is any chance at all that
this can be made to work in a reliable way?
Are there any reasonable alternatives?

Alright, then I tried to re-compile with
./configure --disable-mouse
Here the compile ended with

if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=\"/home/python/PYTHON//bin\"
-DX11_DRIVER_DIR=\"/home/python/PYTHON//libexec/gnuplot/3.8k\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/home/python/PYTHON//share/gnuplot/3.8k/gnuplot.gih\"
-I/usr/X11R6/include -I/usr/include/libpng12  -g -O2 -MT term.o -MD -MP
-MF ".deps/term.Tpo" \
  -c -o term.o `test -f 'term.c' || echo './'`term.c; \
then mv -f ".deps/term.Tpo" ".deps/term.Po"; \
else rm -f ".deps/term.Tpo"; exit 1; \
fi
In file included from term.h:267,
                 from term.c:1043:
../term/x11.trm: In function `X11_args':
../term/x11.trm:304: error: `X11_MOUSE_FEEDBACK' undeclared (first use in
this function)
../term/x11.trm:304: error: (Each undeclared identifier is reported only
once
../term/x11.trm:304: error: for each function it appears in.)
make[3]: *** [term.o] Error 1
make[3]: Leaving directory
`/home/python/INSTALL_PYTHON/CompileDir/gnuplot/src'

I.e., the source of this error are the lines
if (strcmp(*argv, "-nofeedback") == 0)
    X11_MOUSE_FEEDBACK = FALSE;
Commenting out these two lines compilation happily continued to the end.

With this there is no problem with pasting anymore
(however, all the nice mousing stuff is gone ;-)...)

Two more remarks:
  1.) I mentioned in my previous mail (in the P.P.S.) that I have
      some problems when piping commands to gnuplot.
      Whereas an `unset mouse` did not cure them, the
      --disable-mouse did.
      So all this feedback and mousing stuff seems problematic
      when sending commands to gnuplot via a pipe...
  2.) I'd really love to have mousing working, even when gnuplot
      is steered via a pipe.
      Example:
         - do a plot (in my case from python)
         - send a "pause mouse" command
         - read MOUSE_X and MOUSE_Y back to the calling program
         - start some program/computation with these coords
           as input
         - go to step one with the new data
      See http://www.physik.tu-dresden.de/~baecker/python/plot.html
      for a brief example on how to get variables from gnuplot
      back to python.

Regards,

Arnd

Updating aquaterm.trm/apple.m4

[Per P. <per...@ma...>]

Hi,
I'm working on the next version of Aquaterm and consequently an updated 
aquaterm.trm.

The biggest change is that aquaterm.trm now relies on a library  
(libaquaterm) and I took a stab at implementing the following in 
apple.m4+term.h:
	Check for Mac OS X, if true check for the presence of libaquaterm and 
if that exists, define HAVE_LIBAQUATERM and add necessary libs.
	In term.h include aquaterm.trm if HAVE_LIBAQUATERM is defined.

I hope that this is roughly consistent with practice and will suffice 
as a starting point. I'd appreciate feedback on this, this (AC macros) 
is not my cup of tea ;-)

/Per

PS. the apple.m4 is short enough that I just paste it in for reference:

AC_DEFUN(GP_APPLE,
[AC_MSG_CHECKING(for Apple MacOS X)
AC_EGREP_CPP(yes,
[#if defined(__APPLE__) && defined(__MACH__)
   yes
#endif
], AC_MSG_RESULT(yes)
    AC_CHECK_LIB(aquaterm, aqtInit,
         AC_DEFINE(HAVE_LIBAQUATERM, 1, [ Define if AquaTerm is 
installed on this system. ])
         LIBS="$LIBS -laquaterm -framework Foundation"
         CFLAGS="$CFLAGS -ObjC",
         AC_MSG_RESULT(no), -lobjc),
    AC_MSG_RESULT(no))
])

Re: autoconf macro AC_FUNC_SELECT

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

Jim Van Zandt writes:
> 
> Lately when I do "cvs update" I get a series of warning like this:
> 
>  cvs server: conflict: Makefile.in is modified but no longer in the repository
> 
> I tried to fix that by moving the files aside and recreating them, but
> had a lot of trouble getting configuration working again.  I got a lot
> of warnings from automake (or maybe it was autoconf) about an invalid
> macro AC_FUNC_SELECT.  "prepare" didn't help.  Eventually I stumbled
> on a combination of automake, autoconf, aclocal, and prepare that is
> working.  However, there seems to be a problem...
 
 Since some autoconf macros were introduced that require autoconf 2.5x.
 These newer versions of autoconf in turn require automake 1.6 or better.
 Current versions are autoconf 2.59, and automake 1.8 (1.8.0b is available
 for beta testing).

> prepare claims:
> 
>   # Note that both autoconf 2.13/automake 1.5 and autoconf 2.5x/automake
>   # 1.7 or newer may be used, although the gnuplot project continues to
>   # use the former
>   
> However, autoconf 2.13 quits immediately because configure.in contains:
> 
>   AC_PREREQ(2.52)
> 
> I guess the comment in prepare is out of date.

 Fixing it now ...

> configure.in also contains:
> 
>   dnl Argument types of select()
>   AC_FUNC_SELECT
> 
> but AC_FUNC_SELECT is not documented in either autoconf 2.13 or 2.58.
[...]
 
 It is part of the gnuplot distribution, but the switch to autoconf 2.5x
 makes it obsolete, and I'm replacing it with AC_FUNC_SELECT_ARGTYPES
 plus assorted changes.

Re: trouble with rand()??

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

On Mon, 5 Jan 2004, Ethan Merritt wrote:

> In article <btbtll$4qp$1...@ne...> you write:
> >
> >> I assume that the original intent (which is not what is stated by
> >> the documentation) was that rand(x) will return a random number
> >> for (x==0), but will reseed with the real part of x if (x!=0).
> >
> >That may not be as simple as it sounds, for the given PRNG function.
> >The internal state of the generator has more significant bits (2 times
> >32 bits) than a double-precision floating point number, unless you
> >were to use its exponent part, too.
> 
> The static constant used in specfun.c consists of a 32 bit int 
> repeated twice to make a 64 bit seed.   If this is acceptable
> for the chosen algorithm, then I figured to do the same
> thing in seeding from the 32-bit init parameter. 

Which parameter?  The actual parameter is a double-precision float. We
have to be careful what the seed argument's scale is supposed to be:
anything smaller than 2**32, using it as a 32-bit int?  Or 0..1 like the
result of rand(), and use it scaled up accordingly?  Come to think of it,
I don't think it's important or even desirable to have rand(seed)  
reproduce the same series of random numbers as one "seed" was taken from.
I think we actually need three variants of calling ranf():

	seed with time()
	seed specified by user
	no seed, just get the next number.

I suggest to map the to rand(negative), rand(positive) and rand(0), in
that order.  Current behaviour would be reproduced by rand(1234567890).

Actually, there are other problems with that generator: it seems to assume
that longs are 32-bit types.  That's not guaranteed by anything, and is
actually becoming less likely every month, given the spread of 64-bit CPUs
these days.

I guess while at it, we should also swallow the constants Xm1 and friends
into ranf() where they belong.  

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

Re: pasting code into gnuplot

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

On Tue, 6 Jan 2004, Arnd Baecker wrote:

> Redoing the copy and paste a second time it works as expected. (setting
> `unset mouse` or -nofeedback did not change anything).

That's the original X11 buffering/pasting problem alright, but possibly 
in a new disguise.  It shouldn't happen in "unset mouse" mode, though.  
You may have to disable both mouse and feedback now.

AFAICS, the problem happens whenever keyboard input arrives while gnuplot 
is in the process of drawing a plot.  Both font size feedback and mouse
command feedback try to feed their input into the same channel as the 
keyboard, leading to a kind of race-condition.  The process is entirely
timing-dependent, and thus quite hard to debug.

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

pasting code into gnuplot

[Arnd B. <arn...@we...>]

Hi,

I just installed the current CVS of gnuplot
and encounter the following problem under X11:
Marking and pasting (with the middle mouse button)
the following few lines
######
set xrange [0:10]
print "blurb"
plot sin(x)
set out "tst.ps"
set term post
rep
set out
set term x11
######
into a freshly started gnuplot session
only the lines until `plot sin(x)` (inclusive)
are accepted (i.e. pasted)
and that's it.
((Also the "paste-buffer"
seems to get emptied, i.e. directly following
paste produces nothing (neither in gnuplot nor xemacs).))
Redoing the copy and paste a second time
it works as expected.
(setting `unset mouse` or -nofeedback did not change anything).

Can someone else reproduce this behaviour?
((This type of problem was there before some time ago
and somehow I thought that this was resolved ;-),
but maybe I am wrong...))

Best,

Arnd

P.S.: platform: debian linux, testing, gcc version 3.3.2
      (if that matters)
P.P.S.: It also seems that there are some problems with piping
      into gnuplot, but I will have to investigate this further
      (+read the posts on this again ;-) ...

Re: autoconf macro AC_FUNC_SELECT

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

On Thu, 25 Dec 2003, Jim Van Zandt wrote:

> I tried to fix that by moving the files aside and recreating them, but
> had a lot of trouble getting configuration working again.  I got a lot
> of warnings from automake (or maybe it was autoconf) about an invalid
> macro AC_FUNC_SELECT.  "prepare" didn't help.  Eventually I stumbled
> on a combination of automake, autoconf, aclocal, and prepare that is
> working. 

AC_FUNC_SELECT is a macro provided by the gnuplot sourcecode itself (it's 
in gnuplot/m4/select.m4).  It's supposed to be imported through 
aclocal.m4.  That's why prepare runs aclocal with the flag -I m4.

Any chance one of the relevant files is checked out to a fixed version
in your working copy?

>   # Note that both autoconf 2.13/automake 1.5 and autoconf 2.5x/automake
>   # 1.7 or newer may be used, although the gnuplot project continues to
>   # use the former

That comment is, indeed, outdated.  AC_PREREQ() is the hard fact.

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

Re: contouring broken with hidden3d on

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

On Thu, 25 Dec 2003, Don Taber wrote:

> Contouring is broken in current cvs when hidden
> line removal is on.  Maybe a result of recent patch to fix
> breaks in contour lines?

Definitely.  The way hidden3d works is fundamentally incompatible with
keeping contour lines contiguous, anyway, but the patch breaks quite a bit
more badly than it has to.  

Expect an update of that soon.


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

Re: howto drive wgnuplot.

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

On Wed, 24 Dec 2003, Knoppix User wrote:

> i need a 2d library to plot a function in my application. is there a way
> to call wgnuplot from an other c++ application.

Yes.  You _popen() the pgnuplot.exe helper program and send your commands
to that pipe.

> or even simpler for the user to statically link gnuplot into my
> application. 

Not at this time, in any publically accessible version.

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

Re: tic marks for transformed axes

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

On Mon, 22 Dec 2003, Jim Van Zandt wrote:
> Hans-Bernhard Broeker <br...@ph...> wrote:

> >"Reasonable" being as subjective and volatile a quality as it is, that's
> >indeed a noble quest you've set out on ;-)
> 
> By "reasonable" I mean "strictly monotonic".

I would hope to restrict that a little further, to continuous, or even
differentiable functions. We'll have to invert those functions,
eventually, and that's a bitch to do if there are jumps in the input or
intervals where the function isn't defined...

> >>  - Don't allow tic labels to overlap.
> >
> >This is already quite hard to do, in general...
> 
> At the moment, the function uses a simple estimate.  Once it's
> integrated into gnuplot, it can use v_char and h_char.  Where that's
> not enough, maybe we could implement a user-supplied scaling
> parameter for h_char (so it would apply to all strings).

Or put to use the "guess" parameter the current algorithm already has
(currently fixed at 20, for hysterical reasons). Tell it to use fewer tics
if the font is large or the labels take up too much space.

> >> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> 
> so the documentation would be something like this:
> 
>    Syntax:
>          set xtics ... ({"<label>"} <pos> {level} {,{"<label>"}...) }
>    ...
>    The explicit ("<label>" <pos> <level>, ...) form allows arbitrary tic
>    positions or non-numeric tic labels.  In this form, the tics do not
>    need to be listed in numerical order.  Each tic has a 
>    position, optionally with a label.  Note that the label is
>    a string enclosed by quotes.  It may be a constant string, such as
>    "hello", may contain formatting information for converting the
>    position into its label, such as "%3f clients", or may be empty, "".
>    See `set format` for more information.  If no string is given, the
>    default label (numerical) is used.

I'm not sure that we actually can support %3f in the label string
of an explicit tic list, right now.  If you want the number formatted into 
the label, you currently have to leave out the label string and fall back
to 'set format', as far as I'm aware.

>    An explicit tic mark has a third parameter, the "level".  The default
>    is level 0, a major tic.  A level of 1 generates a minor tic.  If the
>    level is specified, then the label must also be supplied.

No.  Something like

	set xtics (1 1, 2 1, 3 2, 4 2)

should be allowed.  If only because it's awkward to express optional
entries being coupled to each other on two sides of a non-optional one,
in the syntax short-hand.

> The only awkward part is that minor tics are signaled twice - once by
> the empty label string and again by the nonzero level.  However, it
> maintains upward compatibility, and as you say it generalizes to more
> sizes of tics.

And to labelled minors right away.

> >and 'set log x'
> >would then internally be mapped to 'set transform x log10(x)'
> 
> Okay.  My first instinct is to hold off on this last step until the
> new transformed autotic function is thoroughly tested.  On the other
> hand, using it for log plots by default will certainly exercise it
> more!

Definitely.  Getting those log-ticks to behave sensibly in the face of
round-off errors was _very_ tricky business.  Just check out all that
business about having to look at the precision of the %l part to correctly
round the %L part in a

	set format x '%5.3l * b^%L'

situation...

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

Re: tic marks for transformed axes

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

On Friday 26 December 2003 03:26 pm, Jim Van Zandt wrote:
>
> I've checked code into CVS that implements levels 0 and 1.
> I'd appreciate if you would run the demo

Jim:

	I ran into a minor issue when updating my patch for
handling string data so that it would apply on top of your new
code.  My patch revises add_tic_user() so that it maintains the
tic entries as sorted lists, allowing only one tic entry for any
given axis coordinate. Your demo scripts revealed a difference
between my patched version and the current behaviour,
but in thinking about it I decided both were incorrect.

The issue is what to do when a minor tic entry and a 
major tic entry both have the same coordinate.  My code
was keeping whichever was specified last.  The current
code keeps both.  Either way potentially causes a
problem, either by over-printing two labels at the same 
place or by losing a desired tic label.

I modified my patch so that only the tic with the lowest
"level" code is kept; i.e. major tics trump minor tics.
This makes your demo scripts behave the same as on
the unpatched cvs version.
I *think* this is the right thing to do, but maybe someone
can offer arguments for a different approach.  Would there
ever be explicit minor tic labels that should over-ride the
[possible null] major tic labels?

I don't see an easy way to even detect this condition in
the current code, though.  So if both major tic labels and
minor tic labels are present they will print on top of each
other at major tic locations.  Maybe we can live with this
though the next release.   Or else I could break out just
the sorted-tic-lists part of the datastrings patch and apply
that to the cvs version sooner rather than later. 

What do you all think?


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

Re: tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>While I do like the general idea of allowing user-placed minitics, I
>strongly dislike that syntax.  Making a distinction between '' and ' '
>is bound to counter-intuitive...
>
>Here's a possible alternative, which would also allow for a possible
>extension to more than 2 kinds of tics in the future:
>
>	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
>                   "here" 14 1, "top" 20)
>
>which would express that there are labelled major (level-0) tics at 0
>and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
>and a labelled minor tic (level 1) at 14.

I've checked code into CVS that implements levels 0 and 1.

I've also updated my demo program at http://jrv.oddones.org/ to use
the new syntax.  I'd appreciate if you would run the demo
(i.e. download http://jrv.oddones.org/transform-0.6.tar.gz, unpack,
and type "make plots").  

I'll be working on the tic routines over the next few days, but will
be traveling so probably won't see any discussion until I return.

	   - Jim Van Zandt

contouring broken with hidden3d on

[Don T. <dt...@to...>]

Contouring is broken in current cvs when hidden
line removal is on.  Maybe a result of recent patch to fix
breaks in contour lines?

Don Taber

autoconf macro AC_FUNC_SELECT

[Jim V. Z. <jr...@co...>]

Lately when I do "cvs update" I get a series of warning like this:

 cvs server: conflict: Makefile.in is modified but no longer in the repository

I tried to fix that by moving the files aside and recreating them, but
had a lot of trouble getting configuration working again.  I got a lot
of warnings from automake (or maybe it was autoconf) about an invalid
macro AC_FUNC_SELECT.  "prepare" didn't help.  Eventually I stumbled
on a combination of automake, autoconf, aclocal, and prepare that is
working.  However, there seems to be a problem...

prepare claims:

  # Note that both autoconf 2.13/automake 1.5 and autoconf 2.5x/automake
  # 1.7 or newer may be used, although the gnuplot project continues to
  # use the former
  
However, autoconf 2.13 quits immediately because configure.in contains:

  AC_PREREQ(2.52)

I guess the comment in prepare is out of date.

configure.in also contains:

  dnl Argument types of select()
  AC_FUNC_SELECT

but AC_FUNC_SELECT is not documented in either autoconf 2.13 or 2.58.

Indeed, when I run configure I get this warning:
  
  ./configure: line 6936: AC_FUNC_SELECT: command not found

I guess it was replaced by AC_FUNC_SELECT_ARGTYPES, which
first appeared in autoconf 2.13 (May '99). 

I trace the usage like this:
  src/gplt_x11.c uses SELECT_FD_SET_CAST like this:

	nf = select(nfds, SELECT_FD_SET_CAST & tset, 0, 0, timer);

  which is defined in stdfn.h like this:

        #ifndef SELECT_FD_SET_CAST
        # define SELECT_FD_SET_CAST
        #endif

  In principle, SELECT_FD_SET_CAST could also be defined in config.h, 
  depending on config.hin and the results of autoconf tests
(e.g. AC_FUNC_SELECT). Apparently since AC_FUNC_SELECT never runs,
SELECT_FD_SET_CAST never really contributes anything.
  
I suggest:
  update the comment in "prepare" to require autoconf 2.5x/automake 1.7
  delete the reference to AC_FUNC_SELECT in configure.in
  delete SELECT_FD_SET_CAST from gplt_x11.c.

Alternatively:
  configure.in should call AC_FUNC_SELECT_ARGTYPES
  in gplt_x11.c (and also in src/fit.c), the second argument to select
should be cast to SELECT_TYPE_ARG234.  Likewise cast the first
argument to SELECT_TYPE_ARG1 and the last argument to SELECT_TYPE_ARG5.
  
Are the nonstandard version of select() common enough to justify the latter?

		- Jim Van Zandt

howto drive wgnuplot.

[Knoppix U. <as...@cl...>]

i need a 2d library to plot a function in my application. is there a way
to call wgnuplot from an other c++ application.or even simpler for the
user to statically link gnuplot into my application.
if yes. please let me know
thanks
any help is very much apreciated.

Re: updated faq

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

On Monday 22 December 2003 13:55, Petr Mikulik wrote:
> I've modified faq.tex on sourceforge:
> Please have a look too.

OK.  I made a pass over it also.

> There are definitely some URLs that needs to prove whether they exists.

I didn't go through all of these - still needs to be done.

> There is a (for me) "strange section" on pgm, pbm et al formats and
> utilities. Maybe it needs a rewrite?

I took it out, in favor of a general statement about using ImageMagick
or the Gimp to process pixel-based image output.  I also deleted=20
discussions that date back to the 'good old days' of the net; e.g.
recommendations to look for files using archie.

Question:

Is it really possible for external users to send mail to
gnu...@li...?
I had the impression that only mail from subscribers gets through to
the list.

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

Re: tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>
>> I'd like to generalize this, at least for the equivalent of "probability
>> paper" and "weibull plots", and preferably for any reasonable
>> user-supplied function. 
>
>"Reasonable" being as subjective and volatile a quality as it is, that's
>indeed a noble quest you've set out on ;-)

By "reasonable" I mean "strictly monotonic".

>>  - Don't allow tic labels to overlap.
>
>This is already quite hard to do, in general...

At the moment, the function uses a simple estimate.  Once it's
integrated into gnuplot, it can use v_char and h_char.  Where that's
not enough, maybe we could implement a user-supplied scaling
parameter for h_char (so it would apply to all strings).

>> 1. Provide for user mini-tics.  Currently the user can provide tic marks
>> with a command like
>>   set ytics ("bottom" 0, "" 10, "top" 20) 
>> 
>> However, only full size tic marks can be generated by this mechanism.
>> I propose a patch below that will generate a minitic for a null label
>> "".  The user can still get a full size tic with no label by putting
>> one or more spaces in the label string.
>
>While I do like the general idea of allowing user-placed minitics, I
>strongly dislike that syntax.  Making a distinction between '' and ' '
>is bound to counter-intuitive...
>
>Here's a possible alternative, which would also allow for a possible
>extension to more than 2 kinds of tics in the future:
>
>	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
>                   "here" 14 1, "top" 20)
>
>which would express that there are labelled major (level-0) tics at
>0 and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
>and a labelled minor tic (level 1)  at 14.

so the documentation would be something like this:

   Syntax:
         set xtics ... ({"<label>"} <pos> {level} {,{"<label>"}...) }
   ...
   The explicit ("<label>" <pos> <level>, ...) form allows arbitrary tic
   positions or non-numeric tic labels.  In this form, the tics do not
   need to be listed in numerical order.  Each tic has a 
   position, optionally with a label.  Note that the label is
   a string enclosed by quotes.  It may be a constant string, such as
   "hello", may contain formatting information for converting the
   position into its label, such as "%3f clients", or may be empty, "".
   See `set format` for more information.  If no string is given, the
   default label (numerical) is used.
  
   An explicit tic mark has a third parameter, the "level".  The default
   is level 0, a major tic.  A level of 1 generates a minor tic.  If the
   level is specified, then the label must also be supplied.
  
   Examples:
         set xtics ("low" 0, "medium" 50, "high" 100)
         set xtics (1,2,4,8,16,32,64,128,256,512,1024)
         set ytics ("bottom" 0, "" 10, "top" 20)
         set ytics ("bottom" 0, "" 10 1, "top" 20)
  
   In the second example, all tics are labelled.  In the third, only the end
   tics are labelled.  In the fourth, the unlabeled tic is a minor tic.

The only awkward part is that minor tics are signaled twice - once by
the empty label string and again by the nonzero level.  However, it
maintains upward compatibility, and as you say it generalizes to more
sizes of tics.

>> The algorithm is more complicated than I like, but I could not get any
>> of the simpler things I tried to work.  There are still some cases
>> that don't come out right.

However, it handles a lot of cases well :-)

>> I propose leaving "logscale" alone, but adding a "transform" option to
>> xtics as follows:
>> 
>>        set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
>>                  {  autofreq
>>                   | <incr>
>>                   | <start>, <incr> {,<end>}
>>                   | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
>>                   | transform <function> }
>>                  { font "name{,<size>}" }
>>                  { textcolor <colorspec> }
>
>No. If we do add axis transformation, it really must be applied not only
>to the tics, but to the plotted data, too, so this option has no business
>hiding itself under the coat of 'set xtics'.  This really should become a
>new command 'set transform {x|y|x2|y2|z|c} <function>', 

agreed

>and 'set log x'
>would then internally be mapped to 'set transform x log10(x)'

Okay.  My first instinct is to hold off on this last step until the
new transformed autotic function is thoroughly tested.  On the other
hand, using it for log plots by default will certainly exercise it
more!

I'll work on implementing user mini-tics with your syntax, unless
someone comes up with a better idea.

		- Jim Van Zandt