There's this addition in the autoload sub, which i'm not sure is
intentional:
printf($AUTOLOAD); printf("\n");
--
With regards,
Christian Walde
--
___
pdl-devel mailing list
Thanks a lot, Chris!
Marek
On Tue, 16 Jun 2015 at 15:57 Chris Marshall wrote:
> Marek-
>
> I've opened a highest priority bug report based on your information:
>
> http://sourceforge.net/p/pdl/bugs/390
>
> Could you add information on your system specifics to the ticket
> for reference (the
Marek-
I've opened a highest priority bug report based on your information:
http://sourceforge.net/p/pdl/bugs/390
Could you add information on your system specifics to the ticket
for reference (the output of perldl -V has the main information)?
We'll be updating the ticket as information beco
This is very bad news for me. I just searched through my scripts and found
586 instances of 'stats'. If this is not corrected, I have to assume that
all of them might potentially produce incorrect results, without even
failing (like in the if($s > 0) example).
We've been using 2.007 for a couple o
OK, thank you for your explanations. I'm not sure if all of this makes
sense. If you try
print $s > 5;
in the above example, you will get 'BAD'. 5 is just a scalar and not a bad
value. And $s is a one-dimensional piddle with a value different from the
bad value. Neither of the values in this cond
That definitely seems like a bug to me. Thanks for the cross-check, Marek.
Devels, I see the same in the latest PDL release so it is not a
PDL-2.007 only issue.
--Chris
On 6/16/2015 09:36, Marek Gierliński wrote:
OK, thank you for your explanations. I'm not sure if all of this makes
sense. I
> Note that Chris's successful build of OpenGL on SPP 5.22.0.1 is against
> freeglut-2.8.1. (OpenGL doesn't build there against freeglut-3.0.0 either
> - so SPP shipped with 2.8.1.)
Exactly, if anyone wants to experiment with SPP 5.22.0.1 + freeglut-3.0.0
then download
http://strawberryperl.co
I wonder if there is a way we could bulletproof the XS->C build process.
For example, xsubpp could generate an assertion that would check for
#defined values that match variable names. The question is how to
avoid cases where this is exactly what you want. Maybe generate a
warning instead?
--Chr
All-
I'm happy to also report that PDL-2.012 seems to passing the
ASPerl builds as well. One build failed due to out of memory
in the VM (not PDL's fault although the machine generated
code does put quite a load on the compiler).
The remaining non-PDL-2.012 builds do have PPMs for either
PDL-2.
This result seems to violate the principle of least surprise.
On the LHS we have a PDL with badvalue(0) and on the RHS we
have a perl scalar with value 0 (which happens to be the bad
value for the PDL).
It seems surprising that $pdl > 0 is actually $pdl > pdl(0)->badvalue(0)
Thoughts?
Chris
--
Thanks for the update - will investigate and hopefully fix today! - Bob
> On Jun 15, 2015, at 12:27 PM, Chris Marshall wrote:
>
> I wish I had read this email earlier. :-)
>
> I can report that I was able to build OpenGL-0.6704_01 on the recent SPP
> 5.22.0.1 with the PDL 2.009_01.
> It requ
I'm delighted to report that with this release, the UNKNOWN
reports from CPAN Testers have dropped from ~20% to <2%
which makes PDL-2.012 test as good or better than all previous
PDL releases. The results are still coming in but it looks like
a new high water mark for PDL performance.
Thanks to e
-Original Message-
From: Ed
Sent: Tuesday, June 16, 2015 5:48 PM
To: sisyph...@optusnet.com.au ; Bob Free ; Chris Marshall
Cc: pdl-devel@lists.sourceforge.net ; kmx
Subject: Re: [Pdl-devel] CHM/OpenGL-0.6704_01.tar.gz uploaded to CPAN
> I'll bet "far" and "near" are #defined to blank, and
I'll bet "far" and "near" are #defined to blank, and are a Windows
pointer-size related issue. Seems best to avoid using them as identifiers in
any case, ie push Rob's changes upstream?
Ed
-Original Message-
From: sisyph...@optusnet.com.au
Sent: Tuesday, June 16, 2015 1:33 AM
To: Bob F
14 matches
Mail list logo
