YES! That works for me.
There is still one wafer-thin problem...
When I use this in an array context, I am getting the function name (and possibly other further parameters) one level above what the package, file, and line number are. I can code around this, but I also wonder if this is a bug or not. Here is a run using Perl 5.18.1:
./bin/trepan.pl example/gcd.pl 3 5
-- main::(example/gcd.pl:18)
die sprintf "Need two integer arguments, got %d", scalar(@ARGV) unless
@ARGV == 2;
$DB::D[0] = 0
(trepanpl): @ caller
$DB::D1 =
@{[
[0] "main",
1 "example/gcd.pl",
2 18,
3 "DB::DB", <---- WRONG!
4 "",
5 1,
6 undef,
7 undef,
8 2018,
9 "UUUUUUUUUUUUUUUU",
10 undef
]}
(trepanpl): @ caller 1
$DB::D2 =
@{<undef>}
(trepanpl): c gcd
-> main::(example/gcd.pl:8)
{
my ($a, $b) = @_;
trepanpl: s # there is a "feature" here in my program where I need to step one more
x1 main::(example/gcd.pl:9)
my ($a, $b) = @_;
(trepanpl): @ caller
$DB::D2 =
@{[
[0] "main",
1 "example/gcd.pl",
2 9,
3 "DB::DB", <--- still wrong
4 "",
5 1,
6 undef,
7 undef,
8 1762,
9 "UUUUUUUUUUUUUUUU",
10 undef
]}
(trepanpl): @ caller 1
$DB::D3 =
@{[
[0] "main",
1 "example/gcd.pl",
2 21,
3 "main::gcd",
4 1,
5 1,
6 undef,
7 undef,
8 2018,
9 "UUUUUUUUUUUUUUUU",
10 undef
]}
(trepanpl): @ caller 2
$DB::D4 =
@{<undef>}
(trepanpl): q
Really quit? (N/y) y
trepan.pl: That's all, folks...
If you want to try the code yourself, see the
github Devel::Trepan repo with a commit after 0babe47e08831a9d5b1099a9971fc2677f604331 | [reply]
[d/l] |
The last comment was a little long, so I wanted to add some other things here...
- Why does this work?
- What's the difference between CORE::GLOBAL::Caller and CORE::Caller.
- Elaboration why one thought BEGIN was needed, and why in fact it isn't and why are things so slow when it is used?
This is just icing on the cake. Just wondering what's going on.
Thanks again, everbody!
| [reply]
[d/l] |
"Why does this work?"
See CORE.
"What's the difference between CORE::GLOBAL::Caller and CORE::Caller."
The difference between CORE::GLOBAL::foo and CORE::foo is thus: The Perl built-in foo() function is "just an alias" for CORE::GLOBAL::foo(). The default implementation of CORE::GLOBAL::foo() is CORE::foo(). You can override CORE::GLOBAL::foo() (and thus the built-in foo() because that's "just an alias"), but you cannot override CORE::foo().
That's the concept anyway. The actual implementation details are far weirder. CORE:: for example is not just a package, but a part of Perl's syntax - a prefix you can add to a Perl keyword to indicate that you do not want to use an overridden CORE::GLOBAL::foo(). You cannot take references to all of the CORE:: and CORE::GLOBAL:: functions, only some of them (though each major release of Perl is improving in this regard).
"Elaboration why one thought BEGIN was needed, and why in fact it isn't"
It is necessary to have performed at least one override of CORE::GLOBAL::caller() before the line containing caller is compiled. If you're using stringy eval, then your line containing caller is probably compiled quite late.
But going back to my example:
use v5.12;
# This is basically a dummy override that must be performed early
# on so that Perl knows we'll be overriding CORE::GLOBAL::caller
# later...
#
BEGIN { *CORE::GLOBAL::caller = sub { CORE::caller(@_) } };
sub foo {
say scalar caller;
}
sub bar {
local *CORE::GLOBAL::caller = sub { 'xxxx' };
foo();
}
foo();
bar();
This outputs "main" then "xxxx". Commenting out the BEGIN block, it outputs "main" then "main" - not the desired effect. (Tested on Perl 5.12.5, 5.14.3, and 5.18.0.)
"why are things so slow when it is used?"
Because after the first time an override happens, any subsequent uses of caller() get compiled into an entersub op rather than a caller op. That is, they incur the full penalty of a sub call.
Compare:
$ perl -MO=Concise -E'BEGIN { *DUMMY::GLOBAL::caller = sub {} }; calle
+r()'
4 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 49 -e:1) v:%,{,2048 ->3
3 <0> caller[t1] v* ->4
-e syntax OK
$ perl -MO=Concise -E'BEGIN { *CORE::GLOBAL::caller = sub {} }; caller
+()'
6 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 49 -e:1) v:%,{,2048 ->3
5 <1> entersub[t3] vKS/TARG,1 ->6
- <1> ex-list K ->5
3 <0> pushmark s ->4
- <1> ex-rv2cv sK ->-
4 <#> gv[*CORE::GLOBAL::caller] s ->5
-e syntax OK
use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
| [reply]
[d/l]
[select] |
CORE::caller is always the built in caller function and can't be changed. CORE::GLOBAL::caller can be changed, and if it exists will be used by a caller() call instead of CORE::caller. Note that the function to use is chosen at compile time.
This is why the BEGIN block is needed in other cases of overriding caller. Perl picks which of the functions to use for a given caller() call when compiling the code. Once it has chosen to use CORE::GLOBAL::caller, the implementation for that function can be switched out and it will use whatever is currently stored in it. In your case, caller() calls directly in evaled code will always be compiled after you set up your override. Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.
Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.
Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.
| [reply] |
| [reply] |
It's not a bug, it's a feature. See this.
Many thanks to Dave Mitchell for going through the weeds on this.
| [reply] |
