Menu
▾
▴
pdl-devel — PDL Developers and Internals Discussion
You can subscribe to this list here.
| 2015 |
Jan
|
Feb
(44) |
Mar
(75) |
Apr
(42) |
May
(50) |
Jun
(82) |
Jul
(17) |
Aug
(45) |
Sep
(32) |
Oct
(32) |
Nov
(41) |
Dec
(22) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(9) |
Feb
(5) |
Mar
(6) |
Apr
(6) |
May
(34) |
Jun
(47) |
Jul
(10) |
Aug
(2) |
Sep
(6) |
Oct
(35) |
Nov
(6) |
Dec
|
| 2017 |
Jan
(7) |
Feb
(5) |
Mar
(3) |
Apr
(2) |
May
(12) |
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(7) |
May
(10) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
(11) |
Jun
(5) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2021 |
Jan
|
Feb
(25) |
Mar
(38) |
Apr
(11) |
May
(3) |
Jun
(6) |
Jul
(2) |
Aug
(22) |
Sep
(12) |
Oct
(18) |
Nov
(6) |
Dec
(1) |
| 2022 |
Jan
(5) |
Feb
(47) |
Mar
(6) |
Apr
(9) |
May
(7) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
(17) |
Oct
(5) |
Nov
|
Dec
|
| 2024 |
Jan
(8) |
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
(13) |
Jun
(10) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Chris M. <dev...@gm...> - 2015-11-01 11:54:00
|
Hi Karl- There is already an ExtUtils::F77 1.18 with a number of fixes for similar issues. Please start with the current release and work from there to avoid breakage and duplicative effort. --Chris P.S. Sorry I didn't get a git repo going but didn't seem a priority since I thought I was the last man standing. :-) On 10/31/2015 22:10, Karl Glazebrook wrote: > I’d appreciate it if people could give this a whirl: > > https://dl.dropboxusercontent.com/u/2148080/ExtUtils-F77-1.18.tar.gz > > I’ve made some improvements to the gfortran linking which should avoid runtime unresolved symbols issues. (e.g. ‘make test’ with modules like PGPLOT) > > It works on OS X, so various Linux tests would be appreciated. Should be no difference on Win32 > > (Basically I figure that the extra libs needed apply to all versions of gfortran > 4.9 and do not depend on OS… nice to confirm this!) > > Also I intend to release this to CPAN in a week or so, so please if you have any other patches please email them to me! > > thanks > > Karl > > > ------------------------------------------------------------------------------ > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: <sis...@op...> - 2015-11-01 05:03:50
|
-----Original Message----- From: Karl Glazebrook Sent: Sunday, November 01, 2015 1:10 PM To: pdl-devel Subject: [Pdl-devel] ExtUtils:F77 new version 1.18 for testing > I’d appreciate it if people could give this a whirl: > > https://dl.dropboxusercontent.com/u/2148080/ExtUtils-F77-1.18.tar.gz Hi Karl, There's already a 1.18 release on CPAN - so this will require a re-versioning to 1.19 (or somesuch). In the CPAN version of 1.18, "$F77config{MinGW}{GFortran}{Link}" returns "-L$dir -L/usr/lib -lgfortran -lquadmath -lm" but, in your version the "-lquadmath" is missing. Therefore, I think (untested) your version won't work with the mingw port of gcc-4.9.2 on Windows. At the moment I've just updated gsl from 1.16 to 2.0, which has broken my builds of PDL owing to changes in the gsl-2.0 API - and I'm currently in the middle of poking around with that. Cheers, Rob |
|
From: Karl G. <kar...@ma...> - 2015-11-01 02:10:12
|
I’d appreciate it if people could give this a whirl: https://dl.dropboxusercontent.com/u/2148080/ExtUtils-F77-1.18.tar.gz I’ve made some improvements to the gfortran linking which should avoid runtime unresolved symbols issues. (e.g. ‘make test’ with modules like PGPLOT) It works on OS X, so various Linux tests would be appreciated. Should be no difference on Win32 (Basically I figure that the extra libs needed apply to all versions of gfortran > 4.9 and do not depend on OS… nice to confirm this!) Also I intend to release this to CPAN in a week or so, so please if you have any other patches please email them to me! thanks Karl |
|
From: Chris M. <dev...@gm...> - 2015-10-29 13:56:05
|
Short answer: safe to ignore the warning.
Long answer: Module::Compile and Filter::Simple are needed
to support some of my work to fix PDL::NiceSlice to correctly ignore
processing patterns in comments, pod, strings,... In the new,
improved development model, this should all be moved to a topic
branch for development rather than leaving it in the main release.
Unless you set the PDL_NICESLICE_ENGINE environment variable
to the non-default options ('Filter::Simple' or 'Module::Compile')
then Filter::Simple or Module::Compile are never use'd or used.
Cheers,
Chris
On Sun, Oct 25, 2015 at 12:46 AM, <sis...@op...> wrote:
> -----Original Message----- From: Karl Glazebrook
> Sent: Sunday, October 25, 2015 2:36 PM
> To: Chris Marshall
> Cc: pdl...@li... ; perldl
> Subject: Re: [Pdl-devel] [Pdl-general] PDL-2.014 release plans (SciPDL
> too?)
>
>
> Just catching up on this… building 2.014 starts off with
>> Warning: prerequisite Module::Compile 0.23 not found.
>> Is this really needed? Reason I ask is I tried to install Module::Compile
>> but the tests blow up
>>
>
> I've been seeing that, too, for quite a while on Windows and Linux.
> It's absence hasn't caused any problems that I've been able to detect - ie,
> whenever I install Module::Compile makes no difference (except that the
> warning no longer appears).
>
> Cheers,
> Rob
>
>
>
>
|
|
From: Karl G. <kgl...@sw...> - 2015-10-25 22:54:18
|
Yes, on Mac it seems we also need to link with something called libgcc_ext.10.5 as well as libquadmath Sigh. Anyone know what that is? google was not much help I am happy to modify ExtUtils::F77 to add these by default for gfortran, but I need to know if this is platform specific… or not. Can someone take a look for linux? Building ‘PGPLOT’ module is an excellent test as it gives a ‘make test’ error if there are undefined symbols…. Karl > On 26 Oct 2015, at 9:43 am, sis...@op... wrote: > > -----Original Message----- From: Karl Glazebrook > Sent: Sunday, October 25, 2015 4:37 PM > To: pdl-devel > Subject: [Pdl-devel] PDL::Slatec > >> Next there’s stuff going on with PERL_DL_NONLAZY (which is the default for 'make test') >> >> Basically loading PDL::Slatec doesn’t work with this variable set due to undefined symbols. (We need to link with more than -lgfortran it seems… go figure.) > > On Windows with gcc-4.9.2 we're adding a -lquadmath link to avoid undefined references to some (libquadmath) symbols. > That wasn't needed when using earlier versions of gcc. > > Perhaps your undefined symbols are libquadmath ones ? > > Cheers, > Rob |
|
From: <sis...@op...> - 2015-10-25 22:44:18
|
-----Original Message----- From: Karl Glazebrook Sent: Sunday, October 25, 2015 4:37 PM To: pdl-devel Subject: [Pdl-devel] PDL::Slatec > Next there’s stuff going on with PERL_DL_NONLAZY (which is the default > for 'make test') > > Basically loading PDL::Slatec doesn’t work with this variable set due to > undefined symbols. (We need to link with more than -lgfortran it seems… go > figure.) On Windows with gcc-4.9.2 we're adding a -lquadmath link to avoid undefined references to some (libquadmath) symbols. That wasn't needed when using earlier versions of gcc. Perhaps your undefined symbols are libquadmath ones ? Cheers, Rob |
|
From: Karl G. <kgl...@sw...> - 2015-10-25 06:13:49
|
I was just trying to tidy up the ‘make test’ issues with PDL::Slatec on Mac in readiness for a new SciPDL. It seems that there’s a couple of issues. ==== First (Mac specific?) the build sequence does a ‘gfortran file.f’ on all the routines. This makes a x86_64 binary. However it tries to create the bundle with cc -arch i386 -arch x86_64. I don’t think gfortran supports dual arch builds??? === Next there’s stuff going on with PERL_DL_NONLAZY (which is the default for 'make test') Basically loading PDL::Slatec doesn’t work with this variable set due to undefined symbols. (We need to link with more than -lgfortran it seems… go figure.) === I can fix both of these! I need to change the PDL::Slatec Makefile.PL and also update ExtUtils::F77. Karl |
|
From: <sis...@op...> - 2015-10-25 04:50:31
|
-----Original Message----- From: Karl Glazebrook Sent: Sunday, October 25, 2015 2:36 PM To: Chris Marshall Cc: pdl...@li... ; perldl Subject: Re: [Pdl-devel] [Pdl-general] PDL-2.014 release plans (SciPDL too?) > Just catching up on this… building 2.014 starts off with > Warning: prerequisite Module::Compile 0.23 not found. > Is this really needed? Reason I ask is I tried to install Module::Compile > but the tests blow up I've been seeing that, too, for quite a while on Windows and Linux. It's absence hasn't caused any problems that I've been able to detect - ie, whenever I install Module::Compile makes no difference (except that the warning no longer appears). Cheers, Rob |
|
From: Karl G. <kar...@ma...> - 2015-10-25 03:36:54
|
Just catching up on this… building 2.014 starts off with Warning: prerequisite Module::Compile 0.23 not found. Is this really needed? Reason I ask is I tried to install Module::Compile but the tests blow up Karl > On 27 Sep 2015, at 4:33 am, Chris Marshall <dev...@gm...> wrote: > > All- > > I'm in the process of squashing the longlong-double-fix > branch in preparation to rejoin master for a PDL-2.014 > release within the next few weeks---starting with a CPAN > devel release. > > In addition to cleaning up the low hanging fruits from > various sf and github issue trackers, we need to have > the SciPDL release prepared. It seems that the one for > PDL-2.013 never got completed. As the PDL-2.014 > release has new support for 64bit index operations, > there may be some additional wrinkles in the build > that need to be ironed out. > > Karl, are you still on board for SciPDL-2.01x? > > Ed, are there any commits/features that your think would > make sense to incorporate from the PDLA work for this > release? > > As always, comments and suggestions welcome! > > --Chris > > > On 9/24/2015 10:19, Chris Marshall wrote: >> PDL Users and Developers- >> >> Recent development by kmx appears to have fixed >> all the known issues for 64bit indexing support for PDL >> and has resolved the problems where significance of >> 64bit integer values was being lost due to implicit >> conversion through the double type. >> >> There have also been a number of bugs as a results of >> persistent investigation by users and developers (thanks >> Matt!). >> >> I would like to plan for a PDL-2.014 release within the >> next few weeks with a notional release date of 12-Oct. >> This release would include the fixes for 64bit support, >> the above mentioned bugs and fixes for any other low >> hanging fruit in the sf.net bugs tracker. >> >> We'll start by pulling the longlong-double-fix branch >> into master by this weekend to be followed soon after >> by the fixes for outstanding bugs. That will be pushed >> as a CPAN developers release for testing while the >> additional bug fixes and development takes place. >> >> Comments, suggestions, welcome! >> >> --Chris >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > pdl-general mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-general |
|
From: Chris M. <dev...@gm...> - 2015-10-19 13:47:07
|
Thanks for the report, Rob. I think it is time to document our support
level for ASPerl and move on. Without someone using ASPerl PDL working to
fix these issues and with PDL builds succeeding for all recent perls
(except when their build VMs run out of memory) there seems little value
added for the work to back port. I think we can add something to the PDL
web site windows page and call it "Done!'. Here is a synopsis from the
ASPerl build results:
Perl 5.8 Perl 5.10 Perl 5.12 Perl 5.14
> Perl 5.16 Perl 5.18 Perl 5.20
>
> Linux (x86, 32-bit) 2.4.11 2.4.11 2.007 2.014
> 2.014 none n/a
> Linux (x86, 32-bit) n/a n/a n/a ok
> ok gcc oom n/a
>
> Linux (x86, 64-bit) n/a 2.4.11 2.007 2.014
> 2.014 2.014 2.014
> Linux (x86, 64-bit) n/a n/a n/a ok
> ok ok ok
>
> Mac OS X 2.4.9 2.4.9 2.4.9 2.014
> 2.013 2.014 2.014
> Mac OS X n/a n/a n/a ok
> cc1 oom ok ok
>
> Solaris (SPARC, 32-bit) notest notest none none
> n/a n/a n/a
> Solaris (SPARC, 32-bit) n/a n/a cg oom cg oom
> n/a n/a n/a
>
> Solaris (SPARC, 64-bit) n/a notest none none
> n/a n/a n/a
> Solaris (SPARC, 64-bit) n/a n/a f90 elf f90 elf
> n/a n/a n/a
>
> Windows (32-bit) 2.4.9 2.4.9 2.007 2.007
> 2.007 2.014 2.014
> Windows (32-bit) n/a n/a n/a cl error cl
> error ok ok
>
> Windows (64-bit) n/a 2.4.11 2.007 2.007
> 2.013 2.014 2.014
> Windows (64-bit) n/a n/a n/a no build cl
> error ok ok
>
>
With the data elided from AS PPM PDL Reports
<http://code.activestate.com/ppm/PDL/>
Cheers,
Chris
On Mon, Oct 19, 2015 at 6:34 AM, <sis...@op...> wrote:
> -----Original Message----- From: sis...@op...
>
>> The blocker there is the use of 'long long' in the generated
>> Basic/Ops/Ops.xs (fixed just now with commit c2ae69d).
>>
>
> s/c2ae69d/a6d59a7/
>
|
|
From: <sis...@op...> - 2015-10-19 10:35:28
|
-----Original Message----- From: sis...@op... > The blocker there is the use of 'long long' in the generated > Basic/Ops/Ops.xs (fixed just now with commit c2ae69d). s/c2ae69d/a6d59a7/ |
|
From: <sis...@op...> - 2015-10-19 09:53:14
|
-----Original Message----- From: Chris Marshall Sent: Thursday, October 15, 2015 6:53 PM To: pdl...@li... Subject: [Pdl-devel] PDL-2.014 testing well > It would be nice to have PDL building for all the ASPerl configurations > but without inside help to debug we'll have to be satisfied with the > latest perls. I noticed that the 64-bit ActivePerl-5.16 happily built PDL-2.013, but not PDL-2.014. It so happens that I have the same compiler as used by ActiveState for their x64 perl-5.16 builds, so I was able to do some testing. AIUI, the problem is that the compiler they're using (Platform SDK) expects C90-compliant code, and PDL-2.014 generates a Bad.xs that is *not* C90-compliant. Specifically, once one of the ANYVAL_* macros has been called we can't subsequently make any declarations in the same block - and it's our non-compliance with that condition in Bad.xs that's causing the errors. (Obviously, the Bad.xs code generated by PDL-2.013 complies with the requirements of the Platform SDK compiler - and PDL-2.013 also builds fine for me with Platform SDK.) This type of problem has cropped up time and time again with PDL and ActiveState's M$ compilers. I don't know if M$ have even released a C99-compliant compiler yet. In the past we've got around this problem by simply inserting some scoping brackets where needed, but this case seems (to me) to be not-so-simple-to-fix. I don't know my way around the PDL source all that well so there may, in fact, be a trivial fix - but I think I'll leave this as an exercise for someone who cares. However, I'll happily test any patches that are presented. The 32-bit builds of ActivePerl-5.16 (and earlier) use MSVC++6.0, and that antiquated compiler imposes additional conditions. The blocker there is the use of 'long long' in the generated Basic/Ops/Ops.xs (fixed just now with commit c2ae69d). This is another constantly recurring problem with PDL and MSVC 6 - as soon as we fix one occurrence of 'long long' another one pops up to take its place :-) Of course, MSVC++ 6.0 also requires that the above issue with Bad.xs be fixed. I *do* agree that it "would be nice to have PDL building for all the ASPerl configurations", though I doubt it's really worth the effort. Cheers, Rob |
|
From: Chris M. <dev...@gm...> - 2015-10-18 16:38:40
|
Attached are the 3 bug examples from the sf bug 403. I figured out how to turn on the pdl debugging but have no idea how to read the output... --Chris On 10/15/2015 03:53, Chris Marshall wrote: > CPAN Testers reports for PDL-2.014 are running > around 99% PASS. > > The ActiveState Perls have successfully built > PDL-2.014 for their gcc toolchain but there > are a number of failed builds for the MS C > compiler/nmake, for Solaris SPARC, and for > 32-bit x86 Linux because the VM has too little > memory for the compiler to run. > > It would be nice to have PDL building for all > the ASPerl configurations but without inside > help to debug we'll have to be satisfied with > the latest perls. > > NOTE: We still have the newly discovered > bug for Changed PDLs causing SEGFAULTs > > http://sourceforge.net/p/pdl/bugs/403/ > > which is important enough to warrant a > PDL-2.015 release once fixed. ATM, I'm out > of PDL 'tuits so any help to solve the problem > would be appreciated. :-) > > Cheers, > Chris > |
|
From: Chris M. <dev...@gm...> - 2015-10-15 07:53:52
|
CPAN Testers reports for PDL-2.014 are running around 99% PASS. The ActiveState Perls have successfully built PDL-2.014 for their gcc toolchain but there are a number of failed builds for the MS C compiler/nmake, for Solaris SPARC, and for 32-bit x86 Linux because the VM has too little memory for the compiler to run. It would be nice to have PDL building for all the ASPerl configurations but without inside help to debug we'll have to be satisfied with the latest perls. NOTE: We still have the newly discovered bug for Changed PDLs causing SEGFAULTs http://sourceforge.net/p/pdl/bugs/403/ which is important enough to warrant a PDL-2.015 release once fixed. ATM, I'm out of PDL 'tuits so any help to solve the problem would be appreciated. :-) Cheers, Chris |
|
From: Henning G. <gl...@de...> - 2015-10-12 18:01:33
|
On Wed, Oct 07, 2015 at 11:06:18AM -0400, Chris Marshall wrote: > We're in the final stages of pre-release testing for the upcoming PDL-2.014 > release next Monday. > The highlight of this release is the completion of 64bit support which I > believe should address the problems which de-railed PDL from the Debian > packages. Presently, there is a huge perl transition (to 5.20) going on in Debian, so I am a bit hesitant to upload any new PDL now. However, the worst issue with implicit int->double conversion I saw involved pointers on ia64 (that architecture seems to have an unusual memory layout, so the problem was only visible there, but is a potential security problem on any architecture). If I find some time I can check manually on a ia64 Debian porterbox. -- c u henning |
|
From: Chris M. <dev...@gm...> - 2015-10-12 18:00:27
|
On 10/12/2015 13:46, Henning Glawe wrote: > On Wed, Oct 07, 2015 at 11:06:18AM -0400, Chris Marshall wrote: >> We're in the final stages of pre-release testing for the upcoming PDL-2.014 >> release next Monday. >> The highlight of this release is the completion of 64bit support which I >> believe should address the problems which de-railed PDL from the Debian >> packages. > Presently, there is a huge perl transition (to 5.20) going on in Debian, so I > am a bit hesitant to upload any new PDL now. > However, the worst issue with implicit int->double conversion I saw involved > pointers on ia64 (that architecture seems to have an unusual memory layout, > so the problem was only visible there, but is a potential security problem on > any architecture). > If I find some time I can check manually on a ia64 Debian porterbox. Thanks, I believe those issues have been addressed with PDL-2.014 and our pre-release testing. However, we won't know for sure until you can run your own. I understand not shaking the boat during the transition but PDL-2.014 has some 63 bug tickets closed since PDL-2.007 along with new support for 64bit integer indexing so when the time is appropriate, it would be a big step forward for the Debian PDL package. --Chris |
|
From: Chris M. <dev...@gm...> - 2015-10-12 15:55:02
|
And should appear at a mirror near you soon.
This release has the usual polishing and bugs fixed
but the highlight is completed support for 64bit
integers as PDL_Indx type.Thanks to the many developers
and users whocontributed to make this release possible.
Enjoy and happy PDL-ing!
Chris and the PDL Development team
v2.014 2015-10-12 11:44:10-04:00
General Notes:
* This is PDL-2.014 introducing full support for
64bit indexing operations using 64bit PDL_Indx
data type.
* PDL can now create and use piddles having more
than 2**32 elements. Of particular use is that
you can now use PDL::IO::FlexRaw to memory map
piddles from files on disk which can allow for
simplified processing and IO on extremely large
data.
* Due to the new PDL_Anyval type changes, existing
PDL::PP modules may need to be updated to support
the new PDL Core version 12 API. Authors, please
see PDL::API for macros to ease the porting.
Users, be aware that some modules may not work
until they are updated by their maintainers.
Highlights:
* Implement PDL_Anyval data type as union to support
64bit indexing
This adds a union data type to add 64bit integer support to
the original PDL-2.x types which assumed that double was
capable of holding all the "lesser" types. With the PDL_Anyval
type, we can correctly handle 64bit integer data types and
avoid errors and loss of precision due to conversions to or
from PDL_Double. Special thanks to kmx and zowie for their
help to complete and debug this implementation.
* Many fixes to the build process to make PDL more robust
to build, test, and install. This takes advantage of new
automated CI testing via Travis CI on the github site.
Thanks much to Ed and Zakariyya for their work to get
this started and maintained. This CI testing makes
this the best tested and best testing PDL release ever!
* Various documentation clean-ups and work to improve
on-line viewing at http://metacpan.org and others.
(Thanks kmx and Derek!)
* A new ipow() method haw been added with 64bit integer
support. ipow() calculates the integer exponentiation
of a value by successive multiplications. This allows
one to avoid loss of significance in integer exponents.
pow() converts the value to double and will always have
<52bits precision.
* nbadover and ngoodover now return indx type (PDL_Indx)
* PDL now detects when your perl installation has been
built with floating point longer than 8 bytes and gives
a one time warning that precision will be lost converting
from perl NV to PDL_Doubles. This warning is given on
"use PDL;"
* "use PDL" now includes "use PDL::IO::Storable"
This avoids a hard to diagnose crash that can
occur when a user tries using Storable without the
necessary "use PDL::IO::Storable".
* MANY sf.net bugs fixed:
400 dataflow slice crash around 2**31 boundary
399 Small doc fixes
398 $pdl->hdr items are lost after $pdl->reshape
396 online docs for modules only work first time in PDL shells
395 ipow (integer exponentiation) support for 64bit index support
394 demo cartography fails
383 gcc/#gfortran 4.9.2 needs -lquadmath
378 where on dice of pdl bad results
376 PDL Segmentation fault working with Storable restored PDL
347 t/#pdl_from_string.t has a failure if BADVAL_NAN=1
346 ExtUtils::F77 dependency causing problems for CPAN install
343 longlong constructor and display lose digits due to...
340 orover of byte data returns long type
|
|
From: Chris M. <dev...@gm...> - 2015-10-10 21:13:36
|
...and should be appearing at a mirror near you soon.
This the the second and likely final release candidate for Monday's
PDL-2.014 release.
It should be identical to the stable release save VERSION number and
Release_Notes.
Final feedback and problem reports for Known_problems only.
Thanks much,
Chris (PDL-2.014 release manager)
v2.013_06 2015-10-10 16:04:14-04:00
General Notes:
* This is PDL-2.013_06 which is RC 2 for PDL-2.014
and likely the final one before the official
release. Please report any final issues and doc
patches ASAP.
Highlights:
* Mark some failing tests in t/primitive.t as TODO
to avoid CPAN Testers failures.
* Add IPC::Cmd to TEST_REQUIRES
|
|
From: Chris M. <dev...@gm...> - 2015-10-09 10:59:30
|
All- CHM/PDL-2.013_05.tar.gz (the first PDL-2.014 release candidate) is testing with >95% PASS. With only a few more days before release, we'll be in code freeze with mainly POD and release documentation changes remaining. Please test and report any problems for inclusion in the Known_problems. If there are some documentation improvements you've been wanting to do, now is the time to get them in the PDL-2.014 release. Maintainers of PDL-based distributions, be aware that the 64bit index support changes affected the internals of the PDL core C code. If your module is XS based, this may cause problems with the build. The list of PDL distributions from the cpan shell is: Distribution CAVANAUGH/PDL-NamedArgs-0.12.tar.gz Distribution CHM/PDL-2.011.tar.gz Distribution CHM/PDL-2.013.tar.gz Distribution CHM/PDL-FFTW-2.024.tar.gz Distribution CHM/PDL-IO-HDF5-0.73.tar.gz Distribution CHM/PDL-LinearAlgebra-0.12.tar.gz Distribution DARIN/PDL-Parallel-MPI-0.02.tar.gz Distribution DCMERTENS/PDL-Drawing-Prima-0.10.tar.gz Distribution DCMERTENS/PDL-Fit-ExpRate-0.02.tar.gz Distribution DCMERTENS/PDL-Graphics-Prima-0.17.tar.gz Distribution DCMERTENS/PDL-Parallel-threads-0.03.tar.gz Distribution DHUNT/PDL-Graphics-PLplot-0.71.tar.gz Distribution DHUNT/PDL-NetCDF-4.20.tar.gz Distribution DJERIUS/PDL-FuncND-0.11.tar.gz Distribution DRAGOS/PDL-RungeKutta-0.01.tgz Distribution EBAUDREZ/PDL-NDBin-0.018.tar.gz Distribution ETJ/PDL-FFTW3-0.04.tar.gz Distribution ETJ/PDL-Stats-0.73.tar.gz Distribution EWATERS/PDL-Graphics-ColorDistance-0.0.1.tar.gz Distribution FANTASMA/PDL-Dims/PDL-Dims-0.013.tar.gz Distribution FANTASMA/PDL-IO-Nifti/PDL-IO-Nifti-0.73.tar.gz Distribution HBABCOCK/PDL-Graphics-X-Fits-0.01.tar.gz Distribution JBERGER/PDL-Util-0.010.tar.gz Distribution JEDWARDS/PDL-IO-Grib-2.0.tar.gz Distribution JLAPEYRE/PDL-DSP-Fir-0.005.tar.gz Distribution JLAPEYRE/PDL-DSP-Windows-0.007.tar.gz Distribution KMX/PDL-Finance-TA-0.008.tar.gz Distribution KMX/PDL-Finance-Talib-0.009.tar.gz Distribution KMX/PDL-IO-CSV-0.006.tar.gz Distribution KMX/PDL-IO-DBI-0.007.tar.gz Distribution KMX/PDL-IO-Image-0.004.tar.gz Distribution KMX/PDL-IO-Sereal-0.002.tar.gz Distribution MAGGIEXYZ/PDL-Graphics-ColorSpace-0.1.0.tar.gz Distribution MGRIMES/PDL-Opt-QP-0.27.tar.gz Distribution MLEHMANN/PDL-Audio-1.2.tar.gz Distribution MOOCOW/PDL-CCS-1.22.2.tar.gz Distribution MOOCOW/PDL-EditDistance-0.06.tar.gz Distribution MOOCOW/PDL-GA-0.07.tar.gz Distribution MOOCOW/PDL-HMM-0.06003.tar.gz Distribution MOOCOW/PDL-Ngrams-0.05003.tar.gz Distribution MOOCOW/PDL-SVDLIBC-0.13.tar.gz Distribution MOOCOW/PDL-VectorValued-1.0.3.tar.gz Distribution ROOTKWOK/PDL-IO-BareStore-0.01.tar.gz Distribution TJENNESS/PDL-IO-NDF-1.04.tar.gz Distribution ZOWIE/PDL-Graphics-Gnuplot-2.005.tar.gz Distribution ZOWIE/PDL-Graphics-Simple-1.005.tar.gz --Chris (PDL-2.014 release manager) |
|
From: <sis...@op...> - 2015-10-08 02:41:26
|
From: Chris Marshall
Sent: Thursday, October 08, 2015 2:06 AM
To: Henning Glawe ; Henning Glawe
Cc: pdl...@li...
Subject: [Pdl-devel] update Debian PDL-2.007 to PDL-2.014?
> Could you please try the current CPAN developers release (
> CHM/PDL-2.013_04.tar.gz ) and report if it now builds on the big-endian
> systems (I think that was where the problems were)?
On my ppc64 (big-endian) box running Debian Wheezy, with perl-5.22.0
(ppc64-linux-thread-multi-ld) I initially had 4 failing test scripts because
Test::Exception was not installed.
The absence of that module may have been my fault ... or it may indicate
that the dependency on Test::Exception has not been correctly declared in
the source. (I haven't checked.)
After installing Test::Exception, all tests pass and the 'make test' summary
report looks like:
Test Summary Report
-------------------
t/bad.t (Wstat: 0 Tests: 82 Failed: 0)
TODO passed: 53-54
t/fits.t (Wstat: 0 Tests: 90 Failed: 0)
TODO passed: 13, 17, 26, 30, 39, 45, 51, 60
t/inline-comment-test.t (Wstat: 0 Tests: 3 Failed: 0)
TODO passed: 3
t/iotypes.t (Wstat: 0 Tests: 7 Failed: 0)
TODO passed: 1-7
t/minmax-behavior.t (Wstat: 0 Tests: 3 Failed: 0)
TODO passed: 1, 3
t/op-eq-warn-for-non-numeric.t (Wstat: 0 Tests: 5 Failed: 0)
TODO passed: 5
t/ops.t (Wstat: 0 Tests: 60 Failed: 0)
TODO passed: 49-52
t/pdl_from_string.t (Wstat: 0 Tests: 113 Failed: 0)
TODO passed: 37-39
t/ufunc.t (Wstat: 0 Tests: 35 Failed: 0)
TODO passed: 14-35
Files=133, Tests=1505, 97 wallclock secs ( 2.15 usr 0.65 sys + 87.21 cusr
9.80 csys = 99.81 CPU)
It's a fairly basic build of PDL. There's no optional extras like TriD,
Proj, and GSL.
Unfortunately I haven't yet been able to get the fortran stuff to compile -
not finding the right gcc libs.
So I removed EU::77; hence no slatec and minuit.
It omens well for big-endian builds (and Debian), but a response from
Henning would be far more authoritative than I can provide.
For completeness, I've stuck the 'perl -V' below my sig.
I do have perls with other configurations - let me know if there's some
specific configuration(s) you'd like tested.
Cheers,
Rob
Summary of my perl5 (revision 5 version 22 subversion 0) configuration:
Platform:
osname=linux, osvers=3.2.0-4-powerpc64,
archname=ppc64-linux-thread-multi-ld
uname='linux debian-sis 3.2.0-4-powerpc64 #1 smp debian 3.2.68-1+deb7u1
ppc64 gnulinux '
config_args='-des -Duse64bitint -Dusethreads -Duselongdouble -Duse64bitall
-Dcc=gcc -m64 -Dprefix=/home/sisyphus-sis/perl522-m64-multi-ld'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
use64bitint=define, use64bitall=define, uselongdouble=define
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc -m64', ccflags
='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
optimize='-O1',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.6.3', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321,
doublekind=4
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16,
longdblkind=6
ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t',
lseeksize=8
alignbytes=16, prototype=define
Linker and Libraries:
ld='gcc -m64', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/powerpc-linux-gnu/4.6/include-fixed
/usr/lib /lib/powerpc-linux-gnu /lib/../lib /usr/lib/powerpc-linux-gnu
/usr/lib/../lib /lib /lib64 /usr/lib64
libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.13.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.13'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC',
lddlflags='-shared -O1 -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS
USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME
USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF
USE_REENTRANT_API
Built under linux
Compiled at Jun 2 2015 22:14:40
@INC:
/home/sisyphus-sis/perl522-m64-multi-ld/lib/site_perl/5.22.0/ppc64-linux-thread-multi-ld
/home/sisyphus-sis/perl522-m64-multi-ld/lib/site_perl/5.22.0
/home/sisyphus-sis/perl522-m64-multi-ld/lib/5.22.0/ppc64-linux-thread-multi-ld
/home/sisyphus-sis/perl522-m64-multi-ld/lib/5.22.0
|
|
From: Chris M. <dev...@gm...> - 2015-10-07 15:06:25
|
Hi Henning- We're in the final stages of pre-release testing for the upcoming PDL-2.014 release next Monday. The highlight of this release is the completion of 64bit support which I believe should address the problems which de-railed PDL from the Debian packages. Could you please try the current CPAN developers release ( CHM/PDL-2.013_04.tar.gz ) and report if it now builds on the big-endian systems (I think that was where the problems were)? With this release, I would like PDL closer to the current baseline (e.g., dozens of bugs have been fixed since PDL-2.007). PDL-2.014 should be the best PDL yet! I look forward to your prompt response. Thanks, Chris |
|
From: Craig D. <def...@bo...> - 2015-10-05 23:51:38
|
I’m planning a PDL::Graphics::Gnuplot release to coincide with Chris’s awesome PDL release next Monday. This is a good time for anyone to gripe and/or make a (smallish) feature request before I zip up the current git in a couple of days and send it to PAUSE. The main functional update for P::G::G 2.06 is a default output file for each file-based device (up till now, failing to specify a file output caused P::G::G to throw an error). There are some minor updates in the documentation, too. Alien::Gnuplot also gets a minor update to avoid an edge case that was losing some devices from the valid-device list. |
|
From: Chris M. <dev...@gm...> - 2015-10-04 19:24:13
|
All- With the release of PDL-2.013_03 today, it appears that the remaining critical issues with long double perls have been addressed. Although there are a number of CPAN Testers FAIL reports that can be fixed, there appear to be no blockers for a PDL-2.014 release next Monday, 12-Oct-2015. I would ask folks to download and test this latest CPAN developers release ( CHM/PDL-2.013_03.tar.gz ) on their platforms. Also, if you have PDL based distributions, please verify that they build and run with this latest PDL. This release finishes the 64bit index support and the known issues. While there may be some further additions to the PDL release, if nothing else makes it in this will still be a release of which we can be proud. Also, now is the time to add those fixes and additions to the PDL documentation. Thanks, Chris |
|
From: Craig D. <def...@bo...> - 2015-10-04 04:08:31
|
Yes, and that can be a pain. But it is not so bad to roll one's own for a corner case like that. (Mobile) > On Oct 3, 2015, at 3:14 PM, Chris Marshall <dev...@gm...> wrote: > > Don't you lose the PP threading for the OtherPar PDL *? > >> On 10/3/2015 17:11, Craig DeForest wrote: >> Sorry I missed the first iteration. You want something like the $T macro, which will substitute source code snippets depending on the $GENERIC type. But by the time you see the PDLs they will have been coerced to a common type, in a vanilla PP routine. I suggest passing the second argument in as an OtherPar of type PDL *. Then you can examine its type explicitly with a switch statement and do what you want. >> >> (Mobile) >> >> On Oct 3, 2015, at 11:00 AM, Chris Marshall <dev...@gm...> wrote: >> >>> I don't think it can be done in one PP routine but I can >>> implement the overload sub so that it uses power for the >>> non-integer exponent cases and ipow for integer exponents. >>> >>> --Chris >>> >>>> On 10/2/2015 11:00, Chris Marshall wrote: >>>> >>>> I would like to implement integer exponentiation support for ** that >>>> is used when the exponent is an integer data type. Unfortunately, I >>>> can't figure out how to conditionalize the code so that pow is called >>>> for float type exponent but ipow is called for integer type >>>> exponents. The generic type info is for the result of the operation >>>> as a whole and not helpful here. >>>> Suggestions? >>>> Chris >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> pdl-devel mailing list >>> pdl...@li... >>> https://lists.sourceforge.net/lists/listinfo/pdl-devel > |
|
From: <sis...@op...> - 2015-10-04 02:08:43
|
-----Original Message-----
From: sis...@op...
Sent: Sunday, October 04, 2015 12:38 PM
To: pdl...@li... ; Chris Marshall
Subject: Re: [Pdl-devel] PDL-2.013_02 tester build failure
> For me (on Ubuntu), the error is avoided if I replace:
>
> warn("Precision loss due to 'long double' to 'PDL_D' conversion!");
> with:
> Perl_warn(aTHX_ "Precision loss due to 'long double' to 'PDL_D'
> conversion!");
Sorry - I subsequently discover that I also need that fix in place on
Windows.
Is it the same on kmx's "long double" Strawberry build ? (Some offlist
discussion I had received suggested that 2.013_02 was working ok there -
with no mention of any fix being needed.)
Cheers,
Rob
|