<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 12pt;">Hi Fabio, hi all,</span><br>
</p>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p><br>
</p>
<p>very good question (and after having waited about twenty minutes for two test executions and comparing them manually, I once again wish we had CI for every inbox commits ...)!</p>
<p><br>
</p>
<p>And actually, I broke the DecompilerTests, e.g. #<span>testBlockNumbering, because somewhere during compilation, an <span>UndeclaredVariableWarning is raised. All other tests, however, did not change their result after loading this inbox commit.</span></span></p>
<p><span><span><br>
</span></span></p>
<p><span><span>This behavior leads me to the question of whether it is justified to derive <span>UndeclaredVariableWarning from Warning, given its #defaultAction implementation making it behave like a Notification.</span></span></span></p>
<p><span><span><span>Alternatively, what could we do else if it is not acceptable to interrupt a test once it raises a warning? As I proposed somewhere else, we could catch UnhandledError instead of all these classes eventually open a debugger, but Marcel told
me that this would be an implementation detail of the EHS and should not be exposed. Still, I cannot imagine any other way to write an exception handler that detects whether an exception will "raise a problem" eventually or whether it won't. Hmm ...<span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px"> What
do you think? :-)</span></span></span></span></p>
<p><span><span><span><br>
</span></span></span></p>
<p><span><span><span>Best,</span></span></span></p>
<p><span><span><span>Christoph</span></span></span></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Fabio Niephaus <lists@fniephaus.com><br>
<b>Gesendet:</b> Donnerstag, 24. September 2020 10:50:44<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: SUnit-ct.129.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText">Hi Christoph,<br>
<br>
If you run all tests in your image without and with your change, does<br>
the number of test failures change?<br>
<br>
Fabio<br>
<br>
On Thu, Sep 24, 2020 at 10:42 AM <commits@source.squeak.org> wrote:<br>
><br>
> Christoph Thiede uploaded a new version of SUnit to project The Inbox:<br>
> <a href="http://source.squeak.org/inbox/SUnit-ct.129.mcz">http://source.squeak.org/inbox/SUnit-ct.129.mcz</a><br>
><br>
> ==================== Summary ====================<br>
><br>
> Name: SUnit-ct.129<br>
> Author: ct<br>
> Time: 24 September 2020, 10:42:52.868426 am<br>
> UUID: 92e68d23-8472-5d48-96d3-8435bd56ac14<br>
> Ancestors: SUnit-pre.122<br>
><br>
> Proposal: Catch warnings and halts in test case execution as well as Errors.<br>
><br>
> Catching (Error, Warning, Halt) is a common pattern to be (relatively) sure that no debugger will occur during an operation. For related usages, see Morph >> #fullBounds, WorldState >> #displayWorldSafely:, and many other places. IMO it is no desired behavior
that the whole test execution, i.e. in a TestRunner, is interrupted because any method under test contains a halt or raises a DeprecationWarning, for example. Instead, the test should be listed as red.<br>
><br>
> For a similar discussion, see <a href="https://github.com/hpi-swa/smalltalkCI/issues/470">
https://github.com/hpi-swa/smalltalkCI/issues/470</a>. I believe we already had talked about this on squeak-dev, but if I remember correctly, I cannot find the thread again.<br>
><br>
> =============== Diff against SUnit-pre.122 ===============<br>
><br>
> Item was changed:<br>
> ----- Method: TestCase>>timeout:after: (in category 'private') -----<br>
> timeout: aBlock after: seconds<br>
> "Evaluate the argument block. Time out if the evaluation is not<br>
> complete after the given number of seconds. Handle the situation<br>
> that a timeout may occur after a failure (during debug)"<br>
><br>
> | theProcess delay watchdog |<br>
><br>
> "the block will be executed in the current process"<br>
> theProcess := Processor activeProcess.<br>
> delay := Delay forSeconds: seconds.<br>
><br>
> "make a watchdog process"<br>
> watchdog := [<br>
> delay wait. "wait for timeout or completion"<br>
> theProcess ifNotNil:[ theProcess signalException:<br>
> (TestFailure new messageText: 'Test timed out') ]<br>
> ] newProcess.<br>
><br>
> "Watchdog needs to run at high priority to do its job (but not at timing priority)"<br>
> watchdog priority: Processor timingPriority-1.<br>
><br>
> "catch the timeout signal"<br>
> watchdog resume. "start up the watchdog"<br>
> + ^[aBlock on: TestFailure, (Error, Warning, Halt) do: [:ex|<br>
> - ^[aBlock on: TestFailure, Error, Halt do:[:ex|<br>
> theProcess := nil.<br>
> ex pass.<br>
> ]] ensure:[ "evaluate the receiver"<br>
> theProcess := nil. "it has completed, so ..."<br>
> delay delaySemaphore signal. "arrange for the watchdog to exit"<br>
> ]!<br>
><br>
> Item was added:<br>
> + ----- Method: TestResult class>>exAllErrors (in category 'exceptions') -----<br>
> + exAllErrors<br>
> + ^ self exError, Warning, Halt<br>
> + !<br>
><br>
> Item was changed:<br>
> ----- Method: TestResult>>runCase: (in category 'running') -----<br>
> runCase: aTestCase<br>
><br>
> | testCasePassed timeToRun |<br>
> testCasePassed := true.<br>
><br>
> [timeToRun := [aTestCase runCase] timeToRunWithoutGC]<br>
> on: self class failure<br>
> do: [:signal |<br>
> failures add: aTestCase.<br>
> testCasePassed := false.<br>
> signal return: false]<br>
> + on: self class exAllErrors<br>
> - on: self class error<br>
> do: [:signal |<br>
> errors add: aTestCase.<br>
> testCasePassed := false.<br>
> signal return: false].<br>
><br>
> testCasePassed ifTrue: [passed add: aTestCase].<br>
> self durations at: aTestCase put: timeToRun.!<br>
><br>
><br>
<br>
</div>
</span></font></div>
</body>
</html>