Front page | perl.perl5.porters |
Postings from July 2012
Re: [perl.git] branch doy/runtime_isa_manipulation_bug, created. v5.17.1-337-gbd8c24f
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
July 29, 2012 13:45
Subject:
Re: [perl.git] branch doy/runtime_isa_manipulation_bug, created. v5.17.1-337-gbd8c24f
Message ID:
B066AF47-F28A-4C84-AEB8-3D894D6CBEEB@cpan.org
On Jul 29, 2012, at 1:12 PM, Jesse Luehrs wrote:
> On Sun, Jul 29, 2012 at 12:49:07PM -0700, Father Chrysostomos wrote:
>>
>> On Jul 12, 2012, at 10:13 PM, Jesse Luehrs wrote:
>>
>>> On Thu, Jul 12, 2012 at 10:00:08PM -0700, Father Chrysostomos wrote:
>>>>
>>>> On Jul 10, 2012, at 5:50 PM, Jesse Luehrs wrote:
>>>>> So the pure perl version worked fine, but I'm trying to adjust the XS
>>>>> version to do the same thing, and I'm really not sure what the right way
>>>>> to go about it is. gv_init isn't sufficient, because it doesn't attach
>>>>> the appropriate magic. The only function that knows about the kinds of
>>>>> magic that need to be attached to globs is gv_fetchpvn_flags, and that
>>>>> requires a stash name, rather than a stash pointer. Is there any actual
>>>>> API for stash aliasing in C (to work around this for now), or am I going
>>>>> to need to poke around at the internals to emulate the behavior?
>>>>
>>>> In 5.10 you have to emulate it:
>>>>
>>>> sv_magic((SV *)GvAVn(gv), (SV *)gv, PERL_MAGIC_isa, NULL, 0);
>>>>
>>>> In 5.12 (d851b122) you can do this:
>>>>
>>>> SV *rv = newRV_noinc(newAV());
>>>> sv_setsv(gv, rv);
>>>> SvREFCNT_dec(rv);
>>>>
>>>> In 5.17.2 (986d39eeb4) you can do this:
>>>>
>>>> GvAVn(gv);
>>>
>>> Sure, but @ISA is only a single case of magical variables. What if gv
>>> is intended for $main::{'^W'}, or something like that? I really don't
>>> want to have to hardcode all of the different variables that might have
>>> magic, especially since it changes between perl versions. The more I
>>> look into it though, the more I can't really see it being reasonably
>>> possible without modifications to the core (in particular, a variant of
>>> gv_fetchpvn_flags that looks things up in a provided stash pointer,
>>> rather than by name). I may have to just stick to name lookups in my
>>> code until something like this makes its way into core.
>>
>> perlsub says this:
>>
>> The construct
>>
>> local *name;
>>
>> creates a whole new symbol table entry for the glob C<name> in the
>> current package. That means that all variables in its glob slot ($name,
>> @name, %name, &name, and the C<name> filehandle) are dynamically reset.
>>
>> This implies, among other things, that any magic eventually carried by
>> those variables is locally lost. In other words, saying C<local */>
>> will not have any effect on the internal value of the input record
>> separator.
>>
>> I have always understood that to mean that undef */ stops $/ from working and it’s your own fault if you do that. (@ISA is different, in that its magicalness is not generally known, and 5.8 and earlier would reset all caches any time a subroutine was defined, preventing most of the stale cache problems we’ve had since 5.10.)
>>
>> Should that change? Maybe. I don’t know.
>>
>> Should we add a gv_add_magic API function? Maybe. I don’t know.
>>
>> What exactly is your use case?
>
> This is all for Package::Stash - I'm trying to get it to work properly
> with anonymous stashes (Package::Anon for now, although the long term
> goal is to have actual anonymous stash support in core). This means that
> I need to be able to apply things like @ISA magic when manipulating @ISA
> even if there is no name attached to the stash, which is difficult
> because gv_fetchpvn_flags is the only API to any of this, and its API
> requires the name of a package variable.
>
> I can work around this by bypassing gv_fetchpvn_flags (just doing a hash
> lookup on the stash HV* and using gv_init when necessary) and applying
> @ISA magic manually when necessary, but then I need to do things like be
> sure to also apply magic for $OVERLOAD (but only for certain versions of
> perl), and then things like $] also break, because the logic for
> autovivifying those variables is also in gv_fetchpvn_flags.
But $] is only supposed to be magical in the main stash. That it was also magical in other stash before 5.14 was a bug. @ISA is now the only magical variable for stashes other than main and core. As for overloading, we need a separate API for that that takes an HV argument.
However, VERSION and EXPORT still need the multi flag, so a gv_add_magic function is not a bad idea, but I wonder whether that name is appropriate.
>
> The issue is that gv_fetchpvn_flags does about four different things -
> converting fully qualified package variable names to a stash and key
> (including forcing things into main when necessary), looking up the
> actual variable in the stash that it found, calling gv_init to make sure
> there is a glob in the stash slot, and then applying whatever magic is
> appropriate to that variable before returning it. Splitting this up
> into a couple smaller functions that could be reused separately would
> make things a lot easier to work with - if I have an actual stash, I
> shouldn't have to convert it back into a name just so that I can pass it
> to this function which then goes and converts it directly back into a
> stash.
Could you come up with a proposal for the interface and file an RT ticket?
Thread Previous
|
Thread Next