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

Re: pgnuplot.exe flow control

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

Hello

--- gnu...@t4... wrote:

> 
> If I've understood correctly how pgnuplot.exe is supposed to work on Win32,
> 	type "object map.gps" | pgnuplot.exe
> should be essentially equivalent to starting wgnuplot.exe and saying
> 	load "object map.gps"
> 
> Is that right, or am I missing something here?

It is not right.  The above two cases are completely different one another.
The pgnuplot recieves the streams from pipe and sends them to wgnuplot command line 
using win32 api function.

For details, please read the source of pgnuplot.

http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/src/win/pgnuplot.c?revision=1.15.2.1&view=markup

The latter directly loads the commands or data from the file.

The followings are the parts of my c program using pgnuplot before

	if((gp = _popen(PGNUPLOT_PATH, "w")) == NULL){
        fprintf(stderr, "Error! I can't find %s.", PGNUPLOT_PATH);
        exit(EXIT_FAILURE);
    }
            :
            :
	while(fgets(buff,BSIZE,fp) != NULL){
		fprintf(gp,"%s",buff);fflush(gp);
	}

In using pgnuplot, using of fflush(gp); after sending one command line is desirble.

Note
The wgnuplot_pipes.exe is entirely different from the pgnuplot

It allows that

plot '< awk -f awkscript.awk'

on the wgnuplot.

 

Regards

Tatsuro

> The problem I see, both on 4.2 and 4.3, is that commands in object map.gps
> are seemingly lost or overlooked. This leads to syntax errors, and all
> sorts of other problems. Normally, pgnuplot.exe closes the wgnuplot.exe
> input window when it reaches EOF. However, in the above scenario with
> "type," the GnuPlot application window remains open, displaying the
> history of botched commands piped in from pgnuplot. That's how I know
> some commands (or parts of commands) are being skipped. It's almost as
> if the pipe needs flow control but doesn't have it... losing bytes that
> fall off the end of the "buffer" when it gets full.
> 
> If I avoid type and put a "sleep 1" between every line I copy into the
> pipe, the script works fine, except that it takes an eternity to run
> anything nontrivial. If I open GnuPlot and say "load 'object map.gps'"
> it works fine. If I run wgnuplot.exe "/path/to/object map.gps", that also
> works fine. The apparent flow control problem is limited to pgnuplot.exe.
> (I've had no luck at all with wgnuplot_pipes.exe.)
> 
> I've seen this behavior on multiple Windows XP installs, at least one
> Vista, and Server 2003, so it's not particular to one computer, OS, or
> GnuPlot version. Anyone else run into this problem? Anyone have an idea
> what's going on? Ideas for a work-around?
> 
> If you want to try it yourself, I've attached an example *.gps that
> generates the errors from above. [If you try to run it on 4.3, you'll
> have to substitute c:/windows/fonts/verdana.ttf for Verdana.ttf as 
> 4.3 seems to have lost the ability to find fonts without a full path to
> the file.]
> 
> This all started because I'd really like to do "perl.exe script.pl |
> pgnuplot.exe" but that has the same issue.
> 
> Tait
> 
> > # comment
> # comment
> # comment
> cd 'C:/temp'
> reset
> set terminal png transparent nointerlace truecolor font 'verdana.TTF,10' size 800,650 nocrop
> enhanced xffffff
> set output 'Object Map.png'
> set title 'Object Map 317366435' font 'Verdana.ttf,14' tc rgbcolor '#A80868' noenhanced
> set xtics 4
> set ytics 4
> set grid front
> set cbrange [0.0:1.0]
> set xrange [4:45]
> set yrange [6:30]
> plot '-' with rgbimage notitle
> 0	0	1	1	1
> 0	1	1	1	1
> 0	2	1	1	1
> 0	3	1	1	1
> 0	4	1	1	1
> 0	5	1	1	1
> 0	6	1	1	1
> 0	7	1	1	1
> 0	8	1	1	1
> 0	9	1	1	1
> 0	10	1	1	1
> 0	11	1	1	1
> 0	12	1	1	1
> 0	13	1	1	1
> 0	14	1	1	1
> 0	15	1	1	1
> 0	16	1	1	1
> 0	17	1	1	1
> 0	18	1	1	1
> 0	19	1	1	1
> 0	20	1	1	1
> 0	21	1	1	1
> 0	22	1	1	1
> 0	23	1	1	1
> 0	24	1	1	1
> 0	25	1	1	1
> 0	26	1	1	1
> 0	27	1	1	1
> 0	28	1	1	1
> 0	29	1	1	1
> 1	0	1	1	1
> 1	1	1	1	1
> 1	2	1	1	1
> 1	3	1	1	1
> 1	4	1	1	1
> 1	5	1	1	1
> 1	6	1	1	1
> 1	7	1	1	1
> 1	8	1	1	1
> 1	9	1	1	1
> 1	10	1	1	1
> 1	11	1	1	1
> 1	12	1	1	1
> 1	13	1	1	1
> 1	14	1	1	1
> 1	15	1	1	1
> 1	16	1	1	1
> 1	17	1	1	1
> 1	18	1	1	1
> 1	19	1	1	1
> 1	20	1	1	1
> 1	21	1	1	1
> 1	22	1	1	1
> 1	23	1	1	1
> 1	24	1	1	1
> 1	25	1	1	1
> 1	26	1	1	1
> 1	27	1	1	1
> 1	28	1	1	1
> 1	29	1	1	1
> 2	0	1	1	1
> 2	1	1	1	1
> 2	2	1	1	1
> 2	3	1	1	1
> 2	4	1	1	1
> 2	5	1	1	1
> 2	6	1	1	1
> 2	7	1	1	1
> 2	8	1	1	1
> 2	9	1	1	1
> 2	10	1	1	1
> 2	11	1	1	1
> 2	12	1	1	1
> 2	13	1	1	1
> 2	14	1	1	1
> 2	15	1	1	1
> 2	16	1	1	1
> 2	17	1	1	1
> 2	18	1	1	1
> 2	19	1	1	1
> 2	20	1	1	1
> 2	21	1	1	1
> 2	22	1	1	1
> 2	23	1	1	1
> 2	24	1	1	1
> 2	25	1	1	1
> 2	26	1	1	1
> 2	27	1	1	1
> 2	28	1	1	1
> 2	29	1	1	1
> 3	0	1	1	1
> 3	1	1	1	1
> 3	2	1	1	1
> 3	3	1	1	1
> 3	4	1	1	1
> 3	5	1	1	1
> 3	6	1	1	1
> 3	7	1	1	1
> 3	8	1	1	1
> 3	9	1	1	1
> 3	10	1	1	1
> 3	11	1	1	1
> 3	12	1	1	1
> 3	13	1	1	1
> 3	14	1	1	1
> 3	15	1	1	1
> 3	16	1	1	1
> 3	17	1	1	1
> 3	18	1	1	1
> 3	19	1	1	1
> 3	20	1	1	1
> 3	21	1	1	1
> 3	22	1	1	1
> 3	23	1	1	1
> 3	24	1	1	1
> 3	25	1	1	1
> 3	26	1	1	1
> 3	27	1	1	1
> 3	28	1	1	1
> 3	29	1	1	1
> 4	0	1	1	1
> 4	1	1	1	1
> 4	2	1	1	1
> 4	3	1	1	1
> 4	4	1	1	1
> 4	5	1	1	1
> 4	6	1	1	1
> 4	7	1	1	1
> 4	8	1	1	1
> 4	9	1	1	1
> 4	10	1	1	1
> 4	11	1	1	1
> 4	12	1	1	1
> 4	13	1	1	1
> 4	14	1	1	1
> 4	15	1	1	1
> 4	16	1	1	1
> 4	17	1	1	1
> 4	18	1	1	1
> 4	19	1	1	1
> 4	20	1	1	1
> 4	21	1	1	1
> 4	22	1	1	1
> 4	23	1	1	1
> 4	24	1	1	1
> 4	25	1	1	1
> 4	26	1	1	1
> 4	27	1	1	1
> 4	28	1	1	1
> 4	29	1	1	1
> 5	0	1	1	1
> 5	1	1	1	1
> 5	2	1	1	1
> 5	3	1	1	1
> 5	4	1	1	1
> 5	5	1	1	1
> 5	6	1	1	1
> 5	7	1	1	1
> 5	8	1	1	1
> 5	9	1	1	1
> 5	10	1	1	1
> 5	11	1	1	1
> 5	12	1	1	1
> 5	13	1	1	1
> 5	14	1	1	1
> 5	15	1	1	1
> 5	16	1	1	1
> 5	17	0.84	0.36	0.36
> 5	18	1	1	1
> 5	19	1	1	1
> 5	20	1	1	1
> 5	21	1	1	1
> 5	22	1	1	1
> 5	23	1	1	1
> 5	24	1	1	1
> 5	25	1	1	1
> 5	26	1	1	1
> 5	27	1	1	1
> 5	28	1	1	1
> 5	29	1	1	1
> 6	0	1	1	1
> 6	1	1	1	1
> 6	2	1	1	1
> 6	3	1	1	1
> 6	4	1	1	1
> 
=== 以下のメッセージは省略されました ===>
-------------------------------------------------------------------------
> 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: errorlines vs errorbars

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

On Tuesday 18 March 2008 07:08, Allin Cottrell wrote:
> Is there any real difference between "errorbars" and "errorlines"?  
> >From the help for errorbars it sounds as if there should be a 
> difference, but I can't see any in the output.
> 
> One feature that would be nice to have -- and that, for a moment, 
> I though "errorlines" might provide -- is the ability to plot a 
> primary series plus y-axis error high and low using just lines 
> (and not vertical bars) for all 3 components.  (This is the most 
> common way of graphing forecasts with error bands in economics.)

This sounds similar to the "between" option of "filledcurves".

> Of course one can achieve this effect manually by providing y, 
> high and low as 3 distinct arguments to 'plot' and forcing the 
> high and low series to use the same line style/type/color.  

In current cvs:

   plot for [i=2:4] 'data' using 1:(column(i)) with lines lc rgb "blue"

where 'data' contains    x ymin y ymax


> But it  
> would be a lot more convenient to be able to provide the same 
> basic input and select the style via errorbars vs 
> errorsomethingelse.
 
I think for quite a while now the philosophy has been that it is
sufficient to provide components from which you can build up a
complicated plot.  For example there is really no advantage of having
a style "linespoints" when you could make the same plot using
"lines" and "points" separately.  

-- 
Ethan A Merritt 

errorlines vs errorbars

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

Is there any real difference between "errorbars" and "errorlines"?  
>From the help for errorbars it sounds as if there should be a 
difference, but I can't see any in the output.

One feature that would be nice to have -- and that, for a moment, 
I though "errorlines" might provide -- is the ability to plot a 
primary series plus y-axis error high and low using just lines 
(and not vertical bars) for all 3 components.  (This is the most 
common way of graphing forecasts with error bands in economics.)

Of course one can achieve this effect manually by providing y, 
high and low as 3 distinct arguments to 'plot' and forcing the 
high and low series to use the same line style/type/color.  But it 
would be a lot more convenient to be able to provide the same 
basic input and select the style via errorbars vs 
errorsomethingelse.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

pgnuplot.exe flow control

[<gnu...@t4...>]

If I've understood correctly how pgnuplot.exe is supposed to work on Win32,
	type "object map.gps" | pgnuplot.exe
should be essentially equivalent to starting wgnuplot.exe and saying
	load "object map.gps"

Is that right, or am I missing something here?

The problem I see, both on 4.2 and 4.3, is that commands in object map.gps
are seemingly lost or overlooked. This leads to syntax errors, and all
sorts of other problems. Normally, pgnuplot.exe closes the wgnuplot.exe
input window when it reaches EOF. However, in the above scenario with
"type," the GnuPlot application window remains open, displaying the
history of botched commands piped in from pgnuplot. That's how I know
some commands (or parts of commands) are being skipped. It's almost as
if the pipe needs flow control but doesn't have it... losing bytes that
fall off the end of the "buffer" when it gets full.

If I avoid type and put a "sleep 1" between every line I copy into the
pipe, the script works fine, except that it takes an eternity to run
anything nontrivial. If I open GnuPlot and say "load 'object map.gps'"
it works fine. If I run wgnuplot.exe "/path/to/object map.gps", that also
works fine. The apparent flow control problem is limited to pgnuplot.exe.
(I've had no luck at all with wgnuplot_pipes.exe.)

I've seen this behavior on multiple Windows XP installs, at least one
Vista, and Server 2003, so it's not particular to one computer, OS, or
GnuPlot version. Anyone else run into this problem? Anyone have an idea
what's going on? Ideas for a work-around?

If you want to try it yourself, I've attached an example *.gps that
generates the errors from above. [If you try to run it on 4.3, you'll
have to substitute c:/windows/fonts/verdana.ttf for Verdana.ttf as 
4.3 seems to have lost the ability to find fonts without a full path to
the file.]

This all started because I'd really like to do "perl.exe script.pl |
pgnuplot.exe" but that has the same issue.

Tait

Re: Calling all Atari geezers - Hello, anyone there?

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

> Message: 1
> Date: Thu, 13 Mar 2008 09:41:23 +0000
> From: Daniel <boy...@gm...>
> Subject: Re: Calling all Atari geezers - Hello, anyone there?


I don't know of anyone who owns or uses Atari.


Mike Sutton



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

Re: Is that kind of substitution possible?

[Brouard N. <br...@in...>]

Le samedi 15 mars 2008 à 01:22 +0100, Juergen Wieferink a écrit :
> > Many thanks for your help, but I just got that:
> > gnuplot> evie(x, y) = real(system("echo 90 %f 0 %f 0.1
> > 1|./eviegompertz", x, y)) gnuplot> print evie(alpha,beta)
> > sh: 0.09400: command not found
> >
> > warning:  internal error--stack not empty!
> >           (function called with too many parameters?)
> > 0.0
> 
> Aaarg, sorry, there is an sprintf missing:
> 
> evie(x, y) = real(system(\
>   sprintf("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y)))
> 
> You can even make it more readable:
> 
> evie_cmd(x, y) = sprintf("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, 
> y)
> evie(x, y) = real(system(evie_cmd(x, y)))
> 
> > gnuplot> help function system
> > Sorry, no help for 'function style system'
> > gnuplot>
> 
> help functions system
> 
> The 's' is crucial here.

That's the power of sprintf. Many thanks.
This is in the help:
  This can be used to import external functions into gnuplot using
  'f(x) = real(system(sprintf("somecommand %f",x)))'

It works with 4.2.

Thanks again for your help, it works fine.

> Juergen
> 
> 
> -------------------------------------------------------------------------
> 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

Re: Is that kind of substitution possible?

[Juergen W. <wie...@fr...>]

> Many thanks for your help, but I just got that:
> gnuplot> evie(x, y) = real(system("echo 90 %f 0 %f 0.1
> 1|./eviegompertz", x, y)) gnuplot> print evie(alpha,beta)
> sh: 0.09400: command not found
>
> warning:  internal error--stack not empty!
>           (function called with too many parameters?)
> 0.0

Aaarg, sorry, there is an sprintf missing:

evie(x, y) = real(system(\
  sprintf("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y)))

You can even make it more readable:

evie_cmd(x, y) = sprintf("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, 
y)
evie(x, y) = real(system(evie_cmd(x, y)))

> gnuplot> help function system
> Sorry, no help for 'function style system'
> gnuplot>

help functions system

The 's' is crucial here.

Juergen

Re: global clean-up?

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

On Thursday 13 March 2008 06:50, Nigel Nunn wrote:
> If cleaning up the code (e.g. removing 2,800 lines for Atari), this
> may be the time to package the remaining global variables into some
> appropriate gnuplot struct.  


Feel free to submit cleanup patches.

> This would make it easy to link gnuplot 
> as a library into larger projects, allowing an arbitrary number of
> plotting panels, say in dockable wxAUI frames.

[shrug] Maybe.  Maybe not.

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: about new feature 'with circles'

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

On Thursday 13 March 2008 20:12, Ethan A Merritt wrote:
> Your fix should work, but I think it may be even simpler to pass
> the style (border or no border) to the routine do_arc().
> I cannot remember if I originally had a reason not to do it that way.

Now I remember. The style parameter is sufficient to tell do_arc() that
a border is wanted, but does not tell what line type to use.

I have applied your fix to CVS with a small change to handle
general line properties via  term_apply_lp_properties().
This is needed because term->linetype() does not know about line styles
or palette or RGB coloring information.

	Ethan

-- 
Ethan A Merritt

Re: Is that kind of substitution possible?

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

On Friday 14 March 2008, Brouard Nicolas wrote:
> Le vendredi 14 mars 2008 à 17:42 +0100, Juergen Wieferink a écrit :
> > Hi,
> >
> > >  gnuplot> alpha="3.51e-5"
> > >  gnuplot> beta="0.09400"
> > >  gnuplot> evie(alpha,beta)= `echo 90.0000  @alpha 0.00000  @beta 
> > > 0.10000 1|./eviegompertz` gnuplot>print evie(alpha,beta)
> > >  4.230246
> > >
> > > where eviegompertz is a private C program which can't be simulated in
> > > gnuplot and just output a value.
> > >
> > > Now I want to just "splot evie(x,y)" where x and y are variables and
> > > not only fixed values. Is it possible to do it? I haven't seen such
> > > similar examples. It may be trivial, sorry.
> >
> > Just use the system function:
> >
> > alpha = 3.51e-5
> > beta  = 0.09400
> > evie(x, y) \
> >   = real(system("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y))
> > print evie(alpha, beta)
> >
> > See "help functions system" for details.
>
> Many thanks for your help, but I just got that:
> gnuplot> evie(x, y) = real(system("echo 90 %f 0 %f 0.1 1|./eviegompertz",
> x, y)) gnuplot> print evie(alpha,beta)
> sh: 0.09400: command not found

That means it is working, so far as gnuplot is concerned.
The error message is from the system, telling you that it is trying
to execute your numerical value as a command.  Probably you
need additional quoting.




> warning:  internal error--stack not empty!
>           (function called with too many parameters?)
> 0.0
> gnuplot> help function system
> Sorry, no help for 'function style system'
> gnuplot>
>
> I will upgrade from 4.2 to latest 4.3 and will tell you.
> Nicolas
>
> > Juergen
> >
> >
> > -------------------------------------------------------------------------
> > 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



-- 
Ethan Merritt
(on the road)

Re: Is that kind of substitution possible?

[Brouard N. <br...@in...>]

Le vendredi 14 mars 2008 à 17:42 +0100, Juergen Wieferink a écrit :
> Hi,
> 
> >  gnuplot> alpha="3.51e-5"
> >  gnuplot> beta="0.09400"
> >  gnuplot> evie(alpha,beta)= `echo 90.0000  @alpha 0.00000  @beta  0.10000
> > 1|./eviegompertz` gnuplot>print evie(alpha,beta)
> >  4.230246
> >
> > where eviegompertz is a private C program which can't be simulated in
> > gnuplot and just output a value.
> >
> > Now I want to just "splot evie(x,y)" where x and y are variables and not
> > only fixed values. Is it possible to do it? I haven't seen such similar
> > examples. It may be trivial, sorry.
> 
> Just use the system function:
> 
> alpha = 3.51e-5
> beta  = 0.09400
> evie(x, y) \
>   = real(system("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y))
> print evie(alpha, beta)
> 
> See "help functions system" for details.

Many thanks for your help, but I just got that:
gnuplot> evie(x, y) = real(system("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y))
gnuplot> print evie(alpha,beta)
sh: 0.09400: command not found

warning:  internal error--stack not empty!
          (function called with too many parameters?)
0.0
gnuplot> help function system
Sorry, no help for 'function style system'
gnuplot> 

I will upgrade from 4.2 to latest 4.3 and will tell you.
Nicolas




> 
> Juergen
> 
> 
> -------------------------------------------------------------------------
> 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
-- 
Brouard Nicolas <br...@in...>

Re: Is that kind of substitution possible?

[Juergen W. <wie...@fr...>]

Hi,

>  gnuplot> alpha="3.51e-5"
>  gnuplot> beta="0.09400"
>  gnuplot> evie(alpha,beta)= `echo 90.0000  @alpha 0.00000  @beta  0.10000
> 1|./eviegompertz` gnuplot>print evie(alpha,beta)
>  4.230246
>
> where eviegompertz is a private C program which can't be simulated in
> gnuplot and just output a value.
>
> Now I want to just "splot evie(x,y)" where x and y are variables and not
> only fixed values. Is it possible to do it? I haven't seen such similar
> examples. It may be trivial, sorry.

Just use the system function:

alpha = 3.51e-5
beta  = 0.09400
evie(x, y) \
  = real(system("echo 90 %f 0 %f 0.1 1|./eviegompertz", x, y))
print evie(alpha, beta)

See "help functions system" for details.


Juergen

Is that kind of substitution possible?

[Brouard N. <br...@in...>]

I am not so familiar with the recent macros but I am able to something
like: 
 gnuplot> alpha="3.51e-5"
 gnuplot> beta="0.09400"
 gnuplot> evie(alpha,beta)= `echo 90.0000  @alpha 0.00000  @beta  0.10000 1|./eviegompertz`
 gnuplot>print evie(alpha,beta)
 4.230246

where eviegompertz is a private C program which can't be simulated in
gnuplot and just output a value.

Now I want to just "splot evie(x,y)" where x and y are variables and not
only fixed values. Is it possible to do it? I haven't seen such similar
examples. It may be trivial, sorry.


Nicolas
-- 
Brouard Nicolas <br...@in...>

Re: about new feature 'with circles'

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

On Thursday 13 March 2008 18:37, Shigeharu TAKENO wrote:
> 
> (1) I think the inner area and the border of each circle should 
> be drawn at the same time, but the gnuplot of the current version
> draw inner areas of all circles firstly, and draw borders 
> separately such that all borders appear on top of screen. 

Hmm. You are right. This is a problem.

And the filledcurves code must suffer from the same problem,
although no one has ever complained.

Your fix should work, but I think it may be even simpler to pass
the style (border or no border) to the routine do_arc().
I cannot remember if I originally had a reason not to do it that way.

> (2) The clipping of circle borders may work correctly by the graph
> boundary, but inner areas of them may not clipped. But I do not 
> know how the problem will be fixed.

Yes. It could be fixed for PostScript, PDF, and SVG by setting a
clipping boundary.  But I have not thought of a general fix that
will work for all terminals.

	Ethan


 
> I think it may not be match for "set object" and it may also be 
> done by the following:
> 
>   plot 'data' with circles lt 1 fs solid noborder, \
>        '' with circles fs empty border -1
> 
> To draw them at same time for each circle, we must do on the 
> current gnuplot:
> 
>   plot for [i=1:N] 'data' every ::(i-1)::(i-1) with circles \
>     lt 1 fs solid border -1
> 
> By the following patch gnuplot will draw the inner area and the 
> borders of each circle at the same time.
> 
> ----- From Here -----
> --- src/graphics.c.ORG	Mon Feb 25 13:43:35 2008
> +++ src/graphics.c	Fri Mar 14 10:44:01 2008
> @@ -3805,7 +3805,12 @@
>      double radius;
>      struct fill_style_type *fillstyle = &plot->fill_properties;
>      int style = style_from_fill(fillstyle);
> +    int withborder=0;
>  
> +    if (fillstyle->border_linetype != LT_NODRAW
> +	&&  fillstyle->border_linetype != LT_UNDEFINED){
> +	withborder=1;
> +    }
>      for (i = 0; i < plot->p_count; i++) {
>  	if (plot->points[i].type == INRANGE) {
>  	    x = map_x(plot->points[i].x);
> @@ -3816,26 +3821,12 @@
>  	    if ((plot->lp_properties.pm3d_color.value < 0.0)
>  		&& (plot->lp_properties.pm3d_color.type == TC_RGB))
>  		set_rgbcolor( plot->points[i].yhigh);
> -	   
> +	    if (withborder) (*term->linetype)(plot->lp_properties.l_type);
>  	    do_arc(x,y, radius, 0., 360., style);
> +	    if (withborder) (*term->linetype)(fillstyle->border_linetype);
> +	    do_arc(x,y, radius, 0., 360., 0);
>  	}
>      }
> -
> -    /* Retrace the border if the style requests it */
> -    if (fillstyle->border_linetype != LT_NODRAW
> -    &&  fillstyle->border_linetype != LT_UNDEFINED) {
> -	(*term->linetype)(fillstyle->border_linetype);
> -
> -	for (i = 0; i < plot->p_count; i++) {
> -	    if (plot->points[i].type == INRANGE) {
> -		x = map_x(plot->points[i].x);
> -		y = map_y(plot->points[i].y);
> -		radius = x - map_x(plot->points[i].xlow);
> -		do_arc(x,y, radius, 0., 360., 0);
> -	    }
> -	}
> -    }
> -
>  }
>  #endif
>  
> ----- To Here -----
> 
> 
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> 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
> 

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

about new feature 'with circles'

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

shige 03/14 2008
----------------

I tested new features "with circles" of gnuplot-4.3. 

(1) I think the inner area and the border of each circle should 
be drawn at the same time, but the gnuplot of the current version
draw inner areas of all circles firstly, and draw borders 
separately such that all borders appear on top of screen. 

I think it may not be match for "set object" and it may also be 
done by the following:

  plot 'data' with circles lt 1 fs solid noborder, \
       '' with circles fs empty border -1

To draw them at same time for each circle, we must do on the 
current gnuplot:

  plot for [i=1:N] 'data' every ::(i-1)::(i-1) with circles \
    lt 1 fs solid border -1

By the following patch gnuplot will draw the inner area and the 
borders of each circle at the same time.

----- From Here -----
--- src/graphics.c.ORG	Mon Feb 25 13:43:35 2008
+++ src/graphics.c	Fri Mar 14 10:44:01 2008
@@ -3805,7 +3805,12 @@
     double radius;
     struct fill_style_type *fillstyle = &plot->fill_properties;
     int style = style_from_fill(fillstyle);
+    int withborder=0;
 
+    if (fillstyle->border_linetype != LT_NODRAW
+	&&  fillstyle->border_linetype != LT_UNDEFINED){
+	withborder=1;
+    }
     for (i = 0; i < plot->p_count; i++) {
 	if (plot->points[i].type == INRANGE) {
 	    x = map_x(plot->points[i].x);
@@ -3816,26 +3821,12 @@
 	    if ((plot->lp_properties.pm3d_color.value < 0.0)
 		&& (plot->lp_properties.pm3d_color.type == TC_RGB))
 		set_rgbcolor( plot->points[i].yhigh);
-	   
+	    if (withborder) (*term->linetype)(plot->lp_properties.l_type);
 	    do_arc(x,y, radius, 0., 360., style);
+	    if (withborder) (*term->linetype)(fillstyle->border_linetype);
+	    do_arc(x,y, radius, 0., 360., 0);
 	}
     }
-
-    /* Retrace the border if the style requests it */
-    if (fillstyle->border_linetype != LT_NODRAW
-    &&  fillstyle->border_linetype != LT_UNDEFINED) {
-	(*term->linetype)(fillstyle->border_linetype);
-
-	for (i = 0; i < plot->p_count; i++) {
-	    if (plot->points[i].type == INRANGE) {
-		x = map_x(plot->points[i].x);
-		y = map_y(plot->points[i].y);
-		radius = x - map_x(plot->points[i].xlow);
-		do_arc(x,y, radius, 0., 360., 0);
-	    }
-	}
-    }
-
 }
 #endif
 
----- To Here -----


(2) The clipping of circle borders may work correctly by the graph
boundary, but inner areas of them may not clipped. But I do not 
know how the problem will be fixed.

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

Readline of MacOS

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

Hello,

There is a system problem on macos which means that the readline  
doesn't work as well as it does on other platforms. I know that we  
sorted this out several months ago. And the solution was to replace  
the symlinks readline.h and libreadline with the gnu version.

Before I hack my system to make is work better, could somebody that  
has done this post a guide?

Cheers,

Dan

Re: Calling all Atari geezers - Hello, anyone there?

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

Hello,

Thanks for the explanation!

Cheers,

Dan.

Re: Calling all Atari geezers - Hello, anyone there?

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

On Thursday 13 March 2008 02:41, Daniel wrote:
> Hi,
> 
> A bit off topic but what are the things that change between platforms?  
> What's the need for the ifdefs. In a naïve voice I say "Code is just  
> code right"?

Examples:

- Age of C compiler+library.  E.g. Ancient libc may not provide strncmp()
  and friends, but we really want to use these if possible.

- File handling.  E.g. MS Windows requires (or at least it used to)
  special treatment of binary files.

- Standards compliance. E.g. does the platform support pipes or not?
  If it does support pipes, do they work reasonably (MSWin: no).
  Does it support internationalization via LOCALE?
  Signal handling?

- Floating point support.  Gnuplot dates back to a time when different
  hardware implemented different representations for floating point
  numbers, with corresponding differences in precision and range.
  Even today there are differences in floating point exception handling
  and support for Inf and Nan.  Large chunks of code and data in
  specfun.c exist to deal with these idiosyncrasies.  One the one hand
  they are probably outdated, but on the other hand they are pretty well
  hidden from the rest of the code so it doesn't bother me that much.

- Mousing support. This is probably the worst tangle.  The mousing
  support offered by x11, windows, pm, OSX, and wxWidgets all use different
  mechanisms.  We try to deal with all of them using shared code, but it
  requires a lot of conditional code.  As a historical side note, there
  were well-intentioned projects like GIGI that aimed to provide a unified
  platform-independent API for graphics interaction. None of them ever
  gained much traction in the real world. Gnuplot has a GIGI driver too:-)

- Not platform-dependence, but another source of #ifdef tangles:
  New features (the ones marked EXPERIMENTAL) have been added to CVS with
  their code bracketed by #ifdef FEATURE_NAME ... #else ... #endif.
  This makes it a bit easier to debug problems, and allows people to
  save a [small] bit of space when compiling the program if they don't
  need the feature.  However, to my knowledge none of the individual
  selectable features makes even 1% difference in program size, so I
  don't find that particular rationale very compelling.

	Ethan


> On 13 Mar 2008, at 03:35, Allin Cottrell <cot...@wf...> wrote:
> 
> > On Wed, 12 Mar 2008, Ethan Merritt wrote:
> >
> >> We could lighten the gnuplot codebase by 2800+ lines if we drop
> >> our current pretense of atari support.  I am dubious that the
> >> current CVS tree would compile on this platform...
> >
> > You're the one doing the great bulk of the work here, but in
> > looking at the gnuplot code I'm struck by how difficult to read
> > many sections are, on account of the multiple ifdefs for various
> > seriously archaic OSes.  Getting rid of atari seems like a good
> > start.
> >
> > Allin Cottrell
> >
> > --- 
> > ----------------------------------------------------------------------
> > 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
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

global clean-up?

[Nigel N. <nn...@gm...>]

If cleaning up the code (e.g. removing 2,800 lines for Atari), this
may be the time to package the remaining global variables into some
appropriate gnuplot struct.  This would make it easy to link gnuplot
as a library into larger projects, allowing an arbitrary number of
plotting panels, say in dockable wxAUI frames.

Nigel

Re: Calling all Atari geezers - Hello, anyone there?

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

Hi,

A bit off topic but what are the things that change between platforms?  
What's the need for the ifdefs. In a naïve voice I say "Code is just  
code right"?

Dan




On 13 Mar 2008, at 03:35, Allin Cottrell <cot...@wf...> wrote:

> On Wed, 12 Mar 2008, Ethan Merritt wrote:
>
>> We could lighten the gnuplot codebase by 2800+ lines if we drop
>> our current pretense of atari support.  I am dubious that the
>> current CVS tree would compile on this platform...
>
> You're the one doing the great bulk of the work here, but in
> looking at the gnuplot code I'm struck by how difficult to read
> many sections are, on account of the multiple ifdefs for various
> seriously archaic OSes.  Getting rid of atari seems like a good
> start.
>
> Allin Cottrell
>
> --- 
> ----------------------------------------------------------------------
> 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

Re: Calling all Atari geezers - Hello, anyone there?

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

On Wed, 12 Mar 2008, Ethan Merritt wrote:

> We could lighten the gnuplot codebase by 2800+ lines if we drop 
> our current pretense of atari support.  I am dubious that the 
> current CVS tree would compile on this platform...

You're the one doing the great bulk of the work here, but in 
looking at the gnuplot code I'm struck by how difficult to read 
many sections are, on account of the multiple ifdefs for various 
seriously archaic OSes.  Getting rid of atari seems like a good 
start.

Allin Cottrell

Re: 3-D plot and Windows terminal

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

On Wed, 12 Mar 2008, Tatsuro MATSUOKA wrote:

> http://www.ring.gr.jp/pub/text/TeX/ptex-win32/utils/

> Here perhaps you find prebuild cvs version of gnuplot 2008-03-08 
> because the upload date is 03-09.

Thanks for the pointer.  I figured out the source of my problem: I 
forgot to define WIN_IPC when building wgnuplot.exe.  Duh!

Alliun Cottrell

Calling all Atari geezers - Hello, anyone there?

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

We could lighten the gnuplot codebase by 2800+ lines if we drop our
current pretense of atari support.  I am dubious that the current
CVS tree would compile on this platform.

- I can find no evidence on the web that any version of gnuplot
  since 3.7 has been successfully built for atari.

- The most recent serious mention of gnuplot that I can find on an
  atari newsgroup is a 1997 post by Theo Hopman that gnuplot 3.6beta
  could be compiled. (OK, there was a 2006 flamefest on
  fr.comp.sys.atari where references to gnuplot were lobbed like
  hand grenades, but I believe we can ignore that). 

- "Due to declining membership, The Ol' Hackers Atari Users Group
   closed its doors after its final meeting in December 2000"
                                 -  http://www.atariarchives.org/
   Searching for "gnuplot" on this web site turns up essentially
   nothing.

- Emulators for Atari do exist (http://www.cheek.org/atari/emulator.htm)
  but seem only to be used by the "retro gaming" community.

Do any Atari sentimentalists want to champion their cause?



Here is a diffstat for removal of atari-related code from CVS
of several months back:

[2] diffstat remove_ATARI_20oct2007.patch
 NEWS                |    1
 config/README       |    4
 config/makefile.amg |    5
 config/makefile.mto |  238 ---------------
 config/makefile.st  |  158 ----------
 config/makefile.unx |    2
 config/term_pc.h    |   16 -
 configure.in        |    4
 docs/Makefile.in    |    4
 docs/doc2texi.el    |    8
 docs/gnuplot.doc    |   60 ---
 docs/gpcard.tex     |    2
 src/command.c       |   99 ------
 src/corplot.c       |    3
 src/fit.c           |   27 -
 src/gadgets.c       |    7
 src/gnuplot.prj     |   60 ---
 src/gp_types.h      |    2
 src/help.c          |   12
 src/internal.c      |   34 --
 src/makefile.all    |    4
 src/makefile.awc    |    4
 src/plot.c          |   48 ---
 src/plot.h          |    3
 src/readline.c      |  124 --------
 src/readline.h      |    4
 src/show.c          |    9
 src/standard.c      |  211 -------------
 src/syscfg.h        |   33 --
 src/term.c          |   12
 src/term.h          |   16 -
 src/variable.c      |    2
 term/atariaes.trm   |  787 ----------------------------------------------------
 term/atarivdi.trm   |  488 --------------------------------
 term/multitos.trm   |  421 ---------------------------
 35 files changed, 56 insertions(+), 2856 deletions(-)

-- 
Ethan A Merritt

Re: 3-D plot and Windows terminal

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

Hello 

http://www.ring.gr.jp/pub/text/TeX/ptex-win32/utils/
Here perhaps you find prebuild cvs version of gnuplot 2008-03-08 because the upload date is 03-09.

Regards

Tatsuro
 
--- Allin Cottrell <cot...@wf...> wrote:

> On Tue, 11 Mar 2008, Hans-Bernhard Br将モker wrote:
> 
> > Allin Cottrell wrote:
> > > I just noticed that in a build of fairly recent CVS gnuplot (i.e. 
> > > about 4 weeks ago) for MS Windows, the manipulation of 3-D 
> > > plots seems to be broken.
> > 
> > I don't see any such problem in current (2008-03-08) CVS.
> 
> OK, thanks; I'll try building current CVS.
> 
> Allin Cottrell> -------------------------------------------------------------------------
> 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: 3-D plot and Windows terminal

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

On Tue, 11 Mar 2008, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> > I just noticed that in a build of fairly recent CVS gnuplot (i.e. 
> > about 4 weeks ago) for MS Windows, the manipulation of 3-D 
> > plots seems to be broken.
> 
> I don't see any such problem in current (2008-03-08) CVS.

OK, thanks; I'll try building current CVS.

Allin Cottrell