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

Re: pasting code into gnuplot

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

On Sat, 10 Jan 2004, Petr Mikulik wrote:

> As I said earlier, I don't know about the techniques you describe in the
> previous letters .. but cannot be something modern used to get rid of these
> problems? 

Modern solutions have the crucial problem of being modern; meaning that
they're not particularly unified or reliably available all across the
spread of platforms we're dealing with.

>   Or would this mean big non-portability to different X11 systems?

I strongly suspect so.

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

Re: pasting code into gnuplot

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

On Saturday 10 January 2004 01:07 pm, Petr Mikulik wrote:
> cannot be something modern used to get rid of these
> problems? E.g. pthreads. There can be a thread waiting for mouse/hotkey
> actions, and it may be triggered by mutexes or semaphores.

Putting all the mouse handling in a separate thread would work (I think).
I don't at the moment see how it would work for hotkeys, though.
A hot-key triggered command should be treated identically to the
same thing typed from the command line, including effects on subsequent
plotting commands.  Is that possible with pthreads?  That is, are
changes to global variables in one thread seen by the others?

> Get rid of stdin to gnuplot_x11 and use named pipe or fifo.

I am not aware of a problem with the input stream to gnuplot_x11.
What did you have in mind?  The problem we have at the moment
is with multiple inputs to gnuplot itself.

>   Or would this mean big non-portability to different X11 systems?

I don't know.  But if we were going to move to a threaded implementation
of gnuplot, I would want to look at making even larger scale use of it.
For example, would it make any sense to spawn off a new thread for each
new plot?  That would be an easier way to achieve multiple active
plots than Dan's current dream of making all the internal data structures
into linked lists.


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

Re: pasting code into gnuplot

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

As I said earlier, I don't know about the techniques you describe in the
previous letters .. but cannot be something modern used to get rid of these
problems? E.g. pthreads. There can be a thread waiting for mouse/hotkey
actions, and it may be triggered by mutexes or semaphores. Get rid of stdin
to gnuplot_x11 and use named pipe or fifo.
  Or would this mean big non-portability to different X11 systems?

---
Petr Mikulik

Re: pasting code into gnuplot

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

On Sat, 10 Jan 2004, Daniel J Sebald wrote:

[....]
> You'll have to forgive me.  I've tried following the code to see exactly 
> the path that the commands come in via stdin, where the pipe is read for 
> the mouse, etc. and I'm having a difficult time keeping track of it all. 

The core function is generally term->waitforinput(), which in the case of
the x11 terminal is provided by X11_waitforinput() in term/x11.trm.  
There are different call paths leading there.  Let me provide an overview.
Cscope helps:

C symbol: waitforinput

  File       Function      Line
0 term_api.h <global>       172 int (*waitforinput) __PROTO((void ));
1 command.c  pause_command  961 if (term && term->waitforinput) {
2 command.c  pause_command  964 term->waitforinput();
3 command.c  fgets_ipc     2212 if (term && term->waitforinput) {
4 command.c  fgets_ipc     2219 c = term->waitforinput();
5 readline.c getc_wrapper    84 if (term && term->waitforinput && interactive) {
6 readline.c getc_wrapper    88 c = term->waitforinput();
7 readline.c ansi_getc      775 if (term && term->waitforinput && interactive)
8 readline.c ansi_getc      776 c = term->waitforinput();

The call paths ultimately start at read_line in command.c.  I'll assume
MOUSE is active:

no READLINE (neither gnuplot's own, nor -lreadline):
	GET_STRING ==> fgets
some READLINE, !interactive: 
	fgets_ipc ==> term->waitforinput
GNU libreadline, interactive:
	read_line ==> rlgets ==> readline_ipc ==> rl_callback_read_char
	(getc_wrapper passed to libreadline as input hook)
gnuplot readline.c, interactive:
	read_line ==> rlgets ==> readline_ipc ==> readline
	==> special_getc ==> ansi_getc

So that's how we get to the core function. Now let's look at
X11_waitforinput itself: it uses select() to dispatch between the two
input streams.  The root of all our trouble is that select() operates not
on <stdio.h> objects like stdin, but rather on unbuffered Unix file
handles.  I.e. select doesn't know a thing about <stdio.h> buffering.

> I find it hard to fathom that this is not possible.  

It's quite certainly possible.  The tricky part is to make it possible
in the context of a massively portable program like gnuplot, without 
breaking the whole program for use on other platforms.

> I mean, doesn't this seem like a fundamental task of operating systems?  
> That is, to distribute I/O around the system?  Let's consider an fread()
> or a fgets() or fgetc().  

For starters, fgetc() and friends aren't even functions of the operating
system to begin with.  They're functions of the C runtime library --- but
ISO/ANSI C doesn't standardize asynchronous I/O. 

> Can't I just do an fread() from the stdin (the place where the commands
> are typed in) and whatever is there I store in a "command buffer" and as
> I'm putting the characters in a command buffer I watch for the "new
> line" or "end of gnuplot command" character.

No, you can't.  The reason is that file I/O on Unix (and all other
platforms I've seen) is by default a "blocking" operation:

> If there is nothing in the buffer or there are less characters than
> asked for, doesn't the fread() simple return and EOF or -1 or number of
> bytes read?

If there's buffered input, but less than requested, it'll return what
there is. But if there's currently _nothing_ in the buffer, it won't
return at all until there is.  You only get an EOF condition if the stream
is actually ended (typical Unix setup: if you typed Ctrl-D at the
keyboard), not if there's just no buffered input available at the moment.

> >F) The usual way around this dilemma is to use poll or select to notify
> >   us when either or both of two input streams is presenting new data.
> >   We currently use select in X11_waitforinput().
> >
> 
> Yes, this is one way.  But if "fread()" is inherently forced to return 
> something even if the buffer is empty, isn't that a form of polling the 
> input as well?  

The problem is we *can't* force fread() to do that.  Non-blocking I/O
is not foreseen in the context of <stdio.h> functions.

> As I said before, it seems to me that current Gnuplot 
> really isn't wanting polling for "characters available", rather it is 
> attempting to poll for "gnuplot command in buffer available" and "mouse 
> command in buffer available".

I'm quite sure that reading characters versus lines is unrelated to the
problem at hand.

> >G) Unfortunately, poll/select notification depends on whether the
> >   input stream is buffered or non-buffered.   I do not know if this is
> >   supposed to be the case, but that's what we see in practice.

Indeed select() doesn't know a thing about buffering, so it will not
report a stream as having data available if all of it is buffered.  

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

Re: pasting code into gnuplot

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

Ethan Merritt wrote:

>On Friday 09 January 2004 14:50, Daniel J Sebald wrote:
>  
>
>>If you turn off buffering immediately after startup, what if a
>>number of Gnuplot commands are already in the buffer?
>>    
>>
>
>Since piping now works, this is demonstrated not to be a problem.
>Of course if you have a test example that fails, I will glumly
>retract that optimistic statement.
>
>  
>
>>Thus the only way to resolve the race condition, in one form
>>or another from Gnuplot, is for there to be an ability for the "setvbuf"
>>command to return the contents of the buffer right before it was
>>changed.
>>    
>>
>
>Not possible. See "man setvbuf".
>

I searched for info.  As usual, the man doesn't seem to give details of 
the tricky aspects.

>>1)  Fix up the I/O scheme so that gnuplot doesn't wait on keyboard
>>input.  Whenever keyboard input is available then parse it.
>>    
>>
>
>Now you are getting near to the heart of it.  Most of our current
>problem comes from not being able to tell when input is available
>without trying to read it.  And if we try to read it, then we are stuck
>waiting until success.
>
>The central problem is that there are few (actually none that I know of)
>portable methods of reading from two or more input sources at the same
>time.  I know perfectly well how to do it under VMS but, sadly, other
>operating systems are not so capable [grin, duck, and run].
>

You'll have to forgive me.  I've tried following the code to see exactly 
the path that the commands come in via stdin, where the pipe is read for 
the mouse, etc. and I'm having a difficult time keeping track of it all. 
 So I'm going to play devil's advocate here and ask naive questions.

I find it hard to fathom that this is not possible.  I mean, doesn't 
this seem like a fundamental task of operating systems?  That is, to 
distribute I/O around the system?  Let's consider an fread() or a 
fgets() or fgetc().  Can't I just do an fread() from the stdin (the 
place where the commands are typed in) and whatever is there I store in 
a "command buffer" and as I'm putting the characters in a command buffer 
I watch for the "new line" or "end of gnuplot command" character.  When 
the end of command character is found, then shuffle that string over to 
the current command parsing stuff.  If there is nothing in the buffer or 
there are less characters than asked for, doesn't the fread() simple 
return and EOF or -1 or number of bytes read?

Then, do the same with the mouse stream.

It sounds to me, correct me if I'm wrong, that Gnuplot is now attempting 
a graceful method of trying to get a complete command from both the 
mouse and the keyboard whenever either is available.  Is this what you 
mean by asynchronous?  If an operating system can do that, that is 
impressive.  But no, I would not expect that to be a feature of all 
operating systems.  It seems to me then, that for Gnuplot (to be 
portable) is the one that needs to do all the work of reconstructing the 
input streams.

Let me attempt a description of what I'm saying without writing the full 
code.  Say there is a "keyboard_stream" and a "mouse_stream".  We make 
internal buffers inside Gnuplot of length, say 200.

keyboard_command_buff[201];
mouse_command_buff[201];
keyboard_buff_ptr = 0;
mouse_buff_ptr = 0;

while (not_end_of_Gnuplot) {

    int number_chars;

    /* Check if there is keyboard input, if so check if a valid command 
is complete. */
    number_chars = fread(keyboard_stream, 
&keyboard_command_buff[keyboard_buff_ptr], 200-keyboard_buff_ptr);   /* 
That is, read up to whatever is space is left in the buffer */
    if (number_chars > 0) {
       [search through the characters just read and test for end of command]
       if (this is valid end of command)  {
           execute gnuplot command;
           copy any chunk left in buffer to the start of buffer;
           keyboard_buff_ptr = 0;
       } else {
           keyboard_buff_ptr += number_chars;
       }
    }
     if (end of buffer has been reached)
         [issue error to the console]


    /* Check if there is mouse input, if so check if a valid mouse 
string is complete. */
   [Do the same for the mouse stream as is done above for the keyboard.]

}


The input method just keeps going around in the loop and never waits on 
anything.  It may be that only a few characters are read at a time, but 
so what.  It isn't like this needs to be super efficient as though it 
were a time critical communication scenario.  We're waiting on mouse and 
keyboard commands which are rather slow I assume.

Is there some issue with buffered mouse characters piling up in the 
stream while a Gnuplot command is being processed?

(more below)

>The current scheme under linux  depends on select(). This scheme,
>problems and all, is the closest thing to simultaneous/asynchronous
>input that I know of in standard linux/unix.
>That said, I am hardly an expert on linux asynchronous I/O.
>
>Here is the bind we are in, as I understand it for the linux+X11 case:
>

Nice summary.  Thanks.

(more below)

>A) We have terminal input coming in on stdin; we have mouse input
>   coming in via a pipe.
>
>B) These two input sources are asynchrounous.  That is, we don't
>   know which one will be the next to provide new input.
>

The scheme I describe above attempts to handle this, I think.

>C) We have non-mouse (font, window size, etc) information coming
>   back over the pipe also. This could be split off from the mouse pipe,
>   but that does not make things any easier, so let's disregard it.
>

This should be fine I think.

>D) If you do a read/scanf/gets/whatever from stdin then you will
>   miss all mouse input until you get the next chunk of terminal input.
>

Please explain why this is.  I'm to lazy to do a test trial at this 
hour, but won't fread() on stdin just send back and EOF or -1 or 
something if there are no characters in the buffer?

>E) Conversely if you do a read/scanf/gets/whatever on the mouse pipe
>   then you can't even look for new terminal commands until after the
>   next mouse event (which may never arrive).
>
>F) The usual way around this dilemma is to use poll or select to notify
>   us when either or both of two input streams is presenting new data.
>   We currently use select in X11_waitforinput().
>

Yes, this is one way.  But if "fread()" is inherently forced to return 
something even if the buffer is empty, isn't that a form of polling the 
input as well?  As I said before, it seems to me that current Gnuplot 
really isn't wanting polling for "characters available", rather it is 
attempting to poll for "gnuplot command in buffer available" and "mouse 
command in buffer available".

>G) Unfortunately, poll/select notification depends on whether the
>   input stream is buffered or non-buffered.   I do not know if this is
>   supposed to be the case, but that's what we see in practice.
>
>H) More things seem to work when stdin is set to unbuffered,
>   hence the call to setvbuf().  Other things broke, because this caused
>   the current contents of the buffer to be lost.   Note that this behaviour
>   is not documented anywhere I can find, but it makes sense and is
>   easily demonstrated. I am optimistic that this problem is minimized
>   by moving the setvbuf() call to the head of the program.
>
>I) Just to make things a little bit worse, we have commands like
>   'pause <n>' and 'pause mouse'.
>

Hey, these are easy to handle for the scheme above.  Deactivate the 
input test according to some timer, i.e.,

if (time expired >= n) {
  n = 0;
   /* The junk above */
}

Gnuplot will simply stop checking for input in the appropriate stream 
for <n> seconds.  (This may not work... but that would be my first 
attempt at such.)

>J) Just to make things a little bit worse yet, we try to support gnu
>   libreadline,  which has its own quirks about handling input streams.
>

I would hope the this is fairly transparent to the C environment.

>K) And if all that was not complicated enough, people want to cut-and-paste
>   from X11.  This involves cooperation from the X server and from the
>   application windows (xterm, nedit, or whatever) on both the cut and the
>   paste end.  So far as I know, there is no guarantee that just because
>   it works for gnuplot running in an xterm window it will also work inside
>   konsole or kterm or Eterm or <alphabetofyourchoice>term.
>

Again, I would hope this is transparent to the C environment.  The 
cutting and pasting simply puts stuff into the "stdin" buffer, I'm guessing.

>
>Now that I understand the problem with setvbuf(), I am considerably
>more hopeful that we can get everything to work using the current
>scheme.  More hopeful than I was a week ago.
>poll/select is *supposed* to work, after all.
>But items I, J and K may still cause us problems.
>
>  
>
>>3)  Since gnuplot only has a "current plot" replot and not information
>>for all its plots, there needs to be some variable that keeps track of
>>which plot number corresponds with the "current plot" replot info.  That
>>way, the "replot" command can be reissued when the window number and the
>>replot info match.
>>    
>>
>
>That is a separate topic.
>Let's not mix the two.
>

Right.  That is something completely different.  I'm confused enough the 
way it is.

Anyway, tell me what is wrong with the approach I describe.  I guess my 
main point is that if you want Gnuplot to be portable, it's the one that 
will have to do all the work in determining "valid command line string 
available" and "valid mouse string available", not the system.

Dan

Re: pasting code into gnuplot

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

On Friday 09 January 2004 14:50, Daniel J Sebald wrote:
> If you turn off buffering immediately after startup, what if a
> number of Gnuplot commands are already in the buffer?

Since piping now works, this is demonstrated not to be a problem.
Of course if you have a test example that fails, I will glumly
retract that optimistic statement.

> Thus the only way to resolve the race condition, in one form
> or another from Gnuplot, is for there to be an ability for the "setvbuf=
"
> command to return the contents of the buffer right before it was
> changed.

Not possible. See "man setvbuf".

> I think the best solution here is to keep the two input streams
> independent.
[snip rest of long description]

What you describe is exactly what we are already doing.
Keeping track of multiple pipes is not a problem. Figuring out
how to read from more than one at a time *is* a problem.

> 1)  Fix up the I/O scheme so that gnuplot doesn't wait on keyboard
> input.  Whenever keyboard input is available then parse it.

Now you are getting near to the heart of it.  Most of our current
problem comes from not being able to tell when input is available
without trying to read it.  And if we try to read it, then we are stuck
waiting until success.

The central problem is that there are few (actually none that I know of)
portable methods of reading from two or more input sources at the same
time.  I know perfectly well how to do it under VMS but, sadly, other
operating systems are not so capable [grin, duck, and run].

The current scheme under linux  depends on select(). This scheme,
problems and all, is the closest thing to simultaneous/asynchronous
input that I know of in standard linux/unix.
That said, I am hardly an expert on linux asynchronous I/O.

Here is the bind we are in, as I understand it for the linux+X11 case:

A) We have terminal input coming in on stdin; we have mouse input
   coming in via a pipe.

B) These two input sources are asynchrounous.  That is, we don't
   know which one will be the next to provide new input.

C) We have non-mouse (font, window size, etc) information coming
   back over the pipe also. This could be split off from the mouse pipe,
   but that does not make things any easier, so let's disregard it.

D) If you do a read/scanf/gets/whatever from stdin then you will
   miss all mouse input until you get the next chunk of terminal input.

E) Conversely if you do a read/scanf/gets/whatever on the mouse pipe
   then you can't even look for new terminal commands until after the
   next mouse event (which may never arrive).

F) The usual way around this dilemma is to use poll or select to notify
   us when either or both of two input streams is presenting new data.
   We currently use select in X11_waitforinput().

G) Unfortunately, poll/select notification depends on whether the
   input stream is buffered or non-buffered.   I do not know if this is
   supposed to be the case, but that's what we see in practice.

H) More things seem to work when stdin is set to unbuffered,
   hence the call to setvbuf().  Other things broke, because this caused
   the current contents of the buffer to be lost.   Note that this behavi=
our
   is not documented anywhere I can find, but it makes sense and is
   easily demonstrated. I am optimistic that this problem is minimized
   by moving the setvbuf() call to the head of the program.

I) Just to make things a little bit worse, we have commands like
   'pause <n>' and 'pause mouse'.

J) Just to make things a little bit worse yet, we try to support gnu
   libreadline,  which has its own quirks about handling input streams.

K) And if all that was not complicated enough, people want to cut-and-pas=
te
   from X11.  This involves cooperation from the X server and from the
   application windows (xterm, nedit, or whatever) on both the cut and th=
e
   paste end.  So far as I know, there is no guarantee that just because
   it works for gnuplot running in an xterm window it will also work insi=
de
   konsole or kterm or Eterm or <alphabetofyourchoice>term.

Now that I understand the problem with setvbuf(), I am considerably
more hopeful that we can get everything to work using the current
scheme.  More hopeful than I was a week ago.
poll/select is *supposed* to work, after all.
But items I, J and K may still cause us problems.

> 3)  Since gnuplot only has a "current plot" replot and not information
> for all its plots, there needs to be some variable that keeps track of
> which plot number corresponds with the "current plot" replot info.  Tha=
t
> way, the "replot" command can be reissued when the window number and th=
e
> replot info match.

That is a separate topic.
Let's not mix the two.

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

Arnd Baecker wrote:

>Hi,
>
>On Wed, 7 Jan 2004, Ethan Merritt wrote:
>
>  
>
>>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
>>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?
>>    
>>
>
>Well, for me the picture is slightly different:
> a) on a PIV machine: no problems, pasting works, piping works
> b) on my PIII (which I used to do the testing):
>    - pasting does not work the first time
>    - piping seems to work fine now
>
>    I haven't done thorough testing yet, but this seems
>    to improve!
>  
>

 From Hans:

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

 From Arnd:

>Is the pasting problem related with what Hans just wrote/suggested
>"I.e. don't switch off buffering halfway into the program, but
>immediately after startup"?
>((Speculating: maybe a "fast" machine is fast enough to switch off
>buffering before something is written to the buffer?))
>

I wonder if there is any way of avoiding a race from the level of 
Gnuplot.  If you turn off buffering immediately after startup, what if a 
number of Gnuplot commands are already in the buffer?  (Sounds like a 
plausible situation.)  Then the commands will be lost.

Simply tossing out what is in the buffer of course won't do.

It seems to me that resolving the race condition can only be done at a 
low level.  Thus the only way to resolve the race condition, in one form 
or another from Gnuplot, is for there to be an ability for the "setvbuf" 
command to return the contents of the buffer right before it was 
changed.  Then one would have to reconstruct the input stream by storing 
that somewhere.  You can't store what is currently in the buffer then 
set the I/O stream to non-buffered as two independent actions. 
 Something could enter the I/O buffer in that time between the save and 
the set, for multitasking systems, and again characters will be lost. 
 Only the low level routines can protect the buffer from something new 
being entered.  Right?

I think the best solution here is to keep the two input streams 
independent.  Leave the keyboard stream as it is, no "setvbuf".  Create 
different pipes for the mouse (that can later be configured), I contend. 
 That means that upon creating an X11 plot window a pipe ID of some sort 
is passed to gnuplot_x11.  Create a variable in the plot structure of 
gnuplot_x11 and save that pipe ID in there and whenever there is a mouse 
action for that window, send its primitive mouse information out that 
pipe.  Whatever is on the other end of the pipe interprets the mouse 
commands.  The default handler on the gnuplot side is to reissue the 
"replot" command if appropriate.  Be consistent with who creates and 
deletes the pipes.  Probably gnuplot should create the pipes and 
gnuplot_x11 should be the one to delete them.  (That way, gnuplot_x11 
will never be sending data to a defunct pipe.  Note, it doesn't need to 
be Gnuplot that creates the pipe ID.  Perhaps a higher application could 
create the pipe and give a pipe ID as an argument to the "set term x11" 
command.)  From the gnuplot_x11 side of things it is fairly 
straightforward.  The work lies on the gnuplot side of things:

1)  Fix up the I/O scheme so that gnuplot doesn't wait on keyboard 
input.  Whenever keyboard input is available then parse it.

2)  A system for interpreting primitives coming across the various 
"mouse pipes"... or can I take the liberty of being ultra-silly here and 
coin the phrase "mouse holes", or better still "mouse traps" :) ... 
 Seriously, it would involve a mechanism for keeping track of the pipes, 
a linked-list sort of thing for the default handler.  Or an alternative 
would be one mouse hole (sick of this phrase already?) and the primitive 
info would include a plot number along with it.  [I'd prefer a linked 
list of connections, myself.]

3)  Since gnuplot only has a "current plot" replot and not information 
for all its plots, there needs to be some variable that keeps track of 
which plot number corresponds with the "current plot" replot info.  That 
way, the "replot" command can be reissued when the window number and the 
replot info match.

It sounds like a lot of work, but I don't think it is IMHO.  Linked 
lists are fairly straightforward, especially when they are so simple. 
 Putting effort into a new scheme seems wiser to me than attempting to 
resolve the race condition.  Are there unforeseen problems with losing 
primitives in the pipe somehow?  I don't know.

Any thoughts anyone?  Is keeping the mouse and keyboard separate a 
necessity?

Dan

Re: pasting code into gnuplot

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

On Fri, 9 Jan 2004, Hans-Bernhard Broeker wrote:

> On Thu, 8 Jan 2004, Arnd Baecker wrote:
>
> > After this the mouse coordinates in the plot window
> > are not updated anymore.
>
> That's not exactly a surprise.  When you made a plot to some other
> terminal driver, you essentially decoupled gnuplot_x11 from gnuplot,
> making several kinds of mouse interaction unavailable.  IOW,
> 'set term post ; replot' essentially acts as a (temporary) equivalent
> of 'set mouse off'.

Ok, I wasn't aware of this - so the solution ist pretty easy,
just add a replot at the end, i.e.
  set xrange [0:10]
  print "blurb"
  plot sin(x)
  set out "tst.ps"
  set term post
  rep
  set out
  set term x11
  replot
and the mouse works fine again.

Many thanks,

Arnd

Re: pasting code into gnuplot

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

On Thu, 8 Jan 2004, Arnd Baecker wrote:

> After this the mouse coordinates in the plot window
> are not updated anymore. 

That's not exactly a surprise.  When you made a plot to some other
terminal driver, you essentially decoupled gnuplot_x11 from gnuplot,
making several kinds of mouse interaction unavailable.  IOW,
'set term post ; replot' essentially acts as a (temporary) equivalent
of 'set mouse off'.

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

Re: pasting code into gnuplot

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

Hi,

sorry for creating confusion, both machines now behave the same way.
(It seems that my first checkout from CVS still contained the old
version. To check on the other machine I did another checkout
a couple of hours later ... - mea culpa, I should have thought
about the sourceforge delay ;-)

To summarize:
  - pasting works
  - piping works

However, I observe the following (small) glitch:
Again pasting the following
  plot sin(x)
  set out "t1.ps"
  set term post
  rep
  set term x11
  set out
After this the mouse coordinates in the plot window
are not updated anymore. After pressing
 "b" or "7"   (`builtin-toggle-ratio`) or zooming
it works again.


And now for something related ;-):
To make me fully happy I would like to ask if someone
has an idea on the following:

I would like to do something like this
#####################################
from GnuplotBiDir import Gnuplot
gp=Gnuplot()
gp("set mouse")       # activate mouse
gp("plot sin(x)")
print "Now get coordinates of a mouse-click:"
gp("pause mouse 'click with mouse' ")
#raw_input("and press enter here after that")
mouse_x=gp.getvar("MOUSE_X")
mouse_y=gp.getvar("MOUSE_Y")
print mouse_x,mouse_y
######################################
Here gp("...") sends the string to gnuplot via a pipe.
and gp.getvar("variable") fetches the variable given as argument.

Of course, this cannot work as the calling program does not
wait for the mouse-click. Uncommenting the raw_input
allows for the expected behaviour, but one has to press
enter after the mouse-click.
Is there a better way for doing this ?


Again many thanks,

Arnd

Re: pasting code into gnuplot

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

> 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

There are no problems there. There is a bidirectional named pipe
gnuplot/pm.trm <=> gnupmdrv.exe, and mousing commands gnupmdrv => gnuplot
go via shared memory and an event semaphore. Commands from user/gnuplot and
mouse/hotkey/gnupmdrv don't mix because the waiting for mouse commands is
encapsulated in a thread, see command.c.

---
Petr Mikulik

Re: pasting code into gnuplot

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

Hi,

On Wed, 7 Jan 2004, Ethan Merritt wrote:

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

Well, for me the picture is slightly different:
 a) on a PIV machine: no problems, pasting works, piping works
 b) on my PIII (which I used to do the testing):
    - pasting does not work the first time
    - piping seems to work fine now

    I haven't done thorough testing yet, but this seems
    to improve!

Is the pasting problem related with what Hans just wrote/suggested
"I.e. don't switch off buffering halfway into the program, but
immediately after startup"?
((Speculating: maybe a "fast" machine is fast enough to switch off
buffering before something is written to the buffer?))

Many thanks,

Arnd

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.