Weighing in on the PGPLOT licensing -- it is FUD for academic / research users (which I think is most of this list) since the license is OK for "non-commercial use". But it is very real for the various Linux packaging houses, who tend to be on hair triggers as far as license cleanliness goes. At least one distribution (I can't remember whether it was Debian or Suse) wouldn't carry PDL for a while because of the NOAO demo image, which was licensed for non-commercial uses only -- that is why our M51 image is now from Hubble -- Hubble images are public domain.
On the other stuff: I'm pretty ambivalent. There are good reasons to adopt-and-fix something (be it PLPlot or, say, Gnuplot) that already does high level formatting. There are also good reasons to write a new interface layer from scratch. I will gladly support (to whatever degree I can) and build on whatever I can get to work first. I have not yet been able to produce a "hello world" plot with PLplot. On Feb 7, 2010, at 11:43 PM, David Mertens wrote: > Chris - > > I've thought a bit about what you wrote about PLplot. I agree that > the 'right' solution to cross-platform 2d plotting is an interface > between something and OpenGL. I advocate PLplot, but could be > convinced that PGPLOT is the way forward if somebody can figure out > the interface and licensing (or is that just FUD?). I just figured > that removing the z-axis from TriD would be a quick hack that would > spur us on to finally interfacing PLplot with OpenGL. As it is, > OpenGL already renders lines for us, albeit in three dimensions, so > we should be able to use that rendering and force the viewing > orientation to be 'straight on,' right? > > The problem with PLplot at the moment is that it's build process is > so clumsy. Please understand that I do not mean any disrespect to > the PLplot developers: they simply cannot depend on a good shell > scripting language. Cygwin? MinGW? VC++? Each of these have > slightly different build processes, but batch files aren't powerful > enough to detect the differences and act accordingly. The PLplot > people do not release pre-compiled versions of their libraries, > either, which makes sense given the large number of ways you can > configure the library. The only practical approach is the one they > took: to write instructions explaining how to install PLplot by hand. > > However, WE CAN expect Perl to be available, and we can make a > number of assumptions about what we want in our builds of PLplot. > Therefore, I am considering writing some sort of Alien package for > PLplot. Hopefully it will be as simple as wrapping the build of > PLplot in an ExtUtils::MakeMaker script (or Module::Build script, > but I'd need to get a lot of help for that). A first cut would be a > plain-old perl script that attempts to detect the build system and > either builds the makefile or invokes the correct build commands for > PLplot. Among other things, this would eliminate the need for > cmake, which is even worse in my view than requiring a fortran > compiler because the latter would at least be useful for other PDL > modules. If I could get some sort of script that installs it on any > 'reasonable machine' running Perl, we might be able to seriously > consider using PLplot for cross-platform plotting. > > Wish me luck. I'd love to pour time into this but I'm very busy. > I'm sure that describes us all. :-) > > David > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
