Got some warnings that probably should be checked out: Core.xs:718:9: warning: implicit declaration of function '_anyval_eq_anyval' [-Wimplicit-function-declaration] simq.c:81:3: warning: implicit declaration of function 'puts' [-Wimplicit-function-declaration] resample.c:292:2: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration] Slatec.xs:11359:21: warning: implicit declaration of function 'polfit_' [-Wimplicit-function-declaration] Slatec.xs:11767:21: warning: implicit declaration of function 'dpolft_' [-Wimplicit-function-declaration] INTEG.xs:18122:10: warning: implicit declaration of function 'warn' [-Wimplicit-function-declaration]
On 9/30/2015 07:37, Chris Marshall wrote: > Looking at the CPAN Testers reports: > - many FAILs from t/bigmem.t running because AUTOMATED_TESTING is not set > - fails for 'long double' perls as reported by Rob > - some UNKNOWN from compiler error for FreeBSD 10.1-release > > With a fix for long double and making t/bigmem.t run on request > only should resolve most of the test failures reported so far. > > --Chris > > On 9/30/2015 06:53, Chris Marshall wrote: >> Adding a case to allow "long double" to "double" >> before the croak should fix the problem. >> >> Recommendations? >> >> --Chris >> >> On 9/30/2015 06:49, Chris Marshall wrote: >>> Hi Rob- >>> >>> Thanks for the reports. This did not occur for >>> PDL-2.013 because the logic for 64bit index support >>> was not complete. What I think is happening is >>> that perl values are being converted in the >>> typemap which assumes that PDL_Double is capable >>> of representing any floating point type. >>> >>> For the case of long double -> double conversion, >>> this is not the case. I don't think we want to >>> try to add long double to the PDL-2.x types but >>> we do need to decide how to handle the conversion >>> process and possible loss of precision or range. >>> >>> --Chris >>> >>> On 9/30/2015 04:23, [email protected] wrote: >>>> -----Original Message----- From: [email protected] >>>> Sent: Wednesday, September 30, 2015 11:28 AM >>>> To: Chris Marshall ; perldl >>>> Subject: Re: [Pdl-general] CHM/PDL-2.013_01.tar.gz uploaded to CPAN >>>> >>>>> There's also problems with my long double builds of perl on Windows. >>>> >>>> No problems when nvtype is "double". >>>> >>>> 45 of the test scripts are failing because whichdatatype_double(), >>>> which is found in Basic/Core/pdlcore.c, croaks when called with an >>>> argument whose finite floating point decimal value cannot be >>>> expressed exactly in base 2.: >>>> >>>> Something's gone wrong: 0.000000 cannot be converted by >>>> whichdatatype_double at C:\sisyphusion\PDL-2.013_01\blib\lib/PDL/ >>>> >>>> (The arg is not zero - it's just that "%lf" does not display the >>>> correct value.) >>>> >>>> whichdatatype_double looks like: >>>> >>>> ########################## >>>> int pdl_whichdatatype_double (NV nv) { >>>> TESTTYPE(PDL_F,PDL_Float) >>>> TESTTYPE(PDL_D,PDL_Double) >>>> >>>> if( !finite(nv) ) { return PDL_D; } >>>> croak("Something's gone wrong: %lf cannot be converted by >>>> whichdatatype_double", >>>> nv); >>>> } >>>> ########################## >>>> >>>> where TESTTYPE is defined as: >>>> #define TESTTYPE(b,a) {a foo = nv; if(nv == foo) return b;} >>>> >>>> Given that PDL_Float is 4 bytes, PDL_Double is 8 bytes and NV is 16 >>>> bytes, it should come as no surprise that TESTTYPE should fail to >>>> return for any finite floating point decimal value that cannot be >>>> expressed exactly in base 2. >>>> >>>> However, the reason that 2.013 succeeds for nvtype='long double' is >>>> that whichdatatype_double() simply does NOT get called at any stage >>>> (during the running of its test suite, at least) . >>>> >>>> So ... the question becomes "Why does the PDL-2.013_01 test suite >>>> call whichdatatype_double() at least 45 times when the nvtype is >>>> 'long double' ?" >>>> >>>> This is not a Windows-only issue. There aren't many cpan-testers >>>> running -Duselongdouble builds, but there's a report from one at: >>>> http://www.cpantesters.org/cpan/report/3b328b0e-66d3-11e5-a1a3-e32696b0373b >>>> >>>> >>>> and the same thing is happening there. >>>> >>>> Cheers, >>>> Rob >>> >> > ------------------------------------------------------------------------------ _______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
