Re: [Pdl-general] PDL 2.078
Hi Hernán, Thank you for the feedback! Any further issues or concerns you see, please do raise them. While PDL is pretty good now (at least so I believe), it can always be better, and the best way for that to happen is for people to question things. So please keep doing so, either on here, or by opening a GitHub issue, or whatever other means you feel suitable :-) Best regards, Ed From: Hernán De Angelis<mailto:variablestarli...@gmail.com> Sent: 12 April 2022 18:50 To: Ed .<mailto:ej...@hotmail.com> Cc: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.078 Thank you, Ed. I understand what you mean. I believe now that a previous version of Alien::proj was indeed present so perhaps that was causing som trouble. I also understand what you say about perldl.conf. I guess we can consider this case closed and my questions answered. Thank you all for the help. Hernán Den tis 12 apr. 2022 18:52Ed . mailto:ej...@hotmail.com>> skrev: Hi Hernán, Great to hear your local issue is sorted – thank you to you and Shawn! PDL absolutely will build without Alien::proj. Problems will only arise if it is installed but broken. You can prove this by making a new Perl installation (“perlbrew” is my recommended tool) with no Alien::proj (but with other actual needed deps like File::Map) then install PDL on it. This is also tested on every single commit of PDL which gets built and tested in our continuous integration (CI) in (among many, many other environments) a container on CentOS with minimal deps. perldl.conf as a mechanism is not a suitable vehicle for this, nor really for anything else. The whole Alien concept in Perl was originally invented to solve this class of problems, for PDL. We are sticking with it until a convincing case is made for something better. Best regards, Ed From: Hernán De Angelis<mailto:variablestarli...@gmail.com> Sent: 12 April 2022 12:50 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.078 Dear all, Just to report that thanks to a good collaboration with Shawn we were able to track the problem to an empty "PKG_CONFIG_PATH" in my system. After adding the proper paths now Alien::proj and PDL both compile fast, well and smoothly. It also seems that PDL will not build without Alien::proj. Then the question remains: would it be possible or desirable to be able to build PDL without proj by giving an appropriate flag in perldl.conf? Best regards and thanks to all Hernán Den 2022-04-12 kl. 11:12, skrev Shawn Laffan: It would be useful to be able to build PDL without the proj-dependent components. This could maybe be done using an environment variable, or an argument passed to the ```perl Makefile.PL``` call. Ed would be better placed to comment on this aspect. Alien::proj will not attempt to build from source if it can find existing libs. If it is building from source on a system where proj>6 is installed then there might be an issue with the probes. The probe to find existing installations uses pkg-config. If that is not on your system, or the proj.pc file is not in the PKG_CONFIG_PATH, then Alien::proj will fall back to a source install. (Note - Hernán is following that up separately). Shawn. On Tue, 12 Apr 2022 at 18:06, Hernán De Angelis mailto:variablestarli...@gmail.com>> wrote: Hello Shawn Thanks for your answer. I am not trying to build Alien::proj. I just would like to tell PDL not to care about it. How is it that up to 2.027 this wasn't a problem but it suddenly is in 2.028? I will dig a bit on this and try to find out. I have a dislike of Alien::* since it will install and build things I already have and which I have control over. This may be purely subjective but if I can avoid having this it would be nice. Again, this wasn't a problem before. Why now? I am not asking anyone to work to find it, my question is rather if someone knows of an easy way to bypass having to install Alien::* just to get PDL going, albeit without the functionality provided by proj. I use openSUSE Tumbleweed (rolling release). I have used Linux exclusively since 2005, mostly openSUSE and its predecessors. For the tools I use more often I do not use a package manager (zypper in openSUSE) but I build them (proj, geos, gdal, GRASS GIS, QGIS and others) from source myself. All of them live in /usr/local and subdirectories, properly exported to the path and library path (they actually found each other, no problems there). I normally update Perl modules using CPAN, including PDL, but when troubleshooting is needed I also build from source using the "perl Makefile.pl" method. And yes, I am familiar with Geo::GDAL::FFI. I use it in a couple of projects. It installs and runs fine. Best regards Hernán Den 2022-04-11 kl. 23:57, skrev Shawn Laffan: Hello Hernan, If you ha
Re: [Pdl-general] PDL 2.078
Thank you, Ed. I understand what you mean. I believe now that a previous version of Alien::proj was indeed present so perhaps that was causing som trouble. I also understand what you say about perldl.conf. I guess we can consider this case closed and my questions answered. Thank you all for the help. Hernán Den tis 12 apr. 2022 18:52Ed . skrev: > Hi Hernán, > > > > Great to hear your local issue is sorted – thank you to you and Shawn! > > > > PDL absolutely will build without Alien::proj. Problems will only arise if > it is installed but broken. You can prove this by making a new Perl > installation (“perlbrew” is my recommended tool) with no Alien::proj (but > with other actual needed deps like File::Map) then install PDL on it. This > is also tested on every single commit of PDL which gets built and tested in > our continuous integration (CI) in (among many, many other environments) a > container on CentOS with minimal deps. > > > > perldl.conf as a mechanism is not a suitable vehicle for this, nor really > for anything else. The whole Alien concept in Perl was originally invented > to solve this class of problems, for PDL. We are sticking with it until a > convincing case is made for something better. > > > > Best regards, > > Ed > > > > *From: *Hernán De Angelis > *Sent: *12 April 2022 12:50 > *To: *pdl-general@lists.sourceforge.net > *Subject: *Re: [Pdl-general] PDL 2.078 > > > > Dear all, > > Just to report that thanks to a good collaboration with Shawn we were able > to track the problem to an empty "PKG_CONFIG_PATH" in my system. After > adding the proper paths now Alien::proj and PDL both compile fast, well and > smoothly. > > It also seems that PDL will not build without Alien::proj. Then the > question remains: would it be possible or desirable to be able to build PDL > without proj by giving an appropriate flag in perldl.conf? > > Best regards and thanks to all > > Hernán > > > > Den 2022-04-12 kl. 11:12, skrev Shawn Laffan: > > It would be useful to be able to build PDL without the proj-dependent > components. This could maybe be done using an environment variable, or an > argument passed to the ```perl Makefile.PL``` call. Ed would be better > placed to comment on this aspect. > > > > Alien::proj will not attempt to build from source if it can find existing > libs. If it is building from source on a system where proj>6 is installed > then there might be an issue with the probes. The probe to find existing > installations uses pkg-config. If that is not on your system, or the > proj.pc file is not in the PKG_CONFIG_PATH, then Alien::proj will fall back > to a source install. (Note - Hernán is following that up separately). > > > > Shawn. > > > > On Tue, 12 Apr 2022 at 18:06, Hernán De Angelis < > variablestarli...@gmail.com> wrote: > > Hello Shawn > > Thanks for your answer. > > I am not trying to build Alien::proj. I just would like to tell PDL not to > care about it. How is it that up to 2.027 this wasn't a problem but it > suddenly is in 2.028? I will dig a bit on this and try to find out. I have > a dislike of Alien::* since it will install and build things I already have > and which I have control over. This may be purely subjective but if I can > avoid having this it would be nice. Again, this wasn't a problem before. > Why now? I am not asking anyone to work to find it, my question is rather > if someone knows of an easy way to bypass having to install Alien::* just > to get PDL going, albeit without the functionality provided by proj. > > I use openSUSE Tumbleweed (rolling release). I have used Linux exclusively > since 2005, mostly openSUSE and its predecessors. For the tools I use more > often I do not use a package manager (zypper in openSUSE) but I build them > (proj, geos, gdal, GRASS GIS, QGIS and others) from source myself. All of > them live in /usr/local and subdirectories, properly exported to the path > and library path (they actually found each other, no problems there). I > normally update Perl modules using CPAN, including PDL, but when > troubleshooting is needed I also build from source using the "perl > Makefile.pl" method. And yes, I am familiar with Geo::GDAL::FFI. I use it > in a couple of projects. It installs and runs fine. > > > Best regards > > Hernán > > > Den 2022-04-11 kl. 23:57, skrev Shawn Laffan: > > Hello Hernan, > > > > If you have issues installing Alien::proj then could you please file a bug > report? https://github.com/shawnlaffan/perl-alien-proj > > > > If you have proj installed with its headers then Alien::proj will run a > system
Re: [Pdl-general] PDL 2.078
Hi Luis, The current plan isn’t to make changes to the structure of PDL in any case, since (after some painful fixes to the Fortran stuff a couple of months ago for 32-bit systems) there is no maintenance effort for the Fortran stuff. Regardless, it’s reassuring that you’d be content with such a shift! (After all, this “PDL” thing exists for the benefit of the users) It would be really helpful to know if you found any of those other options were useful replacements for part or all of what Minuit does (I’m not qualified right now to have an opinion), simply so I (or someone!) could add a note to the PDL::Minuit docs. Please let me know if you do make any such finding :-) Ref that PR, I understand how things go! Among other things, I still want to look over Ingo’s OpenCV stuff, and PDL::Stats’s anova stuff is still somewhat broken (which I revisited last year trying to make a nice visual demo for PDL::Stats). Anyone who knows more about statistics than me who wants to help or even offer guidance on that or the OpenCV stuff, please speak up! Best regards, Ed From: Luis Mochan<mailto:moc...@icf.unam.mx> Sent: 12 April 2022 17:14 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.078 On Tue, Apr 12, 2022 at 02:55:08PM +, Ed . wrote: > Hi Luis! > > Glad to hear Minuit is still in use. If it were removed from main > PDL, it would only be to make it available separately on CPAN as > PDL::Minuit (somewhat similar to PDL::FFTW3). That's a good option. > I’m afraid I’m not very knowledgeable about mathematical > optimisation, but I am aware of other options for PDL somewhat in > that sphere: > > * https://metacpan.org/pod/PDL::Opt::NonLinear > * https://metacpan.org/pod/PDL::Opt::QP > * https://metacpan.org/pod/PDL::Opt::Simplex (in main PDL) > * https://metacpan.org/pod/PDL::Fit::LM (in main PDL) > * https://metacpan.org/pod/PDL::Fit::Levmar Thanks! I wasn't aware of those. > Also, once the OpenCV stuff is cracked, that will be an example of a > PDL library using C++, which would then hopefully make a Minuit 2 > interface much easier. > While I think of it, any chance to look at > https://github.com/wlmb/Photonic/pull/23? :-) Sorry about the long delay! Regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Av. Universidad s/n CP 62210 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] PDL 2.078
Hi Hernán, Great to hear your local issue is sorted – thank you to you and Shawn! PDL absolutely will build without Alien::proj. Problems will only arise if it is installed but broken. You can prove this by making a new Perl installation (“perlbrew” is my recommended tool) with no Alien::proj (but with other actual needed deps like File::Map) then install PDL on it. This is also tested on every single commit of PDL which gets built and tested in our continuous integration (CI) in (among many, many other environments) a container on CentOS with minimal deps. perldl.conf as a mechanism is not a suitable vehicle for this, nor really for anything else. The whole Alien concept in Perl was originally invented to solve this class of problems, for PDL. We are sticking with it until a convincing case is made for something better. Best regards, Ed From: Hernán De Angelis<mailto:variablestarli...@gmail.com> Sent: 12 April 2022 12:50 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.078 Dear all, Just to report that thanks to a good collaboration with Shawn we were able to track the problem to an empty "PKG_CONFIG_PATH" in my system. After adding the proper paths now Alien::proj and PDL both compile fast, well and smoothly. It also seems that PDL will not build without Alien::proj. Then the question remains: would it be possible or desirable to be able to build PDL without proj by giving an appropriate flag in perldl.conf? Best regards and thanks to all Hernán Den 2022-04-12 kl. 11:12, skrev Shawn Laffan: It would be useful to be able to build PDL without the proj-dependent components. This could maybe be done using an environment variable, or an argument passed to the ```perl Makefile.PL``` call. Ed would be better placed to comment on this aspect. Alien::proj will not attempt to build from source if it can find existing libs. If it is building from source on a system where proj>6 is installed then there might be an issue with the probes. The probe to find existing installations uses pkg-config. If that is not on your system, or the proj.pc file is not in the PKG_CONFIG_PATH, then Alien::proj will fall back to a source install. (Note - Hernán is following that up separately). Shawn. On Tue, 12 Apr 2022 at 18:06, Hernán De Angelis mailto:variablestarli...@gmail.com>> wrote: Hello Shawn Thanks for your answer. I am not trying to build Alien::proj. I just would like to tell PDL not to care about it. How is it that up to 2.027 this wasn't a problem but it suddenly is in 2.028? I will dig a bit on this and try to find out. I have a dislike of Alien::* since it will install and build things I already have and which I have control over. This may be purely subjective but if I can avoid having this it would be nice. Again, this wasn't a problem before. Why now? I am not asking anyone to work to find it, my question is rather if someone knows of an easy way to bypass having to install Alien::* just to get PDL going, albeit without the functionality provided by proj. I use openSUSE Tumbleweed (rolling release). I have used Linux exclusively since 2005, mostly openSUSE and its predecessors. For the tools I use more often I do not use a package manager (zypper in openSUSE) but I build them (proj, geos, gdal, GRASS GIS, QGIS and others) from source myself. All of them live in /usr/local and subdirectories, properly exported to the path and library path (they actually found each other, no problems there). I normally update Perl modules using CPAN, including PDL, but when troubleshooting is needed I also build from source using the "perl Makefile.pl" method. And yes, I am familiar with Geo::GDAL::FFI. I use it in a couple of projects. It installs and runs fine. Best regards Hernán Den 2022-04-11 kl. 23:57, skrev Shawn Laffan: Hello Hernan, If you have issues installing Alien::proj then could you please file a bug report? https://github.com/shawnlaffan/perl-alien-proj If you have proj installed with its headers then Alien::proj will run a system install. This will just use your existing installation. If it cannot find the headers then it will run a share install, which means it builds the system from source code. You have not said what operating system you are using but as an example the libproj-dev package is needed on ubuntu to trigger a system install. WRT Ed's comment about GDAL bindings, Geo::GDAL::FFI provides these for perl and has methods to convert rasters to and from PDL ndarrays. https://metacpan.org/pod/Geo::GDAL::FFI https://metacpan.org/pod/Geo::GDAL::FFI::Band#SetPiddle Regards, Shawn. On Tue, 12 Apr 2022 at 04:29, Hernán De Angelis mailto:variablestarli...@gmail.com>> wrote: Hi Ed Thank you for your detailed response. I understand that Alien::proj will install the latest proj. For some reason I cannot manage to build
Re: [Pdl-general] PDL 2.078
On Tue, Apr 12, 2022 at 02:55:08PM +, Ed . wrote: > Hi Luis! > > Glad to hear Minuit is still in use. If it were removed from main > PDL, it would only be to make it available separately on CPAN as > PDL::Minuit (somewhat similar to PDL::FFTW3). That's a good option. > I’m afraid I’m not very knowledgeable about mathematical > optimisation, but I am aware of other options for PDL somewhat in > that sphere: > > * https://metacpan.org/pod/PDL::Opt::NonLinear > * https://metacpan.org/pod/PDL::Opt::QP > * https://metacpan.org/pod/PDL::Opt::Simplex (in main PDL) > * https://metacpan.org/pod/PDL::Fit::LM (in main PDL) > * https://metacpan.org/pod/PDL::Fit::Levmar Thanks! I wasn't aware of those. > Also, once the OpenCV stuff is cracked, that will be an example of a > PDL library using C++, which would then hopefully make a Minuit 2 > interface much easier. > While I think of it, any chance to look at > https://github.com/wlmb/Photonic/pull/23? :-) Sorry about the long delay! Regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Av. Universidad s/n CP 62210 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] PDL 2.078
ke[3]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Cartography' >> make[3]: Entering directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' >> "/usr/local/perls/perl-5.34.1/bin/perl" "-I../../../blib/arch" >> "-I../../../blib/lib" >> "-MPDL::PP=PDL::Transform::Proj4,PDL::Transform::Proj4,Proj4,,1" Proj4.pd >> "/usr/local/perls/perl-5.34.1/bin/perl" -MExtUtils::Command::MM -e >> 'cp_nonempty' -- Proj4.bs >> ../../../blib/arch/auto/PDL/Transform/Proj4/Proj4.bs 644 >> /usr/local/perls/perl-5.34.1/bin/perl: symbol lookup error: >> ../../../blib/arch/auto/PDL/GIS/Proj/Proj.so: undefined symbol: >> proj_list_operations >> make[3]: *** [Makefile:863: Proj4.pm] Error 127 >> make[3]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' >> make[2]: *** [Makefile:516: subdirs] Error 2 >> make[2]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform' >> make[1]: *** [Makefile:515: subdirs] Error 2 >> make[1]: Leaving directory '/root/.cpan/build/PDL-2.078-0/Libtmp' >> make: *** [Makefile:552: subdirs] Error 2 >> >> >> >> >> >> >> >> >> Den 2022-04-11 kl. 18:12, skrev Ed .: >> >> Hi Hernán! >> >> >> >> PDL’s build (which I suspect you normally do using a tool that doesn’t >> show you these messages) is only warning you that it can’t build Proj4 or >> HDF4. It will carry on and build everything else that it can, as hopefully >> you’re seeing. You’re saying core and GSL work, which wouldn’t be true if >> everything else hadn’t built? You say “FFTW”, but there is only an “FFT” in >> PDL. https://metacpan.org/pod/PDL::FFTW3 is an external distribution, >> and is recommended over PDL::FFT. >> >> >> >> The build system was restructured last year so that the tests for those >> things now live within their submodule directories. That is the idiomatic >> way (in ExtUtils::MakeMaker-using distributions) of doing these things, and >> allowed deleting of lots of unnecessary “protection” code, since those >> tests aren’t tried if the submodule doesn’t build (which makes sense if you >> think about it). >> >> >> >> Yes, PDL needs the Alien::* stuff for this. That allows outsourcing of >> things like building (or even just finding, which is surprisingly fiddly) a >> PROJ installation to other code. If you don’t have the Alien modules >> installed, PDL works fine but without the submodules those would have >> needed. This has been how PDL has operated (not building submodules that >> don’t have needed bits) since at least the year 2014. I don’t understand >> your point about “whimsical” or Proj v9, since PDL has supported PROJ v6+ >> since version 2.064, over 3 months ago. If you have an OS-packaged PROJ v6 >> or newer, then install Alien::proj, which PDL now looks for (note, not >> Alien::Proj4), it will see the installed version and not build its own. If >> you then reinstall PDL, it will see that and build the >> PDL::Transform::Proj4 stuff (the name “Proj4” is unimportant, it’s updated >> to v6+ so don’t worry). >> >> >> >> There is certainly some demand for PDL GDAL support. The sensible way >> would be to make a separate distribution for it. I wouldn’t be surprised if >> it only needed similar code to current PDL::GIS::Proj, with the equivalent >> of wrapping a forward and backward transform with parameters. If you’d like >> to create such a thing, we (the PDL porters) can help! Join the IRC channel >> and/or email on here :-) >> >> >> >> The Fortran stuff is only warnings. You will note the submodules still >> built, passed tests and installed. The Fortran code in those submodules >> (Minuit and Slatec) are written in Fortran 77, and are dramatically >> obsolete. We may or may not remove them into separate distributions, since >> I doubt anyone uses them. Nevertheless, they still work. Minuit 2 (not yet >> supported by PDL) is written in C++. Slatec is obsolete and replaced by >> LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra. >> >> >> >> Please open an issue on https://github.com/Perl-GPU/OpenGL-GLUT/issues >> describing the problem you’re having with GLUT to help us fix it. My plan >> is to roll OpenGL::GLUT back into a single OpenGL distribution to ease >> installation/use. >> >> >> >> Best regards, >> >> Ed >> >> >> >> *From: *Hernán De Angelis >> *Sent: *11 April 2022 0
Re: [Pdl-general] PDL 2.078
which I suspect you normally do using a tool that
doesn’t show you these messages) is only warning you that it
can’t build Proj4 or HDF4. It will carry on and build everything
else that it can, as hopefully you’re seeing. You’re saying core
and GSL work, which wouldn’t be true if everything else hadn’t
built? You say “FFTW”, but there is only an “FFT” in PDL.
https://metacpan.org/pod/PDL::FFTW3 is an external distribution,
and is recommended over PDL::FFT.
The build system was restructured last year so that the tests for
those things now live within their submodule directories. That is
the idiomatic way (in ExtUtils::MakeMaker-using distributions) of
doing these things, and allowed deleting of lots of unnecessary
“protection” code, since those tests aren’t tried if the
submodule doesn’t build (which makes sense if you think about it).
Yes, PDL needs the Alien::* stuff for this. That allows
outsourcing of things like building (or even just finding, which
is surprisingly fiddly) a PROJ installation to other code. If you
don’t have the Alien modules installed, PDL works fine but
without the submodules those would have needed. This has been how
PDL has operated (not building submodules that don’t have needed
bits) since at least the year 2014. I don’t understand your point
about “whimsical” or Proj v9, since PDL has supported PROJ v6+
since version 2.064, over 3 months ago. If you have an
OS-packaged PROJ v6 or newer, then install Alien::proj, which PDL
now looks for (note, not Alien::Proj4), it will see the installed
version and not build its own. If you then reinstall PDL, it will
see that and build the PDL::Transform::Proj4 stuff (the name
“Proj4” is unimportant, it’s updated to v6+ so don’t worry).
There is certainly some demand for PDL GDAL support. The sensible
way would be to make a separate distribution for it. I wouldn’t
be surprised if it only needed similar code to current
PDL::GIS::Proj, with the equivalent of wrapping a forward and
backward transform with parameters. If you’d like to create such
a thing, we (the PDL porters) can help! Join the IRC channel
and/or email on here :-)
The Fortran stuff is only warnings. You will note the submodules
still built, passed tests and installed. The Fortran code in
those submodules (Minuit and Slatec) are written in Fortran 77,
and are dramatically obsolete. We may or may not remove them into
separate distributions, since I doubt anyone uses them.
Nevertheless, they still work. Minuit 2 (not yet supported by
PDL) is written in C++. Slatec is obsolete and replaced by
LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra.
Please open an issue on
https://github.com/Perl-GPU/OpenGL-GLUT/issues describing the
problem you’re having with GLUT to help us fix it. My plan is to
roll OpenGL::GLUT back into a single OpenGL distribution to ease
installation/use.
Best regards,
Ed
*From: *Hernán De Angelis <mailto:variablestarli...@gmail.com>
*Sent: *11 April 2022 09:26
*To: *pdl-general@lists.sourceforge.net
*Subject: *[Pdl-general] PDL 2.078
Hi all
Thanks Ed and others for the great job you do maintaining and
developing PDL. Hats off!
Today I got news that 2.078 was available so I promptly went on
CPAN and hit upgrade. But for the first time in *many* years PDL
did not just build smoothly right away.
Upon investigation I see that PDL complains about Proj4 and HDF4
lacking when trying to build PDL::Transform. Problem is I cannot
find anywhere in perdl.conf where I can tell PDL not to care
about this and not run the t/gis_proj.t and t/proj_transform.t
tests. If I remember correctly that possibility existed years
ago. Can we still build PDL without using Proj? Perhaps using
--force? But that is not very elegant ...
A related question is: does PDL really need Alien::* for this
stuff? I would prefer not to mess with that because these
packages install lots of stuff I do not need nor want in my
system. I actually work everyday with geoinformatics and normally
have the latest gdal/ogr and proj. If PDL needs proj I believe it
would be much better to have PDL rely on those rather than some
whimsical Alien::* installing ancient proj4 versions (proj is v.
9 now).
Less serious stuff:
- Glut fails to install at the end but this has been the case for
many months and not been a problem
- there are a lot of FORTRAN warnings (see exerpt below), perhaps
some deprecated syntax that the latest gfortran (11.2.1 20220316)
does not like.
Good things:
- Core, FFTW, GSL build smoothly as usual.
Best
Hernán
# # # # # #
# some fortran warnings
# # # # # #
Warning: Fortran 2018 deleted feature: DO termination statement
whi
Re: [Pdl-general] PDL 2.078
understand > your point about “whimsical” or Proj v9, since PDL has supported PROJ v6+ > since version 2.064, over 3 months ago. If you have an OS-packaged PROJ v6 > or newer, then install Alien::proj, which PDL now looks for (note, not > Alien::Proj4), it will see the installed version and not build its own. If > you then reinstall PDL, it will see that and build the > PDL::Transform::Proj4 stuff (the name “Proj4” is unimportant, it’s updated > to v6+ so don’t worry). > > > > There is certainly some demand for PDL GDAL support. The sensible way > would be to make a separate distribution for it. I wouldn’t be surprised if > it only needed similar code to current PDL::GIS::Proj, with the equivalent > of wrapping a forward and backward transform with parameters. If you’d like > to create such a thing, we (the PDL porters) can help! Join the IRC channel > and/or email on here :-) > > > > The Fortran stuff is only warnings. You will note the submodules still > built, passed tests and installed. The Fortran code in those submodules > (Minuit and Slatec) are written in Fortran 77, and are dramatically > obsolete. We may or may not remove them into separate distributions, since > I doubt anyone uses them. Nevertheless, they still work. Minuit 2 (not yet > supported by PDL) is written in C++. Slatec is obsolete and replaced by > LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra. > > > > Please open an issue on https://github.com/Perl-GPU/OpenGL-GLUT/issues > describing the problem you’re having with GLUT to help us fix it. My plan > is to roll OpenGL::GLUT back into a single OpenGL distribution to ease > installation/use. > > > > Best regards, > > Ed > > > > *From: *Hernán De Angelis > *Sent: *11 April 2022 09:26 > *To: *pdl-general@lists.sourceforge.net > *Subject: *[Pdl-general] PDL 2.078 > > > > Hi all > > Thanks Ed and others for the great job you do maintaining and developing > PDL. Hats off! > > Today I got news that 2.078 was available so I promptly went on CPAN and > hit upgrade. But for the first time in *many* years PDL did not just build > smoothly right away. > > Upon investigation I see that PDL complains about Proj4 and HDF4 lacking > when trying to build PDL::Transform. Problem is I cannot find anywhere in > perdl.conf where I can tell PDL not to care about this and not run the > t/gis_proj.t and t/proj_transform.t tests. If I remember correctly that > possibility existed years ago. Can we still build PDL without using Proj? > Perhaps using --force? But that is not very elegant ... > > A related question is: does PDL really need Alien::* for this stuff? I > would prefer not to mess with that because these packages install lots of > stuff I do not need nor want in my system. I actually work everyday with > geoinformatics and normally have the latest gdal/ogr and proj. If PDL needs > proj I believe it would be much better to have PDL rely on those rather > than some whimsical Alien::* installing ancient proj4 versions (proj is v. > 9 now). > > Less serious stuff: > - Glut fails to install at the end but this has been the case for many > months and not been a problem > - there are a lot of FORTRAN warnings (see exerpt below), perhaps some > deprecated syntax that the latest gfortran (11.2.1 20220316) does not like. > > Good things: > - Core, FFTW, GSL build smoothly as usual. > > > Best > > Hernán > > > > > # # # # # # > # some fortran warnings > # # # # # # > > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 120 at (1) > slatec/tred2.f:112:72: > > 112 | 180 G = G + Z(J,K) * Z(I,K) > > |1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 180 at (1) > slatec/tred2.f:118:72: > > 118 | 200 G = G + Z(K,J) * Z(I,K) > > |1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 200 at (1) > slatec/tred2.f:131:72: > > 131 | DO 260 K = 1, J > > |1 > Warning: Fortran 2018 deleted feature: Shared DO termination label 260 at > (1) > slatec/tred2.f:149:72: > > 149 | 340 G = G + Z(I,K) * Z(K,J) > > |1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 340 at (1) > slatec/tred2.f:151:72: > > 151 | DO 360 K = 1, L > > |1 > Warning: Fortran 2018 deleted feature: Shared DO termination label 360 at > (1) > > > > > ___ > pdl-general mailing list > pdl-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-general > ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] PDL 2.078
On Mon, Apr 11, 2022 at 04:12:43PM +, Ed . wrote: > ... > ...The Fortran code in those submodules (Minuit and Slatec) are > written in Fortran 77, and are dramatically obsolete. We may or may > not remove them into separate distributions, since I doubt anyone uses > them. I do... :( What would be the recommended modules, alternative to minuit, to optimize multiparameter functions using the current PDL? Regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Av. Universidad s/n CP 62210 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] PDL 2.078
Hi Hernán! PDL’s build (which I suspect you normally do using a tool that doesn’t show you these messages) is only warning you that it can’t build Proj4 or HDF4. It will carry on and build everything else that it can, as hopefully you’re seeing. You’re saying core and GSL work, which wouldn’t be true if everything else hadn’t built? You say “FFTW”, but there is only an “FFT” in PDL. https://metacpan.org/pod/PDL::FFTW3 is an external distribution, and is recommended over PDL::FFT. The build system was restructured last year so that the tests for those things now live within their submodule directories. That is the idiomatic way (in ExtUtils::MakeMaker-using distributions) of doing these things, and allowed deleting of lots of unnecessary “protection” code, since those tests aren’t tried if the submodule doesn’t build (which makes sense if you think about it). Yes, PDL needs the Alien::* stuff for this. That allows outsourcing of things like building (or even just finding, which is surprisingly fiddly) a PROJ installation to other code. If you don’t have the Alien modules installed, PDL works fine but without the submodules those would have needed. This has been how PDL has operated (not building submodules that don’t have needed bits) since at least the year 2014. I don’t understand your point about “whimsical” or Proj v9, since PDL has supported PROJ v6+ since version 2.064, over 3 months ago. If you have an OS-packaged PROJ v6 or newer, then install Alien::proj, which PDL now looks for (note, not Alien::Proj4), it will see the installed version and not build its own. If you then reinstall PDL, it will see that and build the PDL::Transform::Proj4 stuff (the name “Proj4” is unimportant, it’s updated to v6+ so don’t worry). There is certainly some demand for PDL GDAL support. The sensible way would be to make a separate distribution for it. I wouldn’t be surprised if it only needed similar code to current PDL::GIS::Proj, with the equivalent of wrapping a forward and backward transform with parameters. If you’d like to create such a thing, we (the PDL porters) can help! Join the IRC channel and/or email on here :-) The Fortran stuff is only warnings. You will note the submodules still built, passed tests and installed. The Fortran code in those submodules (Minuit and Slatec) are written in Fortran 77, and are dramatically obsolete. We may or may not remove them into separate distributions, since I doubt anyone uses them. Nevertheless, they still work. Minuit 2 (not yet supported by PDL) is written in C++. Slatec is obsolete and replaced by LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra. Please open an issue on https://github.com/Perl-GPU/OpenGL-GLUT/issues describing the problem you’re having with GLUT to help us fix it. My plan is to roll OpenGL::GLUT back into a single OpenGL distribution to ease installation/use. Best regards, Ed From: Hernán De Angelis<mailto:variablestarli...@gmail.com> Sent: 11 April 2022 09:26 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: [Pdl-general] PDL 2.078 Hi all Thanks Ed and others for the great job you do maintaining and developing PDL. Hats off! Today I got news that 2.078 was available so I promptly went on CPAN and hit upgrade. But for the first time in *many* years PDL did not just build smoothly right away. Upon investigation I see that PDL complains about Proj4 and HDF4 lacking when trying to build PDL::Transform. Problem is I cannot find anywhere in perdl.conf where I can tell PDL not to care about this and not run the t/gis_proj.t and t/proj_transform.t tests. If I remember correctly that possibility existed years ago. Can we still build PDL without using Proj? Perhaps using --force? But that is not very elegant ... A related question is: does PDL really need Alien::* for this stuff? I would prefer not to mess with that because these packages install lots of stuff I do not need nor want in my system. I actually work everyday with geoinformatics and normally have the latest gdal/ogr and proj. If PDL needs proj I believe it would be much better to have PDL rely on those rather than some whimsical Alien::* installing ancient proj4 versions (proj is v. 9 now). Less serious stuff: - Glut fails to install at the end but this has been the case for many months and not been a problem - there are a lot of FORTRAN warnings (see exerpt below), perhaps some deprecated syntax that the latest gfortran (11.2.1 20220316) does not like. Good things: - Core, FFTW, GSL build smoothly as usual. Best Hernán # # # # # # # some fortran warnings # # # # # # Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 120 at (1) slatec/tred2.f:112:72: 112 | 180 G = G + Z(J,K) * Z(I,K) |1 Warning: Fortran 2018 del
[Pdl-general] PDL 2.078
Hi all Thanks Ed and others for the great job you do maintaining and developing PDL. Hats off! Today I got news that 2.078 was available so I promptly went on CPAN and hit upgrade. But for the first time in *many* years PDL did not just build smoothly right away. Upon investigation I see that PDL complains about Proj4 and HDF4 lacking when trying to build PDL::Transform. Problem is I cannot find anywhere in perdl.conf where I can tell PDL not to care about this and not run the t/gis_proj.t and t/proj_transform.t tests. If I remember correctly that possibility existed years ago. Can we still build PDL without using Proj? Perhaps using --force? But that is not very elegant ... A related question is: does PDL really need Alien::* for this stuff? I would prefer not to mess with that because these packages install lots of stuff I do not need nor want in my system. I actually work everyday with geoinformatics and normally have the latest gdal/ogr and proj. If PDL needs proj I believe it would be much better to have PDL rely on those rather than some whimsical Alien::* installing ancient proj4 versions (proj is v. 9 now). Less serious stuff: - Glut fails to install at the end but this has been the case for many months and not been a problem - there are a lot of FORTRAN warnings (see exerpt below), perhaps some deprecated syntax that the latest gfortran (11.2.1 20220316) does not like. Good things: - Core, FFTW, GSL build smoothly as usual. Best Hernán # # # # # # # some fortran warnings # # # # # # Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 120 at (1) slatec/tred2.f:112:72: 112 | 180 G = G + Z(J,K) * Z(I,K) | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 180 at (1) slatec/tred2.f:118:72: 118 | 200 G = G + Z(K,J) * Z(I,K) | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 200 at (1) slatec/tred2.f:131:72: 131 | DO 260 K = 1, J | 1 Warning: Fortran 2018 deleted feature: Shared DO termination label 260 at (1) slatec/tred2.f:149:72: 149 | 340 G = G + Z(I,K) * Z(K,J) | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 340 at (1) slatec/tred2.f:151:72: 151 | DO 360 K = 1, L | 1 Warning: Fortran 2018 deleted feature: Shared DO termination label 360 at (1)___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
[Pdl-general] PDL 2.078 released
Dear PDL folks, PDL 2.078 has just been released. Notable changes since 2.077: * TriD::GL now more resilient and exceptions don't leave GL broken * Bugfixes including to NiceSlice * “demo 3d” now shows off a 3D Earth (with accurate shading), and also a 3D molecule-like graph evolving over time * The “pdl” struct now has room for a single value (or if not complex long double, several values of smaller datatypes), avoiding extra memory-management for small ndarrays – but you don’t need to recompile installed modules Future plans, in something like intended order: * fix more open GitHub issues * “loop fusion” techniques to maximise locality of computation, minimising data’s trips through the “straw” between CPU and main RAM * finish the independent C interface for making PDL usable from e.g. Python * use OpenCL or other means to also utilise GPUs if available The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and ask questions, or just watch the GitHub messages flow by. As usual, please give the new release a try and report problems. Best regards, Ed ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
