Front page | perl.perl5.porters |
Postings from January 2022
Re: Broken stack traces from use statements.
Thread Previous
|
Thread Next
From:
demerphq
Date:
January 15, 2022 07:22
Subject:
Re: Broken stack traces from use statements.
Message ID:
CANgJU+XhmAzRbSqyNO0a14j6K7O5LCXkqzXLvSpgh45iY-6G8g@mail.gmail.com
On Sat, 15 Jan 2022 at 07:06, demerphq <demerphq@gmail.com> wrote:
> On Sat, 15 Jan 2022 at 05:18, Leon Timmermans <fawaka@gmail.com> wrote:
>
>> On Fri, Jan 14, 2022 at 5:44 PM Leon Timmermans <fawaka@gmail.com> wrote:
>>
>>> On Fri, Jan 14, 2022 at 4:59 PM Ovid <curtis_ovid_poe@yahoo.com> wrote:
>>>
>>>> On Friday, 14 January 2022, 15:54:27 CET, Leon Timmermans <
>>>> fawaka@gmail.com> wrote:
>>>>
>>>> > > But those assumptions are basically broken, so I'm not sure your
>>>> point. Classic case of GIGO.
>>>> >
>>>> > It's not broken if it gets the job done, is it?
>>>>
>>>> > I agree with you that the new behavior is far more usable than the
>>>> older behavior, but that doesn't
>>>> > mean people haven't put the old behavior to use.
>>>>
>>>> I think the old behavior kind of worked because generally, stack traces
>>>> work. It appears to be the use/require case which is problematic.
>>>>
>>>> However, in the use/require case, if the apparently pseudo-random
>>>> ordering is deterministic, on my machine the first stack frame grabbed
>>>> happens to be correct. If that holds (pretty sure it must), then for the
>>>> 'import' case where you're trying to figure out where you're exporting to,
>>>> you're going to export those functions to the right spot. It's when you hit
>>>> stack traces that it becomes an unusable mess.
>>>>
>>>> As it stands:
>>>>
>>>> * The stack trace is clearly incorrect
>>>> * That makes it useless for debugging
>>>> * When you're working on a *huge* system and get those traces, it's
>>>> miserable
>>>>
>>>> Given that, I suspect the most useful discussions are about *how* to
>>>> fix it and/or *when* to fix it.
>>>>
>>>
>>> "How to fix it" probably includes people stepping up to deal with the
>>> fallout. IME the most useful thing proponents of this change could do is
>>> actually write patches for the 3 known affected modules. I don't really
>>> understand how that hasn't happened yet in the past two years.
>>>
>>
>> I think I just did that for DBIx::Class.
>>
>>
> Thanks, although I feel it is worth noting that this was not a fix to
> DBIx::Class and the patch never broke DBIx::Class, it was the tests for
> DBIx::Class that were broken only.
>
> I have looked at the other two cases and as far as I can tell Dave M did
actually dig into them and fix them. They are in the thread here:
https://github.com/Perl/perl5/issues/17663
BTW, in that thread you said: "This ticket raises the question «what is
correctness». The current behavior is truthful, but not intuitive. This
discussion really seems to be about which of those two values are more
relevant for correctness."
Consider the following:
~/tlib$ cat {A..D}.pm
package A;
BEGIN { Carp::cluck "\n--\nIn ", __PACKAGE__; }
use B;
1;
__END__
package B;
BEGIN { Carp::cluck "\n--\nIn ", __PACKAGE__; }
use C;
1;
__END__
package C;
BEGIN { Carp::cluck "\n--\nIn ", __PACKAGE__; }
use D;
1;
__END__
package D;
BEGIN { Carp::cluck "\n--\nIn ", __PACKAGE__; }
1;
__END__
~/tlib$ perl -I. -MCarp -e'use A;'
--
In A at A.pm line 2.
A::BEGIN() called at A.pm line 2
eval {...} called at A.pm line 2
require A.pm called at -e line 1
main::BEGIN() called at A.pm line 2
eval {...} called at A.pm line 2
--
In B at B.pm line 2.
B::BEGIN() called at B.pm line 2
eval {...} called at B.pm line 2
require B.pm called at A.pm line 3
A::BEGIN() called at B.pm line 2
eval {...} called at B.pm line 2
require A.pm called at -e line 1
main::BEGIN() called at B.pm line 2
eval {...} called at B.pm line 2
--
In C at C.pm line 2.
C::BEGIN() called at C.pm line 2
eval {...} called at C.pm line 2
require C.pm called at B.pm line 3
B::BEGIN() called at C.pm line 2
eval {...} called at C.pm line 2
require B.pm called at A.pm line 3
A::BEGIN() called at C.pm line 2
eval {...} called at C.pm line 2
require A.pm called at -e line 1
main::BEGIN() called at C.pm line 2
eval {...} called at C.pm line 2
--
In D at D.pm line 2.
D::BEGIN() called at D.pm line 2
eval {...} called at D.pm line 2
require D.pm called at C.pm line 3
C::BEGIN() called at D.pm line 2
eval {...} called at D.pm line 2
require C.pm called at B.pm line 3
B::BEGIN() called at D.pm line 2
eval {...} called at D.pm line 2
require B.pm called at A.pm line 3
A::BEGIN() called at D.pm line 2
eval {...} called at D.pm line 2
require A.pm called at -e line 1
main::BEGIN() called at D.pm line 2
eval {...} called at D.pm line 2
So respectfully I would like to know how you can consider such
contradictory results (eg the same stack frame being attributed to
different lines of code depending on when caller was called) can be
truthful, especially given some of the stack frames are BEGIN's which fire
once and are never fired again, it seems to me that we should be able to
agree that such a construct should be shown to come from exactly one place,
and one place alone.
Cheers,
Yves
Thread Previous
|
Thread Next