New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bleadperl between fa1e92c and e08be60 breaks MAGGIEXYZ/PDL-Stats-0.5.5.tar.gz #11835
Comments
From @andkgit bisect * v5.14.0-285-gfa1e92c broke PDL (tested with CHM/PDL-2.4.9_992.tar.gz) * v5.14.0-408-ge08be60 made PDL pass tests again * when PDL came back passing, PDL::Stats (tested with diagnostics http://www.cpantesters.org/cpan/report/0e156db2-9266-11e0-8ca7-e3acbd5b0f7c perl -V Summary of my perl5 (revision 5 version 15 subversion 0) configuration: Characteristics of this binary (from libperl): -- |
From @cpansproutOn Sun Jan 01 12:06:27 2012, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
At least on a Mac, with v5.15.6-235-g7d9189d, I can’t even get as far as ... -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From dcmertens.perl@gmail.comThanks for bringing this up. I've forwarded it to the PDL porters. I can't David On Sun, Jan 1, 2012 at 4:10 PM, Father Chrysostomos via RT <
-- |
From @cpansproutOn Sun Jan 01 14:10:26 2012, sprout wrote:
$ uname -a And Linux, too: $ uname -a On the Mac I was compiling with -Dusedevel -Dmad -Duseithreads,
I’ve done more than a few blead builds to find out when things changed. In some versions, the .= 0 in this script has no effect: $ ~/blead/bin/perl5.15.0 -Mblib -e 'use PDL::LiteF; my $a = sequence [ [ I’m calling that ‘bad .=’. In others, it dies with ‘Can't modify non-lvalue subroutine call’, but $ ~/blead/bin/perl5.15.0 -Mblib -e 'use PDL::LiteF; my $a = sequence [ [ I’m calling that one ‘non-lvalue’. The typemap error when building PDL I’m calling ‘typemap problem’. Here is the timeline, starting with the commit that made PDL tass its v5.14.0-408-ge08be60 (v5.15.0~284) bad .= v5.15.0 (v5.15.1~391) bad .= v5.15.1~336 bad .= v5.15.1~335 non-lvalue v5.15.1~93 non-lvalue (ExtUtils::ParseXS branch follows) 9689328~38 non-lvalue 9689328~25 ExtUtils::ParseXS won’t build 9689328~18 non-lvalue 9689328~13 non-lvalue 9689328~12 typemap problem v5.15.1~92 (ExtUtils::ParseXS branch merged) v5.15.1~91 typemap problem v5.15.1 typemap problem (This sort of thing is far too complicated to do with git bisect. Most of the changes are my fault. I haven’t looked into PDL in detail commit 5a784a6 Error handling/message improvements |
From @sisyphus----- Original Message -----
This is the result of some poor coding practices in Core.xs.pl (from which This poorly written code was fixed a while ago, and the problem no longer Cheers, |
From @tseeOn 01/03/2012 10:11 PM, Sisyphus wrote:
Thanks for that. I dimly remember investigating this back when I did the What's the likelihood of seeing a stable, fixed PDL release soon? Or am Cheers, |
From moocow.bovine@gmail.comOn Tue Jan 03 22:56:29 2012, smueller@cpan.org wrote:
The devel release CHM/PDL-2.4.9_992.tar.gz just built ok here with perl I would also like to note that MOOCOW/PDL-CCS-1.17.tar.gz also fails $a=sequence(4); The most recent perl under which this seems to work according to PASS: |
From [Unknown Contact. See original ticket]On Tue Jan 03 22:56:29 2012, smueller@cpan.org wrote:
The devel release CHM/PDL-2.4.9_992.tar.gz just built ok here with perl I would also like to note that MOOCOW/PDL-CCS-1.17.tar.gz also fails $a=sequence(4); The most recent perl under which this seems to work according to PASS: |
From @sisyphus----- Original Message -----
PDL-2.4.10 is imminent. Cheers, |
From @cpansproutOn Wed Jan 04 09:45:26 2012, sisyphus1@optusnet.com.au wrote:
Unless there will be another PDL release after that before May, I think I’ve noticed that the latest dev PDL (2.4.9_992) has ‘no warnings I made a mistake in my timeline. The non-lvalue problem was introduced I(t) changed attributes.pm to warn when applying the lvalue attribute to sub foo:lvalue started doing that in 5.12, and I was trying to make Perl 5.12 started warning and not applying the attribute, because sub foo :lvalue and sub foo { @a } do not do the same thing. The lvalue attribute affects the way the PDL happens to be unaffected by the fact that the compiled op tree is So it seems to me that PDL could easily create lvalue stubs via On the other hand, attributes.pm is rarely used directly, so I would not Giving people enough rope, with a caveat (‘caution: you may hang’ :-), BTW, reverting bb3abb0 makes everything work, including PDL::Stats and So now I have to ask both p5p and pdl-porters: Which is the best way (And could someone please forward this to pdl-porters? Thank you.) P.S.: I think PDL’s test suite needs to cover lvalue subroutines. It is -- Father Chrysostomos |
From @sisyphus----- Original Message -----
We are aiming for a 2.4.11 before then.
We'll turn them back on for 5.15 and later. (Is there any reason that they
Done.
Noted. Thanks for taking the time to have a look (and a think) about this. Cheers, |
From @cpansproutOn Thu Jan 05 17:32:44 2012, sisyphus1@optusnet.com.au wrote:
Is there any reason to disable them for older perls? (From reading the changelog quickly, I thought ‘no warnings 'misc'’ had Of course, whether you have warnings on or not is irrelevant now that we
-- Father Chrysostomos |
From @rjbsThere were at least two distinct threads about this on p5p recently, at least one of which What's the current status of this blocker? |
From [Unknown Contact. See original ticket]There were at least two distinct threads about this on p5p recently, at least one of which What's the current status of this blocker? |
@rjbs - Status changed from 'open' to 'resolved' |
From @cpansproutOn Tue Feb 28 20:16:32 2012, rjbs wrote:
It’s currently marked ‘resolved’, by you. :-) PDL currently uses attributes.pm to set the lvalue attribute on a Because :lvalue has never actually worked properly on existing Perl Now, the inability of :lvalue to make an already-defined Perl sub into a So the question is: Should PDL work around this, or should we give -- Father Chrysostomos |
@rjbs - Status changed from 'resolved' to 'open' |
From @rjbsOn Tue Feb 28 20:44:19 2012, sprout wrote:
Whoops! Must've clicked "resolve" instead of "reply." Unresolved.
Got it.
I *think* this is an unusual case, so I am tempted to say that PDL should My next reaction then would be that: * we should restore the rope I'm very interested in your thoughts on that plan. |
From @cpansproutOn Wed Feb 29 06:58:21 2012, rjbs wrote:
That sounds good to me. I was started to get a bit concerned about forcing PDL to adapt *now*, Restoring the rope but leaving the warning (which PDL already -- Father Chrysostomos |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-02-29T12:22:23]
Great. I'm, uh, gonna leave that to you to take care of? :) That work for -- |
From @cpansproutOn Wed Feb 29 17:51:12 2012, perl.p5p@rjbs.manxome.org wrote:
Yes, but it may be a few days. -- Father Chrysostomos |
From @cpansproutOn Wed Feb 29 06:58:21 2012, rjbs wrote:
Done with commit 345d70e.
Commit c217304.
Untested. I have to go now, so I would appreciate it if someone would -- Father Chrysostomos |
From dcmertens.perl@gmail.comWow, wonderful. Sorry I've been mostly absent from the discussion. The On Thu, Mar 1, 2012 at 2:36 PM, Father Chrysostomos via RT <
-- |
From @rjbs* David Mertens <dcmertens.perl@gmail.com> [2012-03-01T18:18:58]
Does this mean that you've tested it with bleadperl and confirmed things are -- |
From @sisyphusOn Thu Mar 01 15:30:09 2012, perl.p5p@rjbs.manxome.org wrote:
I don't know if David has tested it - but I've just tested this on MS However, I don't see any warnings during the running of the I think you can safely close this bug report - unless this "no visible Cheers, |
@rjbs - Status changed from 'open' to 'resolved' |
From @rjbs* Sisyphus via RT <perlbug-followup@perl.org> [2012-03-01T22:49:01]
FC wrote, earlier: Restoring the rope but leaving the warning (which PDL already Will close. Thanks very much, Rob. -- |
Migrated from rt.perl.org#107366 (status was 'resolved')
Searchable as RT107366$
The text was updated successfully, but these errors were encountered: