On Mon, Jun 13, 2011 at 3:20 PM, Dima Kogan <[email protected]> wrote: > Hi Chris. > > Unlike plplot and pgplot, Gnuplot is NOT a programming API; rather it's > a standalone interactive application that can also take in input on its > STDIN. Since nothing is being linked, the perl module that talks to > gnuplot can be loaded successfully even if gnuplot isn't installed. > This is why the tests pass (the only test currently implemented is the > 'use PDL::Graphics::Gnuplot' test). Getting better error handling is on > my short-term todo list. I've never touched gnuplot on windows, but I > believe at one point a different executable had to be used in order to > pipe data to it. Does windows even have a concept of "standard input"?
Yes, STDIN, STDOUT, and STDERR are available on win32. It is fork() that is the problem (as in I'm not sure if the implicit fork open with '|- works on win32). > In either case, if this thing is to work on windows, somebody other > than me will have to do the testing and getting it to work there. It *is* difficult to develop for a platform which one does not have or use. I recommend the addition of INSTALL information to your README.pod so folks using your module will know what they need to get it running. Also, a diagnostic check and warning (maybe during the perl Makefile.PL stage) that gnuplot was not found and to see POD or URL... to get it for your platform. > Hopefully that isn't a lot of work. I would like to see Alien::XXX modules for the key external dependencies for PDL that work on win32 and all the other supported PDL platforms. Once that happens, getting a needed dependency is as simple as a 'use Alien::XXX;' in the Makefile.PL. Until we get a factory implementation of Alien::XXX that works on win32, it will have to be manual development... --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
