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

Doc : "ai driver deprecated"

[<tim...@en...>]

Hi,

Looking at gnuplot.doc to clean up the "news" section, I came across the=20
following line "4 Adobe Illustrator (ai) driver deprecated".

What does it mean in practise ?
Shouldn't this message rather be in "help ai" instead of the news section=
 ?
I propose to write this, taken from Harald Harders on this list=20
(http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/1952/match=3D=
adobe)=20
:

"Please note that this terminal is outdated and, as PostScript is=20
understood by *Adobe* Illustrator, the `post` should be used instead."

Let me know if it is ok.

Best regards,

Timoth=C3=A9e

Re: problem building latest cvs snapshot

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

On Friday 28 July 2006 01:15 pm, Timoth=E9e Lecomte wrote:
> I tried with ./configure --with-readline=3Dgnu, and get the "Exec"
> warning, the 'make' error, and no .tex nor .eps files generated.
> However, with ./configure (i.e. with the builtin readline), I get the
> "Exec" warning but the .tex and .eps files _are_ generated.
>
> =3D> There is a problem with GNU readline.

More likely a problem with term->waitforinput().

Anyhow, I have fixed the original problem by having
 .../tutorial/Makefile set GNUTERM to "latex" before running
the demo scripts.

We can continue to discuss whether it is a mistake to initialize
x11 on entry if it is the default terminal.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: problem building latest cvs snapshot

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Guys, I suspect we're chasing a red herring.
>
> Let me repeat this:
>
> Hans-Bernhard Br=F6ker wrote:
>  =20
>> gnuplot_x11 isn't even supposed to be started by this run of gnuplot.=20
>> And it isn't --=20
>>    =20
>
> gnuplot_x11 is *not* actually needed by tutorial/Makefile's invocations=
=20
> of gnuplot.  I know that for several independent reasons:
>
> 1) my local working copy is versioned 4.2-rc1, so it looks for=20
> /usr/local/libexec/gnuplot/4.2/gnuplot_x11, which never existed at any=20
> time during this exercise.
>
> 2) To be extra sure, I *removed* all installed gnuplots from this cygwi=
n=20
>   box, and it still failed to fail.
>
> 3) the LaTeX and EPS output files are generated in spite of those messa=
ges.
>
> We're looking at *warnings* here, not errors.
I think I have found what is needed to reproduce the error.

I tried with ./configure --with-readline=3Dgnu, and get the "Exec"=20
warning, the 'make' error, and no .tex nor .eps files generated.
However, with ./configure (i.e. with the builtin readline), I get the=20
"Exec" warning but the .tex and .eps files _are_ generated.

=3D> There is a problem with GNU readline.

Timoth=E9e

Re: -persist and the wxWidgets terminal, continued

[<tim...@en...>]

Dave Denholm wrote:
>  =20
>> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20
>> gnuplot, and I doubt it will actually work : since gnuplot's process i=
s=20
>> still running, octave still waits for it.
>>
>> Do any of you have a miraculous idea, or should I report that to the=20
>> octave developers as I did for maxima ?
>>
>>    =20
>
> gnuplot can fork(), then allow the parent to exit, leaving the child
> continuing to run the same code in exactly the same state, but
> detached.
>  =20
This won't work in my case, because the terminal is multithreaded and=20
fork() has undetermined behaviour with threads, and because exiting the=20
parent would close file and socket descriptors, thus closing the=20
connection to the X server. A workaround would be to close the GUI=20
thread and the windows before the fork() and to open them again in the=20
child, but I'm not sure maxima users would appreciate to see their=20
window disappearing and reappearing...

Best regards,

Timoth=E9e

Re: problem building latest cvs snapshot

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

> Dmitri A. Sergatskov wrote:
>> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
>> Making all in tutorial
>> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
>> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
>> Exec failed: No such file or directory
>> See 'help x11' for more details
>
> gnuplot_x11 isn't even supposed to be started by this run of gnuplot.
> And it isn't -- I know, because I have no
> /usr/local/libexec/gnuplot/$version/gnuplot_x11 for the binary I've just
> tested, and it did work.  In other words, it's not the exec of
> gnuplot_x11 that failed you.  You'll have to dig deeper.

Cannot it happen due to "set term x11" in $HOME/.gnuplot? Gnuplot should 
avoid to read this file during "make".

---
PM

Re: problem building latest cvs snapshot

[<br...@ph...>]

Guys, I suspect we're chasing a red herring.

Let me repeat this:

Hans-Bernhard Br=F6ker wrote:
> gnuplot_x11 isn't even supposed to be started by this run of gnuplo=
t.=20
> And it isn't --=20

gnuplot_x11 is *not* actually needed by tutorial/Makefile's invocatio=
ns=20
of gnuplot.  I know that for several independent reasons:

1) my local working copy is versioned 4.2-rc1, so it looks for=20
/usr/local/libexec/gnuplot/4.2/gnuplot_x11, which never existed at an=
y=20
time during this exercise.

2) To be extra sure, I *removed* all installed gnuplots from this cyg=
win=20
  box, and it still failed to fail.

3) the LaTeX and EPS output files are generated in spite of those mes=
sages.

We're looking at *warnings* here, not errors.

Re: -persist and the wxWidgets terminal, continued

[Dave D. <dde...@es...>]

Timoth=E9e Lecomte <tim...@en...> writes:

> Ethan suggested two alternatives :
> - sending a fake signal SIGCHLD to octave, meaning "child process=20
> terminated". I tried, and it does not work. octave does not wait for
> SIGCHLD

SIGCHILD informs a parent that a child has died : if they were to do a
wait(), they would expect it to complete immediately, but it would
block. So that would be a bad idea I think.

> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20
> gnuplot, and I doubt it will actually work : since gnuplot's process is=20
> still running, octave still waits for it.
>
> Do any of you have a miraculous idea, or should I report that to the=20
> octave developers as I did for maxima ?
>

gnuplot can fork(), then allow the parent to exit, leaving the child
continuing to run the same code in exactly the same state, but
detached.

dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: Calling term->option() in init_terminal()

[<tim...@en...>]

Ethan A Merritt wrote:
> On Friday 28 July 2006 12:59 am, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Ethan in particular, as you were not there to give your point of view,
>>
>> Dmitri A. Sergatskov reported a problem to compile from CVS a few days=
=20
>> ago on the list. 'make' on a fresh installation fails in tutorial=20
>> because gnuplot_x11 is not found.=20
>>    =20
>
> I replied separately just a moment ago, but to recap:
> I can reproduce the error messages easily enough, and I understand why
> your patch makes them go away. =20
>
> But I cannot reproduce the build failure. =20
> For me it emits these messages but completes normally, as you would exp=
ect
> since the x11 driver is not actually used by the scripts in this direct=
ory.
>  =20
Did you start from a clean tree with the tutorial/eg?.tex absent ?

I do get the same error as Dmitri, but I agree that there seems to be=20
some hidden bug here.

As I was playing with ./src/gnuplot before 'make install', I was able to=20
hang gnuplot:

$ ./src/gnuplot
...
Terminal type set to 'wxt'
gnuplot> set term x11
Terminal type set to 'x11'
Options are '0'
gnuplot> Expected X11 driver: /home/tipote/libexec/gnuplot/4.1/gnuplot_x1=
1
Exec failed: No such file or directory
See 'help x11' for more details
plot x
Expected X11 driver: /home/tipote/libexec/gnuplot/4.1/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

=3D> here gnuplot doesn't come back to command line, a ctrl-c does the=20
trick though.

> As to the patch you sent Dmitri, isn't it more logical to fix things
> by having the Makefile set GNUTERM to "pslatex" prior to calling
> gnuplot?
>  =20
Yes, indeed.

Timoth=C3=A9e

Re: Calling term->option() in init_terminal()

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

On Friday 28 July 2006 12:59 am, Timoth=C3=A9e Lecomte wrote:
>=20
> Ethan in particular, as you were not there to give your point of view,
>=20
> Dmitri A. Sergatskov reported a problem to compile from CVS a few days=20
> ago on the list. 'make' on a fresh installation fails in tutorial=20
> because gnuplot_x11 is not found.=20

I replied separately just a moment ago, but to recap:
I can reproduce the error messages easily enough, and I understand why
your patch makes them go away. =20

But I cannot reproduce the build failure. =20
=46or me it emits these messages but completes normally, as you would expect
since the x11 driver is not actually used by the scripts in this directory.
=20
> But this leaves the question open : should the change for bug #1509033=20
> be reverted (at the price of GNUTERM possibly causing some drivers to=20
> segfault unless we check all of them), or can we live with gnuplot_x11=20
> always starting and just apply the quick fix ?

plot.c used to check explicitly for png/jpeg/tgif, and only call term->init=
()
for these cases.  This was wrong, if only because 'gif' should have been
on that list also.

The fix for #1509033 was to call term->init() in all cases. However, this
triggers overhead for x11 that turns out to be unnecessary if the user
switches to another terminal for plotting.

I suggest a middle course.  Let's have a list of "don't call me" drivers
rather than a list of "call me" drivers.  Right now the only candidate
for the "don't call me" list is x11.

As to the patch you sent Dmitri, isn't it more logical to fix things
by having the Makefile set GNUTERM to "pslatex" prior to calling
gnuplot?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem building latest cvs snapshot

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

> Dmitri A. Sergatskov wrote:
> > make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> > Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> > Exec failed: No such file or directory
> > See 'help x11' for more details
> > make[2]: *** [eg1.tex] Error 141
> > make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/dima/src/gnuplot'
> > make: *** [all] Error 2

On Tuesday 25 July 2006 03:32 pm, Timoth=C3=A9e Lecomte wrote:
> Hi Dmitri,=20
> Can you please try the attached patch ?

I can understand why the error messages occur, and why your patch
makes them go away.  But I do not understand why the make failed in
Dmitri's case.  When I try it here, I get the error messages from
the child process that would have become gnuplot_x11, but the main
process exits normally and "make" completes successfully.

Is there another error lurking here somewhere?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Calling term->option() in init_terminal()

[<tim...@en...>]

Hi,

Ethan in particular, as you were not there to give your point of view,

Dmitri A. Sergatskov reported a problem to compile from CVS a few days=20
ago on the list. 'make' on a fresh installation fails in tutorial=20
because gnuplot_x11 is not found. This issue comes from the change for=20
the bug #1509033, trying to adress the problem with GNUTERM and drivers=20
expecting term->options() to be run before term->init() for some=20
initializations. This has caused a collateral damage : gnuplot compiled=20
with the X11 terminal now launches gnuplot_x11 on startup, even if it is=20
not used.

I send a patch to Dmitri to define GNUPLOT_DRIVER_DIR so that his=20
compilation will succeed.

But this leaves the question open : should the change for bug #1509033=20
be reverted (at the price of GNUTERM possibly causing some drivers to=20
segfault unless we check all of them), or can we live with gnuplot_x11=20
always starting and just apply the quick fix ?

Best regards,

Timoth=C3=A9e

Re: problem building latest cvs snapshot

[Daniel J S. <dan...@ie...>]

Dmitri A. Sergatskov wrote:
> Today's cvs on Fedora Core 5 (x86_64).
> ./prepare
> CFLAGS="-O3 -m64 -pipe"
> ./configure --with-readline=gnu
> make
> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
> Making all in tutorial
> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details
> make[2]: *** [eg1.tex] Error 141
> make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/dima/src/gnuplot'
> make: *** [all] Error 2
> 
> (Of course it worked on the computer that had an older version
> installed in /usr/local ...)

[I think this is one for Hans...]

Right.  I suppose developers have had a /usr/local/libexec/gnuplot/4.1/gnuplot_x11 always present.  I've replicated the bug.  Running as su will install gnuplot_x11 and things will be fine.

So, this error message "Expected X11 driver:" is coming from gnuplot, the x11.trm file.  Gnuplot must be run in order to build the files eg1.tex, eg2.tex, etc.  Here is the command that fails:

	    fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);

and this X11_full_command_path is gotten from an environment variable:

    /* HBB 20020214: new code to prepend the environment X11_DRIVER_DIR
     * to the command name, if it doesn't contain any slashes yet */
    if (!strchr(optvec[0],'/')) {
	char *dir = getenv("GNUPLOT_DRIVER_DIR");

If GNUPLOT_DRIVER_DIR is not defined, then apparently the default is used which you've discovered contains no executable.

Hans, is the best solution here to simply define GNUPLOT_CRIVER_DIR as a relative path when running this tutorial Makefile?

Really, the gnuplot x11 driver is not needed for the purpose of this tutorial.  Perhaps there should be a command line option to indicate that the default window environment driver should not be launched?  Or better yet, an option to indicate the default terminal:

gnuplot -term postscript

Dan

Re: -persist command line option and the wxWidgets terminal

[Daniel J S. <dan...@ie...>]

Timoth=C3=A9e Lecomte wrote:

>> I can make a guess as to what may be going on here.  We've had this=20
>> discussion many times in the past, which is the fact that gnuplot only=
=20
>> retains information about a single plot.  If there are several X=20
>> windows open, still it is only the information about the most recent=20
>> plot that is available.  Hence, you'll see that the mouse functions=20
>> only work for the most recent X plot.
>=20
> And worse, with the "persist" implementation in the X11 terminal, you=20
> lose all zooming capabilities once gnuplot has exited.
> That's an additional argument that I forgor to mention if my maxima bug=
=20
> report...

OK, before that discussion gets reopened, there are two approaches as to =
how this could have been programmed.  One would be to zoom what is in the=
 gnuplot_x11 memory buffer.  I.e., make the existing plot bigger so it lo=
oks exactly the same only one is looking at a portion of the plot.  Or, a=
 second would be to send a command back to gnuplot with a new range and r=
eplot.  Consensus is the latter, and of course that means zooming can't b=
e done once gnuplot is closed.


>> Well, I know that for Octave, John decided to open a new instance of=20
>> gnuplot for every plot created.  That way, ever plot in Octave does=20
>> have its information retained.  John figured that gnuplot was a rather=
=20
>> small program so not much harm done.
>>
>> Maybe Maxima people have the same philosophy to get multiple windows,=20
>> only they figure why keep so many versions of gnuplot around?  It's=20
>> wasting memory.
>=20
> I don't really get what you mean here.

In Octave, if there are 20 windows open, it means there are twenty versio=
n of gnuplot running.  If Maxima uses the same strategy, i.e., to open a =
new version of gnuplot for every plot, they may have figured "Why do we n=
eed gnuplot still running for each of these windows?  We've got our plots=
, let's keep those and get rid of the gnuplot executables."  I'm not sayi=
ng that is what they did, but could have been their thinking.


> We are talking about UNIX here. Under Windows, maxima does something=20
> else (I think it is using the png terminal, and copy the image to their=
=20
> home-made gui).

Well, then I don't know what they are thinking.

Dan

Re: -persist and the wxWidgets terminal, continued

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
> Daniel J Sebald wrote:
>  =20
>>
>> I've never seen plots stay alive after Octave is=20
>> closed.  I've gone to the Octave source directory and grepped for=20
>> "persist".  I don't see it anywhere used as an option to gnuplot, and=20
>> the line of code I see uses "gnuplot" as the default launch command.
>>    =20
> Hmm, looks like I have missed something.
> The "persist" option was indeed coming from the wxWidgets terminal=20
> configuration dialog, not from octave.
> But my x11 terminal is also using "persist", and I can't find the=20
> app-defaults file that could have caused that.
>  =20
Well, I reinstalled gnuplot, and now it no longer uses "persist".=20
Something must have been messed up in the app-defaults.
So no problem with octave.

Sorry for the noise.

Best regards,

Timoth=C3=A9e

Re: -persist and the wxWidgets terminal, continued

[<tim...@en...>]

Daniel J Sebald wrote:
> Timoth=C3=A9e Lecomte wrote:
>> Hi,
>>
>> I just tried the wxWidgets terminal with octave (2.1.73, not the last=20
>> development version though).
>>
>> Bad news : it uses "persist" too.
>
> Are you sure?  I've never seen plots stay alive after Octave is=20
> closed.  I've gone to the Octave source directory and grepped for=20
> "persist".  I don't see it anywhere used as an option to gnuplot, and=20
> the line of code I see uses "gnuplot" as the default launch command.
Hmm, looks like I have missed something.
The "persist" option was indeed coming from the wxWidgets terminal=20
configuration dialog, not from octave.
But my x11 terminal is also using "persist", and I can't find the=20
app-defaults file that could have caused that.

Timoth=C3=A9e

Re: -persist and the wxWidgets terminal, continued

[Daniel J S. <dan...@ie...>]

Timoth=C3=A9e Lecomte wrote:
> Hi,
>=20
> I just tried the wxWidgets terminal with octave (2.1.73, not the last=20
> development version though).
>=20
> Bad news : it uses "persist" too.

Are you sure?  I've never seen plots stay alive after Octave is closed.  =
I've gone to the Octave source directory and grepped for "persist".  I do=
n't see it anywhere used as an option to gnuplot, and the line of code I =
see uses "gnuplot" as the default launch command.

Please use 2.9.x series as reference.  There are major changes in store f=
or Octave.  If you must compile, I know, it takes a while.

>=20
> octave uses a pipe to talk with gnuplot, and keeps it open through the=20
> whole octave session. The "persist" behaviour appears when you close=20
> octave (by issuing "quit" at octave prompt). I guess the process goes=20
> the following way : octave closes the pipe, gnuplot engages its exit=20
> process, the wxWidgets says "hold on !" until all the windows are=20
> closed, and ... octave waits for gnuplot to terminate, so you end up=20
> with what looks like a frozen prompt until you realize that you have to=
=20
> close the wxt window (you can also hit ctrl-c twice to force octave to=20
> close).
>=20
> Like maxima, octave relies on the X11 "persist" behaviour.

I don't think so.

>=20
> Ethan suggested two alternatives :
> - sending a fake signal SIGCHLD to octave, meaning "child process=20
> terminated". I tried, and it does not work. octave does not wait for SI=
GCHLD
> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20
> gnuplot, and I doubt it will actually work : since gnuplot's process is=
=20
> still running, octave still waits for it.
>=20
> Do any of you have a miraculous idea, or should I report that to the=20
> octave developers as I did for maxima ?

Talk directly with John Eaton.  He's the only one who will know.  But I'd=
 say it would be best to compile the latest version and come up with a pa=
tch that works with what you are trying to accomplish.  (The file __gnupl=
ot_raw__.cc contains what you are looking for.)

Dan

-persist and the wxWidgets terminal, continued

[<tim...@en...>]

Hi,

I just tried the wxWidgets terminal with octave (2.1.73, not the last=20
development version though).

Bad news : it uses "persist" too.

octave uses a pipe to talk with gnuplot, and keeps it open through the=20
whole octave session. The "persist" behaviour appears when you close=20
octave (by issuing "quit" at octave prompt). I guess the process goes=20
the following way : octave closes the pipe, gnuplot engages its exit=20
process, the wxWidgets says "hold on !" until all the windows are=20
closed, and ... octave waits for gnuplot to terminate, so you end up=20
with what looks like a frozen prompt until you realize that you have to=20
close the wxt window (you can also hit ctrl-c twice to force octave to=20
close).

Like maxima, octave relies on the X11 "persist" behaviour.

Ethan suggested two alternatives :
- sending a fake signal SIGCHLD to octave, meaning "child process=20
terminated". I tried, and it does not work. octave does not wait for SIGC=
HLD
- mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20
gnuplot, and I doubt it will actually work : since gnuplot's process is=20
still running, octave still waits for it.

Do any of you have a miraculous idea, or should I report that to the=20
octave developers as I did for maxima ?

Best regards,

Timoth=C3=A9e

Re: Fwd: [Gnuplot-developers] [ gnuplot-Bugs-1527701 ] -persist halts gnuplot, not exits

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

> "Don't exit until all plot windows are closed."
> And then, why not supporting mouse operations since we can ?

Just to remember you: In the first years of mousing (since cca 1997 or 98), 
mousing was directly in the driver (pm, then x11). Later (cca 2000) it 
changed into term api and thus the gnuplot core was required for mousing.

---
PM

Re: Fwd: [Gnuplot-developers] [ gnuplot-Bugs-1527701 ] -persist halts gnuplot, not exits

[<tim...@en...>]

Ethan A Merritt wrote:
> On Thursday 27 July 2006 01:26 pm,  Timoth=E9e Lecomte wrote:
>  =20
>> Ethan Merritt wrote:
>>    =20
>>> I suggest that wxt should work similarly.  When gnuplot sees that 'ex=
it'
>>> command, it should set a flag for wxt to see.  With the flag set, all
>>> operations that require code outside the wxt driver itself should be
>>> disabled.
>>>  =20
>>>      =20
>> In the case of wxt, gnuplot is still there and the routines definitely=
=20
>> available.
>> On the other hand, disabling all operations that require core routines=
=20
>> means disable all mouse routines. That would be sad.
>>    =20
>
> But if you want to continue using gnuplot, why did you exit from it?
>  =20
I guess the idea was to use "persist" when gnuplot exits _itself_, i.e.=20
when the input is a script and gnuplot reaches the end.
> As I see it, the keyword "persist" means
> "Keep the last plot on the screen even after gnuplot goes away".
>  =20
That's how it works for the x11 terminal.
But as wxt (and the windows terminal too) lives _in_ gnuplot, this=20
meaning doesn't make sense anymore, and becomes :
"Don't exit until all plot windows are closed."
And then, why not supporting mouse operations since we can ?

> Post-4.2 we can re-examine what additional operations are reasonable to
> support while in this persistent state.  This is directly analogous to =
the
> set of mousing operations it would be possible to support in an embedde=
d
> SVG plot. Since gnuplot itself is no longer around at the time of
> interaction with the SVG document, all information for mouse interactio=
n
> must be embedded with it. =20
>
> For example, I'd like to rework zooming so that it does not require
> re-reading data from a file.

I also have a couple of plans for post-4.2 regarding mouse interaction,=20
now that I am a bit more familiar with the current behaviour.
The svg stuff seems very exciting by the way.

Best regards,

Timoth=E9e

Re: Fwd: [Gnuplot-developers] [ gnuplot-Bugs-1527701 ] -persist halts gnuplot, not exits

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

On Thursday 27 July 2006 01:26 pm,  Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
> > I suggest that wxt should work similarly.  When gnuplot sees that 'exit'
> > command, it should set a flag for wxt to see.  With the flag set, all
> > operations that require code outside the wxt driver itself should be
> > disabled.
> >  =20
> In the case of wxt, gnuplot is still there and the routines definitely=20
> available.
> On the other hand, disabling all operations that require core routines=20
> means disable all mouse routines. That would be sad.

But if you want to continue using gnuplot, why did you exit from it?

As I see it, the keyword "persist" means
"Keep the last plot on the screen even after gnuplot goes away".
There is no promise that you can continue to plot new things or
change the plot that is already there. Indeed there is no promise that
you can continue to read mouse coordinates either, although x11 does
allow that and wxt can certainly do the same.

Post-4.2 we can re-examine what additional operations are reasonable to
support while in this persistent state.  This is directly analogous to the
set of mousing operations it would be possible to support in an embedded
SVG plot. Since gnuplot itself is no longer around at the time of
interaction with the SVG document, all information for mouse interaction
must be embedded with it. =20

=46or example, I'd like to rework zooming so that it does not require
re-reading data from a file.  This would have a number of benefits:

1) It would be possible to zoom plots read from in-line data (plot '-').
   This would benefit all drivers.

2) It would (maybe) be possible to do at least simple zooming directly
   in gnuplot_x11 without involving calls back to gnuplot. SVG supports
   zooming natively, but exactly what that means for a gnuplot-generated
   plot I am not yet sure.

3) It would be possible to have zooming active for more than one plot,
   at least for x11 and svg.  Maybe wxt and pm as well.

	Ethan

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem building latest cvs snapshot

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

On 7/25/06, Petr Mikulik <mi...@ph...> wrote:

> Cannot it happen due to "set term x11" in $HOME/.gnuplot? Gnuplot should
> avoid to read this file during "make".
>

my .gnuplot has only "set mouse"

> ---
> PM
>

Dmitri.
--

Re: problem building latest cvs snapshot

[<tim...@en...>]

Dmitri A. Sergatskov wrote:
> Today's cvs on Fedora Core 5 (x86_64).
> ./prepare
> CFLAGS=3D"-O3 -m64 -pipe"
> ./configure --with-readline=3Dgnu
> make
> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
> Making all in tutorial
> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details
> make[2]: *** [eg1.tex] Error 141
> make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/dima/src/gnuplot'
> make: *** [all] Error 2
>
> (Of course it worked on the computer that had an older version
> installed in /usr/local ...)
>
> Sincerely,
>
> Dmitri.
>  =20

Hi Dmitri,

Can you please try the attached patch ?

I think this got broken when we added the call to term->options() in=20
term.c:1729:init_terminal(), to fix the use of GNUTERM for all terminals=20
at once (otherwise some of them would no initialize some of their=20
values). As a consequence, when x11 is compiled in, gnuplot initializes=20
it by launching gnuplot_x11 even if the script does not actually uses=20
the x11 terminal. As per the imprecision on term->fillbox() that we=20
discussed some times ago, some drivers assume that term->options() will=20
be always called before term->init(), whereas others don't and take more=20
care. The fix in init_terminal() was for the former, while the latter=20
(as X11) lose part of their flexibility in the game...

Best regards,

Timoth=E9e

Re: problem building latest cvs snapshot

[<br...@ph...>]

Petr Mikulik wrote:
> Cannot it happen due to "set term x11" in $HOME/.gnuplot? 

No.

gnuplot_x11 isn't actually needed until the plot window is about to be 
actually opened, i.e. the first 'plot', 'splot' or 'set multiplot' with 
'set term x11' open.  tutorial/Makefile never opens an X11 window, so it 
*cannot* need gnuplot_x11.  I can accept that people want it to complain 
about not finding it, even long before the terminal it's actually 
needed, because that signals a broken gnuplot installation.  But it 
can't *fail* because it can't find it.

[Fwd: Re: problem building latest cvs snapshot]

[<tim...@en...>]

Second try as it did not seem to go through gnuplot-beta ...

Dmitri A. Sergatskov wrote:
> Today's cvs on Fedora Core 5 (x86_64).
> ./prepare
> CFLAGS=3D"-O3 -m64 -pipe"
> ./configure --with-readline=3Dgnu
> make
> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
> Making all in tutorial
> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details
> make[2]: *** [eg1.tex] Error 141
> make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/dima/src/gnuplot'
> make: *** [all] Error 2
>
> (Of course it worked on the computer that had an older version
> installed in /usr/local ...)
>
> Sincerely,
>
> Dmitri.
>  =20

Hi Dmitri,

Can you please try the attached patch in tutorial/ ?

I think this got broken when we added the call to term->options() in=20
term.c:1729:init_terminal(), to fix the use of GNUTERM for all terminals=20
at once (otherwise some of them would no initialize some of their=20
values). As a consequence, when x11 is compiled in, gnuplot initializes=20
it by launching gnuplot_x11 even if the script does not actually uses=20
the x11 terminal. As per the imprecision on term->fillbox() that we=20
discussed some times ago, some drivers assume that term->options() will=20
be always called before term->init(), whereas others don't and take more=20
care. The fix in init_terminal() was for the former, while the latter=20
(as X11) lose part of their flexibility in the game...

Best regards,

Timoth=E9e

Re: Documentation for 4.2

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

> should be done in the "news" section of gnuplot.doc. Currently there is 
> a section entitled "What's new in 4.2" and there is also the section

Have a look there, and also to NEWS files, and add lines with features you 
have added, or were added and are not mentioned.

> "What's new in 4.0". It seems to me that the latter should be removed, 
> after having checked that the items are well documented in the 
> appropriate places. Does that sound good ?

No, let this section in. It helps people migrating from 3.7, as well as an 
overview of our work.

> As a side-note, I found the following comment (gnuplot.doc:6857):
> "This was valid only for gnuplot 4.0 (now mousing is on by default as in
> the case of other screen terminals):
>
> I think this paragraph should be removed entirely. Please tell me if it 
> is appropriate.

I think this can be removed.

---
PM