Unable to install on Strawberry Perl 5.26 (Windows 10) #96
Comments
|
Alien::Gnuplot tries to install gnuplot, but it has a limited repertoire. I don’t think that part ever worked quite right on Strawberry Perl.
… On Feb 2, 2023, at 12:20 PM, Phil Perry ***@***.***> wrote:
Per our discussion in #94 <#94>, I decided to go ahead and try to install PGG (PDL::Graphics::Gnuplot). I first tried directly installing via cpan>, but it complained that the gnuplot executable wasn't there (I was hoping that Alien::Gnuplot would have something to do with building or installing Gnuplot, but apparently it doesn't).
The gnuplot.info page says that 5.4 is the latest, but somewhere there is a warning that Windows 10 has problems with PGG, so I should stay back at 5.28. I manually downloaded the zip file that claimed to be 5.28, but after unzipping and moving the directories and updating PATH, apparently it was actually 5.5:
C:\Users\Phil\Desktop>gnuplot
G N U P L O T
Version 5.5 patchlevel 0 last modified 2023-01-06
Copyright (C) 1986-1993, 1998, 2004, 2007-2022
Thomas Williams, Colin Kelley and many others
gnuplot home: http://www.gnuplot.info
mailing list: ***@***.***
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')
Terminal type is now 'qt'
Encoding set to 'cp1252'.
gnuplot> q
C:\Users\Phil\Desktop>
Anyway, Gnuplot claims to be successfully installed. Trying again with PGG, it stopped complaining about the gnuplot executable and proceeded to try installing the PDL prerequisite. The log is far to long to include here except for an excerpt, but I'll try to attach the file:
PGG_install.log <https://github.com/PDLPorters/PDL-Graphics-Gnuplot/files/10572480/PGG_install.log>
C:\Users\Phil>cpan
cpan shell -- CPAN exploration and modules installation (v2.34)
Enter 'h' for help.
cpan> i PDL::Graphics::Gnuplot
Database was generated on Thu, 02 Feb 2023 08:11:47 GMT
Module id = PDL::Graphics::Gnuplot
CPAN_USERID ETJ (Ed J ***@***.***>)
CPAN_VERSION 2.023
CPAN_FILE E/ET/ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz
UPLOAD_DATE 2023-01-29
INST_FILE (not installed)
cpan> install PDL::Graphics::Gnuplot
Running install for module 'PDL::Graphics::Gnuplot'
Checksum for C:\STRAWB~1\cpan\sources\authors\id\E\ET\ETJ\PDL-Graphics-Gnuplot-2.023.tar.gz ok
Scanning cache C:\STRAWB~1\cpan\build for sizes
............................................................................DONE
Configuring E/ET/ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite Alien::Gnuplot 0 not found.
Warning: prerequisite PDL 0 not found.
Warning: prerequisite PDL::Transform::Color 0 not found.
Warning: prerequisite Safe::Isa 0 not found.
Generating a gmake-style Makefile
Writing Makefile for PDL::Graphics::Gnuplot
Writing MYMETA.yml and MYMETA.json
ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz
C:\Strawberry\perl\bin\perl.exe Makefile.PL -- OK
Running make for E/ET/ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz
---- Unsatisfied dependencies detected during ----
---- ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz ----
Alien::Gnuplot [requires]
PDL [requires]
PDL::Transform::Color [requires]
Safe::Isa [requires]
Running install for module 'Alien::Gnuplot'
... Alien::Gnuplot claimed successful installation...
... try to install prerequisite PDL
... snip ...
gmake[2]: Leaving directory 'C:/STRAWB~1/cpan/build/PDL-2.081-0/IO/FastRaw'
gmake[2]: Entering directory 'C:/STRAWB~1/cpan/build/PDL-2.081-0/IO/FlexRaw'
"C:\Strawberry\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, '..\..\blib\lib', '..\..\blib\arch')" t/*.t
t/flexraw.t .......... ok
t/flexraw_fortran.t .. ExtUtils::F77: Unable to guess and/or validate system/compiler configuration
ExtUtils::F77: Will try system=MinGW Compiler=GFortran
t/flexraw_fortran.t .. 1/? 'C:\Users\Phil\AppData\Local\Temp\rawnLn4' is not recognized as an internal or external command,
operable program or batch file.
ERROR: code did not create data file C:\Users\Phil\AppData\Local\Temp\rawnLn4_data
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 3.
t/flexraw_fortran.t .. Dubious, test returned 2 (wstat 512, 0x200)
All 3 subtests passed
t/iotypes.t .......... ok
Test Summary Report
-------------------
t/flexraw_fortran.t (Wstat: 512 (exited 2) Tests: 3 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
t/iotypes.t (Wstat: 0 Tests: 14 Failed: 0)
TODO passed: 1-14
Files=3, Tests=40, 5 wallclock secs ( 0.08 usr + 0.02 sys = 0.09 CPU)
Result: FAIL
Failed 1/3 test programs. 0/40 subtests failed.
gmake[2]: *** [Makefile:623: test_dynamic] Error 255
gmake[2]: Leaving directory 'C:/STRAWB~1/cpan/build/PDL-2.081-0/IO/FlexRaw'
gmake[1]: *** [Makefile:751: subdirs-test_dynamic] Error 2
gmake[1]: Leaving directory 'C:/STRAWB~1/cpan/build/PDL-2.081-0/IO'
gmake: *** [Makefile:1077: subdirs-test_dynamic] Error 2
Lockfile removed.
ETJ/PDL-2.081.tar.gz
C:\STRAWB~1\c\bin\gmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports ETJ/PDL-2.081.tar.gz
Stopping: 'install' failed for 'PDL'.
Failed during this command:
ETJ/PDL-2.081.tar.gz : make_test NO
cpan> i PDL::Graphics::Gnuplot
Module id = PDL::Graphics::Gnuplot
CPAN_USERID ETJ (Ed J ***@***.***>)
CPAN_VERSION 2.023
CPAN_FILE E/ET/ETJ/PDL-Graphics-Gnuplot-2.023.tar.gz
UPLOAD_DATE 2023-01-29
MANPAGE PDL::Graphics::Gnuplot - Gnuplot-based plotting for PDL
INST_FILE (not installed)
cpan>
[Feel free to relocate this report to the PDL issues if you wish]
So where does this leave me? It sounds like PGG is trying to install a lot of bells and whistles that I may not need. All I want is a way to do batch processing, by sending some sort of command file or stream to gnuplot, seeing what the reported status is, and retrieving and displaying the produced PNG or SVG file. Is PGG massive overkill for this? If I can't get PGG to install without heroic efforts, I can try a system() call to gnuplot with either a temporary file for input or a pipe. Would that work?
—
Reply to this email directly, view it on GitHub <#96>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJTGNVUJTGFBTFA7A35GPDWVQCJXANCNFSM6AAAAAAUPNJAR4>.
You are receiving this because you are subscribed to this thread.
|
|
I've played with some of the demos a little bit, directly running Gnuplot in batch mode. Sometimes this works fine, other times in complains that it can't load the default config. Sometimes it produces a possibly corrupt PNG file (Photo viewer says "we don't support this format") -- I haven't tried it with other viewers or with PDF::Builder. I don't see any rhyme or reason about this. It is good to comment out with # the Does anyone else have experience with running in batch mode like this? It would be easy enough to use |
|
From the times I've tried to use pipes to deal with PNG output on Windows (with other tools), I find that PNGs get corrupted. I'm not sure why, but Windows could be doing unwanted encoding or CRLF translation. In code where I need to get PNG output, I special case Windows to write PNGs to temporary files instead of using pipes / redirection. Non-binary formats such as SVG might fare better. The issue of Gnuplot + pipes on Windows 10 is being followed here #79 and is known upstream and will be fixed in the next release of Gnuplot (v5.4.6). You want to install Gnuplot 5.2.8 from https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.8/ to get the last released version that works with pipes on Windows 10. |
|
In this case, I wasn't using pipes at all (that I'm aware of, just command line), although redirecting STDOUT to a file may conceivably have corrupted something in the PNG (binary data, line-ends, etc.). It did work in a few cases. I found something helpful in https://stackoverflow.com/questions/29625776/how-to-save-a-graph-through-command-line-with-gnuplot . Set 'output' to the file name (instead of redirecting) and I no longer get corrupted PNGs. I still get occasional complaints about being unable to load the default config file. Also, some of the demos appear to want to write multiple output files, but this seems to permit only one. If I can't find how to specify multiple output names, it's no great harm to allow only one plot per call. I'm looking to give a user of a Perl program using the PDF::Builder library who wants to include plots a number of ways to do it. One is a separately created PNG or SVG image file from running Gnuplot separately -- PDF::Builder is merely told to embed this image file. Two is a premade .dem file,, (the name) sent to PDF::Builder, who sends it on to command-line Gnuplot and retrieves the file and embeds it. Three would be to call a routine to accept the data/commands needed to generate the plot, and either write a temp file or pipe it in some way into Gnuplot, and either retrieve the image file or pipe its contents back in for embedding. Finally, there's the use of PDL::Graphics::Gnuplot to make it all seamless in some fashion, although I'm becoming concerned that it's going to add a huge amount of unnecessary overhead for the simple task I want to do. Any reports of experiences doing such things (and tips) are welcome, although it would still be nice to get PGG on Windows straightened out anyway. Once/if I start using pipes (PGG's internals?) I may have to downgrade to Gnuplot 5.2.8. |
|
This is now fixed with the just released Gnuplot 5.4.6. |
|
Maybe some related packages got fixed in the meantime? I haven't touched Gnuplot (5.5.0?) itself, but I just retried the installation of PGG 2.023 (same as before) and this time it claims to have succeeded. It did complain about problems with the (optional) install of OpenL::GLUT 0.72. I still don't know if I'm going to require the use of PGG for PDF::Builder plot generation. It may be simpler to use Gnuplot directly in batch mode, rather than piping data in and images out via PGG -- I have yet to see. I really don't need any interactive capabilities. Thank you for your time and effort on this -- I'm sure there are many who will make use of the interactivity. |
|
If you've got the infrastructure in place already to ship stuff out to Gnuplot, go for it! PGG encapsulates that in a way that sort of insulates you (aside form installation snafus) from that layer -- and that it probably the main benefit for you in your particular case. If your own workflow is already working, then you're off to the races anyway. |
Per our discussion in #94, I decided to go ahead and try to install PGG (PDL::Graphics::Gnuplot). I first tried directly installing via cpan>, but it complained that the gnuplot executable wasn't there (I was hoping that Alien::Gnuplot would have something to do with building or installing Gnuplot, but apparently it doesn't).
The gnuplot.info page says that 5.4 is the latest, but somewhere there is a warning that Windows 10 has problems with PGG, so I should stay back at 5.28. I manually downloaded the zip file that claimed to be 5.28, but after unzipping and moving the directories and updating PATH, apparently it was actually 5.5:
Anyway, Gnuplot claims to be successfully installed. Trying again with PGG, it stopped complaining about the gnuplot executable and proceeded to try installing the PDL prerequisite. The log is far to long to include here except for an excerpt, but I'll try to attach the file:
PGG_install.log
[Feel free to relocate this report to the PDL issues if you wish]
So where does this leave me? It sounds like PGG is trying to install a lot of bells and whistles that I may not need. All I want is a way to do batch processing, by sending some sort of command file or stream to gnuplot, seeing what the reported status is, and retrieving and displaying the produced PNG or SVG file. Is PGG massive overkill for this? If I can't get PGG to install without heroic efforts, I can try a
system()call to gnuplot with either a temporary file for input or a pipe. Would that work?The text was updated successfully, but these errors were encountered: