<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Phil,<br>
<br>
On 10/17/2019 2:31 AM, Phil B wrote:
<blockquote
cite="mid:CAMJMOeiH=rKW_5Yj2i6a_vfLSzpR0TchGYQDA45p45N4aj8FiQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr">Juan,</div>
<div><br>
</div>
First, thanks for looking at the OMeta part of this... I really
wasn't expecting it. I was mentioning more as an FYI in case
you had expected the changes not to have functional/performance
impact. That said, the help is greatly appreciated!</div>
</blockquote>
<br>
:)<br>
<br>
<blockquote
cite="mid:CAMJMOeiH=rKW_5Yj2i6a_vfLSzpR0TchGYQDA45p45N4aj8FiQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at
7:05 PM Juan Vuletich <<a moz-do-not-send="true"
href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> Hi Phil,<br>
<br>
Today I tried to understand the problems you ran into.
The attachments are the result of this. To try this,
Start Cuis without the recent changes (i.e. #3866), then
load <a moz-do-not-send="true"
href="http://OMeta2Tests.pck.st" target="_blank">OMeta2Tests.pck.st</a>.
Now load OMetaStuff*.<a moz-do-not-send="true"
href="http://cs.st" target="_blank">cs.st</a> and
UnsavedChangesTo-OMeta2Extensions*.<a
moz-do-not-send="true" href="http://cs.st"
target="_blank">cs.st</a> attached here. Your tests
now pass, and performance seems as usual. I suggest
updating your repo with this.<br>
<br>
My changes do two things. One is to avoid non local
returns in handler blocks. The other one is about a few
places where you did [ :exception | exception signal ]
as the signal handler. Exceptions can only be signaled
once! I changed them to do [ :exception | exception pass
]. This was breaking the exception system if the recent
changes were loaded.<br>
</div>
</blockquote>
<div><br>
</div>
<div>1) Would you be opposed to a #nonLocalReturn: method on
Exception? That seems to me a cleaner and clearer way of
doing this. It's also more consistent with how Exception
deals with the other scenarios.</div>
</div>
</div>
</div>
</blockquote>
<br>
I think #nonLocalReturn: would be ok. Maybe a better name could be
#methodReturn:<br>
<br>
<blockquote
cite="mid:CAMJMOeiH=rKW_5Yj2i6a_vfLSzpR0TchGYQDA45p45N4aj8FiQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div>2) Doh! I'm not sure if I did the double-signaling or
if that was from the original OMeta code. Either way, it
was a dumb thing to do and entirely unnecessary in this
case as your changes show. The 'only signaled once!' part
warrants discussion/clarification...</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> <br>
Finally, I suggest adding yet another change set to Cuis
that could break existing but wrong code: 3924*.<a
moz-do-not-send="true" href="http://cs.st"
target="_blank">cs.st</a> attached throws an error if
an exception is signaled twice.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I guess it depends on what you are saying:</div>
<div><br>
</div>
<div>1) We think signaling twice is bad form and logically
inconsistent and so you shouldn't do it (to me that's not
an error, but is something we should capture and
*optionally* report to the user... I'm working on another
email/changeset related to this case.)</div>
<div><br>
</div>
<div>2) In Cuis, for implementation reasons, signaling twice
is an error and can not be done (define twice... read
on...)</div>
<div><br>
</div>
<div>While what you are saying re: not re-signaling
logically makes sense as something to avoid in general, I
don't see anything in the ANSI spec explicitly either
allowing or forbidding it.[SPEC] That's not a big deal as
sometimes implementation decisions need to be made but I
think we need to be very clear here on what is/isn't
allowed:</div>
<div><br>
</div>
<div>1) You can't signal the exception from within its
handler block (i.e. you can signal the exception again
and/or recycle it, but only *after* the current signal has
been handled)</div>
<div><br>
</div>
<div>2) You can't re-signal an Exception ever (i.e. you can
recycle but not re-signal... meaning we need to have a
method to clear out relevant state for recycling)</div>
<div><br>
</div>
<div>3) You can't re-signal or recycle an Exception ever
(i.e. they are single-shot instances)</div>
<div><br>
</div>
<div>(However we go, it seems like comments on the class and
relevant methods are in order)</div>
<div><br>
</div>
<div>Seriously, I didn't just make this up.... recycling is
a real use case. If you read my final note on <a
moz-do-not-send="true"
href="https://github.com/pbella/OMeta-Cuis">https://github.com/pbella/OMeta-Cuis</a>,
the 'original' OMeta implementation actually did recycle
exceptions as a performance enhancement. It did this by
re-signaling the existing instance since there was no
formal mechanism for recycling. I removed the feature due
to the implementation leaking (on the OMeta side not the
Exception side, IIRC) and had planned to re-implement it
(sans leak) at some point. So I'm wondering if that is
something that is supported or not.</div>
</div>
</div>
</div>
</blockquote>
<br>
I'm pretty sure re-signaling an exception instance while it is being
handled shouldn't be allowed. An exception has a (single)
signalContext. The design can't handle more than one.<br>
<br>
To enable re-signaling an already handled exception instance, I
guess it could be enough to clear ivar 'signalContext' in the
ifCurtailed: block in #evaluateHandlerBlock: . Then,
3924-SignalExceptionsOnlyOnce-JuanVuletich-2019Oct16-18h52m-jmv.1.cs.st
would stay.<br>
<br>
<blockquote
cite="mid:CAMJMOeiH=rKW_5Yj2i6a_vfLSzpR0TchGYQDA45p45N4aj8FiQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>This is all near and dear to me because, as you
probably noticed, Exception is the spine of OMeta's
control flow. If you change/break one, you probably
change/break the other.</div>
</div>
</div>
</div>
</blockquote>
<br>
Yep. It is a good test bed.<br>
<blockquote
cite="mid:CAMJMOeiH=rKW_5Yj2i6a_vfLSzpR0TchGYQDA45p45N4aj8FiQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> <br>
Please review.<br>
Thanks,<br>
<pre cols="72">--
Juan Vuletich</pre>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks,</div>
<div>Phil</div>
<div><br>
</div>
<div>[SPEC] Just to clarify what I mean here. In section
5.5.4.2 they explicitly state in the Errors section where
#outer cannot be sent from. If they intended #signal to
not be called from somewhere in particular, I would expect
(ok, hope) to see that indicated somewhere for #signal as
well. Of course specs aren't perfect and there are any
number of reasons why this might not have been stated one
way or the other.</div>
</div>
</div>
</div>
</blockquote>
<br>
I'm pretty sure it was an oversight. Doing [ :ex | ex signal ] as a
handler block is asking for trouble. How can you know it will not
try to handle the new signal with the same handler, entering in an
endless recursion?<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
</body>
</html>