lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Can't get GUI test to run for pc-linux-gnu


From: Vadim Zeitlin
Subject: Re: [lmi] Can't get GUI test to run for pc-linux-gnu
Date: Sat, 10 Apr 2021 22:14:18 +0200

On Wed, 24 Mar 2021 00:45:07 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 3/23/21 10:00 PM, Vadim Zeitlin wrote:
GC> > On Thu, 18 Mar 2021 23:55:12 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > GC> I feel certain that lmi's GUI tests passed for pc-linux-gnu at
GC> > GC> some time in the not-too-distant past,
GC> > 
GC> >  Yes, I'm almost certain they did. We wanted to enable them in the CI
GC> > build, but there were some sporadic failures there that we've never quite
GC> > tracked down, so we didn't do it...
GC> > 
GC> > GC> but now they fail for me:
GC> > 
GC> >  And me too. And this is not specific to the "about_dialog_version" test
GC> > case, other tests fail as well.

 I just wanted to give another update, as there is some progress: I've
found and fixed several problems, at least one of which really had to be
fixed in wxWidgets itself and several tests do run now. Unfortunately, I
still haven't fixed all of them and some tests still don't pass with wxGTK.

 So I still need to spend more time on this, but in any case to actually
make this work we would need to update wxWidgets version used by lmi and so
I'd like to ask when would be the least inconvenient moment to do this for
you? The answer to this question is quite important for me because, on one
hand, it's not really useful to prioritize this work if wx upgrade in lmi
is not going to happen any time soon, but OTOH it would be very important
to finish it a.s.a.p. if you do plan to do this upgrade in the near future,
so could you please let me know if you have any plans about this?



 The rest of this message is a digression on a somewhat unrelated subject,
so please feel free to skip it entirely. The only important information,
and the related question, is above.

GC> > GC> I think that's just saying that an exception wasn't caught,
GC> > GC> and the output continues:
GC> > 
GC> > [FWIW, IMHO this is one of those circumstances when it would have been
GC> >  useful to do "LMI_NO_EXCEPTION_DUMP=1 ./wx_test" to suppress all the
GC> >  extra expression backtraces output]
GC> 
GC> Recent experience led me to a different viewpoint.

 FWIW all my experience since then has confirmed my opinion about this.
E.g. running the full GUI test suite resulted in thousands of lines of
output, effectively making all of it completely useless. I won't try to
continue convincing you to disable it by default, because it seems clear
that this is not going to happen, but I'm definitely going to maintain my
own local modifications disabling it because all this extra output just
makes debugging completely impossible for me otherwise.

GC> I ran one of those tests in isolation (perhaps it was
GC> "about_dialog_version"), after first manually blocking the stack trace,
GC> and it gave me only:
GC> 
GC> NOTE: starting the test suite
GC> about_dialog_version: started
GC> Abnormal-termination handler called. Please report this problem.

 This is an unrelated inside an unrelated digression, but I believe that
this will be fixed by another change that I'd like to propose, but it also
depends on a newer wx version and so will also have to wait.

GC> Then I reverted the suppression of the stack trace, and got more
GC> information. It wasn't information that I was actually able to
GC> use to diagnose the problem in the time available; but it was
GC> more information.

 IMNSHO information which doesn't allow to diagnose the problem and
prevents me from seeing the really useful information that would allow to
diagnose it, is worse than useless, so I just can't understand why would
you consider it to be a good thing to have it.

 But, again, this is not the really important part, I can disable this in
the GUI tests easily enough with just something like

 // Application to drive the tests
-class SkeletonTest final : public Skeleton
+class SkeletonTest final : public Skeleton, public scoped_unwind_toggler

and I'll simply have to maintain this patch in my own branch if you
disagree with it.


 The only important question is about the wx upgrade schedule above,
thanks in advance once again for answering it!
VZ

Attachment: pgpl2x78luuwJ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]