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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210316/bc660974/attachment.html>