<div dir="ltr">Hi!<div><br></div><div>We still maintain the packages from VPRI.  Looking at the directory, we have quite a few versions of Worlds.  So there is a chance that it does something.<br><div><br></div><div><a href="http://tinlizzie.org/updates/exploratory/packages/">http://tinlizzie.org/updates/exploratory/packages/</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 16, 2021 at 1:59 PM Vanessa Freudenberg <<a href="mailto:vanessa@codefrau.net">vanessa@codefrau.net</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 dir="ltr"><div dir="ltr">On Tue, Mar 16, 2021 at 9:52 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><div dir="ltr"><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>

<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>One more question: Do you know where I can find the Smalltalk implementation of worlds? Is there any at all? The abstract in ResearchGate mentions this but is not addressed in the paper ...</p></div></div></blockquote><div>Well luckily one of the authors is still on this list ... </div><div> </div><div>Looks really interesting and useful!</div><div><br></div><div>Vanessa</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Best,</p>
<p>Christoph</p>
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203Signature">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div>
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203Item.MessagePartBody">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" rel="noopener noreferrer" id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203LPNoLP" target="_blank"><font size="2"><span id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Thiede, Christoph<br>
<b>Gesendet:</b> Dienstag, 16. März 2021 15:10:37<br>
<b>An:</b> <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
<b>Betreff:</b> AW: [squeak-dev] [ANN] SimulationStudio and sandboxed execution for Squeak</font>
<div> </div>
</div>
<div>


<div dir="ltr">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>Hi Subbu, thanks a lot for your thoughts! :-)</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">I am not sure if you have read Warth's research at VPRI</span></p>
<p><br>
<span style="font-size:12pt"></span></p>
<div>No, I have not. Looks very interesting, I will read this!</div>
<div><br>
</div>
<div>The only literature I had found on this (I have to admit that I did not spend much time on research) was this one: <a href="https://wiki.squeak.org/squeak/uploads/2074/sandbox.pdf" id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203LPlnk71614" target="_blank">https://wiki.squeak.org/squeak/uploads/2074/sandbox.pdf</a> It
 mentions a number of problems but does not come up with a simulation solution, so it would exclusively lock your image, I guess.</div>
<div><br>
</div>
<div>> <span style="font-size:12pt">I expect efficiency to improve if VM (e.g. object memory) exposes </span><span style="font-size:12pt">primitives for object spaces with copy-on-write and white-outs (for </span><span style="font-size:12pt">objects finalized
 in child space but not in parent). A sandbox could </span><span style="font-size:12pt">carve out an object space to hold modified/deleted objects and then </span><span style="font-size:12pt">either commit to parent or dispose it off on close. ObjectMemory
 already </span><span style="font-size:12pt">has support for multiple spaces (e.g. old and young). It needs to be </span><span style="font-size:12pt">exposed, with lots of care, to ST-side code.</span>
<div><br>
</div>
<div>Yeah, integrating the sandbox partially into the VM would make things faster, of course ... I haven't made any attempts in this direction for two reasons: First because I, honestly, still did not find the time for getting started with VMMaker, and second
 because while I know that the VM is written in a Smalltalk dialect as well, it hurts me a bit that it lacks the liveness of manipulating everything from within the running image. By the way, is there already some research about unioning these two worlds in
 order to reprogram the VM from within the image that is running in it? I would love this.</div>
<div><br>
</div>
<div>What are white-outs? I could not find any reference on this.</div>
<div><br>
</div>
<div>> <span style="font-size:12pt">Handling primitives, particularly those that involve physical i/o, is a </span><span style="font-size:12pt">difficult problem. This is typically solved by using virtualization and </span><span style="font-size:12pt">double
 buffering (e.g. display or input). It is ok to work with </span><span style="font-size:12pt">non-volatile state variables for the first cut and then introduce </span><span style="font-size:12pt">virtualization for transactional access.</span>
<div><br>
</div>
<div>Actually, my current Sandbox approach does not even intend to "commit" changes back to the rest of the image (rather to work like a Docker container in small). Thus my goal would rather be to virtualize all physical operations but keeping the effects back
 from the real physical devices. For filesystem accesses, for example, I thought about redirecting all write operations to a copy of the files in a special folder ... Not sure how far this approach would work well, though.</div>
<div><br>
</div>
<div>For some I/O primitives, however, virtualization is rather easy. For example, when writing on the global Display, you can simply copy this object like any other object into your sandbox space/world. However, other primitives, such as from the FilePlugin,
 operate on state is managed outside of the image ...</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</div>
</div>
<p></p>
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203x_Signature">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-157474847966763270gmail-m_7713874217196969238gmail-m_-3942506173242290203x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von K K Subbu <<a href="mailto:kksubbu.ml@gmail.com" target="_blank">kksubbu.ml@gmail.com</a>><br>
<b>Gesendet:</b> Dienstag, 16. März 2021 14:21:16<br>
<b>An:</b> <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
<b>Betreff:</b> Re: [squeak-dev] [ANN] SimulationStudio and sandboxed execution for Squeak</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div><br>
On 16/03/21 4:51 pm, Thiede, Christoph wrote:<br>
> Hi all! :-)<br>
> <br>
> <br>
> I'm very excited to finally share my new project with you today, which I <br>
> call *SimulationStudio* and have made available on GitHub under [1]. Its <br>
> primary function is to provide an inheritable <br>
> *SimulationContext* subclass of Context that makes it easy to simulate <br>
> entire call trees while customizing the execution or installing custom <br>
> hooks for various tracing and measurement purposes. Another <br>
> accomplishment is the *Sandbox* which allows you to run arbitrary <br>
> Smalltalk code in an isolated environment, separating any side effects <br>
> that occur during the simulation from the rest of the image.<br>
<br>
This is an amazing development!<br>
<br>
I am not sure if you have read Warth's research at VPRI:<br>
<br>
World: Controlling the Scope of Side Effects by A Warth et. all,<br>
<br>
 <br>
<a href="https://www.researchgate.net/publication/221496497_Worlds_Controlling_the_Scope_of_Side_Effects" target="_blank">https://www.researchgate.net/publication/221496497_Worlds_Controlling_the_Scope_of_Side_Effects</a><br>
<br>
Worlds is like your Sandbox. It also had a commit method to propagate <br>
state changes from the child to the parent. This is useful when a method <br>
modifies multiple state variables subject to strong invariants. A method <br>
may open a World, make changes and then verify invariants are preserved <br>
before committing the changes and closing the World.<br>
<br>
> *Limitations and challenges*<br>
> <br>
> Well, first of all ... *performance.* :-) Some recent measurements that <br>
> I have run have shown that the simulator reaches about 0.1 percent (sic) <br>
> of the speed of the VM executor, depending on the domain and the <br>
> distribution of bytecode operations.<br>
<br>
I expect efficiency to improve if VM (e.g. object memory) exposes <br>
primitives for object spaces with copy-on-write and white-outs (for <br>
objects finalized in child space but not in parent). A sandbox could <br>
carve out an object space to hold modified/deleted objects and then <br>
either commit to parent or dispose it off on close. ObjectMemory already <br>
has support for multiple spaces (e.g. old and young). It needs to be <br>
exposed, with lots of care, to ST-side code.<br>
<br>
> Another challenge is the *handling of primitive operations* during the <br>
> sandbox execution.<br>
<br>
Handling primitives, particularly those that involve physical i/o, is a <br>
difficult problem. This is typically solved by using virtualization and <br>
double buffering (e.g. display or input). It is ok to work with <br>
non-volatile state variables for the first cut and then introduce <br>
virtualization for transactional access.<br>
<br>
Regards .. Subbu<br>
<br>
</div>
</span></font></div>
</div>

<br>
</blockquote></div></div>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">-- Yoshiki<div><br></div></div>