Front page | perl.perl5.porters |
Postings from September 2010
[PATCH] Re: [perl #77548] Runtime hinthash from XS
Thread Previous
|
Thread Next
From:
Ben Morrow
Date:
September 4, 2010 08:08
Subject:
[PATCH] Re: [perl #77548] Runtime hinthash from XS
Message ID:
20100904150742.GA90850@osiris.mauzo.dyndns.org
Quoth ben@morrow.me.uk (Ben Morrow):
> Quoth rafl@debian.org (Florian Ragwitz):
> >
> > I'm not fully happy with the naming.
> >
> > All other hints-related code in the core I've seen so far refers to the
> > hints hash as "hints", not "hinthash". Also a function called
> > hinthash_2hv not actually taking a hinthash but returning the hinthash
> > as an HV seems slightly off.
> >
> > cop_fetch_hint_hv/cop_fetch_hint_{x,sv,pvn,pvs}, maybe?
>
> I agree, though I think I prefer cop_hints_fetch(sv|pv[ns]) and
> cop_hints_2hv. I think the '2hv' is important, because it isn't
> returning the actual hinthash but rather a copy of it.
OK, I've done up a new patch with these names.
> > Also, have you had a look at Devel::Caller's upcontext function? It was
> > originally based on the code you factored out into caller_cx, but is now
> > rather different. I'm curious if the new caller_cx function provides
> > everything that'd be needed to have Devel::Caller run on it.
> >
> > There's also many more caller() implementation in xs, but they all seem
> > to be cargo-culted from Devel::Caller, so I guess it'd be nice if at
> > least that one was possible to be ported to caller_cx.
>
> I haven't (or, at least, not recently, so I can't remember the details).
> I did look at PadWalker, and AFAICT caller_cx is *not* sufficient for
> that, but I wasn't entirely following what was going on there.
OK, I've now looked at all this more carefully. Devel::Caller no longer
has its own implementation, but uses PadWalker's. This differs from
caller_cx in two ways:
- It always returns the frame for the actual sub, rather than going
up an extra frame if this sub was called from &DB::sub. This means
that D::C and PW would need to use the dbcxp parameter rather than
the return value.
- It returns some other information about which callstack the frame
was found in, and where we started and finished looking. PW seems
to be using this to go grovelling around looking for evals: I
don't quite see what this accomplishes, but I suspect it's left
over from the days when evals weren't properly lexically scoped.
D::C doesn't use those parameters at all (the
PadWalker::_upcontext XSUB, rather than the C function behind it,
doesn't support them anyway).
So yes, I believe D::C (and almost certainly PadWalker) could be
rewritten to use caller_cx (though PadWalker would need to use its own
stack-chasing logic on perls before 5.10, even if caller_cx was
available through ppport.h). I haven't tested this, though.
Ben
Thread Previous
|
Thread Next