It is great to hear that image is working there.

Yes, in the current implementation, things have to use the custom compiler
to hook the action. It is, though, conceivable to make Object be
Worlds-aware and all objects would behave that way...  (including the data
structure that supports the Worlds mechanism, or not!), except all
primitives that simply write data into objects.

The JS implementation is a bit different and it compiles a given program
into a Worlds-aware form.

Aran Lunzer found that the simple approach has some unexpected behavior,
and he and I wrote a report on it and how to mitigate it. It might be of
your interest:

http://www.vpri.org/pdf/m2013002_experiments.pdf


On Wed, Mar 17, 2021 at 6:29 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Marcel,
>
>
> ah, that was missing! Thank you. :-)
>
> Some first impressions of the Worlds implementation for Squeak: If I
> understand correctly, it only works with objects that explicitly support
> the worlds mechanism. So for example:
>
> z := #(1).
> world := WWorld thisWorld sprout.
> {world eval: [
> z at: 1 put: 2.
> z].
> z}  "==> #(#(2) #(2))
>
> Sandbox would answer:
>
> z := #(1).
> {Sandbox evaluate: [
> z at: 1 put: 2.
> z].
> z}  "==>  #(#(2) #(1))"
>
> For Worlds, I apparently would need to use a specialized WArray instead.
> This has the advantage of being much faster than Sandbox but also the
> disadvantage of not fitting for general-purpose Smalltalk expressions.
> Still, a very interesting approach!
>
> Best,
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Mittwoch, 17. März 2021 14:12:12
> *An:* squeak-dev
> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
> execution for Squeak
>
> Hi Christoph.
>
> > How am I supposed to tell the VM which image file to load? It always
> wants to open the Squeak4.4-12327.image file only.
>
> Change the .ini file :-) Remove the hard-coded path in there.
>
> > The message above is a result of replacing the default image and
> changes file in the AllInOne bundle with frank.image and frank.changes.
>
> I suppose you need the other DLLs and resources, too? What I tried was to
> copy the VM files over to the contents from the ZIP file. That worked. :-)
>
> Best,
> Marcel
>
> Am 17.03.2021 14:06:05 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi Marcel,
>
>
> it's not working for me:
>
>
> ---------------------------
> Squeak!
> ---------------------------
> Could not open the Squeak image file
> 'C:\Users\Christoph\OneDrive\Downloads\Squeak-4.4-All-in-One\Squeak-4.4-All-in-One.app\Contents\Resources\Squeak4.4-12327.image'
>
> There are several ways to open an image file. You can:
>   1. Double-click on the desired image file.
>   2. Drop the image file onto the application.
> Aborting...
>
> ---------------------------
> OK
> ---------------------------
>
> How am I supposed to tell the VM which image file to load? It always wants
> to open the Squeak4.4-12327.image file only. Dropping another image file on
> the executable only gives me a load error from within the 4.4 image. The
> message above is a result of replacing the default image and changes file
> in the AllInOne bundle with frank.image and frank.changes.
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Mittwoch, 17. März 2021 09:13:04
> *An:* squeak-dev
> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
> execution for Squeak
>
> Hi Christoph.
>
> > Hm, the 4.1 4.2 4.3 VMs refuse to open this image. I also tried to load
> Grease-yo.69.mcz into a fresh 4.2 image but it hangs up as well.
>
> Frank-170908 is based on Squeak 4.4 alpha. The VM from the Squeak 4.4
> release works fine under Windows 10: http://files.squeak.org/4.4/
>
> Best,
> Marcel
>
> Am 17.03.2021 01:36:08 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hm, the 4.1 4.2 4.3 VMs refuse to open this image. I also tried to load
> Grease-yo.69.mcz into a fresh 4.2 image but it hangs up as well.
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
> *Gesendet:* Mittwoch, 17. März 2021 01:02:26
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
> execution for Squeak
>
> It was created on Squeak4.2, Squeak4.4, etc.  I think this one has stuff
> preloaded:
>
> tinlizzie.org/~ohshima/Frank-170908.zip
>
> And you need to find a VM something along the line of:
>
>  'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog
> 4.0.0'
>
> Let me (us) know if you have more questions!
>
> On Tue, Mar 16, 2021 at 4:39 PM Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>
>> My image hangs when loading Greases ... Can you recommend an older
>> version of Squeak which is officially supported? :-)
>>
>>
>> Best,
>>
>> Christoph
>> <http://www.hpi.de/>
>> ------------------------------
>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>> Auftrag von Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>> *Gesendet:* Mittwoch, 17. März 2021 00:20:53
>> *An:* The general-purpose Squeak developers list
>> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
>> execution for Squeak
>>
>> W2Compiler, right? It took sometime to dig it up but it is in the Grease
>> package in the directory.  The main things is to compile AssingmentNode
>> into a message call, and to avoid conflict such accessors were prefiexed
>> with "wiv666" ("world instance variable 666") The majority of job is done
>> by the W2Parser.
>>
>> On Tue, Mar 16, 2021 at 3:55 PM Thiede, Christoph <
>> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>
>>> Thanks! Unfortunately, it's referring to a WCompiler which apparently is
>>> not part of the mcz file ...
>>>
>>>
>>> Best,
>>>
>>> Christoph
>>> <http://www.hpi.de/>
>>> ------------------------------
>>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>> Auftrag von Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>>> *Gesendet:* Dienstag, 16. März 2021 23:48:52
>>> *An:* Vanessa Freudenberg
>>> *Cc:* The general-purpose Squeak developers list
>>> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
>>> execution for Squeak
>>>
>>> Hi!
>>>
>>> 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.
>>>
>>> http://tinlizzie.org/updates/exploratory/packages/
>>>
>>> On Tue, Mar 16, 2021 at 1:59 PM Vanessa Freudenberg <
>>> vanessa at codefrau.net> wrote:
>>>
>>>> On Tue, Mar 16, 2021 at 9:52 AM Thiede, Christoph <
>>>> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>>>
>>>>> 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 ...
>>>>>
>>>> Well luckily one of the authors is still on this list ...
>>>>
>>>> Looks really interesting and useful!
>>>>
>>>> Vanessa
>>>>
>>>>> Best,
>>>>>
>>>>> Christoph
>>>>> <http://www.hpi.de/>
>>>>> ------------------------------
>>>>> *Von:* Thiede, Christoph
>>>>> *Gesendet:* Dienstag, 16. März 2021 15:10:37
>>>>> *An:* squeak-dev at lists.squeakfoundation.org
>>>>> *Betreff:* AW: [squeak-dev] [ANN] SimulationStudio and sandboxed
>>>>> execution for Squeak
>>>>>
>>>>>
>>>>> Hi Subbu, thanks a lot for your thoughts! :-)
>>>>>
>>>>>
>>>>> > I am not sure if you have read Warth's research at VPRI
>>>>>
>>>>>
>>>>> No, I have not. Looks very interesting, I will read this!
>>>>>
>>>>> The only literature I had found on this (I have to admit that I did
>>>>> not spend much time on research) was this one:
>>>>> https://wiki.squeak.org/squeak/uploads/2074/sandbox.pdf It mentions a
>>>>> number of problems but does not come up with a simulation solution, so it
>>>>> would exclusively lock your image, I guess.
>>>>>
>>>>> > I expect efficiency to improve if VM (e.g. object memory) exposes primitives
>>>>> for object spaces with copy-on-write and white-outs (for objects
>>>>> finalized in child space but not in parent). A sandbox could carve
>>>>> out an object space to hold modified/deleted objects and then either
>>>>> commit to parent or dispose it off on close. ObjectMemory already has
>>>>> support for multiple spaces (e.g. old and young). It needs to be exposed,
>>>>> with lots of care, to ST-side code.
>>>>>
>>>>> 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.
>>>>>
>>>>> What are white-outs? I could not find any reference on this.
>>>>>
>>>>> > Handling primitives, particularly those that involve physical i/o,
>>>>> is a difficult problem. This is typically solved by using
>>>>> virtualization and double buffering (e.g. display or input). It is ok
>>>>> to work with non-volatile state variables for the first cut and then
>>>>> introduce virtualization for transactional access.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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 ...
>>>>>
>>>>> Best,
>>>>> Christoph
>>>>>
>>>>> ------------------------------
>>>>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>>>> Auftrag von K K Subbu <kksubbu.ml at gmail.com>
>>>>> *Gesendet:* Dienstag, 16. März 2021 14:21:16
>>>>> *An:* squeak-dev at lists.squeakfoundation.org
>>>>> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
>>>>> execution for Squeak
>>>>>
>>>>>
>>>>> On 16/03/21 4:51 pm, Thiede, Christoph wrote:
>>>>> > Hi all! :-)
>>>>> >
>>>>> >
>>>>> > I'm very excited to finally share my new project with you today,
>>>>> which I
>>>>> > call *SimulationStudio* and have made available on GitHub under [1].
>>>>> Its
>>>>> > primary function is to provide an inheritable
>>>>> > *SimulationContext* subclass of Context that makes it easy to
>>>>> simulate
>>>>> > entire call trees while customizing the execution or installing
>>>>> custom
>>>>> > hooks for various tracing and measurement purposes. Another
>>>>> > accomplishment is the *Sandbox* which allows you to run arbitrary
>>>>> > Smalltalk code in an isolated environment, separating any side
>>>>> effects
>>>>> > that occur during the simulation from the rest of the image.
>>>>>
>>>>> This is an amazing development!
>>>>>
>>>>> I am not sure if you have read Warth's research at VPRI:
>>>>>
>>>>> World: Controlling the Scope of Side Effects by A Warth et. all,
>>>>>
>>>>>
>>>>>
>>>>> https://www.researchgate.net/publication/221496497_Worlds_Controlling_the_Scope_of_Side_Effects
>>>>>
>>>>> Worlds is like your Sandbox. It also had a commit method to propagate
>>>>> state changes from the child to the parent. This is useful when a
>>>>> method
>>>>> modifies multiple state variables subject to strong invariants. A
>>>>> method
>>>>> may open a World, make changes and then verify invariants are
>>>>> preserved
>>>>> before committing the changes and closing the World.
>>>>>
>>>>> > *Limitations and challenges*
>>>>> >
>>>>> > Well, first of all ... *performance.* :-) Some recent measurements
>>>>> that
>>>>> > I have run have shown that the simulator reaches about 0.1 percent
>>>>> (sic)
>>>>> > of the speed of the VM executor, depending on the domain and the
>>>>> > distribution of bytecode operations.
>>>>>
>>>>> I expect efficiency to improve if VM (e.g. object memory) exposes
>>>>> primitives for object spaces with copy-on-write and white-outs (for
>>>>> objects finalized in child space but not in parent). A sandbox could
>>>>> carve out an object space to hold modified/deleted objects and then
>>>>> either commit to parent or dispose it off on close. ObjectMemory
>>>>> already
>>>>> has support for multiple spaces (e.g. old and young). It needs to be
>>>>> exposed, with lots of care, to ST-side code.
>>>>>
>>>>> > Another challenge is the *handling of primitive operations* during
>>>>> the
>>>>> > sandbox execution.
>>>>>
>>>>> Handling primitives, particularly those that involve physical i/o, is
>>>>> a
>>>>> difficult problem. This is typically solved by using virtualization
>>>>> and
>>>>> double buffering (e.g. display or input). It is ok to work with
>>>>> non-volatile state variables for the first cut and then introduce
>>>>> virtualization for transactional access.
>>>>>
>>>>> Regards .. Subbu
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> -- Yoshiki
>>>
>>>
>>>
>>
>> --
>> -- Yoshiki
>>
>>
>>
>
> --
> -- Yoshiki
>
>
>

-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210317/b7d5426a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 158298 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210317/b7d5426a/attachment-0001.jpg>