Front page | perl.perl5.porters |
Postings from April 2016
Re: [perl #127875] Blead breaks Scope::Upper
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
April 18, 2016 10:16
Subject:
Re: [perl #127875] Blead breaks Scope::Upper
Message ID:
20160418101056.GB4160@iabyn.com
On Tue, Apr 12, 2016 at 07:45:12PM -0400, Ricardo Signes wrote:
> Still, there has to be a line drawn between what can be supported and what
> cannot, and right now that line is the public API. It's not a great line. We
> have talked about trying to improve it in the past, but so far nothing has
> actually been done. What we've said in the past is that if you want to build
> something that you can rely on, by all means build it now, but then come to p5p
> and say, "Look, I made a thing. This thing is useful. I want to make sure it
> doesn't get broken in the future. What can be done?" (This gets to what was
> (b) in Tony's mail.)
>
> That shares the onerousness: some for p5p to provide a public API and some for
> the reporter to rework code to use it.
I've spent the last week doing more work on Scope::Upper. I have it down
to 6 failing test scripts out of 58. The main failures at the moment are
the uplevel ones - uplevel being a mechanism to run a sub apparently in a
higher scope. I don't think the current implementation is fixable and will
need to be done a different way, which I will need to think about. I also
haven't tried it on perls older than 5.23.7 (I've been testing using
5.23.7 and 5.23.8 as representing the pre- and post-context perls), so may
need more fixes to run on older perls.
But one thing that should be made clear; it isn't just the case that S::U
is doing something which relies on an internals-only API and that we have
the choice of making this API public; instead it is an inherently fragile
implementation that is extremely sensitive the exact details of how the
save stack is manipulated. It works by artificially altering the
boundaries of N parent savestack frames, then within each SAVEt_DESTRUCTOR
action called while freeing a savestack frame that has an artificially
increased lower bound, it itself frees the savestack items below that
higher threshold, then injects another SAVEt_DESTRUCTOR below that
threshold so that it appears to be in the caller's savestack frame. These
propagate on each scope exit until the desired scope level is reached.
So I don't think there's any sensible API we could create that would
shield S::U from the details of perl's internals. Also, I don't think
S::U should be included in core. We should be discouraging this module's
use, not implicitly endorsing it.
Also, although I have been putting in considerable effort to fix this
module, I don't think I *should* have to do this, nor should it be
expected that p5p will do similar fixups in future.
--
print+qq&$}$"$/$s$,$a$d$g$s$@$.$q$,$:$.$q$^$,$@$a$~$;$.$q$m&if+map{m,^\d{0\,},,${$::{$'}}=chr($"+=$&||1)}q&10m22,42}6:17a2~2.3@3;^2dg3q/s"&=~m*\d\*.*g
Thread Previous
|
Thread Next