search

gisle / tcl.pm

Tcl extension module for Perl
http://search.cpan.org/dist/Tcl
9 stars 8 forks source link

What to do about $Tcl::STACK_TRACE removal? #34

Open chrstphrchvz opened 3 years ago

chrstphrchvz commented 3 years ago

The previous Tkx maintainer attempted to make Tcl error messages be shown as cleanly as possible by outputting only the relevant line numbers of the program using Tkx, and not any lines from Tkx or Tcl.pm. This involved hardcoding the expected error for when $Tcl::STACK_TRACE was set to 0: gisle/tkx@d63e32e.

In 2011 an announcement was made on the mailing list that $Tcl::STACK_TRACE would be removed. Unfortunately no objections were made, and it was removed: 5b55b71. So when Tcl.pm 1.03 was released in 2016, Tkx began failing one of its tests, leading to many reports that Tkx could no longer be installed (since tools like cpan/cpanm insist that tests pass before installing without -f/--force). Tcl::pTk was also disrupted by the changes in Tcl.pm 1.03, and ended up restoring functionality from 1.02: chrstphrchvz/perl-tcl-ptk@47ef11b.

So far I have only marked the failing test as TODO in Tkx 1.10, but I am not sure what else should be done about this issue.

I am not inclined to update Tkx to hardcode the error message from newer Tcl.pm; I think the error messages Tcl.pm provides are for convenience rather than something modules can rely on to not change in future versions of Tcl.pm.

I am not sure whether $Tcl::STACK_TRACE should just be reinstated, although that does seem like a simpler option.

I do not think I completely agree with the original goal in Tkx for error messages to only implicate the Tkx program's code. In addition to my own unfamiliarity with the guts of these wrapper modules, I currently do not expect them to be perfect enough to avoid falsely blaming user code when there is actually problem in these modules. I might actually prefer always getting a verbose stack trace from Carp::confess() (instead of Carp::croak()), so that both the program and wrappers/Tcl.pm are clearly shown.

It would probably also be better if Tcl::pTk avoided duplicating functionality from older Tcl.pm.

vadrer commented 3 years ago

what is your concrete suggestion on the matter?

my point is this: the smaller tcl.pm - the better initially it was ~20 lines tcl.xs and ~100 lines Tcl.pm

its a pity that (relatively) recently we've introduced lots of lines of code for support for anonymous subs callbacks which should made it work but it isn't, but we've got 300+ LOC which are imperfect (unfinished).