Hi Ed,

I think that both cases, glut and lin. algebra accept several
implementations, so the dependency isn't trivial, no? I guess a test
compile with '-lglut' required would do it. I've never done these things
but I can look into this later on, I suppose.

Ingo

On 09.03.21 01:48, Ed wrote:
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 <mailto:ingo...@gmx.at>
*Sent:* Monday, March 08, 2021 8:02 PM
*To:* pdl-devel@lists.sourceforge.net
<mailto: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

Reply via email to