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 v5.25.5-65-g5012eeb breaks JJORE/Devel-OptreeDiff-2.3.tar.gz #15645
Comments
From @andkbisect commit 5012eeb make OP_SPLIT a PMOP, and eliminate OP_PUSHRE diagnostics http://www.cpantesters.org/cpan/report/63ec077c-8aaf-11e6-b985-0de4bb799c77 perl -V Summary of my perl5 (revision 5 version 25 subversion 6) configuration: Characteristics of this binary (from libperl): |
From @andkalso affected: BRUMMETT/Devel-Chitin-0.09.tar.gz |
From @jkeenanOn Thu Oct 06 12:54:02 2016, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Report for the above: http://www.cpantesters.org/cpan/report/c39136d4-8b04-11e6-bbf9-728ebb799c77 A *non-thorough* analysis of these failure reports: Both of these libraries are peering into the Perl 5 optree. Their test suites set up specific expectations as to the state of optrees. My *hunch* is that these expectations were set up based on the state of the internals at a given point in time rather than on documented APIs. Hence, it's quite plausible that changes in the internals would spark test failures, not because the changes in blead are bad but simply because the expectations are no longer valid. I think the maintainers of these libraries should take a look at the failure reports before we take further action. Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Thu, Oct 06, 2016 at 11:37:46AM -0700, Andreas J. Koenig via RT wrote:
The failing test expects a nulled rv2sv op to have a specific op_targ So that module's tests need updating. -- |
From @iabynOn Thu, Oct 06, 2016 at 09:53:32PM +0200, Andreas Koenig wrote:
I don't really understand what this module and test is doing, but it's Can't call method "deparse" on an undefined value at This is happening in a function called pp_split() in a src file called -- |
From @dcollinsnWhile smoking CPAN modules against various versions of Perl, I noticed the Bisects to: HEAD is now at 1c56654 Time-HiRes: explicit clockid_t cast for C++11 make OP_SPLIT a PMOP, and eliminate OP_PUSHRE Most ops that execute a regex, such as match and subst, are of type OP_SPLIT is different; it is just a plain LISTOP, but it always has an At runtime, pp_pushre()'s only job is to push itself (i.e. the current This is a bit unpleasant, because we're pushing an OP* onto the stack, Now that regexes are first-class SVs, we could push a REGEXP onto the But if we're doing that, then why not just go the full hog and make That is exactly what this commit does. For a simple compile-time pattern like split(/foo/, $s, 1), the optree before: after: while for a run-time expression like split(/$pat/, $s, 1), before: after: This makes the code faster and simpler. At the same time, two new private flags have been added for OP_SPLIT - Also, deparsing of split has been improved, to the extent that perl TEST -deparse op/split.t now passes. Also, a couple of panic messages in pp_split() have been replaced with :040000 040000 e627cd701d4a5444ae8edc9c666e594dddc5636a Diagnostics attached. Luckily this appears to be the only CPAN module that Perl -V: Summary of my perl5 (revision 5 version 25 subversion 6) configuration: Characteristics of this binary (from libperl): |
From @andkLooks like a duplicate of 129821 -- |
The RT System itself - Status changed from 'new' to 'open' |
From @dcollinsnAgreed. So should we also submit tickets to the individual distributions, On Oct 13, 2016 1:55 AM, "(Andreas J. Koenig) via RT" <
|
From @andk
> Agreed. So should we also submit tickets to the individual distributions, In doubt more eyes are better. -- |
From @andk
> In doubt more eyes are better. I've now openend 118372..118374 on cpanrt.org. -- |
From @dcollinsnAlso B::Debug: # Failed test at t/debug.t line 81. Will link CPAN RT momentarily |
From @jkeenanOn Thu, 06 Oct 2016 19:54:02 GMT, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
https://rt.cpan.org/Ticket/Display.html?id=118373#txn-1678351 CPAN maintainer has released a new version. -- |
From @iabynOn Tue, Dec 06, 2016 at 02:26:15PM -0800, James E Keenan via RT wrote:
... but the remaining distributions haven't been fixed yet: Devel-OptreeDiff-2.3 #118372 -- |
From @iabynOn Wed, Dec 07, 2016 at 09:19:32AM +0000, Dave Mitchell wrote:
I note in the ticket for B::Debug, Reini suggests removing B::Debug from Anyone have any options yay or nay? -- |
From @xsawyerxOn 12/07/2016 01:14 PM, Dave Mitchell wrote:
The only situation we might encounter, which is a situation for each No objections from me, though. |
From @iabynOn Thu, Dec 08, 2016 at 12:33:34PM +0100, Sawyer X wrote:
Well, B::Debug is unlikely to be used in production, rather, only as a -- |
From @xsawyerxOn 12/09/2016 09:49 AM, Dave Mitchell wrote:
My thoughts exactly. That's why I'm not objecting whatsoever. :) |
From @jkeenanOn Wed, 07 Dec 2016 09:20:00 GMT, davem wrote:
Both Devel-OptreeDiff and Classic-Perl are relying on specific implementations of the Perl internals. As such, it's up to the authors/maintainers to adapt to changes in those internals. For both those distros suggestions and/or cross-references have been made in their rt.cpan.org bug trackers. Hence, the only obstacle I see to closing this RT is the status of B::Debug. Where do we stand with respect to that? Thank you very much. -- |
From @iabynOn Fri, Dec 09, 2016 at 08:49:15AM +0000, Dave Mitchell wrote:
Although having just done a http://grep.cpan.me/, it appears that But given that, I suggest we defer removing B:;Debug from core till after -- |
From @iabynOn Sun, Dec 25, 2016 at 06:46:57PM -0800, James E Keenan via RT wrote:
A new release of B::Debug was made and pulled into blead on Dec 15. -- |
From @jkeenanOn Mon, 26 Dec 2016 11:46:00 GMT, davem wrote:
Hence, no more issues for P5P to deal with. Closing ticket. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'resolved' |
From @xsawyerxOn 12/26/2016 02:09 PM, James E Keenan via RT wrote:
True, but we should also make sure to not remove B::Debug before 5.26. |
From @jkeenanOn Mon, 26 Dec 2016 17:11:56 GMT, xsawyerx@gmail.com wrote:
Created https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130410 and added it to perl-5.28-blockers ticket. -- |
Migrated from rt.perl.org#129821 (status was 'resolved')
Searchable as RT129821$
The text was updated successfully, but these errors were encountered: