Ilya Zakharevich on Thu, 19 Jan 2006 00:28:55 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Graphic support in CVS


On Wed, Jan 18, 2006 at 03:43:26PM +0100, Karim Belabas wrote:
> > Did you try to report this to the author of Term::Gnuplot?  1/2 ;-)

> I think I did (about 2 or 3 years ago), with mixed results : we tracked it
> down to an "improper" installation of perl.

And, IIRC, I added code to Term::Gnuplot to detect and circumvent this
situation.

> Just tried it again on my work machine (out-of-the-box Mandriva-10.1):
> Term::Gnuplot fails to compile because libgd could not be found and a -lgd
> linking flag is included

Sigh.  No, this means that gd library was present (at least in *some*
form), gd headers were present, but the linking failed...

> [ /usr/lib/libgd.so.2 exists, but no /usr/lib/libgd.so link, which would
> require some silly *-dev package to be installed first, I presume. ].

I can't deduce any trick which would detect such silly a misconfiguration...

> I fixed the link, and now get
> * Configure --graphic=builtin.X11-gnuplot-dynamic
> gives me a working X graphing engine, but only ASCII-based gnuplot
> terminals are supported (dumb, latex, etc.) The others yield things like

Are you sure?  You linked in gd, so gd terminals should work too.
Depending on what you have in your gd, something like this (from the docs)

? plotfile("aaa.png")
%1 = 1
? plotterm("png=300,200")
%2 = 1
? ploth(x=-1,20,sin(x^3))
%3 = (-1.000000000000000000 20.00000000000000000 -0.9999945670949001996
0.9999972749521035542)
? \q
Good bye!

> If it could be made as an independant module that may be included without
> including any complicated hook in the PARI distribution, that would be fine
> Then the gnuplot interface could be recovered, provided something like
> 
>   install Term::Gnuplot
>   Configure --graphic=gnuplot

I do not think this worths a lot.  Major point of gnuplot terminals
was that one does not need to recompile GP/PARI (which is, in my
experience, a major hassle).  Thus having a way to switch stuff at
runtime is tantamount.

> is enough. I'm releasing 2.2.12-beta (==> hopefully 2.3-stable in one
> month or so): a simpler, working, gnuplot interface can be added in
> the 2.4 cycle.

2.3?  Do we have all the usability stuff addressed?  E.g., can one
execute arbitrary GP code from .gprc (or at least a way to load a file
recognizing "~/foo.gp" notation)?

> Esp. there is no need to handle 2 simultaneous graphing engines (X / gnuplot),
> or dynamic run-time loading.

IMO, dynamic loading is a must.  What is a problem?  Suppose there is
no #define magic; all the information about plotting engine is in one
structure, accessed through a pointer.  One should be able to
dynamically switch this (e.g., via a function loaded dynamically via
install()).

Yours,
Ilya