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

Re: Compilation instructions for Windows and Mac OS X

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

Thanks. That's very helpful.

Last question (because I am such a Mac OS X idiot):
do I need any non-standard (ie not typically pre-installed)
packages on a Mac to be able to compile anything, such
as the Apple developers kit, or does a regular Mac come
out of the box with the required compilers, linkers, libs?

Best,

		Ph.




On Wednesday 18 June 2008 10:36, you wrote:
> On Wednesday 18 June 2008 09:56:05 am Philipp K. Janert wrote:
> > Thanks to both of you. I am looking for installation
> > and compilation from source, for instance, if somebody
> > wants to build the development version.
> >
> > Let me try and summarize:
> >
> > 1)
> > You need either AquaTerm or X11 installed.
> > (Gnuplot will compile without them, but the only
> > interactive terminal you will be able to use will be
> > the dumb terminal. File terminals will work.)
> >
> > 1a)
> > X11 requires the Apple developers kit as a
> > separate install, unless you are running Leopard
> > or newer, on which it is already preinstalled.
> >
> > 1b)
> > AquaTerm can be downloaded as either src
> > or precompiled binary from sourceforge.
> >
> > 2)
> > Once either one of these is installed and is detected
> > during the configure-step, the build process is the
> > same as for all other Unix platforms.
> >
> > 3)
> > Finally, recent versions of OS X ship with a broken
> > version of the Gnu libreadline. These problems will
> > not be detected during the configure step, but will
> > lead to compile-time errors later. There are two
> > workarounds:
> > - use Gnuplot's own (minimalistic) libreadline:
> > 	/configure --with-readline=builtin
> > - or replace Apple's version of readline with the
> > 	version before building.
> >
> >
> > Is this correct?
>
> The aquaterm version on http://aquaterm.darwinports.com/
> is newer than the one on SourceForge.  I think (not sure) that you
> need the newer one if you are using Leopard.
>
> Development of aquaterm seems to have stagnated.
> Gnuplot actually supports aquaterm features (e.g. transparency)
> that never made it into the aquaterm version on SourceForge.
> I have not checked the Darwin port.
>
> Mac fans seem to like aqua, but in terms of gnuplot performance
> and features,  the x11 terminal works much better than aquaterm.
> If aquaterm development were to resume, that might change.
>
> > By the way, it would be cool if precompiled
> > binaries for OS X would be available on the
> > gnuplot site.
>
> I echo Mojca's concern:  I haven't had much luck with 3rd party
> pre-compiled OSX apps.  They tend to require incompatible versions
> of various font and graphics libraries.  It's probably possible to tweak
> system configurations to work around this, but at least from my
> perspective it's easier to build from source and link against whatever
> version of the libraries you already have installed.  Nevertheless,
> there are pre-compiled gnuplot binaries for both Darwin and Fink if
> you want to go that route.  Maybe also in the Octave package?
>
> 	Ethan
>
> > On Tuesday 17 June 2008 15:05, Mojca Miklavec wrote:
> > > On Tue, Jun 17, 2008 at 9:51 PM, Philipp K. Janert wrote:
> > > > For my book project, I would like to summarize
> > > > installation and compilation instructions for
> > > > gnuplot.
> > > >
> > > > I am struggling to get good descriptions together
> > > > for Win and OS X, not least because I don't have
> > > > access to either platform.
> > > >
> > > > While the description for Windows seems rather
> > > > straightforward, I have not been able to find
> > > > installation instructions for Mac OS X.
> > >
> > > It depends on whether you want gnuplot to run on the first place, or
> > > if you want to create a proper package out of it.
> > >
> > > To make it run at all by building from sources, the instructions are
> > > exactly the same as on linux (probably ./prepare, ./configure, make,
> > > make install). The only additional thing that needs to be installed in
> > > aquaterm (http://sourceforge.net/projects/aquaterm/), but I forgot how
> > > I installed it.
> > >
> > > An alternative straightforward way is to install gnuplot using fink
> > > (http://www.finkproject.org/). If one has fink installed, it's
> > > possible to say either
> > >     fink install gnuplot
> > > or
> > >     fink install gnuplot-nox
> > > which will install gnuplot without support for xterm, but there is
> > > aquaterm, which is in a way better (more native), but doesn't support
> > > all the functionality - mouse is "dead" (you can resize, but that will
> > > only scale, and you cannot zoom into the plot or retreive values from
> > > points).
> > >
> > > Still, I only use aquaterm as a terminal. For using xterm, one needs
> > > to install X11 first, at least on Tiger (on the new Leopard, X11 is
> > > already installed).
> > >
> > > To make a package for distributing it (something approximately
> > > equivalent to rpm on linux), one needs a more elaborate instructions,
> > > but I doubt that people would really want that.
> > >
> > > Mojca
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Compilation instructions for Windows and Mac OS X

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

On Wednesday 18 June 2008 09:56:05 am Philipp K. Janert wrote:
> 
> Thanks to both of you. I am looking for installation
> and compilation from source, for instance, if somebody
> wants to build the development version.
> 
> Let me try and summarize:
> 
> 1)
> You need either AquaTerm or X11 installed.
> (Gnuplot will compile without them, but the only
> interactive terminal you will be able to use will be
> the dumb terminal. File terminals will work.)
> 
> 1a)
> X11 requires the Apple developers kit as a
> separate install, unless you are running Leopard
> or newer, on which it is already preinstalled.
> 
> 1b)
> AquaTerm can be downloaded as either src
> or precompiled binary from sourceforge.
> 
> 2)
> Once either one of these is installed and is detected
> during the configure-step, the build process is the 
> same as for all other Unix platforms.
> 
> 3)
> Finally, recent versions of OS X ship with a broken
> version of the Gnu libreadline. These problems will
> not be detected during the configure step, but will
> lead to compile-time errors later. There are two
> workarounds:
> - use Gnuplot's own (minimalistic) libreadline:
> 	/configure --with-readline=builtin 
> - or replace Apple's version of readline with the 
> 	version before building.
> 
> 
> Is this correct?

The aquaterm version on http://aquaterm.darwinports.com/
is newer than the one on SourceForge.  I think (not sure) that you
need the newer one if you are using Leopard.

Development of aquaterm seems to have stagnated.
Gnuplot actually supports aquaterm features (e.g. transparency)
that never made it into the aquaterm version on SourceForge.
I have not checked the Darwin port.

Mac fans seem to like aqua, but in terms of gnuplot performance
and features,  the x11 terminal works much better than aquaterm.
If aquaterm development were to resume, that might change.
 
> By the way, it would be cool if precompiled
> binaries for OS X would be available on the
> gnuplot site.

I echo Mojca's concern:  I haven't had much luck with 3rd party
pre-compiled OSX apps.  They tend to require incompatible versions
of various font and graphics libraries.  It's probably possible to tweak
system configurations to work around this, but at least from my
perspective it's easier to build from source and link against whatever
version of the libraries you already have installed.  Nevertheless,
there are pre-compiled gnuplot binaries for both Darwin and Fink if
you want to go that route.  Maybe also in the Octave package?

	Ethan


 
> 
> On Tuesday 17 June 2008 15:05, Mojca Miklavec wrote:
> > On Tue, Jun 17, 2008 at 9:51 PM, Philipp K. Janert wrote:
> > > For my book project, I would like to summarize
> > > installation and compilation instructions for
> > > gnuplot.
> > >
> > > I am struggling to get good descriptions together
> > > for Win and OS X, not least because I don't have
> > > access to either platform.
> > >
> > > While the description for Windows seems rather
> > > straightforward, I have not been able to find
> > > installation instructions for Mac OS X.
> >
> > It depends on whether you want gnuplot to run on the first place, or
> > if you want to create a proper package out of it.
> >
> > To make it run at all by building from sources, the instructions are
> > exactly the same as on linux (probably ./prepare, ./configure, make,
> > make install). The only additional thing that needs to be installed in
> > aquaterm (http://sourceforge.net/projects/aquaterm/), but I forgot how
> > I installed it.
> >
> > An alternative straightforward way is to install gnuplot using fink
> > (http://www.finkproject.org/). If one has fink installed, it's
> > possible to say either
> >     fink install gnuplot
> > or
> >     fink install gnuplot-nox
> > which will install gnuplot without support for xterm, but there is
> > aquaterm, which is in a way better (more native), but doesn't support
> > all the functionality - mouse is "dead" (you can resize, but that will
> > only scale, and you cannot zoom into the plot or retreive values from
> > points).
> >
> > Still, I only use aquaterm as a terminal. For using xterm, one needs
> > to install X11 first, at least on Tiger (on the new Leopard, X11 is
> > already installed).
> >
> > To make a package for distributing it (something approximately
> > equivalent to rpm on linux), one needs a more elaborate instructions,
> > but I doubt that people would really want that.
> >
> > Mojca
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Compilation instructions for Windows and Mac OS X

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

On Wed, Jun 18, 2008 at 6:56 PM, Philipp K. Janert wrote:
>
> By the way, it would be cool if precompiled
> binaries for OS X would be available on the
> gnuplot site.

I agree.

They were for some time, but the version available there did not work
on my computer (dynamically linked libraries, incompatible on my
computer with the ones available on the site).

Mojca

Re: Compilation instructions for Windows and Mac OS X

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

Thanks to both of you. I am looking for installation
and compilation from source, for instance, if somebody
wants to build the development version.

Let me try and summarize:

1)
You need either AquaTerm or X11 installed.
(Gnuplot will compile without them, but the only
interactive terminal you will be able to use will be
the dumb terminal. File terminals will work.)

1a)
X11 requires the Apple developers kit as a
separate install, unless you are running Leopard
or newer, on which it is already preinstalled.

1b)
AquaTerm can be downloaded as either src
or precompiled binary from sourceforge.

2)
Once either one of these is installed and is detected
during the configure-step, the build process is the 
same as for all other Unix platforms.

3)
Finally, recent versions of OS X ship with a broken
version of the Gnu libreadline. These problems will
not be detected during the configure step, but will
lead to compile-time errors later. There are two
workarounds:
- use Gnuplot's own (minimalistic) libreadline:
	/configure --with-readline=builtin 
- or replace Apple's version of readline with the 
	version before building.


Is this correct?


By the way, it would be cool if precompiled
binaries for OS X would be available on the
gnuplot site.


On Tuesday 17 June 2008 15:05, Mojca Miklavec wrote:
> On Tue, Jun 17, 2008 at 9:51 PM, Philipp K. Janert wrote:
> > For my book project, I would like to summarize
> > installation and compilation instructions for
> > gnuplot.
> >
> > I am struggling to get good descriptions together
> > for Win and OS X, not least because I don't have
> > access to either platform.
> >
> > While the description for Windows seems rather
> > straightforward, I have not been able to find
> > installation instructions for Mac OS X.
>
> It depends on whether you want gnuplot to run on the first place, or
> if you want to create a proper package out of it.
>
> To make it run at all by building from sources, the instructions are
> exactly the same as on linux (probably ./prepare, ./configure, make,
> make install). The only additional thing that needs to be installed in
> aquaterm (http://sourceforge.net/projects/aquaterm/), but I forgot how
> I installed it.
>
> An alternative straightforward way is to install gnuplot using fink
> (http://www.finkproject.org/). If one has fink installed, it's
> possible to say either
>     fink install gnuplot
> or
>     fink install gnuplot-nox
> which will install gnuplot without support for xterm, but there is
> aquaterm, which is in a way better (more native), but doesn't support
> all the functionality - mouse is "dead" (you can resize, but that will
> only scale, and you cannot zoom into the plot or retreive values from
> points).
>
> Still, I only use aquaterm as a terminal. For using xterm, one needs
> to install X11 first, at least on Tiger (on the new Leopard, X11 is
> already installed).
>
> To make a package for distributing it (something approximately
> equivalent to rpm on linux), one needs a more elaborate instructions,
> but I doubt that people would really want that.
>
> Mojca

Re: Compilation instructions for Windows and Mac OS X

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

On Tue, Jun 17, 2008 at 9:51 PM, Philipp K. Janert wrote:
>
> For my book project, I would like to summarize
> installation and compilation instructions for
> gnuplot.
>
> I am struggling to get good descriptions together
> for Win and OS X, not least because I don't have
> access to either platform.
>
> While the description for Windows seems rather
> straightforward, I have not been able to find
> installation instructions for Mac OS X.

It depends on whether you want gnuplot to run on the first place, or
if you want to create a proper package out of it.

To make it run at all by building from sources, the instructions are
exactly the same as on linux (probably ./prepare, ./configure, make,
make install). The only additional thing that needs to be installed in
aquaterm (http://sourceforge.net/projects/aquaterm/), but I forgot how
I installed it.

An alternative straightforward way is to install gnuplot using fink
(http://www.finkproject.org/). If one has fink installed, it's
possible to say either
    fink install gnuplot
or
    fink install gnuplot-nox
which will install gnuplot without support for xterm, but there is
aquaterm, which is in a way better (more native), but doesn't support
all the functionality - mouse is "dead" (you can resize, but that will
only scale, and you cannot zoom into the plot or retreive values from
points).

Still, I only use aquaterm as a terminal. For using xterm, one needs
to install X11 first, at least on Tiger (on the new Leopard, X11 is
already installed).

To make a package for distributing it (something approximately
equivalent to rpm on linux), one needs a more elaborate instructions,
but I doubt that people would really want that.

Mojca

Re: Compilation instructions for Windows and Mac OS X

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

On Tuesday 17 June 2008 12:51:00 pm Philipp K. Janert wrote:
> 
> For my book project, I would like to summarize 
> installation and compilation instructions for 
> gnuplot.
> 
> While the description for Windows seems rather
> straightforward, I have not been able to find
> installation instructions for Mac OS X. 

Step 1) remove Apple's version of libreadline
Step 2) install the "real" libreadline
Step 3) same as any other unix machine:
	./configure
	make install

If you want x11 support (which I highly recommend)
then add 

Step 0) install Apple X11 developer's kit

> Can somebody point me to a good resource?

http://xanana.ucsc.edu/~wgscott/xtal/wiki/


So far the wxt terminal doesn't work under OSX.
Timothée is working on a revised terminal that is compatible
with OSX, but that isn't likely to be available in an official release
until version 4.4 or 5.0.

Compilation instructions for Windows and Mac OS X

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

For my book project, I would like to summarize 
installation and compilation instructions for 
gnuplot.

I am struggling to get good descriptions together
for Win and OS X, not least because I don't have
access to either platform.

While the description for Windows seems rather
straightforward, I have not been able to find
installation instructions for Mac OS X. 

Can somebody point me to a good resource?

Best,

		Ph.

Re: Hot key to toggle log scale is broken

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

> > Ethan, what do you propose for 'l' and 'L'?
> 
> I propose that 'l' toggles Y in a 2D plot. It toggles Z in a 3D plot.
> But if the mouse is inside the color bar it toggles cb instead.
> 
> 'L' always toggles the axis nearest to the current mouse position.
> (It currently does not work for the X and Y axes in general 3D view).

Ok, I agree. Let's commit the change you propose. 

Maybe you could let
	#if 1 /* until 4.2.3 */
		... switch log cb instead if "view map"
	#endif

---
PM

Re: Coverity scan of gnuplot code

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

On Friday 06 June 2008 05:45:06 am Brendan Burns wrote:
> 
> I will be setting up an account for myself as the primary contact for  
> Coverity.
> 
> I have two questions:
> 
> a) Does anyone else want a login?

Sure.  Give them sfeam as a user name, since that's my SourceForge ID.
 
> b) What version of gnuplot do we want Coverity to scan?  The latest  
> stable release?  The latest development release?  The source repository?

There is no such thing as "latest development release", but I could
run off an installable snapshot of the CVS source tree if that's what
they prefer to work from.

Thanks for taking the lead on this.

	Ethan

> Thanks!
> --brendan
> 
> 
> On May 20, 2008, at 5:07 PM, Ethan Merritt wrote:
> 
> > There's a press release from Coverity today:
> > 	http://lwn.net/Articles/283179/
> > saying that they are releasing
> > "2 years of analysis of more than 55 million lines of code on a  
> > recurring
> > basis from over 250 popular open source projects with Coverity  
> > PreventT, the
> > industry-leading static source code analysis solution."
> >
> > You may or may not recall that Coverity is a commercial outfit
> > that started life as the "Stanford Checker".  As I understand it, it  
> > uses
> > a highly-modified C compiler to examine the code and report flawed  
> > code
> > paths, failures of initialization, and so on.  Anyhow, the point is  
> > that
> > gnuplot is one of the 250 code bases that they analyzed.  The press  
> > release
> > says that
> > "Source code analysis from the Scan site is freely available
> > to qualified open source projects at: http://scan.coverity.com"
> >
> > A quick look at that site doesn't make it obvious what one actually
> > gets as part of the analysis, but I suppose it is worth pursuing.
> > That's a lot of high-powered bug-checking already done for us.
> > But I wonder what version of the code they checked?
> > The site does say that if you work with them to reduce the number
> > of bugs, they will re-run the analysis on a current source tree.
> >
> > Anyone interested in contacting them?
> >
> > -- 
> > Ethan A Merritt
> >
> Hey Folks,
> I contacted Ethan off list and told him I would be interested in  
> following up with Coverity.
> After a couple of weeks, I finally got the following response:
> 
> > We already did an analysis of gnuplot some time ago, and I can put  
> > that
> > online quite quickly as soon as the new server is ready, but we'll  
> > want
> > to give you an updated build as well.
> >
> > Send me a list of developers who want a login to the database, and  
> > I'll
> > get their accounts set up as soon as it's online. If there's a
> > particular person who wants to be the primary contact for us, please  
> > let
> > me know who that is as well.
> >
> > Thank You.

Re: Hot key to toggle log scale is broken

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

On Friday 06 June 2008 02:48:42 am you wrote:
> > > "set log z" invalidates only non-positive z-points, which the pm3d mode
> > > handles natively; "plot with image" cannot handle this.
> > 
> > I am not following you here.  What is it exactly that 'with image' cannot
> > handle?
> 
> 
> set table 'z3.dat'
> splot x
> unset table
> 
> set view map
> set log z
> splot 'z3.dat' with image

So?  You have created a data file with zrange [-10:10].
This is a problem for 'set log z'.  But it has absolutely nothing to
do with image plots as opposed to any other plot style.
I'm still failing to understand what you consider special about 
image plots.

> > > In "splot":
> > >      A. 'l' does "set log z+cb" for both 3D and "view map"
> > > 	 ... this is the current behaviour
> > 
> > This is quite wrong for general 3D plots.  It may be that
> > (PM3DSURFACE + splot_map) can be treated as a special case.
> 
> What's wrong? It works like that until now perfectly!

I think you mean "until now it works perfectly for one kind
of plot  that I use frequently".    

Here's a counter-example.
- Revert to CVS version of 01 June 2008 (before I made any 
  changes to the logscale hotkeys).
- Issue the following plot commands
  set view map
  splot 'silver.dat' using 1:2:3 with points pt 7 lt palette z

This looks like any normal 2D plot, except that it uses palette
coloring.  One expects the 'l' hotkey to toggle Y.  But it doesn't.
It toggles the colorbar instead.   I consider that to be wrong.

Another counter-example is the revised version of the 3D heat-map
in "heatmaps.dem".   The cb axis is _different_ from the z axis.
The previous 'l' hotkey toggled both, but this makes no sense.

> Repeating my summary:
> 
> In "plot": 
>      A. 'l' does "set log y" ... this is the current behaviour
>      B. 'l' does "set log cb" only if there are only
>         'with image' plot(s), otherwise "set log y"
> 
> In "splot": 
>      A. 'l' does "set log z+cb" for both 3D and "view map"
>          ... this is the current behaviour
>      B. 'l' does:
>         "set log cb" in "view map" if there is a palette plot,
>           otherwise "set log z"
>         "set log z+cb" in 3D
>      C. 'l' does "set log cb" in "view map" and "set log z+cb"
>          in 3D without "with image" and "set log cb" if there is some
>          "with image" at non-positive z-coordinates
> 
> 
> Ethan, what do you propose for 'l' and 'L'?

I propose that 'l' toggles Y in a 2D plot. It toggles Z in a 3D plot.
But if the mouse is inside the color bar it toggles cb instead.

'L' always toggles the axis nearest to the current mouse position.
(It currently does not work for the X and Y axes in general 3D view).

Re: Coverity scan of gnuplot code

[Brendan B. <bb...@cs...>]

Hey Folks,
I contacted Ethan off list and told him I would be interested in  
following up with Coverity.
After a couple of weeks, I finally got the following response:

> We already did an analysis of gnuplot some time ago, and I can put  
> that
> online quite quickly as soon as the new server is ready, but we'll  
> want
> to give you an updated build as well.
>
> Send me a list of developers who want a login to the database, and  
> I'll
> get their accounts set up as soon as it's online. If there's a
> particular person who wants to be the primary contact for us, please  
> let
> me know who that is as well.
>
> Thank You.


I will be setting up an account for myself as the primary contact for  
Coverity.

I have two questions:

a) Does anyone else want a login?

b) What version of gnuplot do we want Coverity to scan?  The latest  
stable release?  The latest development release?  The source repository?

Thanks!
--brendan


On May 20, 2008, at 5:07 PM, Ethan Merritt wrote:

> There's a press release from Coverity today:
> 	http://lwn.net/Articles/283179/
> saying that they are releasing
> "2 years of analysis of more than 55 million lines of code on a  
> recurring
> basis from over 250 popular open source projects with Coverity  
> PreventT, the
> industry-leading static source code analysis solution."
>
> You may or may not recall that Coverity is a commercial outfit
> that started life as the "Stanford Checker".  As I understand it, it  
> uses
> a highly-modified C compiler to examine the code and report flawed  
> code
> paths, failures of initialization, and so on.  Anyhow, the point is  
> that
> gnuplot is one of the 250 code bases that they analyzed.  The press  
> release
> says that
> "Source code analysis from the Scan site is freely available
> to qualified open source projects at: http://scan.coverity.com"
>
> A quick look at that site doesn't make it obvious what one actually
> gets as part of the analysis, but I suppose it is worth pursuing.
> That's a lot of high-powered bug-checking already done for us.
> But I wonder what version of the code they checked?
> The site does say that if you work with them to reduce the number
> of bugs, they will re-run the analysis on a current source tree.
>
> Anyone interested in contacting them?
>
> -- 
> Ethan A Merritt
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Hot key to toggle log scale is broken

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

> > "set log z" invalidates only non-positive z-points, which the pm3d mode
> > handles natively; "plot with image" cannot handle this.
> 
> I am not following you here.  What is it exactly that 'with image' cannot
> handle?


set table 'z3.dat'
splot x
unset table

set view map
set log z
splot 'z3.dat' with image

> > The z is usefuly "only" to invalidate points for non-positive z (make the
> > pm3d plot transparent).
> 
> OK, but do you need log scaling for that? 
> Can't you just test for a non-positive value of z?

The "invalidation" works automatically.


> > In "splot":
> >      A. 'l' does "set log z+cb" for both 3D and "view map"
> > 	 ... this is the current behaviour
> 
> This is quite wrong for general 3D plots.  It may be that
> (PM3DSURFACE + splot_map) can be treated as a special case.

What's wrong? It works like that until now perfectly!



Repeating my summary:

In "plot": 
     A. 'l' does "set log y" ... this is the current behaviour
     B. 'l' does "set log cb" only if there are only
        'with image' plot(s), otherwise "set log y"

Option B. would need a clever patch.


In "splot": 
     A. 'l' does "set log z+cb" for both 3D and "view map"
         ... this is the current behaviour
     B. 'l' does:
        "set log cb" in "view map" if there is a palette plot,
          otherwise "set log z"
        "set log z+cb" in 3D
     C. 'l' does "set log cb" in "view map" and "set log z+cb"
         in 3D without "with image" and "set log cb" if there is some
         "with image" at non-positive z-coordinates


Ethan, what do you propose for 'l' and 'L'?

---
PM

Re: Hot key to toggle log scale is broken

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

On Thursday 05 June 2008 11:45:47 am Petr Mikulik wrote:
>
> > This user expects the key to work on the cb mapping, regardless of the
> > current Z range.  Since we are viewing in projection, why should the
> > Z range matter?
>
> You typically "splot 'a.dat' u 1:2:3", thus z=cb.

Well no, I typically am more likely to be plotting heat maps.
So if I am using splot at all it is with 4D data.  For 3D heat maps I can use
either 'plot' or 'splot'.  Also please note the my typical plot mode for a
3D heat map is "with impulses".  
   http://skuld.bmsc.washington.edu/~merritt/gnuplot/lacI_variant3.png

> "set log z" invalidates only non-positive z-points, which the pm3d mode
> handles natively; "plot with image" cannot handle this.

I am not following you here.  What is it exactly that 'with image' cannot
handle?

> > Why should the hotkey act differently depending on whether you
> > drew the graph with "plot" or "splot"?  Since you can now use palette
> > and other coloring options in both 2D and 3D, this seem to me an
> > artificial distinction.
>
> The pm3d mode does not work in "plot".

True.  But almost all other plot modes work in both 2D and 3D.
Would it be OK to make "set view map;  plot ... with pm3d" a special
case for interpreting 'l'?

> On the other hand, "splot ... with image" + set log z reports errors.

Only if the z coordinate range is non-positive.  You can position the image
in any plane you want to.

> > Users who run a script written elsewhere may not even know whether the
> > plot they are looking at on the screen was created by 'plot' or 'splot'.
> > They shouldn't have to;  the hotkeys should behave consistently for both
> > cases.
>
> When 2D plots are unified ... then what to do with 3D splots and the 'l'
> hotkey? Will it flip both z+cb?

I think it should never flip both z and cb.  That's the point I've been trying 
to make :-)

> >  If 'l' tries to toggle log-scale on z it will fail, even though it
> > wouldn't have affected the appearance of the plot anyhow.  Better it
> > should only try to toggle cb.
>
> it fails only for "splot ... with image"

That's not true.  It has nothing to do with which plot style is in effect.

> > Would it be compatible with your previous usage to toggle cb only?
> > I imagine your old plots have z=cb, and in projection you cannot see z.
>
> The z is usefuly "only" to invalidate points for non-positive z (make the
> pm3d plot transparent).

OK, but do you need log scaling for that? 
Can't you just test for a non-positive value of z?

> In summary:
>
> In "plot":
>      A. 'l' does "set log y" ... this is the current behaviour
>      B. 'l' does "set log cb" only if there are only
> 	'with image' plot(s), otherwise "set log y"

I do not understand why you treat "with image" as a special case.
_All_ plot styles can now use palette color in 2D plots.
The problem is already there if you use:
   plot 'foo' using 1:2:3 with points lt palette z

> In "splot":
>      A. 'l' does "set log z+cb" for both 3D and "view map"
> 	 ... this is the current behaviour

This is quite wrong for general 3D plots.  It may be that
(PM3DSURFACE + splot_map) can be treated as a special case.

>      B. 'l' does:
> 	"set log cb" in "view map" if there is a palette plot,
> 	  otherwise "set log z"
> 	"set log z+cb" in 3D

NACK.  That was the original problem I am trying to fix.
There is no good reason that you should not toggle z by 
itself for a 3D palette plot.  What is wrong with: 
'l' in the colorbar toggles cb;  'l' anywhere else toggles z?
You can easily toggle both if you need to.

>      C. 'l' does "set log cb" in "view map" and "set log z+cb"
> 	 in 3D without "with image" and "set log cb" if there is some
> 	 "with image" at non-positive z-coordinates

I see nothing special about  "with image".
I think that whatever we choose to do should treat all plot modes equally.   
Possibly pm3d surfaces in map mode can be an exception, if that is
sufficient to proved backwards compatibility.  Is it?

Re: Hot key to toggle log scale is broken

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

> > The 'l' was one of the hotkeys firstly implemented; it switches the log
> > scale of what axis the user expects and uses most frequently.
> 
> "what the user expects" clearly must depend on the user :-)

The behaviour I vote for is there for ages, and thus I assume it is 
comfortable with everybody.

> This user expects the key to work on the cb mapping, regardless of the
> current Z range.  Since we are viewing in projection, why should the
> Z range matter?

You typically "splot 'a.dat' u 1:2:3", thus z=cb.

"set log z" invalidates only non-positive z-points, which the pm3d mode 
handles natively; "plot with image" cannot handle this.

> The traditional case assumed that z=cb. This is no longer true.

It is, see above.

> Why should the hotkey act differently depending on whether you
> drew the graph with "plot" or "splot"?  Since you can now use palette
> and other coloring options in both 2D and 3D, this seem to me an
> artificial distinction.

The pm3d mode does not work in "plot".

On the other hand, "splot ... with image" + set log z reports errors.

> Users who run a script written elsewhere may not even know whether the 
> plot they are looking at on the screen was created by 'plot' or 'splot'.  
> They shouldn't have to;  the hotkeys should behave consistently for both 
> cases.

When 2D plots are unified ... then what to do with 3D splots and the 'l' 
hotkey? Will it flip both z+cb? 

> There are at least 2 other problems:
> 
> 1) 2D plots can now use palette colors.  I don't think it is reasonable to
> have 'l' toggle y some times and z+cb at other times, depending on
> which coloring schemes are in use for the current plot.

right
but there is no clue for this, as nowadays there can be any mix of plots

> 2) 2D plots created either with 'plot' or 'splot' may have a positive
> range on cb, but not on z.

but not for 'plot'

>  If 'l' tries to toggle log-scale on z it will fail, even though it 
> wouldn't have affected the appearance of the plot anyhow.  Better it 
> should only try to toggle cb.

it fails only for "splot ... with image"

> Would it be compatible with your previous usage to toggle cb only?
> I imagine your old plots have z=cb, and in projection you cannot see z.

The z is usefuly "only" to invalidate points for non-positive z (make the 
pm3d plot transparent). 

> Alternatively,  suppose we change it so that 'l' always tries to
> toggle z+cb .  What should  happen if the z range goes negative? 
> Should it toggle cb only, and give an error message?  No error message?
> Not do anything?


> If 'l' toggles cb (with or without z) in 2D,  how is the user supposed to
> toggle y instead?

in "set view map", you would use 'L'


In summary:

In "plot": 
     A. 'l' does "set log y" ... this is the current behaviour
     B. 'l' does "set log cb" only if there are only
	'with image' plot(s), otherwise "set log y"

Option B. would need a clever patch.


In "splot": 
     A. 'l' does "set log z+cb" for both 3D and "view map"
	 ... this is the current behaviour
     B. 'l' does:
	"set log cb" in "view map" if there is a palette plot,
	  otherwise "set log z"
	"set log z+cb" in 3D
     C. 'l' does "set log cb" in "view map" and "set log z+cb"
	 in 3D without "with image" and "set log cb" if there is some
	 "with image" at non-positive z-coordinates


Opinions?

--- PM

Re: Hot key to toggle log scale is broken

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

On Thursday 05 June 2008 12:12:54 am Petr Mikulik wrote:
>
> The 'l' was one of the hotkeys firstly implemented; it switches the log
> scale of what axis the user expects and uses most frequently.

"what the user expects" clearly must depend on the user :-)
This user expects the key to work on the cb mapping, regardless of the
current Z range.  Since we are viewing in projection, why should the
Z range matter?

> It is documented in the help screen, hotkey "h":
>  l  `builtin-toggle-log` y logscale for plots, z logscale for splots
> You are right there should be
>  l  `builtin-toggle-log` y logscale for plots, z and cb for splots
> I've just fixed it.

> I would like to ask you to switch the 'l' behaviour to the traditional one.

The traditional case assumed that z=cb. This is no longer true.
We must decide how to extend, adapt, or change things to handle
the current capabilities of the program.

Why should the hotkey act differently depending on whether you
drew the graph with "plot" or "splot"?  Since you can now use palette
and other coloring options in both 2D and 3D, this seem to me an
artificial distinction.  Users who run a script written elsewhere may
not even know whether the plot they are looking at on the screen
was created by 'plot' or 'splot'.  They shouldn't have to;  the hotkeys
should behave consistently for both cases.
   
There are at least 2 other problems:

1) 2D plots can now use palette colors.  I don't think it is reasonable to
have 'l' toggle y some times and z+cb at other times, depending on
which coloring schemes are in use for the current plot.

2) 2D plots created either with 'plot' or 'splot' may have a positive
range on cb, but not on z.   If 'l' tries to toggle log-scale on z it will
fail, even though it wouldn't have affected the appearance of the
plot anyhow.  Better it should only try to toggle cb.




Would it be compatible with your previous usage to toggle cb only?
I imagine your old plots have z=cb, and in projection you cannot see z.

Alternatively,  suppose we change it so that 'l' always tries to
toggle z+cb .  What should  happen if the z range goes negative? 
Should it toggle cb only, and give an error message?  No error message?
Not do anything?

If 'l' toggles cb (with or without z) in 2D,  how is the user supposed to
toggle y instead?

Re: Hot key to toggle log scale is broken

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

> I have made a further adjustment to the 'L' hotkey, which I hope addresses
> your concerns.  Please use the new demo plot (last plot in 'heatmaps.dem')
> to see how this works in "set view map" mode:
>   If cursor is in color box, toggle log cb
>   If cursor is near x1 axis, toggle log x1
>   If cursor is near y1 axis, toggle log y1
>   If none of the above, toggle log z

For 'L', this is perfect -- this behaviour was designed like that and you 
have fixed it for independent switching of z and cb.

> The behavior of the 'l' hotkey in "set view map" mode is still a sore point.
> It now does what the documentation always said:  it toggles y1.
> But it used to toggle z+cb.  This was broken (see last demo in heatmaps.dem).
> It would be easy to make it toggle either z or cb instead, and change the
> documentation to match.  But I think it should not toggle both of them.
> You may disagree.
> 
> I am wondering why there is a need for both 'l' and 'L'.
> Is there a particular case where the distinction is necessary?

The 'l' was one of the hotkeys firstly implemented; it switches the log 
scale of what axis the user expects and uses most frequently.
  Thus, it should switch "log y" for "plot" command, and "log z + log cb" 
for "splot" command (in both 3D and map views). It was doing so until now. 
It is documented in the help screen, hotkey "h":
 l  `builtin-toggle-log` y logscale for plots, z logscale for splots
You are right there should be
 l  `builtin-toggle-log` y logscale for plots, z and cb for splots
I've just fixed it.

I would like to ask you to switch the 'l' behaviour to the traditional one.

Thanks, Petr

Re: Hot key to toggle log scale is broken

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

I have made a further adjustment to the 'L' hotkey, which I hope addresses
your concerns.  Please use the new demo plot (last plot in 'heatmaps.dem')
to see how this works in "set view map" mode:
  If cursor is in color box, toggle log cb
  If cursor is near x1 axis, toggle log x1
  If cursor is near y1 axis, toggle log y1
  If none of the above, toggle log z

The behavior of the 'l' hotkey in "set view map" mode is still a sore point.
It now does what the documentation always said:  it toggles y1.
But it used to toggle z+cb.  This was broken (see last demo in heatmaps.dem).
It would be easy to make it toggle either z or cb instead, and change the
documentation to match.  But I think it should not toggle both of them.
You may disagree.

I am wondering why there is a need for both 'l' and 'L'.
Is there a particular case where the distinction is necessary?

	Ethan

On Wednesday 04 June 2008 07:32, Ethan A Merritt wrote:
> On Tuesday 03 June 2008 23:49, Petr Mikulik wrote:
> > > > > I propose to restrict the effect of 'l' and 'L' to the X,Y axes in 2D
> > > > > and the Z axis in 3D.  We can add another hotkey, probably 'c', to 
> > > > > explicitly toggle log scaling on the colorbar in both 2D and 3D plots.
> > > > 
> > > > I don't think we need a separate hotkey.  'l' only acts on the axis the 
> > > > mouse is close to.  So it should act on the cb axis only if the colorbox 
> > > > is visible, and the mouse is inside it.
> > > 
> > > That "axis the mouse is close to" works only in 2D.
> > > In 3D the hotkey always toggles Z no matter where the mouse is.
> > > 
> > > But yes, we could change it to check where the colorbox is in both 2D and 3D.
> > 
> > In 2D, it works OK.
> > 
> > However, the 'l' hotkey is completely broken in 3D. It should (un)log both Z 
> > and CB axes, not only one of them.
> 
> No, it should not.  That is exactly what I am trying to fix.
> Long ago, Z and CB tracked the same quantity and it was reasonable to
> treat them jointly.  This is no longer true.
>  
> >The hotkey 'L' should be selective to Z 
> > or CB according to position of the mouse cursor -- it's ok now.
> 
> > Another broken example:
> > 
> > gnuplot> set pm3d map
> > gnuplot> splot x*x+y*y+1
> > gnuplot>          y range has y coord of -10; must be above 0 for log scale!
> > 
> > I.e., the 3D hotkey functionality for 'l' should work as before the patch, 
> > while the 'L' works correctly now.
> 
> The documentation has always said that 'l' toggles the Y axis in
> 2D plots.  This was untrue, because it toggled Z + CB instead in a 
> case such as the one above.  The new code does what the documentation
> has always said: toggles the Y axis. 2D and 3D plots now behave 
> uniformly.  The hotkeys toggle the cb scaling if and only if the mouse
> is near the color bar.
> 
> -- 
> Ethan A Merritt
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry       Regular Mail: Mailstop 357742
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: Hot key to toggle log scale is broken

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

On Tuesday 03 June 2008 23:49, Petr Mikulik wrote:
> > > > I propose to restrict the effect of 'l' and 'L' to the X,Y axes in 2D
> > > > and the Z axis in 3D.  We can add another hotkey, probably 'c', to 
> > > > explicitly toggle log scaling on the colorbar in both 2D and 3D plots.
> > > 
> > > I don't think we need a separate hotkey.  'l' only acts on the axis the 
> > > mouse is close to.  So it should act on the cb axis only if the colorbox 
> > > is visible, and the mouse is inside it.
> > 
> > That "axis the mouse is close to" works only in 2D.
> > In 3D the hotkey always toggles Z no matter where the mouse is.
> > 
> > But yes, we could change it to check where the colorbox is in both 2D and 3D.
> 
> In 2D, it works OK.
> 
> However, the 'l' hotkey is completely broken in 3D. It should (un)log both Z 
> and CB axes, not only one of them.

No, it should not.  That is exactly what I am trying to fix.
Long ago, Z and CB tracked the same quantity and it was reasonable to
treat them jointly.  This is no longer true.
 
>The hotkey 'L' should be selective to Z 
> or CB according to position of the mouse cursor -- it's ok now.

> Another broken example:
> 
> gnuplot> set pm3d map
> gnuplot> splot x*x+y*y+1
> gnuplot>          y range has y coord of -10; must be above 0 for log scale!
> 
> I.e., the 3D hotkey functionality for 'l' should work as before the patch, 
> while the 'L' works correctly now.

The documentation has always said that 'l' toggles the Y axis in
2D plots.  This was untrue, because it toggled Z + CB instead in a 
case such as the one above.  The new code does what the documentation
has always said: toggles the Y axis. 2D and 3D plots now behave 
uniformly.  The hotkeys toggle the cb scaling if and only if the mouse
is near the color bar.

-- 
Ethan A Merritt

Re: Hot key to toggle log scale is broken

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

> > > I propose to restrict the effect of 'l' and 'L' to the X,Y axes in 2D
> > > and the Z axis in 3D.  We can add another hotkey, probably 'c', to 
> > > explicitly toggle log scaling on the colorbar in both 2D and 3D plots.
> > 
> > I don't think we need a separate hotkey.  'l' only acts on the axis the 
> > mouse is close to.  So it should act on the cb axis only if the colorbox 
> > is visible, and the mouse is inside it.
> 
> That "axis the mouse is close to" works only in 2D.
> In 3D the hotkey always toggles Z no matter where the mouse is.
> 
> But yes, we could change it to check where the colorbox is in both 2D and 3D.

In 2D, it works OK.

However, the 'l' hotkey is completely broken in 3D. It should (un)log both Z 
and CB axes, not only one of them. The hotkey 'L' should be selective to Z 
or CB according to position of the mouse cursor -- it's ok now.

Another broken example:

gnuplot> set pm3d map
gnuplot> splot x*x+y*y+1
gnuplot>          y range has y coord of -10; must be above 0 for log scale!

I.e., the 3D hotkey functionality for 'l' should work as before the patch, 
while the 'L' works correctly now.

---
PM

Re: What plotting program?

[Juergen W. <wie...@fr...>]

Hi,

> In you opinion what plotting programe made this contour plot,
> http://solardat.uoregon.edu/download/misc/EugeneContour.pdf

You can get a cheap version of this with the label_contours.awk
script from the gnuplot home page.

> What do you think?

Personally, I like the following representation:

f(x,y) = sin(sqrt(x*x+y*y)) / sqrt(x*x+y*y)
Dcnt = 0.2
set samples 200
set isosamples 200
unset surface
set contour base
set cntrparam levels incremental -1, Dcnt, 1
set table "tmp.dat"
splot f(x,y)
unset table
unset contour

set size ratio -1
set cbrange [-1:1]
set palette defined (-1 'red', 0 'white', 1 'blue')
plot [-10:10] [-10:10] '++' using 1:2:(Dcnt*floor(f($1,$2)/Dcnt)) with 
image, \
     "tmp.dat" w l lt -1


Juergen

Re: What plotting program?

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

On Mon, Jun 2, 2008 at 6:00 AM, Daniel Farrell <boy...@gm...> wrote:
> Hello,
>
> In you opinion what plotting programe made this contour plot,
> http://solardat.uoregon.edu/download/misc/EugeneContour.pdf
>

This is done with DISLIN library (http://www.mps.mpg.de/dislin/).
The frontend could be anything...

Sincerely,

Dmitri.
--

What plotting program?

[Daniel F. <boy...@gm...>]

Hello,

In you opinion what plotting programe made this contour plot,
http://solardat.uoregon.edu/download/misc/EugeneContour.pdf

I know I could just contact the author (I think I will) but I wanted  
to point this out to the list because it looks really nice. I looks  
nicers than a gnuplot contour plot. I like the labels appearing along  
the contour lines. For certain types of contour plots (where the  
changes over the surface a smooth) I think this better represent the  
data as apposed to using colours and a colour map bar.

What do you think?

Regards,

Dan.

Re: Windows build of wgnuplot.exe

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

On Sunday 01 June 2008 21:15, Ethan A Merritt wrote:
> Is there a reason why the windows binary on SourceForge does not
> know about transparent fill styles?

Bleah. Never mind. 
The copy on SourceForge is of course Version 4.2 not the CVS version.

The commands work fine in A. Kakuto's recent CVS build, although I
see that transparency itself has not been implemented for win.trm.
Is anyone willing to have a look at that?

	Ethan

-- 
Ethan A Merritt

Windows build of wgnuplot.exe

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

Is there a reason why the windows binary on SourceForge does not
know about transparent fill styles?

E.g.
gnuplot>  set style fill transparent solid 0.5
                          ^
                         ';' expected

This code was added back in November 2006, and even if the windows
terminal itself doesn't support transparency (does it?) it should
still be available for PNG, SVG, and other terminals.  If the
object file for misc.c hasn't been rebuilt since 2006 I am surprised
the program works at all!

-- 
Ethan A Merritt

Re: Hot key to toggle log scale is broken

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

On Sunday 01 June 2008 15:05, Hans-Bernhard Bröker wrote:
> 
> > I propose to restrict the effect of 'l' and 'L' to the X,Y axes in 2D
> > and the Z axis in 3D.  We can add another hotkey, probably 'c', to 
> > explicitly toggle log scaling on the colorbar in both 2D and 3D plots.
> 
> I don't think we need a separate hotkey.  'l' only acts on the axis the 
> mouse is close to.  So it should act on the cb axis only if the colorbox 
> is visible, and the mouse is inside it.

That "axis the mouse is close to" works only in 2D.
In 3D the hotkey always toggles Z no matter where the mouse is.

But yes, we could change it to check where the colorbox is in both 2D and 3D.

-- 
Ethan A Merritt