<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 6:22 PM, Juan Vuletich via Cuis-dev wrote: </div> <blockquote type="cite" cite="mid:64358948.3020200@cuis.st">On 4/11/2023 10:05 AM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">On 4/11/23 12:55 PM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">On 4/11/23 11:19 AM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">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 </blockquote> I had some time to think things over. #halt should not do the same as #break. 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 SystemDictionary>>#isDevelopmentEnvironmentPresent which, IHMO, uses the correct criteria and is used when handling unhandled (pun intended) exceptions: UnhandledError>>#defaultAction defaultAction "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." Smalltalk isDevelopmentEnvironmentPresent ifTrue: [ self devDefaultAction ] ifFalse: [ self standaloneAppDefaultAction ] In the case of no development environment standaloneAppDefaultAction is sent, which terminates – without further ado, directly using the primitive – the image after writing a log messages. (Side note: It should delegate the handling to an installed application) In fact it executes: Smalltalk logError: self description inContext: self signalerContext to: 'CuisDebug'. If #halt 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 #break: In a production environment, #break 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 #break accordingly. Just another 1 SFr, Gerald </blockquote> Please find another changes set, that implements #break with the aforementioned principles in mind. The second change set fixes BreakingMethodWrapper to behave in the same manner as #break. HTH, Gerald </blockquote> Hi Gerald, I agree with the idea that a halt in production is something that should never happen. I just pushed an update to turn almost all calls to #halt and #halt: in the base image into #error: WRT BreakingMethodWrapper, your fix failed to answer the correct value. I pushed a different one, that does answer the correct value, but doesn't bother to log anything. I don't think logging is needed or useful for leftover breakpoints. WRT #break, I see that the biggest feature is not to worry if you forget any of them in production code. I don't think it outweighs the added complexity, given that we already have breakpoints and #halt. Thanks, <fieldset class="mimeAttachmentHeader"></fieldset> </blockquote> Hi juan, You a right, I forgot to call the actual method, so it also missed its (side) effects, silly me. In nutshell the BDFL ruled: <ol> <li><tt>#halt</tt> is enough and it should be used for debugging.</li> <li>If there are sends of <tt>#halt</tt> in production code, we just bail out (without a parachute). </li> <li>If the aforementioned behavior is unwanted, the developer is free to catch the <tt>Halt</tt> exception and resume it.</li> </ol> I can live with that. I will move the break-related code to a breakpoint-package yet to be written. Best Regards, Gerald </body> </html>