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

[Gerald Klix]

On 4/11/23 6:22 PM, Juan Vuletich via Cuis-dev wrote:
> 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,
>
>
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:

 1. #halt is enough and it should be used for debugging.
 2. If there are sends of #halt in production code,
    we just bail out (without a parachute).
 3. If the aforementioned behavior is unwanted,
    the developer is free to catch the Halt exception
    and resume it.

I can live with that.

I will move the break-related code to a breakpoint-package
yet to be written.


Best Regards,

Gerald


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