<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/11/23 12:55 PM, Gerald Klix via
Cuis-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fe49445c-603d-7368-598e-eb78d66714a1@klix.ch">On 4/11/23
11:19 AM, Gerald Klix via Cuis-dev wrote:
<br>
<blockquote type="cite">On 4/10/23 3:46 PM, Juan Vuletich wrote:
<br>
<blockquote type="cite">On 4/8/2023 7:45 PM, Gerald Klix via
Cuis-dev wrote:
<br>
<blockquote type="cite">Hi all, Hi Juan,
<br>
<br>
Is there a chance, that you may accept this little change
set?
<br>
It brings back `self break`, to which I got used over time,
<br>
using Squeak, Pharo and Cuis.
<br>
<br>
Needless to say, that added some improvements.
<br>
<br>
<br>
HTH and Best Regards,
<br>
<br>
Gerald
<br>
</blockquote>
<br>
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?
<br>
<br>
Thanks,
<br>
<br>
</blockquote>
Well,
<br>
it has one, probably tiny, advantage:
<br>
The stack frame with the #break-send is not displayed.
<br>
I considered it a bit annoying, that I have to step over this
<br>
stack-frame – that's what I believed.
<br>
<br>
However during the course of the implementation
<br>
of #break, I found that there is code that enables the
<br>
debugger to 'single-step' and 'step over'
<br>
in all frames, not only in the top-frame.
<br>
(I used the debugger to single-step the debugger)
<br>
I hope this cool feature is documented somewhere
<br>
and I fear that I overlooked it in a every other
<br>
Smalltalk I used so far.
<br>
<br>
<br>
There is also another feature, that may be an advantage
<br>
or a big nightmare: The implementation isn't based
<br>
on exceptions, you can not 'subvert' it with an
<br>
exception handler.
<br>
<br>
<br>
Concerning #halt, its category talks about errors,
<br>
not about debugging. We should have a common
<br>
understanding of the pragmatics of halt vs. break.
<br>
(Operational) semantics are clear, as you pointed
<br>
out: Both leave you in the debugger.
<br>
<br>
There are several sends of #halt in the pristine
<br>
Cuis image. IHMO most signal some unspecified
<br>
error condition. See Morph>>#copyForClipboard
<br>
for a counter-example :-}
<br>
<br>
<br>
Just my 1€,
<br>
<br>
Gerald
<br>
<br>
<br>
</blockquote>
I had some time to think things over.
<br>
#halt should not do the same as #break.
<br>
<br>
There is a case I forgot to consider in my
<br>
break implementation: What should we do,
<br>
if we run in a 'production'-environment (vs.
<br>
'development'-environment).
<br>
<br>
There is SystemDictionary>>#isDevelopmentEnvironmentPresent
<br>
which, IHMO, uses the correct criteria and is
<br>
used when handling unhandled (pun intended)
<br>
exceptions:
<br>
<br>
UnhandledError>>#defaultAction
<br>
<br>
defaultAction
<br>
"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."
<br>
<br>
Smalltalk isDevelopmentEnvironmentPresent
<br>
ifTrue: [ self devDefaultAction ]
<br>
ifFalse: [ self standaloneAppDefaultAction ]
<br>
<br>
In the case of no development environment
standaloneAppDefaultAction
<br>
is sent, which terminates – without further ado,
<br>
directly using the primitive –
<br>
the image after writing a log messages.
<br>
(Side note: It should delegate the handling to an installed
application)
<br>
In fact it executes:
<br>
Smalltalk logError: self description inContext: self
signalerContext to: 'CuisDebug'.
<br>
If #halt was meant for debugging purposes, it should
<br>
not log an error and should not quit the image
<br>
in a production environment.
<br>
(Squeak does more or less the same, with much more fuss)
<br>
<br>
Conclusion: The original intention (pragmatics) was to signal a
<br>
(probably fatal) error.
<br>
<br>
<br>
Concerning #break:
<br>
<br>
In a production environment, #break must have no effect.
<br>
It is desirable that writes some log message, complaining
<br>
about leftover debug code, but things should work as
<br>
if there was no debug code present.
<br>
<br>
I hope the community can agree on this distinction
<br>
and that we can change the implementation of #break
<br>
accordingly.
<br>
<br>
<br>
Just another 1 SFr,
<br>
<br>
Gerald
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
Please find another changes set, that implements <tt>#break</tt><br>
with the aforementioned principles in mind.<br>
<br>
The second change set fixes <tt>BreakingMethodWrapper</tt><br>
to behave in the same manner as <tt>#break</tt>.<br>
<br>
<br>
HTH,<br>
<br>
Gerald<br>
</body>
</html>