Fix for failed test at CPAN

[anne-gert]

Hello maintainers,

I've been using the Tkx module for years and I'm very happy with it. Unfortunately, there is a long-standing test issue on CPAN ( see http://www.cpantesters.org/cpan/report/640f2c8c-1c8e-11eb-9ee7-b9ac198ac9a8 ).

The error reads:

# Test 18 got: "Tcl error 'Foo at /home/sand/src/perl/repoperls/installed-perls/host/k93bionic/v5.33.3/ebf1/lib/site_perl/5.33.3/x86_64-linux-thread-multi-ld/Tcl.pm line 817.\n' while invoking scalar result call:\n\t\"error Foo\" at t/tcl.t line 38.\n" (t/tcl.t at line 39)
#    Expected: "Foo at t/tcl.t line 38.\n"
#  t/tcl.t line 39 is: ok($@, "Foo at @{[__FILE__]} line @{[__LINE__ - 1]}.\n");
t/tcl.t ........... 

I believe the problem is a platform dependency in the regex in Tkx.pm at line 334.

Change the end of that regex from \n\z to \s*\z

• Is this sufficient information to request an update?
• Is this module still being maintained?

Best Regards,

Anne-Gert

[anne-gert]

I created PR #8 for this.

[chrstphrchvz]

Hello @anne-gert, I have been added as a maintainer of Tkx. I will likely be maintaining it from my fork instead of this repository.

I would like to publish a maintenance release that fixes this often-encountered issue, but am still trying to understand what is causing it and how to address it. The approach proposed in #8 illustrates how the issue is deeper than the affected t/tcl.t test case. I think it may have been caused by Tcl.pm removing features which Tkx still expects, e.g. $Tcl::STACK_TRACE: gisle/tcl.pm@5b55b71; and which other Tcl.pm dependents like Tcl::pTk had to workaround: chrstphrchvz/perl-tcl-ptk@47ef11b.

It could be that all Tkx was trying to do here was provide nicer/cleaner error messages to Tkx programs, so maybe there is some flexibility in improving both the error message code and the affected test case.

[chrstphrchvz]

For now, I have marked the affected test as TODO in Tkx 1.10.

[anne-gert]

Hello Christopher, I'm not sure if I can reply like this. I have not deeply investigated this issue, but I came to a similar solution that it was a dependency on how Tcl used to work. I added a second commit on 10 Nov. I did some trial and error and I think I got it to work. I'm rather new to git, so can you use my commits on gisle's version? I think it should also be possible to add you as a remote and submit the same pr to your fork. Please let me know if I can help. Best regards, Anne-Gert

…

On February 6, 2021 8:21:18 AM GMT+01:00, Christopher Chavez ***@***.***> wrote: Hello @anne-gert, I have been added as a maintainer of Tkx. I will likely be maintaining it from my [fork](https://github.com/chrstphrchvz/tkx) instead of this repository. I would like to publish a maintenance release that fixes this often-encountered issue, but am still trying to understand what is causing it and how to address it. The approach proposed in #8 illustrates how the issue is deeper than the affected t/tcl.t test case. I think it may have been caused by Tcl.pm removing features which Tkx still expects, e.g. `$Tcl::STACK_TRACE`: ***@***.***; and which other Tcl.pm dependents like Tcl::pTk had to workaround: ***@***.*** It could be that all Tkx was trying to do here was provide nicer/cleaner error messages to Tkx programs, so maybe there is some flexibility in improving both the error message code and the affected test case. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7 (comment)