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

Re: names of gnuplot Win32 binaries

[don t. <dt...@to...>]

> 2. Console-mode executable gnuplot.exe was added to the package. This is
>   now the recommended binary to be used under Windows -- the same name

Sorry if this is a stupid question, but I haven't been paying much
attention to this thread. Is 'gnuplot.exe' simply what you get when
you use the *nix configure/Makefile in a cygwin environment?

And what makefile generates the 'wgnuplot_pipes.exe' ?  I always
use makefile.cyg for generating windows binaries and I've never
seen this mysterious thing appear :-)

Maybe a general cleanup of the various {makefile,config}.??? in config/
is called for.  Or at least a README that explains what they all
do.  This is by no means clear from their names.  For example,
makefile.nt is for VisualC 6.x but who would guess this from
the name?

Don Taber

Re: names of gnuplot Win32 binaries

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

Final decision for naming gnuplot Win32 executables for gnuplot binary 
releases (for the current development version 4.3):

1. Names and functionality of wgnuplot.exe and wgnuplot_pipes.exe (GUI 
   command line mode) and pgnuplot.exe (piper to wgnuplot.exe) stay intact.

2. Console-mode executable gnuplot.exe was added to the package. This is 
   now the recommended binary to be used under Windows -- the same name 
   as on all other platforms. The programs (like Octave) which want to use 
   it can bundle/use the gnuplot binary distribution (see below) and replace 
   the current call to "pgnuplot" by "gnuplot". (It is a development version 
   of gnuplot but it works very well.)

Updated package gp43-Nov21_2008-winbin.zip is available at
    http://gnuplot.sourceforge.net/development/binaries/

For Octave: please remove the Octave-forge patches for gnuplot sources as 
they are no more necessary. Use the gnuplot sourceforge site to contribute 
new patches.

---
PM

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated. (ChangeLog Date 2008-11-15)

[Tatsuro M. <tma...@ya...>]

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-11-11)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: names of gnuplot Win32 binaries

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik <mi...@ph...> wrote:

> Therefore there are the following solutions for what the gnuplot 
> distribution for win32 can contain:
> 1. There are 4 full-featured executables:
>     wgnuplot.exe	... as nowadays
>     wgnuplot_pipes.exe	... as nowadays
>     pgnuplot_small.exe 	... renamed current pgnuplot.exe
>     gnuplot.exe		... console mode gnuplot
>     pgnuplot.exe	... copy of gnuplot.exe
> 2. There are 3 full-featured executables:
>     wgnuplot.exe	... as nowadays
>     wgnuplot_pipes.exe	... as nowadays
>     pgnuplot_small.exe 	... renamed current pgnuplot.exe
>     gnuplot.exe		... console mode gnuplot
>     pgnuplot.exe	... small executable piping stdin to gnuplot.exe
> 			    instead of wgnuplot.exe (I've send the code
> 			    yesterday)
> 3. There are 3 full-featured executables:
>     wgnuplot.exe	... as nowadays
>     wgnuplot_pipes.exe	... as nowadays
>     pgnuplot.exe 	... the current version piping to wgnuplot
>     gnuplot.exe		... console mode gnuplot
> 
> Choice 3 is to be rejected as no Program profits from the console mode 
> improvements.
> 
> Using 2. will save cca 2 MB of disk space with respect to choice 1.
> 
> So - shell the distribution contain 1 or 2?

I prefer case 1 because the case 2 causes additional overhead.
Increase of 2MB disk space is not a serious problem in current computer environments.
Perhaps case 1 is the almopst same as that Michael's proporsal.

However my mind does not always mean to reject the case 2.

Regards

Tatsuro




--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: names of gnuplot Win32 binaries

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

> However, the original pgnuplot is written by Hans so that the name of
> console mode of gnuplot on win32 cannot be called as 'pgnuplot.exe'
> as long as Hans does not agree with Petr's opinion.

We agree that the console mode will be called gnuplot.exe.
We all agree gnuplot.exe outperforms current pgnuplot.exe -> wgnuplot.exe.
Now the question is whether pgnuplot.exe will use gnuplot.exe instead of
the current use of wgnuplot.exe and how to achieve this.

> No.  pgnuplot can stay as it is.  Real console gnuplot does more than
> pgnuplot can, and does it better.  So programs using pgnuplot now will
> want to switch to the new gnuplot.exe anyway.

A windows Program cannot switch easily:
(a) it will take till next year when gnuplot 4.4 gets released;
(b) it may take some months/years till users upgrade gnuplot;
(c) all this is beyond control of gnuplot developers and of the Program
    developer.
Therefore:
1. all current Program call pgnuplot.exe.
2. nobody knows whether gnuplot.exe is available for Program;
We have to cope with this and provide a reliable service for gnuplot and
Program's users and Program distributors/authors.

Possible solutions for the Program's code:
A. Program's author tries to autoconfigure on runtime by
	popen("gnuplot.exe --version")
   If it can read something, then use "gnuplot.exe", otherwise use
   "pgnuplot.exe". This need a change to source code of Program.
B. Program does not care about gnuplot version, call always "pgnuplot.exe"
   -- then let pgnuplot.exe to choose what it will do.


Therefore there are the following solutions for what the gnuplot 
distribution for win32 can contain:
1. There are 4 full-featured executables:
    wgnuplot.exe	... as nowadays
    wgnuplot_pipes.exe	... as nowadays
    pgnuplot_small.exe 	... renamed current pgnuplot.exe
    gnuplot.exe		... console mode gnuplot
    pgnuplot.exe	... copy of gnuplot.exe
2. There are 3 full-featured executables:
    wgnuplot.exe	... as nowadays
    wgnuplot_pipes.exe	... as nowadays
    pgnuplot_small.exe 	... renamed current pgnuplot.exe
    gnuplot.exe		... console mode gnuplot
    pgnuplot.exe	... small executable piping stdin to gnuplot.exe
			    instead of wgnuplot.exe (I've send the code
			    yesterday)
3. There are 3 full-featured executables:
    wgnuplot.exe	... as nowadays
    wgnuplot_pipes.exe	... as nowadays
    pgnuplot.exe 	... the current version piping to wgnuplot
    gnuplot.exe		... console mode gnuplot

Choice 3 is to be rejected as no Program profits from the console mode 
improvements.

Using 2. will save cca 2 MB of disk space with respect to choice 1.

So - shell the distribution contain 1 or 2?

---
PM

Re: names of gnuplot Win32 binaries

[Tatsuro M. <tma...@ya...>]

Hello

--- Michael Goffioul <mic...@gm...> wrote:

> AFAIK, pgnuplot.exe and gnuplot.exe would achieve the same goal.
> So why not simply "cp gnuplot.exe pgnuplot.exe" [1] at installation
> time, and rename the old pgnuplot into something else? Then
> advertise that pgnuplot is deprecated for a given transition period.
> 
> Michael.
> 
> [1] don't think symlink would be good in that context

Thank you for Michaek for your reply.
Mmmm. It sounds nice proposal to me.

>>Hans-Bernhard 
What do you think about Michael's proprosal?
 
Rerards

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: names of gnuplot Win32 binaries

[Tatsuro M. <tma...@ya...>]

Hello

Petr Mikulik's opinion is based on keeping backward compatibility while Hans-Bernhard Br将モker's one
is based on the consistency in all platforms.

For me, both opinions are reasonable.  I cannot judge which is better.

However, the original pgnuplot is written by Hans so that the name of console mode of gnuplot on win32
cannot be called as 'pgnuplot.exe' as long as Hans does not agree with Petr's opinion.

The most important thing is the console mode of gnuplot to be public to windows users.

I think that it is better to find the compromising point that console mode of gnuplot is to be called
'gnuplot.exe' rather than to continue to discuss on this matter.

Any comments?

Regards

Tatsuro

   

--- Hans-Bernhard Br将モker <HBB...@t-...> wrote:

> Petr Mikulik wrote:
> 
> > The pgnuplot program serves to capture the standard input and pass it to 
> > gnuplot for drawing. As it is more efficient to pass data to gnuplot.exe 
> > instead of wgnuplot.exe (it was the aim of the console mode gnuplot), then
> > pgnuplot.c could use this code:
> 
> No.  pgnuplot can stay as it is.  Real console gnuplot does more than 
> pgnuplot can, and does it better.  So programs using pgnuplot now will 
> want to switch to the new gnuplot.exe anyway.
> 
> Yes, programs using pgnuplot now will have to be modified.  But for most 
> of them that modification will just be a simplification --- they don't 
> need to special-case Windows any more.
> 
> > Then Windows programs can use the traditional method of piping to 
> > pgnuplot.exe on Windows but with improved efficiency. 
> 
> Or they can just call gnuplot.exe directly, which is better in every 
> conceivable way.
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: names of gnuplot Win32 binaries

[Hans-Bernhard B. <HBB...@t-...>]

Petr Mikulik wrote:

> The pgnuplot program serves to capture the standard input and pass it to 
> gnuplot for drawing. As it is more efficient to pass data to gnuplot.exe 
> instead of wgnuplot.exe (it was the aim of the console mode gnuplot), then
> pgnuplot.c could use this code:

No.  pgnuplot can stay as it is.  Real console gnuplot does more than 
pgnuplot can, and does it better.  So programs using pgnuplot now will 
want to switch to the new gnuplot.exe anyway.

Yes, programs using pgnuplot now will have to be modified.  But for most 
of them that modification will just be a simplification --- they don't 
need to special-case Windows any more.

> Then Windows programs can use the traditional method of piping to 
> pgnuplot.exe on Windows but with improved efficiency. 

Or they can just call gnuplot.exe directly, which is better in every 
conceivable way.

Re: names of gnuplot Win32 binaries

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

\> > The primary intention was to achieve better functionality of programs piping
> > commands to gnuplot, like Octave, i.e. an efficient pgnuplot.exe
> > replacement.
> 
> Not quite.  Given that pgnuplot itself was always meant as a replacement for
> the missing console, pipe-capable implementation of gnuplot for MS Windows.
> 
> We're effectively talking about the replacement of a replacement here.
> 
> > Thus, what should be the name of this executable?
> 
> gnuplot.exe

Well, then the console mode version of gnuplot will be called gnuplot.exe.

The pgnuplot program serves to capture the standard input and pass it to 
gnuplot for drawing. As it is more efficient to pass data to gnuplot.exe 
instead of wgnuplot.exe (it was the aim of the console mode gnuplot), then
pgnuplot.c could use this code:

{
    FILE *gp;
    gp = popen("gnuplot.exe", "wb");
    if (!gp) {
	printf("Cannot run gnuplot.exe!\n");
	return 1;
    }
    while (fgets(psBuffer, BUFFER_SIZE, stdin) != NULL) {
	fprintf(gp, psBuffer);
    }
    fclose(gp);
    return 0;
}


Then Windows programs can use the traditional method of piping to 
pgnuplot.exe on Windows but with improved efficiency. The tradition 
(backwards compatibility) is important as the other programs don't have to 
take care which version of gnuplot is installed -- and drawing will work 
regardless the executable the pgnuplot is piping data to.


Hans-Bernhard, is this approach OK for you?

---
PM

Re: legend bug with style image on win32

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

On Sunday 16 November 2008, Pieter Cristiaan de Groot wrote:
> Hello all,
> 
> I would like to report a bug I found in Gnuplot 4.3 Patchlevel 0, 
> September 2008. terminal windows on win32 machine.
> 
> I am reasonably sure that this should be posted here, if not please tell 
> me where.

This is closely related to existing bug report #2163532 on the
SourceForge bug tracker

 https://sourceforge.net/tracker/index.php?func=detail&aid=2163532&group_id=2055&atid=102055
 
Several fixes addressing this problem were made already, but clearly 
there are still remaining problems.

> When making a colorplot using:
> 
> set style data image
> set view map
> splot 'datafile'
> 
> the key that gets automatically generated (the filename) is messed up.
> 
> Where in previous versions (4.2.4) the key would appear above the axes 
> (I think tmargin), now it is placed behind the colorplot.

I think that is expected behaviour.  The key is always placed inside the
plot by default.  The fact that your example sort of worked in 4.2 is an
accident.  In fact the key box was placed quite incorrectly, but in your
case it just happened to leave the top line of the key in an acceptable
position.  

> Trying to replace the key position with 'set key lmargin/tmargin' etc. 
> gives funny results. Of these 'bmargin' is the worst, since it 
> completeley crashes gnuplot.

Indeed. 
I have added that to the list of problems on the tracker item.

	thanks for the bug report,

		Ethan (sf...@us...)

 
> Unfortunately my skills do not allow fixing this myself, so I hope 
> somebody can pick up this report.
> 
> Thanks for all the efforts, the program is great!
> 
> Pieter

-- 
Ethan A Merritt

legend bug with style image on win32

[Pieter C. de G. <p.c...@tu...>]

Hello all,

I would like to report a bug I found in Gnuplot 4.3 Patchlevel 0, 
September 2008. terminal windows on win32 machine.

I am reasonably sure that this should be posted here, if not please tell 
me where.

When making a colorplot using:

set style data image
set view map
splot 'datafile'

the key that gets automatically generated (the filename) is messed up.

Where in previous versions (4.2.4) the key would appear above the axes 
(I think tmargin), now it is placed behind the colorplot. This can be 
found out by choosing an extremely long filename, such that it comes out 
 under the plot on the left side.

Trying to replace the key position with 'set key lmargin/tmargin' etc. 
gives funny results. Of these 'bmargin' is the worst, since it 
completeley crashes gnuplot.

Unfortunately my skills do not allow fixing this myself, so I hope 
somebody can pick up this report.

Thanks for all the efforts, the program is great!

Pieter

Re: expanding allowed usage of word() command

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li...
> Cc: "m sutton" <mw...@us...>
> Subject: Re: expanding allowed usage of word() command
> Date: Sun, 9 Nov 2008 17:55:09 -0700
> 
> 
> On Sunday 09 November 2008, Ethan A Merritt wrote:
> > How about:
> >     plot for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq 
> > "lines" ? $2 : NaN), \
> >          for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq 
> > "points" ? $2 : NaN)
> >
> 
> That should obviously have been
> 
>       plot for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq 
> "lines" ? $2 : NaN)  with lines, \
>            for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq 
> "points" ? $2 : NaN) with points

It never occurred to me to make a qualification to the using portion.  I will give this a try on some real data.  The only drawback I see is this would be inefficient when a line with many points is "skipped" by the second part of the plot statement and vice versa.  But this approach is way better than using empty labels to plot points.

Mike Sutton


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x isupdated.(ChangeLog Date 2008-11-11)

[Tatsuro M. <tma...@ya...>]

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-11-11)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: [Gnuplot-cvs] gnuplot/src interpol.c,1.35,1.36

[Philipp K. J. <ja...@ie...>]

My bad, now fixed.

On Tuesday 11 November 2008 15:48, Hans-Bernhard Bröker wrote:
> Philipp K. Janert wrote:
> > !     /*  sigma = sqrt( (sigma - avg*avg)/(double)n ); /* Standard
> > Deviation */
>
> Ahem... no nested comments, please.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: [Gnuplot-cvs] gnuplot/src interpol.c,1.35,1.36

[Hans-Bernhard B. <HBB...@t-...>]

Philipp K. Janert wrote:
> !     /*  sigma = sqrt( (sigma - avg*avg)/(double)n ); /* Standard Deviation */

Ahem... no nested comments, please.

Re: names of gnuplot Win32 binaries

[Hans-Bernhard B. <HBB...@t-...>]

Petr Mikulik wrote:

> The primary intention was to achieve better functionality of programs piping 
> commands to gnuplot, like Octave, i.e. an efficient pgnuplot.exe 
> replacement.

Not quite.  Given that pgnuplot itself was always meant as a replacement 
for the missing console, pipe-capable implementation of gnuplot for MS 
Windows.

We're effectively talking about the replacement of a replacement here.

> Thus, what should be the name of this executable?

gnuplot.exe

> Choice 1.
> The executable will be called pgnuplot.exe -- it will replace the current 
> pgnuplot.exe. No change is required for programs using gnuplot as a plotting 
> engine.

There already *is* a change in octave and similar programs right now --- 
the change that if they're running on Windows, they call "pgnuplot" 
instead of "gnuplot".  So we're not really talking about a new change, 
but rather the removal of a previous change.

> Choice 2.
> The executable is called gnuplot.exe. Then, every platform will have an
> executable called gnuplot. However -- this will happen somewhen in future 
> (when gnuplot 4.4 is released).

Why the delay?

> Drawbacks:
> 1. the name clashes with the name of the x11-capable executable 
>    (user/program cannot determine which one gets called)

Which is exactly as it should be.  gnuplot on Linux is called the same 
regardless of whether it's built with wxt or X11 as the default 
terminal.  gnuplot on Windows should be called gnuplot regardless if the 
primary terminal is Windows or X11.

> 2. no piping program is set-up to use gnuplot.exe under Windows, 

So you know for sure that _no_ piping program on Windows expects to find 
the cygwin+X11 (or even a non-GUI) gnuplot.exe?

> Thus, it would at least require to reimplement pgnuplot.c so that it 
> redirects all characters from stdin into gnuplot.exe instead of WinMessages 
> into wgnuplot.exe.

No.  pgnuplot should stay exactly as it is (bugfixes set aside), and 
continue to provide the same service it always did, for programs 
expecting exactly that behaviour.

Re: names of gnuplot Win32 binaries

[Tatsuro M. <tma...@ya...>]

Hello Petr

Thank you for your mail for the purposes of resolving the issue of names of gnuplot Win32 binaries.

Previously I had the same opinion with Hans-Bernhard Broeker. But I have compromize with Petr's
opininon on the point of backward compatiblity.

However if Hans does not agree with the name, I think that it is impossible to use the name
'pgnuplot.exe' because it is originally written by Hans and nobody has right to name a console mode
gnuplot Win32 binary to be called as pgnuplot.

Regards

Tatsuro



--- Petr Mikulik <mi...@ph...> wrote:

> Thus, what should be the name of this executable?
> 
> Choice 1.
> The executable will be called pgnuplot.exe -- it will replace the current 
> pgnuplot.exe. No change is required for programs using gnuplot as a plotting 
> engine.
> 
> Choice 2.
> The executable is called gnuplot.exe. Then, every platform will have an
> executable called gnuplot. However -- this will happen somewhen in future 
> (when gnuplot 4.4 is released).
> Drawbacks:
> 1. the name clashes with the name of the x11-capable executable 
>    (user/program cannot determine which one gets called)
> 2. no piping program is set-up to use gnuplot.exe under Windows, and in 
>    future there will be ambiguity whether to call pgnuplot.exe or 
>    gnuplot.exe.
> Thus, it would at least require to reimplement pgnuplot.c so that it 
> redirects all characters from stdin into gnuplot.exe instead of WinMessages 
> into wgnuplot.exe.
> 
> 
> Therefore, in my option, the best way to ensure compatibility is to call 
> the console-capable executable pgnuplot.exe. There will be no change needed 
> for other programs using gnuplot, power users could use pgnuplot.exe for 
> console mode with Windows terminal and others will not be confused.
> 
> I have proposed to rename the current binary of pgnuplot.c to 
> pgnuplot_small.exe if somebody still needs to use it.
> 
> 
> Opinions - votes?
> 
> ---
> Petr Mikulik
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: names of gnuplot Win32 binaries

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

On Tuesday 11 November 2008, Petr Mikulik wrote:
> 	Hi all,
> 
> we should solve an issue with naming Windows gnuplot binaries after the 
> recent addition of the console-capable target.

I have no opinion.  I leave it to those of you who are using Windows.

	Ethan


> Current situation:
> - wgnuplot.exe:
>   binary with a GUI for text input; piping into it does not work; piping
>   "inside" (e.g. "plot '<preprocess data.dat'") does not work
> - wgnuplot_pipes.exe:
>   as above, piping "inside" works (drawback: executable is tighed to a 
>   a console window)
> - pgnuplot.exe: helper program used for piping commands into wgnuplot.exe, 
>   i.e. redirect standard input
> - gnuplot.exe: console mode binary compiled by Cygwin with X11 terminal 
>   (requires running X-server - works OK with eXceed, cygwin's X11, etc.)
> 
> Recently, Michael Goffioul provided a patch to gnuplot sources what enables 
> to compile Windows gnuplot binary with console text input and Windows 
> terminal, see [ 1627936 ] Gnuplot Win32 in console mode 
> http://sourceforge.net/tracker/?func=detail&atid=302055&aid=1627936&group_id=2055
> 
> The primary intention was to achieve better functionality of programs piping 
> commands to gnuplot, like Octave, i.e. an efficient pgnuplot.exe 
> replacement.
> 
> Thus, what should be the name of this executable?
> 
> Choice 1.
> The executable will be called pgnuplot.exe -- it will replace the current 
> pgnuplot.exe. No change is required for programs using gnuplot as a plotting 
> engine.
> 
> Choice 2.
> The executable is called gnuplot.exe. Then, every platform will have an
> executable called gnuplot. However -- this will happen somewhen in future 
> (when gnuplot 4.4 is released).
> Drawbacks:
> 1. the name clashes with the name of the x11-capable executable 
>    (user/program cannot determine which one gets called)
> 2. no piping program is set-up to use gnuplot.exe under Windows, and in 
>    future there will be ambiguity whether to call pgnuplot.exe or 
>    gnuplot.exe.
> Thus, it would at least require to reimplement pgnuplot.c so that it 
> redirects all characters from stdin into gnuplot.exe instead of WinMessages 
> into wgnuplot.exe.
> 
> 
> Therefore, in my option, the best way to ensure compatibility is to call 
> the console-capable executable pgnuplot.exe. There will be no change needed 
> for other programs using gnuplot, power users could use pgnuplot.exe for 
> console mode with Windows terminal and others will not be confused.
> 
> I have proposed to rename the current binary of pgnuplot.c to 
> pgnuplot_small.exe if somebody still needs to use it.
> 
> 
> Opinions - votes?


-- 
Ethan A Merritt

Re: Gnuplot on Windows

[Reinier H. <re...@he...>]

Hi,

Petr Mikulik wrote:
>> When wgnuplot is closed manually, the pgnuplot program stays alive. It is
>> therefore very hard to detect whether the gnuplot instance has been killed (in
>> which case I want to respawn one). I've attached a patch to pgnuplot.c to fix
>> this issue: it will check whether the wgnuplot process is still alive when it
>> receives input. By writing an empty string from my python program twice (with
>> a small delay in between) I can detect that wgnuplot is closed. Perhaps it
>> would be even better to call select() on stdin, but I think this is usually
>> good enough.
>>     
>
> There is a new pgnuplot replacement just available from cvs; we are 
> discussing the proper name (pgnuplot? gnuplot?) -- you should have got a 
> copy of this email. With this new pgnuplot you will have no such problems.
>   
That's great! I think calling it pgnuplot will indeed be the best 
option, since it would behave similar to the older version and require 
no changes to software depending on that. Do I understand correctly that 
this binary does not have a command input window next to stdin and stdout?

Btw, if the old pgnuplot is kept somewhere it still might be good to 
apply my patch so that it terminates if wgnuplot is closed.

>> The second problem is that my programs spawns quite a few gnuplot instances,
>> and they become hard to distinguish. On linux the wxt terminal supports a
>> "title" option that allows to give the windows a title, e.g. set terminal wxt
>> title "test". It would be great to have this in the windows terminal too.
>>     
>
> This feature is available in the development version 4.3.x since May.
> It seems it would be interesting if this gets ported into 4.2.
>   
Ah, sorry, I did not know. I will give the 4.3 test binary a try then! 
Also, backporting sounds reasonable if it's not too much work.

> Well, what about a portable way
> 	set termoption title "xxx"
> Is this feasible?
>   
Sounds good!

> ---
> PM
>
>   
Regards,

-- 
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands

Tel: +31 6 10852639

Re: Gnuplot on Windows

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

> When wgnuplot is closed manually, the pgnuplot program stays alive. It is
> therefore very hard to detect whether the gnuplot instance has been killed (in
> which case I want to respawn one). I've attached a patch to pgnuplot.c to fix
> this issue: it will check whether the wgnuplot process is still alive when it
> receives input. By writing an empty string from my python program twice (with
> a small delay in between) I can detect that wgnuplot is closed. Perhaps it
> would be even better to call select() on stdin, but I think this is usually
> good enough.

There is a new pgnuplot replacement just available from cvs; we are 
discussing the proper name (pgnuplot? gnuplot?) -- you should have got a 
copy of this email. With this new pgnuplot you will have no such problems.

> The second problem is that my programs spawns quite a few gnuplot instances,
> and they become hard to distinguish. On linux the wxt terminal supports a
> "title" option that allows to give the windows a title, e.g. set terminal wxt
> title "test". It would be great to have this in the windows terminal too.

This feature is available in the development version 4.3.x since May.
It seems it would be interesting if this gets ported into 4.2.

Well, what about a portable way
	set termoption title "xxx"
Is this feasible?

---
PM

names of gnuplot Win32 binaries

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

	Hi all,

we should solve an issue with naming Windows gnuplot binaries after the 
recent addition of the console-capable target.

Current situation:
- wgnuplot.exe:
  binary with a GUI for text input; piping into it does not work; piping
  "inside" (e.g. "plot '<preprocess data.dat'") does not work
- wgnuplot_pipes.exe:
  as above, piping "inside" works (drawback: executable is tighed to a 
  a console window)
- pgnuplot.exe: helper program used for piping commands into wgnuplot.exe, 
  i.e. redirect standard input
- gnuplot.exe: console mode binary compiled by Cygwin with X11 terminal 
  (requires running X-server - works OK with eXceed, cygwin's X11, etc.)

Recently, Michael Goffioul provided a patch to gnuplot sources what enables 
to compile Windows gnuplot binary with console text input and Windows 
terminal, see [ 1627936 ] Gnuplot Win32 in console mode 
http://sourceforge.net/tracker/?func=detail&atid=302055&aid=1627936&group_id=2055

The primary intention was to achieve better functionality of programs piping 
commands to gnuplot, like Octave, i.e. an efficient pgnuplot.exe 
replacement.

Thus, what should be the name of this executable?

Choice 1.
The executable will be called pgnuplot.exe -- it will replace the current 
pgnuplot.exe. No change is required for programs using gnuplot as a plotting 
engine.

Choice 2.
The executable is called gnuplot.exe. Then, every platform will have an
executable called gnuplot. However -- this will happen somewhen in future 
(when gnuplot 4.4 is released).
Drawbacks:
1. the name clashes with the name of the x11-capable executable 
   (user/program cannot determine which one gets called)
2. no piping program is set-up to use gnuplot.exe under Windows, and in 
   future there will be ambiguity whether to call pgnuplot.exe or 
   gnuplot.exe.
Thus, it would at least require to reimplement pgnuplot.c so that it 
redirects all characters from stdin into gnuplot.exe instead of WinMessages 
into wgnuplot.exe.


Therefore, in my option, the best way to ensure compatibility is to call 
the console-capable executable pgnuplot.exe. There will be no change needed 
for other programs using gnuplot, power users could use pgnuplot.exe for 
console mode with Windows terminal and others will not be confused.

I have proposed to rename the current binary of pgnuplot.c to 
pgnuplot_small.exe if somebody still needs to use it.


Opinions - votes?

---
Petr Mikulik

Gnuplot on Windows

[Reinier H. <re...@he...>]

Hi,

First of all: thanks for the great tool!

However, I have a few windows-specific issues integrating gnuplot with 
some software I'm writing. I use the python Gnuplot class to write 
commands to a gnuplot instance, which works very well.

When wgnuplot is closed manually, the pgnuplot program stays alive. It 
is therefore very hard to detect whether the gnuplot instance has been 
killed (in which case I want to respawn one). I've attached a patch to 
pgnuplot.c to fix this issue: it will check whether the wgnuplot process 
is still alive when it receives input. By writing an empty string from 
my python program twice (with a small delay in between) I can detect 
that wgnuplot is closed. Perhaps it would be even better to call 
select() on stdin, but I think this is usually good enough.

The second problem is that my programs spawns quite a few gnuplot 
instances, and they become hard to distinguish. On linux the wxt 
terminal supports a "title" option that allows to give the windows a 
title, e.g. set terminal wxt title "test". It would be great to have 
this in the windows terminal too. I think it shouldn't be too hard to 
do, but I don't exactly know where to start. Any pointers? I guess the 
first time the title is set is in src/win/winmain.c.

Regards,

-- 
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands

Tel: +31 6 10852639

Re: expanding allowed usage of word() command

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

On Sunday 09 November 2008, Ethan A Merritt wrote:
> How about:
>     plot for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "lines" ? $2 : NaN), \
>          for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "points" ? $2 : NaN)
> 

That should obviously have been

     plot for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "lines" ? $2 : NaN)  with lines, \
          for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "points" ? $2 : NaN) with points


-- 
Ethan A Merritt

Re: expanding allowed usage of word() command

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

On Sunday 09 November 2008, m sutton wrote:
> 
> > ----- Original Message -----
> > From: "Ethan A Merritt" <merritt@u.washington.edu>
> > To: gnu...@li...
> > Cc: "m sutton" <mw...@us...>
> > Subject: Re: expanding allowed usage of word() command
> > Date: Sun, 9 Nov 2008 11:56:03 -0700
> > 
> > You are asking for substitution of keywords, which is a somewhat different
> > process than the evaluation of string-valued functions.  There actually is
> > an existing  mechanism for macro-substitution, although it hasn't been
> > re-examined in the context of iteration clauses.
> > 
> > I think the command you are aiming for is
> >      set macros
> >      plot for [style in "lines impulses"]  foo with @style title style
> > 
> > That almost works. Note that the clause
> >         with @style title style
> > expands the same user variable 'style' using two different mechanisms.
> > 'title style' uses it as a string constant.
> > The macro @style is exanded to generate a string of lexical
> > tokens, which means that a keyword is an acceptable value.
> > 
> > The command as shown currently fails because the process of macro exansion
> > overwrites the original command line rather than preserving it.
> > That works fine for a one-shot use, but breaks when the command line is
> > re-scanned for iterative execution. That may be fixable.
> > 
> > Bottom line:
> > 
> > 1) It may be possible to do as you say, and add a special case to the
> > parser so that if it fails to find a keyword after "with" it falls
> > back to attempting evaluation of a string-valued function that returns
> > a keyword.  This strikes me as very hack-ish and ugly, but perhaps we
> > can come up with a less hackish or more general form.
> > 
> > 2) Alternatively, the macro expansion code can be updated to work
> > inside an iteration loop.
> > 
> > I view the macro-expansion mechanism in gnuplot as being kind of a
> > failed experiment.  It was an early attempt to work around the lack of
> > string variables.  Now that gnuplot supports both string variables and
> > string-valued functions, there is not much need for the macro mechanism.
> > But this may be a case where it really would make sense to use it.
> 
> 
> I think I over simplified my initial example.  I have been working to convert a program that plots model outputs using XGKS.  Gnuplot creates nicer looking plots and can generate PNG and other formats that can be put directly into documents and presentations.  I have been able to do most every thing so far.
> 
> The user specifies non-gnuplot commands that can result in either lines or points being plotted.  It was not until the "for" iteration was added to Gnuplot that the conversion to Gnuplot became feasible.  I currently have been hacking the plotting of points using empty string labels with points.  One down side is that zooming doesn't crop out labels.

Really?  It is certainly supposed to, and it does when I try it here.
Could you please file a separate bug report for that?
Maybe it's a terminal-specific problem.

 
> So the Gnuplot command I was striving for would look like this.
> 
>   n=3
>   list="lines lines points"
>   ls_list="3 6 99"
>   plot for [j=0:n] 'data.dat' index j with word(list,j+1) ls word(ls_list,j+1)


How about:
    plot for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "lines" ? $2 : NaN), \
         for [j=0:n] 'foo' index j using 1:(word(list,j+1) eq "points" ? $2 : NaN)



 
> I figured since word() gets evaluated for the "linestyle" portion it might get expanded for the "with" portion too.
> 
> I can understand the hesitation to allow something other than a keyword after a "with".  The "set style line" mechanism doesn't let you specify that lines or points be used.  So would it be less hackish to change lines styles so that 'set style line' can some how specify that lines or points be used.  Or should the word() function be allowed to dynamically substitute keywords?
> 
> Perhaps some combined thought power can arrive at a solution.
> 
> Mike Sutton
> 
> 
> 
> 



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

Re: expanding allowed usage of word() command

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li...
> Cc: "m sutton" <mw...@us...>
> Subject: Re: expanding allowed usage of word() command
> Date: Sun, 9 Nov 2008 11:56:03 -0700
> 
> You are asking for substitution of keywords, which is a somewhat different
> process than the evaluation of string-valued functions.  There actually is
> an existing  mechanism for macro-substitution, although it hasn't been
> re-examined in the context of iteration clauses.
> 
> I think the command you are aiming for is
>      set macros
>      plot for [style in "lines impulses"]  foo with @style title style
> 
> That almost works. Note that the clause
>         with @style title style
> expands the same user variable 'style' using two different mechanisms.
> 'title style' uses it as a string constant.
> The macro @style is exanded to generate a string of lexical
> tokens, which means that a keyword is an acceptable value.
> 
> The command as shown currently fails because the process of macro exansion
> overwrites the original command line rather than preserving it.
> That works fine for a one-shot use, but breaks when the command line is
> re-scanned for iterative execution. That may be fixable.
> 
> Bottom line:
> 
> 1) It may be possible to do as you say, and add a special case to the
> parser so that if it fails to find a keyword after "with" it falls
> back to attempting evaluation of a string-valued function that returns
> a keyword.  This strikes me as very hack-ish and ugly, but perhaps we
> can come up with a less hackish or more general form.
> 
> 2) Alternatively, the macro expansion code can be updated to work
> inside an iteration loop.
> 
> I view the macro-expansion mechanism in gnuplot as being kind of a
> failed experiment.  It was an early attempt to work around the lack of
> string variables.  Now that gnuplot supports both string variables and
> string-valued functions, there is not much need for the macro mechanism.
> But this may be a case where it really would make sense to use it.


I think I over simplified my initial example.  I have been working to convert a program that plots model outputs using XGKS.  Gnuplot creates nicer looking plots and can generate PNG and other formats that can be put directly into documents and presentations.  I have been able to do most every thing so far.

The user specifies non-gnuplot commands that can result in either lines or points being plotted.  It was not until the "for" iteration was added to Gnuplot that the conversion to Gnuplot became feasible.  I currently have been hacking the plotting of points using empty string labels with points.  One down side is that zooming doesn't crop out labels.

So the Gnuplot command I was striving for would look like this.

  n=3
  list="lines lines points"
  ls_list="3 6 99"
  plot for [j=0:n] 'data.dat' index j with word(list,j+1) ls word(ls_list,j+1)


I figured since word() gets evaluated for the "linestyle" portion it might get expanded for the "with" portion too.

I can understand the hesitation to allow something other than a keyword after a "with".  The "set style line" mechanism doesn't let you specify that lines or points be used.  So would it be less hackish to change lines styles so that 'set style line' can some how specify that lines or points be used.  Or should the word() function be allowed to dynamically substitute keywords?

Perhaps some combined thought power can arrive at a solution.

Mike Sutton




-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com