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

[Juan Vuletich]

On 4/11/2023 10:05 AM, Gerald Klix via Cuis-dev wrote:
> 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

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,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

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