Hi Ingo, That would probably be the build process (the relevant Makefile.PL) not catching that a needed library was missing on your system. Currently, PDL::LinearAlgebra (a PDL interface to an already-installed LAPACK library) has the same issue, which is why it gets lots of failures on CPAN Testers. For now, we haven’t really crunched down on that kind of thing. To make the build system more rigorous, it isn’t terribly hard – see PDL::Core::Dev’s new “got_complex_version” for how to detect a library/particular functions in it.
My current stance is to tolerate this, but of course it’s not ideal. PRs always welcome :-) Best regards, Ed From: Ingo Schmid Sent: Monday, March 08, 2021 8:02 PM To: pdl-devel@lists.sourceforge.net Subject: Re: [Pdl-devel] [Pdl-general] PDL 2.027 released Hi Ed, I got this error /bin/ld: cannot find -lglut while compiling latest git master on debian. I freshly installed (apt) libopengl-perl. Installing freeglut3-dev solved the issue. Is this a pdl issue, an opgengl issue or neither? In any case it should be caught in the perl Makefile.PL stage, no? What do you think? Ingo On 06.03.21 20:41, Ed . wrote: Dear PDL folks, I have just uploaded PDL 2.027. Changes from 2.026: - native support for complex numbers - thanks Ingo Schmid - define and use C macros in PP for shorter, more comprehensible XS Note that the native complex numbers are as defined in C99, and no attempt has (yet) been made to integrate this with PDL::Complex. Additionally, it’s not yet clear to me whether PDL performs better on complex numbers via PDL::Complex, or natively. Could someone more knowledgeable than me with PDL complex numbers (Luis?) come up with a benchmark, or at least a plausible, representative set of calculations to do with complex numbers so I can make a comparison? Adding this in case it’s useful, because I can’t figure out a sensible place to document it that anyone interested would be likely to find it: as discovered in fixing the temporary regression in asin(2) not returning NaN, it is highly likely that PDL functions given longlong data losing precision by converting the numbers to double is caused by this: when a function is given data not in its “GenericTypes” definition, PP defaults to the last entry in that definition. Therefore, if the function hasn’t specified it handles longlong, it will be treated as the last entry (often “D”, a double). Therefore, to fix this, all that would be needed is to add a “Q” entry to the relevant function to explicitly handle longlong. As usual, please report any problems with a pull-request fix (best), a GitHub issue with enough info to reproduce (still great), or at least a report on here (also fine!). Next steps: split out PDL::Core, then other large chunks, into their own distributions, for easier maintenance, and easier use by packagers. Best regards, Ed _______________________________________________ pdl-general mailing list pdl-gene...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
