,
I see the way forward as Diab and I being co-maintainers. If it’s
easiest, I’ll be happy to be first-come, then I can add Diab as co-maint.
My ID is “ETJ”. Could you include ExtUtils::F77 in the process?
Best regards,
Ed
*From:* Chris Marshall <mailto:devel.chm...@gmail.com>
*Sent:* Monday,
Ed/Diab-
I think it is time to get out of the way. Would you be willing to accept
maintainership of all the PDL modules. You would be able to delegate as
needed. Please confirm your PAUSE IDs and let me know to whom to assign
ownership.
Thanks,
Chris
___
Diab,
I think another "bitrot fix" release of the legacy PDL is a good idea.
Thanks for volunteering to be release manager. I'm happy to transfer the
various PDL maintainerships I have accumulated over time. Then you can
distribute any co-maintainerships and handle any other module rights stuff
The last time I investigated the failures to build it appeared to be issues
with virtual machines memory sizes or possibly buggy compiler versions.
--Chris
On Fri, Nov 30, 2018 at 2:18 AM Derek Lamb wrote:
> After updating the install webpage for SciPDL I was looking at updates to
> the instruc
that as the authoritative location for them.
If you like that thought, then we don't need a "push freeze", just everyone
points each of their repo "origin" at the GitHub location! Then as you say
we can just make PRs and when you're happy you can release them to
Let's have a "push freeze" for:
PDL::LinearAlgebra
PDL::Book
PDL::Graphics::PLplot
PDL::IO::HDF5
PDL::FFTW 2.x
pdl-www
and switch to the github repositories.
Most were adopted by me as their original
developers moved on and their update rate has
been almost nothing since PDL-2.018.
Announcing the release of PDL-2.019 as the first
release marking the move of PDL development from
the increasingly erratic sf.net to github.
Thanks much to Ed J, Derek Lamb, Jerry Leibold,
and sisyphus for contributions to this release
and special thanks for Ed J who spearheaded the
move and has
Hi Jerry-
Thanks for taking the time to contribute
to PDL!
The "secret sauce" for your contribution
is that MatrixOps.pm a generated file
which is why it was in .gitignore.
The source file is matrixops.pd in the
same Basic/MatrixOps directory at line
#364. The patches needed would be the
one f
ld you now make a dev-release? I’m going to ensure the SF bugs
> are all on GH issues.
>
> Best regards,
> Ed
>
> *From:* Ed .
> *Sent:* Monday, April 09, 2018 4:39 AM
> *To:* pdl-devel@lists.sourceforge.net ; Chris Marshall
>
> *Subject:* Re: [Pdl-devel] unstable SF g
Christian’s script – no more error emails!
Can anyone see things I missed or got wrong there?
Ed
*From:* Christian Walde <mailto:walde.christ...@gmail.com>
*Sent:* Tuesday, March 06, 2018 5:56 PM
*To:* pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net> ; Ch
Will-
Any progress with the work around? I'm on #pdl today.
--Chris
On 3/22/2018 16:31, Chris Marshall wrote:
Makefile.PL is the file in which the File::Map line needs to be
deleted
On Thu, Mar 22, 2018 at 4:30 PM, Chris Marshall
mailto:devel.chm...@gmail.com>> wrote:
Hi Will-
I understand your frustration in not being able to
build/install PDL.
When we/I say it is not a PDL bug, we don't mean
that the bug doesn't affect PDL as it clearly does
since we require File::Map which requires PerlIO::Layers.
It means that the fix is not in the PDL code and that a
bug
Makefile.PL is the file in which the File::Map line needs to be deleted
On Thu, Mar 22, 2018 at 4:30 PM, Chris Marshall
wrote:
> A quick look at the CPAN testers reports for
> PerlIO::Layers show passes for your perl version
> and many others on Mac platforms. I can't help
A quick look at the CPAN testers reports for
PerlIO::Layers show passes for your perl version
and many others on Mac platforms. I can't help
with a debug for your build there...
...but you can delete the line containing the
string 'File::Map' to removed the hard dependency
for PDL on this module.
Christian and all-
I'm fine with moving development and issues
to github if someone wants to take the lead
to maintain things on github.
We should do a quick release to point at
the new locations and maybe include a few
fixes in the hopper. I'm not sure that
all the sf.net bugs are on github at
Hi Derek-
The tests all pass for cygwin/win7 but I did notice
that the imag2d.pd does not appear to have been
updated for 64bit index support as all the types
therein are either int for PDL_Long which may be
related to the windows issues---or not.
--Chris
On 11/3/2017 19:48, Derek Lamb wrote:
Hi Edward-
It seems that the docs may be out of date
with respect to the implementation. I get
pdl(), piddle(), null(), and barf() missing
errors using only PDL::Lite.
The piddle() routine seems to be equivalent
to pdl() but is not documented AFAICT.
It is worth opening a ticket to report
the
I'm pleased to observe that PDL-2.018 is PASS-ing
CPAN Testers with 150 PASSes and only 1 FAIL (plus
some UNKNOWN and NA). My conclusion is that
we've resolved the bitrot problem...until the next
time! :-)
Cheers,
Chris
On 5/21/2017 17:21, Chris Marshall wrote:
...and should be ap
Everything seems to be running fine but when pl2bat.bat
is run there appears to be a crash of some sort. The
logs don't give a clue but maybe someone more familiar
with the ASPerl PPM builds could help debug:
http://ppm4.activestate.com/MSWin32-x86-64int/5.24/2400/C/CH/CHM/PDL-2.018.d/log-2017052
...and should be appearing at a CPAN mirror near you soon.
The PDL Developers are pleased to announce the 2.018 release
of the Perl Data Language. This release fixes some bugs and,
most importantly, addresses some coming build and compatibility
problems for PDL.
Thanks much to contributions by L
...and should appear at a mirror near you soon.
This is release candidate 1 for the immanent
PDL 2.018 planned for this weekend.
Test early; test often!
Thanks,
Chris for the PDL Developers
v2.017_02 2017-05-18 17:33:55-04:00
General Notes:
* This is version 2.017_02 of the Perl Data Langu
);
> |, $boolean);
which may be where the error is coming from. At
any rate, it seems not to be a PDL problem and
since there appear to be a small number of tests
with this problem, it doesn't need to hold up
the "bitrot fix" release process.
Thanks for looking,
Chri
have 0.68 and 0.62.
--Chris
On 5/7/2017 06:46, sisyph...@optusnet.com.au wrote:
>
> -Original Message- From: Chris Marshall
> Sent: Sunday, May 07, 2017 6:39 AM
> To: pdl-devel@lists.sourceforge.net
> Subject: [Pdl-devel] Inline failures for PDL-2.017_01...more bitrot
>
The PDL "bitrot fix" developers release is testing
well except for 3 reports where there is a failure
in t/inline-with.t and t/inline-comment-test.t:
http://www.cpantesters.org/cpan/report/9555ca7a-2d05-11e7-b551-93771d927244
http://www.cpantesters.org/cpan/report/97798df0-2d05-11e7-b551-93771d927
Per sf.net feature request #82:
https://sourceforge.net/p/pdl/feature-requests/82/
Now that we have the PDL_Indx data type for
indexing operations, it would seem to make
sense that operations returning index values
should have PDL_Indx as the default return
type. This breaks long existing API
I'm implementing some additional routines along
the lines of indadd. They provide other combining
operations which can be used to compute region
properties of component labelled piddles. At the
moment I have:
indadd
indmax
indmin
all of which are fairly straightforward. Then I saw
that
All-
We're looking for someone using MacOSX with experience in
compiling and linking XS/C code including OpenGL. We need
help to get OpenGL::Modern to compile and run on MacOSX.
This process is hampered by no developers with that hardware
and software platform.
The work involved is pretty much s
...and should be appearing at a mirror near you soon.
This release includes believed to be correct implementations
of all OpenGL routines that are neither called with or return
pointer type arguments (e.g. * or [] types).
It includes autogenerated routines for the rest with the
arguments replaced
This is another in a series of alpha releases of OpenGL::Modern.
It has candidate fixes for some build issues and now creates
bindings of all non-pointer OpenGL routines with the usual OpenGL
routine name. It also creates bindings for all the functions with
pointer or pointer-like arguments with
"has a" in place of "is a".
--Chris
On Wed, Oct 26, 2016 at 3:00 PM, Chris Marshall
wrote:
> I believe that the approach for PDL::NextGen core using the C Object
> System (COS) could address this problem: the operations being overloaded
> would then be multimetho
might avoid or
mitigate this problem...)
--Chris
On Tue, Oct 25, 2016 at 10:30 AM, Chris Marshall
wrote:
> On re-reading, I think the problem we're really discussing here is
> the operator overloading and the difficulty seems to be because the
> overload resolution doesn't handl
t sure
a real solution is possible save implementing overload using multi-methods.
--Chris
On Mon, Oct 24, 2016 at 1:30 PM, Chris Marshall
wrote:
> Thanks for the additional clarification for context---what a mess!
>
> From your example, it seems that the current PDL approach for OO via
> &q
Thanks for the additional clarification for context---what a mess!
>From your example, it seems that the current PDL approach for OO via
"has-a" doesn't work but my question is what method would work? Is there
an example of an OO language or framework that can be shown to work for
this type of pr
Hi Diab-
I haven't done much with subclassing from PDL but
I have noted some warts as in PDL::Complex.
For the PDL::NextGen work I would like to have an
approach that is interoperable with Moo[se] and
possibly other OO frameworks. One thought was to
make PDL-ness a Role rather than a class as th
ed things up by
avoiding hand transcription.
Cheers,
Chris
On 10/22/2016 02:36, Karl Glazebrook wrote:
Done.
https://dl.dropboxusercontent.com/u/2148080/SciPDL-v2.017.dmg
On 16 Oct 2016, at 6:17 AM, Chris Marshall wrote:
Hi Karl-
PDL-2.017 is testing very well (and cleanly with all the w
interpol() seems to be implemented in terms of
interpolate() already. Does seem a bit confusing.
Maybe the two routines could be merged into a
"smarter" interpolate()...
--Chris
On 10/15/2016 05:18, Karl Glazebrook wrote:
> Seems to me we should fix this inconsistency in usage?
>
> - Karl
>
> us
erwise it is fine. I have set it up to be easy.
>
> Karl
>
>> On 29 Sep 2016, at 12:34 AM, Chris Marshall wrote:
>>
>> Hi Karl-
>>
>> We're heading for a PDL 2.017 release on 10-Oct-2016. There are many bugs
>> fixed and all the warning messages
already made it into
Debian Unstable and Debian Testing. With this release, I
expect we'll see PDL-2.017 as the default PDL package from
the Debian perl maintainers.
Happy PDL-ing!
Chris Marshall for the PDL Developerment Team
> v2.017 2016-10-08 13:50:39-04:00
>
> General Notes:
ll : $self->{$_}->copy
> for $self->{$_->$_isa( 'PDL' ) };
> return bless \%new, ref $self;
>}
>
> It's inconsistent for copy() to return anything other than an exact copy.
>
> Could you define what you mean by "inappropriate context&q
A.k.a PDL 2.017 release candidate 1.
We're now in code freeze for the coming PDL-2.017.
Please test and confirm correct operations.
If you havea non-Core PDL module, now would be a
good time tocheck that it works with the release candidate.
Assuming things test well, thiswill become the new sta
Hi Karl-
We're heading for a PDL 2.017 release on 10-Oct-2016. There are many
bugs fixed and all the warning messages seem to be gone. Will you be
ready for a new SciPDL release by the 10-11th Oct?
Thanks,
Chris
--
__
committed
and verified before 03-Oct.
--Chris
On 9/17/2016 16:45, Chris Marshall wrote:
> All-
>
> Thanks to some vigorous coding and tests cleanup by Derek and Zaki, we
> plan to push a CPAN developers by this coming weekend. Assuming things
> check out there, it seems to be
This is a new CPAN developers release of PDL
including a number of build and bug fixes.
Please test and report any issues as it is
likely the RC1 for PDL-2.017 planned for
release early next month
Enjoy and Happy PDL-ing!
Chris
v2.016_02 2016-09-21 13:42:15-04:00
General Notes:
* This is
All-
Thanks to some vigorous coding and tests cleanup by Derek and Zaki, we
plan to push a CPAN developers by this coming weekend. Assuming things
check out there, it seems to be a good time for another release in the
PDL-2.x branch. If you have any bugs you would like to fix or docs to
scrib
of SciPDL...
> (1) including Perl itself and (2) making a draggable DMG rather than a
> packagemaker package. I suppose I could just call it 'newSciPDL' and match
> the version numbers
>
> - Karl
>
>
>> On 4 Jun 2016, at 11:05 PM, Chris Marshall wrote:
&g
Hi Karl-
I suggest opening a ticket with the information on platform,
compiler, and the log of issues. While warnings are often only
annoying, they can indicate a potential problem in general
or a platform specific one. Unfortunately, without a full,
multi-platform regression test suite, it can
iPDL-v3.1.dmg
>
> Can someone test? I tried to script it a bit but want an independent check
> for screw-ups
>
> Karl
>
>
>
>> On 28 May 2016, at 7:51 AM, Chris Marshall wrote:
>>
>> Hi Karl-
>>
>> Interested in updating SciPDL for the comin
Announcing the release of PDL-2.016 to CPAN.
It should be appearing at a mirror near you
shortly. This release fixes some bugs, adds
some features and addresses some build problems
that emerged since PDL-2.015 last November.
It would not have happened without the work
of some diligent PDL develop
Our current pdl packages on Debian are from 2.007 or earlier.
I've been unable to contact Henning Glawe by email or phone.
I'm now trying to connect with the debian science maintainers
about what to do next.
My last information was that the latest issue was that new
tests were being run that now p
Hi Karl-
Interested in updating SciPDL for the coming PDL-2.016 release?
Do you have any issues with the current release candidate?
Thanks,
Chris
Forwarded Message
Subject:SciPDL 3 for Mac OS X
Date: Sun, 8 May 2016 13:59:28 -0400
From: Chris Marshall
To
...and should be appearing at a CPAN mirror near you soon.
This CPAN developers release (a.k.a. PDL 2.016 release
candidate 1) includes the code changes expected for the
PDL-2.016 release. Please test with your configuration
and report any issues or problems needed fixing (with
solutions if poss
PDL Users and Developers-
I think we're ready for a CPAN developers release
candidate for coming PDL-2.016. If you have anything
you really think should be in PDL-2.016 that isn't
in already, please e-mail me immediately.
Barring any requests for an extension, I plan to push
a release candidate
/2016 12:50, Chris Marshall wrote:
> Thanks to a number of bug fixes and warts removed, I think we should
> aim for a PDL-2.016 polish/update/maintenance release this May.
> If you have any interest in grabbing and fixing a bug or a minor feature
> within the next couple of weeks, I invite
Hi Henning-
I was wondering what the status of getting an up to date Debian package
for PDL-2.015? I think the last I checked there was some issue with
tests being run that failed. Do you know if the current PDL fixes that?
It would be nice to have PDL-2.015 as the standard for Debian given t
In the ANYVAL_FROM_CTYPE macro, -1 for the type and 0 for the value is the
result when an non-handled type is processed. It probably works ok if an
enum were "just an int". More properly, we could add an PDL_INVALID to the
enum for types to handle the case. Given the fagility of the PDL-2.x type
I was looking at the PDL/Basic/Core for how the magic
was used and discovered that we appear to have a PDL
magic implementation that is similar to perl's but specific
to PDL. Is this correct? I'm interested because the idea
of controlling a vtable is tied with ideas for PDL Next Gen.
--Chri
Thanks to a number of bug fixes and warts removed, I think we should
aim for a PDL-2.016 polish/update/maintenance release this May.
If you have any interest in grabbing and fixing a bug or a minor feature
within the next couple of weeks, I invite you to do so.
--Chris
Looks good to me. Including the copyright info in the DATA section
appears to address any possible issues.
--Chris
On 2/25/2016 12:20, Derek Lamb wrote:
> I created a pull request (from branch lmfit) on GitHub earlier this week for
> some changes to the PDL::Fit::LM module. Most (all?) of the
Great!
Will cpanm/cpan/... work with the SciPDL? That
is a feature I really like with Strawberry Perl Portable.
I'll let actual Mac users and testers let you know how
it works. :-)
--Chris
On 1/27/2016 23:35, Karl Glazebrook wrote:
> Hi everyone
>
> I’ve been experimenting with a new version of
Hi Karl-
What Rob said but PDL::FFTW was moved to its
own distribution as of PDL-2.007 and the dead code
was removed in PDL-2.008 .. PDL-2.011.
PDL::FFTW 2.024 is only a stub module to provide
the following FFT safety message:
This module no longer exists on CPAN and is completely
unsuppor
Happy New Year-
I was reading the blog by Niel Bowers at
http://neilb.org/2015/12/22/cpan-river-water-quality.html
and thought his criteria seem reasonable to me.
PDL doesn't make the cut because of the
high number of test failures in CPAN Testers
reports, currently:
PASS (367) FAIL (23) NA (18
Forgot to send to pdl-devel.
Forwarded Message
Subject:Perl OpenGL 2 Development
Date: Wed, 23 Dec 2015 08:23:19 -0500
From: Chris Marshall
To: perldl
Announcing the newly activated Perl OpenGL
mailing lists for the existing POGL module
and, more
ing around to see what the ‘windows’ are made of. Open GL?
>
>> On 7 Dec 2015, at 1:59 am, Chris Marshall wrote:
>>
>> I couldn't find any but you could get the library
>> and build and run some of the Examples:
>>
>> http://www.arrayfire.com/docs/gr
gt;> On 7 Dec 2015, at 1:59 am, Chris Marshall wrote:
>>
>> I couldn't find any but you could get the library
>> and build and run some of the Examples:
>>
>> http://www.arrayfire.com/docs/graphics_2plot3_8cpp-example.htm
>>
>> I would be int
PDL Developers-
I had the pleasure to meet zowie in
person for dinner this week and a
chance to talk PDL. That makes 2
core developers that I have met.
It was nice to hear some of the
ways that he has been using PDL
in his work and some of the context
from the earlier days of PDL.
Now, that PDL-
eenshots?
>
>> On 2 Dec 2015, at 2:22 am, David Mertens wrote:
>>
>> And it has built-in graphics support:
>> http://www.arrayfire.com/docs/classaf_1_1Window.htm
>>
>> On Tue, Dec 1, 2015 at 9:51 AM, Chris Marshall
>> wrote:
>> See the very si
I think that the CPAN developers release recently
pushed by Maggie may have that fix in it:
MAGGIEXYZ/PDL-Stats-0.73_1.tar.gz
--Chris
On 12/4/2015 05:33, Ingo Schmid wrote:
Hi,
yes, I've seen it once in my code. It is the change to fix crashes on
reshape and related, if I remember.
A sim
ort:
> http://www.arrayfire.com/docs/classaf_1_1Window.htm
>
> On Tue, Dec 1, 2015 at 9:51 AM, Chris Marshall
> wrote:
>
>> See the very similar implementation of their
>> Indexing using parentheses (kind of like our
>> PDL::NiceSlice syntax):
>>
>> http://w
See the very similar implementation of their
Indexing using parentheses (kind of like our
PDL::NiceSlice syntax):
http://www.arrayfire.com/docs/indexing.htm
--Chris
On Tue, Dec 1, 2015 at 9:44 AM, Chris Marshall
wrote:
> All-
>
> One of the plans for PDL next gen (PDLng)
> was
All-
One of the plans for PDL next gen (PDLng)
was support for GPGPU computing. The
ArrayFire library
http://www.arrayfire.com/docs/index.htm
appears to offer a lot of the desired capability
and I think we might be able to use bindings
to it to accelerate an implementation. It even
has JIT s
All-
The current PDL-2.015 release candidate 2
( CHM/PDL-2.014_02.tar.gz ) is testing very
well and its time to stop tweaking and make
the official release.
At the moment, there are some final updates
to the Changes, Known_problems, and the
meta information for the release but no new
code changes
the idea of setting this parameter anywhere other than at
compile time. Action at a distance is madness at a distance…
On Nov 18, 2015, at 3:47 PM, Chris Marshall <mailto:devel.chm...@gmail.com>> wrote:
I agree that the this is a surprising result---even
if correct by our current
By the Principle of Least Surprise, we should
> therefore always autopromote to the most common case (double), and require
> explicit cast to get to floating-point values.
>
> Sorry for the wall of text here, this is a pretty cool bug.
>
>
> On Nov 18, 2015, at 1:42 PM, Chris M
I think we may need something like
an option to enable/disable forced
conversion of perl scalars to double
piddles.
--Chris
On Wed, Nov 18, 2015 at 3:03 PM, Chris Marshall
wrote:
> Hi Doug-
>
> I think the problem is only when
> a perl scalar is the input to atan().
> The top tw
Hi Doug-
I think the problem is only when
a perl scalar is the input to atan().
The top two cases are the expected
result. Maybe the logic in the type
conversion is off. You don't say
what version of PDL but I see the
same output from PDL-2.014_02.
--Chris
On Wed, Nov 18, 2015 at 1:29 PM, Dou
I don't know when or why this happened but the
PDL license is now listed as unknown on
http://search.cpan.org and on http://metacpan.org
Meta-experts assistance welcome!
Thanks,
Chris
--
__
Hi Bryan-
The problem is that PDL::PP has a safety check that the version of the PDL
core it was compiled against is the same as the version using the module.
Unfortunately, this version has nothing to do with the version numbers of
your modules and I don't know of a way to get the CPAN Testers to
some conditional code is missing? There is no file *gcc_ext* on
my system.
Cheers,
Chris
On 11/15/2015 09:54, Chris Marshall wrote:
> The repo magic looks good, Karl.
>
> Some of the extra checking breaks for cygwin.
> Which does have gfortran. I get this from make test:
>
> perl -M
The repo magic looks good, Karl.
Some of the extra checking breaks for cygwin.
Which does have gfortran. I get this from make test:
perl -Mblib t/require.t
1..2
ExtUtils::F77: Version 1.19
Loaded ExtUtils::F77 version 1.19
Found compiler gfortran
ExtUtils::F77: gfortran version 4.9.3
ExtUtils:
I'm currently working on some experiments to
use tinycc as a JIT compiler for the computational
code for a portable numeric library (the Perl
Data Language, http://pdl.perl.org).
We have a requirement to support computation
with complex numbers and arithmetic (C99).
The initial developments look p
any
guidelines for use of git and/or sf.net
repositories.
Merci en avance,
Chris Marshall
PDL Release Manager
http://pdl.perl.org
--
___
pdl-devel mailing list
pdl-devel
ficial PDL-2.015 so that any
potential issues from the Debian side
may be addressed if possible.
Cheers,
Chris
On 10/12/2015 14:00, Chris Marshall wrote:
> On 10/12/2015 13:46, Henning Glawe wrote:
>> On Wed, Oct 07, 2015 at 11:06:18AM -0400, Chris Marshall wrote:
>>> We're i
Hi Karl-
Craig is finishing up the fix for the reshape()
bugand a number of other issues with
PDL-2.014 have been addressed as well.
At this point I'm ready to release PDL-2.015
and call the PDL-2.x development branch
"done" for a while.
It would be nice if your fixes for the SciPDL
build could b
Hi Karl-
I was wondering how things are going with the SciPDL work?
I made a git branch on the sf.net repo ( karl-f77-fixes ) that
you can use as the starting point for your additions. Here
is a cheat sheet of working with the current PDL workflow
as applies to the stable PDL repository at sf.n
release. Help with debugging and
fixing welcome!
Thanks,
Chris
On Thu, Nov 5, 2015 at 6:19 AM, Chris Marshall
wrote:
> Good news/bad news story:
>
> We just had a report of a bug in clump(-N) for PDL-2.014.
> As in the reshape() bug, this can lead to invalid values and crashes.
&g
Good news/bad news story:
We just had a report of a bug in clump(-N) for PDL-2.014.
As in the reshape() bug, this can lead to invalid values and crashes.
I am able to reproduce the bug on my cygwin PDL-2.014 install.
The good news part is we have a specific code to debug.
See http://sourceforge.n
http://search.cpan.org/~chm/ExtUtils-F77-1.18/
On 11/1/2015 06:53, Chris Marshall wrote:
> 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
>
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 la
On Sun, Oct 25, 2015 at 12:46 AM, wrote:
> -Original Message- From: Karl Glazebrook
> Sent: Sunday, October 25, 2015 2:36 PM
> To: Chris Marshall
> Cc: pdl-devel@lists.sourceforge.net ; perldl
> Subject: Re: [Pdl-devel] [Pdl-general] PDL-2.014 release plans (SciPDL
> too
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
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
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
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
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
...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 mu
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.
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
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 wo
e 'IV' (aka 'long') not
compatible with any generic association type
if( !finite(nv) ) { return PDL_D; }
^~
Looking for some help with this one as well.
Thanks,
Chris
On 10/3/2015 17:22, Chris Marshall wrote:
> In this report
>
In this report
http://www.cpantesters.org/cpan/report/f2b520ac-6a02-11e5-af12-2392e0bfc7aa
the build fails because the pointer to the $PDL::SHARE Core
structure is not declared. I'm having trouble following the logic
since we have a declaration of PDL as a Core struct. The use of
warn as PDL->p
1 - 100 of 219 matches
Mail list logo
