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/