On Thu May 21 18:30:31 2020, JKEENAN wrote:
Show quoted text> On Thu May 21 17:27:45 2020, JKEENAN wrote:
> > On Thu May 21 17:06:51 2020, JKEENAN wrote:
> > > On Thu May 21 15:01:20 2020, ANDK wrote:
> > > > In the subject line I try to express what I have observed on my
> > > > smoker
> > > > the last days.
> > > >
> > > > Plenty of fail reports can be found via the matrix at
> > > >
http://matrix.cpantesters.org/?dist=Tk-Clock+0.41
> > > >
> > > > Just to pick an example:
> > > >
http://www.cpantesters.org/cpan/report/06c36a9e-9a65-11ea-9026-
> > > > 25288bde4a20
> > > >
> > > > The typical error message produced:
> > > > XS_Tk__Callback_Call error:panic: Mismatch between what Perl
> > > > thinks
> > > > LC_CTYPE is (en_US.UTF-8) and what internal glibc thinks (C)
> > > >
> > > > CC'd to SREZIC and KHW who can probably help diagnosing what's
> > > > going
> > > > on.
> > >
> > > I can confirm the test failures when Tk-Clock is tested against
> > > perl
> > > 5
> > > blead built with threads, longdouble and -DEBUGGING=both. See
> > > attachment. Building with the same configuration except
> > > -DEBUGGING=-
> > > g
> > > PASSes.
> > >
> > > I notice that
https://metacpan.org/release/Tk-Clock suggests that
> > > the
> > > latest version of Tk-Clock, 0.41, was uploaded very recently on
> > > April
> > > 09 2020. This may explain why the failures on Andreas's machines
> > > have
> > > only begun to appear recently. However, in the git checkout there
> > > is
> > > no tag later than 'v0.39' and the most recent CommitDate is Thu Oct
> > > 31
> > > 06:07:34 2019. So I'm confused as to how to proceed.
> > >
> > > Thank you very much.
> > > Jim Keenan
> >
> > To further muddy the waters ...
> >
> > When I build Perl 5 blead with threads, longdouble but '-DEBUGGING=-
> > g'
> > and test an *earlier* version of Tk-Clock, I get a PASS.
> >
> > #####
> > $ thisperl -V:config_args
> > config_args='-des -Dusedevel -Dusethreads -Duselongdouble
> > -DEBUGGING=-
> > g
> > -Dprefix=/home/jkeenan/testing/56d9fe2f0976a30544c45bec229c1199e2e95396
> > -Uversiononly -Dman1dir=none -Dman3dir=none';
> >
> > $ gitshowf
> > commit fb41f1c902c1cf1ae5c1a2077162d4c231fe217c (HEAD, tag: v0.36)
> > Author: H.Merijn Brand - Tux <h.m.brand@xs4all.nl>
> > AuthorDate: Fri Apr 11 08:05:12 2014 +0200
> > Commit: H.Merijn Brand - Tux <h.m.brand@xs4all.nl>
> > CommitDate: Fri Apr 11 08:05:12 2014 +0200
> >
> > Deal with single-digit formats with dynamic width
> > ...
> >
> > $ thisprove -b t/10_base.t t/30_dual.t
> > t/10_base.t .. ok
> > t/30_dual.t .. ok
> > All tests successful.
> > Files=2, Tests=56, 96 wallclock secs ( 0.03 usr 0.01 sys + 0.66
> > cusr
> > 0.05 csys = 0.75 CPU)
> > Result: PASS
> > #####
> >
> > However, if I build with -DEBUGGING=both and then test Tk-Clock at
> > v0.36, I get the failures reported previously.
> >
> > So my hunch is that the recent CPAN upload of v0.41 of Tk-Clock
> > triggered CPANtesters runs which are disclosing some problem with '-
> > DEBUGGING=both' versus '-DEBUGGING=-g'.
> >
> > Thank you very much.
> > Jim Keenan
>
> Further debugging suggests:
>
> 1. '-Duselongdouble' is not responsible for the test failures.
> Deleting it from config_args does not affect the Tk-Clock tests'
> results. ('-Duselongdouble' does, however, appear to cause Tk's test
> suite to hang indefinitely at t/errordialog.t *when run via cpanm*.
> But that's for another ticket in a different queue.)
>
> 2. '-Dusethreads' is implicated in the test failures. When I build a
> perl at blead with '-DEBUGGING=both' but *without* '-Duseithreads',
> Tk-Clock tests PASS at both tag v0.36 and at HEAD.
>
> I'm leaning to the hypothesis is that this is a bug in perl 5 blead
> when built with '-DEBUGGING=both -Dusethreads'. It would be good if
> we could reduce the test failures in Tk-Clock's test suite to debug
> this further and perhaps bisect it.
>
> Thank you very much.
> Jim Keenan
The tests fail in blocks that use the ja_JP.utf8 locale. If I comment out the unit tests in t/10 and t/30 that use this locale, the tests PASS on a perl-5.28 or later built with -Dusethreads and -DEBUGGING=both. This problem can also be seen when the attached program is run by that kind of perl.
My belief now is that this is a case where Tk-Clock (or, perhaps, Tk) needs to be updated to reflect the changes in perl made in this commit:
#####
commit 58e641fba50d93bcd84c0dc042b36d201958293d
Author: Karl Williamson <khw@cpan.org>
AuthorDate: Thu Feb 15 22:44:24 2018 -0700
Commit: Karl Williamson <khw@cpan.org>
CommitDate: Sun Feb 18 15:44:23 2018 -0700
Add switch_to_globale_locale()
This new API function is for use in applications that call alien library
routines that are expecting the old pre-POSIX 2008 locale functionality,
namely a single global locale accessible via setlocale().
This function converts the calling thread to use that global locale, if
not already there.
#####
Thank you very much.
Jim Keenan
use strict;
use warnings;
use Tk;
use Tk::Clock;
END { print "Finished!\n"; }
my $rv;
my ($delay, $period, $m, $c) = (0, 300);
unless ($m = eval { MainWindow->new (-title => "clock") }) {
exit 0;
}
$c = $m->Clock (-background => "Black");
print "Clock Widget ", (defined $c ? "defined" : "not defined"), "\n";
print "Delay is 0 ", ($delay == 0 ? "ok" : "not ok"), "\n";
print "Period is $period ", (($period =~ qr/^\d+$/) ? "ok" : "not ok"), "\n";
$delay += $period;
print "First after $delay ", (($delay =~ qr/^\d+$/) ? "ok" : "not ok"), "\n";
$delay += $period;
$c->after ($delay, sub {
$c->configure (-background => "Purple4");
$rv = $c->config ({
useAnalog => 0,
useInfo => 0,
useDigital => 1,
useLocale => ($^O eq "MSWin32" ? "Japanese_Japan.932" : "ja_JP.utf8"),
timeFont => "Helvetica 8",
dateFont => "Helvetica 8",
dateFormat => "dddd\nd mmm yyy",
timeFormat => "",
});
print "Purple4 aD dddd\\nd mmm yyy '' ", ($rv ? "ok" : "not ok"), "\n";
});
$delay += $period;
$c->after ($delay, sub {
print "XXX: Entering destructors\n";
$c->destroy;
print "Destroy Clock ", (!Exists ($c) ? "ok" : "not ok"), "\n";
local $@;
eval {$m->destroy; };
$@ and warn "Destroy Main FAIL: $@";
});
MainLoop;
