Ilya Zakharevich on Sun, 05 Feb 2006 01:07:07 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Graphic support in CVS |
This is a resent, do not think it managed to pass through qsec the previous times... Subject: Re: Graphic support in CVS Message-ID: <20060118232944.GE805@powdermilk.math.berkeley.edu> References: <20051124043610.GE8459@powdermilk.math.berkeley.edu> <20060116181257.GB1445@math.u-bordeaux.fr> <20060116185007.GA331@powdermilk.math.berkeley.edu> <20060118144325.GA9861@math.u-bordeaux.fr> Content-Type: text/plain; charset=us-ascii In-Reply-To: <20060118144325.GA9861@math.u-bordeaux.fr> On Wed, Jan 18, 2006 at 03:43:26PM +0100, Karim Belabas wrote: > > > 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. So, here our experience differs. I do not think I had GP/PARI compile out-of-the-box on more than 10% of "public" systems (ones with a separate system administrator) I was on. > > > 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 ? It does. But with dynamic loading (which I favor much over the static one) only the shim is visible from GP/PARI. GP/PARI has no way to know that the shim APIs may be translated to low-level Gnuplot API; these are details of implementation of Term::Gnuplot subject to change at any moment... Hope this helps, Ilya