| Subject: | Strawberry PDL edition on Windows cannot display plots out of the box |
It appears that the PDL edition of Strawberry Perl 5.30.1.1 for Windows is shipped with a version of Alien::Gnuplot (v1.033 from 2013) that cannot detect the shipped version of gnuplot (v5.2 patchlevel 6), and that the shipped version of gnuplot cannot be used (on Windows 10) by this version of PDL anyway.
The very first PDL example from the PDL Book (May 2015 version, Chapter 2, page 3) to display a plot fails on Windows 10 for the PDL Edition of Strawberry Perl 5.30.1.1. The input is:
Show quoted text
pdl> use PDL::Graphics::Simple
pdl> imag (sin(rvals(200,200)+1))
and the response is:
Trying gnuplot (PDL::Graphics::Gnuplot)...nope
Trying pgplot (PDL::Graphics::PGPLOT::Window)...nope
Trying plplot (PDL::Graphics::PLplot)...nope
Trying prima (PDL::Graphics::Prima)...nope
Runtime error: Sorry, all known plotting engines failed. Install one and try again.
I expected this to succeed because gnuplot (v5.2 patchlevel 6) is included in the distribution (as BASE/c/bin/gnuplot.exe). The PDL edition is recommended (at http://pdl.perl.org/?page=install) as the "absolute easiest way" to install PDL on Windows, but its usefulness is limited if it cannot produce plots out of the box and if no instructions are given for how to easily achieve this.
I tracked down one cause of the problem: The version of Alien::Gnuplot (v1.033) included in the distribution (at BASE/perl/vendor/lib/Alien/Gnuplot.pm) can't locate this version of gnuplot because it tries but fails to capture the output of gnuplot's 'show version' command, and then incorrectly concludes that there is no gnuplot. The Alien::Gnuplot code dates back to 2013; presumably it worked with the then-current versions of Perl and gnuplot, but it doesn't with the current versions. This cause might also apply to bug #124984.
I fixed the Alien::Gnuplot problem on my local system by changing the Windows-specific code in Alien::Gnuplot::load_gnuplot to
if($^O =~ /MSWin32/i) {
if( $exec_path =~ m/([\"\*\?\<\>\|])/ ) {
die "Alien::Gnuplot: Invalid character '$1' in path to gnuplot -- I give up" ;
}
use Win32::Job;
my $job = Win32::Job->new;
open my $ofh, ">$file";
if (defined $ofh) {
my $pid = $job->spawn(undef, qq{"$exec_path" ${file}_gzinta},
{ no_window => 1, stdout => $ofh, stderr => $ofh });
if (defined $pid) {
$job->run(3); # wait at most 3 seconds for job to finish
}
}
}
but don't know if that patch is suitable for general use (because of the new dependency on Win32::Job on Windows).
With this patch applied, running the PDL example yields:
Trying gnuplot (PDL::Graphics::Gnuplot)...PDL::Graphics::SImple: Gnuplot exists but yours doesn't support either the x11 or wxt terminal
Trying pgplot (PDL::Graphics::PGPLOT::Window)...nope
Trying plplot (PDL::Graphics::PLplot)...nope
Trying prima (PDL::Graphics::Prima)...nope
Runtime error: Sorry, all known plotting engines failed. Install one and try again.
so now gnuplot is found, but doesn't meet some apparently essential requirements regarding the gnuplot terminal to use. Updating PDL to version 2.020 didn't help.
If I start that version of gnuplot manually and run the 'set terminal' command to get a list of available terminal types, then indeed x11 and wxt are not in the printed list, but some 40 other terminals (including 'dumb' and 'windows') are.
Given that gnuplot gets shipped with the PDL edition of Strawberry Perl for Windows, apparently it was the intention that PDL can make use of gnuplot to display plots, so I am puzzled that it fails to do so (even when the Alien::Gnuplot problem is fixed).