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

Re: utf-8 description (specify to use utf-8 without BOM)

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, January 25, 2011, Mojca Miklavec wrote:
> I don't know enough about gnuplot's source, so I don't know how
> difficult it is to change it, but if there is no problem to support
> comments (in both data files and scripts), I don't see why ignoring
> the first two bytes would not be doable. I consider it "equally hard".

If you want to experiment with that approach,  you can find the
relevant switch statement at line 201 of scanner.c (scanner):

            switch (expression[current]) {
            case '#':           /* DFK: add comments to gnuplot */
                goto endline;   /* ignore the rest of the line */
            case '^':
            case '+':

That isn't going to help with data files, however.
Only with command lines that unexpectedly contain the BOM sequence.

Re: utf-8 description (specify to use utf-8 without BOM)

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

On Tuesday, January 25, 2011, Mojca Miklavec wrote:
> On Tue, Jan 25, 2011 at 03:12, Allin Cottrell wrote:
> >
> > I'm not sure I'd call this a "fix". Wikipedia says of the BOM in
> > UTF-8:
> >
> > "While Unicode standard allows BOM in UTF-8, it does not require
> > or recommend it.

That same Wikipedia paragraph goes on to say:
   The BOM will make a batch file not executable on Windows, so batch
   files must be saved as ANSI, not Unicode[...] On any platform, 
   a UTF-8 BOM will interfere with the interpretation of source code
   for compiler and tools that don't recognise it but could otherwise
   handle UTF-8. 

> However ... this has to be read as: gnuplot is not required to
> *output* files with BOM (and thus doesn't need to be fixed to create
> BOM marks in output), but it should better support them when *opening*
> external files. Even if the marks are not required by the standard,
> they are still there. Even worse ... from what some people here say
> they are even there by default in some standard Windows tools.

It is worse than you may think.  Notepad cannot even read _it's own files_
reliably. I'm sure you can find many discussions on Notepad and the BOM
problem via Google;  here are pointers to a couple: 
   http://www.eeggs.com/items/48383.html 
   http://www.datamystic.com/forums/viewtopic.php?t=586 
   
Best to view it as some Windows-specific craziness that must be
stripped from the file when transferring it to unix/linux, exactly
the same as we must strip the extra ^M at the end of every line.

I realize that may leave you with a problem if you are both creating
and using the files on Windows, but I do not have a good solution for
that.  I did come across several recommendations to replace Notepad with
Notepad++, which offers the option to edit and save UTF-8 files without
adding a BOM.

It's not just the script files, by the way.  The same problem with
presence or absence of a BOM applies to data files as well, including
so far as I know binary files.  So if you are unlucky enough to have
a binary data file that just happens to contain the BOM bit pattern at
the start, many Windows tools will handle it incorrectly.

> (But once again: I don't know the source good enough, so I have no
> idea how difficult it would be to fix that particular behaviour.)

A check for BOM would have to be made every time a file is opened.
So it might have to be handled in the readline library, and/or by providing
a custom fopen() routine.  But even that wouldn't help if you fed the
input file to gnuplot via
    gnuplot < my-file-with-BOM.gp

Re: utf-8 description (specify to use utf-8 without BOM)

[Mojca M. <moj...@gm...>]

On Tue, Jan 25, 2011 at 03:12, Allin Cottrell wrote:
>
> I'm not sure I'd call this a "fix". Wikipedia says of the BOM in
> UTF-8:
>
> "While Unicode standard allows BOM in UTF-8, it does not require
> or recommend it.

However ... this has to be read as: gnuplot is not required to
*output* files with BOM (and thus doesn't need to be fixed to create
BOM marks in output), but it should better support them when *opening*
external files. Even if the marks are not required by the standard,
they are still there. Even worse ... from what some people here say
they are even there by default in some standard Windows tools.

Mojca

(But once again: I don't know the source good enough, so I have no
idea how difficult it would be to fix that particular behaviour.)

Re: utf-8 description (specify to use utf-8 without BOM)

[Mojca M. <moj...@gm...>]

On Mon, Jan 24, 2011 at 23:57, Ethan A Merritt wrote:
> On Monday, January 24, 2011 02:21:34 pm Mojca Miklavec wrote:
>> On Mon, Jan 24, 2011 at 23:11, Tatsuro MATSUOKA wrote:
>> > Hello
>> >
>> > gnuplot only accepts utf-8 without the BOM (Byte Oder Mark) but not that with the BOM.
>> >
>> > I think it is better to mention it in a proper position  in the manual
>>
>> Or even better: to fix the source code :)
>
> You mean the source code for Notepad?

I understand that that was sarcasm, but still ...

BOM is allowed by the standard. One could argue that Notepad could
offer a few more advanced settings, but it is definitely not
misbehaving, while gnuplot *is* misbehaving according to the standard
if it doesn't accept and ignore the BOM mark.

2011/1/25 Tatsuro MATSUOKA wrote:
>
> When script saved in utf-8 with BOM , bit order marks are attached to the script contests.
> I think that it is not practical to rewrite gnuplot code to accept the script with the utf-8 with BOM.

I don't know enough about gnuplot's source, so I don't know how
difficult it is to change it, but if there is no problem to support
comments (in both data files and scripts), I don't see why ignoring
the first two bytes would not be doable. I consider it "equally hard".

It might be even less practical for users to do dirty tricks to remove
BOM marks from their files. Source code needs to be fixed just once,
while users need to repeat the process over and over again. I never
had any problem with BOM marks, so I don't know how serious problem
that presents in practice.

Mojca

PS: I definitely have to give a compliment about a really nice
surprize to see unicode work almost satisfactory with the latest wxt
terminal in windows (compared to the old one with its own console) ...
It could still be improved (supporting the whole range of unicode as
opposed to just a subset that corresponds to local codepage; and using
unicode automatically/by default), but it is already lightyears ahead
of what it was before that change. This tiny change with BOM seems
nothing compared to the horrible zero-nonascii-support before the new
terminal.

Re: utf-8 description (specify to use utf-8 without BOM)

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

Hello Allin

--- Allin Cottrell  wrote:

> I'm not sure I'd call this a "fix". Wikipedia says of the BOM in
> UTF-8:
> 
> "While Unicode standard allows BOM in UTF-8, it does not require
> or recommend it. Byte order has no meaning in UTF-8 so a BOM only
> serves to identify a text stream or file as UTF-8 or that it was
> converted from another format that has a BOM."
> 
> Some MS Windows applications add these redundant bytes to UTF-8
> files but "proper" UTF-8 gets by fine without them.

Thanks for explanation. 

All text editors I have used in MS-windows seem to add byte when files are used in utf-8 with the BOM
format. Script files with saved the BOM have not ever be able to use.

Even if this phenomenon is specific to the MS-windows, 
this fact is to be better to mention in somewhere.

I think it is better to mention it in gnuplot.doc (i.e. manual and help) .
Another candidate is FAQ, I think.  

My preference is the gnuplot.doc but I'm not against that this issue is described in the FAQ or some
other places.  What is important is that users easy get to know that scripts written in the utf-8 with
the BOM format cannot be used gnuplot on windows.

Regards

Tatsuro

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

Re: utf-8 description (specify to use utf-8 without BOM)

[Allin C. <cot...@wf...>]

On Tue, 25 Jan 2011, Tatsuro MATSUOKA wrote:

> --- Mojca Miklavec wrote:
>
> > On Mon, Jan 24, 2011 at 23:11, Tatsuro MATSUOKA wrote:
> > >
> > > gnuplot only accepts utf-8 without the BOM (Byte Oder Mark)
> > > but not that with the BOM.
> > >
> > > I think it is better to mention it in a proper position
> > > �in the manual
> >
> > Or even better: to fix the source code :)

I'm not sure I'd call this a "fix". Wikipedia says of the BOM in
UTF-8:

"While Unicode standard allows BOM in UTF-8, it does not require
or recommend it. Byte order has no meaning in UTF-8 so a BOM only
serves to identify a text stream or file as UTF-8 or that it was
converted from another format that has a BOM."

Some MS Windows applications add these redundant bytes to UTF-8
files but "proper" UTF-8 gets by fine without them.

Allin Cottrell

Re: hidden3d plot in current cvs source

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

Hello

I have confirmed the fix and uploaded binaries on my website.

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

Regards

Tatsuro

--- Ethan A Merritt  wrote:

> On Monday, January 24, 2011 01:57:53 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Thank you for your reply
> > Now I am building using new snapshot.
> > 
> > I have noticed that the latest changelog date
> > is 2011-01-20. Is this 2011-01-24?
> 
> Oops.  Yes.  (well, it was 2011-01-23 on this side of the dateline)
> 
> 
> 	Ethan
> 
> > 
> > ****************************
> > 2011-01-20  Ethan A Merritt  <merritt@u.washington.edu>
> > 
> > 	* src/graph3d.c (xtick_callback ytick_callback ztick_callbacke):
> > 	Revert change made 2011-01-20 because it breaks hidden3d.
> > <snip>
> > ********************
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > --- "sfeam (Ethan Merritt)" wrote:
> > 
> > > On Saturday, January 22, 2011, Tatsuro MATSUOKA wrote:
> > > > Hello
> > > > 
> > > > I have noticed that recent snapshot 3d graph using hidden3d looks different from that made
> by
> > > previous
> > > >  version.  Some tics seems to fail to be hidden.  
> > > 
> > > My fault.  Last week's fix for bug #3157712 broke the hidden3d processing
> > > of axis ticks.  I have reverted that patch and replaced it with one that
> > > forces both the map3d_xy() and map3d_xyz() code paths to share the routine
> > > used for transforming 3D coordinates.   
> > > 
> > > 	Ethan
> > > 
> > > 
> > > 
> > > >  I do not know the exact date this phenomenon has
> > > > been appear.  I think that the snapshot made by older version seem to be correct.
> > > > 
> > > > I have confirmed X11, wxt and windows terminals.
> > > > 
> > > > http://www.geocities.jp/tmgpltwin/Files/Files.html#0050
> > > > 
> > > > 0050 111023hidden_1.png, 25,253 bytes, 2011-01-23, example snapshot of hidden 3d produced
> > > gnuplot 4.5
> > > > (ChangeLog Date 2011-01-20)
> > > > 0051 111023hidden_2.png, 18,552 bytes, 2011-01-23, example snapshot of hidden 3d produced
> > > gnuplot
> > > > 4.4.0
> > > > 
> > > > Regards
> > > > 
> > > > Tatsuro
> > > > 
> > > > --------------------------------------
> > > > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> > > > http://pr.mail.yahoo.co.jp/ie8/
> > > > 
> > > > ------------------------------------------------------------------------------
> > > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > > > Finally, a world-class log management solution at an even better price-free!
> > > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> > > > February 28th, so secure your free ArcSight Logger TODAY! 
> > > > http://p.sf.net/sfu/arcsight-sfd2d
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > > 
> > > 
> > > 
> > 
> > 
> > --------------------------------------
> > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> > http://pr.mail.yahoo.co.jp/ie8/
> > 
> > ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> > February 28th, so secure your free ArcSight Logger TODAY! 
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 


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

Re: utf-8 description (specify to use utf-8 without BOM)

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

Hello

--- Mojca Miklavec wrote:

> On Mon, Jan 24, 2011 at 23:11, Tatsuro MATSUOKA wrote:
> > Hello
> >
> > gnuplot only accepts utf-8 without the BOM (Byte Oder Mark) but not that with the BOM.
> >
> > I think it is better to mention it in a proper position �in the manual
> 
> Or even better: to fix the source code :)
> 
> Mojca

When script saved in utf-8 with BOM , bit order marks are attached to the script contests.
I think that it is not practical to rewrite gnuplot code to accept the script with the utf-8 with BOM.

Regards

Tatsuro 


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

Re: utf-8 description (specify to use utf-8 without BOM)

[Ethan A M. <sf...@us...>]

On Monday, January 24, 2011 02:21:34 pm Mojca Miklavec wrote:
> On Mon, Jan 24, 2011 at 23:11, Tatsuro MATSUOKA wrote:
> > Hello
> >
> > gnuplot only accepts utf-8 without the BOM (Byte Oder Mark) but not that with the BOM.
> >
> > I think it is better to mention it in a proper position  in the manual
> 
> Or even better: to fix the source code :)

You mean the source code for Notepad?

Re: utf-8 description (specify to use utf-8 without BOM)

[Mojca M. <moj...@gm...>]

On Mon, Jan 24, 2011 at 23:11, Tatsuro MATSUOKA wrote:
> Hello
>
> gnuplot only accepts utf-8 without the BOM (Byte Oder Mark) but not that with the BOM.
>
> I think it is better to mention it in a proper position  in the manual

Or even better: to fix the source code :)

Mojca

utf-8 description (specify to use utf-8 without BOM)

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

Hello

gnuplot only accepts utf-8 without the BOM (Byte Oder Mark) but not that with the BOM.

I think it is better to mention it in a proper position  in the manual

The below is my proposal.

**************************
--- gnuplot.orig.doc    2011-01-17 08:00:38 +0900
+++ gnuplot.doc 2011-01-25 07:05:29 +0900
@@ -7520,7 +7520,7 @@
     cp1251      - codepage for 8-bit Russian, Serbian, Bulgarian, Macedonian
     cp1254      - codepage for MS Windows, Turkish (superset of Latin5)
     utf8        - variable-length (multibyte) representation of Unicode
-                  entry point for each character
+                  entry point for each character (use utf-8 without BOM(Byte Or der Mark))

  The command `set encoding locale` is different from the other options.
  It attempts to determine the current locale from the runtime environment.

*****************************

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

Re: hidden3d plot in current cvs source

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

Hello

Thank you for your reply
Now I am building using new snapshot.

I have noticed that the latest changelog date
is 2011-01-20. Is this 2011-01-24?

****************************
2011-01-20  Ethan A Merritt  <merritt@u.washington.edu>

	* src/graph3d.c (xtick_callback ytick_callback ztick_callbacke):
	Revert change made 2011-01-20 because it breaks hidden3d.
<snip>
********************

Regards

Tatsuro

--- "sfeam (Ethan Merritt)" wrote:

> On Saturday, January 22, 2011, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have noticed that recent snapshot 3d graph using hidden3d looks different from that made by
> previous
> >  version.  Some tics seems to fail to be hidden.  
> 
> My fault.  Last week's fix for bug #3157712 broke the hidden3d processing
> of axis ticks.  I have reverted that patch and replaced it with one that
> forces both the map3d_xy() and map3d_xyz() code paths to share the routine
> used for transforming 3D coordinates.   
> 
> 	Ethan
> 
> 
> 
> >  I do not know the exact date this phenomenon has
> > been appear.  I think that the snapshot made by older version seem to be correct.
> > 
> > I have confirmed X11, wxt and windows terminals.
> > 
> > http://www.geocities.jp/tmgpltwin/Files/Files.html#0050
> > 
> > 0050 111023hidden_1.png, 25,253 bytes, 2011-01-23, example snapshot of hidden 3d produced
> gnuplot 4.5
> > (ChangeLog Date 2011-01-20)
> > 0051 111023hidden_2.png, 18,552 bytes, 2011-01-23, example snapshot of hidden 3d produced
> gnuplot
> > 4.4.0
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > --------------------------------------
> > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> > http://pr.mail.yahoo.co.jp/ie8/
> > 
> > ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> > February 28th, so secure your free ArcSight Logger TODAY! 
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 


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

Re: spurious errors in ticks

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

On 01/24/11 00:46, sfeam (Ethan Merritt) wrote:
> On Sunday, January 23, 2011, pl...@pi... wrote:
>> Hi,
>>
>> I just ran up a very simple plot file for some simple time data.
>>
>>
>> set xdata time
>> set timefmt "%d/%m/%y"
>>
>> datafile='bois.log'
>> plot datafile using 1:2
>>
>>
>> when I tried to plot it I got a series of unexpected errors:
>>
>> gnuplot>  load "bois.gnu
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
>>            "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>>
>>
>> After some testing I found that this was caused by calling gnuplot form
>> an xterm&  when the parent terminal had subsequently been closed.
>
> I must not be understanding you correctly.
> If the parent terminal was closed, how could you see these error messages?
> What do you mean by "parent terminal"?

Sorry if that was a bit unclear.

I had an xterm running and spawned three new terminals with xterm& : one 
to edit the data; one to edit the gnuplot script and one to run gnuplot. 
I then closed the "parent" from which these three were spawned. Only 
after closing do I see this error, so data and script are good.

It appears that something changes in shell running gnuplot when it's 
parent goes. This seems odd.

gnuplot 'terminal size' is default from just running gnuplot and using 
load "gnuplotfile.gnu" and is not showing problems until original shell 
(parent of the shell running gnuplot) goes.


regards,

>
>> I am not sure how closing the parent would affect the environment of the
>> xterm running gnuplot but clearly it does. What could be changing that
>> is causing gnuplot to fail to calculate the ticks?
>
> It may be possible to get this error if the current terminal is very small
> ("terminal" in the gnuplot sense of "set terminal ... size XX,YY"),
> although I couldn't trigger it by intentionally setting the x11 window to
> as small as it would go by resizing with the mouse.  Instead I saw warnings
> like "Warning - difficulty fitting plot titles into key" and
> "warning: difficulty making room for xtic labels".
> Did you see this kind of message also?
>
> 	Ethan
>
>
>> Is this to be expected ?
>>
>> TIA,
>>
>> Peter.
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>

Re: spurious errors in ticks

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, January 23, 2011, pl...@pi... wrote:
> Hi,
> 
> I just ran up a very simple plot file for some simple time data.
> 
> 
> set xdata time
> set timefmt "%d/%m/%y"
> 
> datafile='bois.log'
> plot datafile using 1:2
> 
> 
> when I tried to plot it I got a series of unexpected errors:
> 
> gnuplot> load "bois.gnu
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
>           "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
> 
> 
> After some testing I found that this was caused by calling gnuplot form 
> an xterm& when the parent terminal had subsequently been closed.

I must not be understanding you correctly.
If the parent terminal was closed, how could you see these error messages?
What do you mean by "parent terminal"?

> I am not sure how closing the parent would affect the environment of the 
> xterm running gnuplot but clearly it does. What could be changing that 
> is causing gnuplot to fail to calculate the ticks?

It may be possible to get this error if the current terminal is very small
("terminal" in the gnuplot sense of "set terminal ... size XX,YY"),
although I couldn't trigger it by intentionally setting the x11 window to
as small as it would go by resizing with the mouse.  Instead I saw warnings
like "Warning - difficulty fitting plot titles into key" and 
"warning: difficulty making room for xtic labels".
Did you see this kind of message also?

	Ethan

 
> Is this to be expected ?
> 
> TIA,
> 
> Peter.
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: hidden3d plot in current cvs source

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, January 22, 2011, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have noticed that recent snapshot 3d graph using hidden3d looks different from that made by previous
>  version.  Some tics seems to fail to be hidden.  

My fault.  Last week's fix for bug #3157712 broke the hidden3d processing
of axis ticks.  I have reverted that patch and replaced it with one that
forces both the map3d_xy() and map3d_xyz() code paths to share the routine
used for transforming 3D coordinates.   

	Ethan



>  I do not know the exact date this phenomenon has
> been appear.  I think that the snapshot made by older version seem to be correct.
> 
> I have confirmed X11, wxt and windows terminals.
> 
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0050
> 
> 0050 111023hidden_1.png, 25,253 bytes, 2011-01-23, example snapshot of hidden 3d produced gnuplot 4.5
> (ChangeLog Date 2011-01-20)
> 0051 111023hidden_2.png, 18,552 bytes, 2011-01-23, example snapshot of hidden 3d produced gnuplot
> 4.4.0
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

spurious errors in ticks

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

Hi,

I just ran up a very simple plot file for some simple time data.


set xdata time
set timefmt "%d/%m/%y"

datafile='bois.log'
plot datafile using 1:2


when I tried to plot it I got a series of unexpected errors:

gnuplot> load "bois.gnu
          "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
          "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
          "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
          "bois.gnu", line 7: warning: Too many axis ticks requested (>9)
          "bois.gnu", line 7: warning: Too many axis ticks requested (>7)
          "bois.gnu", line 7: warning: Too many axis ticks requested (>9)


After some testing I found that this was caused by calling gnuplot form 
an xterm& when the parent terminal had subsequently been closed.

I am not sure how closing the parent would affect the environment of the 
xterm running gnuplot but clearly it does. What could be changing that 
is causing gnuplot to fail to calculate the ticks?

Is this to be expected ?

TIA,

Peter.

Re: hidden3d plot in current cvs source

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

On 23.01.2011 07:51, Tatsuro MATSUOKA wrote:

> I have noticed that recent snapshot 3d graph using hidden3d looks
> different from that made by previous version. Some tics seems to fail
> to be hidden. I do not know the exact date this phenomenon has been
> appear.

That's pretty certainly a side effect of Ethan's change to graph3d.c 
dated 2011-01-20.  That change effectively killed depth information for 
the tickmarks, thus breaking hidden3d's chance to get it right.

hidden3d plot in current cvs source

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

Hello

I have noticed that recent snapshot 3d graph using hidden3d looks different from that made by previous
 version.  Some tics seems to fail to be hidden.  I do not know the exact date this phenomenon has
been appear.  I think that the snapshot made by older version seem to be correct.

I have confirmed X11, wxt and windows terminals.

http://www.geocities.jp/tmgpltwin/Files/Files.html#0050

0050 111023hidden_1.png, 25,253 bytes, 2011-01-23, example snapshot of hidden 3d produced gnuplot 4.5
(ChangeLog Date 2011-01-20)
0051 111023hidden_2.png, 18,552 bytes, 2011-01-23, example snapshot of hidden 3d produced gnuplot
4.4.0

Regards

Tatsuro

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

Re: win terminal doesn't track mouse wheel?

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

shige 01/22 2011
----------------

| >Comment By: Ethan Merritt (sfeam)
| Date: 2011-01-17 19:19
| 
| Message:
| Excellent!
| Thank you so much.

Sorry, I made a mistake. A bug reported on Japanese BBS from 
A.Kakuto.

----- From here -----
--- wgraph.c.orig Fri Jan 21 00:29:26 2011
+++ wgraph.c Sat Jan 22 11:49:30 2011
@@ -47,7 +47,7 @@
 #define STRICT
 #if defined(WIN32) && defined(USE_MOUSE)
 /* shige: for mouse wheel */
-#define __WIN32_WINNT 0x0400
+#define _WIN32_WINNT 0x0400
 #endif
 #include <windows.h>
 #include <windowsx.h>
----- From here -----

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

Re: some warnings on mac

[Allin C. <cot...@wf...>]

On Thu, 20 Jan 2011, Werner Smekal wrote:

> >>> ../term/post.trm:1819: warning: format not a string literal and no
> >>> format arguments
> >>>
> >>> This comes from
> >>>       static char GPFAR psg1[] = "0 setgray\nnewpath\n";
> >>>       fprintf(gppsfile, psg1);
> >> [\me scratches head] Sure looks like a string literal to me.
> >
> > It's not.  It's s string-valued variable.
> >
> > The complaint is a bit vague, but what I'm pretty sure the compiler is
> > trying to tell us here is that it's kinda pointless to use *printf() if
> > you're not going to format any data into the output.  It wants us to
> > replace the above fprintf() by either
> >
> >           fprintf(gppsfile, "%s", psg1);
> >
> > or
> >
> > 	fputs(psg1, gppsfile);
> It's a security problem, e.g.
> http://bobthegnome.blogspot.com/2009/07/format-not-string-literal-and-no-format.html,
> which might be exploited.
>
> Hans' first version would be IMO the correct one (the second one would
> add an extra \n).

No it wouldn't. Perhaps you're thinking of puts(), which does add
'\n'.

Allin Cottrell

Re: some warnings on mac

[Werner S. <wer...@mi...>]

>
> 	
>
>>> ../term/post.trm:1819: warning: format not a string literal and no
>>> format arguments
>>>
>>> This comes from
>>>       static char GPFAR psg1[] = "0 setgray\nnewpath\n";
>>>       fprintf(gppsfile, psg1);
>> [\me scratches head] Sure looks like a string literal to me.
>
> It's not.  It's s string-valued variable.
>
> The complaint is a bit vague, but what I'm pretty sure the compiler is
> trying to tell us here is that it's kinda pointless to use *printf() if
> you're not going to format any data into the output.  It wants us to
> replace the above fprintf() by either
>
>           fprintf(gppsfile, "%s", psg1);
>
> or
>
> 	fputs(psg1, gppsfile);
It's a security problem, e.g. 
http://bobthegnome.blogspot.com/2009/07/format-not-string-literal-and-no-format.html, 
which might be exploited.

Hans' first version would be IMO the correct one (the second one would 
add an extra \n).

Regards,
Werner
>>> In gnuplot-mode:
>>> gnuplot.el:2518:41:Warning: `make-variable-buffer-local' should be called at
>>>       toplevel
>> I have no idea what this means, or even who is printing the error.
>
>> Is that a message from emacs?
>
> Yes.
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> ------------------------------------------------------------------------
>
> 	Ethan Merritt <mailto:merritt@u.washington.edu>
> January 19, 2011 4:08 AM
>
>
> On Tuesday, January 18, 2011, Mojca Miklavec wrote:
>> I'm sending a copy of some errors that get reported when I try to
>> compile gnuplot ...
>
> Errors from what version of which compiler?
>
>> In file included from term.h:349,
>>                   from term.c:1399:
>> ../term/post.trm: In function 'PS_graphics':
>> ../term/post.trm:1819: warning: format not a string literal and no
>> format arguments
>>
>> This comes from
>>      static char GPFAR psg1[] = "0 setgray\nnewpath\n";
>>      fprintf(gppsfile, psg1);
>
> [\me scratches head] Sure looks like a string literal to me.
>
>
>> util.c:524:1: warning: "sprintf" redefined
>> In file included from /Developer/SDKs/MacOSX10.6.sdk/usr/include/stdio.h:443,
>>                   from stdfn.h:48,
>>                   from util.h:41,
>>                   from util.c:37:
>
> That seems to be an error in stdio.h as provided by SDK.
> Report it to Apple!
>
>
>> /Developer/SDKs/MacOSX10.6.sdk/usr/include/secure/_stdio.h:46:1:
>> warning: this is the location of the previous definition
>> wxterminal/gp_cairo.c: In function 'gp_cairo_convert':
>> wxterminal/gp_cairo.c:678: warning: format '%d' expects type 'int',
>> but argument 5 has type 'gsize'
>> wxterminal/gp_cairo.c:678: warning: format '%d' expects type 'int',
>> but argument 6 has type 'size_t'
>> gplt_x11.c: In function 'exec_cmd':
>> gplt_x11.c:2892: warning: format not a string literal and no format arguments
>> gplt_x11.c:2897: warning: format not a string literal and no format arguments
>> gplt_x11.c:2902: warning: format not a string literal and no format arguments
>> gplt_x11.c:2907: warning: format not a string literal and no format arguments
>
> Those messages are garbage. Ignore them.
>
>> In gnuplot-comint-start-function:
>> gnuplot.el:1838:18:Warning: `make-variable-buffer-local' should be called at
>>      toplevel
>>
>> In gnuplot-mode:
>> gnuplot.el:2518:41:Warning: `make-variable-buffer-local' should be called at
>>      toplevel
>
> I have no idea what this means, or even who is printing the error.
> Is that a message from emacs?
>
>
>> Some more are related to AquaTerm, but that's an issue on its own.
>>
>> Mojca
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> ------------------------------------------------------------------------
>
> 	Mojca Miklavec <mailto:moj...@gm...>
> January 19, 2011 3:49 AM
>
>
> I'm sending a copy of some errors that get reported when I try to
> compile gnuplot ...
>
> In file included from term.h:349,
> from term.c:1399:
> ../term/post.trm: In function 'PS_graphics':
> ../term/post.trm:1819: warning: format not a string literal and no
> format arguments
>
> This comes from
> static char GPFAR psg1[] = "0 setgray\nnewpath\n";
> fprintf(gppsfile, psg1);
>
> util.c:524:1: warning: "sprintf" redefined
> In file included from 
> /Developer/SDKs/MacOSX10.6.sdk/usr/include/stdio.h:443,
> from stdfn.h:48,
> from util.h:41,
> from util.c:37:
> /Developer/SDKs/MacOSX10.6.sdk/usr/include/secure/_stdio.h:46:1:
> warning: this is the location of the previous definition
> wxterminal/gp_cairo.c: In function 'gp_cairo_convert':
> wxterminal/gp_cairo.c:678: warning: format '%d' expects type 'int',
> but argument 5 has type 'gsize'
> wxterminal/gp_cairo.c:678: warning: format '%d' expects type 'int',
> but argument 6 has type 'size_t'
> gplt_x11.c: In function 'exec_cmd':
> gplt_x11.c:2892: warning: format not a string literal and no format 
> arguments
> gplt_x11.c:2897: warning: format not a string literal and no format 
> arguments
> gplt_x11.c:2902: warning: format not a string literal and no format 
> arguments
> gplt_x11.c:2907: warning: format not a string literal and no format 
> arguments
>
> In gnuplot-comint-start-function:
> gnuplot.el:1838:18:Warning: `make-variable-buffer-local' should be 
> called at
> toplevel
>
> In gnuplot-mode:
> gnuplot.el:2518:41:Warning: `make-variable-buffer-local' should be 
> called at
> toplevel
>
> Some more are related to AquaTerm, but that's an issue on its own.
>
> Mojca
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> ------------------------------------------------------------------------


-- 
Werner Smekal
email: wer...@mi...
phone: +43-(0)680-1419590

Re: Corrections to links in page http://www.gnuplot.info/docs_4.4/

[Niall M. <nm...@ui...>]

Ethan,

Thanks for your reply.

I think I must have picked up
	http://www.gnuplot.info/docs_4.4/
from a Google search.

  > I've now put in a redirection to the correct page, but is there a link to 
  > the incorrect URL somewhere that we need to fix?

That seems to have fixed it -- all the links look OK to me.

	Regards,
	Niall


On Jan 19, 10:54am, Ethan Merritt wrote:
> Subject: Re: Corrections to links in page http://www.gnuplot.info/docs_4.4
> On Wednesday, January 19, 2011 02:09:51 am Niall Mansfield wrote:
> > On page
> > 	http://www.gnuplot.info/docs_4.4/
>       ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > the links for
> > 	Version 4.4 (English) PDF format.
> > and
> > 	Gnuplot reference card (version 4.0): ... gpcard.pdf
> > are wrong, and ought to be:
> > 	http://www.gnuplot.info/docs_4.4/gnuplot.pdf
> > 	http://www.gnuplot.info/docs_4.0/gpcard.pdf
> 
> That page is not intended to be accessed directly.
> The correct top-level documentation page is
>     http://www.gnuplot.info/documentation.html
> 

> 
> 	Ethan
> 
> 
> > Regards,
> > Niall
> > 
> > -------------------------------------------------------------
> > Niall Mansfield, Editor
> >     UIT Cambridge Ltd.
> >     PO Box 145                          email: nm...@ui...
> >     Cambridge CB4 1GQ,  England		tel: +44 1223 302 041
> > -------------------------------------------------------------
>-- End of excerpt from Ethan Merritt

Re: finite summation - sum [k=1:4] k

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

On 01/19/11 19:15, mw...@gm... wrote:
> Hi,
>
> I have implemented 'sum' which can be used as folows:
>
>      a    = sum [k=1:4] k
>      f(x) = sum [k=1:4] sin(k*x)
>      print  sum [k=1:4] k
>      plot   sum [k=1:4] sin(k*x)
>
> Motivation: A friend asked me how to plot the sum of the first 10, 100, 1000
> fourier coefficients of a (particular) square wave. This patch allows to do so:
>
>      fourier(k, x) = sin(3./2*k)/k * 2./3*cos(k*x)
>      plot 1./2 + sum [k=1:1000] fourier(k, x)
>
>      # alternatively
>      plot 1./2 + sum [k=1:1000] sin(3./2*k)/k * 2./3*cos(k*x)
>
>
> Questions: I am not sure where to put the documentation in gnuplot.doc:
> | The `sum` keyword allows the calulation of the finite sum
> | \sum_{i=a}^b f_i.
> |
> | Example:
> |       # fourier coefficients of some square wave
> |       fourier(k, x) = sin(3./2*k)/k * 2./3*cos(k*x)
> |       plot 1./2 + sum [k=1:1000] fourier(k, x)
> |
> |       plot 1./2 + sum [k=1:1000] sin(3./2*k)/k * 2./3*cos(k*x)
>
>
>> Ethan Merritt<merritt@u.washington.edu>  wrote:
>> On Wednesday, January 12, 2011 07:49:57 am mw...@gm... wrote:
> [...]
>> My first thought would be to aim for
>>        fourier(x) = for [k=1:100] sin(3./2*k)/k * 2./3*cos(k*x)
>
> I had to rename it to 'sum', since 'for' turned out to be ambiguous (for
> example: "plot for [k=1:10] sin(k*x)")
>
>>> As Mr. Bröker pointed out, there is a trick involving the tertinary operator
>>> '?' and recursion to sorta workaround. Originally I tried to plot the sum
>>> with '?' but I could only do so for 1..10, in case of 1..100 it said
>>> something about stack overflow.
>>
>> I am inclined to agree with Hans-Bernhard that such a summation
>> meta-function is not required.
>> But feel free to provide a contrary argument.
>
> I suppose an experienced gnuplot developer knows all the tricks by heart whereas
> I had a much harder time and ultimately was not able to solve the original
> problem of plotting the sum of 1000 terms. I tend to believe that '?:' results
> in hard to read code and 'sum' is easier to use and understand by the "normal"
> user. 'sum' also removes the recursion.
>
> [...]
>
>>> I have added below a working patch but would like you to have a look at it.
>>
>> I don't really have much time right now.
>> Could you please upload it to the patch tracker on Sourceforge?
>> That way it won't get lost, you can update it whenever you want,
>> and testers can post comments and provide feedback.
>
> I have not done so yet, but will do so if my patch is not complete garbage.
>
> Thank you for your consideration,
> Micha Wiedenmann
>
>
> diff --git gnuplot-cvs/demo/bivariat.dem b/demo/bivariat.dem
> index 1865a59..21c46be 100644
> --- gnuplot-cvs/demo/bivariat.dem
> +++ b/demo/bivariat.dem
> @@ -115,5 +115,27 @@ set title "Greatest Common Divisor (for integers only)"
>   plot gcd(x, 60) with impulses
>   pause -1 "Hit return to continue"
>
> +#
> +# This definition computes the sum of the first 10, 100, 1000 fourier
> +# coefficients of a (particular) square wave.
> +
> +set title "Finite summation of 10, 100, 1000 fourier coefficients"
> +
> +set samples 500
> +set xrange [-10:10]
> +set yrange [-0.4:1.2]
> +set key bottom right
> +
> +fourier(k, x) = sin(3./2*k)/k * 2./3*cos(k*x)
> +sum10(x)   = 1./2 + sum [k=1:10]   fourier(k, x)
> +sum100(x)  = 1./2 + sum [k=1:100]  fourier(k, x)
> +sum1000(x) = 1./2 + sum [k=1:1000] fourier(k, x)
> +
> +plot \
> +    sum10(x)   title "1./2 + sum [k=1:10]   sin(3./2*k)/k * 2./3*cos(k*x)", \
> +    sum100(x)  title "1./2 + sum [k=1:100]  sin(3./2*k)/k * 2./3*cos(k*x)", \
> +    sum1000(x) title "1./2 + sum [k=1:1000] sin(3./2*k)/k * 2./3*cos(k*x)"
> +pause -1 "Hit return to continue"
> +
>   reset
>
> diff --git gnuplot-cvs/src/eval.c b/src/eval.c
> index 8b551d8..64517ab 100644
> --- gnuplot-cvs/src/eval.c
> +++ b/src/eval.c
> @@ -89,6 +89,7 @@ const struct ft_entry GPFAR ft[] =
>       {"pop",  f_pop},
>       {"call",  f_call},
>       {"calln",  f_calln},
> +    {"sum", f_sum},
>       {"lnot",  f_lnot},
>       {"bnot",  f_bnot},
>       {"uminus",  f_uminus},
> @@ -669,6 +670,20 @@ add_udv_by_name(char *key)
>       return (*udv_ptr);
>   }
>
> +struct udvt_entry *
> +get_udv_by_name(char *key)
> +{
> +    struct udvt_entry *udv = first_udv;
> +
> +    while (udv) {
> +        if (!strcmp(key, udv->udv_name))
> +            return udv;
> +
> +        udv = udv->next_udv;
> +    }
> +
> +    return NULL;
> +}
>
>   static void update_plot_bounds __PROTO((void));
>   static void fill_gpval_axis __PROTO((AXIS_INDEX axis));
> diff --git gnuplot-cvs/src/eval.h b/src/eval.h
> index 79edb6e..ed02262 100644
> --- gnuplot-cvs/src/eval.h
> +++ b/src/eval.h
> @@ -53,7 +53,7 @@
>   enum operators {
>       /* keep this in line with table in eval.c */
>       PUSH, PUSHC, PUSHD1, PUSHD2, PUSHD, POP,
> -    CALL, CALLN, LNOT, BNOT, UMINUS,
> +    CALL, CALLN, SUM, LNOT, BNOT, UMINUS,
>       LOR, LAND, BOR, XOR, BAND, EQ, NE, GT, LT, GE, LE, PLUS, MINUS, MULT,
>       DIV, MOD, POWER, FACTORIAL, BOOLE,
>       DOLLARS, /* for using extension - div */
> @@ -161,6 +161,7 @@ void execute_at __PROTO((struct at_type *at_ptr));
>   void evaluate_at __PROTO((struct at_type *at_ptr, struct value *val_ptr));
>   void free_at __PROTO((struct at_type *at_ptr));
>   struct udvt_entry * add_udv_by_name __PROTO((char *key));
> +struct udvt_entry * get_udv_by_name __PROTO((char *key));
>
>   /* update GPVAL_ variables available to user */
>   void update_gpval_variables __PROTO((int from_plot_command));
> diff --git gnuplot-cvs/src/internal.c b/src/internal.c
> index b4cd25f..706df95 100644
> --- gnuplot-cvs/src/internal.c
> +++ b/src/internal.c
> @@ -200,6 +200,54 @@ f_calln(union argument *x)
>
>
>   void
> +f_sum(union argument *arg)
> +{
> +    struct value beg, end, varname; /* [<var>  =<start>:<end>] */
> +    udft_entry *udf;                /* function to evaluate */
> +    udvt_entry *udv;                /* iteration variable */
> +    struct value ret;               /* result */
> +    struct value z;
> +    int i;
> +
> +    (void) pop(&end);
> +    (void) pop(&beg);
> +    (void) pop(&varname);
> +
> +    if (beg.type != INTGR || end.type != INTGR)
> +        int_error(NO_CARET, "range specifiers of sum must have integer values");
> +    if (varname.type != STRING)
> +        int_error(NO_CARET, "internal error: f_sum expects argument (varname) of type string.");
> +
> +    udv = get_udv_by_name(varname.v.string_val);
> +    if (!udv)
> +        int_error(NO_CARET, "internal error: f_sum could not access iteration variable.");
> +    udv->udv_undef = false;
> +
> +    udf = arg->udf_arg;
> +    if (!udf)
> +        int_error(NO_CARET, "internal error: f_sum could not access summation coefficient function");
> +
> +    Gcomplex(&ret, 0, 0);
> +    for (i=beg.v.int_val; i<=end.v.int_val; ++i) {
> +        double x, y;
> +
> +        /* calculate f_i = f() with user defined variable i */
> +        Ginteger(&udv->udv_value, i);
> +        execute_at(udf->at);
> +
> +        pop(&z);
> +        x = real(&ret) + real(&z);
> +        y = imag(&ret) + imag(&z);
> +        Gcomplex(&ret, x, y);
> +    }
> +
> +    gpfree_string(&varname);
> +
> +    push(Gcomplex(&z, real(&ret), imag(&ret)));
> +}
> +
> +
> +void
>   f_lnot(union argument *arg)
>   {
>       struct value a;
> diff --git gnuplot-cvs/src/internal.h b/src/internal.h
> index 9bb1a3a..7fbdbf8 100644
> --- gnuplot-cvs/src/internal.h
> +++ b/src/internal.h
> @@ -55,6 +55,7 @@ void f_pushd __PROTO((union argument *x));
>   void f_pop __PROTO((union argument *x));
>   void f_call __PROTO((union argument *x));
>   void f_calln __PROTO((union argument *x));
> +void f_sum __PROTO((union argument *x));
>   void f_lnot __PROTO((union argument *x));
>   void f_bnot __PROTO((union argument *x));
>   void f_lor __PROTO((union argument *x));
> diff --git gnuplot-cvs/src/parse.c b/src/parse.c
> index 2a665ab..954d9fe 100644
> --- gnuplot-cvs/src/parse.c
> +++ b/src/parse.c
> @@ -89,6 +89,7 @@ static void parse_relational_expression __PROTO((void));
>   static void parse_additive_expression __PROTO((void));
>   static void parse_multiplicative_expression __PROTO((void));
>   static void parse_unary_expression __PROTO((void));
> +static void parse_sum_expression __PROTO((void));
>   static int  parse_assignment_expression __PROTO((void));
>   static int is_builtin_function __PROTO((int t_num));
>
> @@ -190,7 +191,8 @@ string_or_express(struct at_type **atptr)
>       has_dummies = FALSE;
>       for (i = 0; i<  at->a_count; i++) {
>   	enum operators op_index = at->actions[i].index;
> -	if ( op_index == PUSHD1 || op_index == PUSHD2 || op_index == PUSHD ) {
> +	if ( op_index == PUSHD1 || op_index == PUSHD2 || op_index == PUSHD
> +                || op_index == SUM ) {
>   	    has_dummies = TRUE;
>   	    break;
>   	}
> @@ -488,6 +490,8 @@ parse_primary_expression()
>   		c_token++;
>   		add_action(call_type)->udf_arg = add_udf(tok);
>   	    }
> +	} else if (equals(c_token, "sum")) {
> +            parse_sum_expression();
>   	    /* dummy_func==NULL is a flag to say no dummy variables active */
>   	} else if (dummy_func) {
>   	    if (equals(c_token, c_dummy_var[0])) {
> @@ -834,6 +838,112 @@ parse_unary_expression()
>   	parse_primary_expression();
>   }
>
> +
> +/* create action code for 'sum' expressions */
> +static void
> +parse_sum_expression()
> +{
> +    /* Design: Use a user defined variable (udv) as iterator variable (k). The
> +     * original idea was to treat the expression after the range as a function
> +     * f(k). Consider 'g(x) = sum [k=1:4] f(k)', there are two dummy variables
> +     * 'x' and 'k' from different functions 'g' and 'f' which cannot be handled
> +     * by the parser. */
> +
> +    char *errormsg = "Expecting 'sum [<var>  =<start>:<end>]'\n";
> +    char *varname = NULL;
> +    union argument *arg;
> +    struct udft_entry *udf;
> +
> +    struct at_type * save_at;
> +    int save_at_size;
> +    int i;
> +
> +    if (!equals(c_token, "sum"))
> +        return;
> +    c_token++;
> +
> +    if (!equals(c_token, "["))
> +        int_error(c_token, errormsg);
> +    c_token++;
> +
> +    /*<var>  */
> +    if (!isletter(c_token))
> +        int_error(c_token, errormsg);
> +    /* create a user defined variable and pass it to f_sum via the action
> +     * table, since the argument of f_sum is already used by the udf */
> +    m_capture(&varname, c_token, c_token);
> +    add_udv(c_token);
> +    arg = add_action(PUSHC);
> +    Gstring(&(arg->v_arg), varname);
> +    c_token++;
> +
> +    if (!equals(c_token, "="))
> +        int_error(c_token, errormsg);
> +    c_token++;
> +
> +    /*<start>  */
> +    if (!isanumber(c_token))
> +        int_error(c_token, errormsg);
> +    arg = add_action(PUSHC);
> +    convert(&(arg->v_arg), c_token);
> +    c_token++;
> +
> +    if (!equals(c_token, ":"))
> +        int_error(c_token, errormsg);
> +    c_token++;
> +
> +    /*<end>  */
> +    if (!isanumber(c_token))
> +        int_error(c_token, errormsg);
> +    arg = add_action(PUSHC);
> +    convert(&(arg->v_arg), c_token);
> +    c_token++;
> +
> +    /* TODO add increment */
> +    if (!equals(c_token, "]"))
> +        int_error(c_token, errormsg);
> +    c_token++;
> +
> +    /* parse the next expression and convert it to an action table. */
> +    /* save environment to restart parsing */
> +    save_at = at;
> +    save_at_size = at_size;
> +
> +    at = (struct at_type *) gp_alloc(sizeof(struct at_type), "action table");
> +    at->a_count = 0;
> +    /* taken from temp_at()
> +     * XXX Why is it necessary to reset the action table? Shouldn't it be
> +     * either sizeof(struct at_type) or a_count = 0? */
> +    memset(at, 0, sizeof(*at));
> +    at_size = MAX_AT_LEN;
> +
> +    /* Q: Do I have to save and restore parse_recursion_level?
> +     * A: parse_recursion_level is used to abort parsing after the strings
> +     * ('-\pi', '-\pi/2') in ('-\pi' -pi, '-\pi/2' -pi/2.), otherwise it would
> +     * try to subtract pi from the string '-\pi'. This is only in effect for
> +     * parse_recursion_level == 1 and string_result_only == true. My conclusion
> +     * is thus to not touch parse_recursion_level. */
> +    parse_expression();
> +
> +    /* save action table in a user defined function */
> +    udf = (struct udft_entry *) gp_alloc(sizeof(struct udft_entry), "sum");
> +    udf->next_udf = (struct udft_entry *) NULL;
> +    udf->udf_name = NULL; /* TODO maybe add a name and definition */
> +    udf->at = at;
> +    udf->definition = NULL;
> +    udf->dummy_num = 0;
> +    for (i = 0; i<  MAX_NUM_VAR; i++)
> +        (void) Ginteger(&(udf->dummy_values[i]), 0);
> +
> +    /* restore environment */
> +    at = save_at;
> +    at_size = save_at_size;
> +
> +    /* pass the udf to f_sum using the argument */
> +    add_action(SUM)->udf_arg = udf;
> +}
> +
> +
>   /* find or add value and return pointer */
>   struct udvt_entry *
>   add_udv(int t_num)
>

The idea is interesting but this kind of ad hoc , special case addition 
to syntax can only end up as a mess in the long run. As Hans pointed out 
gnuplot is not supposed to be a full blown programming language. If that 
ever becomes a desire it will require top-down design, it can't happen 
by evolution.

If that is attempted it will reach a breaking point where everything 
needs restructuring and the conviction gnuplot has towards backwards 
compatibility will have to be broken.

This is really trying to add a structured programming feature without 
structured programming. Gnuplot does not even have a proper if-then-else 
syntax yet.

If the latter was to be implemented fully it would probably require 
adding the structured programming infrastructure that would make adding 
this "sum" idea in a clean and coherent way fairly easy.

But adding that infrastructure will need some careful design.

regards, Peter.

Re: Corrections to links in page http://www.gnuplot.info/docs_4.4/

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

On Wednesday, January 19, 2011 12:07:04 pm pl...@pi... wrote:
> On 01/19/11 19:54, Ethan Merritt wrote:
> > On Wednesday, January 19, 2011 02:09:51 am Niall Mansfield wrote:
> >> On page
> >> 	http://www.gnuplot.info/docs_4.4/
> >        ^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >> the links for
> >> 	Version 4.4 (English) PDF format.
> >> and
> >> 	Gnuplot reference card (version 4.0): ... gpcard.pdf
> >> are wrong, and ought to be:
> >> 	http://www.gnuplot.info/docs_4.4/gnuplot.pdf
> >> 	http://www.gnuplot.info/docs_4.0/gpcard.pdf
> >
> > That page is not intended to be accessed directly.
> > The correct top-level documentation page is
> >      http://www.gnuplot.info/documentation.html
> >
> > I've now put in a redirection to the correct page, but is there a link to
> > the incorrect URL somewhere that we need to fix?
> >
> > 	Ethan
> >
> >
> >> Regards,
> >> Niall
> >>
> >>
> 
> Ethan, I don' t think you can say a page is "not intended to be ..." . 
> As soon as you publish a page it will get linked and will turn up in 
> search results.

I meant "not intended to be accessed directly" as
"is version specific and would better be replaced by a generic link
to the current documentation"

> The best policy would seem to be only to post valid documents on-line 
> and leave them in place for reference as newer ones become available.

It was a valid document.  But because it was accessed through a symlink,
the relative directory paths did not resolve correctly.  That part is now fixed.
But I'd still like to encourage any links that are specific to version 4.2 or 4.4
to be replaced with links that resolve to whatever is the current version, or
to the top level listing that includes links to both current and past versions.

	cheers,
	
		Ethan

 
> regards, Peter.

Re: Corrections to links in page http://www.gnuplot.info/docs_4.4/

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

On 01/19/11 19:54, Ethan Merritt wrote:
> On Wednesday, January 19, 2011 02:09:51 am Niall Mansfield wrote:
>> On page
>> 	http://www.gnuplot.info/docs_4.4/
>        ^^^^^^^^^^^^^^^^^^^^^^^^
>
>> the links for
>> 	Version 4.4 (English) PDF format.
>> and
>> 	Gnuplot reference card (version 4.0): ... gpcard.pdf
>> are wrong, and ought to be:
>> 	http://www.gnuplot.info/docs_4.4/gnuplot.pdf
>> 	http://www.gnuplot.info/docs_4.0/gpcard.pdf
>
> That page is not intended to be accessed directly.
> The correct top-level documentation page is
>      http://www.gnuplot.info/documentation.html
>
> I've now put in a redirection to the correct page, but is there a link to
> the incorrect URL somewhere that we need to fix?
>
> 	Ethan
>
>
>> Regards,
>> Niall
>>
>>

Ethan, I don' t think you can say a page is "not intended to be ..." . 
As soon as you publish a page it will get linked and will turn up in 
search results.

The best policy would seem to be only to post valid documents on-line 
and leave them in place for reference as newer ones become available.

regards, Peter.