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

Re: strange plot title in parametric mode

[Thomas S. <t.s...@fz...>]

it seems that the new iteration mechanism made some changes
regarding token counting ("start_token").

may it be that the if-blocks following the comment
    /* Ok, fix up the title to include both the xp and yp plots. */
in "parametric_fixup()" in "plot2d.c"
and 
    /* Ok, fix up the title to include xp and yp plots. */
in "parametric_3dfixup()" in "plot3d.c"
are not needed anymore?


Shigeharu TAKENO wrote:
> 
> shige 05/07 2010
> ----------------
> 
> In parametric mode, plot titles made by gnuplot-4.4.0 may be 
> strange.
> 
> For the commands
> 
>  set parametric
>  plot sin(t),cos(t)
> 
> gnuplot-4.4.0 makes the plot title "sin(t), sin(t),cos(t)" though
> gnuplot-4.2.6 makes "sin(t),cos(t)". For
> 
>  set parametric
>  splot f(u,v),g(u,v),h(u,v)
> 
> gnuplot-4.4.0 makes the title 
> 
>   "f(u,v), f(u,v),g(u,v), f(u,v),g(u,v),h(u,v)"
> 
> though gnuplot-4.2.6 makes "f(u,v),g(u,v),h(u,v)".
> 
> The cvs version of gnuplot may have the same feature as version 
> 4.4.0.
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://old.nabble.com/strange-plot-title-in-parametric-mode-tp28484392p28512273.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Some demos cannot work correct on cvs source (2010-05-08)

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

Hello

--- Hans-Bernhard Br将モker  wrote:

> Actually, it does.  The crucial clue is the second of the errors you 
> found.  It turns out that
> 	
> 	print laplace(0, 0, 0.5)
> 
> works, but
> 
> 	print laplace(0.0, 0.0, 0.5)
> 
> reports 'undefined value'.  My re-implementation of hypot() has a 
> loophole for input value {0,0} that causes it to divide by zero.  I'll 
> fix it ASAP.

I have confirmed your fix on the cvs source. Now all demos go well on the Cygwin and the MinGW.

Thanks!!

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Re: Some demos cannot work correct on cvs source (2010-05-08)

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

Tatsuro MATSUOKA wrote:
> However,
> 2010-05-08  Hans-Bernhard Broeker  <br...@ph...>
> 
> 	* src/eval.c (magnitude): Make implementation robust to overflows
> 	and underflows.
> 
> the above change seems to not cause the directly cause the bug.

Actually, it does.  The crucial clue is the second of the errors you 
found.  It turns out that
	
	print laplace(0, 0, 0.5)

works, but

	print laplace(0.0, 0.0, 0.5)

reports 'undefined value'.  My re-implementation of hypot() has a 
loophole for input value {0,0} that causes it to divide by zero.  I'll 
fix it ASAP.



> 
> I do not figure out what is wrong at present.
> 
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
> http://pr.mail.yahoo.co.jp/gyao/
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Some demos cannot work correct on cvs source (2010-05-08)

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

Hello

I have checked out the cvs source and build it on cygwin and MinGW.
On cygwin, demo freezes at prob.dem.
On MinGW

1. surface1.dem
Hit return to continue (24)

splot [-2:1][-1.5:1.5] mand({0,0},compl(x,y),30)
                                                     ^
"surface1.dem", line 214: All points z value undefined

2.prob.dem
ymax = 1.1 * laplace(mu, mu, b) #Mode of laplace PDF used
       ^
"prob.dem", line 471: undefined value

The above did not occur by the cvs source at 2010-05-06.

However,
2010-05-08  Hans-Bernhard Broeker  <br...@ph...>

	* src/eval.c (magnitude): Make implementation robust to overflows
	and underflows.

the above change seems to not cause the directly cause the bug.

I do not figure out what is wrong at present.


Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Some demos cannot work correct cvs source (2010-05-08)

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

Hello

I have checked out the cvs source and build it on cygwin and MinGW.
On cygwin, demo freezes at prob.dem.
On MinGW

1. surface1.dem
Hit return to continue (24)

splot [-2:1][-1.5:1.5] mand({0,0},compl(x,y),30)
                                                     ^
"surface1.dem", line 214: All points z value undefined

2.prob.dem
ymax = 1.1 * laplace(mu, mu, b) #Mode of laplace PDF used
       ^
"prob.dem", line 471: undefined value

The above did not occur by the cvs source at 2010-05-06.

However,
2010-05-08  Hans-Bernhard Broeker  <br...@ph...>

	* src/eval.c (magnitude): Make implementation robust to overflows
	and underflows.

the above change seems to not cause the directly cause the bug.

I do not figure out what is wrong at present.


Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

strange plot title in parametric mode

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

shige 05/07 2010
----------------

In parametric mode, plot titles made by gnuplot-4.4.0 may be 
strange.

For the commands

 set parametric
 plot sin(t),cos(t)

gnuplot-4.4.0 makes the plot title "sin(t), sin(t),cos(t)" though
gnuplot-4.2.6 makes "sin(t),cos(t)". For

 set parametric
 splot f(u,v),g(u,v),h(u,v)

gnuplot-4.4.0 makes the title 

  "f(u,v), f(u,v),g(u,v), f(u,v),g(u,v),h(u,v)"

though gnuplot-4.2.6 makes "f(u,v),g(u,v),h(u,v)".

The cvs version of gnuplot may have the same feature as version 
4.4.0.

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

Re: minimum installation query

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

On Wed, 23 Jan 2008 12:43:14 +0100, <pl...@pi...> wrote:

> On Wed, 23 Jan 2008 07:10:52 +0100, Ethan A Merritt  
> <merritt@u.washington.edu> wrote:
>
>> On Tuesday 22 January 2008 20:30, you wrote:
>>> On Wed, 23 Jan 2008 02:16:20 +0100, Ethan Merritt
>>> <merritt@u.washington.edu> wrote:
>>>
>>> > Anyhow, FWIW last time I tried to build a minimally-configured  
>>> gnuplot
>>> > it came in at 0.75 MByte for a 32-bit x86 executable image.  If you
>>> > can share libraries with apache, it should be smaller than that for
>>> > an arm executable (I think).
>>>
>>> Thanks for that guide.
>>>
>>> I found that all I needed to bring in was libstdc++ at about 831 kB
>>>
>>> my gnuplot came down to very close to a meg with "-mcpu=arm9 -Os"
>>>
>>>   ./configure --without-x --without-tutorial --without-pdf  
>>> --without-cairo
>>> --disable-wxwidgets --without-gd --with-readline=builtin
>>> --without-documentation --prefix=/debsTS/usr --host=arm-linux
>>>
>>>
>>> Can you see anything I have left in or has it just grown quite a bit  
>>> since
>>> you tried your minimalist trip?
>>
>> You will still get the default set of terminals built with this command.
>> Instead of all the explicit --without-terminalXXX options,
>> just edit .../src/term.h so that it only includes the terminal[s] that  
>> you
>> want.  This procedure is described in the installation instructions.
>> Probably in your case you can strip it all the way down to:
>>
>> term.h:
>> #include "estimate.trm"       /* used for enhanced text processing */
>> #include "svg.trm"            /* my only terminal type */
>>
>>
>>> It's not really a problem now I'm under 2 megs additional but if I'm  
>>> still
>>> carrying cruft it would be nice to strip it out.
>>
>> Other thoughts:
>>
>> - do not assume that the compiler's -s option will produce a smaller  
>> executable.
>>   Yes I know that's its claimed reason for existence, but it doesn't  
>> always work
>>   that way.
>>
>> - stripping the resulting executable (if you haven't already done so)  
>> should
>>   make it considerably smaller at the cost of being harder to debug  
>> errors.
>>
>> - I suspect that the build system is not smart enough to detect that  
>> some of
>>   the component modules are no longer required at all once you have  
>> stripped
>>   out essentially all of the default terminals.  In particular I  
>> suspect that
>>   bitmap.o can be replaced by a null file.  I am certain that you don't  
>> need
>>   mouse.o either, but I think the build system is smart enough to catch  
>> that
>>   one.
>>
>
> Hi,
>
> thanks for pointing out term.h , I'd not wanted to get too far into  
> hacking unless it was really required, I did not realise the code was so  
> well set up for this sort of change. It was well worth the effort it  
> saved me about 250K ;)
>
> O2 came out about the same as Os in size.
>
> I now have 780k or 670k stripped.
>
> Fun as all this is I probably need to focus on actually using it now. My  
> feeling is it's unlikely to get down to <600k whatever I do.
>
> If I need more space I should probably look at reducing libstdc++,  
> that's the killer.
>
> Many thanks for all your help. This has been invaluable and lot less  
> effor than I expected.
>
> regards, Peter.
>

Hi Ethan ,

I've dug this one out again. I'm now working on gcc 4.3.4 gnueabi -  
maverick fpu. (I've made some progress on the segfaults ;) )

I have term.h down to bare svg and enh but I seem to have grown by about  
100k since last time. (This may of course be gcc producing larger code but  
I doubt it to that point).

My current stripped and unstripped sizes are:

13323865 -rwxr-xr-x 1 user users 843771 May  5 15:51 src/gnuplot
13323870 -rwxr-xr-x 1 user users 751432 May  5 15:52 src/gnuplot

One thing I don't seem to be able to get rid off is postscript. I took all  
mention of it out of term.h but I can still see it building , This is  
presumably quite large as well.

Is it a core requirement or can I hack it out somewhere.

Thanks again, Peter.

Re: gnuplot on vista?

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

On Mon, 3 May 2010, Dhruva Kulkarni wrote:

> please let me know if gnuplot is compatible with vista...
> i downloaded and installed gnuplot for windows and ran wgnuplot.exe...which
> opened up a prompt where i entered "plot sin(x)" upon which a new window
> opened but was blank and then it stopped responding.

Yes, gnuplot works fine on Microsoft Windows Vista, insofar as any
program works OK on that operating system.

>From where did you get your wgnuplot.exe?

Allin Cottrell

Re: ICE on ARM

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

On 04/05/10 07:24, Ethan Merritt wrote:
> On Monday 03 May 2010, pl...@pi... wrote:
>> Hi,
>>
>> I'm trying to cross-compile gnuplot with maverick crunch fpu on ARM.
>>
>> I have it building without the fpu code generation but it falls at the
>> first hurdle if I use the FPU.
>>
>> CFLAGS="-O2 -mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp"
>> CXXFLAGS="-O2 -mcpu=ep9312 " ./configure --host=arm --prefix=/rar/root
>> --without-x --without-pdf --without-cairo --without-documentation
>> --disable-wxwidgets --without-lua --without-tutorial
>> --disable-volatile-data  --disable-objects
>>
>> make
>
> [...]
>> arm-maverick-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..  -I../term
>> -I../term -DBINDIR=\"/rar/root/bin\"
>> -DX11_DRIVER_DIR=\"/rar/root/libexec/gnuplot/4.3\"
>                                                ^^^^^
> So your source must be about a year old?  Without a precise date on the source
> it's hard to comment on what pitfalls may lie in that routine.  On the other
> hand, your compiler failure seems to come from the last line of the routine
> so I'm not sure that more precise line numbers would help.
>
>> -DGNUPLOT_PS_DIR=\"/rar/root/share/gnuplot/4.3/PostScript\"
>> -DGNUPLOT_JS_DIR=\"/rar/root/share/gnuplot/4.3/js\"
>> -DCONTACT=\"gnu...@li...\"
>> -DHELPFILE=\"/rar/root/share/gnuplot/4.3/gnuplot.gih\"
>> -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -O2 -mcpu=ep9312
>> -mfpu=maverick -mfloat-abi=softfp -MT axis.o -MD -MP -MF .deps/axis.Tpo
>> -c -o axis.o axis.c
>> axis.c: In function 'gen_tics':
>> axis.c:1163: internal compiler error: Segmentation fault
>> Please submit a full bug report,
>>
>>
>> gen_tics seems to make heavy use of floats , is there any areas that may
>> be a bit flakey on an unusual arch?
>
> Have you tried with -O0 ?
>
>> Clearly this is a major problem with the compiler itself but I'm
>> wondering if there's anything likely to trip it up.
>
> The code tests for loss-of-precision errors that "shouldn't happen".
> I can imagine that this might confuse a software fp library.
> Somewhere around line 1068 you may see a code section that begins
>     if (1) /* (some-test-for-range-and-or-step-size) */
> You could try setting that to  if (0) instead, thus disabling the
> tests for  (x + fabs(delta)<= x).
>
>

Thanks very much Ethan.

-O0 does compile! That at least  means I can get eabi crunch working.
Os O1 and O2 all fail in exactly the same way.

Those ideas enabled me to track down where it's happening. The for-loop 
even with the guts ripped out causes the segfault.

		/* {{{  process minitics */
		double mplace, mtic;
mtic=0;
/*
		for (mplace = ministart; mplace < miniend; mplace += ministep) {
mtic=0;
		}
*/
		/* }}} */

The above compiles , with the for-loop it segs.

It looks pretty innocuous on the face of it but the compiler spits the 
dummy.

There are more if I continue the build. graphics:606
     if (lkey) {
   TBOOLEAN key_panic = FALSE;



BTW this is gcc arm eabi with maverick-crunch FPU support enabled, not 
software fp emulation.  -mfloat-abi=softfp does not mean what one may 
expect ;)

I'll test it built with -O0 and FPU, hopefully it will still be faster 
than software fp.

best regards.

Re: ICE on ARM

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

On Monday 03 May 2010, pl...@pi... wrote:
> Hi,
> 
> I'm trying to cross-compile gnuplot with maverick crunch fpu on ARM.
> 
> I have it building without the fpu code generation but it falls at the 
> first hurdle if I use the FPU.
> 
> CFLAGS="-O2 -mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp" 
> CXXFLAGS="-O2 -mcpu=ep9312 " ./configure --host=arm --prefix=/rar/root 
> --without-x --without-pdf --without-cairo --without-documentation 
> --disable-wxwidgets --without-lua --without-tutorial 
> --disable-volatile-data  --disable-objects
> 
> make

[...]
> arm-maverick-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..  -I../term 
> -I../term -DBINDIR=\"/rar/root/bin\" 
> -DX11_DRIVER_DIR=\"/rar/root/libexec/gnuplot/4.3\" 
                                              ^^^^^
So your source must be about a year old?  Without a precise date on the source
it's hard to comment on what pitfalls may lie in that routine.  On the other
hand, your compiler failure seems to come from the last line of the routine
so I'm not sure that more precise line numbers would help.

> -DGNUPLOT_PS_DIR=\"/rar/root/share/gnuplot/4.3/PostScript\" 
> -DGNUPLOT_JS_DIR=\"/rar/root/share/gnuplot/4.3/js\" 
> -DCONTACT=\"gnu...@li...\" 
> -DHELPFILE=\"/rar/root/share/gnuplot/4.3/gnuplot.gih\" 
> -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -O2 -mcpu=ep9312 
> -mfpu=maverick -mfloat-abi=softfp -MT axis.o -MD -MP -MF .deps/axis.Tpo 
> -c -o axis.o axis.c
> axis.c: In function 'gen_tics':
> axis.c:1163: internal compiler error: Segmentation fault
> Please submit a full bug report,
> 
> 
> gen_tics seems to make heavy use of floats , is there any areas that may 
> be a bit flakey on an unusual arch?

Have you tried with -O0 ?

> Clearly this is a major problem with the compiler itself but I'm 
> wondering if there's anything likely to trip it up.

The code tests for loss-of-precision errors that "shouldn't happen".
I can imagine that this might confuse a software fp library.
Somewhere around line 1068 you may see a code section that begins
   if (1) /* (some-test-for-range-and-or-step-size) */
You could try setting that to  if (0) instead, thus disabling the
tests for  (x + fabs(delta) <= x).

ICE on ARM

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

Hi,

I'm trying to cross-compile gnuplot with maverick crunch fpu on ARM.

I have it building without the fpu code generation but it falls at the 
first hurdle if I use the FPU.

CFLAGS="-O2 -mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp" 
CXXFLAGS="-O2 -mcpu=ep9312 " ./configure --host=arm --prefix=/rar/root 
--without-x --without-pdf --without-cairo --without-documentation 
--disable-wxwidgets --without-lua --without-tutorial 
--disable-volatile-data  --disable-objects

make

make  all-recursive
make[1]: Entering directory `/back/ts/ct-wkg/gnuplot'
Making all in config
make[2]: Entering directory `/back/ts/ct-wkg/gnuplot/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/back/ts/ct-wkg/gnuplot/config'
Making all in m4
make[2]: Entering directory `/back/ts/ct-wkg/gnuplot/m4'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/back/ts/ct-wkg/gnuplot/m4'
Making all in term
make[2]: Entering directory `/back/ts/ct-wkg/gnuplot/term'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/back/ts/ct-wkg/gnuplot/term'
Making all in src
make[2]: Entering directory `/back/ts/ct-wkg/gnuplot/src'
Making all in wxterminal
make[3]: Entering directory `/back/ts/ct-wkg/gnuplot/src/wxterminal'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/back/ts/ct-wkg/gnuplot/src/wxterminal'
make[3]: Entering directory `/back/ts/ct-wkg/gnuplot/src'
arm-maverick-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..  -I../term 
-I../term -DBINDIR=\"/rar/root/bin\" 
-DX11_DRIVER_DIR=\"/rar/root/libexec/gnuplot/4.3\" 
-DGNUPLOT_PS_DIR=\"/rar/root/share/gnuplot/4.3/PostScript\" 
-DGNUPLOT_JS_DIR=\"/rar/root/share/gnuplot/4.3/js\" 
-DCONTACT=\"gnu...@li...\" 
-DHELPFILE=\"/rar/root/share/gnuplot/4.3/gnuplot.gih\" 
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -O2 -mcpu=ep9312 
-mfpu=maverick -mfloat-abi=softfp -MT alloc.o -MD -MP -MF 
.deps/alloc.Tpo -c -o alloc.o alloc.c
mv -f .deps/alloc.Tpo .deps/alloc.Po
arm-maverick-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..  -I../term 
-I../term -DBINDIR=\"/rar/root/bin\" 
-DX11_DRIVER_DIR=\"/rar/root/libexec/gnuplot/4.3\" 
-DGNUPLOT_PS_DIR=\"/rar/root/share/gnuplot/4.3/PostScript\" 
-DGNUPLOT_JS_DIR=\"/rar/root/share/gnuplot/4.3/js\" 
-DCONTACT=\"gnu...@li...\" 
-DHELPFILE=\"/rar/root/share/gnuplot/4.3/gnuplot.gih\" 
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -O2 -mcpu=ep9312 
-mfpu=maverick -mfloat-abi=softfp -MT axis.o -MD -MP -MF .deps/axis.Tpo 
-c -o axis.o axis.c
axis.c: In function 'gen_tics':
axis.c:1163: internal compiler error: Segmentation fault
Please submit a full bug report,


gen_tics seems to make heavy use of floats , is there any areas that may 
be a bit flakey on an unusual arch?

Clearly this is a major problem with the compiler itself but I'm 
wondering if there's anything likely to trip it up.

Thanks for any suggestions, Peter.

gnuplot on vista?

[Dhruva K. <dhr...@gm...>]

dear developers,
please let me know if gnuplot is compatible with vista...
i downloaded and installed gnuplot for windows and ran wgnuplot.exe...which
opened up a prompt where i entered "plot sin(x)" upon which a new window
opened but was blank and then it stopped responding.

thanks,
regards,
dhruva

Re: GNUplot problem

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

On 04/15/10 18:08, Thomas Sefzick wrote:
>
> so, you have two files?
> one with data and one with commands?
> if yes, which commands are in the script file?
>
> which operating system are you using?
> which version of gnuplot?
>
>
> princemahmmod wrote:
>>
>> I think you could not understand my problem. When I plot my file it can be
>> plot but when I am trying to load my file using>  load 'Return Loss.p'
>> Error is showing "util.c: file/directory not found"
>> Please help me what should I do....
>>
>>

Please try to remember this is a development / bug report mailing list , 
not first steps user help and general hand-holding.

Try using the help command from gnuplot command line and report back if 
something is not functioning as it is stated to work in the doc.

/Peter.

>>
>> princemahmmod wrote:
>>>
>>> Hi,
>>> when I am going to load my file is showing..."util.c: file/directory not
>>> found".
>>> However, I can plot my file using command    plot "Return Loss.dat" using
>>> 1:2 title 'column' with linespoints.
>>> May I know how to solve util.c error...???
>>>
>>
>>
>

Re: GNUplot problem

[Thomas S. <t.s...@fz...>]

so, you have two files?
one with data and one with commands?
if yes, which commands are in the script file?

which operating system are you using?
which version of gnuplot?


princemahmmod wrote:
> 
> I think you could not understand my problem. When I plot my file it can be
> plot but when I am trying to load my file using   > load 'Return Loss.p' 
> Error is showing "util.c: file/directory not found"
> Please help me what should I do.... 
> 
> 
> 
> princemahmmod wrote:
>> 
>> Hi,
>> when I am going to load my file is showing..."util.c: file/directory not
>> found".
>> However, I can plot my file using command    plot "Return Loss.dat" using
>> 1:2 title 'column' with linespoints.
>> May I know how to solve util.c error...???
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/GNUplot-problem-tp28248532p28257344.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: GNUplot problem

[Thomas S. <t.s...@fz...>]

'loading' files is for script files, i.e. files containing commands,
not only data.

> gnuplot Return Loss.dat
Cannot open load file 'Return'
"Return", line 0: util.c: No such file or directory

doesn't work due to the space in the filename, and

> gnuplot "Return Loss.dat"
...
"Return Loss.dat", line 1: invalid command

doesn't work because there a no commands in the file.

you need a script file (e.g. 'plot.plot') containing

plot "Return Loss.dat" using 1:2 title 'column' with linespoints.

this file you may load with

>gnuplot plot.plt


princemahmmod wrote:
> 
> Hi,
> when I am going to load my file is showing..."util.c: file/directory not
> found".
> However, I can plot my file using command    plot "Return Loss.dat" using
> 1:2 title 'column' with linespoints.
> May I know how to solve util.c error...???
> 

-- 
View this message in context: http://old.nabble.com/GNUplot-problem-tp28248532p28254426.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: hlp file for windows vista and 7

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

Hello Tait

Thank you for your comprehensive explanations. 

--- Tait  wrote:

> Because so many program force the user to be administrator to run (and
> therefore put the operating system at risk from bugs and malicious code),
  :
(snip)

> We could work around these issues by creating an installer for gnuplot
> on Windows (possibly using Windows Installer, or not) and shipping (a)
> manifest file(s). This would require a lot of Windows-specific effort and
> code. I got out of the messing-with-Windows-Installer business some years
> back, and I don't want to get back into it. Without a willing contributor
> and maintainer, I think it is most friendly for gnuplot to ship the files
> and no installer. Those who need an installer will be able to create an
> installer for their evironment from the files we provide with minimal
> effort.

I personally agree with you.
 
> As for winhlp, Microsoft has made clear it's going the way of the
> dodo bird. The popular thing to do these days seems to be to ship the
> documentation and help as a set of HTML pages (also copied into Program
> Files). When the user requests help, the default browser is simply pointed
> at the appropriate page.

In the gnuplot, there is system to create HTML documentation.
However someone have to work help command of gnuplot command script like 'help plot' 
point to the corresponding the HTML page, some works will be required.

Another choice is to create chm file specially prepared html files and compile them by HTML help
complier.

At any case, voluntary works on the help system will be needed.  To be honest, I do not want to spare
my time for the help issue considering my job and my private conditions.
(Currently my mental condition is not good in these days.)

Regards

Tatsuro

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

Re: hlp file for windows vista and 7

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

> In addition, it is required the files should be copied to 'C:\Program files' as an administrator.
> and remove the *** access block *** that win7 (windows vista) puts on the help file afterwards.
>
> The person who reported this issue suggest to use windows installer for the gnuplot for windows.
>
> Before talking the way of install in the future, I would like to know the current state the security
> setting of the windows vista and 7.

Because so many program force the user to be administrator to run (and
therefore put the operating system at risk from bugs and malicious code),
Microsoft has developed a complicated system of permissions intended to
prevent administrative users from being able to easily cause damage. On
Vista and Seven, an administrative user must request elevated permissions
(i.e. "full" administrative access) before installation. This elevation
is apparently requested automatically if the installer is called
*setup*.exe. More information:
	http://technet.microsoft.com/en-us/library/dd835561%28WS.10%29.aspx
	http://msdn.microsoft.com/en-us/library/bb530410.aspx

There are also integrity access controls to contend with. Processes
with lower integrity levels (e.g. the login/shell) cannot write to
higher-integrity data (e.g. Program Files), regardless of any other access
controls that might say otherwise. More information:
	(briefly) http://blogs.msdn.com/jolson/archive/2007/11/12/what-s-mandatory-integrity-control.aspx
	http://msdn.microsoft.com/en-us/library/bb625964.aspx

There are, of course, the usual discretionary access controls that
prevent non-administrative users from writing to system locations like
Program Files. These are separate from the integrity controls mentioned
above.

I haven't read it, but this sounded like a good resource based on its
title. Sorry about the format; it's not my choice.
	http://code.msdn.microsoft.com/Windows7AppQuality/Release/ProjectReleases.aspx

There are also NTFS streams attached to files downloaded from the internet
that mark those files as potentially unsafe. These streams are propagated
to files extracted from a so-marked zip file. Marked executables require
the user agree to an additional dialog before running. The "potentially
unsafe" mark can be removed via the Unblock button in the file properties,
or via explicitly finding and removing the NTFS stream. Since FAT
filesystems don't support streams, this is a non-issue in those cases
(e.g. USB thumb drives).

We could work around these issues by creating an installer for gnuplot
on Windows (possibly using Windows Installer, or not) and shipping (a)
manifest file(s). This would require a lot of Windows-specific effort and
code. I got out of the messing-with-Windows-Installer business some years
back, and I don't want to get back into it. Without a willing contributor
and maintainer, I think it is most friendly for gnuplot to ship the files
and no installer. Those who need an installer will be able to create an
installer for their evironment from the files we provide with minimal
effort.

As for winhlp, Microsoft has made clear it's going the way of the
dodo bird. The popular thing to do these days seems to be to ship the
documentation and help as a set of HTML pages (also copied into Program
Files). When the user requests help, the default browser is simply pointed
at the appropriate page.

Tait

hlp file for windows vista and 7

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

Hello

In the SourceForge bug tracker, it is reported that wgnuplot.hlp file issue.

http://sourceforge.net/tracker/?func=detail&aid=2984116&group_id=2055&atid=102055

In windows vista and 7, '.hlp' file is not supported  by the default and need to install the
win32hlp.exe.  

In addition, it is required the files should be copied to 'C:\Program files' as an administrator.
and remove the *** access block *** that win7 (windows vista) puts on the help file afterwards.

The person who reported this issue suggest to use windows installer for the gnuplot for windows.

Before talking the way of install in the future, I would like to know the current state the security
setting of the windows vista and 7.  

I do not have windows vista nor 7, I do not know about the security setting of them in detail.
To my knowledge, it is required administrative privileges to copy files to C:\Program Files and treat
files in the C:\Program Files.

Please give the information of windows vista and 7 on the help file and the information administrative
privileges to copy files to and f access files in C:\Program Files.

Regards

Tatsuro

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

Re: postscript dash patterns in parametric vs data plots

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

On Monday 29 March 2010, Mojca Miklavec wrote:
> PS: if it's only about the round-off error - why not putting some
> "lineto" statements every now and then instead of rlineto? I guess
> rlineto result in smaller files, but one doesn't need to "stroke" the
> line in the middle of curve.

That would work to overcome the current problem.  But according to
the comments in post.trm this runs into a separate problem:

    /* Ghostscript has a "pile-up of rounding errors" bug: a sequence of many
     * rmove's or rlineto's does not yield the same line as move's or lineto's.
     * Therefore, we periodically force an update of the absolute position.
     * There was a case when 400 rlineto's were too much, so let's go a little
     * bit higher than the default function sampling rate in gnuplot.
     * This runs into a second ghostscript bug, that mixing relative and absolute
     * lineto with no intervening 'stroke' is ridiculously slow to render.
     * So we stroke the partial line, update the position in absolute terms,
     * then continue.  This whole section can go away if ghostscript/gv is fixed.
     */
#   define MAX_REL_PATHLEN 105
    if (ps_path_count >= MAX_REL_PATHLEN) {
        fprintf(gppsfile, "stroke %d %d M\n", x, y);
        ps_path_count = 1;
    }

I suppose we could make MAX_REL_PATHLEN configurable, and skip the section if
it is set to zero.

So, has ghostscript/gv been fixed during the intervening years? 
I don't know.

Re: postscript dash patterns in parametric vs data plots

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

2010/3/30 Hans-Bernhard Bröker wrote:
>
>> (PS: one could definitely optimize the output with zillions of lines like
>> 2 0 V
>> 2 0 V
>
> Not really one couldn't, because a straight line is a very special case of a
> parametric curve.  The short moves are strictly necessary to make curves
> that actually curve out of straight segments.

One could optimize "if two consecutive line segments are straight and
point to the same direction, remove point in the middle", but this
would not remove the bug.

Mojca

PS: if it's only about the round-off error - why not putting some
"lineto" statements every now and then instead of rlineto? I guess
rlineto result in smaller files, but one doesn't need to "stroke" the
line in the middle of curve.

Re: postscript dash patterns in parametric vs data plots

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

Mojca Miklavec wrote:

> Oh, nice observation. At 104-105-106 gnuplot (or maybe PS terminal)
> most probably starts being a bit more "careful" about too long lines.

That's actually the effect of a bug fix we put in to accomodate 
renderers that accumulate round-off errors if a single PS polyline path 
becomes too long.  That bug fix has been in there for 7 years now.

> (PS: one could definitely optimize the output with zillions of lines like
> 2 0 V
> 2 0 V

Not really one couldn't, because a straight line is a very special case 
of a parametric curve.  The short moves are strictly necessary to make 
curves that actually curve out of straight segments.

Re: postscript dash patterns in parametric vs data plots

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

2010/3/30 Jonathan Thornburg wrote:
> Hi, all,
>
> On Mon, 29 Mar 2010, Hans-Bernhard Br?ker wrote:
>> I'll venture a guess, then: the difference disappears if you use the same
>> number of points for both lines, right?  I.e. if you 'set samples 2' for (a),
>> the two plots will be the same.  Or if you output the sampled function to a
>> data file (--> help table), and plot that in place of the inline data, the two
>> plots will again be the same.
>
> Success!  I've experimented with placing 'set samples N' for various N
> near the start of my test gnuplot script, with the following results
> (this is still using gnuplot 4.2.6 on my computer; I've just downloaded
> gnuplot-4.4.0.tar.gz but haven't compiled/installed it yet):
>        N       result
>        1000    wierd dash pattern for parametric line
>        300     wierd dash pattern for parametric line
>        200     wierd dash pattern for parametric line
>        150     almost-normal dash pattern for parametric line
>                (very slightly different from that for explicit-data
>                 line when viewed at high magnification)
>        100     normal dash pattern for parametric line
>        2       normal dash pattern for parametric line
>
> Moreover, this now explains the apparent system-dependence (i.e.,
> Ethan not being able to reproduce the problem): my personal
>  $HOME/.gnuplot   file contains (among other things) 'set samples 1000'.
>
> Question:  Ethan, do you see the wierd dash patterns (or even the
> same eps file as I do?) if you put 'set samples 1000' at the start
> of my gnuplot script?

Oh, nice observation. At 104-105-106 gnuplot (or maybe PS terminal)
most probably starts being a bit more "careful" about too long lines.

with 'set samples 104':

1 0 V
2 0 V
2 0 V
% End plot #1
% Begin plot #2
stroke

with 'set samples 105':

1 0 V
2 0 V
2 0 V
stroke 1137 882 M
% End plot #1
% Begin plot #2
stroke

with 'set samples 106':

2 0 V
1 0 V
2 0 V
stroke 1135 882 M
2 0 V
% End plot #1
% Begin plot #2
stroke

At least the example with 'set samples 105' seems very weird to me.

Mojca

(PS: one could definitely optimize the output with zillions of lines like
2 0 V
2 0 V
1 0 V
2 0 V
1 0 V
2 0 V
1 0 V
2 0 V
2 0 V
)

Re: postscript dash patterns in parametric vs data plots

[Jonathan T. <jt...@as...>]

Hi, all,

On Mon, 29 Mar 2010, Hans-Bernhard Br?ker wrote:
> I'll venture a guess, then: the difference disappears if you use the same
> number of points for both lines, right?  I.e. if you 'set samples 2' for (a),
> the two plots will be the same.  Or if you output the sampled function to a
> data file (--> help table), and plot that in place of the inline data, the two
> plots will again be the same.

Success!  I've experimented with placing 'set samples N' for various N
near the start of my test gnuplot script, with the following results
(this is still using gnuplot 4.2.6 on my computer; I've just downloaded
gnuplot-4.4.0.tar.gz but haven't compiled/installed it yet):
	N	result
	1000	wierd dash pattern for parametric line
	300	wierd dash pattern for parametric line
	200	wierd dash pattern for parametric line
	150	almost-normal dash pattern for parametric line
		(very slightly different from that for explicit-data
		 line when viewed at high magnification)
	100	normal dash pattern for parametric line
	2	normal dash pattern for parametric line

Moreover, this now explains the apparent system-dependence (i.e.,
Ethan not being able to reproduce the problem): my personal
  $HOME/.gnuplot   file contains (among other things) 'set samples 1000'.

Question:  Ethan, do you see the wierd dash patterns (or even the
same eps file as I do?) if you put 'set samples 1000' at the start
of my gnuplot script?

In any case, I think Hans-Bernhard's guess-which-turns-out-to-be-right
supports Ethan's hypothesis
# I'm guessing that the dot-dash pattern associated with the line is re-started
# for each line segment, so if you draw a line made up of multiple segments
# (as is likely for a parametric curve) the pattern is discontinuous at each
# break point.


There is also still Mojca Miklavec's observation that on a Mac,
Apple's viewer and ps2pdf give different results when viewing the eps
file I uploaded to sourceforge.  Can anyone else on a different type
of computer try viewing the eps file I generated?  I'm at home & don't
have a postscript printer available, though I can try printing this at
work on wednesday.  Of course, some postscript printers internally
use ghostscript (just as my viewer 'gv' does), so consistency there
may not mean quite as much as one might hope.....

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: postscript dash patterns in parametric vs data plots

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

On Mon, Mar 29, 2010 at 23:34, Mojca Miklavec wrote:
> Hello,
>
> I'm sending a minimal example (an EPS file) that reproduces the
> problem (it's exactly the same line that you sent, but shifted and
> with all the overhead removed completely).
>
> Apple's software and ps2pdf give different results. This could be
> called "a bug in renderer" (though I'm not sure whether it's Apple or
> GS that's buggy - it's just inconsistent). I can send screenshots if
> that helps anyone.
>
> The other question is why gnuplot draws two lines (and also: why it
> draws "1 0 rlineto" more than hundred times in a row). I didn't try to
> understand what the gnuplot code does.

I have played with EPS file before. Now I have tried to run your
gnuplot code and the problem disapears even with GS. It now draws only
a single long line as opposed to what it did on your output:

% Begin plot #1
3.000 UL
LT1
LCb setrgbcolor
972 882 M
2 0 V
1 0 V
2 0 V
2 0 V
1 0 V
...
2 0 V
2 0 V
1 0 V
2 0 V
2 0 V
% End plot #1
% Begin plot #2
stroke

You seem to have compiled the example with gnuplot 4.2 patchlevel 6,
while I have gnuplot 4.5 patchlevel 0 (I'm not sure about the exact
version).

Mojca

Re: postscript dash patterns in parametric vs data plots

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

Hello,

I'm sending a minimal example (an EPS file) that reproduces the
problem (it's exactly the same line that you sent, but shifted and
with all the overhead removed completely).

Apple's software and ps2pdf give different results. This could be
called "a bug in renderer" (though I'm not sure whether it's Apple or
GS that's buggy - it's just inconsistent). I can send screenshots if
that helps anyone.

The other question is why gnuplot draws two lines (and also: why it
draws "1 0 rlineto" more than hundred times in a row). I didn't try to
understand what the gnuplot code does.

%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: -2 0 166 40
%%EndComment
10 setlinewidth
[40 20] 0 setdash
% first line
0   10 moveto 104 0 rlineto stroke
104 10 moveto  61 0 rlineto stroke
% second line
0   30 moveto 164 0 rlineto stroke
showpage
%%Trailer

The code corresponds to the following part from your original EPS:

972 883 M
1 0 V
1 0 V
1 0 V
...
1 0 V
stroke 1076 883 M
1 0 V
...
1 0 V
stroke
LT1
LCb setrgbcolor
3112 883 M
164 0 V
1.000 UP
stroke


Mojca