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