On 2024-01-03T23:44:30+00:00, mail@jaromir.net wrote:
Hi Christoph, sorry for confusing you :)
On 04-Jan-24 12:34:04 AM, christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
Hi Jaromir,
On 2024-01-03T22:36:17+00:00, mail(a)jaromir.net wrote:
Hi Christoph,
On 02-Jan-24 8:05:31 PM,
christoph.thiede(a)student.hpi.uni-potsdam.de
wrote:
Hi Jaromir,
thanks for the clarification. If you don't mind I would still wait
for
a couple of days to see whether Eliot or Marcel or someone else who
are
longer aboard find anything against your change, but I have been convinced by you. :-) After that, we can merge your open test and eliminate the ifNil checks in the TraceDebugger and also in the penultimate line of Context>>#return:from:.
In general, some methods are "pure simulation" methods intended
to
mimic the VM behavior (#step etc) but nothing prevents one from
using
them for other purposes - like what #runUntilErrorOrReturnFrom: did:
to
just get rid of some contexts). Is it ok to do that? I tend to think it's not; it's confusing. That's why I made #stepToCalleeOrNil a private method because it's not a "true" simulation method but a
sort
of hybrid.
Yes, I think I understand your point here, the assumptions and use cases for #stepToCalleeOrNil are too special to expose it to
everyone.
Clients should mainly use #step, #stepToCallee, or maybe - with care
#runUntilErrorOrReturnFrom: to advance a context I think.
This is also why I checked Jakob's Git Browser and all tests seem
fine.
Wait, Squot is using code simulation?
I guess not, but as I noted, nothing prevents you from using
simulation
methods in the non-simulation code :) Plus, one might use simulation methods to prepare test scenarios... So I just ran the changes
through
Squot tests for good measure ;)
I still don't understand. :-) You ran the Squot test on the off chance that something in Squot or the Squot test uses code simulation?
Well, you can put it that way :) The more tests the better chance you catch something :D It happened a few times Pharo tests caught things Squeak didn't.
Got it! But chances might be very low in many situations ... There is even a distinct research topic on test prioritization. :D I guess I'm doing something roughly similar in the kernel tests for SimulationStudio and TraceDebugger, where I run a couple of selected test suites from trunk packages inside my simulators to catch any edge cases in their execution semantics ...
Or did you run the Squot tests inside the simulator? :D
Best, Christoph
Best, Christoph
Sent from Squeak Inbox Talk https://github.com/hpi-swa-lab/squeak-inbox-talk
On 2024-01-02T11:25:57+00:00, mail(a)jaromir.net wrote:
Hi Christoph,
correct me if I'm wrong: with the corrected #step semantics (the #return:from: fix) one should no longer need to do things like:
self step ifNil: [^ self]
because #step should always return a context, even if attempting
to
step
to a nil context:
[] asContext step
In this case it correctly returns the #cannotReturn: context.
I've noticed these nil checks in Trace debugger's #doStepOver or #stepToHome.
I hope I haven't overlooked anything :)
Thanks for your thoughts, Jaromir
On 31-Dec-23 10:42:54 AM, "Jaromir Matas" <mail(a)jaromir.net>
wrote:
Hi Christoph,
Yes, that's exactly what I was talking about - the #return:from:
fix
changes slightly (perhaps it's better to say corrects) the
semantics
of
some stepping methods - #step and #stepToCallee, which allowed illegally stepping into a dead or nil context. They can no
longer be
used in the manner you showed. Another example was #runUntilErrorOrReturnFrom: - it used #stepToCallee this way so
as a
workaround I created the #stepToCalleeOrNil method and used in #runUntilErrorOrReturnFrom:
[ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToCalleeOrNil].
Theoretically there might be some external code (mis)using the incorrect stepping semantics. In Pharo's trunk they were mainly
tests
and #stepToHome but I haven't checked any external code. But all
their
tests are green with this change and I guess it's not
widespread.
This is also why I checked Jakob's Git Browser and all tests
seem
fine.
My opinion is to keep the correct simulation semantics and deal
with
potential consequences as/if they come. However I don't expect a
huge
impact as the change only affects border situations.
In general, some methods are "pure simulation" methods intended
to
mimic the VM behavior (#step etc) but nothing prevents one from
using
them for other purposes - like what #runUntilErrorOrReturnFrom:
did:
to
just get rid of some contexts). Is it ok to do that? I tend to
think
it's not; it's confusing. That's why I made #stepToCalleeOrNil a private method because it's not a "true" simulation method but a
sort
of hybrid.
What do you think?
Thanks for reviewing the fix! Best, Jaromir
On 30-Dec-23 11:07:54 PM,
christoph.thiede(a)student.hpi.uni-potsdam.de
wrote:
>Hi Jaromir, > >I found a breaking change in the new behavior of >Context>>#return:from: while using the TraceDebugger: > >In the past we could say: > >c:=[2+3]asContext. >[c]whileNotNil:[c:=cstep]. > >With your change, the script runs forever because the last step
does
>not answer nil as before but activates a new #cannotReturn:. > >This behavior seems not be expected anywhere in the trunk (if
my
first
>search was complete), and you are right that the new behavior
aligns
>closer to the VM behavior. Still, the old code seemed to
explicitly
>intend this - see the "newTop ifNotNil:" at the bottom of the
method.
> >I wonder whether we should keep this. For me it is not a big
deal;
I
>can just change my script like this: > >c:=[2+3]asContext. >[csenderisNiland:[cwillReturn]]whileNotNil:[c:=cstep]. > >I just wonder whether this could a breaking or unintended
change
for
>anything else. For [^2] ensure: [] it would not be a big deal,
we
>could just change the check in question to >(aSenderisDeador:[newTopnotNiland:[newTopisDead]])ifTrue:. I am >tending against restoring the old behavior, but I am unsure.
What
is
>your opinion on this? > >Best, >Christoph > >--- >Sent from Squeak Inbox Talk >https://github.com/hpi-swa-lab/squeak-inbox-talk > >On 2023-12-30T21:13:37+00:00, mail(a)jaromir.net wrote: > > > > nit: You mixed up the order of arguments for
#assert:equals:
> > > > oops, sorry :) It happens to me all the time; I've never
actually
> > understood why the strange, almost Yodaesque, order... as if
you
>asked > > in English: > > > > "Make sure 18 is his age." > > > > Thanks, > > Jaromir > > > > > > On 30-Dec-23 9:13:56 PM, >christoph.thiede(a)student.hpi.uni-potsdam.de > > wrote: > > > > >nit: You mixed up the order of arguments for
#assert:equals:
(it is
> > >assert: expected equals: actual) and could have used it in
the
>final > > >assert again, but that's clearly no reason to hold back a
useful
>test. > > >;-) Merged, thanks! :-) > > > > > >Best, > > >Christoph > > > > > >--- > > >Sent from Squeak Inbox Talk > > >https://github.com/hpi-swa-lab/squeak-inbox-talk > > > > > >On 2023-12-30T17:33:08+00:00, mail(a)jaromir.net wrote: > > > > > > > Hi Christoph, > > > > > > > > Thanks for merging the fixes; I've just sent another
test in
> > > > KernelTests-jar.448 to complement them. > > > > > > > > Please take a look and if ok I'd appreciate it if you
could
>merge it > > >as > > > > well. > > > > > > > > Best regards and Happy New Year to you too! > > > > Jaromir > > > > > > > > > > > > On 30-Dec-23 6:15:25 PM, > > >christoph.thiede(a)student.hpi.uni-potsdam.de > > > > wrote: > > > > > > > > >Hi Jaromir, hi all, > > > > > > > > > >finally I have found the time to review these
suggestions.
> > > > >Kernel-jar.1537, Kernel-jar.1538, and Kernel-jar.1539
look
>excellent > > >to > > > > >me as well. Clear, straightforward, useful. :-) I have
merged
>them > > >into > > > > >the trunk via Kernel-ct.1545. > > > > > > > > > >Regarding DebuggerTests>>test16HandleSimulationError, I
have
>patched > > >it > > > > >via ToolsTests-ct.125. Nothing to rack your brains
over:
> > >"thisContext > > > > >pc: nil" just mimicks any kind of unhandled error
inside
the
> > >simulator > > > > >- since we now gently handle this via #cannotReturn:, I
just
> > >replaced > > > > >it with "thisContext pc: false". :-) Sorry for not
clarifying
>that > > > > >earlier and letting you speculate. > > > > > > > > > >Thanks for your work, and I already wish you a happy
new
year!
> > > > > > > > > >Best, > > > > >Christoph > > > > > > > > > >--- > > > > >Sent from Squeak Inbox Talk > > > > >https://github.com/hpi-swa-lab/squeak-inbox-talk > > > > > > > > > >On 2023-11-29T13:31:09+00:00, mail(a)jaromir.net wrote: > > > > > > > > > > > Hi Marcel, > > > > > > > > > > > > > [myself] whether the patch would have been
necessary
>should the > > > > > > #return:from: had been fixed then > > > > > > > > > > > > Nonsense, I just mixed it up with another issue :) > > > > > > > > > > > > > > > > > > On 29-Nov-23 1:51:21 PM, "Jaromir Matas" ><mail(a)jaromir.net> > > >wrote: > > > > > > > > > > > > >Thanks Marcel! This test somehow slipped my
attention
:)
> > > > > > > > > > > > > >The test can no longer work as is. It takes
advantage
of
>the > > > > >erroneous > > > > > > >behavior of #return:from: in the sense that if you
simulate
> > > > > > > > > > > > > > thisContext pc: nil > > > > > > > > > > > > > >it'll happily return to a dead context (i.e. to
thisContext
>from > > > > >#pc: > > > > > > >nil context) - which is not what the VM does during >runtime. It > > > > >should > > > > > > >immediately raise an illegal return exception not
only
>during > > > > >runtime > > > > > > >but also during simulation. > > > > > > > > > > > > > >The test mentions a patch for an infinite debugger
chain
> > > > > > > >(http://forum.world.st/I-broke-the-debugger-td5110752.html).
I
> > > > >wonder > > > > > > >whether the problem could have something to do with
this
> > >simulation > > > > >bug > > > > > > >in return:from:; and a terrible idea occurred to me
whether
>the > > > > >patch > > > > > > >would have been necessary should the #return:from:
had
been
> > >fixed > > > > >then > > > > > > >;O > > > > > > > > > > > > > >We may potentially come up with more examples like
this,
>even in > > >the > > > > > > >trunk, where the bug from #return:from: propagated
and
was
>taken > > > > > > >advantage of. I've found and fixed >#runUntilErrorOrReturnFrom: > > >but > > > > >more > > > > > > >can still be surviving undetected... > > > > > > > > > > > > > >I'd place the test into #expectedFailures for now
but
maybe
>it's > > > > >time > > > > > > >to remove it; Christoph should decide :) > > > > > > > > > > > > > >Thanks again, > > > > > > >Jaromir > > > > > > > > > > > > > > > > > > > > >On 29-Nov-23 10:28:38 AM, "Taeumel, Marcel via
Squeak-dev"
> > > > > > ><squeak-dev(a)lists.squeakfoundation.org> wrote: > > > > > > > > > > > > > >>Hi Jaromir -- > > > > > > >> > > > > > > >>Looks good. Still, what about that >#test16HandleSimulationError > > > > >now? > > > > > > >>:-) It is failing with your changes ... how would
you
>adapt it? > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>Best, > > > > > > >>Marcel > > > > > > >>>Am 28.11.2023 01:29:39 schrieb Jaromir Matas > > ><mail(a)jaromir.net>: > > > > > > >>> > > > > > > >>>Hi Eliot, Marcel, all, > > > > > > >>> > > > > > > >>>I've sent a fix Kernel-jar.1539 to the Inbox that
solves
>the > > > > > > >>>remaining bit of the chain of bugs described in
the
>previous > > >post. > > > > > > >>>All tests are green now and I think the root
cause
has
>been > > >found > > > > >and > > > > > > >>>fixed. > > > > > > >>> > > > > > > >>>In this last bit I've created a version of
stepToCallee
>that > > >would > > > > > > >>>identify a potential illegal return to a nil
sender
and
>avoid > > >it. > > > > > > >>> > > > > > > >>>Now this example can be debugged without any
problems:
> > > > > > >>> > > > > > > >>>[[self halt. ^ 1] on: BlockCannotReturn do:
#resume ]
>fork > > > > > > >>> > > > > > > >>>If you're happy with the solution in
Kernel-jar.1539,
> > > > > > >>>Kernel-jar.1538, Kernel-jar.1537 and the test in > > > > >KernelTests-jar.447, > > > > > > >>>could you please double-check and merge, please?
(And
>remove > > > > > > >>>Kernel-mt.1534 and Tools-jar.1240 from the Inbox) > > > > > > >>> > > > > > > >>>Best, > > > > > > >>>Jaromir > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>>On 27-Nov-23 12:09:37 AM, "Jaromir Matas" ><mail(a)jaromir.net> > > > > >wrote: > > > > > > >>> > > > > > > >>>>Hi Eliot, Christoph, all > > > > > > >>>> > > > > > > >>>>It looks like there are some more skeletons in
the
>closet :/ > > > > > > >>>> > > > > > > >>>>If you run this example > > > > > > >>>> > > > > > > >>>>[[self halt. ^ 1] on: BlockCannotReturn do: [:ex
|
ex
>resume] > > >] > > > > >fork > > > > > > >>>> > > > > > > >>>>and step over halt and then step over ^1 you get
a
> > >nonsensical > > > > >error > > > > > > >>>>as a result of decoding nil as an instruction. > > > > > > >>>> > > > > > > >>>>It turns out that the root cause is in the
#return:from:
> > >method: > > > > >it > > > > > > >>>>only checks whether aSender is dead but ignores
the
> > >possibility > > > > >that > > > > > > >>>>aSender sender may be nil or dead in which cases
the
VM
>also > > > > > > >>>>responds with sending #cannotReturn, hence I
assume
the
> > >simulator > > > > > > >>>>should do the same. In addition, the VM nills
the pc
in
>such > > > > > > >>>>scenario, so I added the same functionality here
too:
> > > > > > >>>> > > > > > > >>>>Context >> return: value from: aSender > > > > > > >>>> "For simulation. Roll back self to aSender and
return
>value > > > > > > >>>>from it. Execute any unwind blocks on the way.
ASSUMES
> > >aSender is > > > > > > >>>>a sender of self" > > > > > > >>>> > > > > > > >>>> | newTop | > > > > > > >>>> newTop := aSender sender. > > > > > > >>>> (aSender isDead or: [newTop isNil or: [newTop
isDead]])
> > >ifTrue: > > > > > > >>>> "<--------- this is extended ------" > > > > > > >>>> [^self pc: nil; send: #cannotReturn: to: self
with:
> > > > > > >>>>{value}]. "<------ pc: nil is added ----" > > > > > > >>>> (self findNextUnwindContextUpTo: newTop)
ifNotNil:
> > > > > > >>>> "Send #aboutToReturn:through: with nil as the
second
> > > > > > >>>>argument to avoid this bug: > > > > > > >>>> Cannot #stepOver '^2' in example '[^2] ensure:
[]'.
> > > > > > >>>> See > > > > > > > > > > > > > > >
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-June/220975.html > > > > > > > > > > > > > > >
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-June/220975.html" > > > > > > >>>> [^self send: #aboutToReturn:through: to: self
with:
>{value. > > > > > > >>>>nil}]. > > > > > > >>>> self releaseTo: newTop. > > > > > > >>>> newTop ifNotNil: [newTop push: value]. > > > > > > >>>> ^newTop > > > > > > >>>> > > > > > > >>>>In order for this to work #cannotReturn: has to
be
>modified > > >as in > > > > > > >>>>Kernel-jar.1537: > > > > > > >>>> > > > > > > >>>>Context >> cannotReturn: result > > > > > > >>>> > > > > > > >>>> closureOrNil ifNotNil: [^ self cannotReturn:
result
to:
>self > > > > > > >>>>home sender]. > > > > > > >>>> self error: 'Computation has been terminated!' > > > > > > >>>>"<----------- this has to be an Error -----" > > > > > > >>>> > > > > > > >>>>Then it almost works except when you keep
stepping
over
>in > > >the > > > > > > >>>>example above, you get an MNU error on `self
previousPc`
>in > > > > > > >>>>#cannotReturn:to:` with your solution of the VM
crash.
>If you > > > > >don't > > > > > > >>>>mind I've amended your solution and added the
final
>context > > >where > > > > > > >>>>the computation couldn't return along with the
pc:
> > > > > > >>>> > > > > > > >>>>Context >> cannotReturn: result to: homeContext > > > > > > >>>> "The receiver tried to return result to
homeContext
>that > > >cannot > > > > > > >>>>be returned from. > > > > > > >>>> Capture the return context/pc in a
BlockCannotReturn.
>Nil > > >the pc > > > > > > >>>>to prevent repeat > > > > > > >>>> attempts and/or invalid continuation. Answer
the
result
>of > > > > > > >>>>raising the exception." > > > > > > >>>> > > > > > > >>>> | exception previousPc | > > > > > > >>>> exception := BlockCannotReturn new. > > > > > > >>>> previousPc := pc ifNotNil: [self previousPc].
"<-----
>here's > > >a > > > > > > >>>>fix ----" > > > > > > >>>> exception > > > > > > >>>> result: result; > > > > > > >>>> deadHome: homeContext; > > > > > > >>>> finalContext: self; "<----- here's the new
state,
if
> > > > > > >>>>that's fine ----" > > > > > > >>>> pc: previousPc. > > > > > > >>>> pc := nil. > > > > > > >>>> ^exception signal > > > > > > >>>> > > > > > > >>>>Unfortunately, this is still not the end of the
story:
>there > > >are > > > > > > >>>>situations where #runUntilErrorOrReturnFrom:
places
the
>two > > >guard > > > > > > >>>>contexts below the bottom context. And that is a
problem
> > >because > > > > > > >>>>when the method tries to remove the two guard
contexts
>before > > > > > > >>>>returning at the end it uses #stepToCalee to do
the
job
>but > > >this > > > > > > >>>>unforotunately was (ab)using the above bug in >#return:from: - > > > > >I'll > > > > > > >>>>explain: #return:from: didn't check whether
aSender
>sender > > >was > > > > >nil > > > > > > >>>>and as a result it allowed to simulate a return
to a
>"nil > > > > >context" > > > > > > >>>>which was then (ab)used in the clean-up via
#stepToCalee
>in > > >the > > > > > > >>>>#runUntilErrorOrReturnFrom:. > > > > > > >>>> > > > > > > >>>>When I fixed the #return:from: bug, the > > > > >#runUntilErrorOrReturnFrom: > > > > > > >>>>cleanup of the guard contexts no longer works in
that
>very > > > > >special > > > > > > >>>>case where the guard contexts are below the
bottom
>context. > > > > >There's > > > > > > >>>>one case where this is being used:
#terminateAggresively
>by > > > > > > >>>>Christoph. > > > > > > >>>> > > > > > > >>>>If I'm right with this analysis, the > > >#runUntilErrorOrReturnFrom: > > > > > > >>>>should get fixed too but I'll be away now for a
few
days
>and > > >I > > > > >won't > > > > > > >>>>be able to respond. If you or Christoph had a
chance
to
>take > > >a > > > > >look > > > > > > >>>>at Kernel-jar.1538 and Kernel-jar.1537 I'd be
very
>grateful. > > >I > > > > >hope > > > > > > >>>>this super long message at least makes some
sense :)
> > > > > > >>>>Best, > > > > > > >>>>Jaromir > > > > > > >>>> > > > > > > >>>>[1] Kernel-jar.1538, Kernel-jar.1537 > > > > > > >>>>[2] KernelTests-jar.447 > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>PS: Christoph, > > > > > > >>>> > > > > > > >>>>With Kernel-jar.1538 + Kernel-jar.1537 your
example
> > > > > > >>>> > > > > > > >>>>process := > > > > > > >>>> [(c := thisContext) pc: nil. > > > > > > >>>> 2+3] newProcess. > > > > > > >>>>process runUntil: [:ctx | ctx selector = >#cannotReturn:]. > > > > > > >>>>self assert: process suspendedContext sender
sender
= c.
> > > > > > >>>>self assert: process suspendedContext arguments
=
{c}.
> > > > > > >>>> > > > > > > >>>>works fine, I've just corrected your first
assert.
> > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>On 21-Nov-23 6:40:32 PM, "Eliot Miranda" > > > > ><eliot.miranda(a)gmail.com> > > > > > > >>>>wrote: > > > > > > >>>> > > > > > > >>>>>Hi Jaromir, > > > > > > >>>>> > > > > > > >>>>>>On Nov 20, 2023, at 11:51 PM, Jaromir Matas > > > > ><mail(a)jaromir.net> > > > > > > >>>>>>wrote: > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>>Hi Eliot, > > > > > > >>>>>>Very elegant! Now I finally got what you meant
exactly
>:) > > > > >Thanks. > > > > > > >>>>>> > > > > > > >>>>>>Two questions: > > > > > > >>>>>>1. in order for the enclosed test to work I'd
need
an
>Error > > > > > > >>>>>>instead of Processor debugWithTitle:full: call
in
> > > > >#cannotReturn:. > > > > > > >>>>>>Otherwise I don't know how to catch a plain
invocation
>of > > >the > > > > > > >>>>>>Debugger: > > > > > > >>>>>> > > > > > > >>>>>>cannotReturn: result > > > > > > >>>>>> > > > > > > >>>>>> closureOrNil ifNotNil: [^ self cannotReturn:
result
>to: > > >self > > > > > > >>>>>>home sender]. > > > > > > >>>>>> self error: 'Computation has been
terminated!'
> > > > > > >>>>> > > > > > > >>>>>Much nicer. > > > > > > >>>>> > > > > > > >>>>>>2. We are capturing a pc of self which is
completely
> > >different > > > > > > >>>>>>context from homeContext indeed. > > > > > > >>>>> > > > > > > >>>>>Right. The return is attempted from a specific
return
> > >bytecode > > > > >in a > > > > > > >>>>>specific block. This is the coordinate of the
return
>that > > >cannot > > > > >be > > > > > > >>>>>made. This is the relevant point of origin of
the
>cannot > > >return > > > > > > >>>>>exception. > > > > > > >>>>> > > > > > > >>>>>Why the return fails is another matter: > > > > > > >>>>>- the home context’s sender is a dead context
(cannot
>be > > > > >resumed) > > > > > > >>>>>- the home context’s sender is nil (home
already
>returned > > >from) > > > > > > >>>>>- the block activation’s home is nil rather
than a
>context > > > > >(should > > > > > > >>>>>not happen) > > > > > > >>>>> > > > > > > >>>>>But in all these cases the pc of the home
context
is
> > >immaterial. > > > > > > >>>>>The hike is being returned through/from, rather
than
>from; > > >the > > > > > > >>>>>home’s pc is not relevant. > > > > > > >>>>> > > > > > > >>>>>>Maybe we could capture self in the exception
too
to
>make it > > > > >more > > > > > > >>>>>>clear/explicit what is going on: what context
the
>captured > > >pc > > > > >is > > > > > > >>>>>>actually associated with. Just a thought... > > > > > > >>>>> > > > > > > >>>>>Yes, I like that. I also like the idea of
somehow
>passing > > >the > > > > > > >>>>>block activation’s pc to the debugger so that
the
>relevant > > > > >return > > > > > > >>>>>expression is highlighted in the debugger. > > > > > > >>>>> > > > > > > >>>>>> > > > > > > >>>>>>Thanks again, > > > > > > >>>>>>Jaromir > > > > > > >>>>> > > > > > > >>>>>You’re welcome. I love working in this part of
the
>system. > > > > >Thanks > > > > > > >>>>>for dragging me there. I’m in a slump right now
and
> > >appreciate > > > > >the > > > > > > >>>>>fellowship. > > > > > > >>>>> > > > > > > >>>>>>------ Original Message ------ > > > > > > >>>>>>From "Eliot Miranda"
<eliot.miranda(a)gmail.com>
> > > > > > >>>>>>To "Jaromir Matas" <mail(a)jaromir.net> > > > > > > >>>>>>Cc squeak-dev(a)lists.squeakfoundation.org > > > > > > >>>>>>Date 11/21/2023 2:17:21 AM > > > > > > >>>>>>Subject Re: Re[2]: [squeak-dev] Re: Resuming
on
> > > > >BlockCannotReturn > > > > > > >>>>>>exception > > > > > > >>>>>> > > > > > > >>>>>>>Hi Jaromir, > > > > > > >>>>>>> > > > > > > >>>>>>> see Kernel-eem.1535 for what I was
suggesting.
This
> > >example > > > > > > >>>>>>>now has an exception with the right pc value
in
it:
> > > > > > >>>>>>> > > > > > > >>>>>>>[[^1] on: BlockCannotReturn do: [:ex| ex pc
inspect.
>ex > > > > >resume]] > > > > > > >>>>>>>fork > > > > > > >>>>>>> > > > > > > >>>>>>>The fix is simply > > > > > > >>>>>>> > > > > > > >>>>>>>Context>>cannotReturn: result to: homeContext > > > > > > >>>>>>> "The receiver tried to return result to
homeContext
>that > > > > > > >>>>>>>cannot be returned from. > > > > > > >>>>>>> Capture the return pc in a
BlockCannotReturn.
Nil
>the pc > > >to > > > > > > >>>>>>>prevent repeat > > > > > > >>>>>>> attempts and/or invalid continuation. Answer
the
>result > > >of > > > > > > >>>>>>>raising the exception." > > > > > > >>>>>>> > > > > > > >>>>>>> | exception | > > > > > > >>>>>>> exception := BlockCannotReturn new. > > > > > > >>>>>>> exception > > > > > > >>>>>>> result: result; > > > > > > >>>>>>> deadHome: homeContext; > > > > > > >>>>>>> pc: self previousPc. > > > > > > >>>>>>> pc := nil. > > > > > > >>>>>>> ^exception signal > > > > > > >>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>>The VM crash is now avoided. The debugger
displays
>the > > >method, > > > > > > >>>>>>>but does not highlight the offending pc,
which is
no
>big > > >deal. > > > > >A > > > > > > >>>>>>>suitable defaultHandler for B
lockCannotReturn
may be
>able > > >to > > > > >get > > > > > > >>>>>>>the debugger to highlight correctly on
opening.
Try
>the > > > > > > >>>>>>>following examples: > > > > > > >>>>>>> > > > > > > >>>>>>>[[^1] on: BlockCannotReturn do: #resume]
fork.
> > > > > > >>>>>>> > > > > > > >>>>>>>[[^1] on: BlockCannotReturn do: [:ex| ex pc
inspect.
>ex > > > > >resume]] > > > > > > >>>>>>>fork > > > > > > >>>>>>> > > > > > > >>>>>>>[[^1] value] fork. > > > > > > >>>>>>> > > > > > > >>>>>>>They al; seem to behave perfectly acceptably
to
me.
>Does > > >this > > > > > > >>>>>>>fix work for you? > > > > > > >>>>>>> > > > > > > >>>>>>>On Fri, Nov 17, 2023 at 3:14 PM Jaromir Matas > > > > ><mail(a)jaromir.net> > > > > > > >>>>>>>wrote: > > > > > > >>>>>>>>Hi Eliot, > > > > > > >>>>>>>> > > > > > > >>>>>>>>How about to nil the pc just before making
the
>return: > > > > > > >>>>>>>>``` > > > > > > >>>>>>>>Context >> #cannotReturn: result > > > > > > >>>>>>>> > > > > > > >>>>>>>> self push: self pc. "backup the pc for the
sake
of
> > > > > > >>>>>>>>debugging" > > > > > > >>>>>>>> closureOrNil ifNotNil: [^self cannotReturn:
result
>to: > > >self > > > > > > >>>>>>>>home sender; pc: nil]. > > > > > > >>>>>>>> Processor debugWithTitle: 'Computation has
been
> > >terminated!' > > > > > > >>>>>>>>translated full: false > > > > > > >>>>>>>>``` > > > > > > >>>>>>>>The nilled pc should not even potentially
interfere
>with > > >the > > > > > > >>>>>>>>#isDead now. > > > > > > >>>>>>>> > > > > > > >>>>>>>>I hope this is at least a step in the right >direction :) > > > > > > >>>>>>>> > > > > > > >>>>>>>>However, there's still a problem when
debugging
the
> > > > >resumption > > > > > > >>>>>>>>of #cannotReturn because the encoders expect
a
>reasonable > > > > >index. > > > > > > >>>>>>>>I haven't figured out yet where to place a
nil
check
>- > > >#step, > > > > > > >>>>>>>>#stepToSendOrReturn... ? > > > > > > >>>>>>>> > > > > > > >>>>>>>>Thanks again, > > > > > > >>>>>>>>Jaromir > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>>------ Original Message ------ > > > > > > >>>>>>>>From "Eliot Miranda"
<eliot.miranda(a)gmail.com>
> > > > > > >>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net> > > > > > > >>>>>>>>Date 11/17/2023 8:36:50 PM > > > > > > >>>>>>>>Subject Re: [squeak-dev] Re: Resuming on > > >BlockCannotReturn > > > > > > >>>>>>>>exception > > > > > > >>>>>>>> > > > > > > >>>>>>>>>Hi Jaromir, > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>>On Nov 17, 2023, at 7:05 AM, Jaromir Matas > > > > ><mail(a)jaromir.net> > > > > > > >>>>>>>>>>wrote: > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>Eliot, hi again, > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>Please disregard my previous comment about
nilling
>the > > > > > > >>>>>>>>>>contexts that have returned. We are indeed
talking
> > >about > > > > >the > > > > > > >>>>>>>>>>context directly under the #cannotReturn
context
>which > > >is > > > > > > >>>>>>>>>>totally different from the home context in
another
> > >thread > > > > > > >>>>>>>>>>that's gone. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>I may still be confused but would nilling
the
pc
>of the > > > > > > >>>>>>>>>>context directly under the cannotReturn
context
>help? > > > > >Here's > > > > > > >>>>>>>>>>what I mean: > > > > > > >>>>>>>>>>``` > > > > > > >>>>>>>>>>Context >> #cannotReturn: result > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> closureOrNil ifNotNil: [^self pc: nil; >cannotReturn: > > > > > > >>>>>>>>>>result to: self home sender]. > > > > > > >>>>>>>>>> Processor debugWithTitle: 'Computation
has
been
> > > > > > >>>>>>>>>>terminated!' translated full: false. > > > > > > >>>>>>>>>>``` > > > > > > >>>>>>>>>>Instead of crashing the VM invokes the
debugger
>with > > >the > > > > > > >>>>>>>>>>'Computation has been terminated!'
message.
> > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>Does this make sense? > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>Nearly. But it loses the information on
what
the pc
> > >actually > > > > > > >>>>>>>>>is, and that’s potentially vital
information.
So
>IMO the > > >ox > > > > > > >>>>>>>>>should only be nilled between the
BlockCannotReturn
> > > > >exception > > > > > > >>>>>>>>>being created and raised. > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>[But if you try this don’t be surprised if
it
>causes a > > >few > > > > > > >>>>>>>>>temporary problems. It looks to me that
without
a
>little > > > > > > >>>>>>>>>refactoring this could easily cause an
infinite
> > >recursion > > > > > > >>>>>>>>>around the sending of isDead. I’m sure
you’ll
be
>able to > > >fix > > > > > > >>>>>>>>>the code to work correctly] > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>>Thanks, > > > > > > >>>>>>>>>>Jaromir > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>------ Original Message ------ > > > > > > >>>>>>>>>>From "Jaromir Matas" <mail(a)jaromir.net> > > > > > > >>>>>>>>>>To "Eliot Miranda"
<eliot.miranda(a)gmail.com>;
>"The > > > > > > >>>>>>>>>>general-purpose Squeak developers list" > > > > > > >>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org> > > > > > > >>>>>>>>>>Date 11/17/2023 10:15:17 AM > > > > > > >>>>>>>>>>Subject [squeak-dev] Re: Resuming on >BlockCannotReturn > > > > > > >>>>>>>>>>exception > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>>Hi Eliot, > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>------ Original Message ------ > > > > > > >>>>>>>>>>>From "Eliot Miranda"
<eliot.miranda(a)gmail.com>
> > > > > > >>>>>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net> > > > > > > >>>>>>>>>>>Cc "The general-purpose Squeak developers
list"
> > > > > > >>>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org> > > > > > > >>>>>>>>>>>Date 11/16/2023 11:52:45 PM > > > > > > >>>>>>>>>>>Subject Re: Re[2]: [squeak-dev] Re:
Resuming
on
> > > > > > >>>>>>>>>>>BlockCannotReturn exception > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>>Hi Jaromir, > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>On Thu, Nov 16, 2023 at 2:22 PM Jaromir
Matas
> > > > > > >>>>>>>>>>>><mail(a)jaromir.net> wrote: > > > > > > >>>>>>>>>>>>>Hi Nicolas, Eliot, > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>here's what I understand is happening
(see
the
> > >enclosed > > > > > > >>>>>>>>>>>>>screenshot): > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>1) we fork a new process to evaluate
[^1]
> > > > > > >>>>>>>>>>>>>2) the new process evaluates [^1] which
means
> > > > >instruction > > > > > > >>>>>>>>>>>>>18 is being evaluated, hence pc points
to
> > >instruction 19 > > > > > > >>>>>>>>>>>>>now > > > > > > >>>>>>>>>>>>>3) however, the home context where ^1
should
>return > > >to > > > > >is > > > > > > >>>>>>>>>>>>>gone by this time (the process that
executed
>the > > >fork > > > > >has > > > > > > >>>>>>>>>>>>>already returned - notice the two up
arrows
in
>the > > > > >debugger > > > > > > >>>>>>>>>>>>>screenshot) > > > > > > >>>>>>>>>>>>>4) the VM can't finish the instruction
and
>returns > > > > >control > > > > > > >>>>>>>>>>>>>to the image via placing the
#cannotReturn:
>context > > >on > > > > >top > > > > > > >>>>>>>>>>>>>of the [^1] context > > > > > > >>>>>>>>>>>>>5) #cannotReturn: evaluation results in >signalling > > >the > > > > >BCR > > > > > > >>>>>>>>>>>>>exception which is then handled by the
#resume
> > >handler > > > > > > >>>>>>>>>>>>> (in our debugged case the [:ex | self
halt. ex
> > >resume] > > > > > > >>>>>>>>>>>>>handler) > > > > > > >>>>>>>>>>>>>6) ex resume is evaluated, however,
this
means
> > > > >requesting > > > > > > >>>>>>>>>>>>>the VM to evaluate instruction 19 of
the
[^1]
> > >context - > > > > > > >>>>>>>>>>>>>which is past the last instruction of
the
>context > > >and > > > > >the > > > > > > >>>>>>>>>>>>>crash ensues > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>I wonder whether such situations
could/should
>be > > > > >prevented > > > > > > >>>>>>>>>>>>>inside the VM or whether such an
expectation is
> > >wrong > > > > >for > > > > > > >>>>>>>>>>>>>some reason. > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>As Nicolas says, IMO this is best done
at
the
>image > > > > >level. > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>It could be prevented in the VM, but at
great
>cost, > > >and > > > > >only > > > > > > >>>>>>>>>>>>partially. The performance issue is that
the
>last > > > > >bytecode > > > > > > >>>>>>>>>>>>in a method is not marked in any way,
and
that
>to > > > > >determine > > > > > > >>>>>>>>>>>>the last bytecode the bytecodes must be >symbolically > > > > > > >>>>>>>>>>>>evaluated from the start of the method.
See
> > >implementors > > > > >of > > > > > > >>>>>>>>>>>>endPC at the image level (which defer to
the
>method > > > > >trailer) > > > > > > >>>>>>>>>>>>and implementors of endPCOf: in the
VMMaker
>code. > > >Doing > > > > >this > > > > > > >>>>>>>>>>>>every time execution commences is
prohibitively
> > > > >expensive. > > > > > > >>>>>>>>>>>>The "only partially" issue is that
following
the
> > >return > > > > > > >>>>>>>>>>>>instruction may be other valid
bytecodes,
but
>these > > >are > > > > >not > > > > > > >>>>>>>>>>>>a continuation. > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>Consider the following code in some
block:
> > > > > > >>>>>>>>>>>> [self expression ifTrue: > > > > > > >>>>>>>>>>>> [^1]. > > > > > > >>>>>>>>>>>> ^2 > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>The bytecodes for this are > > > > > > >>>>>>>>>>>> pushReceiver > > > > > > >>>>>>>>>>>> send #expression > > > > > > >>>>>>>>>>>> jumpFalse L1 > > > > > > >>>>>>>>>>>> push 1 > > > > > > >>>>>>>>>>>> methodReturnTop > > > > > > >>>>>>>>>>>>L1 > > > > > > >>>>>>>>>>>> push 2 > > > > > > >>>>>>>>>>>> methodReturnTop > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>Clearly if expression is true these
should
be
>*no* > > > > > > >>>>>>>>>>>>continuation in which ^2 is executed. > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>Well, in that case there's a bug because
the
> > >computation > > > > >in > > > > > > >>>>>>>>>>>the following example shouldn't continue
past
the
>[^1] > > > > >block > > > > > > >>>>>>>>>>>but it silently does: > > > > > > >>>>>>>>>>>`[[true ifTrue: [^ 1]] on:
BlockCannotReturn
do:
> > >#resume ] > > > > > > >>>>>>>>>>>fork` > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>The bytecodes are > > > > > > >>>>>>>>>>> push true > > > > > > >>>>>>>>>>> jumpFalse L1 > > > > > > >>>>>>>>>>> push 1 > > > > > > >>>>>>>>>>> returnTop > > > > > > >>>>>>>>>>>L1 > > > > > > >>>>>>>>>>> push nil > > > > > > >>>>>>>>>>> blockReturn > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>So even if the VM did try and detect
whether
the
> > >return > > > > >was > > > > > > >>>>>>>>>>>>at the last block method, it would only
work
for
> > >special > > > > > > >>>>>>>>>>>>cases. > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>It seems to me the issue is simply that
the
>context > > >that > > > > > > >>>>>>>>>>>>cannot be returned from should be marked
as
dead
>(see > > > > > > >>>>>>>>>>>>Context>>isDead) by setting its pc to
nil at
>some > > >point, > > > > > > >>>>>>>>>>>>presumably after copying the actual
return
pc
>into > > >the > > > > > > >>>>>>>>>>>>BlockCannotReturn exception, to avoid
ever
>trying to > > > > >resume > > > > > > >>>>>>>>>>>>the context. > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>Does this mean, in other words, that
every
>context > > >that > > > > > > >>>>>>>>>>>returns should nil its pc to avoid being >"wrongly" > > > > > > >>>>>>>>>>>reused/executed in the future, which
concerns
> > >primarily > > > > >those > > > > > > >>>>>>>>>>>being referenced somewhere hence
potentially
> > >executable in > > > > > > >>>>>>>>>>>the future, is that right? > > > > > > >>>>>>>>>>>Hypothetical question: would nilling the
pc
>during > > >returns > > > > > > >>>>>>>>>>>"fix" the example? > > > > > > >>>>>>>>>>>Thanks a lot for helping me understand
this.
> > > > > > >>>>>>>>>>>Best, > > > > > > >>>>>>>>>>>Jaromir > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>Thanks, > > > > > > >>>>>>>>>>>>>Jaromir > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>><bdxuqalu.png> > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>------ Original Message ------ > > > > > > >>>>>>>>>>>>>From "Eliot Miranda" ><eliot.miranda(a)gmail.com> > > > > > > >>>>>>>>>>>>>To "Jaromir Matas"
<mail(a)jaromir.net>;
"The
> > > > >general-purpose > > > > > > >>>>>>>>>>>>>Squeak developers list" > > > > > > >>>>>>>>><squeak-dev(a)lists.squeakfoundation.org> > > > > > > >>>>>>>>>>>>>Date 11/16/2023 6:48:43 PM > > > > > > >>>>>>>>>>>>>Subject Re: [squeak-dev] Re: Resuming
on
> > > > >BlockCannotReturn > > > > > > >>>>>>>>>>>>>exception > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>Hi Jaromir, > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>On Nov 16, 2023, at 3:23 AM, Jaromir
Matas
> > > > > > >>>>>>>>>>>>>>><mail(a)jaromir.net> wrote: > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>Hi Nicloas, > > > > > > >>>>>>>>>>>>>>>No no, I don't have any practical
scenario in
> > >mind, > > > > >I'm > > > > > > >>>>>>>>>>>>>>>just trying to understand why the VM
is
> > >implemented > > > > >like > > > > > > >>>>>>>>>>>>>>>this, whether there were a reason to
leave
>this > > > > > > >>>>>>>>>>>>>>>possibility of a crash, e.g. it would
slow
>down > > >the VM > > > > >to > > > > > > >>>>>>>>>>>>>>>try to prevent such a dumb situation
(who
>would > > >resume > > > > > > >>>>>>>>>>>>>>>from BCR in his right mind? :) ) - or
perhaps
>I > > >have > > > > > > >>>>>>>>>>>>>>>overlooked some good reason to even
keep
this
> > >behavior > > > > >in > > > > > > >>>>>>>>>>>>>>>the VM. That's all. > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>Let’s first understand what’s really >happening. > > > > >Presumably > > > > > > >>>>>>>>>>>>>>at tone point a context is resumed
those
pc is
> > >already > > > > >at > > > > > > >>>>>>>>>>>>>>the block return bytecode
(effectively,
>because it > > > > >crashes > > > > > > >>>>>>>>>>>>>>in JITted code, but I bet the stack vm
will
>crash > > >also, > > > > > > >>>>>>>>>>>>>>but not as cleanly - it will try and
execute
>the > > >bytes > > > > >in > > > > > > >>>>>>>>>>>>>>the encoded method trailer). So which
method
> > >actually > > > > > > >>>>>>>>>>>>>>sends resume, and to what, and what
state
is
> > >resume’s > > > > > > >>>>>>>>>>>>>>receiver when resume is sent? > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>Thanks for your reply. > > > > > > >>>>>>>>>>>>>>>Regards, > > > > > > >>>>>>>>>>>>>>>Jaromir > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>------ Original Message ------ > > > > > > >>>>>>>>>>>>>>>From "Nicolas Cellier" > > > > > > >>>>>>>>>>><nicolas.cellier.aka.nice(a)gmail.com> > > > > > > >>>>>>>>>>>>>>>To "Jaromir Matas"
<mail(a)jaromir.net>;
"The
> > > > > > >>>>>>>>>>>>>>>general-purpose Squeak developers
list"
> > > > > > >>>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org> > > > > > > >>>>>>>>>>>>>>>Date 11/16/2023 7:20:20 AM > > > > > > >>>>>>>>>>>>>>>Subject Re: [squeak-dev] Resuming on > > >BlockCannotReturn > > > > > > >>>>>>>>>>>>>>>exception > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>Hi Jaromir, > > > > > > >>>>>>>>>>>>>>>>Is there a scenario where it would
make
>sense to > > > > >resume > > > > > > >>>>>>>>>>>>>>>>a BlockCannotReturn? > > > > > > >>>>>>>>>>>>>>>>If not, I would suggest to protect
at
image
>side > > >and > > > > > > >>>>>>>>>>>>>>>>override #resume. > > > > > > >>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>Le mer. 15 nov. 2023, 23:42, Jaromir
Matas
> > > > > > >>>>>>>>>>>>>>>><mail(a)jaromir.net> a écrit : > > > > > > >>>>>>>>>>>>>>>>>Hi Eliot, Christoph, All, > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>It's known the following example
crashes
>the VM. > > >Is > > > > > > >>>>>>>>>>>>>>>>>this an intended behavior or a
"tolerated
>bug"? > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>`[[^ 1] on: BlockCannotReturn do:
#resume]
>fork` > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>I understand why it crashes: the
non-local
> > >return > > > > >has > > > > > > >>>>>>>>>>>>>>>>>nowhere to return to and so
resuming
the
> > >computation > > > > > > >>>>>>>>>>>>>>>>>leads to a crash. But why not raise
another
>BCR > > > > > > >>>>>>>>>>>>>>>>>exception to prevent the crash?
Potential
> > >infinite > > > > > > >>>>>>>>>>>>>>>>>loop? Perhaps I'm just missing the
purpose
>of > > >this > > > > > > >>>>>>>>>>>>>>>>>behavior... > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>Thanks for an explanation. > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>Best, > > > > > > >>>>>>>>>>>>>>>>>Jaromir > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>-- > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>>Jaromir Matas > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>-- > > > > > > >>>>>>>>>>>>_,,,^..^,,,_ > > > > > > >>>>>>>>>>>>best, Eliot > > > > > > >>>>>>>>>><Context-cannotReturn.st> > > > > > > >>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>>-- > > > > > > >>>>>>>_,,,^..^,,,_ > > > > > > >>>>>>>best, Eliot > > > > > > >>>>>><ProcessTest-testResumeAfterBCR.st>
Sent from Squeak Inbox Talk https://github.com/hpi-swa-lab/squeak-inbox-talk
Best, Christoph
--- Sent from Squeak Inbox Talk