gnuplot-beta

Time to branch off 4.0 from 4.1?

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

Hello, everyone,

I sense some of us are already champing at the bit to get off with
integrating tons of new features into 4.1, once it's started.  In-flow of
new bugs also seems pretty much within expectations for a stable release
by now, so it seems time to move on.  Thus I'm prepared to tag and branch
any time now, but I'ld like some things cleared up first:

*) If we move towards ANSI-C function definitions, I think that should be
done *before* we split off a 4.0 branch, to reduce "patch distance"  
between the two branches.  I'm in favour of doing that, with a tag 4.0.1
before we start it, and another tag (4.0.2) right afterwards.  4.0.2 would
become the branch-off point for the 4.0-release branch.

*) K&R incompatibilities.  Mainly the use of 'char' in some function's
parameter lists, most prominently in the terminal API.  Currently we're
neither fully compatible with K&R, nor with ANSI-C.  I suggest we fix
towards K&R C after the split, and only on the 4.0 branch.  The 4.1 stem
would be moved towards ANSI/ISO C instead.  We will have to burn the
bridges to K&R C at some point, and this feels as good a time as any.  
The only viable alternative to this approach I see right now would be to
step onto a soapbox and declare 3.7.3 as the last version actually
compilable on K&R compilers, and that's that.

*) Some currently open bugs that need fixing.  I won't even try to comment
on the recurring mouse interaction timing/concurrency problems on various
platforms.  But the yrange flip needs to be fixed, and the EMF terminal
output has to be made compatible with Windows 2K and XP (note: I suspect
any dependence on _Office_ version numbers is a red herring) --- it's
essentially unusable right now.

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

Re: Time to branch off 4.0 from 4.1?

[Allin C. <cot...@wf...>]

On Wed, 16 Jun 2004, Hans-Bernhard Broeker wrote:

> *) K&R incompatibilities.  Mainly the use of 'char' in some function's
> parameter lists, most prominently in the terminal API.  Currently we're
> neither fully compatible with K&R, nor with ANSI-C.  I suggest we fix
> towards K&R C after the split, and only on the 4.0 branch.  The 4.1 stem
> would be moved towards ANSI/ISO C instead.

This sounds good to me.

> *) Some currently open bugs that need fixing.  I won't even try to comment
> on the recurring mouse interaction timing/concurrency problems on various
> platforms.  But the yrange flip needs to be fixed, and the EMF terminal
> output has to be made compatible with Windows 2K and XP (note: I suspect
> any dependence on _Office_ version numbers is a red herring) --- it's
> essentially unusable right now.

That's true of the 4.0 release, but not once the patch recently
submitted by Stephane is applied.  Ethan had trouble reading
gnuplot-generated EMFs under wine, but the evidence is that the
new-format gnuplot EMFs are read correctly under the actual Windows
gdi.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Time to branch off 4.0 from 4.1?

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

> I sense some of us are already champing at the bit to get off with
> integrating tons of new features into 4.1, once it's started.

Yes, I'm looking forward to this event!

> *) If we move towards ANSI-C function definitions, I think that should be
> *) K&R incompatibilities.  Mainly the use of 'char' in some function's

I'm not expert here, but I propose to have gnuplot 4.0 compatible to as much
as compilers possible -- 4.0 is a major step forward, so why not have it
that. (If somebody will ever need a K&R compatibility in future versions, he
can submit an (unofficial) patch to SF -- as most current developers don't
access such compilers, that's the reason for being unofficial.)

> *) Some currently open bugs that need fixing.  I won't even try to comment
> on the recurring mouse interaction timing/concurrency problems on various
> platforms.
> But the yrange flip needs to be fixed

yes, now it is quite irritating

Another point follows a recent discussion: when in "pause mouse" on X11, and
closing the window, then gnuplot does not respond any longer and it must be
killed. Also, it should not close itself when hitting "q" (especially not
in "pause mouse key").

---
PM

Re: Time to branch off 4.0 from 4.1?

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

On Wednesday 16 June 2004 07:01 am, Petr Mikulik wrote:
> Another point follows a recent discussion: when in "pause mouse" on X11,
> and closing the window, then gnuplot does not respond any longer and it
> must be killed.

I can't replicate this behavior either with the current cvs version.
Yes, if you close the plot window then you need to type ctrl-C to exit the 
pause-for-mouse state.  But this doesn't kill gnuplot, it just returns to the
command line.

Could you please give me an exact sequence of commands and
events to try using the current cvs version?  

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

> > Another point follows a recent discussion: when in "pause mouse" on X11,
> > and closing the window, then gnuplot does not respond any longer and it
> > must be killed.
>
> I can't replicate this behavior either with the current cvs version.
> Yes, if you close the plot window then you need to type ctrl-C to exit the
> pause-for-mouse state.  But this doesn't kill gnuplot, it just returns to the
> command line.

Yes, it works as you explain.

The problem is when "pause mouse" is issued by an application using gnuplot
as its front end. Particular case: In Octave, I use ginput.m (see gnuplot
web page for the script) to receive given number of point coordinates. Then,
it send "pause mouse" to gnuplot and reads one coordinate after another
using fifo. If you close gnuplot in between, then the reader gets blocked --
you will need "Ctrl-C" in your driving application, or to kill gnuplot, or
like that.

Do you have an idea how to avoid this block?

---
PM

Re: Time to branch off 4.0 from 4.1?

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

On Thursday 17 June 2004 05:26 am, Petr Mikulik wrote:
>
> The problem is when "pause mouse" is issued by an application using
> gnuplot as its front end. Particular case: In Octave, I use ginput.m
> (see gnuplot web page for the script) to receive given number of point
> coordinates. Then, it send "pause mouse" to gnuplot and reads one
> coordinate after another using fifo. If you close gnuplot in between,
> then the reader gets blocked -- you will need "Ctrl-C" in your driving
> application, or to kill gnuplot, or like that.
>
> Do you have an idea how to avoid this block?

I have added a check in gplt_x11 for the DestroyNotify event,
which should be generated any time a plot window is closed.
If it is the current plot window, then gnuplot_x11 passes the
information on to gnuplot via the mousing pipe using the existing
GE_reset mechanism.

On the gnuplot side I have added code to terminate the
paused_for_mouse state whenever a GE_reset event is seen.

Please let me know if this change resolves your problems with
running gnuplot via a script.  There are ways to close a window that
bypass this mechanism (killing gnuplot_x11 from the command line is
one of them), but I think this change handles the normal cases.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

> I have some ideas, but not a complete solution.
> How exactly do you "close gnuplot"?  Do you mean that you
> click on one of the buttons that the window manager adds to
> the frame of the plot window?  Or do you type "q", or what?

Yes, by hitting "q" key or by Alt-F4.

> On the gnuplot side I have added code to terminate the
> paused_for_mouse state whenever a GE_reset event is seen.
>
> Please let me know if this change resolves your problems with
> running gnuplot via a script.  There are ways to close a window that
> bypass this mechanism (killing gnuplot_x11 from the command line is
> one of them), but I think this change handles the normal cases.

Yes, it works better. Now, can you please add the following improvement:

If user closes gnuplot_x11, then "show variables" should have define all
usual mousing variables, obviously with zero values, and the MOUSE_KEY
should be set to -1:

MOUSE_X = 0
MOUSE_Y = 0
MOUSE_X2 = 0
MOUSE_Y2 = 0
MOUSE_SHIFT = 0
MOUSE_ALT = 0
MOUSE_CTRL = 0
MOUSE_KEY = -1

This is absolutely important in order not to break scripts for bidirectional
communication of other programs with gnuplo, which get feedback from mousing
by writing the above MOUSE_* values to pipe / fifo.

In my testing Octave scripts, which does some actions passed from gnuplot's
"pause mouse key", after the following sent to gnuplot via fifo:

fprintf(gp.f, 'pause mouse key\n\n');
fflush(gp.f);
fprintf(gp.f, 'print MOUSE_X, MOUSE_Y, MOUSE_KEY\n');
fflush(gp.f);

gnuplot reports (obvious) error: "undefined variable: MOUSE_KEY".


Finally, what do you think about this: "q" hotkey is disabled when "pause
mouse key" comes to action; thus, command.c should call "x11_hotkeys(0)"
and afterwards "x11_hotkeys(1)" to enable them again. Note that "<space>"
hotkey is still quite useful to be unchanged.

---
PM

Re: Time to branch off 4.0 from 4.1?

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

On Friday 18 June 2004 06:09 am, you wrote:
>
> If user closes gnuplot_x11, 

If a user kills gnuplot_x11 then all bets are off.  Killing it (SIGTERM etc)
will bypass any code that I add.  So I assume you mean:
if a user closes the plot window...

> then "show variables" should have define all 
> usual mousing variables, obviously with zero values, and the MOUSE_KEY
> should be set to -1:

I do not like this idea at all.
zero is a legal coordinate value, so setting coordinates to zero is not a safe way
of indicating an abnormal return.

> This is absolutely important in order not to break scripts for
> bidirectional communication of other programs with gnuplo, which get
> feedback from mousing by writing the above MOUSE_* values to pipe /
> fifo.

But a script should not assume that any of these variables are defined. 
In fact they are not defined to begin with, and only become defined
at the time a mouse click is first requested and successfully recognized.
I suggest that the proper fix is to modify your scripts to test for the
existence of the variable before trying to print it.

This is simply a specific example of the more general case of 
user-defined variables.  Scripts are free to define and use variables
via gnuplot, but they cannot assume the variables are defined. Or else
they must be very careful to insure that a variable becomes defined
before trying to use it, but that strikes me as a dangerous programming
style.

> Finally, what do you think about this: "q" hotkey is disabled when
> "pause mouse key" comes to action;

I have been unable to figure out how to do this.
The "q" hotkey is handled directly by gnuplot_x11, which doesn't know
anything about "pause mouse".   I think it would take a separate
communication channel and a new set of driver calls to implement 
this, since gnuplot would have to inform gnuplot_x11 asynchronously
that it is requested to change how it is handling X11 input events.
Frankly, I think it would be a huge headache to get this working.

The only alternative I have been able to come up with is to
move the "q" processing for the current plot window out of gnuplot_x11
altogether, and make it equivalent to 
   bind 'q' '<some command related to set term x11 close>'
If you have any better ideas, please speak up.

> thus, command.c should call 
> "x11_hotkeys(0)" and afterwards "x11_hotkeys(1)" to enable them again.

x11_hotkeys()?   Is this a new driver primitive that you have designed?
I agree it would be possible to do this sort of thing by adding a new set
of driver primitives.  But that's a big job and I don't have time to tackle it.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

> > then "show variables" should have define all
> > usual mousing variables, obviously with zero values, and the MOUSE_KEY
> > should be set to -1:
>
> I do not like this idea at all. zero is a legal coordinate value, so
> setting coordinates to zero is not a safe way of indicating an abnormal
> return.

I didn't mean MOUSE_X, but MOUSE_KEY -- that's the indication what has
happened during "pause mouse".

From the programming point of view, what a driving program has to write to
gnuplot in either case -- an Octave example:

A. "close" sets MOUSE_X, .. to e.g. 0, and MOUSE_KEY to -1:

graw('\nprint MOUSE_X, MOUSE_Y, MOUSE_KEY;');
...read them from fifo...
if (mouse_key >= 0) ...

B. "close" does not define anything:

graw('\nif (defined(MOUSE_KEY)) print MOUSE_X, MOUSE_Y, MOUSE_KEY; else
print "0 0 -1"\n');
...read them from fifo...
if (mouse_key >= 0) ...

Note that "\n..." is necessary as one character gets eaten during close.


In summary: I would like more to have MOUSE_KEY defined always, and being
positive for mouse and key events, and being negative for a "fatal" case of
no such event.


> I suggest that the proper fix is to modify your scripts to test for the
> existence of the variable before trying to print it.

The above-mentioned script works, just "it does not look so nice" with the
additional "if ; else 0 0 -1".


BTW, one bug:

gnuplot> plot x
gnuplot> pause mouse key
 ..hit q
gnuplot> pause mouse key
 ..now must press Ctrl-C
gnuplot> pause mouse key
    warning: Mousing not active
                     ^
         expecting string

gnuplot> pause mouse
         warning: Mousing not active


It should report the "Mousing not active", or rather "Interactive terminal
window is closed", even in the 1st trail; that Ctrl-C is fatal for driving
apps.



> > Finally, what do you think about this: "q" hotkey is disabled when
> > "pause mouse key" comes to action;
>
> I have been unable to figure out how to do this.
> The "q" hotkey is handled directly by gnuplot_x11, which doesn't know
> anything about "pause mouse".

Thus, a special string must be sent to the interactive terminal at the
beginning, and another one at the end.

Actually, it will be the same thing as switching on/off mouse-related menu
items in the PM terminal, when mouse gets disabled in gnuplot. See
mouse.c: builtin_toggle_mouse()
...
# ifdef OS2
    update_menu_items_PM_terminal();
# endif
...


/* update menu items in PM terminal */
void
update_menu_items_PM_terminal(void)
{
    send_gpPMmenu(PM_pipe);
}


=> and send_gpPMmenu does:

    putc('#', PM_pipe);
    fwrite(&gpPMmenu, sizeof(gpPMmenu), 1, PM_pipe);

Great hack, but works as user expects.


> I think it would take a separate communication channel and a new set of
> driver calls to implement this, since gnuplot would have to inform
> gnuplot_x11 asynchronously that it is requested to change how it is
> handling X11 input events. Frankly, I think it would be a huge headache to
> get this working.

That's why my previous idea to change "set_cursor" api to "set_interactive"
to pass exactly such events, instead of those e.g.  SET_SPECIAL events sent
by some .trm.


> The only alternative I have been able to come up with is to
> move the "q" processing for the current plot window out of gnuplot_x11
> altogether, and make it equivalent to
>    bind 'q' '<some command related to set term x11 close>'
> If you have any better ideas, please speak up.

But "q" is traditional as it closes -persisten gnuplot_x11 too.

> > thus, command.c should call
> > "x11_hotkeys(0)" and afterwards "x11_hotkeys(1)" to enable them again.
> x11_hotkeys()?   Is this a new driver primitive that you have designed?
> I agree it would be possible to do this sort of thing by adding a new set
> of driver primitives.  But that's a big job and I don't have time to tackle it.

To be reused set_cursor. Ok, then it can wait for cvs branch splitting.

---
Petr

Re: Time to branch off 4.0 from 4.1?

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

On Wednesday 16 June 2004 06:49 am, Allin Cottrell wrote:
>
> That's true of the 4.0 release, but not once the patch recently
> submitted by Stephane is applied.  Ethan had trouble reading
> gnuplot-generated EMFs under wine, but the evidence is that the
> new-format gnuplot EMFs are read correctly under the actual Windows
> gdi.

Correct.  Also I later discovered that the character strangeness
under wine can be fixed after reading in the plot by explicitly
selecting "convert to MicroSoft Office drawing object".

So I think Stephane's patch is usable, with maybe a footnote
somewhere to warn of possible character problems.  My
one remaining reservation is that the revised version is no
longer unicode compatible.  

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

[Allin C. <cot...@wf...>]

On Wed, 16 Jun 2004, Ethan Merritt wrote:

> So I think Stephane's patch is usable, with maybe a footnote
> somewhere to warn of possible character problems.  My
> one remaining reservation is that the revised version is no
> longer unicode compatible.

Could we persuade Stephane to revert that aspect of the change?  As I
recall, he made the change for compatibility with libemf, but the
non-recognition of the "wide" version of emf text is itself a bug in
libemf, and furthermore I'm not aware of anyone using libemf (which is
a bit of a shame, but there you are); gnuplot certainly doesn't use
it in any way.

Allin Cottrell

Re: Time to branch off 4.0 from 4.1?

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

On the topic of compiler compatibility, 
do we care about the following warnings from "gcc -pedantic"?

set.c:181: warning: string length `738' is greater than the length `509' ISO C89 compilers are required to support
show.c:184: warning: string length `753' is greater than the length `509' ISO C89 compilers are required to support
show.c:880: warning: string length `541' is greater than the length `509' ISO C89 compilers are required to support
../term/dxf.trm:182: warning: string length `985' is greater than the length `509' ISO C89 compilers are required to support
../term/svg.trm:632: warning: string length `1027' is greater than the length `509' ISO C89 compilers are required to support
../term/pslatex.trm:270: warning: string length `1079' is greater than the length `509' ISO C89 compilers are required to support
../term/pstricks.trm:258: warning: string length `747' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:204: warning: string length `1548' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:261: warning: string length `807' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:298: warning: string length `519' is greater than the length `509' ISO C89 compilers are required to support
../term/metapost.trm:466: warning: string length `1969' is greater than the length `509' ISO C89 compilers are required to support
unset.c:149: warning: string length `774' is greater than the length `509' ISO C89 compilers are required to support


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195