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

Re: Segmentation fault when using hidden option

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

On Wednesday 24 January 2007 14:51, Ethan Merritt wrote:
> It turns out that this bug has already been found and fixed 
> in the 4.3 CVS tree, but I did not realize that the fix also was
> needed for 4.2.   

And here is a 4.2 version of the relevant patch.  I've already 
added it to the CVS branch for 4.2

--- gnuplot42/src/hidden3d.c	2006-03-17 07:36:26.000000000 -0800
+++ gnuplot/src/hidden3d.c	2006-12-28 10:25:50.000000000 -0800
@@ -926,9 +925,15 @@
     max_crvlen = -1;
 
     for (this_plot = plots, surface = 0;
-	 surface < pcount;
-	 this_plot = this_plot->next_sp, surface++) {
-	long int crvlen = this_plot->iso_crvs->p_count;
+	surface < pcount;
+	this_plot = this_plot->next_sp, surface++) {
+	long int crvlen;
+	
+	/* Quietly skip empty plots */
+	if (this_plot->plot_type == NODATA)
+	    continue;
+
+	crvlen = this_plot->iso_crvs->p_count;
 
 	/* Allow individual plots to opt out of hidden3d calculations */
 	if (this_plot->opt_out_of_hidden3d)
@@ -997,6 +1002,10 @@
 	} /* switch */
     } /* for (plots) */
 
+    /* Check for no data at all */
+    if (max_crvlen <= 0)
+	return;
+
     /* allocate all the lists to the size we need: */
     resize_dynarray(&vertices, nv);
     resize_dynarray(&edges, ne);
@@ -1020,9 +1029,15 @@
     for (this_plot = plots, surface = 0;
 	 surface < pcount;
 	 this_plot = this_plot->next_sp, surface++) {
-	long int crvlen = this_plot->iso_crvs->p_count;
 	lp_style_type *lp_style = NULL;
 	TBOOLEAN color_from_column = this_plot->pm3d_color_from_column;
+	long int crvlen;
+
+	/* Quietly skip empty plots */
+	if (this_plot->plot_type == NODATA)
+	    continue;
+
+	crvlen = this_plot->iso_crvs->p_count;
 
 	/* Allow individual plots to opt out of hidden3d calculations */
 	if (this_plot->opt_out_of_hidden3d)

Re: Segmentation fault when using hidden option

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

On Tuesday 23 January 2007 21:57, Johan Tuitman wrote:
> Using the attached input result in a segmentation
> fault using:
>         Version 4.2 patchlevel rc3
>         last modified January 2007
>         System: Linux 2.6.11.4-21.15-smp
> 
> Using the same input with:
>         Version 4.0 patchlevel 0
>         last modified Thu Apr 15 14:44:22 CEST 2004
>         System: Linux 2.6.11.4-21.15-smp
> Does not give problems. 
> 
> I hope this is enough information to track the
> problem. 

Thank you for the bug report.

It turns out that this bug has already been found and fixed 
in the 4.3 CVS tree, but I did not realize that the fix also was
needed for 4.2.   




> 
> Gnuplot 4.2 shows great improvements. I am really
> happy with the improvements of the epslatex term. 
> 
> Best regards,
> 
> Johan
> 
> 
> 
>  
> ____________________________________________________________________________________
> Food fight? Enjoy some healthy debate 
> in the Yahoo! Answers Food & Drink Q&A.
> http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: gnuplot-4.2.rc3 is out Re: Version 4.2 release plans

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

> > I have put a third release candidate on SourceForge
> >   	gnuplot-4.2.rc3.tar.gz
> > 
> > Could someone please update the "Latest News" entry?
> 
> Done (for rc4, though ;-)

Some "release" reflections:

- http://www.gnuplot.info  is still out of date

- gpcard needs some modifications (with image not there, wx terminal not 
listed, ...)

- FAQ seems not to need changes.

---
PM

Re: Segmentation fault when using hidden option

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

> Using the attached input result in a segmentation
> fault using:
>         Version 4.2 patchlevel rc3
>         last modified January 2007
>         System: Linux 2.6.11.4-21.15-smp

It works for me:

        Version 4.2 patchlevel rc3
        last modified January 2007
        System: Linux 2.6.13-15.13-default

(gnuplot just recompiled from 4.2-cvs).

---
PM

Re: gnuplot-4.2.rc3 is out Re: Version 4.2 release plans

[<HBB...@t-...>]

Ethan Merritt wrote:
> I have put a third release candidate on SourceForge
>   	gnuplot-4.2.rc3.tar.gz
> 
> Could someone please update the "Latest News" entry?

Done (for rc4, though ;-)

Segmentation fault when using hidden option

[Johan T. <joh...@ya...>]

Using the attached input result in a segmentation
fault using:
        Version 4.2 patchlevel rc3
        last modified January 2007
        System: Linux 2.6.11.4-21.15-smp

Using the same input with:
        Version 4.0 patchlevel 0
        last modified Thu Apr 15 14:44:22 CEST 2004
        System: Linux 2.6.11.4-21.15-smp
Does not give problems. 

I hope this is enough information to track the
problem. 

Gnuplot 4.2 shows great improvements. I am really
happy with the improvements of the epslatex term. 

Best regards,

Johan



 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: problem with 4.2rc2 and wxt_gui.cpp on Solaris

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

Kostas Oikonomou wrote:
> Hello,
>
> I just built 4.2rc2 on Solaris 10 using Sun's compilers (Sun=20
> Studio 11).  Everything seems to work, but when I press the=20
> "Configuration" button on the wxt terminal, I get a core dump.
>
> This is what happens:
>
> (<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line=20
> 2643: assertion `str !=3D NULL' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line=20
> 2643: assertion `str !=3D NULL' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line=20
> 2643: assertion `str !=3D NULL' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtkaccellabel.c:=20
> line 187: assertion `string !=3D NULL' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtkmisc.c: line 185:=20
> assertion `GTK_IS_MISC (misc)' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtkcontainer.c: line=20
> 946: assertion `GTK_IS_WIDGET (widget)' failed
> (<unknown>:9638): Gtk-CRITICAL **: file gtkaccellabel.c:=20
> line 384: assertion `GTK_IS_ACCEL_LABEL (accel_label)' failed
> Segmentation Fault (core dumped)
>
>
> I found out that the first 3 messages are caused by
>
> 	wxCheckBox *check1 =3D new wxCheckBox ( ...)
>
> in wxt_gui.cpp.  But I have no idea what to do to fix them.=20
>   I have wxwidgets 2.7.2.
>
> Any help would be appreciated.
>
> 				Kostas
>  =20

Hi Kostas,

Thanks for taking some time to build gnuplot and test new features.

I have several remarks regarding your problem:
First, wxWidgets 2.7.2 is a "development" version. It should be safer to=20
use either the 2.6.3 or 2.8.0 versions which are "stable".
Then, it could be also a bug in the gtk, although it seems less probable.
FInally, you could help us by providing the backtrace corresponding to=20
the core dump. It will give us some idea of where the segmentation fault=20
is coming from. If you need some help to do this, don't hesitate to ask.

Best regards,

Timoth=E9e

gnuplot-4.2.rc3 is out Re: Version 4.2 release plans

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

I have put a third release candidate on SourceForge
  	gnuplot-4.2.rc3.tar.gz

Could someone please update the "Latest News" entry?


Announcement / Release Notes:

=====================================================
3rd (FINAL) RELEASE CANDIDATE FOR GNUPLOT VERSION 4.2
=====================================================

We are delighted to announce the availability of the third and hopefully
final release candidate for gnuplot version 4.2, in the form of a source
file tarball.  Pre-compiled binaries for selected platforms will follow.
Unless serious new bugs are reported, the final 4.2 release will be
identical to -rc3 except for the versioning tags.

You may download 4.2-rc3 from the gnuplot development site on SourceForge.

  http://sourceforge.net/project/showfiles.php?group_id=2055


Installation
------------
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.2.rc3 ; ./configure ; make
test it:
		make check
install it:
		make install


Short list of fixes since 4.2-rc2
---------------------------------
- Auto-configuration will use gnu libreadline unless explicitly disabled
- Document deprecation of "set size" to change image file size in pixels.
- Explicit size in terminal commands (e.g. "set term png size 500,300")
  guarantees output image size in pixels.
- 2D back/front settings are also honored in 3D plots made with "set view map"
- Allow for quoted strings in csv data files.
- Orientation of images drawn by "with image" is corrected for axis direction.
- Multi-dimensional parameters to "binary" and "with image" plot commands are
  now separated by colons rather than commas, and may be variables.
- In anticipation of libgd 2.0.34, gd.trm now checks for error from gdImageCreate
- Add Xresource gnuplot*encoding to work around a font selection bug in x.org 7.1
- Bugfix for splots with explicit reversed axes.

Remaining issues (unlikely to be resolved before official 4.2 release)
----------------------------------------------------------------------
- Installation of the new wxt terminal under OSX and Solaris is problematic
- In plots with mixed font sizes, vertical centering of text is imperfect
- Plot styles image and rgbimage are EXPERIMENTAL; implementation is incomplete


Version 4.2
-----------
This version has been under development since the release of version
4.0 in April 2004. You have probably seen frequent mention of it here
as "the development version" or "version 4.1" or "the cvs version". 

4.2 contains a ton of new features and several new terminal drivers.
For a complete list, see the NEWS file that comes with the program.
Major additions include

	* new 2D plot styles 'histogram' 'labels' 'image' 'rgbimage'
	* new 3D plot styles 'labels' 'vectors' 'image' 'rgbimage'
	* user control over color definitions and color choices
	* improved font handling and text formatting
	* text strings can be read and manipulated as normal data
	* new syntax to handle string variables and string functions
	* creation of animated gif sequences

Demo plots illustrating these and other features are online at

	http://gnuplot.sourceforge.net/demo_4.2/


We encourage everybody with a vested interest in gnuplot to get this new
version and give it a test ride.  In other words, we're calling for a
beta-test by the broader public.  That means you.

In order to assure that the quality of the upcoming full release is as
high as practical, it is important that as many of you as possible test
this release candidate in your own ways, and check that it doesn't break
spectacularly.  If there's a bug in it that makes this version unusable,
we'd like to hear about it _now_, rather than 3 hours after we release
an official version 4.2 to the general public.

Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

Thanks in advance, and have fun with it!

Re: For gnuplot 4.2 rc3

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

> I was just about to prepare the -rc3 tarball, but I'll wait for your
> readline configuration patch if you have it ready to go.

It's done. Please make rc3.

---
PM

Re: For gnuplot 4.2 rc3

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

> > > > 2. I propose to set
> > > > 	--with-readline=gnu
> > > >    to be the default, instead of the built-in readline.
> > > >    People (except for some distributors) always use this option,
> > > >    and setting this to default will save us time to answer those
> > > >    permanent emails "tabulator does not work in the new version".
> > > 
> > > Fine with me.  Do you have a patch?
> 
> Maybe have the built-in readline be selected by
>   --with-readline=builtin
> rather than
>   --with-readline
> 
> This comment is confusing:
> 
> Readline library: builtin minimal readline (use --with-readline to override)

Yes, it as. I've changed it:

$ ./configure --help
...
  --with-readline=builtin  use the built-in minimal readline
  --with-readline=gnu      use the GNU readline library (default; 4.2 or 
				newer required)
  --with-readline=DIR      specify the location of GNU readline
...


$ ./configure --with-readline
$ ./configure --with-readline=gnu
...
Readline library: GNU readline library with  -lncurses
...


$ ./configure --with-readline=builtin
...
Readline library: builtin minimal (use --with-readline=gnu for GNU 
readline)
...


---
PM

Re: For gnuplot 4.2 rc3

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

> > I wish rc3 appears soon. There, I propose the following changes:
> > 
> > 1. Apply [ gnuplot-Bugs-1612995 ] Flag 'interactive' not reset to FALSE
> >    after '-' plot script
> 
> As per the comments attached to the bug report, I don't think that
> patch is the correct fix for the problem.  The problem is not the
> interactive flag; it is a failure to distinguish between a typed
> "load" command  and an additional input file.

If the input file does not exist, or there is an error in it, gnuplot should 
exit. Instead, it loops forever. So there is a bug... (but I don't know a 
better fix).


> > 2. I propose to set
> > 	--with-readline=gnu
> >    to be the default, instead of the built-in readline.
> >    People (except for some distributors) always use this option,
> >    and setting this to default will save us time to answer those
> >    permanent emails "tabulator does not work in the new version".
> 
> Fine with me.  Do you have a patch?

It is enclosed. I think it is OK; I will commit it unless some other 
comments.

---
PM

Re: For gnuplot 4.2 rc3

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

On Saturday 20 January 2007 11:54, Petr Mikulik wrote:
> I wish rc3 appears soon. There, I propose the following changes:
> 
> 1. Apply [ gnuplot-Bugs-1612995 ] Flag 'interactive' not reset to FALSE
>    after '-' plot script

As per the comments attached to the bug report, I don't think that
patch is the correct fix for the problem.  The problem is not the
interactive flag; it is a failure to distinguish between a typed
"load" command  and an additional input file.

 
> 2. I propose to set
> 	--with-readline=gnu
>    to be the default, instead of the built-in readline.
>    People (except for some distributors) always use this option,
>    and setting this to default will save us time to answer those
>    permanent emails "tabulator does not work in the new version".

Fine with me.  Do you have a patch?

I was just about to prepare the -rc3 tarball, but I'll wait for your
readline configuration patch if you have it ready to go.

	Ethan

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

For gnuplot 4.2 rc3

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

I wish rc3 appears soon. There, I propose the following changes:

1. Apply [ gnuplot-Bugs-1612995 ] Flag 'interactive' not reset to FALSE
   after '-' plot script

2. I propose to set
	--with-readline=gnu
   to be the default, instead of the built-in readline.
   People (except for some distributors) always use this option,
   and setting this to default will save us time to answer those
   permanent emails "tabulator does not work in the new version".

3. www.gnuplot.info is not mirroring gnuplot.sourceforge.net, for
   a long time, nobody responded until now. Is still Clark Gaylord the
   persons with the access there?

---
PM

Re: emf assertions fail

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

On Friday 19 January 2007 03:42, Dr. Johannes Zellner wrote:
> Hello,
> 
> there are assertions as
> 
>     assert(ux < term->xmax && uy < term->ymax);
> 
> in emf.trm which fail sometimes.
> 
> I belive, that these assertions should be changed to include
> equality like this:
> 
>     assert(ux <= term->xmax && uy <= term->ymax);
> 
> agreed?

Can we also change them to int_error() rather than assert?.
It's very annoying to have the program die just because of a
something trivial like an arrowhead protruding across the edge
of the canvas.

emf assertions fail

[Dr. J. Z. <joh...@ze...>]

Hello,

there are assertions as

    assert(ux < term->xmax && uy < term->ymax);

in emf.trm which fail sometimes.

I belive, that these assertions should be changed to include
equality like this:

    assert(ux <= term->xmax && uy <= term->ymax);

agreed?

-- 
Johannes

Re: print axis scale

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

On Wednesday 17 January 2007 13:03, Christian Henning wrote:
> I make gif-dataplots with gnuplot under linux. I use the autorange function. 
> For further processing I need to know the scale of the generated y and y1 
> axis. So I would like to have an output (stdout) like this:
> 
> Y1-Max: 55
> Y1-Min: 45
> Y2-Max:2.9
> Y2-Min:1.2
> 
> Can you give me an hint were the axis is calculeted and were I can find 
> these values.

In version 4.2 (but not in earlier versions) these are exported as user
variables.

plot 'foo'
print "Y1-max:", GPVAL_Y_MAX
print "Y1-min:", GPVAL_Y_MIN
print "Y2-max:", GPVAL_Y2_MAX
print "Y2-min:", GPVAL_Y2_MIN

print axis scale

[Christian H. <po...@we...>]

Hi,

I make gif-dataplots with gnuplot under linux. I use the autorange function. 
For further processing I need to know the scale of the generated y and y1 
axis. So I would like to have an output (stdout) like this:

Y1-Max: 55
Y1-Min: 45
Y2-Max:2.9
Y2-Min:1.2

Can you give me an hint were the axis is calculeted and were I can find 
these values.

Thanks
Christian

Re: surface elements for transparent_solids.dem

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

Petr Mikulik wrote:
>>Please consider making this change.  It's a relatively short patch.
> 
> 
> Unfortunately it does not patch to current cvs.

It works for the CVS version I downloaded half an hour ago.

>>Also, the above plot and the one that follows it:
>>
>>set title '"set pm3d scansbackward" makes this as viewed from above'
>>
>>have border lines that appear kind of Escher-ish.
> 
> 
> The plot depends on the scan direction. Shown are those rectangles coming 
> last. It is probably the plot title which should change.

Yes, title change is what is needed.

Dan

Re: surface elements for transparent_solids.dem

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

> Please consider making this change.  It's a relatively short patch.

Unfortunately it does not patch to current cvs.

> >Or maybe "outline" would suffice as opposed to "tileline"
> I would find "sort3d" more intuitive. Perhaps you were looking for a more 
> encompassing name reflecting the overall effect of "estimate hidden line 
> removal".  But in some sense, "depthorder" or "sort3d" is specific too 
> because the user needs to understand that the pm3d elements are what are 
> being sorted.  So "outline" is no more specific than "depthorder".

Yes, sorry, I thought you want to replace "depthorder".


> Petr, in the demo 'pm3d.dem' it says 
> set title "surface at view 130,10 (viewed from below)"
> set pm3d
> set palette
> set view 130,10
> set samples 50; set isosamples 50
> set border 4095
> unset surface
> set pm3d at s scansforward
> splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2)
> pause -1 "Hit return to continue"
> 
> This example isn't technically something that looks to be view from below, is
> it?  Instead there is something discontinuous about it.
> 
> Also, the above plot and the one that follows it:
> 
> set title '"set pm3d scansbackward" makes this as viewed from above'
> 
> have border lines that appear kind of Escher-ish.

The plot depends on the scan direction. Shown are those rectangles coming 
last. It is probably the plot title which should change.

---
PM

Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

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

Petr Mikulik wrote:
>>>I've placed a patch on SourceForge that changes the option name of
>>>'hidden3d' to 'tileline' of 'set pm3d'.
>>
>>Or maybe "outline" would suffice as opposed to "tileline"
> 
> 
> I would find "sort3d" more intuitive.

Perhaps you were looking for a more encompassing name reflecting the overall effect of "estimate hidden line removal".  But in some sense, "depthorder" or "sort3d" is specific too because the user needs to understand that the pm3d elements are what are being sorted.  So "outline" is no more specific than "depthorder".

Dan

Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

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

Petr Mikulik wrote:
>>>I've placed a patch on SourceForge that changes the option name of
>>>'hidden3d' to 'tileline' of 'set pm3d'.
>>
>>Or maybe "outline" would suffice as opposed to "tileline"
> 
> 
> I would find "sort3d" more intuitive.

"sort3d", for the option of including a line drawn around the pm3d elements?  I guess I didn't write that out correctly.  What I was proposing would be

  set pm3d depthorder outline

rather than

  set pm3d depthorder hidden3d

Were you thinking I meant a different name for "depthorder" or something else?

Dan

Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

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

> > I've placed a patch on SourceForge that changes the option name of
> > 'hidden3d' to 'tileline' of 'set pm3d'.
> 
> Or maybe "outline" would suffice as opposed to "tileline"

I would find "sort3d" more intuitive.

---
PM

Re: surface elements for transparent_solids.dem

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

Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
>>I've placed a patch on SourceForge that changes the option name of
>>'hidden3d' to 'tileline' of 'set pm3d'.
> 
> 
> Or maybe "outline" would suffice as opposed to "tileline"

Oh yeah, I forgot to mentioned that from my tests it looks like the slowness of the double torus example in 'transparent_solid.dem' is due more to drawing all those elements in gnuplot_x11.

Dan

Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

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

Daniel J Sebald wrote:
> I've placed a patch on SourceForge that changes the option name of
> 'hidden3d' to 'tileline' of 'set pm3d'.

Or maybe "outline" would suffice as opposed to "tileline"

Dan

Re: surface elements for transparent_solids.dem

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

I've placed a patch on SourceForge that changes the option name of 'hidden3d' to 'tileline' of 'set pm3d'.  Then hidden3d is enabled to work with 'with pm3d' by moving the hidden line function call to after the pm3d code in 'graph3d.c'.  Also, documentation makes the distinction between the two.

Please consider making this change.  It's a relatively short patch.  I think it more accurately reflects the plotting action.  (It takes a while for someone to realize that 'hidden3d' for 'set pm3d' and the 'set hidden3d' are actually two different things.)  It also moves things in the direction that Ethan suggested.  Future work would be to integrate solid surfaces into the hidden code.

The first example of 'transparent_solids.dem' I've left as is.  The second example (Kuen) I've changed to use the hidden3d.  I realize that messes up the intended illustration of transparent surfaces.  After the patch, someone can rearrange the demos.  (I'd suggest using Kuen surface as an example of illustrating speed and bad tile order in pm3d.dem... see my comments below about the current illustrations in pm3d.dem.)

Dan

...

Petr, in the demo 'pm3d.dem' it says 

set title "surface at view 130,10 (viewed from below)"
set pm3d
set palette
set view 130,10
set samples 50; set isosamples 50
set border 4095
unset surface
set pm3d at s scansforward
splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2)
pause -1 "Hit return to continue"

This example isn't technically something that looks to be view from below, is it?  Instead there is something discontinuous about it.

Also, the above plot and the one that follows it:

set title '"set pm3d scansbackward" makes this as viewed from above'

have border lines that appear kind of Escher-ish.

A little further along in the demo is the plot:

set title "set hidden3d"
set samples 30; set isosamples 30
set hidden3d
set pm3d
set surface
set view 50,220
set xrange [-2:2]
set yrange [-2:2]
splot log(x*x*y*y)

Notice, that prior to the patch I created, this plot did not have hidden3d present.  After the patch, it looks to have hidden3d, per the plot description.