Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the circular-require CPAN distribution.

Report information
The Basics
Id: 72983
Status: rejected
Priority: 0/
Queue: circular-require
People
Owner: Nobody in particular
Requestors: mschwern [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: 0.03
Fixed in: (no value)

History Show all quoted text
  Mon Dec 05 16:01:41 2011 mschwern [...] cpan.org - Ticket created
Subject: Use a code ref in @INC instead of CORE::GLOBAL::require?
Hi, We're looking at using this as part of perl5i. See https://github.com/schwern/perl5i/issues/217 I have a concern that the warning is not lexical, leading to the UNIVERSAL::isa problem. That can be fixed pretty easily, but CORE::GLOBAL::require needs to be in effect at all times to track module loads. An alternative implementation is to put a code ref at the front of @INC which tracks every time it's called. This leaves CORE::GLOBAL::require clear. Now the problem is what if something gets put in front of our tracker in @INC? Turns out every code ref in @INC will get called, even if an earlier entry resolves the module. What if @INC gets cleared? Make the tracker an object whose DESTROY method puts a new object back. :-) What do you think?
  Mon Dec 05 16:53:29 2011 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added
On Mon Dec 05 16:01:41 2011, MSCHWERN wrote: Show quoted text
> Hi, > We're looking at using this as part of perl5i. See > https://github.com/schwern/perl5i/issues/217 > > I have a concern that the warning is not lexical, leading to the > UNIVERSAL::isa problem. That can be fixed pretty easily, but > CORE::GLOBAL::require needs to be in effect at all times to track module > loads. > > An alternative implementation is to put a code ref at the front of @INC > which tracks every time it's called. This leaves CORE::GLOBAL::require > clear. Now the problem is what if something gets put in front of our > tracker in @INC? Turns out every code ref in @INC will get called, even > if an earlier entry resolves the module. > > What if @INC gets cleared? Make the tracker an object whose DESTROY > method puts a new object back. :-) > > What do you think?
That won’t be as reliable as you think: $ perl -le' @INC = bless eval "sub {}"; DESTROY { push @INC, bless eval "sub {}" } shift @INC; print @INC' main=CODE(0x803b30) $ perl -le' @INC = bless eval "sub {}"; DESTROY { push @INC, bless eval "sub {}" } @INC=(); print @INC' I get the same results with 5.10.1 and 5.15.5. If you make it an XS module that uses PL_check[OP_REQUIRE] to set the o->op_ppaddr to a custom function, that will be more reliable. But you’ll need a pointer table to keep the old ppaddr. See autovivification.xs (on CPAN) and arybase.xs (in blead) for examples.
  Mon Dec 05 16:53:30 2011 The RT System itself - Status changed from 'new' to 'open'
  Mon Dec 05 17:02:33 2011 mschwern [...] cpan.org - Correspondence added
On Mon Dec 05 16:53:29 2011, SPROUT wrote: Show quoted text
> That won’t be as reliable as you think: > > $ perl -le' @INC = bless eval "sub {}"; DESTROY { push @INC, bless > eval "sub {}" } shift @INC; > print @INC' > main=CODE(0x803b30) > $ perl -le' @INC = bless eval "sub {}"; DESTROY { push @INC, bless > eval "sub {}" } @INC=(); > print @INC' > > I get the same results with 5.10.1 and 5.15.5.
You're right. It also has a distressing tendency to segfault. I also realized that while it can see when modules are loaded, it doesn't see when it's finished loading. I don't think this technique will work.
  Sun Feb 12 06:00:50 2012 DOY [...] cpan.org - Correspondence added
I'll close this then.
  Sun Feb 12 06:00:51 2012 DOY [...] cpan.org - Status changed from 'open' to 'rejected'