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

Re: Heavy weight deps (was y scaling error)

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

On Wed, 07 Nov 2007 06:53:57 +0100, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

> On Tuesday 06 November 2007 19:33, pl...@pi... wrote:
>> On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt
>> <merritt@u.washington.edu> wrote:
>>
>> >
>> >> I'm using gnuplot on ARM embedded. At the moment it's running on a=
  =

>> full
>> >> debian image via nfs but when it goes onboard cruft will not be an=

>> >> option.
>> > The major consideration in building a lightweight gnuplot executabl=
e
>> > is which terminal drivers to include.  But the LaTeX terminals are =
 =

>> pretty
>> > small, so disabling them isn't likely to save any space unless you
>> > disable
>> > PostScript support as well.  I made a chart 2 years ago for version=
  =

>> 4.0
>> >      =

>> http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bl=
oat
>> > I should update it against current CVS.
>>
>>
>> Thanks, that new info will be very useful. Sounds like my ./configure=
  =

>> arg
>> list is going to be rather long!
>>
>> Is there a more concise way to get a bare bones gnuplot
>> --without-terminals and just add in the one that I need , svg?
>
> Interesting question.
> I see that it's hard to turn off a lot of the auto-detected stuff.
> For instance, doing
>   ./configure --disable-wxwidgets --disable-cairo
> nevertheless detects and links against the cairo and pango libraries, =
 =

> even
> though it doesn't actually build the wxt or cairo terminals.  Stupid.
> And just removing the library references from the Makefile doesn't wor=
k
> either, because it still tries to compile gp_cairo.c.  Not that  =

> gp_cairo.o
> is very big, but it's annoying.
>
>
> Here's my go at it:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
%%%
> ./configure --without-x --without-gd \
>             --disable-wxwidgets --disable-cairo --disable-mouse
>      echo '#include "svg.trm"' > src/term.h
>      echo '#include "estimate.trm"' >> term.h
> [Manually hack src/Makefile to remove all the cairo/pango related libr=
ary
>  definitions, and the gp_cairo.o target]
>      make
>
> size gnuplot
>    text    data     bss     dec     hex filename
>  631437   30580   14432  676449   a5261 gnuplot
>
> ldd gnuplot
>         linux-gate.so.1 =3D>  (0xffffe000)
>         libreadline.so.5 =3D> /lib/libreadline.so.5 (0xb7f2d000)
>         libncurses.so.5 =3D> /lib/libncurses.so.5 (0xb7ee8000)
>         libz.so.1 =3D> /lib/libz.so.1 (0xb7ed5000)
>         libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0xb7cfb000)
>         libm.so.6 =3D> /lib/tls/libm.so.6 (0xb7cd6000)
>         libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0xb7ccb000)
>         libc.so.6 =3D> /lib/tls/libc.so.6 (0xb7b9c000)
>         libdl.so.2 =3D> /lib/libdl.so.2 (0xb7b98000)
>         /lib/ld-linux.so.2 (0xb7f75000)
>
> ./gnuplot
> gnuplot> set term
> Available terminal types:
>               svg  W3C Scalable Vector Graphics driver
>           unknown  Unknown terminal type - not a plotting device
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
%%%%
>
> Are you sure you don't want at least a few more output options?
>
> svg by itself is pretty horrible for pm3d or image plots.
> Normally if you're creating svg pages, you would embed links to png
> images instead.
>
> Adding libgd would get you png, jpeg and gif (including animated gif).=

> Although if you want nice fonts then it'll drag in libfreetype, which
> isn't so lightweight.  By the time you have libgd, libpng, libfreetype=
,
> that's probably an additional hit equal in size to gnuplot itself.
> Of course those are shared libraries, so if you're using them for
> something else already they are essentially free.
>
> And it's probably worth including dumb.trm, if only for debugging.
>
> Will there be a user interface of any sort, or will it be entirely
> script-driven?
>
>

Thanks for all the detail, it looks like I should get quite close to wha=
t  =

I want with all that.

The application is a headless hardware monitoring system. My aim is to  =

provide continual realtime data viewing with svg and apache so in  =

principal that one terminal is enough. SVG seems ideally suited to plots=
  =

since it allows zooming in for detail and is way lighter than png.

Since svg rendering is getting pretty stable on Opera, konqueror and  =

Firefox I think this will do the job.

Most of it will be automatic updates running off cron or triggered by th=
e  =

monitoring software.

I'm not too close to installing on the board yet, but I'm running native=
  =

ARM over nfs during the development stage. I'll get back to this in deta=
il  =

once I get to hone all this down to fit on the board.

Many thanks for your help.

Peter.

Re: Heavy weight deps (was y scaling error)

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

On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
> For instance, doing
>   ./configure --disable-wxwidgets --disable-cairo
> nevertheless detects and links against the cairo and pango libraries, even
> though it doesn't actually build the wxt or cairo terminals.

False alarm.  It should have been
    ./configure --disable-wxwidgets --without-cairo

It's a pity that enable/disable and with/without aren't treated
as synonyms.  How is anyone supposed to remember which one goes
with which option?


-- 
Ethan A Merritt

Re: Heavy weight deps (was y scaling error)

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

On Tuesday 06 November 2007 19:33, pl...@pi... wrote:
> On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt  
> <merritt@u.washington.edu> wrote:
> 
> >
> >> I'm using gnuplot on ARM embedded. At the moment it's running on a full
> >> debian image via nfs but when it goes onboard cruft will not be an  
> >> option.
> > The major consideration in building a lightweight gnuplot executable
> > is which terminal drivers to include.  But the LaTeX terminals are pretty
> > small, so disabling them isn't likely to save any space unless you  
> > disable
> > PostScript support as well.  I made a chart 2 years ago for version 4.0
> >     http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat
> > I should update it against current CVS.
> 
> 
> Thanks, that new info will be very useful. Sounds like my ./configure arg  
> list is going to be rather long!
> 
> Is there a more concise way to get a bare bones gnuplot  
> --without-terminals and just add in the one that I need , svg?

Interesting question.
I see that it's hard to turn off a lot of the auto-detected stuff.
For instance, doing
  ./configure --disable-wxwidgets --disable-cairo
nevertheless detects and links against the cairo and pango libraries, even
though it doesn't actually build the wxt or cairo terminals.  Stupid.
And just removing the library references from the Makefile doesn't work
either, because it still tries to compile gp_cairo.c.  Not that gp_cairo.o
is very big, but it's annoying.


Here's my go at it:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
./configure --without-x --without-gd \
            --disable-wxwidgets --disable-cairo --disable-mouse
     echo '#include "svg.trm"' > src/term.h
     echo '#include "estimate.trm"' >> term.h
[Manually hack src/Makefile to remove all the cairo/pango related library
 definitions, and the gp_cairo.o target]
     make

size gnuplot
   text    data     bss     dec     hex filename
 631437   30580   14432  676449   a5261 gnuplot

ldd gnuplot
        linux-gate.so.1 =>  (0xffffe000)
        libreadline.so.5 => /lib/libreadline.so.5 (0xb7f2d000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7ee8000)
        libz.so.1 => /lib/libz.so.1 (0xb7ed5000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7cfb000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7cd6000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ccb000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7b9c000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7b98000)
        /lib/ld-linux.so.2 (0xb7f75000)

./gnuplot
gnuplot> set term
Available terminal types:
              svg  W3C Scalable Vector Graphics driver
          unknown  Unknown terminal type - not a plotting device
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Are you sure you don't want at least a few more output options?

svg by itself is pretty horrible for pm3d or image plots.
Normally if you're creating svg pages, you would embed links to png
images instead.

Adding libgd would get you png, jpeg and gif (including animated gif).
Although if you want nice fonts then it'll drag in libfreetype, which 
isn't so lightweight.  By the time you have libgd, libpng, libfreetype,
that's probably an additional hit equal in size to gnuplot itself.
Of course those are shared libraries, so if you're using them for
something else already they are essentially free.

And it's probably worth including dumb.trm, if only for debugging.

Will there be a user interface of any sort, or will it be entirely
script-driven?


-- 
Ethan A Merritt

Re: Heavy weight deps (was y scaling error)

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

On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt  
<merritt@u.washington.edu> wrote:

>
>> I'm using gnuplot on ARM embedded. At the moment it's running on a full
>> debian image via nfs but when it goes onboard cruft will not be an  
>> option.
> The major consideration in building a lightweight gnuplot executable
> is which terminal drivers to include.  But the LaTeX terminals are pretty
> small, so disabling them isn't likely to save any space unless you  
> disable
> PostScript support as well.  I made a chart 2 years ago for version 4.0
>     http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat
> I should update it against current CVS.


Thanks, that new info will be very useful. Sounds like my ./configure arg  
list is going to be rather long!

Is there a more concise way to get a bare bones gnuplot  
--without-terminals and just add in the one that I need , svg?

thx

Re: Heavy weight deps (was y scaling error)

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

On Tuesday 06 November 2007 00:35, pl...@pi... wrote:
> 
> Is there a way to remove these heavy dependancies? 
> It seems you are about as keen on emacs as I am and tetex is a monster.

They are not really dependencies, except in the sense that if the
autoconfigure script finds them installed it may try to use them.
Certainly once the program is built it cares nothing about either
emacs or TeX.

Or at least that's the intent.  I've had repeated troubles with the
emacs test (it tries to write to a system directory, which means 
normal users get an error message).  I'm not aware of any problems
with building on a system without TeX installed.  Then again, I'm
a TeX user so most of my machines have it :-) 

> I'm using gnuplot on ARM embedded. At the moment it's running on a full  
> debian image via nfs but when it goes onboard cruft will not be an option.

The major consideration in building a lightweight gnuplot executable
is which terminal drivers to include.  But the LaTeX terminals are pretty
small, so disabling them isn't likely to save any space unless you disable
PostScript support as well.  I made a chart 2 years ago for version 4.0
    http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat
I should update it against current CVS.

-- 
Ethan A Merritt

Heavy weight deps (was y scaling error)

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

On Mon, 05 Nov 2007 18:02:32 +0100, Ethan Merritt  
<merritt@u.washington.edu> wrote:

>
>> > I am convinced that the texinfo system is far more trouble
>> > than it is worth.
>>
>> I'll second that
>>
>> > Perhaps it should be removed from the
>> > default build.  We distribute a copy of gnuplot.texi anyway,
>> > so there's not normally a need for the user to rebuild it.
>> >
>>
>> It's also a huge dep. pkg IRCC it's about an order of magnitude bigger
>> than gnuplot! I had some trouble compiling tetex
> You are still confusing TeX  (tetex) and gnu info.
> Gnu info is only large because of emacs.  I find both info and emacs
> unusable, but I keep emacs installed on one machine so that I can
> regenerate gnuplot.texi from time to time
> But the really huge package is TeX (tetex), which is something else
> altogether.
>

Many thanks Ethan, the touch sorted out my installation problem.

Is there a way to remove these heavy dependancies? It seems you are about  
as keen on emacs as I am and tetex is a monster.

One of the very appealing features of gnuplot is that it's a fully  
featured but lightwieght plotting tool. It seems a bit incongruous to have  
heavy deps for what seem to be accessory features.

I'm using gnuplot on ARM embedded. At the moment it's running on a full  
debian image via nfs but when it goes onboard cruft will not be an option.

BTW I was very favourably surprised how quickly it ran on that arch. A  
credit to both the power/wieght ratio of the ARM and the power/volume  
ratio of gnuplot.

Kudos to all concerned.

;)

Re: y scaling error

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

On Monday 05 November 2007 07:54, pl...@pi... wrote:
> > What version of Emacs is it trying to use?
> >
> 
> emacs-22.1-r1
> on Gentoo ~x86
> 
> > I applied a patch last week that supposedly accommodated
> > more recent versions of Xemacs.  It worked for me here,
> > but I suppose it could be the culprit.
> > Try reverting this change:
> 
> What does that bug no. refer to? Where's the patch?

Gentoo bug:
	http://bugs.gentoo.org/show_bug.cgi?id=194216 
Gnuplot report:
	http://sourceforge.net/tracker/index.php?func=detail&aid=1822610&group_id=2055&atid=102055

You obviously don't really care about gnuplot.texi.
I suggest you just do:
	touch .../docs/gnuplot.texi
after that the make system should ignore it.  In fact, now that I
think about it, that's probably why you are just noticing the problem now.
Because I applied that gentoo patch, one of the dependencies in the source
tree is now newer than gnuplot.texi.  So "make" is trying to rebuild it
even though nothing has really changed.  Just do the "touch" and forget it.

> > 2007-10-30  Christian Faulhammer (v-...@us...)
> >         * docs/doc2texi.el: Gentoo patch to allow for changed handling of
> >         newlines in up-coming version of XEmacs. Needed in order to
> >         regenerate gnuplot.texi on such a system.
> >         Bug #1822610
> >

> > I am convinced that the texinfo system is far more trouble
> > than it is worth.
> 
> I'll second that ;)
> 
> > Perhaps it should be removed from the
> > default build.  We distribute a copy of gnuplot.texi anyway,
> > so there's not normally a need for the user to rebuild it.
> >
> 
> It's also a huge dep. pkg IRCC it's about an order of magnitude bigger  
> than gnuplot! I had some trouble compiling tetex

You are still confusing TeX  (tetex) and gnu info.
Gnu info is only large because of emacs.  I find both info and emacs
unusable, but I keep emacs installed on one machine so that I can 
regenerate gnuplot.texi from time to time :-)

But the really huge package is TeX (tetex), which is something else
altogether.

-- 
Ethan A Merritt

Re: y scaling error

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

On Mon, 05 Nov 2007 15:58:45 +0100, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Monday 05 November 2007 01:12, pl...@pi... wrote:
>>
>> Unfortunatley I can't check out current cvs because it fails to build
>> without doc
>>
>>
>>    529  ./prepare
>>    530  ./configure --without-tutorial
>>    531  make
>>    532  make install
>
> --without-tutorial has nothing to do with gnuplot.texi
> It is for of the gnu info system, not the TeX documentation.
>
>
>> make[1]: Leaving directory `/svn/gnuplot/src'
>> Making install in docs
>> make[1]: Entering directory `/svn/gnuplot/docs'
>> ../mkinstalldirs /usr/local/share/gnuplot/4.3
>> /usr/bin/install -c -m 644 gnuplot.gih
>> /usr/local/share/gnuplot/4.3/gnuplot.gih
>> Creating texinfo
>> Symbol's value as variable is void: load
>> make[1]: *** [gnuplot.texi] Error 255
>> make[1]: Leaving directory `/svn/gnuplot/docs'
>> make: *** [install-recursive] Error 1
>> bash-3.2#
>
> What version of Emacs is it trying to use?
>

emacs-22.1-r1
on Gentoo ~x86

> I applied a patch last week that supposedly accommodated
> more recent versions of Xemacs.  It worked for me here,
> but I suppose it could be the culprit.
> Try reverting this change:

What does that bug no. refer to? Where's the patch?

>
> 2007-10-30  Christian Faulhammer (v-...@us...)
>         * docs/doc2texi.el: Gentoo patch to allow for changed handling of
>         newlines in up-coming version of XEmacs. Needed in order to
>         regenerate gnuplot.texi on such a system.
>         Bug #1822610
>
> I am convinced that the texinfo system is far more trouble
> than it is worth.

I'll second that ;)

> Perhaps it should be removed from the
> default build.  We distribute a copy of gnuplot.texi anyway,
> so there's not normally a need for the user to rebuild it.
>

It's also a huge dep. pkg IRCC it's about an order of magnitude bigger  
than gnuplot!
I had some trouble compiling tetex which was needed for gnuplot and had to  
do some digging to avoid it. If it can be taken out of default it seems  
like a good move.

Wasn't there another option like --without-doc that I don't seem to see  
any more?


Thanks, Peter.

Re: y scaling error

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

On Monday 05 November 2007 01:12, pl...@pi... wrote:
> 
> Unfortunatley I can't check out current cvs because it fails to build  
> without doc
> 
> 
>    529  ./prepare
>    530  ./configure --without-tutorial
>    531  make
>    532  make install

--without-tutorial has nothing to do with gnuplot.texi
It is for of the gnu info system, not the TeX documentation.


> make[1]: Leaving directory `/svn/gnuplot/src'
> Making install in docs
> make[1]: Entering directory `/svn/gnuplot/docs'
> ../mkinstalldirs /usr/local/share/gnuplot/4.3
> /usr/bin/install -c -m 644 gnuplot.gih  
> /usr/local/share/gnuplot/4.3/gnuplot.gih
> Creating texinfo
> Symbol's value as variable is void: load
> make[1]: *** [gnuplot.texi] Error 255
> make[1]: Leaving directory `/svn/gnuplot/docs'
> make: *** [install-recursive] Error 1
> bash-3.2#

What version of Emacs is it trying to use?

I applied a patch last week that supposedly accommodated
more recent versions of Xemacs.  It worked for me here,
but I suppose it could be the culprit.
Try reverting this change:

2007-10-30  Christian Faulhammer (v-...@us...)
        * docs/doc2texi.el: Gentoo patch to allow for changed handling of
        newlines in up-coming version of XEmacs. Needed in order to
        regenerate gnuplot.texi on such a system.
        Bug #1822610

I am convinced that the texinfo system is far more trouble
than it is worth.  Perhaps it should be removed from the
default build.  We distribute a copy of gnuplot.texi anyway,
so there's not normally a need for the user to rebuild it.


-- 
Ethan A Merritt

Re: y scaling error

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

On Mon, 05 Nov 2007 10:12:33 +0100, <pl...@pi...> wrote:

> Hi,
>
> running cvs build from about a week back I am getting scaling errors on a
> simple temp vs time plot.
>
> the y data is getting streched to fit the full y range. The cursor
> displays y values that match the data but the "with lines" plot goes from
> x axis to top even though the data does not cover that range.
>
> my y data goes from 17 - 70 , if I set a yrange 0:80 the plot goes 0-80 ,
> if I let gnuplot set the range it does 10-70 as expected but the plot
> starts from 10 not 17 as per the data.
>

appologies, red herring. I had x1y2 slipped by me during a copy-paste, so  
not y scale problem.


Install issue remains.

regards,


>
> Unfortunatley I can't check out current cvs because it fails to build
> without doc
>
>
>    529  ./prepare
>    530  ./configure --without-tutorial
>    531  make
>    532  make install
>
>
> ...
>
> make[1]: Leaving directory `/svn/gnuplot/src'
> Making install in docs
> make[1]: Entering directory `/svn/gnuplot/docs'
> ../mkinstalldirs /usr/local/share/gnuplot/4.3
> /usr/bin/install -c -m 644 gnuplot.gih
> /usr/local/share/gnuplot/4.3/gnuplot.gih
> Creating texinfo
> Symbol's value as variable is void: load
> make[1]: *** [gnuplot.texi] Error 255
> make[1]: Leaving directory `/svn/gnuplot/docs'
> make: *** [install-recursive] Error 1
> bash-3.2#
>
>
> I got this after running   cvs up -P gnuplot  on a cvs tree that did
> compile and install a short while ago. To check again I did a fresh cvs  
> co
> gnuplot and got the same error.
>
> Am I missing a step or has --without-tutorial got an issue?
>
> I suspect the plot error was already there but I had not noticed
>
> Any suggestions?
>
> TIA, Peter.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

y scaling error

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

Hi,

running cvs build from about a week back I am getting scaling errors on a  
simple temp vs time plot.

the y data is getting streched to fit the full y range. The cursor  
displays y values that match the data but the "with lines" plot goes from  
x axis to top even though the data does not cover that range.

my y data goes from 17 - 70 , if I set a yrange 0:80 the plot goes 0-80 ,  
if I let gnuplot set the range it does 10-70 as expected but the plot  
starts from 10 not 17 as per the data.


Unfortunatley I can't check out current cvs because it fails to build  
without doc


   529  ./prepare
   530  ./configure --without-tutorial
   531  make
   532  make install


...

make[1]: Leaving directory `/svn/gnuplot/src'
Making install in docs
make[1]: Entering directory `/svn/gnuplot/docs'
../mkinstalldirs /usr/local/share/gnuplot/4.3
/usr/bin/install -c -m 644 gnuplot.gih  
/usr/local/share/gnuplot/4.3/gnuplot.gih
Creating texinfo
Symbol's value as variable is void: load
make[1]: *** [gnuplot.texi] Error 255
make[1]: Leaving directory `/svn/gnuplot/docs'
make: *** [install-recursive] Error 1
bash-3.2#


I got this after running   cvs up -P gnuplot  on a cvs tree that did  
compile and install a short while ago. To check again I did a fresh cvs co  
gnuplot and got the same error.

Am I missing a step or has --without-tutorial got an issue?

I suspect the plot error was already there but I had not noticed

Any suggestions?

TIA, Peter.

Current project about wxt

[<tim...@lp...>]

Dear gnuplot developpers,

I would like to inform you about my current projects related to gnuplot. 
Although I have been quite unproductive in terms of CVS commits for the 
last months, I am still thinking about implementing several things, and 
my interest in gnuplot has not vanished.

First, I still have in mind the gnuplot-with-wxt-on-MacOS issues. The 
radical solution is to use a separate process for the "wxt" terminal, as 
it is done for the "x11" terminal. I am currently working on this. It 
involves some work on IPC communication. I have chosen to use a "named 
pipe", which can be extended in the future to become a socket, if 
somebody is ever interested in network transparency at this level. I 
would like the gnuplot-wxt process to be pure GPL, so I won't borrow 
code from gplt_x11.c, but will write fresh lines. It's helping me to 
learn the issues of designing a IPC protocol... and once completed, it 
may be possible to replace some code in gplt_x11.c by the new one, if 
it's technically interesting. Part of the work involves killing the use 
of global variables in gp_cairo.c, such as the "enhanced text" variables 
or the global "term" pointer.

Second, linux distributions are likely to ship gnuplot without the wxt 
terminal, because they don't distribute wxWidgets libraries by default. 
So I plan to write a GTK terminal similar to "wxt", based on the same 
common roots of wxt, pngcairo and pdfcairo, namely the shared cairo and 
pango code.

Once those to items will be completed, I may work on some other ideas, 
such as a pdflatex terminal, or using flex+bison as a parser, or more 
several-terminals-at-a-time interactivity work, or 3D lightning and 
perspective, or whatever idea motivates me enough.

Best regards,

Timothée Lecomte

Re: Building on MacOS 10.5

[<HBB...@t-...>]

Ethan Merritt wrote:

> In a nutshell, the problem is that Leopard ships with a gnu readline
> emulation library built on top of the BSD editline library.  But it is
> not a complete emulation, and the initialization commands are different.

Sounds like anything we would do here would be a waste of breath.  The 
bug is clearly on Apple's end of things, so Apple has to fix it.  If 
every single package that gets affected by this OS bug implements its 
own fix, the problem will only become worse with time, instead of 
better.  By my book, the only sensible approach would be to put an "if 
MacOSX version 10.5, change default to --readline=builtin" into our 
configure.in, assuming that Apple gets their act together before 10.6.

Experience tells us that nothing lasts longer than "temporary 
workarounds" like this.  And they often cause bigger troubles than they 
were originally intended to solve.  E.g., the GIF patent has been dead 
and buried for years now, and we're still suffering the consequences of 
our attempts to accomodate it.

Re: Building on MacOS 10.5

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

[CC'ed to various people who have been helping me sort out OSX installation problems]

I have gnuplot working on OSX 10.4 (Tiger), and a patch queued to
gnuplot CVS to automate this.  However, that is not sufficient for
OSX 10.5 (Leopard).

In a nutshell, the problem is that Leopard ships with a gnu readline
emulation library built on top of the BSD editline library.  But it is
not a complete emulation, and the initialization commands are different.

The most complete description I've found of the problem, and fixes for a
different package (iPython) are here:

  http://www.nabble.com/readline-support-for-OS-X-Leopard-t4670419.html

Another report (in Japanese, but the key parts you can cut-and-paste)

  http://www.python.jp/pipermail/python-ml-jp/2007-October/004150.html

We should aim to get gnuplot's autoconfigure script to recognize this
state of affairs and adapt accordingly.  I'll happy accept volunteer
fixers or guinea pigs testers.
	
	Ethan


On Sunday 28 October 2007 02:54, Daniel Farrell wrote:
> 
> I want to install 4.2.2 on MacOS 10.5, the ./configure step runs  
> smoothly, then make returns errors when it gets to 'version.c'.
> 
> Making version.c returns an 'underfined symbols' error. See below for  
> more details.
> 
> Cheers,
> 
> Dan.
> 
> ___
> 
> Making version.c
> g++  -g -O2   -o gnuplot  alloc.o axis.o breaders.o bitmap.o color.o  
> command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o  
> getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o  
> interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o  
> pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o  
> stdfn.o tables.o term.o time.o unset.o util.o util3d.o variable.o  
> version.o   -lreadline  -lncurses  -lz
> Undefined symbols:
>    "_rl_forced_update_display", referenced from:
>        _restore_prompt in command.o
>    "_rl_ding", referenced from:
>        _alert in mouse.o
>    "_history_list", referenced from:
>        _write_history_list in history.o
>    "_rl_complete_with_tilde_expansion", referenced from:
>        _rl_complete_with_tilde_expansion$non_lazy_ptr in plot.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[3]: *** [gnuplot] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 

-- 
Ethan A Merritt

Re: hypot()

[<HBB...@t-...>]

Philipp K. Janert wrote:
> Can we rely on the hypot() function to exist
> on all platforms that we care about?

No.

> It is part of C99 - is this good enough?

No.  There are way too many platforms out there that don't have C99 yet, 
and some that may never get it (Microsoft, e.g., reportedly decided to 
ignore it completely).

hypot()

[Philipp K. J. <ja...@ie...>]

Can we rely on the hypot() function to exist
on all platforms that we care about?

It is part of C99 - is this good enough?

Best,

		Ph.

Re: gnuplot-beta Digest, Vol 17, Issue 12

[Philipp K. J. <ja...@ie...>]

>
> Message: 1
> Date: Sun, 28 Oct 2007 17:30:36 -0700
> From: Ethan A Merritt <merritt@u.washington.edu>
> Subject: Re: Ggn...@li... crashing for
> 	"hidden3d undefined" ?
> To: gnu...@li...
> Cc: Thomas Sefzick <t.s...@fz...>, Hans-Bernhard Br?ker
> 	<HBB...@t-...>
> Message-ID: <200710281730.36644.merritt@u.washington.edu>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Sunday 28 October 2007 15:11, Hans-Bernhard Br?ker wrote:
> > Mouse interaction doesn't really have much to do with this --- or
> > rather, it shouldn't.
>
> Maybe I mis-understood the original bug report, but certainly the
> problems that I have observed myself are directly due to mouse
> interaction.  What happens, as Thomas described a moment ago, is that
> if you use the middle mouse button to zoom in the vertical, then the
> program dies on an assert test just before the plotted surface
> reaches the edge of the plot area.  There is no particular reason that
> the program could not continue to zoom further; it would just have to
> clip to the top boundary of the plot.   And that is exactly what
> version 4.0 does.  The 1.53 -> 1.54 patch was the exact change that
> broke this.
>


Just to clarify: My original bug report did NOT
involve any mouse interaction. (Although I
have also observed the behavior that Ethan
describes when dragging with middle mouse
button pressed).

By the way, here is another (similar? related?)
problem:

set xyplane at -10
splot exp(-x**2-y**2)

Crashes (but WITHOUT any assertions being
fired).

For comparison:

set xyplane at -0.1
splot exp(-x**2-y**2)

is fine. 

Best,

		Ph.

Re: x11 dashed

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

On Monday 29 October 2007 15:17, Petr Mikulik wrote:
> There is no description in "help x11" about the option "solid|dashed". I 
> think something should be written about this option.
> 
> It seems that "set term x11 dashed" works only for "gnuplot -monochrome". Is 
> this intentional or a bug?

That is not correct. It works fine for color lines.
The problem is more likely that you don't have the dash styles
set in your X resources database.

Try   
  xrdb -merge < Gnuplot.app-defaults
  gnuplot
  gnuplot>  set term x11 dashed
  gnuplot>  test

screenshot attached

-- 
Ethan A Merritt

x11 dashed

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

There is no description in "help x11" about the option "solid|dashed". I 
think something should be written about this option.

It seems that "set term x11 dashed" works only for "gnuplot -monochrome". Is 
this intentional or a bug?

---
PM

Re: Suggestion for dgrid3d

[Philipp K. J. <ja...@ie...>]

Thanks.

I am happy to develop and send in a patch,
provided we can agree that this is a good
path forward and is likely to be adopted if
a sufficiently high-quality implementation is
available.

Best,

		Ph.



On Monday 29 October 2007 14:58, you wrote:
> > > We do consider backward compatibility a bit of a holy grail in this
> > > project.  It's always bad if a change to the program modifies the
> > > result of a previously established usage.  So new features (like a
> > > modified weight function) should always be introduced such that they're
> > > only triggered by commands that would have done nothing useful in
> > > earlier versions.
> >
> > That's fine - this is the reason why I suggested adding
> > an additional (optional) argument to dgrid3d, which
> > allows the user to select the smoothing kernel. It would
> > default to the current kernel (thus not breaking any
> > existing apps), but allows users to make a different
> > choice for new development.
>
> It would be nice to have options in "set dgrid3d" to choose the gridding
> method. Nowadays, the "thin splines method" as an alternative can only be
> chosen at compile time. The run-time option would be much better.
>
> I think this issue has been discussed long time, but it is still not
> implemented.
>
> ---
> PM

Re: Suggestion for dgrid3d

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

> > We do consider backward compatibility a bit of a holy grail in this
> > project.  It's always bad if a change to the program modifies the result
> > of a previously established usage.  So new features (like a modified
> > weight function) should always be introduced such that they're only
> > triggered by commands that would have done nothing useful in earlier
> > versions.
> 
> That's fine - this is the reason why I suggested adding
> an additional (optional) argument to dgrid3d, which 
> allows the user to select the smoothing kernel. It would
> default to the current kernel (thus not breaking any
> existing apps), but allows users to make a different
> choice for new development.

It would be nice to have options in "set dgrid3d" to choose the gridding 
method. Nowadays, the "thin splines method" as an alternative can only be 
chosen at compile time. The run-time option would be much better.

I think this issue has been discussed long time, but it is still not 
implemented.

---
PM

Bug or feature? set xyplane AT ...

[Philipp K. J. <ja...@ie...>]

When playing with set xyplane, I discovered
the following behaviour:

When using set xyplane without the AT keyword,
the vertical lines of the surrounding box (borders)
are extended to the the location of the base
plane (or shortened, as the case may be).

When using set xyplane with the AT keyword,
the vertical lines are unaffected, potentially
leading to strange results.

Example:

All good:
unset xyplane
set border 8191
set xyplane 1
splot [-3:3][-3:3][0:1] exp(-x**2-y**2)

Funny:
unset xyplane
set border 8191
set xyplane at -1
splot [-3:3][-3:3][0:1] exp(-x**2-y**2)

I am not sure whether this is intended behavior
or not. Certainly not critical, but I wanted to point
it out.

(Version info below)

Best,

		Ph.









        G N U P L O T
        Version 4.2 patchlevel 2 
        last modified 31 Aug 2007
        System: Linux 2.6.18.2-34-default

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from http://www.gnuplot.info/faq/

        Send bug reports and suggestions to 
<http://sourceforge.net/projects/gnu
plot>

Compile options:
-READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  

DRIVER_DIR     
= "/home/janert/Gnuplot/Build/Release-4.2.2/build/libexec/gnuplot
/4.2"
GNUPLOT_PS_DIR 
= "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4
.2/PostScript"
HELPFILE       
= "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4
.2/gnuplot.gih"

Re: Ggnuplot-beta@lists.sourceforge.netnuplot crashing for "hidden3d undefined" ?

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

Ethan A Merritt wrote:
> 
> Trials to replace the assert() statements with int_warn() return the
> behaviour to that of 4.0, which is much more user friendly.
> If you try really hard, you can make the program crash.  But the way
> it is now, it crashes whenever you expand the plot even an infinitesimally
> beyond the plot border. This can easily happen while mousing, and
> it's quite annoying.
> 

i did some tests with gnuplot 4.0 patchlevel 0:

regardless what i did
- move the mouse excessively with middle button pressed
- set 'scale' and 'scale_z' to absolutely nonsense values (e.g. set view
60,30,10000,10000)
i didn't succeed in producing a segmentation fault!

i got artefacts, many of them... but no program crash.

this means, replacing the assert statements in version 4.2 doesn't result in
complete version 4.0 behaviour, there are some more differences.
-- 
View this message in context: http://www.nabble.com/Gnuplot-crashing-for-%22hidden3d-undefined%22---tf4688619.html#a13466741
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Suggestion for dgrid3d

[Philipp K. J. <ja...@ie...>]

(snip)
>
> We do consider backward compatibility a bit of a holy grail in this
> project.  It's always bad if a change to the program modifies the result
> of a previously established usage.  So new features (like a modified
> weight function) should always be introduced such that they're only
> triggered by commands that would have done nothing useful in earlier
> versions.

That's fine - this is the reason why I suggested adding
an additional (optional) argument to dgrid3d, which 
allows the user to select the smoothing kernel. It would
default to the current kernel (thus not breaking any
existing apps), but allows users to make a different
choice for new development.

(snip)
> >
> > Yes, that's true. But I think that's exactly what
> > would be nice to have - to put the ability to
> > control the range into the hands of users, who
> > DO know their data!
>
> I'm afraid you're still thing "filter radius" when you now say "range".
> When I say range, I mean the xrange and friends.  That's sufficiently
> controllable by the user.

It seems as if we still have terminology problems.
Yes, I mean "filter radius" - I am obviously not 
talking about the plot range here!

>
> > For example, if I know that
> > my data is very smooth, but not on a grid, I might
> > want to use dgrid3d with a small averaging range,
> > just to get a surface drawn. But when I know my data
> > to be noisy, I might want to have a wide averaging
> > range, to get some of the noise out.
>
> This kind of "range" control is what the power parameter is about.
> The higher the power, the more local the filter.  But it's not a range:
> its effect changes with the distribution of input points.

But the effect is just not very good. Did you ever
check out the samples I show at
	www.philipp-janert.com/gnuplot

There, I show a very "smooth" data set. Using 
dgrid3d on it introduces all kinds of spurious
"wiggles" and NO choice of the power parameter
gets rid of them.

The gaussian kernel on the other hand leads to
quite faithful representation of the data set.

Please: let's get past the discussion of the 
status-quo and instead start to look forward.
I have tried to give several reasons why having
a gaussian kernel can be desirable. If we add
an optional argument, so that users decide
which kernel to use, we don't break any existing
apps. And we provide more value for the users. 
What's wrong with that?

Best,

		Ph.

Re: Ggnuplot-beta@lists.sourceforge.netnuplot crashing =?iso-8859-1?q?for=09?="hidden3d undefined" ?

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

On Sunday 28 October 2007 15:11, Hans-Bernhard Br=F6ker wrote:
>=20
> Mouse interaction doesn't really have much to do with this --- or=20
> rather, it shouldn't.

Maybe I mis-understood the original bug report, but certainly the=20
problems that I have observed myself are directly due to mouse
interaction.  What happens, as Thomas described a moment ago, is that
if you use the middle mouse button to zoom in the vertical, then the
program dies on an assert test just before the plotted surface
reaches the edge of the plot area.  There is no particular reason that
the program could not continue to zoom further; it would just have to
clip to the top boundary of the plot.   And that is exactly what
version 4.0 does.  The 1.53 -> 1.54 patch was the exact change that
broke this.

Actual segfaults or mis-tracking of the vertices doesn't happen
unless/until there is more extreme abuse of the scaling parameters.

Trials to replace the assert() statements with int_warn() return the
behaviour to that of 4.0, which is much more user friendly.
If you try really hard, you can make the program crash.  But the way
it is now, it crashes whenever you expand the plot even an infinitesimally
beyond the plot border. This can easily happen while mousing, and
it's quite annoying.

I am thinking that the assert tests are looking at the wrong thing.
As I read it, they will trigger as soon as the vertical extent of the
plot hits 1.0  in screen coordinates.  Why?  Most of the terminals can
do proper clipping.  Certainly x11 and wxt seem to clip properly if I
remove the assert statements.  Do you recall which terminal was causing
problems when you first put them in?

	EAM



=20
> The key problem are the third and fourth parameter to 'set view', and=20
> how they affect the plot.  From the start these parameters were the=20
> wrong approach to the perceived problem of incomplete space utilization=20
> by 3D plots.  They cause the plot to outside all sensible boundaries ---=
=20
> the graph box, the viewport, and eventually even the page itself.
>=20
> surface_zscale (the fourth argument of 'set view') is the worst of them.=
=20
>   The only effect this parameter reliably has is to blow the plot off=20
> the page.
>=20
> > that's why i think that the y-min/max-values should be checked
> > against some combination of 'surface_scale' and 'surface_zscale'.
>=20
> I think both of these variables should be killed for good.
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742