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

Re: Qt Wrapper, wx and real-time plots

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

Nigel Nunn wrote:

>My experimental term wx works well, but the Gnuplot's use
>of global variables effectively limits us to a single panel.
>This could be fixed by packaging these globals in a struct,
>and associating one such struct with each display panel.
>  
>

We've had discussion of global variables before.  I don't like 'em... 
and I tried reducing the extent of them when reworking the use of 
df_open(), df_readline(), etc.

Dan

RE: Qt Wrapper, wx and real-time plots

[Nigel N. <nN...@au...>]

Hi all,=0D
=0D
Thanks to Hans-Bernhard for setting the (wx) scene.=0D

--- On Friday, 10 December 2004 HBB wrote: ---

> Ethan Merritt wrote:
>> On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote:
>>=0D
>>> Again, since wx transmogrifies into a native app on each
>>> platform, the same option would still be available for
>>> term=3Dwx on a Win32/64 box. =0D
>>=0D
>> What is this "term=3Dwx"; is that an out-of-tree gnuplot=0D
>> driver, or something else entirely?
>
> Nigel Nunn seems otherwise occupied, so I'll bite: it's a=0D
> hypothetical new driver, to be built by extending Nigel's=0D
> work on integrating gnuplot into other apps, as a GUI control=0D
> (original an MFC control, now, apparently, a wx Widget).


My (ever-evolving, monolithic) simulation environment needs=0D
a number of plotting panels.  These are managed by the app,
and plots are generated by simulation threads.  Since most=0D
academics appear to prefer their flavor of *nix rather than=0D
HPC-Win64 on a rack of multi-core blades, there was little=0D
interest in my VC-specific version... hence I migrated the=0D
whole show to wxWidgets.=0D

My experimental term wx works well, but the Gnuplot's use=0D
of global variables effectively limits us to a single panel.=0D
This could be fixed by packaging these globals in a struct,=0D
and associating one such struct with each display panel.=0D
=0D
=0D
>> Or do you mean that rather than reading from a real file,
>> you want gnuplot to read from a shared-memory area?
>
> That's what he meant.  gnuplot-as-a-library, if it is to make=0D
> sense, needs a way to get data passed in by huge blocks, from=0D
> the calling application.  Going through an ASCII data file=0D
> would be pretty foolish for that, but a shared memory-mapped=0D
> file of binary data would do it.
>
> In other words, a named pipe by usage, but implemented in a=0D
> more Windows-ish fashion.

Memory-mapped files were one of those neat innovations the=0D
DEC engineers built into their NT-OS for their Alpha, before=0D
Microsoft bought everything and everyone involved.=0D
=0D
Nigel=0D
=0D
=0D
=0D

___________________________________________________________________________=
________

This message is intended for the addressee named and may contain=
 confidential and=0D
privileged information. If you are not the intended recipient please note=
 that any=0D
form of distribution, copying or use of this communication or the=
 information in it=0D
is strictly prohibited and may be unlawful. If you receive this message in=
 error,=0D
please delete it and notify the sender.

Keep up to date with what's happening in Australian sport. Visit=
 www.ausport.gov.au
___________________________________________________________________________=
________=0D

Re: Gpcard.pdf: no paper size, right margin missing

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

> and tried to view it with xpdf version 3.00, gv version 3.5.8 and Adobe
> acrobat reader 4.0. Neither program shows the right margin of the
> reference card: in the Graphics Devices column, only the "s" of the
> "set terminal" command is shown. Xpdf complains with
>   Error: No paper information available - using defaults

I've put there a regenerated version. Please try it.

---
PM

Re: Qt Wrapper, wx and real-time plots

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote:
> 
>>>Again, since wx transmogrifies into a native app on each
>>>platform, the same option would still be available for
>>>term=wx on a Win32/64 box.  
> 
> 
> What is this "term=wx"; is that an out-of-tree gnuplot driver,
> or something else entirely?

Nigel Nunn seems otherwise occupied, so I'll bite: it's a hypothetical 
new driver, to be built by extending Nigel's work on integrating gnuplot 
into other apps, as a GUI control (original an MFC control, now, 
apparently, a wx Widget).

> Or do you mean that rather than reading from a real file,
> you want gnuplot to read from a shared-memory area?

That's what he meant.  gnuplot-as-a-library, if it is to make sense, 
needs a way to get data passed in by huge blocks, from the calling 
application.  Going through an ASCII data file would be pretty foolish 
for that, but a shared memory-mapped file of binary data would do it.

In other words, a named pipe by usage, but implemented in a more 
Windows-ish fashion.

Re: pm3d and parametric function surface plots

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

> I've just uploaded a patch to graph3d.c which implements the depth patch
> also for "set pm3d implicit".

Can you please upload the complete patch? pm3d.c fails to be patched.

Thanks, Petr

Re: pm3d and parametric function surface plots

[Johannes Z. <joh...@ze...>]

On Tue, Dec 07, 2004 at 09:35:35AM +0100, Petr Mikulik wrote:
> > > set pm3d depth
> > > splot 'whale.dat' with pm3d
> >
> > actually here it works fine. I guess you're missing
> >
> >     set pm3d at s explicit
> 
> Yes, now it works fine.
> 
> > I guess I've to update the patch to work also with implicit surface
> > coloring.
> 
> That would be nice.

I've just uploaded a patch to graph3d.c which implements the depth patch
also for "set pm3d implicit". Even if pm3d is "implicit", the surface
type has to be specified explicitely on the splot line like

     gnuplot> set pm3d implicit
     gnuplot> splot 'whale.dat' with pm3d

This is due to the fact that when using

     gnuplot> set pm3d implicit
     gnuplot> splot 'whale.dat'

the pm3d surface must be plotted before the default style (which might
be lines for example).

-- 
Johannes

Re: no mirroring to www.gnuplot.info

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

Petr Mikulik wrote:

>I have posted this message several times already, but no one responded. =
Who
>is the maintainer of www.gnuplot.info???
>
>FWD:
>Mirroring of gnuplot.sf.net to www.gnuplot.info does not work -- cf. pag=
es
>from October/November to those of May.
> =20
>

Not sure what is not being updated... However, perusing some demos, I'd=20
suggest someone removing this one:

Une belle fille <http://f3wm.free.fr/linux/gp_girl.html> =96 gnuplot peut=
=20
tracer n'importe quelle courbe depuis un fichier de donn=E9s ad=E9quat
(A beatiful girl =96 gnuplot can plot any curve from a suitable datafile)=
.

I'm try not being too much of a moralist, and the human body doesn't=20
frighten me in any way. However, in the scientific field traditionally=20
being male oriented, unless one is willing to put a picture of a buff=20
stud with his dangly parts hanging out, I'd call this one sexist.

Dan

Re: no mirroring to www.gnuplot.info

[Lars H. <lhe...@us...>]

Petr Mikulik writes:
> I have posted this message several times already, but no one responded. Who
> is the maintainer of www.gnuplot.info???
> 
> FWD:
> Mirroring of gnuplot.sf.net to www.gnuplot.info does not work -- cf. pages
> from October/November to those of May.
> 
> Who is maintaining www.gnuplot.info?
> Could he restart the mirroring?
 
 I have forwarded your mail to Clark Gaylord.

Re: Qt Wrapper, wx and real-time plots

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

On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote:
> >
> > Again, since wx transmogrifies into a native app on each
> > platform, the same option would still be available for
> > term=wx on a Win32/64 box.  

What is this "term=wx"; is that an out-of-tree gnuplot driver,
or something else entirely?

> > If *nix also has high-speed 
> > memory mapped file options, I wonder if this mode might
> > be implemented more generally in the Gnuplot core.

In most unix/linux systems *all* files are cached in memory
to the extent possible. 

Or do you mean that rather than reading from a real file,
you want gnuplot to read from a shared-memory area?
That would be possible, but probably unnecessary.
You could achieve much the same thing with no change to existing
code by using a named pipe rather than a file.  I think there's
a Python-based demo on the web site that provides an example of this.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

no mirroring to www.gnuplot.info

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

I have posted this message several times already, but no one responded. Who
is the maintainer of www.gnuplot.info???

FWD:
Mirroring of gnuplot.sf.net to www.gnuplot.info does not work -- cf. pages
from October/November to those of May.

Who is maintaining www.gnuplot.info?
Could he restart the mirroring?

---
PM

Re: Qt Wrapper, wx and real-time plots

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

> Recalling old version of "embedded" Win32 Gnuplot engine
> plotting 500 random points, directly from memory-mapped
> file, refreshing an MFC CView 100 times a second, on a
> dual 733 MHz PIII...  Gnuplot's "oscilloscope" mode ?
>
> Again, since wx transmogrifies into a native app on each
> platform, the same option would still be available for
> term=wx on a Win32/64 box.  If *nix also has high-speed
> memory mapped file options, I wonder if this mode might
> be implemented more generally in the Gnuplot core.

If you have a demo of your approach, it may be worth to be put into
gnuplot's web site.

---
PM

Re: pm3d and parametric function surface plots

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

> > (*) Quadrangles may take a lot of memory. I propose to change double to
> > float (should probably happen also for gpdPoint structure).
> >
> > typedef struct {
> >     double gray;
> >     double z; /* maximal z value after rotation to graph coordinate system
> > */
> >     gpdPoint corners[4];
> >     gpiPoint icorners[4]; /* also if EXTENDED_COLOR_SPECS is not defined */
> > } quadrangle;
>
> Please, if you do that, respect prior art and use the existing type
> 'coordval' for that.  That's what this type was designed for: it's
> defined as double on platforms that can afford it, and float elsewhere.

IMHO, gnuplot is using too much memory for images and surfaces -- or, in
other words, it can work with large images, like >=512^2 pts, but it
suffers. I would prefer not to use double if float is sufficient, as in this
case.

The above structure is 64 B for double, and 40 B for float.
For an image of 512^2 it would save 6 MB.

Well, we can always recompile gnuplot for using float instead of double. I
do sometimes.

---
PM

Re: pm3d and parametric function surface plots

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

> > set pm3d depth
> > splot 'whale.dat' with pm3d
>
> actually here it works fine. I guess you're missing
>
>     set pm3d at s explicit

Yes, now it works fine.

> I guess I've to update the patch to work also with implicit surface
> coloring.

That would be nice.

---
PM

Re: pm3d and parametric function surface plots

[Johannes Z. <joh...@ze...>]

On Mon, Dec 06, 2004 at 06:48:16PM +0100, Petr Mikulik wrote:
> (*) The ordering works with the torus example. But then I have tried this
> demo:
> 
> set pm3d depth
> splot 'whale.dat' with pm3d

actually here it works fine. I guess you're missing

    set pm3d at s explicit

I guess I've to update the patch to work also with implicit surface
coloring.

-- 
Johannes

Re: pm3d and parametric function surface plots

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> (*) The ordering works with the torus example. But then I have tried this
> demo:
> 
> set pm3d depth
> splot 'whale.dat' with pm3d
> 
> but it does not do the ordering. What's wrong?

Probably that Johannes didn't think about multi-mesh and multi-function
plots.  Hidden surface removal can't really be done on individual
surfaces --- you *have* to do it for the entire display. There's a
reason 'set hidden3d' is a global setting, and its implementation
intermixed all through the 3D graphics output routines.

Which brings me to a suggestion: this new depth-sorting feature may have
to be re-organized from scratch, and moved to be controlled by 'set
hidden3d'.  I.e. it'll become the hidden3d mode of pm3d (rather than
what currently sails under than option name in 'set pm3d', which is
something entirely different).

> (*) The option "set pm3d ... depth" should have also "... nodepth" variant
> to switch this feature off.

 From what I understood, 'depthsorting' is an exclusive alternative to
'scans{forward|backward|default}', so wouldn't 'scansdefault' do that
already?

> (*) Quadrangles may take a lot of memory. I propose to change double to
> float (should probably happen also for gpdPoint structure).
> 
> typedef struct {
>     double gray;
>     double z; /* maximal z value after rotation to graph coordinate system
> */
>     gpdPoint corners[4];
>     gpiPoint icorners[4]; /* also if EXTENDED_COLOR_SPECS is not defined */
> } quadrangle;

Please, if you do that, respect prior art and use the existing type
'coordval' for that.  That's what this type was designed for: it's
defined as double on platforms that can afford it, and float elsewhere.

Re: pm3d and parametric function surface plots

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

(*) The ordering works with the torus example. But then I have tried this
demo:

set pm3d depth
splot 'whale.dat' with pm3d

but it does not do the ordering. What's wrong?

(*) The option "set pm3d ... depth" should have also "... nodepth" variant
to switch this feature off.

(*) Quadrangles may take a lot of memory. I propose to change double to
float (should probably happen also for gpdPoint structure).

typedef struct {
    double gray;
    double z; /* maximal z value after rotation to graph coordinate system
*/
    gpdPoint corners[4];
    gpiPoint icorners[4]; /* also if EXTENDED_COLOR_SPECS is not defined */
} quadrangle;


---
PM

Re: compile faild at term/fig.trm

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

Hans-Bernhard Broeker wrote:

> Reminder to all: we're not even fully up to ANSI/ISO C89 yet.  Which 
> means: no C99 nor C++ specialities are allowed in gnuplot's source 
> (yes, Petr, that does mean no // style comments, either...).


Hey!  Petr is the one who always catches the // I put in code.  (Since 
there are supposed to be no // in the code, I use the double backslash 
to temporarily comment out lines of code... then forget to clean.)

:-)

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

Daniel J Sebald wrote:

> Daniel J Sebald wrote:
>
>> set key ... background rgb (0.3, 0.2, 0.57)
>
>
>
> Does this "rgb (0.3, 0.2, 0.57)" run the risk of being confused as a 
> user-defined function?


Hans' may have just answered this:

>      gnuplot> splot using (x):(y):f(x,y):color(x,y) 
>  
>
<>
Good thinging, in principle. Except may not be 100% correct. Some daring 
young fella *might* have gone ahead
and defined himself a function named 'using' ;-)

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

Daniel J Sebald wrote:

> set key ... background rgb (0.3, 0.2, 0.57)


Does this "rgb (0.3, 0.2, 0.57)" run the risk of being confused as a 
user-defined function?

Dan

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

Petr Mikulik wrote:

>>I've been wondering about plot background colors, too.  I often see
>>plots with slightly off-white backgrounds.  There is the X11 background
>>color, but nothing for controlling background color for, say, png or
>>PostScript.  I know it has little to do with the "scientific" leanings
>>of gnuplot.  It would require something like "set background" (whole
>>area including axes and labels), "set plotground" (area only inside the
>>axes).  This might then require some color such as "none" or "clear",
>>which have obvious meanings in terminals like PostScript.
>>    
>>
>
>Yet another background is that of the graph (easy for 2D and 'view map',
>more intriguing for 3D), and for the key.
>
>What about some new syntax for that?
>
>set key ... background rgb "gray10"
>set border ... background rgb "gray10"
>set size ... background rgb "cyan"
>
>or
>
>set style background {key | border | graph | paper} .... ?
>
>  
>

(I was out of town for a bit...)  Either of these would be fine.  Or 
does your "or" mean both methods should be implemented?

This doesn't seem like a difficult thing to add.  It wouldn't be 
something I could get around to for a while.  Rather than letting this 
proposed syntax get lost in the discussion list, maybe it would be a 
good idea to put this under a patch or something in SourceForge.  There 
wouldn't be an actual patch there just yet, unfortunately, but it would 
be a reminder for later?  Should we do that?

For the 3D interpretation, how about just coloring the x-y plane 
portion?  Another alternative might be the back three sides of a 3-space 
cube, but I don't know if that would have an appealing look.  
Individually controlling plane colors?...  that's over doing it in my 
opinion.

...

With the rgb color format.  Those are fine.  Also, I added a tuple 
format for the binary data options, to represent points in 2-space or 
3-space.  For example, (1.5,3.5) or (4.5, 3.3, 2.2).  Could those be 
used in other places?  E.g.,

set key ... background rgb (0.3, 0.2, 0.57)

[Writing this just now makes it seem better in my mind than in type.]  
If so, maybe the tuple code could be made part of the parser.  I'm not 
strongly advocating it, just tossing it out to the list.

Dan

Re: pm3d and parametric function surface plots

[Johannes Z. <joh...@ze...>]

On Thu, Dec 02, 2004 at 12:36:39PM -0800, Ethan Merritt wrote:
> On Thursday 02 December 2004 09:27 am, Johannes Zellner wrote:
> > 
> > I just thought that coloring parametric surface plots according to the
> > computed z-Value is not reasonable or obvious at all.
> 
> I agree. 
> Then again, I have never needed to plot such a surface at all,
> so maybe I am failing to imagine a reasonable use.
> 
> > It would be 
> > reasonable to color it according to any function which depends on u and
> > v (the parametric variables).
> 
> Yes, that sounds much more reasonable.  It gives you the same sort
> of "4th dimension" that is available for plotting data from a file.
>  
> >     gnuplot> unset parametric
> >     gnuplot> splot f(x, y), color(x, y) w pm3d
> > 
> > But this time, the specification is ambigous.
> 
> I don't like the use of commas at all.
> Any syntax that uses commas to mean more than one thing
> is intrinsically ambiguous.
> By analogy to the existing syntax for data files,
> I think the above should instead be
> 
>       gnuplot> splot using (x):(y):f(x,y):color(x,y) 
> 
> which it may or may not be possible to shorten to
> 
>       gnuplot> splot using f(x,y):color(x,y)
> 
> > Introducing an option which forces function plots to have a color
> > function would solve the ambiguity.

and again what about:

    gnuplot> splot u, v, u * v w pm3d [at s] [function color(u, v)]

the options after pm3d beeing optional? -- The [at s] option is already
present, so why not another option which specifies the color function?
This way it would be just like any style option, where you specify
options to "styles":

    w lines lt 3 pt 1
    w pm3d function color(u, v)

What's the difference, in principle?
HBB: would that overload the syntax too much?

And it would be backward compatible. And it's /EASY/ to implement (I'd
just a look ...)

-- 
Johannes

Re: compile faild at term/fig.trm

[Hans-Bernhard B. <br...@ph...>]

Shigeharu TAKENO wrote:

>      double gray = colorspec->value;
> +    int new_color;
>  
>      if (colorspec->type != TC_FRAC)
>  	return;
>  
> -    int new_color = (gray <= 0) ? 0 : (int)(gray * sm_palette.colors);
> +    new_color = (gray <= 0) ? 0 : (int)(gray * sm_palette.colors);

Thanks for spotting this.  I'm checking in that fix right away.

Reminder to all: we're not even fully up to ANSI/ISO C89 yet.  Which 
means: no C99 nor C++ specialities are allowed in gnuplot's source (yes, 
Petr, that does mean no // style comments, either...).  People using GCC 
version 3 or higher may have to configure with the appropriate CFLAGS 
set to disallow C99-isms like the above from creeping into the CVS.

compile faild at term/fig.trm

[Shigeharu T. <sh...@ie...>]

shige 12/03 2004
----------------

I compiled current CVS version of gnuplot on 

 OS: Solaris 2.6 
 Compiler: gcc-2.95.3

But the compile of term/fig.trm (rev. 1.47) is failed. The 
following patch fixes it.

----- From here -----
--- term/fig.trm.ORG	Fri Dec  3 19:53:18 2004
+++ term/fig.trm	Fri Dec  3 20:47:57 2004
@@ -1107,11 +1107,12 @@
 TERM_PUBLIC void FIG_set_color(t_colorspec *colorspec)
 {
     double gray = colorspec->value;
+    int new_color;
 
     if (colorspec->type != TC_FRAC)
 	return;
 
-    int new_color = (gray <= 0) ? 0 : (int)(gray * sm_palette.colors);
+    new_color = (gray <= 0) ? 0 : (int)(gray * sm_palette.colors);
     if (new_color >= FIG_palette_size)
 	new_color = FIG_palette_size - 1;
     if (FIG_palette_set == FALSE) {
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: pm3d and parametric function surface plots

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

On Thursday 02 December 2004 12:44 pm, Hans-Bernhard Broeker wrote:

> >       gnuplot> splot using (x):(y):f(x,y):color(x,y) 
> 
> > it will not break existing scripts.
> 
> may not be 100% correct.  Some daring young fella *might* have gone ahead
> and defined himself a function named 'using' ;-)

Good point ;-)

More likely, though, he tried to 'splot u(x)'  which could still
run aground on the obvious implementation

	if almost_equals(c_token, "u$sing")

So there is a real concern hiding in there.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: pm3d and parametric function surface plots

[Hans-Bernhard B. <br...@ph...>]

On Thu, 2 Dec 2004, Ethan Merritt wrote:

> On Thursday 02 December 2004 09:27 am, Johannes Zellner wrote:
> > 
> > I just thought that coloring parametric surface plots according to the
> > computed z-Value is not reasonable or obvious at all.
> 
> I agree. 
> Then again, I have never needed to plot such a surface at all,
> so maybe I am failing to imagine a reasonable use.

Oh, Johannes is just setting out on a mission to beat Mathematica in the
game of "making glorious pictures of maths".  No big deal, piece of cake
actually ;->

> > But this time, the specification is ambigous.
> 
> I don't like the use of commas at all.
> Any syntax that uses commas to mean more than one thing
> is intrinsically ambiguous.
> By analogy to the existing syntax for data files,
> I think the above should instead be
> 
>       gnuplot> splot using (x):(y):f(x,y):color(x,y) 

Good thinging, in principle.  Except

> Since the syntax "splot using ..." is not currently valid, it will not
> break existing scripts.

may not be 100% correct.  Some daring young fella *might* have gone ahead
and defined himself a function named 'using' ;-)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.