> Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-)

Yahoo, a Meta-Object Facility adoption for Smalltalk systems. :-) And depth -1 would correspond to the Slang-generated VM implementation, right? ;-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 8. Dezember 2020 13:44:09
An: squeak-dev
Betreff: Re: [squeak-dev] A discrepancy between bytecode execution and simulation

Hi Christoph

> [...] between simulation and production (btw did I choose the right terms for them? :)

Since code simulation needs code execution, I think that "simulation" is a part of "execution".

Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-)

"Production" is then simulation depth 0. :-D

Best,
Marcel

Am 07.12.2020 18:55:31 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi all, hi Eliot,


I constructed the following code snippet which evaluates to true when running it using the production execution machinery:


nil == thisContext pop


I guess this is fine, because what alternatives would the execution machinery have? It could terminate the whole VM or we could introduce something like #cannotReturn: for invalid stack frame objects. Probably the current implementation is the best despite an invalid position in the context stack has been addressed.


However, the simulation machinery treats the same snippet differently, and it throws:


Error: subscript is out of bounds: 0


I wonder whether it is acceptable to have diverging behaviors for such an ill-defined edge case between simulation and production (btw did I choose the right terms for them? :)). Might it a better alternative to raise a Warning (#notify:) only and then return nil such as the VM appears to do?


Best,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210106/1375d3ff/attachment.html>