Re: Graphic support in CVS

["Karim Belabas" <belabas@math.u-bordeaux1.fr>]

[ Sorry, long mail ahead ]

* Ilya Zakharevich [2006-01-16 20:37]:
> On Mon, Jan 16, 2006 at 07:12:57PM +0100, Karim Belabas wrote:
>> I tried unsuccessfully to install Term::Gnuplot on 2 different Linux machines:
>> (Fedora and Mandriva distributions), and both failed to build.
> 
> 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. In the meantime, I succeeded in
hacking something out of the gnuplot sources by defining a list of extra
dummy symbols in graph/gnuplot.c and compiling an ad-hoc libgnuplot.

But the Term::Gnuplot module simply could not be installed in my native
perl environment ( I ended up re-installing everything, including gcc which
couldn't compile the perl version I fetched from CPAN. Eventually, I almost
had it working: the module was installed properly and only a few  tests
failed. ) This was an old Solaris box, no longer worth the trouble.

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

[ /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 fixed the link, and now get

Manifying blib/man3/Term::Gnuplot.3pm
*** ERROR: unterminated F<...> at line 83 in file Gnuplot.pm

which is not fatal. I tried the pari-2.2.11 (october 2005) version:

* Configure --graphic=gnuplot
yields
###
### Could not find gnuplot library in ./gnuplot-linux-i686 ./gnuplot ./../gnuplot-linux-i686 ./../gnuplot ./../../gnuplot-linux-i686 ./../../gnuplot /usr/local/lib /lib /usr/lib /opt/lib /opt/local/lib /opt/gnu/lib /lib/pa1.1 /usr/lib/large /lib/large /usr/lib/small /lib/small /usr/ccs/lib /usc/ucblib /usr/shlib .
###
### You may need to execute
###   ar cr libgnuplot.a version.o util.o term.o bitmap.o stdfn.o
### In the build directory of gnuplot-3.7, and move
### libgnuplot.a to ./gnuplot-linux-i686 or ./gnuplot subdirs
### or to similarly-named directories up the directory tree.

* 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

  (15:17) gp > plotterm("x11")
  %1 = 1
  exec failed: No such file or directory
  (15:17) gp > ploth(x=0,1,x)
    *** ploth: Broken Pipe, resetting file stack....

> > Gnuplot support 
> > 1) complicated quite a bit the Configure scripts, and the relevant graphing code
> > ( swapping functions with #define magic to support simulatneously two
> > graphing engines )
> 
> > 2) did not bring in a major improvement compared to the other plotting engines
> 
> AFAIK, having graphic engine available BY DEFAULT is a major
> improvement.  (To enable graphics, all one needs to do is to install a
> Perl module, which is an automatic process [of course, this assumes it
> succeeds].  There is no need to rebuild GP/PARI, which is NOT an
> automatic process in many cases.)

X is generally available by default.

If not (OSX, Win32), installing fltk has become my favourite. And, no, on
the OSX and Win32 systems which I checked, perl was either not installed by
default, or incorrectely installed so that it failed to install
Term::Gnuplot properly without some major intervention (eventually
unsuccessful in some cases). In any case, at least as difficult as
installing fltk.

> > 3) was at the best of times quite difficult to build ( I failed more often
> > than not when trying to compile gnuplot support ).
> 
> Same may be said about building GP/PARI.

I do not think this is true. Math::Pari is difficult to compile, yes,
because it must be integrated as a perl module, must support a lot of pari
versions, and is not frequently tested by the core PARI development team
while using a number of undocumented PARI internals. (So we inadvertently
break it, times and times again.)

> > 4) was not trivial to integrate with the new implementation of 
> > rectdraw0 / gen_rectdraw0.
> 
> I may have some time to do this.

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

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.

Esp. there is no need to handle 2 simultaneous graphing engines (X / gnuplot),
or dynamic run-time loading. The old system (e.g. using dynamic addressing
tables and #define magic to change symbol names) was far too clever for our
own good.

Cheers,

    Karim.

> > 6) brought in legal difficulties [ the gnuplot license is not so permissive ]
> 
> I do not think the code of the shim is anyway bound by the gnuplot
> license.

Doesn't Term::Gnuplot contain code modules taken verbatim from some gnuplot
sources ? (the old ad-hoc libgnuplot certainly did).

-- 
Karim Belabas                  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]