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

Gerald Klix cuis.01 at klix.ch
Tue Apr 11 02:19:46 PDT 2023


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/02689b55/attachment.htm>


More information about the Cuis-dev mailing list