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