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

Re: Compiling

[Alexandre F. <o.a...@gm...>]

I downloaded the source in a zip file from the web-based svn in the
sourceforge.
The purpose to build gnuplot for windows is that i want include a feature
there. It is a simple
one, predict discontinuities on function interavals, would you tried
plotting 1/x with lines? my intention is create some stuff to handle
discontinuities, and then improve the automatic
choose for ploting range in fundamental singularities points, since it
should be not be
displayed anyway, it's not smart grow the range to view every points, more
over, if the
function have mor than one singularity in usually one of then determines the
plotting range
and the other are not ocuppying all the chart area. When this issue is
resolved, is time to hack 3D charts.
The main problem i am facing is that i have a little experience on
conpilling projects from
source, i would like to learn more about, but my time is sparse, my use of
open source
where run the compiled programs, or learn some programming tecnics to apply
in my
programs, that are generaly for particular use.
I still don't know  how it works but what i will need is only one terminal
say wxt (i have
already the wxWidgets configured in my machine). For my purpose i could
disable all-1
terminals, and plot only 1d functions in 2d space, because my first change
is in the valuation of functions. Could someone having a windows compiling
version send-me only the important archives preferably reducing the
dependency from other souces, i repeat, i'm not a compiler expert, please be
understanding, I use code::blocks, if some can create a code::blocks project
and put it working, even if with limited features, i would be grateful.
In the "binary" dir there are several .dll, using it in some way with the
linker is not enough?

Re: Compiling

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

Hello

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> What is purpose to build gnuplot on windows? 
> If you want to use cvs version, I am continuing distribute the binary on my web.
> 
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> 
> If you want to build by yourself from other reason, you have to prepare a lot of dependencies
> (libpng,
> jpeg, gd, freetype, fontconfig, cairo, pango, iconv, intl, and wx).
> Some libraries are available on the web site but some libraries should be built by  yourself.
> 
> Regards
> 
> Tatsuro
>  
> 
> 
> --- Alexandre Felipe  wrote:
> > One Problem:
> > I can't compile. i use gcc 3.4.5 i tried using mingw32-make, it says
> > "Nothing to be done for ..."
> > who can help me, this questions
> > 

Current Makefile.mgw requires to use the Msys + MinGW toolchain and thus requires the Msys make but
not mingw32-make.
It is logically possible to use mingw32-make but you have to modify path name handling.

BTW,

1. You also have to get the pkg-config command working on the if you want to use the cairo based
terminals
(pngcairo, pdfcairo and wxt terminals.) 

2. I myself could not built the gnuplot for a long time. 
But now I am building it about twice per a week.
It is not easy way to build gnuplot on windows but you can do it if you strongly hope to do it.

3. I personally use GCC-4.5.0 but not 3.4.5 on the MinGW from the performance reason.

Good Luck

Tatsuro

Regards

--------------------------------------
Let's write special new year cards!
- Yahoo! JAPAN  Nengajo 2011 Special Site -
http://pr.mail.yahoo.co.jp/nenga2011/

Re: Compiling

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

Hello

What is purpose to build gnuplot on windows? 
If you want to use cvs version, I am continuing distribute the binary on my web.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

If you want to build by yourself from other reason, you have to prepare a lot of dependencies (libpng,
jpeg, gd, freetype, fontconfig, cairo, pango, iconv, intl, and wx).
Some libraries are available on the web site but some libraries should be built by  yourself.

Regards

Tatsuro
 


--- Alexandre Felipe  wrote:

> *In Reply to sfeam*
> Ok, i am subscribed in the mailing list, and my first try was send it
> through it.
> Since i have not received back my mail, i though that it would be a solution
> post
> here in the forum.
> 
> *New questions*
> i will slowly understand the svn, because i am a windows user, that code
> alone, only small tasks
> except in my university research project, where the task is not small, but
> still i code alone.
> 
> One Problem:
> I can't compile. i use gcc 3.4.5 i tried using mingw32-make, it says
> "Nothing to be done for ..."
> who can help me, this questions
> 
> I don't received any mail from this list, there are something wrong (I have
> enabled the mail delivery)
> > ------------------------------------------------------------------------------
> This SF Dev2Dev email is sponsored by:
> 
> WikiLeaks The End of the Free Internet
> http://p.sf.net/sfu/therealnews-com> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Learn more about HIV/AIDS - Red Ribbon Campaign 2010
http://pr.mail.yahoo.co.jp/redribbon/

Re: Compiling

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

Alexandre Felipe wrote:

> One Problem:
> I can't compile. i use gcc 3.4.5 i tried using mingw32-make, it says 
> "Nothing to be done for ..."
> who can help me, this questions

Perhaps you are missing some files or the path is not correct.  Please provide more details Alexandre.  Send a block copy of the output of the compile process (so long as it is reasonably small) so we can tell the where/when/why of it stopping.

Dan

Compiling

[Alexandre F. <o.a...@gm...>]

*In Reply to sfeam*
Ok, i am subscribed in the mailing list, and my first try was send it
through it.
Since i have not received back my mail, i though that it would be a solution
post
here in the forum.

*New questions*
i will slowly understand the svn, because i am a windows user, that code
alone, only small tasks
except in my university research project, where the task is not small, but
still i code alone.

One Problem:
I can't compile. i use gcc 3.4.5 i tried using mingw32-make, it says
"Nothing to be done for ..."
who can help me, this questions

I don't received any mail from this list, there are something wrong (I have
enabled the mail delivery)

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Stanislav M. <sta...@gm...>]

On Tue, Dec 07, 2010 at 09:39:05PM +0100, Hans-Bernhard Bröker wrote:
> On 07.12.2010 16:42, Stanislav Maslovski wrote:
> 
> >So, I solved this issue by patching pm3d.c:pm3d_depth_queue_flush()
> >so that sorting of quadrangles was done based on the average depth of
> >4 corners.
> 
> Unfortunately that's not really a solution.  There is no particular
> reason to prefer one sorting criterion over the other.  Painter's
> algorithm is plain and simply wrong --- no matter which property you
> sort by.  If it appears to work sometimes that's by happenstance, not
> by design.

Yes, I agree completely. "Solved" above meant that it helped me to
produce a reasonable result in a reasonable time, and nothing more.
>From what I have read from the docs it seems that the developers are
against of impelementing a better algorithm (I noticed a statement
like gnuplot is not a virtual reality software therefore...).

If that is the current position, then I think it would be reasonable
at least to make the depth sorting algorith configurable, do not you
think so?

-- 
Stanislav

Discontinuities

[Alexandre F. <o.a...@gm...>]

Hello, my name is Alexandre Felipe, well known as Bobby, i study Electrical
Engeneering in the UDESC, South Brazil.
I have experienced some problems with discontinuous functions, for a
software
with so many features like gnuplot, i think, it isn't acceptable that 1/x
need to be
 ploted by parts with several tricks.

I'm contacting you for asking or offering a solution.

I would be glad by helping the development of the gnuplot. Therefor i will
need
 some time to understand the engine, since i have just downloaded the source
 code of the 4.4.2 version. Since just today i figured that i could become
myself
a member of the gnuplot development group.

I have two main ideas about how implement this, i have subscribed in this
group

i'm awaiting.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

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

On 07.12.2010 16:42, Stanislav Maslovski wrote:

> So, I solved this issue by patching pm3d.c:pm3d_depth_queue_flush()
> so that sorting of quadrangles was done based on the average depth of
> 4 corners.

Unfortunately that's not really a solution.  There is no particular 
reason to prefer one sorting criterion over the other.  Painter's 
algorithm is plain and simply wrong --- no matter which property you 
sort by.  If it appears to work sometimes that's by happenstance, not by 
design.

Re: errorbar

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

On 24.11.2010 12:52, Tomáš Zajíc wrote:

> please do you know if it's possible to make errorbars in gnuplot dotted
> or dashed instead of line style?

The same way you make lines in 'with lines' style dotted or dashed: 
specify the linetype explicitly.

Re: errorbar

[Tomáš Z. <tom...@se...>]

Hello,

please do you know if it's possible to make errorbars in gnuplot dotted 
or dashed instead of line style?

Thank you in advance,
Tomas Zajic

Re: bug in pm3d.c

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

On Monday, November 22, 2010 02:07:08 pm don taber wrote:
> pm3d.c in current CVS does not compile if EXTENDED_COLOR_SPECS
> is defined.  Below is the patch I fixed it with. Someone who 
> actually understands the code should verify that it is the 
> correct fix and everything is initialized that needs to be.

I think you need a bit more than that, reverting also part of the
code simplification patch of 2010-10-12.
Slightly larger patch attached.
 
> Am I the last person in the world using the vgagl terminal ? :-)

Could be :-)

Going back all the way to version 4.0, so about size years now,
I have totally failed to build a version of gnuplot that uses the
vga/vgagl/linux console terminal drivers for anything other than to
lock up my video card.  There must be some trick to configuring
things, but it has defeated me every time I'm attempted it.

Strangely, the vgagl driver doesn't give any hint in the code
or docs that it requires EXTENDED_COLOR_SPECS.  
It might be worth adding a configuration note somewhere.


> pm3d sure looks good on it.

Could you maybe provide a screenshot?

> 
> Don Taber

bug in pm3d.c

[don t. <dt...@to...>]

pm3d.c in current CVS does not compile if EXTENDED_COLOR_SPECS
is defined.  Below is the patch I fixed it with. Someone who 
actually understands the code should verify that it is the 
correct fix and everything is initialized that needs to be.

Am I the last person in the world using the vgagl terminal ? :-)
pm3d sure looks good on it.

Don Taber
--------------------------------

--- pm3d.c.orig	2010-10-13 04:00:11.000000000 -0700
+++ pm3d.c	2010-11-22 13:48:50.000000000 -0800
@@ -390,7 +390,11 @@
 	    set_color(qp->gray);
 	    if (pm3d.hidden3d_tag < 0)
 		pm3d_border_lp.pm3d_color = *(qp->border_color);
+#ifdef EXTENDED_COLOR_SPECS
+	    filled_quadrangle(qp->corners, qp->icorners);
+#else
 	    filled_quadrangle(qp->corners);
+#endif
 	}
     }
 

Re: How to plot a 3D histogram ?

[jacob c. <jac...@ro...>]

> 
> On Wed, 2010-10-06 at 14:33 +0200, Le-Berre, Francois wrote:
> > Hello,
> > 
> > I would like to know if it possible to plot a 3D histogram (GNUPLOT
> > version 4.2, under windows). 
> > 
> > My need is the following : i want to plot in Z a signal level per CCD
> > pixel, in X the X_pixel index, in Y the y_pixel index of the CCD
> > sensor.
> > 
> 
> did you get any inspiration from this page:
> 
> http://www.gnuplot.info/demo/surface1.html
> 
> ?
> 
> richard,


Hi,

I hope you can help? did you get anywhere with this I need something similar...

http://www.bmsc.washington.edu/people/merritt/gnuplot/lacI_variant3.png

looking at examples it doesn't look impossible but I cannot find a script that I 
can use.

thanks

Jacob

Re: gnuplot 4.4

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

On 12.11.2010 14:46, Kabir Humayun wrote:
> Why is the screendump not working in gnuplot 4.4 version?

The screendump command only exists in the native MS Windows terminal 
driver.  As of version 4.4, the default terminal driver in gnuplot for 
Windows is WXT.  It doesn't have this command.

hShell32 = LoadLibrary(TEXT("shell32.dll")) in appdata_directory(void) in winmain.c

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

Hello

In the gnuplot thread in Japan, the topic of the DLL Preloading Attack in the gnuplot for windows,
have been discussed

In winmain.c, the function

GetDllVersion(LPCTSTR lpszDllName)

is defined.

In the function, the below is the decribed
    /* For security purposes, LoadLibrary should be provided with a
       fully-qualified path to the DLL. The lpszDllName variable should be
       tested to ensure that it is a fully qualified path before it is used. */


However, in function 
appdata_directory(void)

I found 
    hShell32 = LoadLibrary(TEXT("shell32.dll"));

GetDllVersion(LPCTSTR lpszDllName) is not used for this code.

However, in winmenu.c, I found

if (GetDllVersion(TEXT("shell32.dll")) >= PACKVERSION(4,0)) {

Is it better to carry out similar check for    hShell32 = LoadLibrary(TEXT("shell32.dll"));
in the function appdata_directory(void) ?


Or am I misleading the situation ?



BTW,
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Windows XP and Windows 2000 with SP4:  Safe DLL search mode is disabled by default. To enable this
feature, create the SafeDllSearchMode registry value and set it to 1. Safe DLL search mode is enabled
by default starting with Windows XP with Service Pack 2 (SP2).
Windows 2000:  The SafeDllSearchMode value is not supported. The DLL search order is identical to the
search order that occurs when safe DLL search mode is disabled. The SafeDllSearchMode value is
supported starting with Windows 2000 with SP4.



1.The directory from which the application loaded.
2.The system directory. Use the GetSystemDirectory function to get the path of this directory.
3.The 16-bit system directory. There is no function that obtains the path of this directory, but it is
searched.
4.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5.The current directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include
the per-application path specified by the App Paths registry key. The App Paths key is not used when
computing the DLL search path.

Perhaps most win XP users uses XP sp3, so that
    hShell32 = LoadLibrary(TEXT("shell32.dll"));
may not be a problem.

However, for windows 2000, "The SafeDllSearchMode value is supported starting with Windows 2000 with
SP4." However, SafeDllSearchMode is disabled in windows 2000 sp4.

Therefore,     hShell32 = LoadLibrary(TEXT("shell32.dll")); may not be secure only for users of
windows 2000.


Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

gnuplot 4.4

[Kabir H. <hum...@ya...>]

Why is the screendump not working in gnuplot 4.4 version? For this reason,  I 
cannot print a plot directly. I am running the program on win xp. The screendump 
code works fine in the old version.


      

Re: Puzzling aspect of logscale implementation

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

On Saturday, November 06, 2010, Hans-Bernhard Bröker wrote:
> On 06.11.2010 00:16, Ethan Merritt wrote:
> > On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:
> 
> >> And it would appear to happen so late to allow implementing the
> >> 'islog_override' argument for AXIS_INIT3D.
> 
> > That doesn't seem relevant.  The islog_override flag turns off log scaling
> > for 3D parametric axes [which can never be turned on anyhow so the whole
> > mechanism seems unnecessary...].
> 
> Well, for what it's worth, 'fit' does run AXIs_INIT3D of the u and v 
> axes with the override turned off...

Are you saying that the 3D fit code uses, or can use, log scale on
a parametric variable?  What does that even mean?  
Can you suggest a test case that I should check before removing what
seems to be an unused block of code?





> 
> >> OTOH, none of the code using log_base is or ever was meant to be used
> >> before AXIS_INIT* anyway, so it's not really out of sync.
> 
> > Sure.  But now I do have a reason to use it before a plot command is issued.
> > Hence the problem.
> 
> So maybe whatever that undisclosed reason actually is needs to be 
> handled differently.
> 
> >> No, it shouldn't.  Precisely because it's never legal for a log axis,
> >> it's just about the perfect signal for "this axis is not logarithmic".
> 
> > It could have been used that way as a signal.  But it isn't.
> 
> But setting it to a "legal" value like log(10) would kill the option of 
> using it that way for good.  I fail to see how that's any better.
> 

Re: Puzzling aspect of logscale implementation

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

On 06.11.2010 00:16, Ethan Merritt wrote:
> On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:

>> And it would appear to happen so late to allow implementing the
>> 'islog_override' argument for AXIS_INIT3D.

> That doesn't seem relevant.  The islog_override flag turns off log scaling
> for 3D parametric axes [which can never be turned on anyhow so the whole
> mechanism seems unnecessary...].

Well, for what it's worth, 'fit' does run AXIs_INIT3D of the u and v 
axes with the override turned off...

>> OTOH, none of the code using log_base is or ever was meant to be used
>> before AXIS_INIT* anyway, so it's not really out of sync.

> Sure.  But now I do have a reason to use it before a plot command is issued.
> Hence the problem.

So maybe whatever that undisclosed reason actually is needs to be 
handled differently.

>> No, it shouldn't.  Precisely because it's never legal for a log axis,
>> it's just about the perfect signal for "this axis is not logarithmic".

> It could have been used that way as a signal.  But it isn't.

But setting it to a "legal" value like log(10) would kill the option of 
using it that way for good.  I fail to see how that's any better.

Re: Puzzling aspect of logscale implementation

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

On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:
> On 05.11.2010 19:50, Ethan Merritt wrote:
> > I have encountered a problem while trying to predict or adjust axis scaling
> > in advance of actually issuing a plot command.   The problem is that the
> > "set log" command sets the field AXIS.base, but the corresponding field
> > log_base is not initialized until a subsequent plot command invokes the
> > macro AXIS_INIT2D.   Instead it is set to zero.
> 
> It's _initialized_ to zero.  It's set to zero only by the AXIS_INIT*D 
> macros themselves, and that only if the axis is not logscaled.
> 
> And it would appear to happen so late to allow implementing the 
> 'islog_override' argument for AXIS_INIT3D.

That doesn't seem relevant.  The islog_override flag turns off log scaling
for 3D parametric axes [which can never be turned on anyhow so the whole
mechanism seems unnecessary...]. It does this independent of the previous values
of either AXIS.base or AXIS.log_base, so it shouldn't care about whether or not
they were properly initialized earlier as well.

> > Why would you ever want to have AXIS.log_base out of sync with AXIS.base?
> 
> Well, that "you" might be me, I guess.  I started axis.[ch] as a 
> renovation project.  That was finished by the release of gnuplot 3.8e, 
> exactly 10 years ago this week.  But most of that code I just refactored 
> from lots of individual arrays (min_array[], log_base_array[], ...) into 
> a single array of structs, so the code you're looking at is actually 
> even older than that.
> 
> OTOH, none of the code using log_base is or ever was meant to be used 
> before AXIS_INIT* anyway, so it's not really out of sync.

Sure.  But now I do have a reason to use it before a plot command is issued.
Hence the problem.
 
> > Can anyone think of a reason why it isn't correct to always set log_base
> > at the same time the base itself is set?  I.e.,  on every call to "set log".
> 
> One part of the problem is: what value do you set it to when the axis is 
> _not_ logarithmic?  In theory, it would have to be negative infinity --- 
> but that can't be done reliably.  Zero is the next best thing.
> > And everywhere that it is set to zero should be removed, since zero is
> > never a legal value.
> 
> No, it shouldn't.  Precisely because it's never legal for a log axis, 
> it's just about the perfect signal for "this axis is not logarithmic". 

It could have been used that way as a signal.  But it isn't.
As I already noted, no place in the current code tests the value of log_base.
Instead there is a separate boolean flag AXIS.log, which is a cleaner
solution.

So - historical artifact.  That's fine. I just wanted to check if I had
missed something.

	Ethan

Re: Puzzling aspect of logscale implementation

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

On 05.11.2010 19:50, Ethan Merritt wrote:
> I have encountered a problem while trying to predict or adjust axis scaling
> in advance of actually issuing a plot command.   The problem is that the
> "set log" command sets the field AXIS.base, but the corresponding field
> log_base is not initialized until a subsequent plot command invokes the
> macro AXIS_INIT2D.   Instead it is set to zero.

It's _initialized_ to zero.  It's set to zero only by the AXIS_INIT*D 
macros themselves, and that only if the axis is not logscaled.

And it would appear to happen so late to allow implementing the 
'islog_override' argument for AXIS_INIT3D.

> Why would you ever want to have AXIS.log_base out of sync with AXIS.base?

Well, that "you" might be me, I guess.  I started axis.[ch] as a 
renovation project.  That was finished by the release of gnuplot 3.8e, 
exactly 10 years ago this week.  But most of that code I just refactored 
from lots of individual arrays (min_array[], log_base_array[], ...) into 
a single array of structs, so the code you're looking at is actually 
even older than that.

OTOH, none of the code using log_base is or ever was meant to be used 
before AXIS_INIT* anyway, so it's not really out of sync.

> Can anyone think of a reason why it isn't correct to always set log_base
> at the same time the base itself is set?  I.e.,  on every call to "set log".

One part of the problem is: what value do you set it to when the axis is 
_not_ logarithmic?  In theory, it would have to be negative infinity --- 
but that can't be done reliably.  Zero is the next best thing.

> And everywhere that it is set to zero should be removed, since zero is
> never a legal value.

No, it shouldn't.  Precisely because it's never legal for a log axis, 
it's just about the perfect signal for "this axis is not logarithmic". 
And since axes are non-logarithmic by default, that's the right initial 
value.

Puzzling aspect of logscale implementation

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

I have encountered a problem while trying to predict or adjust axis scaling
in advance of actually issuing a plot command.   The problem is that the
"set log" command sets the field AXIS.base, but the corresponding field
log_base is not initialized until a subsequent plot command invokes the
macro AXIS_INIT2D.   Instead it is set to zero.
So until you actually issue a plot command, anything that tries to use
the macros AXIS_DO_LOG or AXIS_UNDO_LOG triggers a
divide by zero or other error because AXIS.log_base is 0.

Why would you ever want to have AXIS.log_base out of sync with AXIS.base?

Why is it reset to zero in several places?  Zero is never a correct value
to use in applying the log scale, and I don't see any place in the code
that uses zero/non-zero as a flag to control something else.

Can anyone think of a reason why it isn't correct to always set log_base
at the same time the base itself is set?  I.e.,  on every call to "set log".

And everywhere that it is set to zero should be removed, since zero is
never a legal value.  If an initialization value is needed,  log(10) makes
a whole lot more sence than 0.

So, proposed patch:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/set.c   2010-10-11 14:30:23.000000000 -0700
+++ gnuplot-new/src/set.c       2010-11-05 11:43:27.000000000 -0700
@@ -2229,6 +2229,7 @@ set_logscale()
 	        if (set_for_axis[axis]) {
                axis_array[axis].log = TRUE;
                axis_array[axis].base = newbase;
+               axis_array[axis].log_base = log(newbase);
            }
         }
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Anyone see a problem with this?

	Ethan

gnuplot manual misprint (no.34)

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

shige 11/02 2010
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.633 2010/10/27 04:25:12 sfeam Exp $

I found the following misprints. 

----- From here -----
--- gnuplot.doc.ORG	2010-11-02 19:38:42.000000000 +0900
+++ gnuplot.doc	2010-11-02 19:42:00.000000000 +0900
@@ -7529,7 +7529,7 @@
         plot 'datafile' using 1:2, f(x)
 
  By default the information written to the log file is also echoed to
- the terminal session.  "set fit quiet" turns off the echo.
+ the terminal session. `set fit quiet` turns off the echo.
 3 fontpath
 ?commands set fontpath
 ?commands show fontpath
@@ -9373,7 +9373,7 @@
  A pm3d color surface is drawn if the splot command specifies `with pm3d`,  
  if the data or function `style` is set to pm3d globally, or if the pm3d mode is
  `set pm3d implicit`.  In the latter two cases, the pm3d surface is draw in
- addition to the mesh produced byt the style specified in the plot command. E.g.
+ addition to the mesh produced by the style specified in the plot command. E.g.
        splot 'fred.dat' with lines, 'lola.dat' with lines
  would draw both a mesh of lines and a pm3d surface for each data set.
  If the option `explicit` is on (or `implicit` is off) only plots specified
@@ -9383,7 +9383,7 @@
 
  On gnuplot start-up, the mode is `explicit`. For historical and compatibility
  reasons, the commands `set pm3d;` (i.e. no options) and `set pm3d at X ...`
- (i.e.  `at` is the first option) set change the mode to `implicit`.
+ (i.e.  `at` is the first option) change the mode to `implicit`.
  The command `set pm3d;` sets other options to their default state.
 
  If you set the default data or function style to `pm3d`, e.g.:
@@ -11471,7 +11471,7 @@
  within [-1000:1000]
        set xrange [-1000<*:*<1000]
 
- Make sure xmin is somwehere between -200 and 100:
+ Make sure xmin is somewhere between -200 and 100:
        set xrange [-200<*<100:]
 
 3 xtics
----- To here -----

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

Re: pm3d.dem fails on the cvs source (4.5) 2010-10-26

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

Hello

I have confirmed the fix and updated the binary distribution of cvs version on the cygwin and mingw.

Thanks!!

Tatsuro

--- Ethan Merritt wrote:

> On Wednesday, October 27, 2010 05:05:07 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have built gnuplot binaries from the cvs source at 2010-10-26.
> > 
> > I have met an error at pm3d.dem
> > 
> > gnuplot> set style rectangle back fc lt -3 fillstyle   solid 1.00 border lt -1
> >                                                                          ^
> >          line 816: Unrecognized or duplicate option
> 
> Yes. I found the same thing this morning.
> Yesterday's fix for "plot ... with ... fillstyle border"
> did not work correctly for "set style fill border".
> I think it is working again now.
> 
> 	Ethan
> 
> 
> 
> > 
> > The above happened on gnuplot on cygwin and windows.
> > 
> > I have tested on gnuplot 4.4.0. No error was occurred.
> > 
> > Perhaps the change
> > 
> > 	* src/plot3d.c src/misc.c:  Simplify calls to load_linetype() 
> > 
> > may be origin of the error.
> > 
> > Is this a bug ? Or is the pm3d.dem script need to be modified ?
> > 
> > Regards
> > 
> > Tatsuro
> >   
> > 
> > --------------------------------------
> > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> > http://pr.mail.yahoo.co.jp/ie8/
> > 
> > ------------------------------------------------------------------------------
> > Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> > Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> > http://p.sf.net/sfu/nokia-dev2dev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: pm3d.dem fails on the cvs source (4.5) 2010-10-26

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

On Wednesday, October 27, 2010 05:05:07 pm Tatsuro MATSUOKA wrote:
> Hello
> 
> I have built gnuplot binaries from the cvs source at 2010-10-26.
> 
> I have met an error at pm3d.dem
> 
> gnuplot> set style rectangle back fc lt -3 fillstyle   solid 1.00 border lt -1
>                                                                          ^
>          line 816: Unrecognized or duplicate option

Yes. I found the same thing this morning.
Yesterday's fix for "plot ... with ... fillstyle border"
did not work correctly for "set style fill border".
I think it is working again now.

	Ethan



> 
> The above happened on gnuplot on cygwin and windows.
> 
> I have tested on gnuplot 4.4.0. No error was occurred.
> 
> Perhaps the change
> 
> 	* src/plot3d.c src/misc.c:  Simplify calls to load_linetype() 
> 
> may be origin of the error.
> 
> Is this a bug ? Or is the pm3d.dem script need to be modified ?
> 
> Regards
> 
> Tatsuro
>   
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

pm3d.dem fails on the cvs source (4.5) 2010-10-26

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

Hello

I have built gnuplot binaries from the cvs source at 2010-10-26.

I have met an error at pm3d.dem

gnuplot> set style rectangle back fc lt -3 fillstyle   solid 1.00 border lt -1
                                                                         ^
         line 816: Unrecognized or duplicate option

The above happened on gnuplot on cygwin and windows.

I have tested on gnuplot 4.4.0. No error was occurred.

Perhaps the change

	* src/plot3d.c src/misc.c:  Simplify calls to load_linetype() 

may be origin of the error.

Is this a bug ? Or is the pm3d.dem script need to be modified ?

Regards

Tatsuro
  

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/