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

make of gnuplot cvs djgpp failed (Newly imported Bug??)

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

Hello

I have attemted to gnuplot cvs (2008-03-02) on the djgpp.

gcc -c -DHAVE_CONFIG_H -O2 -g  -I. -DHELPFILE=\"gnuplot.gih\" command.c
command.c:1337: error: conflicting types for 'refresh_request'
command.c:1332: error: previous implicit declaration of 'refresh_request' was he
re
make.exe: *** [command.o] Error 1
make.exe: Leaving directory `d:/usr/Tatsu/djgpphome/gnuplotcvs/gnuplot/src'

The error seems to be confiliction in terms of "refresh_request".

My trying comes from only curiosity so that the reply is not urgent but
the problem seem to be Bug newly imported bug.

Regards

Tatsuro

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: Possible problem with CGM terminal

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

Ethan,

That is great news.  You are a genius!

I'm in the middle of upgrading our engineering modeling software from Gnuplot 3.8h to a CVS snapshot.  We generate about 15 different kinds of plots (2D, 3D and pm3d) and support screen (X11 & Windows), Postscript and CGM output types.  We needed to add PNG file type support so I decided to upgrade Gnuplot at the same time.  Everything has been pretty smooth.  Some of the labeling for the screen plots had to be adjusted now that X11 supports rotated text.  For my newest plot type, the macros and string variables are indispensable.

Thanks again,

Mike Sutton


> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "m sutton" <mw...@us...>
> Subject: Re: Possible problem with CGM terminal
> Date: Sat, 1 Mar 2008 14:34:01 -0800
> 
> 
> On Friday 29 February 2008 20:41, Ethan A Merritt wrote:
> > On Friday 29 February 2008 17:49, m sutton wrote:
> > > > However with the 4.3beta snapshot I get the solid black area 
> > in > PowerPoint and Corel Draw gives an I/O read error and 
> > OpenOffice works fine.
> 
> Fixed in CVS.
> 
> When the support for filled boxes was added in 2003, the code for
> managing fill styles was put in the routined CGM_fillbox(), which in
> turn calls CGM_filled_polygon().   However, the pm3d code calls
> term->filled_polygon() directly.  So in general the pm3d calls were not
> in sync with the current color and fill settings.
> 
> The fix was to move the fill style code out of CGM_fillbox() and
> into CGM_filled_polygon().
> 
> While testing this change, I found another separate bug in managing
> dash styles.  For example you can see that the three blue lines in
> the dashcolors.dem demo all have the same dash style in the cgm output.
> That one remains to be fixed.
> 
> Also I was reminded that CGM doesn't support RGB colors.
> I don't know if it would be possible to add support or not.
> Does anyone have a pointer to CGM documentation?
> 
> --
> Ethan A Merritt

>


-- 
Want an e-mail address like mine?
Get a free e-mail account today at www.mail.com!

Re: Possible problem with CGM terminal

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

On Friday 29 February 2008 20:41, Ethan A Merritt wrote:
> On Friday 29 February 2008 17:49, m sutton wrote:
> > 
> > However with the 4.3beta snapshot I get the solid black area in 
> > PowerPoint and Corel Draw gives an I/O read error and OpenOffice works fine. 

Fixed in CVS.

When the support for filled boxes was added in 2003, the code for
managing fill styles was put in the routined CGM_fillbox(), which in 
turn calls CGM_filled_polygon().   However, the pm3d code calls
term->filled_polygon() directly.  So in general the pm3d calls were not
in sync with the current color and fill settings.

The fix was to move the fill style code out of CGM_fillbox() and
into CGM_filled_polygon().

While testing this change, I found another separate bug in managing
dash styles.  For example you can see that the three blue lines in
the dashcolors.dem demo all have the same dash style in the cgm output.
That one remains to be fixed.

Also I was reminded that CGM doesn't support RGB colors.
I don't know if it would be possible to add support or not.
Does anyone have a pointer to CGM documentation? 

-- 
Ethan A Merritt

Re: cbfix

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

> Having autoscaling
> switched on for all axes by default (so the default for all axes is
> the same) might be esthetically and conceptionally "correct" but it is
> counterintuitive.

A note of clarification: it's not actually autoscaling that's getting in 
your way there.  It's auto-extension.  Which only happens if both 
auto-scaling and auto-ticking are in operation.

> I would guess that it's far above 90% of cases where
> the colorbox range should be "cbfix".  My feeling is that the default
> autoscaling for the colorbox is rarely wanted and used. Therefore I'd
> suggest to turn the default to "set autoscale cbfix" (even though this
> breaks backwards compatibility.

I'm against breaking backward compatibility for an issue that can 
trivially be fixed by putting a line in your ~/.gnuplotrc (or other 
platform's equivalent)

cbfix

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

Hello,

about everybody of my collegues who uses gnuplot / pm3d the first time
asks me how to make the pm3d colorbox to display only the colors from
the plot -- which is easily be done by "set autoscale cbfix". I heared
this question about 10 or 15 times the last years. Having autoscaling
switched on for all axes by default (so the default for all axes is
the same) might be esthetically and conceptionally "correct" but it is
counterintuitive. I would guess that it's far above 90% of cases where
the colorbox range should be "cbfix". My feeling is that the default
autoscaling for the colorbox is rarely wanted and used. Therefore I'd
suggest to turn the default to "set autoscale cbfix" (even though this
breaks backwards compatibility.

-- 
Dr. Johannes Zellner <joh...@ze...>

Re: Possible problem with CGM terminal

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

On Friday 29 February 2008 17:49, m sutton wrote:
> 
> I'm thinking that there may be a problem somewhere.
> 
> Attached (test38.cgm) is a cgm file created with gnuplot 3.8h.
> I can load this file into PowerPoint 2003 and Corel Draw X3 just fine.
> 
> However with the 4.3beta snapshot I get the solid black area in 
> PowerPoint and Corel Draw gives an I/O read error and OpenOffice works fine. 

Strange.  And nobody has complained for four and a half years.
I guess nobody uses cgm + pm3d.

Disabling the small section below, added in May 2003, makes pm3d work
in PowerPoint under wine.

--- gnuplot-broken/term/cgm.trm        2008-02-24 11:49:37.000000000 -0800
+++ gnuplot-works/term/cgm.trm    2008-02-29 20:29:23.000000000 -0800
@@ -1162,10 +1162,12 @@
      * we implement a big enough block that problems should be
      * rare.  */

+#ifdef BROKEN_BROKEN
     if (cgm_current.interior_style != cgm_next.interior_style){
       cgm_current.interior_style = cgm_next.interior_style;
       CGM_write_int_record(5, 22, 2, &cgm_next.interior_style);
     }
+#endif
     if (cgm_current.fill_color != cgm_next.fill_color){
       cgm_current.fill_color = cgm_next.fill_color;
       CGM_write_int_record(5, 23, 2, &cgm_next.fill_color);


Those lines were added in support of pattern-fill, and removing them
breaks pattern fill (again as judged using PowerPoint under wine).
I can stare at the code and hope that further enlightenment strikes,
but I don't have any CGM documentation to guide me any further.

	Ethan

-- 
Ethan A Merritt

Re: Possible problem with CGM terminal

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

> ----- Original Message -----
> From: "Tatsuro MATSUOKA" <tma...@ya...>
> To: HBB...@t-..., "m sutton" <mw...@us...>
> Subject: Re: Possible problem with CGM terminal
> Date: Fri, 29 Feb 2008 22:10:58 +0900 (JST)
>
>
> Hello
>
> I have tested both on Microsoft office 2003 (word and powerpoint) and
> OpenOffice 2.1 impress.
> On the Microsoft office 2003, I also have gotten  a solid black
> area instead of the expected rainbow of color.
>
> However on the open office impress of win xp worked well.
> Perhaps it is not problem of gnuplot but that of win xp cgm filter.
>

I'm thinking that there may be a problem somewhere.

Attached (test38.cgm) is a cgm file created with gnuplot 3.8h.  I can load this file into PowerPoint 2003 and Corel Draw X3 just fine.  Open office impress 2.3 loads the file but the text is white instead of black.

However with the 4.3beta snapshot I get the solid black area in PowerPoint and Corel Draw gives an I/O read error and OpenOffice works fine.

Mike Sutton




-- 
Want an e-mail address like mine?
Get a free e-mail account today at www.mail.com!

Re: Possible problem with CGM terminal

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

Hello

I have tested both on Microsoft office 2003 (word and powerpoint) and 
OpenOffice 2.1 impress.
On the Microsoft office 2003, I also have gotten  a solid black
area instead of the expected rainbow of color.

However on the open office impress of win xp worked well.
Perhaps it is not problem of gnuplot but that of win xp cgm filter.

Regards

Tatsuro



--- Hans-Bernhard Br&#65533;ker <HBB...@t-...> wrote:

> m sutton wrote:
> 
> > When I import the resulting CGM into PowerPoint I get a solid black
> > area instead of the expected rainbow of color.
> 
> > Can anyone reproduce this?
> 
> It works just fine with OpenOffice.org Impress 2.0 on XP, and the CVS 
> version of gnuplot as of right now.  I opened the .cgm file with Office 
> instead of importing it, though.
> 
> -------------------------------------------------------------------------
> 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
> 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: Possible problem with CGM terminal

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

m sutton wrote:

> When I import the resulting CGM into PowerPoint I get a solid black
> area instead of the expected rainbow of color.

> Can anyone reproduce this?

It works just fine with OpenOffice.org Impress 2.0 on XP, and the CVS 
version of gnuplot as of right now.  I opened the .cgm file with Office 
instead of importing it, though.

Re: POV-Ray Terminal

[Timothée L. <tim...@lp...>]

Ethan Merritt a écrit :
> On Wednesday 27 February 2008 01:17, Timothée Lecomte wrote:
>
>   
>> The authors have bypassed gnuplot terminal system almost completely,
>> and only 'splot' seems to be possible.
>>     
>
> To be fair, it is not clear what one should do with a 'plot' command.
> There are only 2 coordinates, not 3, and we don't have 3D equivalents
> for plot elements like boxes and filledcurves.  The best approach 
> might be to run off a 2D plot as a PNG image, and then map the result
> into 3D using 'splot ... with image'.
>
> 	Ethan
>   

Spreadsheet software usually offer a 3D view of any diagram, applying a 
depth to every single part of the plot, apart from text maybe. A 'plot' 
command on a 3D-"aware" terminal could produce such a thing. I don't 
think it's very useful for complex scientific data, but simple 
histograms look a little more appealing that way.

Best regards,

Timothée

>
>
>   
>> Daniel Farrell a écrit :
>>     
>>> Hello,
>>>
>>> I was listing to the latest FLOSS Weekly Podcast (http://twit.tv/ 
>>> floss24) in which the topic was POV-Ray; an open source ray tracing  
>>> program. After some idle surfing I found that somebody has contributed  
>>> patches to gnuplot for a POV-Ray terminal; fancy ray-traced figures  
>>> found here, (http://t-kita.net/gnuplot_povrml/) and the submitted  
>>> patch here, (http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
>>> ).
>>>
>>> I cannot apply this patch successfully to the gnuplot-4.0.0 source? I  
>>> am going like this,
>>>
>>> cp -r gnuplot-4.0.0 gnuplot
>>> cp -r gnuplot gnuplot-patch
>>> mv povray.diff gnuplot
>>> cd gnuplot
>>> patch -p1 < povray.diff
>>>
>>> Anybody have gnuplot and POV-Ray working together?
>>>
>>> Cheers,
>>>
>>> Dan.
>>>
>>>
>>>   
>>>       
>> Hi Daniel,
>>
>> You have found a wonderful peace of work there ! The povray figures that 
>> are given in http://t-kita.net/gnuplot_povrml/ are simply gorgeous. The 
>> two authors, KITA Toshihiro and MIYATA Shigeo, have done something that 
>> others (I included) have probably dreamed of sometimes : let the 
>> terminal driver handle 3D instead of letting gnuplot core do all the 
>> work. Here POV-ray gives a very valuable addition compared to gnuplot 3D 
>> routines : it does true (isometric) perspective, plus realistic shading, 
>> something that is desperately lacking in gnuplot today. There is a patch 
>> on SF.net for adding perspective to gnuplot 3D routines, but the author 
>> did not work on it until inclusion in CVS, and as far as shading (or, 
>> plot points as little spheres, etc), I had never seen such a thing for 
>> gnuplot.
>>
>> There's at least one thing that this work has not achieved according to 
>> the figures : it's pm3d coloring, which is very important for 3d data 
>> visualization. Perspective + shading + pm3d coloring of surfaces plots 
>> would be a great achievement. Let me add that POV-ray, like openGL, is 
>> probably able to draw polygons colored with gradients, something that is 
>> very difficult or impossible with most 2D drawing API (Cairo, for 
>> example, cannot do it). Gradients coloring makes surface plots much 
>> nicer, and gnuplot already has the mechanisms to do that, but they are 
>> used by a single terminal driver, namely the SVGA one, the one that 
>> Ethan never achieved to see working, the one that is also presumably 
>> unsecure. Too bad, isn't it ?
>>
>> Let's talk about the code now.
>> You mention the following patch : 
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
>> . This is not the patch that gave the POV-ray figures. This patch on 
>> SF.net only does 2D rendering, as the author, Gaël Varoquaux, explains 
>> on the page:
>>     
>>> This patch is not terribly iseful as long as the 2D/3D code
>>> in gnuplot is not refactored. This patch only implements the
>>> 2D drawing API (as there is no 3D API currently).
>>>       
>> However, the right patch is provided in 
>> http://t-kita.net/gnuplot_povrml/gnuplot_povrml-0.3.patch
>> First, it is offered as a public domain work, so there is no license 
>> issue. Good.
>> It's not really large:
>>     
>>> # diffstat gnuplot_povrml-0.3.patch
>>>  src/plot2d.c    |   21 ++
>>>  src/plot3d.c    |   19 +
>>>  src/povray.c    |  538 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  src/term.h      |    6
>>>  src/vrml.c      |  399 +++++++++++++++++++++++++++++++++++++++++
>>>  term/povray.trm |  152 +++++++++++++++
>>>  term/vrml.trm   |  151 +++++++++++++++
>>>  7 files changed, 1286 insertions(+)
>>>       
>> However, after a quick glance at the patch, it's not in a state that 
>> would allow it to be included immediately. The authors have bypassed 
>> gnuplot terminal system almost completely, and only 'splot' seems to be 
>> possible.
>>
>> Steps to make that patch better :
>> - make it work with gnuplot CVS,
>> - identify key functions to design an API to extend the current terminal 
>> one in gnuplot.
>> - get full 2D + 3D (maybe mix this patch with Gaël's one)
>>
>> Thanks Daniel for making this work known !
>> Best regards,
>>
>> Timothée Lecomte
>>     
>
>   

Possible problem with CGM terminal

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

I may have stumbled upon a problem with the CGM terminal when using pm3d palettes.  I know this worked properly in older versions.  I'm using a fairly recent CVS snapshot.  The cgm.trm file is revision 1.83.  

When I do the following

set view map
set term cgm solid color
set out 'test.cgm'
splot sin(x) w pm3d

When I import the resulting CGM into PowerPoint I get a solid black area instead of the expected rainbow of color.

I have tried a Solaris and Window build of Gnuplot and get the same result.

Can anyone reproduce this?

Mike Sutton



-- 
Want an e-mail address like mine?
Get a free e-mail account today at www.mail.com!

Re: POV-Ray Terminal

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

On Wednesday 27 February 2008 01:17, Timothée Lecomte wrote:

> The authors have bypassed gnuplot terminal system almost completely,
> and only 'splot' seems to be possible.

To be fair, it is not clear what one should do with a 'plot' command.
There are only 2 coordinates, not 3, and we don't have 3D equivalents
for plot elements like boxes and filledcurves.  The best approach 
might be to run off a 2D plot as a PNG image, and then map the result
into 3D using 'splot ... with image'.

	Ethan



> Daniel Farrell a écrit :
> > Hello,
> >
> > I was listing to the latest FLOSS Weekly Podcast (http://twit.tv/ 
> > floss24) in which the topic was POV-Ray; an open source ray tracing  
> > program. After some idle surfing I found that somebody has contributed  
> > patches to gnuplot for a POV-Ray terminal; fancy ray-traced figures  
> > found here, (http://t-kita.net/gnuplot_povrml/) and the submitted  
> > patch here, (http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
> > ).
> >
> > I cannot apply this patch successfully to the gnuplot-4.0.0 source? I  
> > am going like this,
> >
> > cp -r gnuplot-4.0.0 gnuplot
> > cp -r gnuplot gnuplot-patch
> > mv povray.diff gnuplot
> > cd gnuplot
> > patch -p1 < povray.diff
> >
> > Anybody have gnuplot and POV-Ray working together?
> >
> > Cheers,
> >
> > Dan.
> >
> >
> >   
> Hi Daniel,
> 
> You have found a wonderful peace of work there ! The povray figures that 
> are given in http://t-kita.net/gnuplot_povrml/ are simply gorgeous. The 
> two authors, KITA Toshihiro and MIYATA Shigeo, have done something that 
> others (I included) have probably dreamed of sometimes : let the 
> terminal driver handle 3D instead of letting gnuplot core do all the 
> work. Here POV-ray gives a very valuable addition compared to gnuplot 3D 
> routines : it does true (isometric) perspective, plus realistic shading, 
> something that is desperately lacking in gnuplot today. There is a patch 
> on SF.net for adding perspective to gnuplot 3D routines, but the author 
> did not work on it until inclusion in CVS, and as far as shading (or, 
> plot points as little spheres, etc), I had never seen such a thing for 
> gnuplot.
> 
> There's at least one thing that this work has not achieved according to 
> the figures : it's pm3d coloring, which is very important for 3d data 
> visualization. Perspective + shading + pm3d coloring of surfaces plots 
> would be a great achievement. Let me add that POV-ray, like openGL, is 
> probably able to draw polygons colored with gradients, something that is 
> very difficult or impossible with most 2D drawing API (Cairo, for 
> example, cannot do it). Gradients coloring makes surface plots much 
> nicer, and gnuplot already has the mechanisms to do that, but they are 
> used by a single terminal driver, namely the SVGA one, the one that 
> Ethan never achieved to see working, the one that is also presumably 
> unsecure. Too bad, isn't it ?
> 
> Let's talk about the code now.
> You mention the following patch : 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
> . This is not the patch that gave the POV-ray figures. This patch on 
> SF.net only does 2D rendering, as the author, Gaël Varoquaux, explains 
> on the page:
> > This patch is not terribly iseful as long as the 2D/3D code
> > in gnuplot is not refactored. This patch only implements the
> > 2D drawing API (as there is no 3D API currently).
> 
> However, the right patch is provided in 
> http://t-kita.net/gnuplot_povrml/gnuplot_povrml-0.3.patch
> First, it is offered as a public domain work, so there is no license 
> issue. Good.
> It's not really large:
> > # diffstat gnuplot_povrml-0.3.patch
> >  src/plot2d.c    |   21 ++
> >  src/plot3d.c    |   19 +
> >  src/povray.c    |  538 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  src/term.h      |    6
> >  src/vrml.c      |  399 +++++++++++++++++++++++++++++++++++++++++
> >  term/povray.trm |  152 +++++++++++++++
> >  term/vrml.trm   |  151 +++++++++++++++
> >  7 files changed, 1286 insertions(+)
> However, after a quick glance at the patch, it's not in a state that 
> would allow it to be included immediately. The authors have bypassed 
> gnuplot terminal system almost completely, and only 'splot' seems to be 
> possible.
> 
> Steps to make that patch better :
> - make it work with gnuplot CVS,
> - identify key functions to design an API to extend the current terminal 
> one in gnuplot.
> - get full 2D + 3D (maybe mix this patch with Gaël's one)
> 
> Thanks Daniel for making this work known !
> Best regards,
> 
> Timothée Lecomte

-- 
Ethan A Merritt

Re: POV-Ray Terminal

[Timothée L. <tim...@lp...>]

Daniel Farrell a écrit :
> Hello,
>
> I was listing to the latest FLOSS Weekly Podcast (http://twit.tv/ 
> floss24) in which the topic was POV-Ray; an open source ray tracing  
> program. After some idle surfing I found that somebody has contributed  
> patches to gnuplot for a POV-Ray terminal; fancy ray-traced figures  
> found here, (http://t-kita.net/gnuplot_povrml/) and the submitted  
> patch here, (http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
> ).
>
> I cannot apply this patch successfully to the gnuplot-4.0.0 source? I  
> am going like this,
>
> cp -r gnuplot-4.0.0 gnuplot
> cp -r gnuplot gnuplot-patch
> mv povray.diff gnuplot
> cd gnuplot
> patch -p1 < povray.diff
>
> Anybody have gnuplot and POV-Ray working together?
>
> Cheers,
>
> Dan.
>
>
>   
Hi Daniel,

You have found a wonderful peace of work there ! The povray figures that 
are given in http://t-kita.net/gnuplot_povrml/ are simply gorgeous. The 
two authors, KITA Toshihiro and MIYATA Shigeo, have done something that 
others (I included) have probably dreamed of sometimes : let the 
terminal driver handle 3D instead of letting gnuplot core do all the 
work. Here POV-ray gives a very valuable addition compared to gnuplot 3D 
routines : it does true (isometric) perspective, plus realistic shading, 
something that is desperately lacking in gnuplot today. There is a patch 
on SF.net for adding perspective to gnuplot 3D routines, but the author 
did not work on it until inclusion in CVS, and as far as shading (or, 
plot points as little spheres, etc), I had never seen such a thing for 
gnuplot.

There's at least one thing that this work has not achieved according to 
the figures : it's pm3d coloring, which is very important for 3d data 
visualization. Perspective + shading + pm3d coloring of surfaces plots 
would be a great achievement. Let me add that POV-ray, like openGL, is 
probably able to draw polygons colored with gradients, something that is 
very difficult or impossible with most 2D drawing API (Cairo, for 
example, cannot do it). Gradients coloring makes surface plots much 
nicer, and gnuplot already has the mechanisms to do that, but they are 
used by a single terminal driver, namely the SVGA one, the one that 
Ethan never achieved to see working, the one that is also presumably 
unsecure. Too bad, isn't it ?

Let's talk about the code now.
You mention the following patch : 
http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
. This is not the patch that gave the POV-ray figures. This patch on 
SF.net only does 2D rendering, as the author, Gaël Varoquaux, explains 
on the page:
> This patch is not terribly iseful as long as the 2D/3D code
> in gnuplot is not refactored. This patch only implements the
> 2D drawing API (as there is no 3D API currently).

However, the right patch is provided in 
http://t-kita.net/gnuplot_povrml/gnuplot_povrml-0.3.patch
First, it is offered as a public domain work, so there is no license 
issue. Good.
It's not really large:
> # diffstat gnuplot_povrml-0.3.patch
>  src/plot2d.c    |   21 ++
>  src/plot3d.c    |   19 +
>  src/povray.c    |  538 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  src/term.h      |    6
>  src/vrml.c      |  399 +++++++++++++++++++++++++++++++++++++++++
>  term/povray.trm |  152 +++++++++++++++
>  term/vrml.trm   |  151 +++++++++++++++
>  7 files changed, 1286 insertions(+)
However, after a quick glance at the patch, it's not in a state that 
would allow it to be included immediately. The authors have bypassed 
gnuplot terminal system almost completely, and only 'splot' seems to be 
possible.

Steps to make that patch better :
- make it work with gnuplot CVS,
- identify key functions to design an API to extend the current terminal 
one in gnuplot.
- get full 2D + 3D (maybe mix this patch with Gaël's one)

Thanks Daniel for making this work known !
Best regards,

Timothée Lecomte

POV-Ray Terminal

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

Hello,

I was listing to the latest FLOSS Weekly Podcast (http://twit.tv/ 
floss24) in which the topic was POV-Ray; an open source ray tracing  
program. After some idle surfing I found that somebody has contributed  
patches to gnuplot for a POV-Ray terminal; fancy ray-traced figures  
found here, (http://t-kita.net/gnuplot_povrml/) and the submitted  
patch here, (http://sourceforge.net/tracker/index.php?func=detail&aid=1262281&group_id=2055&atid=302055 
).

I cannot apply this patch successfully to the gnuplot-4.0.0 source? I  
am going like this,

cp -r gnuplot-4.0.0 gnuplot
cp -r gnuplot gnuplot-patch
mv povray.diff gnuplot
cd gnuplot
patch -p1 < povray.diff

Anybody have gnuplot and POV-Ray working together?

Cheers,

Dan.

yet another language that uses gnuplot

[Ralf J. <jue...@cs...>]

FYI, SoftIntegration uses gnuplot as the plotting facility
for its Ch language/programming environment, wrapped in a
proprietary plotting API:
http://www.softintegration.com/products/silib/graphlib/

ralf

Re: fit(timedata)

[<pl...@pi...>]

On Mon, 25 Feb 2008 14:46:56 +0100, <pl...@pi...> wrote:

sorry , posted without checking what I wrote...
> Hi,
>
> I have some time data plotting correctly and need to fit a straight line.
> This seems fine but when I
>
> set timefmt "%H:%M:%S"
> set xdata time
>
> ...
>
> plot fit(x)

c=3;m=-1;
f(x)=x*m+c;
fit f(x) datafile using 1:4 via m,c;

plot datafile  using 1:(($4)/1.0) w l title "resampled DAC output"\
, f(x) with lines title "lin. regression fit"  \
  ;

this gives me a flat line at 1.5 instead of a neg slope from 3.0 If I skip  
the fit call it gives me a flat line at -60000 (appx)

:?


>
> I get y values indicating that it is using integer seconds for x and not
> respecting the xdata setting.
>
> I suppose I could work around it by setting a constant to subtract but
> should this be needed.
>
> The current behaviour seems a bit inconsistant unless I'm mususing it.
>
> Thx, Peter.
>
> -------------------------------------------------------------------------
> 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
>

fit(timedata)

[<pl...@pi...>]

Hi,

I have some time data plotting correctly and need to fit a straight line.  
This seems fine but when I

set timefmt "%H:%M:%S"
set xdata time

...

plot fit(x)

I get y values indicating that it is using integer seconds for x and not  
respecting the xdata setting.

I suppose I could work around it by setting a constant to subtract but  
should this be needed.

The current behaviour seems a bit inconsistant unless I'm mususing it.

Thx, Peter.
 

Re: Patch proposal for config.mgw

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

Hello Petr Mikulik

--- Petr Mikulik <mi...@ph...> wrote:
> It's done (fixed several config/config.xxx files), see ChangeLog.
> Further, I've put recompiled 4.3-cvs binaries (Windows, OS/2, DJGPP)
> at
>     http://gnuplot.sourceforge.net/development/binaries/

I've confirm and dowmload them (Windows, DJGPP).

Thanks!!

Tatsuro


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: pgnuplot+wgnuplot does not accept binary from pipe

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

Hello 

Thank you for your reply.

You are surely right.
However there happned the change by this setting.
This will not be applied to the authorized verion the pgnuplot.

Can I make the special version of pgnuplot for the octave like pgnuplot_oct ?
Of course, the changes are represented by paches and the special version name is attached.

Regards

Tatsuro  

--- Hans-Bernhard Br&#65533;ker <HBB...@t-...> wrote:

> Tatsuro MATSUOKA wrote:
> > Addition of
> > 
> > _setmode(fileno(stdin), _O_BINARY);
> > 
> > is the most essential change. 
> 
> Unfortunately, I'm quite sure this is attacking the wrong side of the 
> problem.  The *source* application has to know if it wants to send 
> binary or text to the pipe.  So it's in its responsibility to change the 
> mode of the pipe.
> 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: Patch proposal for config.mgw

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

> I'll wait the new cvs version of gnuplot sources. 

It's done (fixed several config/config.xxx files), see ChangeLog.

Further, I've put recompiled 4.3-cvs binaries (Windows, OS/2, DJGPP)
at
    http://gnuplot.sourceforge.net/development/binaries/

---
Petr Mikulik

Re: millisecond time format

[<pl...@pi...>]

On Sat, 23 Feb 2008 19:12:09 +0100, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Saturday 23 February 2008 09:58, pl...@pi... wrote:
>> This does however raise another question in my mind. I am mainly using
>> gnuplot in an embedded context using softfloat. If all x coords are
>> treated as double (although not using the fractional part) this mean a  
>> lot
>> of unnecessary float operations at every step of the plot process.
>>
>> Mightn't it be worthwhile my changing this locally to use integer on an
>> integer arch?
>
> On input, data values are stored in a variable of type "coordval",
> which is either float or double depending on the architecture and
> configuration options.   However when the data is used for plotting
> the program switches to using integer coordinates representing
> individual pixels to the precision of the current terminal.
>
> I doubt there is much room for switching to integers any earlier.
>
>

OK! So internal calculation is always float of some sort or another and  
the original question of support for sub-second time resolution once again  
becomes a "simple" question of defining an input specifier and parsing the  
input data.

Thus all plotting and fitting and other functions would account for the  
new precision.

Thanks for the explainations.

Peter.

Re: millisecond time format

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

On Saturday 23 February 2008 09:58, pl...@pi... wrote:
> This does however raise another question in my mind. I am mainly using  
> gnuplot in an embedded context using softfloat. If all x coords are  
> treated as double (although not using the fractional part) this mean a lot  
> of unnecessary float operations at every step of the plot process.
> 
> Mightn't it be worthwhile my changing this locally to use integer on an  
> integer arch?

On input, data values are stored in a variable of type "coordval",
which is either float or double depending on the architecture and 
configuration options.   However when the data is used for plotting
the program switches to using integer coordinates representing 
individual pixels to the precision of the current terminal.

I doubt there is much room for switching to integers any earlier.


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

Re: millisecond time format

[<pl...@pi...>]

On Sat, 23 Feb 2008 00:04:17 +0100, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

>
>> Currently the internal representation of time is an integer number
>> of seconds.
> Not really.  time_t of the Standard C library is an integer, typically
> seconds since 1970-01-01 --- but our own time routines don't use that.
> Instead we use a double to hold seconds since 2000-01-01.


>> So the code can already handle decimal fractions of seconds,

> No.  Nothing in the code is actually prepared to work with fractions of  
> seconds.  Somebody just thought, a >*long* time ago, that the usable  
> range of 32-bit integers was a bit small (viz. the "Y2K37 problem"), and  
> >that most systems' "double" can hold a wider range of integers.


So in effect Ethan was correct. Although stored in a double the value is  
integer and all arithemtic on the value is done as interger and there is  
no support for sub-second resolution in the time formats.

The answer to my original enquiry is "no you can't" and it's all a long  
way off. Shame, you got my hopes up for a minute there. Thanks for  
explaining the state of play.


This does however raise another question in my mind. I am mainly using  
gnuplot in an embedded context using softfloat. If all x coords are  
treated as double (although not using the fractional part) this mean a lot  
of unnecessary float operations at every step of the plot process.

Mightn't it be worthwhile my changing this locally to use integer on an  
integer arch?

Thanks again.

Peter.

Re: millisecond time format

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

pl...@pi... wrote:

> So the code can already handle decimal fractions of seconds,

No.  Nothing in the code is actually prepared to work with fractions of 
seconds.  Somebody just thought, a *long* time ago, that the usable 
range of 32-bit integers was a bit small (viz. the "Y2K37 problem"), and 
that most systems' "double" can hold a wider range of integers.

> it's just a  
> case adding IO specifiers and adjusting the output routines. Is that  
> correct?

No. "Just" isn't even remotely doing justice to the kind of trickery 
needed to keep time/date data handling in a state resembling sanity.

> Would it be much work to add something like the microsecond specifier I  
> suggested and get it to accept a decimal part. (Using %MM:%SS.%UUU takes  
> care of any question of european locales using comma separtors on input.)

It also goes against the grain of the existing format specifications. 
It should have to be "%M:%S:%U" or something like that --- except that 
it can't be %U.  That's taken; see "help time_specifiers".

Re: pgnuplot+wgnuplot does not accept binary from pipe

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

Hi 

I previuosly wrote the mail.
At that time, I think that pgnuplot did not have relation to the matters.
However the pgnuplot have relation to the matter.
This is because the stdin of windows is the windows specific text mode.  
I made a code the following the diff results.

The log results attached as 'temp.dat'

Addition of

_setmode(fileno(stdin), _O_BINARY);

is the most essential change.  Other changes are only for taking the log.

If you have any suggestion to me, please make a reply.

Regards

Tatsuro


**************************************************************
*** pgnuplot.org.c	Sat Apr  8 23:22:48 2006
--- pgnuplota.c	Sat Feb 23 14:58:00 2008
***************
*** 223,235 ****
      LPTSTR  psCmdLine;
      BOOL    bSuccess;
      BOOL    bPersist = FALSE;
!     int	i;
! 
  #if !defined(_O_BINARY) && defined(O_BINARY)
  # define _O_BINARY O_BINARY
  # define _setmode setmode /* this is for BC4.5 ... */
  #endif
!     _setmode(fileno(stdout), _O_BINARY);
  
      for (i = 1; i < argc; i++) {
  	if (!argv[i])
--- 223,235 ----
      LPTSTR  psCmdLine;
      BOOL    bSuccess;
      BOOL    bPersist = FALSE;
!     int	i;   FILE *fp; 
!  
  #if !defined(_O_BINARY) && defined(O_BINARY)
  # define _O_BINARY O_BINARY
  # define _setmode setmode /* this is for BC4.5 ... */
  #endif
!     _setmode(fileno(stdout), _O_BINARY);  _setmode(fileno(stdin), _O_BINARY);
  
      for (i = 1; i < argc; i++) {
  	if (!argv[i])
***************
*** 340,348 ****
  
      /* wait for commands on stdin, and pass them on to the wgnuplot text
       * window */
!     while (fgets(psBuffer, BUFFER_SIZE, stdin) != NULL) {
  	PostString(hwndText, psBuffer);
      }
  
      /* exit gracefully, unless -persist is requested */
      if (!bPersist) {
--- 340,352 ----
  
      /* wait for commands on stdin, and pass them on to the wgnuplot text
       * window */
!      while (fgets(psBuffer, BUFFER_SIZE, stdin) != NULL) {
!         fp=fopen("temp.txt", "ab");    
  	PostString(hwndText, psBuffer);
+         fputs(psBuffer, fp);
+ 	fclose(fp);	     
      }
+         
  
      /* exit gracefully, unless -persist is requested */
      if (!bPersist) {


--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hi 
> 
> In the help of the wgnuplot, Plot-data-BINARY DATA FILES: 
> 
> General binary data can be entered at the command line via the special file name '-'.  However,
> this
> is intended for use through a pipe where programs can exchange binary data, not for keyboards.  
> 
> However this could not be done for  pgnuplot+wgnuplot.
> I sent the data from the octave via pipe to pgnuplot.
> The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot.
> So this phenomenon comes from wgnuplot.
> 
> see the snapshot : wgplt080204.png at
> http://www.geocities.jp/tmgpltwin/Files/Files.htm
> 
> After wgnuplot stopped, it cannot accept code nor keybord anymore.
> 
> If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot.
> 
> Environment
> wgnuplot 4.2.2 on winXP(personal)
> 
> Regards
> 
> Tatsuro
> 
> 
> 
> --------------------------------------
> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> -------------------------------------------------------------------------
> 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
> 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/