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

combining binary+vector terminals

[Mojca M. <moj...@gm...>]

Hello,

I'm using gnuplot a lot for different kinds of graphs. I'm mostly
using the TeX terminal (my own one, ConTeXt), but as soon as one wants
to draw a complicated graphic (it's enough to request this:
http://gnuplot.sourceforge.net/demo_4.3/pm3d.8.png) the following
happens:
- TeX runs out of memmory very quickly
- even if TeX manages to process the graphic, desplaying it becomes
extremely slow if you ask any PS/PDF viewer to display one million
points or lines; it needs to draw every line separately even if most
of them are hidden
- If I want to use 3D, I would like to display at least 200x200 or
better grid (let alone the fact that I don't like the straight lines
when smooth splines could be used, but I know that I cannot request
gnuplot to do that), or I would like to draw several million points
when drawing scatter plots; that's too much to request from either TeX
or the viewer

If I use GD terminal, then I'm very limited with the labels I use (I
cannot use TeX tricks on them, the fonts don't scale, switching fonts
is very complicated and not too much platform-independent; I'm
copiling my documents on multiple platforms) etc. etc.

I would like to create a terminal that would combine some "pixel"
terminal with a TeX terminal. The same has been done with epslatex
where PS takes care for graphical part of the plot and TeX is used for
generating labels. I would like to do the same, but in the way that
drawing pixel data is delegated to some third terminal that generates
a PNG figure (could be GD or pango or whatever) and TeX labels are
handled with the TeX terminal. TeX would then include the generated
PNG image and draw true labels on top of image.

My main question is: how difficult is the configuration process that
needs to be done in the background? I know a bit about programming and
managed to write a terminal that works OK, but I don't understand a
bit about configuring the bits and pieces, so that the code compiles
properly when using different libraries.

I would be grateful for any pointers, opinions or idas.

Thanks,
    Mojca

New Lua/TikZ-terminal patch for testing

[Peter H. <pe...@af...>]

Hi,

there is a new patch (lua_terminal_rev96_20090329.patch) in the patch tracker
(http://sourceforge.net/tracker/?func=detail&aid=2183264&group_id=2055&atid=302055) 
for testing, that addresses a few things discussed before.

The most important change is the new naming scheme of the Lua terminal:

  * Providing a script or target name is now mandatory. The new syntax:
       set terminal lua <target name> | "<file name>"
                        {<script_args> ...}
    This will look for a script named `gnuplot-<target name>.lua' or
    a script named "<file name>".
  * Support for script names via the environmental variable
    GNUPLOT_LUA_SCRIPT is dropped.
  * The option "script" is obsolete and also removed.
  * Via the environmental variable GNUPLOT_DRIVER_DIR the default search
    directory for target scripts can be changed.

This way adding new target scripts is straightforward. And also using modified 
ones in local directories is still possible and I hope intuitive.

Secondly, the TikZ target's help is now added to the standard documentation 
and can be generated from the script by calling 
 # lua gnuplot-tikz.lua termhelp > gnuplot-tikz.help


Feedback is most welcome!

-Peter

Version 4.2.5 released

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

Version 4.2.5 is now available for download from SourceForge.
There may be a delay before it is visible from mirror sites.

Thanks to everyone who found and reported last minute bugs or other issues

-- 
Ethan A Merritt

Re: readline on Mac problems again

[Mojca M. <moj...@gm...>]

On Sun, Mar 29, 2009 at 19:52, Ethan A Merritt wrote:
> On Sunday 29 March 2009, Dmitri A. Sergatskov wrote:
>> On Sun, Mar 29, 2009 at 7:33 AM, Mojca Miklavec wrote:
>> > Hello,
>> >
>> > I have reinstalled my MacOS X 10.5 from scratch. After trying to build
>> > gnuplot I get the following error reports
>
> As of recently, gnuplot allows a 3rd option for line input.
> You can configure it to use the NetBSD editline library
>        ./configure --with-readline=bsd
>
> But there is still a missing piece.
> The MacOS so-called "readline" library is really  a wrapper for the BSD editline
> library.  So gnuplot _could_ use it if it were named correctly.  But since it
> calls itself "readline" rather than "editline" we cannot detect it automatically.
> I imagine this MacOS craziness could be detected and worked around by the
> gnuplot configuration script, but no one has yet contributed a modified script
> to handle it.

The --with-readline=bsd works nicely. One question: what advantages
does the true GNU readline have over editline? If there are no big
differences, maybe something like "if this is mac, use
--with-readline=bsd by default" would work?

(I can imagine people having gnu readline installed, but they could
invoke it with --with-readline=gnu, at least until someone figures out
how to figure out which library is being used.)

Thanks,
    Mojca

Re: Enhancement Request: output pipe for interogation commands

[Ben A. <bpa...@ma...>]

nabed wrote:
> 
> Thanks Ethan,
> 
> The final part of the question is to provide the ability for the user to
> graphically add new points onto a given graph by clicking on a location on
> the graph. e.g say I have a smooth function and want to add a bump to it
> in a region, I could replace three existing points by adding three new
> points (via mouse interaction on the graph window) and then form a new
> smooth interpolated graph containing the new points. I would then want to
> get the new dataset back from gnuplot.
> 
> Serle
> 

As Petr mentioned Octave is able to communicate with gnuplot and obtain
information with regards the mouse. You might find it useful to look over
that solution.

http://hg.savannah.gnu.org/hgweb/octave/file/8651fcc89556/scripts/plot/__gnuplot_ginput__.m

The pipe/plot-stream is opened in the routine below

http://hg.savannah.gnu.org/hgweb/octave/file/8651fcc89556/scripts/plot/gnuplot_drawnow.m

Ben

-- 
View this message in context: http://www.nabble.com/Enhancement-Request%3A-output-pipe-for-interogation-commands-tp22495484p22770790.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: readline on Mac problems again

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

On Sunday 29 March 2009, Dmitri A. Sergatskov wrote:
> On Sun, Mar 29, 2009 at 7:33 AM, Mojca Miklavec
> <moj...@gm...> wrote:
> > Hello,
> >
> > I have reinstalled my MacOS X 10.5 from scratch. After trying to build
> > gnuplot I get the following error reports (the repository is from
> > 3.3.2009; I'll upgrade to the latest version asap).
> >
> > I almost urgently need a working version of self-compiled gnuplot, so
> > I might install the needed packages in the meantime, but I can provide
> > some more feedback if needed (under assumption that it won't start
> > working out-of-the-box in the meantime after I start installing
> > additional packages).
> >
> > Mojca
> >
> > g++  -g -O2   -o gnuplot alloc.o axis.o binary.o breaders.o bitmap.o
> > color.o command.o contour.o datafile.o dynarray.o eval.o fit.o
> > gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o
> > internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o
> > plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o
> > standard.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o
> > util3d.o variable.o version.o   -lreadline  -lncurses  -lz
> > Undefined symbols:
> >  "_rl_forced_update_display", referenced from:
> >      _restore_prompt in command.o
> >  "_rl_ding", referenced from:
> >      _alert in mouse.o
> >  "_history_list", referenced from:
> >      _write_history_list in history.o
> >  "_rl_complete_with_tilde_expansion", referenced from:
> >      _rl_complete_with_tilde_expansion$non_lazy_ptr in plot.o
> >  "_rl_reset_after_signal", referenced from:
> >      _main in plot.o
> > ld: symbol(s) not found
> > collect2: ld returned 1 exit status
> > make[3]: *** [gnuplot] Error 1
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> 
> 
> This looks to me as usual MaCOS problem with its readline not being
> real readline. There are few ways to solve it, perhaps the simplest is to pass
> "-with-readline=no" to configure.


Yup. Same problem as always.  MacOS tells a lie that it provides libreadline.
Please see the comments and discussion on
https://sourceforge.net/tracker/?func=detail&aid=1839048&group_id=2055&atid=102055

As of recently, gnuplot allows a 3rd option for line input.
You can configure it to use the NetBSD editline library
	./configure --with-readline=bsd

But there is still a missing piece.
The MacOS so-called "readline" library is really  a wrapper for the BSD editline
library.  So gnuplot _could_ use it if it were named correctly.  But since it
calls itself "readline" rather than "editline" we cannot detect it automatically.
I imagine this MacOS craziness could be detected and worked around by the
gnuplot configuration script, but no one has yet contributed a modified script
to handle it.

-- 
Ethan A Merritt

Re: readline on Mac problems again

[Dmitri A. S. <das...@gm...>]

On Sun, Mar 29, 2009 at 7:33 AM, Mojca Miklavec
<moj...@gm...> wrote:
> Hello,
>
> I have reinstalled my MacOS X 10.5 from scratch. After trying to build
> gnuplot I get the following error reports (the repository is from
> 3.3.2009; I'll upgrade to the latest version asap).
>
> I almost urgently need a working version of self-compiled gnuplot, so
> I might install the needed packages in the meantime, but I can provide
> some more feedback if needed (under assumption that it won't start
> working out-of-the-box in the meantime after I start installing
> additional packages).
>
> Mojca
>
> g++  -g -O2   -o gnuplot alloc.o axis.o binary.o breaders.o bitmap.o
> color.o command.o contour.o datafile.o dynarray.o eval.o fit.o
> gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o
> internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o
> plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o
> standard.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o
> util3d.o variable.o version.o   -lreadline  -lncurses  -lz
> Undefined symbols:
>  "_rl_forced_update_display", referenced from:
>      _restore_prompt in command.o
>  "_rl_ding", referenced from:
>      _alert in mouse.o
>  "_history_list", referenced from:
>      _write_history_list in history.o
>  "_rl_complete_with_tilde_expansion", referenced from:
>      _rl_complete_with_tilde_expansion$non_lazy_ptr in plot.o
>  "_rl_reset_after_signal", referenced from:
>      _main in plot.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[3]: *** [gnuplot] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2


This looks to me as usual MaCOS problem with its readline not being
real readline. There are few ways to solve it, perhaps the simplest is to pass
"-with-readline=no" to configure.

Sincerely,
Dmitri.
--

readline on Mac problems again

[Mojca M. <moj...@gm...>]

Hello,

I have reinstalled my MacOS X 10.5 from scratch. After trying to build
gnuplot I get the following error reports (the repository is from
3.3.2009; I'll upgrade to the latest version asap).

I almost urgently need a working version of self-compiled gnuplot, so
I might install the needed packages in the meantime, but I can provide
some more feedback if needed (under assumption that it won't start
working out-of-the-box in the meantime after I start installing
additional packages).

Mojca

g++  -g -O2   -o gnuplot alloc.o axis.o binary.o breaders.o bitmap.o
color.o command.o contour.o datafile.o dynarray.o eval.o fit.o
gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o
internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o
plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o
standard.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o
util3d.o variable.o version.o   -lreadline  -lncurses  -lz
Undefined symbols:
  "_rl_forced_update_display", referenced from:
      _restore_prompt in command.o
  "_rl_ding", referenced from:
      _alert in mouse.o
  "_history_list", referenced from:
      _write_history_list in history.o
  "_rl_complete_with_tilde_expansion", referenced from:
      _rl_complete_with_tilde_expansion$non_lazy_ptr in plot.o
  "_rl_reset_after_signal", referenced from:
      _main in plot.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [gnuplot] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Re: Enhancement Request: output pipe for interogation commands

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

> Would it be possible to add the ability recieve output from gnuplot, over
> stdout to enable command driven bi-directional communication with gnuplot.
> That way a program could start an embedded gnuplot process and monitor the
> processes input and outpout streams to do bi-directional communication. 

This is possible and e.g. Octave is using this mechanism.
For more information, see
http://gnuplot.sourceforge.net/links.html
=> Programming interfaces – bidirectional interaction

> Specifically I would want to be able to use this text output pipe mechanism
> to:
> 
> 1)  get the region displayed by the graph, after the user has finished
> interactively zooming and panning. (get_xxx)

I would recommend to let the user do the zooming and press Enter 
when he is finished ... because then you can use
	pause mouse key
until MOUSE_CHAR is Enter (or Escape) character.

> 2) to be able to set when the user can interact with gnuplot or not i.e.
> toggle interaction mode.
	{un}set mouse

> 3) to be able to be able to put gnuplot in a mode which allows the user to
> toggle the addition and removal of new data points and to output point_added
> and point_removed notifications.

That's not task of gnuplot but of the driving application. You can do
	pause mouse key
and then read MOUSE_CHAR, MOUSE_X, MOUSE_Y (see "show var all"), remove/add 
the point, and replot.

---
PM

Windows Interprocess Communication - Socket Interface Request

[nabed <ss...@ol...>]

I'm having problems getting the gnuplot_i.c code working under windows. It
would seem that named pipes are not supported fully under windows. Would it
be possible to build a socket based protocol (command interface) so that IPC
is more standardised accross platforms. 

It would be nice to be able to start up gnuplot with a given terminal type
and in a background mode that was listenning on a given IP/port.

thanks
Serle
-- 
View this message in context: http://www.nabble.com/Windows-Interprocess-Communication---Socket-Interface-Request-tp22717189p22717189.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Enhancement Request: output pipe for interogation commands

[nabed <ss...@ol...>]

Thanks Ethan,

The final part of the question is to provide the ability for the user to
graphically add new points onto a given graph by clicking on a location on
the graph. e.g say I have a smooth function and want to add a bump to it in
a region, I could replace three existing points by adding three new points
(via mouse interaction on the graph window) and then form a new smooth
interpolated graph containing the new points. I would then want to get the
new dataset back from gnuplot.


Serle



Ethan Merritt wrote:
> 
> On Wednesday 25 March 2009 05:31:14 nabed wrote:
>> 
>> Hi
>> 
>> Would it be possible to add the ability recieve output from gnuplot, over
>> stdout to enable command driven bi-directional communication with
>> gnuplot.
>> That way a program could start an embedded gnuplot process and monitor
>> the
>> processes input and outpout streams to do bi-directional communication. 
>> 
>> Specifically I would want to be able to use this text output pipe
>> mechanism
>> to:
>> 
>> 1)  get the region displayed by the graph, after the user has finished
>> interactively zooming and panning. (get_xxx)
> 
> If you want output to stdout:
>  print GPVAL_XMIN, GPVAL_XMAX, GPVAL_YMIN, GPVAL_YMAX
> 
> If you want output via a new or different pipe:
>  set print "| namedpipe"
>  print GPVAL_XMIN, GPVAL_XMAX, GPVAL_YMIN, GPVAL_YMAX
> 
>> 2) to be able to set when the user can interact with gnuplot or not i.e.
>> toggle interaction mode.
> 
> I don't understand what you mean by this.
> 
>> 3) to be able to be able to put gnuplot in a mode which allows the user
>> to
>> toggle the addition and removal of new data points and to output
>> point_added
>> and point_removed notifications.
> 
> See the demo script:   "mousevariables.dem"
> 
> 
> All of this is possible already; much of since version 4.2 or earlier.
> If you could narrow your question down to a specific thing that you want
> to do, perhaps someone will suggest a bit of sample code to look at.
> 
>> Thanks,
>> Serle
> 
> -- 
> Ethan A Merritt
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/Enhancement-Request%3A-output-pipe-for-interogation-commands-tp22495484p22717065.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Enhancement Request: output pipe for interogation commands

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

On Wednesday 25 March 2009 05:31:14 nabed wrote:
> 
> Hi
> 
> Would it be possible to add the ability recieve output from gnuplot, over
> stdout to enable command driven bi-directional communication with gnuplot.
> That way a program could start an embedded gnuplot process and monitor the
> processes input and outpout streams to do bi-directional communication. 
> 
> Specifically I would want to be able to use this text output pipe mechanism
> to:
> 
> 1)  get the region displayed by the graph, after the user has finished
> interactively zooming and panning. (get_xxx)

If you want output to stdout:
 print GPVAL_XMIN, GPVAL_XMAX, GPVAL_YMIN, GPVAL_YMAX

If you want output via a new or different pipe:
 set print "| namedpipe"
 print GPVAL_XMIN, GPVAL_XMAX, GPVAL_YMIN, GPVAL_YMAX

> 2) to be able to set when the user can interact with gnuplot or not i.e.
> toggle interaction mode.

I don't understand what you mean by this.

> 3) to be able to be able to put gnuplot in a mode which allows the user to
> toggle the addition and removal of new data points and to output point_added
> and point_removed notifications.

See the demo script:   "mousevariables.dem"


All of this is possible already; much of since version 4.2 or earlier.
If you could narrow your question down to a specific thing that you want
to do, perhaps someone will suggest a bit of sample code to look at.

> Thanks,
> Serle

-- 
Ethan A Merritt

Re: Qt terminal

[nabed <ss...@ol...>]

Hi,

I would like to be able to put three Qt Terms (Gnu Plot) widgets on a single
dialog in my Qt application. I would then like to be able to send gnuplot
commands & data steams these QtGnuPlot widgets and also be able to obtain
information on the where the user has panned to or zoomed to. 

Ideally I would want the QT Term to emit signals on pan & zoom events as I'm
wanting to correlate the pan and zooming across the three QtGnuPlot
widgets/terms. Would this be possible with your QtGnuplot widget?  

When/Where would I be able to obtain your widget. 

Serle


Jérôme Lodewyck-5 wrote:
> 
> Le lundi 2 février 2009, Ethan A Merritt a écrit :
>> On Sunday 01 February 2009, Jérôme Lodewyck wrote:
>> > Hi,
>> >
>> > 	I have written a Qt terminal for Gnuplot. My main motivation for doing
>> > this is that Qt is going to be released under the LGPL, and I far as I
>> > understood, this license is compatible with Gnuplot.
>> > 	The terminal is mostly inspired from the wxWidgets terminal (thanks
>> > Timothée for your hard work !). It is not yet optimized and there are
>> > still some glitches here and there, but it is mostly feature complete.
>> > 	If it is of interest for someone, I will be happy to propose a patch.
>>
>> Sure, go ahead and post a patch.
>> It is hard to tell much about how it works by looking only at
>> screenshots.
> 
> Ok, the patch is submitted
> 
>> Please describe more precisely what libraries or environment thie new
>> terminal would require.
>> Does it use the KDE libraries, or just Qt?
>> If one built gnuplot with only the driver, would it be run on, say,
>> the OpenMoko mobile phone platform?
>> What about non-linux Qt platforms?
> 
> It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my 
> experience, Qt applications usually work out of the box on any platform 
> supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE).
> Only 
> one pat of the terminal makes use of non-Qt functions: the Qt main loop is 
> implemented inside a pthread, which is a problem because
> 1/ It doesn't work on non-UNIX platforms, but from what I understood from
> the 
> wx terminal, Windows support would only imply putting #ifdef's around the 
> pthread functions
> 2/ Qt does not officially support running the main event loop inside a
> thread; 
> however, I did not experience any problem with this (except that Qt
> functions 
> should be used with care in the gnuplot thread)
> 
> Jérôme
> 
>> 	Ethan
>>
>> > Screenshots:
>> >
>> > http://lodewyck.free.fr/gp1.png
>> > http://lodewyck.free.fr/gp2.png
>> > http://lodewyck.free.fr/gp3.png
>> >
>> > Regards,
>> >
>> > Jérôme
>> >
>> >
>> -------------------------------------------------------------------------
>> >----- This SF.net email is sponsored by:
>> > SourcForge Community
>> > SourceForge wants to tell your story.
>> > http://p.sf.net/sfu/sf-spreadtheword
>> > _______________________________________________
>> > gnuplot-beta mailing list
>> > gnu...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/Qt-terminal-tp21784702p22493878.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Enhancement Request: output pipe for interogation commands

[nabed <ss...@ol...>]

Hi

Would it be possible to add the ability recieve output from gnuplot, over
stdout to enable command driven bi-directional communication with gnuplot.
That way a program could start an embedded gnuplot process and monitor the
processes input and outpout streams to do bi-directional communication. 

Specifically I would want to be able to use this text output pipe mechanism
to:

1)  get the region displayed by the graph, after the user has finished
interactively zooming and panning. (get_xxx)

2) to be able to set when the user can interact with gnuplot or not i.e.
toggle interaction mode.

3) to be able to be able to put gnuplot in a mode which allows the user to
toggle the addition and removal of new data points and to output point_added
and point_removed notifications.

Thanks,
Serle
-- 
View this message in context: http://www.nabble.com/Enhancement-Request%3A-output-pipe-for-interogation-commands-tp22495484p22495484.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: greetings from gd

[Pierre J. <pie...@gm...>]

It can also mean that some invalid parameter are passed to a GD
function, maybe ImageCreate*, hard to say without a reproduce case.

Cheers,

On Tue, Mar 24, 2009 at 9:54 PM, Ralf Juengling <jue...@cs...> wrote:
> Hi,
>
> I just created my first animated gifs with gnuplot, works
> like a charm. FYI, after generating on the order of
> 100 or so frames/plots for one gif file I am occasionally
> seeing this message:
>
> gd warning: one parameter to a memory allocation multiplication is
> negative or zero,
> failing operation gracefully
>
> I suppose that comes from the gif terminal code. The created
> gifs seem to be fine, though. This is with gnuplot 4.2.4, and
> dpkg says:
>
> ||/ Name             Version          Description
> +++-================-================-================================================
> ii  libgd2-xpm       2.0.35.dfsg-3ubu GD Graphics Library version 2
>
>
> Ralf
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>



-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

Re: greetings from gd

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

On Tuesday 24 March 2009 13:54:08 Ralf Juengling wrote:
> Hi,
> 
> I just created my first animated gifs with gnuplot, works
> like a charm. FYI, after generating on the order of
> 100 or so frames/plots for one gif file I am occasionally
> seeing this message:
> 
> gd warning: one parameter to a memory allocation multiplication is 
> negative or zero,
> failing operation gracefully
> 
> I suppose that comes from the gif terminal code.

I don't think so.  I think it came from the gd library itself.
I suggest forwarding the report to 
	 
	gd-...@li...



> The created 
> gifs seem to be fine, though. This is with gnuplot 4.2.4, and
> dpkg says:
> 
> ||/ Name             Version          Description
> +++-================-================-================================================
> ii  libgd2-xpm       2.0.35.dfsg-3ubu GD Graphics Library version 2
> 
> 
> Ralf
> 
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: How to use table header as title inside for loops?

[James R. V. Z. <jr...@co...>]

Mojca Miklavec <moj...@gm...> wrote:
>On Tue, Mar 17, 2009 at 03:29, James R. Van Zandt wrote:
>>
>> Let me try again.  Assuming this data file:
>>
>>  # R     I      V
>>  2000 0.001000  2
>>  2750 0.000727  2
>>  3500 0.000571  2
>>  4250 0.000471  2
>>  5000 0.000400  2
>>
>>
>>  2000 0.002500  5
>>  2750 0.001818  5
>>  3500 0.001429  5
>>  4250 0.001176  5
>>  5000 0.001000  5
>>
>>
>>  2000 0.005000 10
>>  2750 0.003636 10
>>  3500 0.002857 10
>>  4250 0.002353 10
>>  5000 0.002000 10
>>
>> I'd like to plot current as a function of resistance, with the title
>> for each curve giving the voltage.
>
>I understand your question, but if I had this kind of data, I would
>transform the data first into this form:
>
># first column: R
># header: I
># data: V
>R	2	5	10
>2000 0.001000	0.002500	0.005000
>2750 0.000727	0.001818	0.003636
>3500 0.000571	0.001429	0.002857
>4250 0.000471	0.001176	0.002353
>5000 0.000400	0.001000	0.002000
>
>set key autotitle columnhead
>plot for [n=2:4] 'lab.dat' using 1:n

That kind of transformation looks much too fragile to me.  I suppose I
could plot the entire data file twice, once without titles (so every
point is plotted) and again, with matching line styles, taking the
titles from the first row of each datablock.  Still error-prone.  Or I
could duplicate the first line in each datablock, so there is one copy
for the title and a second copy to be plotted.  Not a big deal if you
only do it once.  

>(Nobody can guarantee that the label in each row is identical in your case.)

I can guarantee it.  I would hardly ask anyone else to.  :-)


               - Jim Van Zandt

greetings from gd

[Ralf J. <jue...@cs...>]

Hi,

I just created my first animated gifs with gnuplot, works
like a charm. FYI, after generating on the order of
100 or so frames/plots for one gif file I am occasionally
seeing this message:

gd warning: one parameter to a memory allocation multiplication is 
negative or zero,
failing operation gracefully

I suppose that comes from the gif terminal code. The created
gifs seem to be fine, though. This is with gnuplot 4.2.4, and
dpkg says:

||/ Name             Version          Description
+++-================-================-================================================
ii  libgd2-xpm       2.0.35.dfsg-3ubu GD Graphics Library version 2


Ralf

Re: mouse.c: protocol error in Windows for bind

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

> > > The only place that can happen is here, and only when
> > > thisTimestamp != lastTimestamp.   Suggested patch is shown below.
> > > 
> > This patch works OK, thanks!
> 
> Great.  I have added it to cvs.  Please check that I didn't mess it up somehow,
> since I can't test for a successful Windows build here.

Yes, the patch works OK.

> Any other issues to be resolved before pushing out 4.2.5 ?

I think it is 4.2.5 can go out.

The bug in "screendump" command on Windows will have to wait till the next 
release (or somebody can make the patch fastly?).

---
PM

Re: Strangeness with PM3D

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

> In trying to figure out why some of the output files produced by the
> canvas driver are so large, I stumbled across a strange pm3d problem
> that seems to affect many drivers.  It shows up in several of the demos,
> but the most extreme case is transparent_solids.dem.
> 
> The issue is this line in pm3d.c
>   693:         /* set the color */
>   694:         set_color(gray);
> 
> The line is clearly necessary in the general case, but there must be one
> or more conditions in which the loop containing this line is executed
> many times even though no pm3d quadrangles are actually drawn.
> This results in huge numbers of useless color setting commands in the
> output file.  For instance, if you run it through the postscript driver
>    set term post color solid
>    set output 'ts.ps'
>    load 'transparent_solids.dem'
> 
> you will find in the output file lines like the following:
> %pm3d_map_begin
> .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g  ... [snip] %pm3d_map_end
>
> How can we get rid of this unwanted output?

It was a problem of the depthorder option, here is the shortest test case:

set pm3d depthorder
splot x*x+y*y with pm3d
set term post color; set out 'z.ps'
replot
set out; set term pop


I have fixed it.

---
PM

Re: mouse.c: protocol error in Windows for bind

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

On Monday 23 March 2009 15:17:33 Petr Mikulik wrote:
> > > > > Can somebody else on Windows reproduce the bug below? I would like this gets 
> > > > > fixed before 4.2.5 is released.
> > > > > 
> > > > > In Windows, there is only one open and active graph window. 
> > > > > I think this could be the reason while mouse.c:event_keypress() reports 
> > > > > "protocol error" if you try e.g.:
> > > > > 
> > > > > bind 's' 'print "Hello";'
> > > > > bind 'd' 'set grid;'
> > > > > bind 'f' 'set time'
> > > > > bind 'g' 'plot x;'
> > > > > bind 'x' 'test;'
> > > > > plot x*x
> > > > > 
> > > > > and then press "s" hotkey (or the others) several times. 
> > > > > 
> > > > > The code in mouse.c after
> > > > >    if (ptr->allwindows && ptr->command) {
> > > > > 
> > > > > is testing "allwindows" and "active" windows but it could somehow miss the 
> > > > > case of a single-window graph. I'm not sure what should be the correct fix 
> > > > > among these several if .. else if ... This well handles case of multiple 
> > > > > windows (x11, wxt), but what should it do for single-window cases such as 
> > > > > windows or pm terminals?
> > > > 
> > > > It must recognize the current window correctly, or it would have exited the
> > > > loop before reaching that protocol error message.
> > > > 1387:	} else if (!current) break;
> > > > 
> > > > I think it is more likely that some spurious event is being generated
> > > > in addition to the desired keypress event, and we should just ignore it.
> > > > Is the behaviour acceptable if you change the fprintf() to FPRINTF(())?
> > > 
> > > Correct behaviour is achieved by setting
> > > 	ptr->allwindows = 1
> > > or by
> > > 	par2 = 0
> > > With
> > > 	current = 1
> > > some events are lost and "protocol error" is shown.
> > > 
> > > What (and where) should be set for correct behaviour?
> > 
> > OK, with that set of clues I conclude that the failure happens whenever
> > the GE_keypress event notification is sent with a non-zero par2.
> > The only place that can happen is here, and only when
> > thisTimestamp != lastTimestamp.   Suggested patch is shown below.
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > --- gnuplot42/src/win/wgraph.c  2008-10-10 10:21:07.000000000 -0700
> > +++ gnuplot-4.2.5/src/win/wgraph.c      2009-03-19 16:59:30.000000000 -0700
> > @@ -1973,9 +1973,13 @@ Wnd_exec_event(LPGW lpgw, LPARAM lparam,
> >      int mx, my;
> >      static unsigned long lastTimestamp = 0;
> >      unsigned long thisTimestamp = GetMessageTime();
> > +    int par2 = thisTimestamp - lastTimestamp;
> > +
> > +    if (type == GE_keypress)
> > +       par2 = 0;
> > 
> >      GetMousePosViewport(lpgw, &mx, &my);
> > -    gp_exec_event(type, mx, my, par1, thisTimestamp - lastTimestamp, 0);
> > +    gp_exec_event(type, mx, my, par1, par2, 0);
> >      lastTimestamp = thisTimestamp;
> >  }
> 
> 
> This patch works OK, thanks!

Great.  I have added it to cvs.  Please check that I didn't mess it up somehow,
since I can't test for a successful Windows build here.

Any other issues to be resolved before pushing out 4.2.5 ?







> 
> 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > I do not know what this Timestamp test is intended to do.
> > No equivalent test exists in the x11 or wxt drivers for keypress events.
> > Perhaps it is intended to handle double-click?  If so it should only
> > apply to buttonrelease events, not keypress events.
> 
> There are doubleclicks, see "help mouse".
> MB1 copies mouse position to clipboard. This needs to be a doubleclick 
> because single click focuses/selects the window.
> 
> > It might also be safe to simply remove the test in mouse.c, like this:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > --- gnuplot42/src/mouse.c       2009-02-08 20:43:44.000000000 -0800
> > +++ gnuplot-4.2.5/src/mouse.c   2009-03-19 16:51:07.000000000 -0700
> > @@ -1387,7 +1387,7 @@ event_keypress(struct gp_event_t *ge, TB
> >             } else if (!current) {
> >                 break;
> >             /* Let user defined bindings overwrite the builtin bindings */
> > -           } else if ((par2 & 1) == 0 && ptr->command) {
> > +           } else if (ptr->command) {
> >                 do_string(ptr->command);
> >                 break;
> >             } else if (ptr->builtin) {
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > but I am a little reluctant to do that for 4.2.5 because I haven't figured
> > out what case it was supposed to handle.  We could make the change in 4.3
> > and see if anyone reports problems with x11 or wxt or os2.
> 
> This patch also fixes the problem (patch 1 is not applied).
> 
> I think the patch 1 should be put to cvs.
> I don't know why there is "(par2 & 1) == 0".
> 
> ---
> PM
> 
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: mouse.c: protocol error in Windows for bind

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

> > > > Can somebody else on Windows reproduce the bug below? I would like this gets 
> > > > fixed before 4.2.5 is released.
> > > > 
> > > > In Windows, there is only one open and active graph window. 
> > > > I think this could be the reason while mouse.c:event_keypress() reports 
> > > > "protocol error" if you try e.g.:
> > > > 
> > > > bind 's' 'print "Hello";'
> > > > bind 'd' 'set grid;'
> > > > bind 'f' 'set time'
> > > > bind 'g' 'plot x;'
> > > > bind 'x' 'test;'
> > > > plot x*x
> > > > 
> > > > and then press "s" hotkey (or the others) several times. 
> > > > 
> > > > The code in mouse.c after
> > > >    if (ptr->allwindows && ptr->command) {
> > > > 
> > > > is testing "allwindows" and "active" windows but it could somehow miss the 
> > > > case of a single-window graph. I'm not sure what should be the correct fix 
> > > > among these several if .. else if ... This well handles case of multiple 
> > > > windows (x11, wxt), but what should it do for single-window cases such as 
> > > > windows or pm terminals?
> > > 
> > > It must recognize the current window correctly, or it would have exited the
> > > loop before reaching that protocol error message.
> > > 1387:	} else if (!current) break;
> > > 
> > > I think it is more likely that some spurious event is being generated
> > > in addition to the desired keypress event, and we should just ignore it.
> > > Is the behaviour acceptable if you change the fprintf() to FPRINTF(())?
> > 
> > Correct behaviour is achieved by setting
> > 	ptr->allwindows = 1
> > or by
> > 	par2 = 0
> > With
> > 	current = 1
> > some events are lost and "protocol error" is shown.
> > 
> > What (and where) should be set for correct behaviour?
> 
> OK, with that set of clues I conclude that the failure happens whenever
> the GE_keypress event notification is sent with a non-zero par2.
> The only place that can happen is here, and only when
> thisTimestamp != lastTimestamp.   Suggested patch is shown below.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> --- gnuplot42/src/win/wgraph.c  2008-10-10 10:21:07.000000000 -0700
> +++ gnuplot-4.2.5/src/win/wgraph.c      2009-03-19 16:59:30.000000000 -0700
> @@ -1973,9 +1973,13 @@ Wnd_exec_event(LPGW lpgw, LPARAM lparam,
>      int mx, my;
>      static unsigned long lastTimestamp = 0;
>      unsigned long thisTimestamp = GetMessageTime();
> +    int par2 = thisTimestamp - lastTimestamp;
> +
> +    if (type == GE_keypress)
> +       par2 = 0;
> 
>      GetMousePosViewport(lpgw, &mx, &my);
> -    gp_exec_event(type, mx, my, par1, thisTimestamp - lastTimestamp, 0);
> +    gp_exec_event(type, mx, my, par1, par2, 0);
>      lastTimestamp = thisTimestamp;
>  }


This patch works OK, thanks!


> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> I do not know what this Timestamp test is intended to do.
> No equivalent test exists in the x11 or wxt drivers for keypress events.
> Perhaps it is intended to handle double-click?  If so it should only
> apply to buttonrelease events, not keypress events.

There are doubleclicks, see "help mouse".
MB1 copies mouse position to clipboard. This needs to be a doubleclick 
because single click focuses/selects the window.

> It might also be safe to simply remove the test in mouse.c, like this:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot42/src/mouse.c       2009-02-08 20:43:44.000000000 -0800
> +++ gnuplot-4.2.5/src/mouse.c   2009-03-19 16:51:07.000000000 -0700
> @@ -1387,7 +1387,7 @@ event_keypress(struct gp_event_t *ge, TB
>             } else if (!current) {
>                 break;
>             /* Let user defined bindings overwrite the builtin bindings */
> -           } else if ((par2 & 1) == 0 && ptr->command) {
> +           } else if (ptr->command) {
>                 do_string(ptr->command);
>                 break;
>             } else if (ptr->builtin) {
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> but I am a little reluctant to do that for 4.2.5 because I haven't figured
> out what case it was supposed to handle.  We could make the change in 4.3
> and see if anyone reports problems with x11 or wxt or os2.

This patch also fixes the problem (patch 1 is not applied).

I think the patch 1 should be put to cvs.
I don't know why there is "(par2 & 1) == 0".

---
PM

Strangeness with PM3D

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

In trying to figure out why some of the output files produced by the
canvas driver are so large, I stumbled across a strange pm3d problem
that seems to affect many drivers.  It shows up in several of the demos,
but the most extreme case is transparent_solids.dem.

The issue is this line in pm3d.c
  693:         /* set the color */
  694:         set_color(gray);

The line is clearly necessary in the general case, but there must be one
or more conditions in which the loop containing this line is executed
many times even though no pm3d quadrangles are actually drawn.
This results in huge numbers of useless color setting commands in the
output file.  For instance, if you run it through the postscript driver
   set term post color solid
   set output 'ts.ps'
   load 'transparent_solids.dem'

you will find in the output file lines like the following:
%pm3d_map_begin
.4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4729 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g .4218 g  ... [snip] %pm3d_map_end

where all of that is on one line of >15000 characters!
Deleting these spurious lines has no visible effect on the rendered plot, 
but reduces the file size considerably.  

How can we get rid of this unwanted output?


-- 
Ethan A Merritt

Re: mouse.c: protocol error in Windows for bind

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

On Thursday 19 March 2009 15:32:41 Petr Mikulik wrote:
> > > Can somebody else on Windows reproduce the bug below? I would like this gets 
> > > fixed before 4.2.5 is released.
> > > 
> > > In Windows, there is only one open and active graph window. 
> > > I think this could be the reason while mouse.c:event_keypress() reports 
> > > "protocol error" if you try e.g.:
> > > 
> > > bind 's' 'print "Hello";'
> > > bind 'd' 'set grid;'
> > > bind 'f' 'set time'
> > > bind 'g' 'plot x;'
> > > bind 'x' 'test;'
> > > plot x*x
> > > 
> > > and then press "s" hotkey (or the others) several times. 
> > > 
> > > The code in mouse.c after
> > >    if (ptr->allwindows && ptr->command) {
> > > 
> > > is testing "allwindows" and "active" windows but it could somehow miss the 
> > > case of a single-window graph. I'm not sure what should be the correct fix 
> > > among these several if .. else if ... This well handles case of multiple 
> > > windows (x11, wxt), but what should it do for single-window cases such as 
> > > windows or pm terminals?
> > 
> > It must recognize the current window correctly, or it would have exited the
> > loop before reaching that protocol error message.
> > 1387:	} else if (!current) break;
> > 
> > I think it is more likely that some spurious event is being generated
> > in addition to the desired keypress event, and we should just ignore it.
> > Is the behaviour acceptable if you change the fprintf() to FPRINTF(())?
> 
> Correct behaviour is achieved by setting
> 	ptr->allwindows = 1
> or by
> 	par2 = 0
> With
> 	current = 1
> some events are lost and "protocol error" is shown.
> 
> What (and where) should be set for correct behaviour?

OK, with that set of clues I conclude that the failure happens whenever
the GE_keypress event notification is sent with a non-zero par2.
The only place that can happen is here, and only when
thisTimestamp != lastTimestamp.   Suggested patch is shown below.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

--- gnuplot42/src/win/wgraph.c  2008-10-10 10:21:07.000000000 -0700
+++ gnuplot-4.2.5/src/win/wgraph.c      2009-03-19 16:59:30.000000000 -0700
@@ -1973,9 +1973,13 @@ Wnd_exec_event(LPGW lpgw, LPARAM lparam,
     int mx, my;
     static unsigned long lastTimestamp = 0;
     unsigned long thisTimestamp = GetMessageTime();
+    int par2 = thisTimestamp - lastTimestamp;
+
+    if (type == GE_keypress)
+       par2 = 0;

     GetMousePosViewport(lpgw, &mx, &my);
-    gp_exec_event(type, mx, my, par1, thisTimestamp - lastTimestamp, 0);
+    gp_exec_event(type, mx, my, par1, par2, 0);
     lastTimestamp = thisTimestamp;
 }

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I do not know what this Timestamp test is intended to do.
No equivalent test exists in the x11 or wxt drivers for keypress events.
Perhaps it is intended to handle double-click?  If so it should only
apply to buttonrelease events, not keypress events.

It might also be safe to simply remove the test in mouse.c, like this:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot42/src/mouse.c       2009-02-08 20:43:44.000000000 -0800
+++ gnuplot-4.2.5/src/mouse.c   2009-03-19 16:51:07.000000000 -0700
@@ -1387,7 +1387,7 @@ event_keypress(struct gp_event_t *ge, TB
            } else if (!current) {
                break;
            /* Let user defined bindings overwrite the builtin bindings */
-           } else if ((par2 & 1) == 0 && ptr->command) {
+           } else if (ptr->command) {
                do_string(ptr->command);
                break;
            } else if (ptr->builtin) {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
but I am a little reluctant to do that for 4.2.5 because I haven't figured
out what case it was supposed to handle.  We could make the change in 4.3
and see if anyone reports problems with x11 or wxt or os2.

-- 
Ethan A Merritt

Re: mouse.c: protocol error in Windows for bind

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

> > Can somebody else on Windows reproduce the bug below? I would like this gets 
> > fixed before 4.2.5 is released.
> > 
> > In Windows, there is only one open and active graph window. 
> > I think this could be the reason while mouse.c:event_keypress() reports 
> > "protocol error" if you try e.g.:
> > 
> > bind 's' 'print "Hello";'
> > bind 'd' 'set grid;'
> > bind 'f' 'set time'
> > bind 'g' 'plot x;'
> > bind 'x' 'test;'
> > plot x*x
> > 
> > and then press "s" hotkey (or the others) several times. 
> > 
> > The code in mouse.c after
> >    if (ptr->allwindows && ptr->command) {
> > 
> > is testing "allwindows" and "active" windows but it could somehow miss the 
> > case of a single-window graph. I'm not sure what should be the correct fix 
> > among these several if .. else if ... This well handles case of multiple 
> > windows (x11, wxt), but what should it do for single-window cases such as 
> > windows or pm terminals?
> 
> It must recognize the current window correctly, or it would have exited the
> loop before reaching that protocol error message.
> 1387:	} else if (!current) break;
> 
> I think it is more likely that some spurious event is being generated
> in addition to the desired keypress event, and we should just ignore it.
> Is the behaviour acceptable if you change the fprintf() to FPRINTF(())?

Correct behaviour is achieved by setting
	ptr->allwindows = 1
or by
	par2 = 0
With
	current = 1
some events are lost and "protocol error" is shown.

What (and where) should be set for correct behaviour?

---
PM