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

Re: gnuplot, wxWidgets and distributions

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

On Sunday 24 September 2006 09:57 am, Timoth=C3=A9e Lecomte wrote:

> I have discussed a little bit about Fedora developpers as I was thinking
> about the way gnuplot 4.2 and the wxWidgets terminal would be=20
> distributed. It seems to raise quite a bit of questioning.

I don't have any real solutions to this issue.  But I can point out that
Redhat has been shipping a minimally-configured and stripped down gnuplot
package for a long time.  The current Redhat gnuplot rpm does not even=20
link against libgd, thus they fail to include support for any of the=20
gd-based terminals.=20

> I won't talk about other distributions, but the situation is probably=20
> quite close to Fedora's.

Not really.  For one thing, the move is in general towards distributing
as a single DVD image rather than multiple CD images.  And at least in
the case of Mandriva, which is where I have the most familiarity, there
is no such distinction between 'core' and 'extra'.
=20
> The other alternatives are:
> - static linking with wxWidgets. No, it's not possible. Fedora forbids it.
> - write a plugin interface to gnuplot, so that the wxWidgets is=20
>   dynamically loadable and can be distributed separately (in Extras).
>=20
> What do you think about that ?

You left out the most obvious option, which is in fact the one you have
to use today to get a decent version of gnuplot going under either RHEL
or Fedora:

    rpmbuild --rebuild gd-2.0.33-2.src.rpm
    rpmbuild --rebuild gnuplot-4.0.0-11.src.rpm

I find that in general the default packages and configuration on
both RHEL and Fedora are not ideal for scientific lab use.  Both
Suse and Mandriva are a better match out-of-the-box.  This comment
is not intended as a slam against Redhat;  they have identified a
target user community and designed their offerings accordingly.
But labs like mine are apparently not in their target community,
and the choices they make are often contrary to our needs.

The truth is that we don't really know who exactly is the core user
community for gnuplot. But at least among the developers it seems that
scientific lab use predominates, and in my experience this means that
=46edora core may not be as common as other linux distros.

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

gnuplot, wxWidgets and distributions

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

Dear all,

I have discussed a little bit about Fedora developpers as I was thinking=20
about the way gnuplot 4.2 and the wxWidgets terminal would be=20
distributed. It seems to raise quite a bit of questioning.

I won't talk about other distributions, but the situation is probably=20
quite close to Fedora's.

Currently, gnuplot is distributed in Fedora "Core", it means that it is=20
the very first set of CDs, and it is in the most controlled part of the=20
distribution. It is a nice situation, since packages in the "Core" are=20
often judged of high quality and accessible to the largest set of users=20
(most Install parties do their stuff with the "Core" CDs only).

However wxWidgets is not distributed in the "Core", but in "Extras". The=20
packages in this repository are said to receive a little less attention=20
(Extras is _really_ much bigger than Core), and they are often not=20
installed by default.

There is little chance for wxWidgets to move from Extras to Core, given=20
that few applications use it (audacity, xmule). The consequence is that=20
gnuplot is likely to be distributed without the wxWidgets terminal, or=20
to go from Core to Extras. Either situation is not really good, given=20
that being in Core is a nice privilege that we may not want to lose, and=20
that the wxWidgets adds a valuable improvement to gnuplot.

The other alternatives are:
- static linking with wxWidgets. No, it's not possible. Fedora forbids it.
- write a plugin interface to gnuplot, so that the wxWidgets is=20
dynamically loadable and can be distributed separately (in Extras). It's=20
far from being difficult (and probably a nice project for the future - I=20
am thinking of our problem about linking to X11 for the 'raise console'=20
key bindings), but it does not really solve the problem, since many=20
users will never know about the new terminal.
- rewrite the terminal in GTK+2, which is included in the core of=20
virtually all distributions. GTK+2 is C, not C++ (I'm used to C++ now=20
!), and not as well supported on non-X11 platforms as wxWidgets is.=20
Fortunately, more than half of the code of the wxWidgets terminal is=20
already wxWidgets-agnostic (that's the cairo&pango part). The logic for=20
the rest can probably be kept, so it's somehow like a port.=20
Unfortunately this is still a lot of work to do. I do not know either if=20
we would want to have both a wxWidgets and a GTK terminal at the same tim=
e.

What do you think about that ?

Best regards,

Timoth=C3=A9e

Re: gnuplot numerical errors on Intel MacBook

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>=20
>>Hmm, that would suggest to me a problem with the exterior gamma
>>function.  (We should get rid of these warnings though as a first
>>step.) =20
>=20
>=20
> No.  Those warnings are harmless --- they occur for basically all
> functions tested by ./configure that turn out to be GCC built-in functi=
ons.
>=20
> The most likely reason for this problem is signgam, the extra variable=20
> used by gamma() to report the sign of its result (since the main result=
=20
> is the logarithmized gamma value, it can't carry the sign).  This is=20
> quite notorious for being absent; or present but not declared in any he=
ader.
>=20
> In case of doubt, you may have to use autoconf's mechanisms for forcing
> the results of the gamma() and lgamma() tests to "no" (or edit config.h=
=20
> before running 'make').

Then if C runs the 'prob.dem' demo, it should be inverted.  (Is that what=
 you are seeing for that demo?)

Dan

Re: gnuplot numerical errors on Intel MacBook

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

Daniel J Sebald wrote:

> Hmm, that would suggest to me a problem with the exterior gamma
> function.  (We should get rid of these warnings though as a first
> step.)  

No.  Those warnings are harmless --- they occur for basically all
functions tested by ./configure that turn out to be GCC built-in functions.

The most likely reason for this problem is signgam, the extra variable 
used by gamma() to report the sign of its result (since the main result 
is the logarithmized gamma value, it can't carry the sign).  This is 
quite notorious for being absent; or present but not declared in any header.

In case of doubt, you may have to use autoconf's mechanisms for forcing
the results of the gamma() and lgamma() tests to "no" (or edit config.h 
before running 'make').

Re: New German gnuplot-book available

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

> I'm not sure, whether this is the the right address for
> announcements like these. Unfortuanetly the projects
> homepage gives no further information about who is actually
> taking care of keeping it up to date.
> It was not my intention to bother anyone, so please accept
> my excuses if this is not the right way of communicating.
>
> I recently finished my work on a handbook with in
> introduction to gnuplot in German Language. It is available
> exclusively or members and students of Greman Universities
> and Colleges of Higher Education at a very low price (~ 5
> Euro). More information is provided at
> http://www.rrzn.uni-hannover.de/buch.html?&no_cache=1&titel=gnuplot
>
> I would appreciate, if a link or a short remark would be
> added to the projects homepage.

Added to
 	http://gnuplot.sourceforge.net/help.html
... to be mirrored by gnuplot.info soon.

---
PM

Re: gnuplot numerical errors on Intel MacBook

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

CM wrote:

>> I get those too in the configuration file.  (Never noticed.)  However,
>> everything seems fine to me.  I see similar warnings for several 
>> functions
>> like sin() and efc().
>>
>> Are those routines working for you?  "plot sin(x)", or try the '
>> bivariat.dem' demo...
> 
> 
> 
> Yes, sin and bivariat.dem both work correctly.

Hmm, that would suggest to me a problem with the exterior gamma function.  (We should get rid of these warnings though as a first step.)  Hans?  Ethan?  Any ideas?

Dan

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

On 9/23/06, Daniel J Sebald <dan...@ie...> wrote:
>
> CM wrote:
> > The config output indicates that both "gamma" and "lgamma" are found,
> but
> > the log says this:
> >
> > configure:8466: checking for gamma
> > configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include
> conftest.c
> >
> >> &5
> >
> > conftest.c:94: warning: conflicting types for built-in function 'gamma'
> > configure:8528: $? = 0
> > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8538: $? = 0
> > configure:8545: test -s conftest
> > configure:8548: $? = 0
> > configure:8562: result: yes
> > configure:8466: checking for lgamma
> > configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include
> conftest.c
> >
> >> &5
> >
> > conftest.c:95: warning: conflicting types for built-in function 'lgamma'
> > configure:8528: $? = 0
> > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8538: $? = 0
> > configure:8545: test -s conftest
> > configure:8548: $? = 0
> > configure:8562: result: yes
> >
> > In other words, it finds them, but gets some interesting warnings.
>
> I get those too in the configuration file.  (Never noticed.)  However,
> everything seems fine to me.  I see similar warnings for several functions
> like sin() and efc().
>
> Are those routines working for you?  "plot sin(x)", or try the '
> bivariat.dem' demo...


Yes, sin and bivariat.dem both work correctly.

Dan
>



-- 
:(){ :|:&};:

Re: gnuplot numerical errors on Intel MacBook

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

CM wrote:
> The config output indicates that both "gamma" and "lgamma" are found, but
> the log says this:
> 
> configure:8466: checking for gamma
> configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include  conftest.c
> 
>> &5
> 
> conftest.c:94: warning: conflicting types for built-in function 'gamma'
> configure:8528: $? = 0
> configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> configure:8538: $? = 0
> configure:8545: test -s conftest
> configure:8548: $? = 0
> configure:8562: result: yes
> configure:8466: checking for lgamma
> configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include  conftest.c
> 
>> &5
> 
> conftest.c:95: warning: conflicting types for built-in function 'lgamma'
> configure:8528: $? = 0
> configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> configure:8538: $? = 0
> configure:8545: test -s conftest
> configure:8548: $? = 0
> configure:8562: result: yes
> 
> In other words, it finds them, but gets some interesting warnings.

I get those too in the configuration file.  (Never noticed.)  However, everything seems fine to me.  I see similar warnings for several functions like sin() and efc().

Are those routines working for you?  "plot sin(x)", or try the 'bivariat.dem' demo...

Dan

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

On 9/23/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
>
> On Saturday 23 September 2006 07:46 pm, CM wrote:
> > I'm sorry.  I should have provided more information.
> >
> > Version of GNUPlot:
> >
> > 4.0 (from fink on Tiger, MacBook Pro)
> > 4.1 (from cvs today, same platform)
> >
> > gamma(x) is returning all negative values, and very, very large ones at
> > that.
>
> Could you please check for compiler warnings or errors during the
> build.  In particular, look to see if any variant of the
> gamma function is mentioned in connection with a message on the
> order of "implicit declaration of built-in function 'lgamma'".
> But please report all warnings or errors.



Here is all of the stderr output (minus the last obvious stuff) that might
be relevant, but appears not to be anyway:

set.c: In function 'set_mouse':
set.c:2309: warning: pointer targets in passing argument 2 of 'map_position'
differ in signedness
set.c:2309: warning: pointer targets in passing argument 3 of 'map_position'
differ in signedness
/usr/bin/ld: warning multiple definitions of symbol _init_color
color.o definition of _init_color in section (__TEXT,__text)
/sw/lib/libncurses.dylib(lib_color.o) definition of _init_color
/usr/bin/ld: warning multiple definitions of symbol _set_term
term.o definition of _set_term in section (__TEXT,__text)
/sw/lib/libncurses.dylib(lib_set_term.o) definition of _set_term



Also please look in the file config.h created while preparing
> the cvs distribution and tell us whether HAVE_LGAMMA is defined or
> commented out.


HAVE_LGAMMA is defined to be 1, not commented out.

The config output indicates that both "gamma" and "lgamma" are found, but
the log says this:

configure:8466: checking for gamma
configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include  conftest.c
>&5
conftest.c:94: warning: conflicting types for built-in function 'gamma'
configure:8528: $? = 0
configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
configure:8538: $? = 0
configure:8545: test -s conftest
configure:8548: $? = 0
configure:8562: result: yes
configure:8466: checking for lgamma
configure:8522: gcc -o conftest -g -O2   -I/usr/X11R6/include  conftest.c
>&5
conftest.c:95: warning: conflicting types for built-in function 'lgamma'
configure:8528: $? = 0
configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
configure:8538: $? = 0
configure:8545: test -s conftest
configure:8548: $? = 0
configure:8562: result: yes

In other words, it finds them, but gets some interesting warnings.

- C

Re: gnuplot numerical errors on Intel MacBook

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

On Saturday 23 September 2006 07:46 pm, CM wrote:
> I'm sorry.  I should have provided more information.
>=20
> Version of GNUPlot:
>=20
> 4.0 (from fink on Tiger, MacBook Pro)
> 4.1 (from cvs today, same platform)
>=20
> gamma(x) is returning all negative values, and very, very large ones at
> that.

Could you please check for compiler warnings or errors during the
build.  In particular, look to see if any variant of the
gamma function is mentioned in connection with a message on the
order of "implicit declaration of built-in function =E2=80=98lgamma=E2=80=
=99".
But please report all warnings or errors.

Also please look in the file config.h created while preparing
the cvs distribution and tell us whether HAVE_LGAMMA is defined or
commented out.



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

Re: gnuplot numerical errors on Intel MacBook

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

CM wrote:
> I'm sorry.  I should have provided more information.
> 
> Version of GNUPlot:
> 
> 4.0 (from fink on Tiger, MacBook Pro)
> 4.1 (from cvs today, same platform)
> 
> gamma(x) is returning all negative values, and very, very large ones at
> that.  I have included two images, one with the auto-scaling that gnuplot
> usually gives, another with [0:5] [0:100].  As you can see, the results are
> quite simply wrong.

No doubt.


> These are compiled for X11, and the behavior is independent of the terminal
> setting.

When you do ./configure, are you getting this?

checking for gamma... yes
checking for lgamma... yes

It could be that you don't have the math library where the gamma function resides and gnuplot is falling back on it's own internal versions, for which the #defines look slightly convoluted.


> Thanks!  Once again, sorry for the brief email I sent previously; as I was
> writing it, I discovered that my 3-year-old had just finished very quietly
> cutting her own hair with some nail scissors, and I had to run really fast.
> It's amazing how fast she can be when she's doing something she is *not*
> asked to do....

Ah, but did you specifically ask her to not do that.  You see, there's a big difference there.

Dan

Re: gnuplot numerical errors on Intel MacBook

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

CM wrote:
> Has anyone seen numerical errors on the MacBook line of computers?  I have
> tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package),
> and in each case the result of
> 
> plot gamma(x)
> 
> is very, very wrong.  Has anyone else seen this?  I searched the archives
> for this list and didn't see anything relevant.
> 
> - C

As Hans said, please give us some results we can verify against.  However, I think that the gamma function is working properly, as I had just spruced up the 'prob.dem' file.  Please have a look at that file.  I added some printouts of the gamma function and the log gamma function, and spent a lot of time making sure I got adequate sampling in those tricky subregions to the left of the plot.

I will send you some screen captures separately.

Dan

Re: gnuplot numerical errors on Intel MacBook

[Joe K. <jko...@co...>]

on 9/23/06 5:56 PM, Dmitri A. Sergatskov at das...@gm... wrote:

> On 9/23/06, CM <mon...@gm...> wrote:
>> Has anyone seen numerical errors on the MacBook line of computers?  I have
>> tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package),
>> and in each case the result of
>> 
>> plot gamma(x)
>> 
>> is very, very wrong.  Has anyone else seen this?  I searched the archives
>> for this list and didn't see anything relevant.
> 
> Does it look better if you do:
> 
> gnuplot> set samples 100000
> gnuplot> plot [-2.5:6][-100:100] gamma(x)
> 
> ?
> 
>> 
>> - C
>> 
> 
> Sincerely,
> 
> Dmitri.
> --
> 
For what it is worth, my gnuplot-4.1 compiled from CVS March 17, 2006 had
severe problems with pm3d colors. My latest CVS, Sept. 17, 2006 gives
correct pm3d colors and compares well with gnuplot-4.0. Is it a version
issue? Did you compile your gnuplot-4.1 from the (now stale) March snapshot?

Joe

Re: gnuplot numerical errors on Intel MacBook

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

On 9/23/06, CM <mon...@gm...> wrote:
> Has anyone seen numerical errors on the MacBook line of computers?  I have
> tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package),
> and in each case the result of
>
> plot gamma(x)
>
> is very, very wrong.  Has anyone else seen this?  I searched the archives
> for this list and didn't see anything relevant.

Does it look better if you do:

gnuplot> set samples 100000
gnuplot> plot [-2.5:6][-100:100] gamma(x)

?

>
> - C
>

Sincerely,

Dmitri.
--

Re: gnuplot numerical errors on Intel MacBook

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

CM wrote:
> Has anyone seen numerical errors on the MacBook line of computers?  I 
> have tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac 
> package), 

Compiled for which target / terminal drivers?  Aqua, X11, or wx?  All 
three of them?

 > and in each case the result of
> 
> plot gamma(x)
> 
> is very, very wrong.  Has anyone else seen this?

That's quite completely impossible to answer --- how can we know if we 
saw this, if you don't tell tell us what it is we're supposed to see?

gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

Has anyone seen numerical errors on the MacBook line of computers?  I have
tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package),
and in each case the result of

plot gamma(x)

is very, very wrong.  Has anyone else seen this?  I searched the archives
for this list and didn't see anything relevant.

- C

Re: Missing colorbox with pm3d points plot

[Joe K. <jko...@co...>]

on 9/22/06 10:40 PM, Ethan A Merritt at merritt@u.washington.edu wrote:

> On Thursday 21 September 2006 02:12 pm, Hans-Bernhard Br=F6ker wrote:
>> Joe Koski wrote:
>>> I asked about this problem on the gnuplot help list and didn't get a
>>> response after a day or two, so I am assuming that it is a bug, not a n=
ew
>>> feature. Attached in .tar.gz format is a script and a short data file t=
hat
>>> reproduce the bug on my machine.
>>=20
>> The example is a bit too complicated.  It can be boiled down to just one
>> command:
>>=20
>>     splot x+y with points palette
>>=20
>> The outermost reason why this plot doesn't get a colorbox is that the
>> comparison against TC_DEFAULT made by set_plot_with_palette is
>> triggered.  The plot in question has a pm3d_color.type value of 6, as if
>> the user had specified 'palette z'.  This might be an inadvertant side
>> effect of the changes that allowed 'with points palette cb -45' etc.
>=20
> I think that is correct.
> As best as I can make out, the error arises from a false assumption that =
was
> waiting to bite us for a long time.  I don't know exactly which change
> caused it to emerge.  The offending lines are these, from pm3d.c
>=20
> 1001       if (this_3dplot->lp_properties.use_palette) {
> 1002           if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAU=
LT)
> 1003               /* can this really happen? for which syntax? */
> 1004               want_palette_but_not_colorbox =3D TRUE;
> 1005               /* don't return yet -- decide later whether showing co=
lor
> box is desirable */
>=20
> The implicit assumption is that no color spec other than TC_DEFAULT uses
> the palette. This has been incorrect for a very long time, but was not a
> problem until you could explicitly override the default color-by-z style
> of splot surfaces using another palette option.
>=20
> The fix is
>=20
> --- gnuplot/src/pm3d.c 2006-06-15 08:42:33.000000000 -0700
> +++ gnuplot-cvs/src/pm3d.c 2006-09-22 21:25:10.000000000 -0700
> @@ -999,8 +999,8 @@
> return;
>  #endif
>    if (this_3dplot->lp_properties.use_palette) {
> -  if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAULT)
> -      /* can this really happen? for which syntax? */
> +         int type =3D this_3dplot->lp_properties.pm3d_color.type;
> +  if (type =3D=3D TC_LT || type =3D=3D TC_LINESTYLE || type =3D=3D TC_RGB)
>    want_palette_but_not_colorbox =3D TRUE;
>    /* don't return yet -- decide later whether showing color box is desir=
able
> */
> else
>=20
Ethan,

I applied the patch to pm3d.c and did make, make install, and it does solve
the problem for me. Thanks.

Joe

Re: Missing colorbox with pm3d points plot

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

On Thursday 21 September 2006 02:12 pm, Hans-Bernhard Br=F6ker wrote:
> Joe Koski wrote:
> > I asked about this problem on the gnuplot help list and didn't get a
> > response after a day or two, so I am assuming that it is a bug, not a n=
ew
> > feature. Attached in .tar.gz format is a script and a short data file t=
hat
> > reproduce the bug on my machine.
>=20
> The example is a bit too complicated.  It can be boiled down to just one=
=20
> command:
>=20
>     splot x+y with points palette
>=20
> The outermost reason why this plot doesn't get a colorbox is that the=20
> comparison against TC_DEFAULT made by set_plot_with_palette is=20
> triggered.  The plot in question has a pm3d_color.type value of 6, as if=
=20
> the user had specified 'palette z'.  This might be an inadvertant side=20
> effect of the changes that allowed 'with points palette cb -45' etc.

I think that is correct.
As best as I can make out, the error arises from a false assumption that was
waiting to bite us for a long time.  I don't know exactly which change
caused it to emerge.  The offending lines are these, from pm3d.c

1001       if (this_3dplot->lp_properties.use_palette) {
1002           if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAU=
LT)
1003               /* can this really happen? for which syntax? */
1004               want_palette_but_not_colorbox =3D TRUE;
1005               /* don't return yet -- decide later whether showing colo=
r box is desirable */

The implicit assumption is that no color spec other than TC_DEFAULT uses
the palette. This has been incorrect for a very long time, but was not a
problem until you could explicitly override the default color-by-z style
of splot surfaces using another palette option. =20

The fix is

=2D-- gnuplot/src/pm3d.c	2006-06-15 08:42:33.000000000 -0700
+++ gnuplot-cvs/src/pm3d.c	2006-09-22 21:25:10.000000000 -0700
@@ -999,8 +999,8 @@
 		return;
 #endif
 	    if (this_3dplot->lp_properties.use_palette) {
=2D		if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAULT)
=2D		    /* can this really happen? for which syntax? */
+	        int type =3D this_3dplot->lp_properties.pm3d_color.type;
+		if (type =3D=3D TC_LT || type =3D=3D TC_LINESTYLE || type =3D=3D TC_RGB)
 		    want_palette_but_not_colorbox =3D TRUE;
 		    /* don't return yet -- decide later whether showing color box is des=
irable */
 		else


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

Re: Missing colorbox with pm3d points plot

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

Joe Koski wrote:
> I asked about this problem on the gnuplot help list and didn't get a
> response after a day or two, so I am assuming that it is a bug, not a new
> feature. Attached in .tar.gz format is a script and a short data file that
> reproduce the bug on my machine.

The example is a bit too complicated.  It can be boiled down to just one 
command:

    splot x+y with points palette

The outermost reason why this plot doesn't get a colorbox is that the 
comparison against TC_DEFAULT made by set_plot_with_palette is 
triggered.  The plot in question has a pm3d_color.type value of 6, as if 
the user had specified 'palette z'.  This might be an inadvertant side 
effect of the changes that allowed 'with points palette cb -45' etc.

Missing colorbox with pm3d points plot

[Joe K. <jko...@co...>]

I asked about this problem on the gnuplot help list and didn't get a
response after a day or two, so I am assuming that it is a bug, not a new
feature. Attached in .tar.gz format is a script and a short data file that
reproduce the bug on my machine.

I am using the Sept. 17 CVS of gnuplot-4.1, compiled on a Mac G5 with OS X
10.4.7 and Xcode-2.4 developer tools. I upgraded automake-1.6.3 to 1.9.6 in
order to get ./prepare to work. This has been reported via the gnuplot help
list. I am using AquaTerm-1.0.1 for output. The build completed and
installed without problems.

When I run the script via gnuplot < gnutest.inp, the colorbox to the right
of the plot frame does not appear. This script has worked with an earlier
version of gnuplot-4.1 built back in March of this year.

Is this a bug? Thanks.

Joe Koski

New German gnuplot-book available

[Lars H. <la...@ho...>]

Hello,
I'm not sure, whether this is the the right address for 
announcements like these. Unfortuanetly the projects 
homepage gives no further information about who is actually 
taking care of keeping it up to date.
It was not my intention to bother anyone, so please accept 
my excuses if this is not the right way of communicating.

I recently finished my work on a handbook with in 
introduction to gnuplot in German Language. It is available 
exclusively or members and students of Greman Universities 
and Colleges of Higher Education at a very low price (~ 5 
Euro). More information is provided at 
http://www.rrzn.uni-hannover.de/buch.html?&no_cache=1&titel=gnuplot

I would appreciate, if a link or a short remark would be 
added to the projects homepage.

Thanks in advance!
Lars Hoegen 

Re: Resize behaviour for the wxt terminal

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

Timoth=E9e Lecomte wrote:
>>> I just committed a small peace of code to fill in gray the empty spac=
e
>>> left aside or below a plot when you resize the wxt terminal window
>>>      =20
>> That's the reason why the wxt terminals can not longer be compiled in =
on
>> SUSE 10.0?
>>
>> checking for wx-config... /usr/bin/wx-config
>> checking for pkg-config... /usr/bin/pkg-config
>> checking pkg-config is at least version 0.9.0... yes
>> checking for CAIRO... yes
>> checking for PANGO... configure: WARNING: Pango can't be found. The
>> wxWidgets terminal will not be compiled.
>> checking for PANGOCAIRO... configure: WARNING: Cairo rendering support=
 for
>> Pango can't be found. The wxWidgets terminal will not be compiled.
>>
>>
>> But it worked until now, the version is:
>> $ rpm -qa | grep -i pango
>> pango-1.10.0-3
>> pango-doc-1.10.0-3
>> pango-devel-1.10.0-3
>>
>> Aha, I see it in ChangeLog ... but then the configure message is wrong=
: it
>> should say that a newer version of pango is required. Please fix this.
>>    =20
>
> You're right, the help message could be more not useful here. By the wa=
y,
> you made me double-check with the pango guys, and it's only the 1.10.2
> version of pango that has the bug found by Richard. 1.10.0 is perfectly
> fine.
>
> I'll modify this. Thanks.
Ok, done.
I finally copied the full defaults pkg-config messages, which will tell=20
you precisely why the test failed. (I didn't do that the first time=20
because the defaults test make the script fail with an error, and I=20
didn't have the autoconf skills at that time...) By the way, compiling=20
with pango 1.10.0 will work again.

Best regards,

Timoth=E9e

Re: Resize behaviour for the wxt terminal

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

Thanks.  I have no qualms with the way that behaves.  Forcing an aspect r=
ation on the window would then not allow reploting to a different aspect =
ratio.  I take it that you are changing your values for

     unsigned int xmax,ymax,v_char,h_char,v_tic,h_tic;

in the terminal definition so that it has an effect on the manner in whic=
h the core lays out the plot.  (In your example, it appears the fonts bec=
ome a different size relative to the position and the line thickness chan=
ges.)  If that is the case, would it be worthwhile to add an escape key t=
hat will print out what your xmax/ymax are?  That might give the user som=
e guidance in how to pick these values when transition to a different ter=
minal for an output figure.

Dan


Timoth=C3=A9e Lecomte wrote:
> Daniel J Sebald wrote:
>=20
>> Timoth=C3=A9e Lecomte wrote:
>>
>>> Dear gnuplot developpers,
>>>
>>> I just committed a small peace of code to fill in gray the empty=20
>>> space left aside or below a plot when you resize the wxt terminal=20
>>> window without keeping its aspect ratio constant. This was the=20
>>> easiest way to make this behaviour a little more easy to understand=20
>>> visually. I also modified the help text a little bit to reflect that.=
=20
>>> I would like to know if it's ok for you now. I know that this=20
>>> behaviour was one of the few complaints about the wxt terminal. I am=20
>>> still reluctant to make it behave like the x11 terminal, since I=20
>>> don't like it at all. Moreover, I'm convinced it's not a critical=20
>>> point: at worse, after some time the user will realize he just has to=
=20
>>> type 'replot' or, more easily, to click on the 'replot' icon to have=20
>>> the plot be redrawn completely to fit in the window.
>>
>>
>> Timoth=C3=A9e, could you send or place a screen capture somewhere with=
 this=20
>> gray area?  Another thing you could do is force an aspect ratio on the=
=20
>> window rather than display some area as a different color, i.e., an=20
>> ability to resize by mouse, but not independently in both dimensions.
>>
>> I like the X11 behavior, but it isn't critical that other window=20
>> platforms behave the same way.  Maybe an alternative from X11 is good=20
>> at this point.
>>
>> Dan
>=20
> Here are four captures of the wxt window :
>=20
> http://tipote.free.fr/initial.png
>    =3D> initial window after 'plot x**2'
>=20
> http://tipote.free.fr/decrease_y.png
>    =3D> I decrease the height of the window, the plot is downscaled and=
=20
> keeps its aspect ratio, leaving a gray area on the right of the window
>=20
> http://tipote.free.fr/increase_x_and_y.png
>    =3D> I increase both the width and the height of the window, the hei=
ght=20
> is increased more than the width. A gray area is left on the bottom of=20
> the window.
>=20
> http://tipote.free.fr/after_replot.png
>    =3D> I hit the 'replot' icon or type 'replot'. The plot is regenerat=
ed,=20
> fills the whole window, and font sizes and linewidths take their=20
> original value back.
>=20
> Best regards,
>=20
> Timoth=C3=A9e
>=20


--=20

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: Resize behaviour for the wxt terminal

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

Daniel J Sebald wrote:
> Timoth=C3=A9e Lecomte wrote:
>> Dear gnuplot developpers,
>>
>> I just committed a small peace of code to fill in gray the empty=20
>> space left aside or below a plot when you resize the wxt terminal=20
>> window without keeping its aspect ratio constant. This was the=20
>> easiest way to make this behaviour a little more easy to understand=20
>> visually. I also modified the help text a little bit to reflect that.=20
>> I would like to know if it's ok for you now. I know that this=20
>> behaviour was one of the few complaints about the wxt terminal. I am=20
>> still reluctant to make it behave like the x11 terminal, since I=20
>> don't like it at all. Moreover, I'm convinced it's not a critical=20
>> point: at worse, after some time the user will realize he just has to=20
>> type 'replot' or, more easily, to click on the 'replot' icon to have=20
>> the plot be redrawn completely to fit in the window.
>
> Timoth=C3=A9e, could you send or place a screen capture somewhere with =
this=20
> gray area?  Another thing you could do is force an aspect ratio on the=20
> window rather than display some area as a different color, i.e., an=20
> ability to resize by mouse, but not independently in both dimensions.
>
> I like the X11 behavior, but it isn't critical that other window=20
> platforms behave the same way.  Maybe an alternative from X11 is good=20
> at this point.
>
> Dan
Here are four captures of the wxt window :

http://tipote.free.fr/initial.png
    =3D> initial window after 'plot x**2'

http://tipote.free.fr/decrease_y.png
    =3D> I decrease the height of the window, the plot is downscaled and=20
keeps its aspect ratio, leaving a gray area on the right of the window

http://tipote.free.fr/increase_x_and_y.png
    =3D> I increase both the width and the height of the window, the=20
height is increased more than the width. A gray area is left on the=20
bottom of the window.

http://tipote.free.fr/after_replot.png
    =3D> I hit the 'replot' icon or type 'replot'. The plot is=20
regenerated, fills the whole window, and font sizes and linewidths take=20
their original value back.

Best regards,

Timoth=C3=A9e

Re: Resize behaviour for the wxt terminal

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

>> I just committed a small peace of code to fill in gray the empty space
>> left aside or below a plot when you resize the wxt terminal window
>
> That's the reason why the wxt terminals can not longer be compiled in o=
n
> SUSE 10.0?
>
> checking for wx-config... /usr/bin/wx-config
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for CAIRO... yes
> checking for PANGO... configure: WARNING: Pango can't be found. The
> wxWidgets terminal will not be compiled.
> checking for PANGOCAIRO... configure: WARNING: Cairo rendering support =
for
> Pango can't be found. The wxWidgets terminal will not be compiled.
>
>
> But it worked until now, the version is:
> $ rpm -qa | grep -i pango
> pango-1.10.0-3
> pango-doc-1.10.0-3
> pango-devel-1.10.0-3
>
> Aha, I see it in ChangeLog ... but then the configure message is wrong:=
 it
> should say that a newer version of pango is required. Please fix this.

You're right, the help message could be more not useful here. By the way,
you made me double-check with the pango guys, and it's only the 1.10.2
version of pango that has the bug found by Richard. 1.10.0 is perfectly
fine.

I'll modify this. Thanks.

Best regards,

Timoth=E9e