Menu
▾
▴
gnuplot-beta
|
From: Arnd B. <arn...@we...> - 2004-01-06 08:32:02
|
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 ;-) ...
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-01-07 23:54:51
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-01-08 07:59:38
|
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 |
|
From: Arnd B. <arn...@we...> - 2004-01-08 08:12:55
|
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
|
|
From: Arnd B. <arn...@we...> - 2004-01-08 12:51:23
|
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
|
|
From: Arnd B. <arn...@we...> - 2004-01-09 09:40:56
|
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
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-01-11 21:23:19
|
On Thursday 08 January 2004 12:05 pm, Arnd Baecker wrote:
> 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
> ######################################
> Of course, this cannot work as the calling program does not
> wait for the mouse-click.
I have placed a fix for this in CVS. 'pause mouse' was terminating
on either a mouse click or a <cr> on stdin. That is OK for
terminal input, but with piped input there may already be multiple
commands backed up in the pipe, in which case it would not wait
for a mouse click. As of now the behaviour is changed to only
terminate 'pause mouse' on a mouse click or on ctrl-C.
I also added some sanity checking so that you cannot get
stuck waiting for 'pause mouse' if mousing is not active.
Note that requesting "set mouse" before plotting is essential.
The default for piped input is to disable mousing.
--
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle
|
|
From: Daniel J S. <dan...@ie...> - 2004-01-09 22:32:24
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-01-10 00:09:25
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-01-10 07:24:22
|
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
|
|
From: Petr M. <mi...@ph...> - 2004-01-10 21:07:56
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-01-10 22:52:11
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-01-11 17:02:15
|
Ethan A Merritt wrote: >On Saturday 10 January 2004 01:07 pm, Petr Mikulik wrote: > > >> 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. > There goes my pipe dream. Dan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X