Karim Belabas on Wed, 18 Jan 2006 16:10:41 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Graphic support in CVS |
[ 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]