bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#72004: 30.0.50, master: 'erc--check-prompt-input-for-multiline-blank


From: Andrea Corallo
Subject: bug#72004: 30.0.50, master: 'erc--check-prompt-input-for-multiline-blanks' test fail
Date: Fri, 12 Jul 2024 03:30:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

"J.P." <jp@neverwas.me> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> I buy the theory of this being related to trampoline generation under
>> high system load, looking at my logs I see this test failing only with
>> native compilation an passing without.
>>
>> I'm wondering if we could work around the issue somehow 🤔
>
> I'm afraid I can offer next to nothing when it comes to serious insights
> about Emacs internals and related magic 😞
>
>>
>> Also I'm not sure the right tag is :expensive, shouldn't be :unstable?
>
> If we want to prevent the test from running completely (at least on
> EMBA), then :unstable would indeed make sense. However, if we'd like the
> test to run on the 3x daily expensive pipelines, I'm fairly confident my
> latest change sidesteps the issue. It now waits to start the subprocess,
> which was previously too short-lived, until after the macro has done its
> (potentially time-consuming) advising. Thus, the liveliness check that
> was signaling the error should now always find a running process.
> (Although, for good measure, I also lengthened the timeout from 10s to
> 5m.) All this said, I'm happy to change it to :unstable or try a safer
> approach, such as mocking `process-status'. Thanks.

Generally speaking I think we should flag tests for what they are and
then tune the EMBA testing strategy to our needs afterward.  That said
with a 5m timeout the test is now probably more expansive than unstable
so I think the classificaiton it's fine :)

Thanks closing this.

  Andrea





reply via email to

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