<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 4/11/23 11:19 AM, Gerald Klix via Cuis-dev wrote: </div> <blockquote type="cite" cite="mid:18b6f9a9-ce5d-d1b6-7ae9-21b05ef759ce@klix.ch">On 4/10/23 3:46 PM, Juan Vuletich wrote: <blockquote type="cite">On 4/8/2023 7:45 PM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">Hi all, Hi Juan, Is there a chance, that you may accept this little change set? It brings back `self break`, to which I got used over time, using Squeak, Pharo and Cuis. Needless to say, that added some improvements. HTH and Best Regards, Gerald </blockquote> Nice. But this serves the same purpose as #halt, right? Does it make sense to have both? Does your implementation have any other advantage besides saving a couple of clicks in the debugger? Is forking a new process needed? Thanks, </blockquote> Well, it has one, probably tiny, advantage: The stack frame with the #break-send is not displayed. I considered it a bit annoying, that I have to step over this stack-frame – that's what I believed. However during the course of the implementation of #break, I found that there is code that enables the debugger to 'single-step' and 'step over' in all frames, not only in the top-frame. (I used the debugger to single-step the debugger) I hope this cool feature is documented somewhere and I fear that I overlooked it in a every other Smalltalk I used so far. There is also another feature, that may be an advantage or a big nightmare: The implementation isn't based on exceptions, you can not 'subvert' it with an exception handler. Concerning #halt, its category talks about errors, not about debugging. We should have a common understanding of the pragmatics of halt vs. break. (Operational) semantics are clear, as you pointed out: Both leave you in the debugger. There are several sends of #halt in the pristine Cuis image. IHMO most signal some unspecified error condition. See Morph>>#copyForClipboard for a counter-example :-} Just my 1€, Gerald <fieldset class="mimeAttachmentHeader"></fieldset> </blockquote> I had some time to think things over. <tt>#halt</tt> should not do the same as <tt>#break</tt>. There is a case I forgot to consider in my break implementation: What should we do, if we run in a 'production'-environment (vs. 'development'-environment). There is <tt>SystemDictionary>>#isDevelopmentEnvironmentPresent</tt><tt> </tt>which, IHMO, uses the correct criteria and is used when handling unhandled (pun intended) exceptions: <tt>UnhandledError>>#defaultAction</tt><tt> </tt><tt> </tt><tt>defaultAction</tt><tt> </tt><tt> "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated."</tt><tt> </tt><tt> </tt><tt> Smalltalk isDevelopmentEnvironmentPresent</tt><tt> </tt><tt> ifTrue: [ self devDefaultAction ]</tt><tt> </tt><tt> ifFalse: [ self standaloneAppDefaultAction ]</tt><tt> </tt><tt> </tt>In the case of no development environment <tt>standaloneAppDefaultAction </tt>is sent<tt>, </tt>which terminates – without further ado, directly using the primitive – the image after writing a log messages<tt>. </tt>(Side note: It should delegate the handling to an installed application<tt>)</tt><tt> </tt>In fact it executes:<tt> Smalltalk logError: self description inContext: self signalerContext to: 'CuisDebug'. </tt>If <tt>#halt</tt> was meant for debugging purposes, it should not log an error and should not quit the image in a production environment. (Squeak does more or less the same, with much more fuss) Conclusion: The original intention (pragmatics) was to signal a (probably fatal) error. Concerning <tt>#break</tt>: In a production environment, <tt>#break</tt> must have no effect. It is desirable that writes some log message, complaining about leftover debug code, but things should work as if there was no debug code present. I hope the community can agree on this distinction and that we can change the implementation of <tt>#break</tt> accordingly. Just another 1 SFr, Gerald <tt> </tt><tt></tt> </body> </html>