[Cuis-dev] [IMPROV] Bring back #break

Gerald Klix cuis.01 at klix.ch
Tue Apr 11 06:05:17 PDT 2023


On 4/11/23 12:55 PM, Gerald Klix via Cuis-dev wrote:
> On 4/11/23 11:19 AM, Gerald Klix via Cuis-dev wrote:
>> On 4/10/23 3:46 PM, Juan Vuletich wrote:
>>> On 4/8/2023 7:45 PM, Gerald Klix via Cuis-dev wrote:
>>>> 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
>>>
>>> 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,
>>>
>> 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
>>
>>
> 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
>
>
>
>
>
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/6dca1b73/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5760-BringBackBreakTake2-GeraldKlix-2023Apr11-14h38m-KLG.001.cs.st
Type: application/vnd.sailingtracker.track
Size: 6102 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/6dca1b73/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5761-DontBreakInProductionEnvironments-GeraldKlix-2023Apr11-15h02m-KLG.001.cs.st
Type: application/vnd.sailingtracker.track
Size: 1026 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/6dca1b73/attachment-0003.bin>


More information about the Cuis-dev mailing list