Missing sub-module of PDL::Graphics::Simple

perlboy_emeritus has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks

I tried for weeks to get the latest PDL (then, 2.083) to build on macOS High Sierra 10.13.6, but all attempts failed resulting in segmentation fault to pdlcore.c with both clang 9 and 10 (the C++ standard changed, among other things, re pre-processor macro expansion). I teach Applied Linear Algebra with PDL, Python3 and R, and I had all this working in HS but with PDL 2.026. I need to run a PDL at least as capable as my well-heeled students (using daddie's money), so, I gave up and bit the bullet and bought a refurbished macBookPro (lots of Intel macs available from M1/M2 migration) that now runs Monterey 12.6.8, darwin 21.6.0, clang 14.0.0. I checked the PDL testers' logs before I spent the $ and verified that PDL 2.084 builds with this version of clang in Monterey. So, the odyssey, not for the faint-hearted, begins...

  I installed XCode 14.0.1 plus its command line tools; OK
  I installed XQuartz; OK
  I installed perlbrew; OK
  I downloaded and built Perl 5.36.1 with perlbrew; OK
  I downloaded macPorts; OK
  I downloaded and built Gnuplot with macPorts; OK,
    when gnuplot is run standalone it sets terminal type to 'aqua'.
  I used cpanm to get first PDL 2.083 and then 2.084; both OK
  I used cpanm to get PDL::Graphics::Simple; OK

I then attempted to run the simplest test script from the PDLBook, to wit:

#!/usr/bin/env perl -w
##!/usr/bin/env perl -wd

use strict;
use Data::Dumper;
use PDL;
use PDL::Graphics::Simple;

$Data::Dumper::Purity = 1;

imag (sin(rvals(200,200)+1));

sleep 10;
exit 0;
__END__
[download]

This fails with "Can't locate PDL/Graphics/PGPLOT/Window.pm in @INC (you may need to install the PDL::Graphics::PGPLOT::Window module)"

So, I did 'cpanm PDL::Graphics::PGPLOT::Window' and the first messages are:

--> Working on PDL::Graphics::PGPLOT::Window
Fetching http://www.cpan.org/authors/id/E/ET/ETJ/PDL-2.084.tar.gz ... 
+OK
Configuring PDL-2.084 ... OK
Building and testing PDL-2.084 ... OK
Successfully installed PDL-2.084
1 distribution installed
[download]

Instead of installing ::Window, it re-installs PDL 2.084, not ::Window.pm, and when I look in site_perl I can verify it did not install that module. Thus, that utterly simple PDL test script fails.

Here is what my ../Simple sub-directory contains:

  -r--r--r--  1 wills  staff  10827 Jan 27  2023 Gnuplot.pm
  -r--r--r--  1 wills  staff  10461 Jan 27  2023 PGPLOT.pm
  -r--r--r--  1 wills  staff  13490 Jan 27  2023 PLplot.pm
  -r--r--r--  1 wills  staff  16637 Jan 27  2023 Prima.pm

and:
../Graphics contains:

  drwxr-xr-x  6 wills  staff    192 Aug 11 17:34 Simple
  -r--r--r--  1 wills  staff  45340 Jan 27  2023 Simple.pm

no PGPLOT/Window.pm

I know this is probably pilot error. What am I missing or doing wrong? Is there perhaps a way to force PDL to use Gnuplot? Simple.pm contains this fragment:

for my $submod(qw/ PGPLOT Gnuplot PLplot Prima /) {
eval "use PDL::Graphics::Simple::$submod;";
}
[download]

Perhaps putting Gnuplot first in that list would be appropriate in macOS since it does not require that Window.pm module?

Comment on Missing sub-module of PDL::Graphics::Simple Select or Download Code

Replies are listed 'Best First'.
Re: Missing sub-module of PDL::Graphics::Simple by cavac (Prior) on Aug 13, 2023 at 11:00 UTC
This looks at first glance like a genuine bug in the PDL distribution. I think you best bet would be to report it on the official Github bug tracker for the project. It seems some of the contributors there are working on bugs regarding MacOS, for example there's a pull request for fixing rendering (i think) on that OS. Since Apples are not the most common systems for Perl devs, you could set up remote access for one or two of the PDL devs if they are interested (use direct messages, not public posts to exchange sensitive information). This could help them test and debug their code without having to buy an expensive piece of equipment. (Essentially, you'd be donating your Mac to the project in exchange for better support for your rich students). PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply]
Re^2: Missing sub-module of PDL::Graphics::Simple by perlboy_emeritus (Scribe) on Aug 13, 2023 at 16:35 UTC
Thank you cavac, I will cross-post on the PDL bug tracker, but here is a bit more information. My last thought in my post was to edit the list of external plot mechanisms in Simple.pm, but neither shuffling the order or even removing all but Gnuplot fail to resolve the issue. So, I tried cpanm PDL::Graphics::Gnuplot, because gnuplot is alive and well on my system. I can plot to XQuartz from stand-alone gnuplot with either terminal set default to 'aqua' (macOS default) or with GNUTERM='x11' set in my zsh environment. However, therein is another issue that may be either related or a second bug with PDL itself. The build log for PDL::Graphics::Gnuplot contains: # Failed test at t/plot.t line 16. # got: 'PDL::Graphics::Gnuplot: Your gnuplot has terminal 'un +known' but it is not supported. # unknown: Unknown term (gnuplot final default) [NS: not a t +erminal] # # You can use the 'terminfo' method for a list of available terminals. # # at /Users/wills/.cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2 +.024/blib/lib/PDL/Graphics/Gnuplot.pm line 2333. # PDL::Graphics::Gnuplot::output(undef) called at /Users/wills/. +cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2.024/blib/lib/PDL/G +raphics/Gnuplot.pm line 2174 # PDL::Graphics::Gnuplot::new("PDL::Graphics::Gnuplot") called a +t /Users/wills/.cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2.02 +4/blib/lib/PDL/Graphics/Gnuplot.pm line 2091 # PDL::Graphics::Gnuplot::gpwin() called at t/plot.t line 14 # eval {...} called at t/plot.t line 14 # ' # expected: '' # Failed test ''Constructor created a plotting object' isa 'PDL::Gra +phics::Gnuplot'' # at t/plot.t line 17. # 'Constructor created a plotting object' isn't defined [download] I can find no way to configure the build environment in PDL::Graphics::Gnuplot to set the terminal type, and the build environment does not recognize the environment variable GNUTERM set to 'x11', even though gnuplot does. There is code in the POD for Gnuplot.pm such as `my $win = gpwin('x11');` that shows how to set gnuplot terminal from inside a PDL script but no explanation of how to configure the interface to gnuplot to get the module to build and pass its tests. Also, quoting from the POD, to wit: gpwin is the PDL::Graphics::Gnuplot exported constructor. It is exported by default and is a synonym for "new PDL::Graphics::Gnuplot(...)". If given no arguments, it creates a plot object with the default terminal settings for your gnuplot. You can also give it the name of a Gnuplot terminal type (e.g. 'x11') and some terminal and output options (see "output"). If I can set GNUTERM='x11' in zsh, and gnuplot recognizes it as its default, why doesn't the Makefile recognize it? Another intreresting observation in the POD is that PDL uses Alien::Gnuplot to discover whether gnuplot is installed and working correctly. If it isn't Alien::Gnuplot will barf and terminate. Mine doesn't but PD::Graphics::Gnuplot will still not build. I know interfacing PDL with an external plotting engine such as gnuplot is not trivial, but neither is getting it to build. As I said, I will cross-post, but getting an answer from the PDL dev group can take a very long time. Any advice from Monks would be very welcome.	[reply] [d/l] [select]
Re^3: Missing sub-module of PDL::Graphics::Simple by NERDVANA (Priest) on Aug 15, 2023 at 01:11 UTC
You might know more about this than me, but I find it odd that you're setting the GNUTERM variable instead of the TERM variable. The latter is the one that all software I know of is looking at.	[reply]
Re^4: Missing sub-module of PDL::Graphics::Simple by perlboy_emeritus (Scribe) on Aug 15, 2023 at 13:46 UTC
Re^3: Missing sub-module of PDL::Graphics::Simple by perlboy_emeritus (Scribe) on Aug 13, 2023 at 18:03 UTC
Insights, insights, insights :-) I don't know if there is an easy fix for this but I discovered that in my perlbrewed perl 5.36.1 there is a gnuplot binary, Version 5.4 patchlevel 6 last modified 2023-02-09, whereas mine built and installed in /opt/local with macPorts is Version 5.4 patchlevel 8 last modified 2023-06-01. The versions themselves are not important, but what is, is that 'unknown' terminal type is coming from the perlbrew version, as in: Terminal type is now 'unknown' set term x11 ^ unknown or ambiguous terminal type; type just 'set terminal' for a list WARNING: Error during initialization The PDL::Graphics::Gnuplot build Make is not using my macPorts gnuplot but this one in perlbrew that may be crippled. Also, this perlbrewed version is not honoring GNUTERM='x11' in zsh. Simply relying on $PATH won't work as 'which gnuplot' already returns the one in /opt/local while the Make in PDL::Graphics::Gnuplot is not. It looks like fetching and building Alien::Gnuplot with cpanm is the source of that gnuplot binary in perlbrew. I'm not sure what the best fix is, to delete all traces of gnuplot in perlbrew or to explore its config. It strikes me as the better solution is to use the macPorts version which probably contains a full implementation of gnuplot. Comments please?	[reply]
Re^4: Missing sub-module of PDL::Graphics::Simple by perlboy_emeritus (Scribe) on Aug 13, 2023 at 20:07 UTC
Re^2: Missing sub-module of PDL::Graphics::Simple by etj (Priest) on Mar 31, 2024 at 17:52 UTC
This looks at first glance like a genuine bug in the PDL distribution The OP's problems are with some PDL::Graphics modules, but PDL is working fine. The PR you refer to was to make PDL::Graphics::TriD build on MacOS, which the OP hasn't tried. Gnuplot is fiendishly hard to interact with programmatically, because it requires talking to an executable over a pipe. This makes it prone to all sorts of cross-platform problems.	[reply]
Re: Missing sub-module of PDL::Graphics::Simple by Anonymous Monk on Aug 14, 2023 at 00:23 UTC
Sorry to hijack your node, I don't have a Mac, but after reading your post I decided to give `PDL::Graphics::Simple` another try here with my Strawberry Perl. Maybe results would be of interest if you have to debug your case further. I installed latest `PDL` (2.084) and `PDL::Graphics::Gnuplot`. The `PDL::Graphics::PGPLOT` (and `::PLplot`) never worked on Strawberry for me, and neither did `PDL::Graphics::Simple`. I vaguely remember couple years ago in PDL's what's new at least some progress was reported with these, but installation still fails as I'm checking now. Looks like the "Can't locate PDL/Graphics/PGPLOT/Window.pm..." message is harmless, if annoying. It comes from eval which leads to unconditional `print $@;` after another eval. Not very nice style. I just commented-out that print. Now to what causes `PDL::Graphics::Simple` tests to fail on Strawberry. Output of `PDL::Graphics::Gnuplot::terminfo(windows)` lists valid options for Windows display. Neither `persist` nor `dashed` are in there. But #142 and further 144,148,150 set them anyway, therefore `PDL::Graphics::Gnuplot` constructor fails. I don't understand the purpose of 142, 148, so I deleted them. On 144, 150 -- deleted everything after `@params`. At last, tests for `PDL::Graphics::Simple` are passing. Same "uninitialized" warnings on 7494 as you report, but otherwise OK. And quite a mess it was.	[reply] [d/l] [select]
Re^2: Missing sub-module of PDL::Graphics::Simple by perlboy_emeritus (Scribe) on Aug 15, 2023 at 00:05 UTC
Thanks for the Strawberry info. I used to run Strawberry in XP before I got my first Mac, still have it, in fact, on my XP in VirtualBox. I also used Active State and gave it a dose of Unix with the MKS-Toolkit. I got that Mac because I wanted Unix on a laptop and it was so challenging to get Linux running on the laptops of that day (2005, or thereabouts: chasing drivers was the pits). Today, if I had to start over from scratch I would just buy a modular laptop from Framework and put Ubuntu up on it, less difficult than getting Ubuntu running in VirtualBox). Those were the days... I still have not nailed down in the Alien tree which module fetched a truly broken pre-built (I think) gnuplot binary and stuffed it into my perlbrew. That binary is brain-dead in a macOS environment because ...drum roll, in macOS I know of only three terminal types that can render graphics, to wit: aqua, wxt and x11, and none of these are in the terminal list returned by set terminal in the broken binary. All are in the binary I built with macPorts. No macOS head would ever fetch such a binary and expect it to work. That's why it returned terminal 'unknown'. I, like probably many perl-heads who use cpanm, take installing modules for granted. It is so easy and reliable that when it isn't, as with this mix of stuff needed to get PDL up and running, it is, or can be non-trivial to debug the failures. I have now resolved before I install any Perl module to first read the docs on cpan or github or wherever that discuss installation issues. Had I done that and found those environment variables I could have saved myself a load of grief. Still, need I say, there is work to be done in the PDL distribution docs and builds to make installing PDL easier. Oops, I just wrote something that's going to get me bashed by one of the devs, who shall remain nameless, but he knows me :-( UPDATE, 8/15/2023 Perusing (snooping) in the build directory for Alien::Gnuplot I discovered that Alien::Gnuplot actually downloaded the source for gnuplot and built it on my machine using clang. However, it failed to build it for macOS because it omitted the terminal definitions for aqua, wxt and x11, the only graphics drivers that are installed by default or can be downloaded (XQuartz) to macOS. Here's why, found in term.h, to wit: /* * term.h: terminal support definitions * Edit this file depending on the set of terminals you wish to support. * Comment out the terminal types that you don't want or don't have, and * uncomment those that you want included. Be aware that some terminal * types will require changes in the makefile LIBS definition. */ Need I say, in total exasperation, the three .h files for these three are commented out. I built my instance of gnuplot with macPorts and it knew to include these terminal defs without any prompting from me. Now granted, it took me at least two hours of valuable time to find these useful fragments of information, even knowing where to look took some hacking, but get real folks, this is a build that base Alien executed on a very recent macOS, and did not even provision to test for darwin (a simple uname in an #ifdef would suffice) and include those headers, since building and testing the gnuplot binary was successful and silent. I installed my own gnuplot and expected it to be used, as I was unaware that another binary would be built and installed without my knowledge in my private Perl tree. The Alien concept is brilliant in conception (the notion of using pipes to connect Perl clients with non-Perl executables, but hiding the details leaves the user up the proverbial creek without a paddle if it doesn't work. Apparently, we all have to be hackers to survive in a modern Perl environment. Could that be why so many new programming heads are embracing Python? I know that's what's being taught in CS, and I use NumPy and SciPy in my own teaching, because my students expect me to be able to answer their questions, but Perl is still hands down more programmer productive than Python (especially non-OOP functional Perl). For example, I write all non-trivial regex in Perl (to use Regexp::Debugger), and put equivalent Python3 code below __END__, because debugging regex in Python sucks. At the moment I can't find this boffo quote from some Perl wag, to wit: "Python is TIMTOWTDI in Perl", but I digress.	[reply]