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

[Gerald Klix]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/14b434e9/attachment.htm>