Smalltalk › Squeak › Squeak - Dev

MorphicProject subclass: #EtoysProject

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

74 messages Options

1234

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

On 10/19/17, Marcel Taeumel <[hidden email]> wrote:
> Nice! Seems to work somehow. Graphics are kind of messed up:
>
>
> Still, it is running. It reacts to user input. :)
>
> Best,
> Marcel

Thank you for the test, Marcel.

Good confirmation in terms of Etoys. :-)

I do not have the issue with the graphics display, see screen shot of
the the test I did in Ubuntu 14.04.
Let's move the discussion about the graphics to a separate thread and
do more tests.

--Hannes

> Am 19.10.2017 08:48:20 schrieb H. Hirzel <[hidden email]>:
> Update: It is now possible to load a project such as home.pr into the
> 6.0a trunk image.
> Drop a pr file (downloaded from
> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
> desktop and it loads without blocking. This is due to fixes done this
> month so far.
>
> The following notes are written in a way that you can jump in helping
> to finalize Etoys project loading and setup without having read the
> earlier messages in this thread.
>
>
>
> Issues:
>
>
> 1. Walkback window left on screen after loading
> --------------------------------------------------------------------
>
> A walk-back window still comes up after home.pr has been loaded.
> The reason for this still needs to be found out. But just closing the
> window does not seem to have a negative effect to the functioning of
> the etoys project.
>
>
>
>
> 2. Etoys tiles (TileMorph)
> ------------------------------------
>
> Incrementing and decrementing values in tiles has been fixed so that
> it is possible to use the project. It was a problem related to the
> Environment code.
>
> More tests using the tiles are needed to see if there are more
> problems such as this.
>
>
>
>
> 3. Loading pr files
> ---------------------------
>
> Please help testing with loading different pr files. Other loading
> problems are likely to come up. Focus on projects created with Etoys5.
> ( http://squeakland.org/download/).
>
> Etoys 5.0 uses the image format 6502
> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
> in Smalltalk code (not VM code) in 6.0a trunk (class
> LegacyImageSegment / ImageSegmentLoader). [1]
>
> SmartRefStream does the conversion of the loaded objects if necessary.
>
>
>
>
> 4. Cleanup of a loaded project
> -------------------------------------------
>
> A loaded project is not yet properly set up. The button 'previous
> project' does not work.
>
> To fix this
>
> EtoysProject >> #finalEnterActions:
>
> needs to be set up.
>
> The call
>
> self world actionMap removeKey: #aboutToLeaveWorld
>
> as discussed earlier in this thread is one a cleanup actions to be here.
>
>
> When loading a pr file an instance of MorphicProject is created as
> currently
>
> MorphicProject->EtoysProject
>
> has not been mapped yet in SmartRefStream initKnownRenames. This needs
> to be done.
>
>
> --Hannes
>
>
>
> -------------------------------------------------------------
>
> [1] There are quite a number of etoys pr files around which are not in
> the 6502 format.
> http://wiki.squeak.org/squeak/6502
>
> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
> are probably necessary.
>
> On 10/14/17, Marcel Taeumel wrote:
>> Hi Hannes,
>>
>> if you have project instances that need clean-up, you can put that code
>> at
>> one of several checkpoints:
>>
>> - entering a project (EtoysProject >> #finalEnterActions:)
>> - leaving a project (EtoysProject >> #finalExitActions:)
>> - loading/merging a Monticello package (see postLoad scripts)
>> - quitting the Squeak image (EtoysProject class >> #shutDown:)
>> - resuming the Squeak image (EtoysProject class >> #startUp:)
>> - loading a ChangeSet (see postLoad scripts)
>>
>> Or if you plan to persist Etoys project in the file system, clean them up
>> manually (e.g. with a workspace and object inspector) and write the clean
>> version back to disk for everybody to share.
>>
>> Best,
>> Marcel
>>
>> Am 14.10.2017 12:21:20 schrieb H. Hirzel :
>> Thank you Dave for reviewing and merging and committing
>> Morphic-hjh.1349.mcz.
>>
>> One of the next issues is that the loaded Etoys project has a key
>>
>> #aboutToLeaveWorld
>>
>> in the actionMap which causes an error message to appear when leaving
>> the project.
>>
>> Executing
>>
>> Project current world actionMap removeKey: #aboutToLeaveWorld
>>
>> or just
>>
>> self world actionMap removeKey: #aboutToLeaveWorld
>>
>> if not called from a workspace
>>
>> solves that problem.
>>
>> But I am not sure if this is the right thing to do and where to put this.
>>
>> The event mechanism is not used much in Squeak6.0a. (see thread:
>> 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
>> need to do?', in particular answer by Bob Arning')
>>
>>
>> Another issue is that
>>
>> SugarNavigatorBar showSugarNavigator: true.
>>
>> needs to be called.
>>
>>
>> A third question: In which directory should the three projects to preload
>> stay?
>> ( Section 3 on http://wiki.squeak.org/squeak/6531)
>>
>> Smalltalk imagePath
>>
>> ?
>>
>>
>> --Hannes
>>
>> On 10/13/17, H. Hirzel wrote:
>>> Thank you Bert for the links to the regular three projects (home,
>>> gallery, tutorials) and the background information.
>>>
>>>
>>> Update
>>> -----------
>>>
>>> for the most recent trunk image Squeak6.0a-17417 with
>>> Morphic-hjh.1349.mcz loaded manually from the inbox:
>>>
>>>
>>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
>>>
>>> loads, and works but brings up an error window regarding a #script1.
>>>
>>> The car is moving around.
>>>
>>> To leave the project you need to open a workspace and paste and execute
>>> Project current world actionMap removeKey: #aboutToLeaveWorld
>>>
>>> The menu entry 'previous project' works fine.
>>>
>>> - Hannes -
>>>
>>> On 10/10/17, Bert Freudenberg wrote:
>>>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
>>>> wrote:
>>>>
>>>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>>>>> > It's all class-based. E.g. if the shape of a class changed (new /
>>>>> > renamed
>>>>> > inst vars) that class can provide a "conversion method" that creates
>>>>> > an
>>>>> > instance with the new layout from the old inst vars (that are loaded
>>>>> > as
>>>>> > a
>>>>> > dictionary). There still is a preference
>>>>> > (conversionMethodsAtFileOut)
>>>>> that
>>>>> > used to prompt people to provide these conversion methods when they
>>>>> changed
>>>>> > a class. But it didn't survive the transition to Monticello, we now
>>>>> > have
>>>>> to
>>>>> > remember to write conversion methods for instances that may be
>>>>> > stored
>>>>> > in
>>>>> a
>>>>> > project.
>>>>>
>>>>> To check my understanding, the "conversion method" might be something
>>>>> like
>>>>> #storeDataOn: and #readDataFrom:size: like what I described for
>>>>> DateAndTime,
>>>>> is that right?
>>>>>
>>>>
>>>> No, it's those weirdly-named methods like Hannes just made
>>>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
>>>> per-object.
>>>> This
>>>> would have been too expensive back in the interpreter days on slow
>>>> CPUs,
>>>> that's why the project is stored as an image-segment, and the segment
>>>> is
>>>> written to a SmartRefStream with its out-pointers (references to
>>>> objects
>>>> outside the segment, e.g. classes).
>>>>
>>>> The SmartRefStream is only used to resolve the class references from
>>>> the
>>>> ImageSegment that stores the project.
>>>>
>>>>> This is different from the Etoys home screen (the clouds and
>>>>> drive-a-car)
>>>>> > which is simply a project that would be loaded by the deployment
>>>>> > script
>>>>> > that creates an Etoys image. It does not have to ship with the
>>>>> > general
>>>>> > Squeak image.
>>>>>
>>>>> I do not know if it will make sense, but I guess my mental image is an
>>>>> Etoys "deployed image" hosted inside my regular Squeak trunk image. So
>>>>> I
>>>>> guess that I am thinking of the "clouds and drive-a-car" project being
>>>>> loaded the first time that I create a new EtoysProject from normal
>>>>> Squeak,
>>>>> and that somehow the subsequent project navigation within that new
>>>>> "hosted"
>>>>> Etoys would behave is if I were in a stand-alone Etoys image. Finally,
>>>>> I would want to be able to escape back to my normal Squeak.
>>>>
>>>>
>>>> That sounds good :)
>>>>
>>>> - Bert -
>>>>
>>>
>>
>>
>
>

Etoys_after_dropping_home.pr_to_desktop_Sq6.0a-17429_ubuntu14.04_2017-10-19.png (101K) Download Attachment

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

In reply to this post by Hannes Hirzel

Hannes,

Thank you for this summary, it helps a lot. I can load the project,
and I note that my VM crashes fairly often when playing with this, so
that that will give me something to look into :-)

I don't have time to look further now, but the (old) VM I am using at
the moment is:

/usr/local/lib/squeak/5.0-201608171728-64/squeak
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919]
Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700
$ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016

Dave

On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:

> Update: It is now possible to load a project such as home.pr into the
> 6.0a trunk image.
> Drop a pr file (downloaded from
> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
> desktop and it loads without blocking. This is due to fixes done this
> month so far.
>
> The following notes are written in a way that you can jump in helping
> to finalize Etoys project loading and setup without having read the
> earlier messages in this thread.
>
>
>
> Issues:
>
>
> 1. Walkback window left on screen after loading
> --------------------------------------------------------------------
>
> A walk-back window still comes up after home.pr has been loaded.
> The reason for this still needs to be found out. But just closing the
> window does not seem to have a negative effect to the functioning of
> the etoys project.
>
>
>
>
> 2. Etoys tiles (TileMorph)
> ------------------------------------
>
> Incrementing and decrementing values in tiles has been fixed so that
> it is possible to use the project. It was a problem related to the
> Environment code.
>
> More tests using the tiles are needed to see if there are more
> problems such as this.
>
>
>
>
> 3. Loading pr files
> ---------------------------
>
> Please help testing with loading different pr files. Other loading
> problems are likely to come up. Focus on projects created with Etoys5.
> ( http://squeakland.org/download/).
>
> Etoys 5.0 uses the image format 6502
> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
> in Smalltalk code (not VM code) in 6.0a trunk (class
> LegacyImageSegment / ImageSegmentLoader). [1]
>
> SmartRefStream does the conversion of the loaded objects if necessary.
>
>
>
>
> 4. Cleanup of a loaded project
> -------------------------------------------
>
> A loaded project is not yet properly set up. The button 'previous
> project' does not work.
>
> To fix this
>
> EtoysProject >> #finalEnterActions:
>
> needs to be set up.
>
> The call
>
> self world actionMap removeKey: #aboutToLeaveWorld
>
> as discussed earlier in this thread is one a cleanup actions to be here.
>
>
> When loading a pr file an instance of MorphicProject is created as currently
>
> MorphicProject->EtoysProject
>
> has not been mapped yet in SmartRefStream initKnownRenames. This needs
> to be done.
>
>
> --Hannes
>
>
>
> -------------------------------------------------------------
>
> [1] There are quite a number of etoys pr files around which are not in
> the 6502 format.
> http://wiki.squeak.org/squeak/6502
>
> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
> are probably necessary.
>
> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
> > Hi Hannes,
> >
> > if you have project instances that need clean-up, you can put that code at
> > one of several checkpoints:
> >
> > - entering a project (EtoysProject >> #finalEnterActions:)
> > - leaving a project (EtoysProject >> #finalExitActions:)
> > - loading/merging a Monticello package (see postLoad scripts)
> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
> > - resuming the Squeak image (EtoysProject class >> #startUp:)
> > - loading a ChangeSet (see postLoad scripts)
> >
> > Or if you plan to persist Etoys project in the file system, clean them up
> > manually (e.g. with a workspace and object inspector) and write the clean
> > version back to disk for everybody to share.
> >
> > Best,
> > Marcel
> >
> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
> > Thank you Dave for reviewing and merging and committing
> > Morphic-hjh.1349.mcz.
> >
> > One of the next issues is that the loaded Etoys project has a key
> >
> > #aboutToLeaveWorld
> >
> > in the actionMap which causes an error message to appear when leaving
> > the project.
> >
> > Executing
> >
> > Project current world actionMap removeKey: #aboutToLeaveWorld
> >
> > or just
> >
> > self world actionMap removeKey: #aboutToLeaveWorld
> >
> > if not called from a workspace
> >
> > solves that problem.
> >
> > But I am not sure if this is the right thing to do and where to put this.
> >
> > The event mechanism is not used much in Squeak6.0a. (see thread:
> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
> > need to do?', in particular answer by Bob Arning')
> >
> >
> > Another issue is that
> >
> > SugarNavigatorBar showSugarNavigator: true.
> >
> > needs to be called.
> >
> >
> > A third question: In which directory should the three projects to preload
> > stay?
> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
> >
> > Smalltalk imagePath
> >
> > ?
> >
> >
> > --Hannes
> >
> > On 10/13/17, H. Hirzel wrote:
> >> Thank you Bert for the links to the regular three projects (home,
> >> gallery, tutorials) and the background information.
> >>
> >>
> >> Update
> >> -----------
> >>
> >> for the most recent trunk image Squeak6.0a-17417 with
> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
> >>
> >>
> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
> >>
> >> loads, and works but brings up an error window regarding a #script1.
> >>
> >> The car is moving around.
> >>
> >> To leave the project you need to open a workspace and paste and execute
> >> Project current world actionMap removeKey: #aboutToLeaveWorld
> >>
> >> The menu entry 'previous project' works fine.
> >>
> >> - Hannes -
> >>
> >> On 10/10/17, Bert Freudenberg wrote:
> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
> >>> wrote:
> >>>
> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
> >>>> > It's all class-based. E.g. if the shape of a class changed (new /
> >>>> > renamed
> >>>> > inst vars) that class can provide a "conversion method" that creates
> >>>> > an
> >>>> > instance with the new layout from the old inst vars (that are loaded
> >>>> > as
> >>>> > a
> >>>> > dictionary). There still is a preference (conversionMethodsAtFileOut)
> >>>> that
> >>>> > used to prompt people to provide these conversion methods when they
> >>>> changed
> >>>> > a class. But it didn't survive the transition to Monticello, we now
> >>>> > have
> >>>> to
> >>>> > remember to write conversion methods for instances that may be stored
> >>>> > in
> >>>> a
> >>>> > project.
> >>>>
> >>>> To check my understanding, the "conversion method" might be something
> >>>> like
> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
> >>>> DateAndTime,
> >>>> is that right?
> >>>>
> >>>
> >>> ???No, it's those weirdly-named methods like Hannes just made
> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
> >>> per-object.
> >>> This
> >>> would have been too expensive back in the interpreter days on slow CPUs,
> >>> that's why the project is stored as an image-segment, and the segment is
> >>> written to a SmartRefStream with its out-pointers (references to objects
> >>> outside the segment, e.g. classes).
> >>>
> >>> The SmartRefStream is only used to resolve the class references from the
> >>> ImageSegment that stores the project.
> >>>
> >>>> This is different from the Etoys home screen (the clouds and
> >>>> drive-a-car)
> >>>> > which is simply a project that would be loaded by the deployment
> >>>> > script
> >>>> > that creates an Etoys image. It does not have to ship with the
> >>>> > general
> >>>> > Squeak image.
> >>>>
> >>>> I do not know if it will make sense, but I guess my mental image is an
> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk image. So
> >>>> I
> >>>> guess that I am thinking of the "clouds and drive-a-car" project being
> >>>> loaded the first time that I create a new EtoysProject from normal
> >>>> Squeak,
> >>>> and that somehow the subsequent project navigation within that new
> >>>> "hosted"
> >>>> Etoys would behave is if I were in a stand-alone Etoys image. Finally,
> >>>> I would want to be able to escape back to my normal Squeak.
> >>>
> >>>
> >>> ???That sounds good :)
> >>>
> >>> - Bert -???
> >>>
> >>
> >
> >
>

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

In reply to this post by Bert Freudenberg

On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:

> On Fri, Oct 6, 2017 at 2:44 PM, David T. Lewis <[hidden email]> wrote:
>
> >
> > So we might have some kind of rule in project loading that says "if
> > the current project is an EtoysProject, and if I am loading a *.pr for
> > a MorphicProject, then make it an EtoysProject". And perhaps when saving
> > a project, we could reverse the rule and always save a project as
> > MorphicProject, because we know that a loader in EtoysProject will know
> > how to do the right thing with it.
> >
>
> ???Actually, projects saved from the Squeakland image store a class named
> "Project???". Since this has been made abstract now, we instead load it as
> MorphicProject.
>
> ???The logic is mostly in SmartRefStream, in this case, #initKnownRenames.
>

I decided to play around with this a bit, and put some experimental updates
in the http://www.squeaksource.com/EtoysProject repository. This allows a
project file to be dropped into an EtoysProject, and the resulting new project
will be EtoysProject rather than MorphicProject. When transitioning from an
EtoysProject to something else (usually a MorphicProject), the Etoys-specific
preference overrides are restored to normal. When moving from one EtoysProject
to another, the preference overrides should stay in effect.

Dropping a project file into a MorphicProject still creates a new MorphicProject
as before.

I'm not sure this is a good idea, and it is surely going to be full of bugs,
but it does seem to work.

The updates:

Name: Collections-dtl.765
Author: dtl
Time: 21 October 2017, 7:44:28.846825 pm
UUID: 0109fe1c-9f9b-4826-ab6b-dac5db14ba18
Ancestors: Collections-topa.764

Assuming that the object saved as a Dictionary value may be any object that
responds to #value (i.e. a block), implement keyAtEvaluatedValue: to look
up the key corresponding the the evaluated object.

Name: System-dtl.970
Author: dtl
Time: 21 October 2017, 7:51:39.874717 pm
UUID: 90db9247-00c0-4f0d-a205-c7121125b971
Ancestors: System-dtl.969

The #renamed dictionary of a SmartReferenceStream maps a serialized class,
such as Project, to the expected class to be used for materialization, such
as MorphicProject. In some cases it may be desirable to let the mapping choice
be decided at load time. Therefore, let the value stored in #renamed be
either a symbol or a block. If it is a block, evaluated it to determine the
new mapped class. For example, if EtoysProject is a specialized implementation
of MorphicProject, then it may be desirable to map a saved Project to a new
EtoysProject rather than a new MorphicProject.

Name: Project-Etoys-dtl.2
Author: dtl
Time: 21 October 2017, 7:55:23.65049 pm
UUID: 7a7f7f95-c623-4024-be85-af380d03ca4f
Ancestors: Project-Etoys-dtl.1

Restore saved global preferences only if the project being entered is not
an EtoysProject. Thus retain the preference overrides while moving from one
EtoysProject to another.

Dave

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

In reply to this post by David T. Lewis

On 10/19/17, David T. Lewis <[hidden email]> wrote:
> Hannes,
>
> Thank you for this summary, it helps a lot. I can load the project,

Dave,
that implies that you do not have the graphics problem Marcel
encountered, is this correct?

> and I note that my VM crashes fairly often when playing with this, so
> that that will give me something to look into :-)
>
> I don't have time to look further now, but the (old) VM I am using at
> the moment is:
>
> /usr/local/lib/squeak/5.0-201608171728-64/squeak
> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919]
> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
> platform sources revision VM: 201608171728
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17
> 10:28:01 2016 -0700
> $ Plugins: 201608171728
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-cb.1919 uuid:
> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid:
> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>
>
> Dave
>
>
>
> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
>> Update: It is now possible to load a project such as home.pr into the
>> 6.0a trunk image.
>> Drop a pr file (downloaded from
>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
>> desktop and it loads without blocking. This is due to fixes done this
>> month so far.
>>
>> The following notes are written in a way that you can jump in helping
>> to finalize Etoys project loading and setup without having read the
>> earlier messages in this thread.
>>
>>
>>
>> Issues:
>>
>>
>> 1. Walkback window left on screen after loading
>> --------------------------------------------------------------------
>>
>> A walk-back window still comes up after home.pr has been loaded.
>> The reason for this still needs to be found out. But just closing the
>> window does not seem to have a negative effect to the functioning of
>> the etoys project.
>>
>>
>>
>>
>> 2. Etoys tiles (TileMorph)
>> ------------------------------------
>>
>> Incrementing and decrementing values in tiles has been fixed so that
>> it is possible to use the project. It was a problem related to the
>> Environment code.
>>
>> More tests using the tiles are needed to see if there are more
>> problems such as this.
>>
>>
>>
>>
>> 3. Loading pr files
>> ---------------------------
>>
>> Please help testing with loading different pr files. Other loading
>> problems are likely to come up. Focus on projects created with Etoys5.
>> ( http://squeakland.org/download/).
>>
>> Etoys 5.0 uses the image format 6502
>> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
>> in Smalltalk code (not VM code) in 6.0a trunk (class
>> LegacyImageSegment / ImageSegmentLoader). [1]
>>
>> SmartRefStream does the conversion of the loaded objects if necessary.
>>
>>
>>
>>
>> 4. Cleanup of a loaded project
>> -------------------------------------------
>>
>> A loaded project is not yet properly set up. The button 'previous
>> project' does not work.
>>
>> To fix this
>>
>> EtoysProject >> #finalEnterActions:
>>
>> needs to be set up.
>>
>> The call
>>
>> self world actionMap removeKey: #aboutToLeaveWorld
>>
>> as discussed earlier in this thread is one a cleanup actions to be here.
>>
>>
>> When loading a pr file an instance of MorphicProject is created as
>> currently
>>
>> MorphicProject->EtoysProject
>>
>> has not been mapped yet in SmartRefStream initKnownRenames. This needs
>> to be done.
>>
>>
>> --Hannes
>>
>>
>>
>> -------------------------------------------------------------
>>
>> [1] There are quite a number of etoys pr files around which are not in
>> the 6502 format.
>> http://wiki.squeak.org/squeak/6502
>>
>> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
>> are probably necessary.
>>
>> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
>> > Hi Hannes,
>> >
>> > if you have project instances that need clean-up, you can put that code
>> > at
>> > one of several checkpoints:
>> >
>> > - entering a project (EtoysProject >> #finalEnterActions:)
>> > - leaving a project (EtoysProject >> #finalExitActions:)
>> > - loading/merging a Monticello package (see postLoad scripts)
>> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
>> > - resuming the Squeak image (EtoysProject class >> #startUp:)
>> > - loading a ChangeSet (see postLoad scripts)
>> >
>> > Or if you plan to persist Etoys project in the file system, clean them
>> > up
>> > manually (e.g. with a workspace and object inspector) and write the
>> > clean
>> > version back to disk for everybody to share.
>> >
>> > Best,
>> > Marcel
>> >
>> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
>> > Thank you Dave for reviewing and merging and committing
>> > Morphic-hjh.1349.mcz.
>> >
>> > One of the next issues is that the loaded Etoys project has a key
>> >
>> > #aboutToLeaveWorld
>> >
>> > in the actionMap which causes an error message to appear when leaving
>> > the project.
>> >
>> > Executing
>> >
>> > Project current world actionMap removeKey: #aboutToLeaveWorld
>> >
>> > or just
>> >
>> > self world actionMap removeKey: #aboutToLeaveWorld
>> >
>> > if not called from a workspace
>> >
>> > solves that problem.
>> >
>> > But I am not sure if this is the right thing to do and where to put
>> > this.
>> >
>> > The event mechanism is not used much in Squeak6.0a. (see thread:
>> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
>> > need to do?', in particular answer by Bob Arning')
>> >
>> >
>> > Another issue is that
>> >
>> > SugarNavigatorBar showSugarNavigator: true.
>> >
>> > needs to be called.
>> >
>> >
>> > A third question: In which directory should the three projects to
>> > preload
>> > stay?
>> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
>> >
>> > Smalltalk imagePath
>> >
>> > ?
>> >
>> >
>> > --Hannes
>> >
>> > On 10/13/17, H. Hirzel wrote:
>> >> Thank you Bert for the links to the regular three projects (home,
>> >> gallery, tutorials) and the background information.
>> >>
>> >>
>> >> Update
>> >> -----------
>> >>
>> >> for the most recent trunk image Squeak6.0a-17417 with
>> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
>> >>
>> >>
>> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
>> >>
>> >> loads, and works but brings up an error window regarding a #script1.
>> >>
>> >> The car is moving around.
>> >>
>> >> To leave the project you need to open a workspace and paste and execute
>> >> Project current world actionMap removeKey: #aboutToLeaveWorld
>> >>
>> >> The menu entry 'previous project' works fine.
>> >>
>> >> - Hannes -
>> >>
>> >> On 10/10/17, Bert Freudenberg wrote:
>> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
>> >>> wrote:
>> >>>
>> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>> >>>> > It's all class-based. E.g. if the shape of a class changed (new /
>> >>>> > renamed
>> >>>> > inst vars) that class can provide a "conversion method" that
>> >>>> > creates
>> >>>> > an
>> >>>> > instance with the new layout from the old inst vars (that are
>> >>>> > loaded
>> >>>> > as
>> >>>> > a
>> >>>> > dictionary). There still is a preference
>> >>>> > (conversionMethodsAtFileOut)
>> >>>> that
>> >>>> > used to prompt people to provide these conversion methods when they
>> >>>> changed
>> >>>> > a class. But it didn't survive the transition to Monticello, we now
>> >>>> > have
>> >>>> to
>> >>>> > remember to write conversion methods for instances that may be
>> >>>> > stored
>> >>>> > in
>> >>>> a
>> >>>> > project.
>> >>>>
>> >>>> To check my understanding, the "conversion method" might be something
>> >>>> like
>> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
>> >>>> DateAndTime,
>> >>>> is that right?
>> >>>>
>> >>>
>> >>> ???No, it's those weirdly-named methods like Hannes just made
>> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
>> >>> per-object.
>> >>> This
>> >>> would have been too expensive back in the interpreter days on slow
>> >>> CPUs,
>> >>> that's why the project is stored as an image-segment, and the segment
>> >>> is
>> >>> written to a SmartRefStream with its out-pointers (references to
>> >>> objects
>> >>> outside the segment, e.g. classes).
>> >>>
>> >>> The SmartRefStream is only used to resolve the class references from
>> >>> the
>> >>> ImageSegment that stores the project.
>> >>>
>> >>>> This is different from the Etoys home screen (the clouds and
>> >>>> drive-a-car)
>> >>>> > which is simply a project that would be loaded by the deployment
>> >>>> > script
>> >>>> > that creates an Etoys image. It does not have to ship with the
>> >>>> > general
>> >>>> > Squeak image.
>> >>>>
>> >>>> I do not know if it will make sense, but I guess my mental image is
>> >>>> an
>> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk image.
>> >>>> So
>> >>>> I
>> >>>> guess that I am thinking of the "clouds and drive-a-car" project
>> >>>> being
>> >>>> loaded the first time that I create a new EtoysProject from normal
>> >>>> Squeak,
>> >>>> and that somehow the subsequent project navigation within that new
>> >>>> "hosted"
>> >>>> Etoys would behave is if I were in a stand-alone Etoys image.
>> >>>> Finally,
>> >>>> I would want to be able to escape back to my normal Squeak.
>> >>>
>> >>>
>> >>> ???That sounds good :)
>> >>>
>> >>> - Bert -???
>> >>>
>> >>
>> >
>> >
>>
>
>

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

Dave,

I started with an updated trunk image 6.0a-17435.

Then I manually loaded from

MCHttpRepository
location: 'http://www.squeaksource.com/EtoysProject'
user: ''
password: ''

Name: System-dtl.970
Name: Collections-dtl.765
Name: System-dtl.970

I created a new (empty) 'Etoys project' by choosing 'Projects -> New
project -> New Etoys project'.

=> an empty pr file was created with an Etoys docking bar, actually
called 'Sugar Navigator Flap'.

In a workspace

Project current
an EtoysProject (Unnamed2) in a PasteUpMorph(3017056) [world]

Then I dropped a pr-file into that project and was expecting that a
EtoysProject will result.
But I still got

Project current
Project current a MorphicProject (JHexagon2) in a
PasteUpMorph<world>(715845) [world]

To load a pr file which contains an Etoys project as an EtoysProject
makes sense.

An Etoys project is a MorphicProject (isa-relationship).

MorphicProject subclass: #EtoysProject

So I wonder why the imported project object was not set to be an
EtoysProject instance. I do not have the time to further look into
the issue at the moment.

--Hannes

On 10/23/17, H. Hirzel <[hidden email]> wrote:

> On 10/19/17, David T. Lewis <[hidden email]> wrote:
>> Hannes,
>>
>> Thank you for this summary, it helps a lot. I can load the project,
>
> Dave,
> that implies that you do not have the graphics problem Marcel
> encountered, is this correct?
>
>> and I note that my VM crashes fairly often when playing with this, so
>> that that will give me something to look into :-)
>>
>> I don't have time to look further now, but the (old) VM I am using at
>> the moment is:
>>
>> /usr/local/lib/squeak/5.0-201608171728-64/squeak
>> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
>> VMMaker.oscog-cb.1919]
>> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
>> platform sources revision VM: 201608171728
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17
>> 10:28:01 2016 -0700
>> $ Plugins: 201608171728
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>> CoInterpreter VMMaker.oscog-cb.1919 uuid:
>> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid:
>> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>>
>>
>> Dave
>>
>>
>>
>> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
>>> Update: It is now possible to load a project such as home.pr into the
>>> 6.0a trunk image.
>>> Drop a pr file (downloaded from
>>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
>>> desktop and it loads without blocking. This is due to fixes done this
>>> month so far.
>>>
>>> The following notes are written in a way that you can jump in helping
>>> to finalize Etoys project loading and setup without having read the
>>> earlier messages in this thread.
>>>
>>>
>>>
>>> Issues:
>>>
>>>
>>> 1. Walkback window left on screen after loading
>>> --------------------------------------------------------------------
>>>
>>> A walk-back window still comes up after home.pr has been loaded.
>>> The reason for this still needs to be found out. But just closing the
>>> window does not seem to have a negative effect to the functioning of
>>> the etoys project.
>>>
>>>
>>>
>>>
>>> 2. Etoys tiles (TileMorph)
>>> ------------------------------------
>>>
>>> Incrementing and decrementing values in tiles has been fixed so that
>>> it is possible to use the project. It was a problem related to the
>>> Environment code.
>>>
>>> More tests using the tiles are needed to see if there are more
>>> problems such as this.
>>>
>>>
>>>
>>>
>>> 3. Loading pr files
>>> ---------------------------
>>>
>>> Please help testing with loading different pr files. Other loading
>>> problems are likely to come up. Focus on projects created with Etoys5.
>>> ( http://squeakland.org/download/).
>>>
>>> Etoys 5.0 uses the image format 6502
>>> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
>>> in Smalltalk code (not VM code) in 6.0a trunk (class
>>> LegacyImageSegment / ImageSegmentLoader). [1]
>>>
>>> SmartRefStream does the conversion of the loaded objects if necessary.
>>>
>>>
>>>
>>>
>>> 4. Cleanup of a loaded project
>>> -------------------------------------------
>>>
>>> A loaded project is not yet properly set up. The button 'previous
>>> project' does not work.
>>>
>>> To fix this
>>>
>>> EtoysProject >> #finalEnterActions:
>>>
>>> needs to be set up.
>>>
>>> The call
>>>
>>> self world actionMap removeKey: #aboutToLeaveWorld
>>>
>>> as discussed earlier in this thread is one a cleanup actions to be here.
>>>
>>>
>>> When loading a pr file an instance of MorphicProject is created as
>>> currently
>>>
>>> MorphicProject->EtoysProject
>>>
>>> has not been mapped yet in SmartRefStream initKnownRenames. This needs
>>> to be done.
>>>
>>>
>>> --Hannes
>>>
>>>
>>>
>>> -------------------------------------------------------------
>>>
>>> [1] There are quite a number of etoys pr files around which are not in
>>> the 6502 format.
>>> http://wiki.squeak.org/squeak/6502
>>>
>>> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
>>> are probably necessary.
>>>
>>> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
>>> > Hi Hannes,
>>> >
>>> > if you have project instances that need clean-up, you can put that
>>> > code
>>> > at
>>> > one of several checkpoints:
>>> >
>>> > - entering a project (EtoysProject >> #finalEnterActions:)
>>> > - leaving a project (EtoysProject >> #finalExitActions:)
>>> > - loading/merging a Monticello package (see postLoad scripts)
>>> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
>>> > - resuming the Squeak image (EtoysProject class >> #startUp:)
>>> > - loading a ChangeSet (see postLoad scripts)
>>> >
>>> > Or if you plan to persist Etoys project in the file system, clean them
>>> > up
>>> > manually (e.g. with a workspace and object inspector) and write the
>>> > clean
>>> > version back to disk for everybody to share.
>>> >
>>> > Best,
>>> > Marcel
>>> >
>>> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
>>> > Thank you Dave for reviewing and merging and committing
>>> > Morphic-hjh.1349.mcz.
>>> >
>>> > One of the next issues is that the loaded Etoys project has a key
>>> >
>>> > #aboutToLeaveWorld
>>> >
>>> > in the actionMap which causes an error message to appear when leaving
>>> > the project.
>>> >
>>> > Executing
>>> >
>>> > Project current world actionMap removeKey: #aboutToLeaveWorld
>>> >
>>> > or just
>>> >
>>> > self world actionMap removeKey: #aboutToLeaveWorld
>>> >
>>> > if not called from a workspace
>>> >
>>> > solves that problem.
>>> >
>>> > But I am not sure if this is the right thing to do and where to put
>>> > this.
>>> >
>>> > The event mechanism is not used much in Squeak6.0a. (see thread:
>>> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
>>> > need to do?', in particular answer by Bob Arning')
>>> >
>>> >
>>> > Another issue is that
>>> >
>>> > SugarNavigatorBar showSugarNavigator: true.
>>> >
>>> > needs to be called.
>>> >
>>> >
>>> > A third question: In which directory should the three projects to
>>> > preload
>>> > stay?
>>> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
>>> >
>>> > Smalltalk imagePath
>>> >
>>> > ?
>>> >
>>> >
>>> > --Hannes
>>> >
>>> > On 10/13/17, H. Hirzel wrote:
>>> >> Thank you Bert for the links to the regular three projects (home,
>>> >> gallery, tutorials) and the background information.
>>> >>
>>> >>
>>> >> Update
>>> >> -----------
>>> >>
>>> >> for the most recent trunk image Squeak6.0a-17417 with
>>> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
>>> >>
>>> >>
>>> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
>>> >>
>>> >> loads, and works but brings up an error window regarding a #script1.
>>> >>
>>> >> The car is moving around.
>>> >>
>>> >> To leave the project you need to open a workspace and paste and
>>> >> execute
>>> >> Project current world actionMap removeKey: #aboutToLeaveWorld
>>> >>
>>> >> The menu entry 'previous project' works fine.
>>> >>
>>> >> - Hannes -
>>> >>
>>> >> On 10/10/17, Bert Freudenberg wrote:
>>> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
>>> >>> wrote:
>>> >>>
>>> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>>> >>>> > It's all class-based. E.g. if the shape of a class changed (new /
>>> >>>> > renamed
>>> >>>> > inst vars) that class can provide a "conversion method" that
>>> >>>> > creates
>>> >>>> > an
>>> >>>> > instance with the new layout from the old inst vars (that are
>>> >>>> > loaded
>>> >>>> > as
>>> >>>> > a
>>> >>>> > dictionary). There still is a preference
>>> >>>> > (conversionMethodsAtFileOut)
>>> >>>> that
>>> >>>> > used to prompt people to provide these conversion methods when
>>> >>>> > they
>>> >>>> changed
>>> >>>> > a class. But it didn't survive the transition to Monticello, we
>>> >>>> > now
>>> >>>> > have
>>> >>>> to
>>> >>>> > remember to write conversion methods for instances that may be
>>> >>>> > stored
>>> >>>> > in
>>> >>>> a
>>> >>>> > project.
>>> >>>>
>>> >>>> To check my understanding, the "conversion method" might be
>>> >>>> something
>>> >>>> like
>>> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
>>> >>>> DateAndTime,
>>> >>>> is that right?
>>> >>>>
>>> >>>
>>> >>> ???No, it's those weirdly-named methods like Hannes just made
>>> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
>>> >>> per-object.
>>> >>> This
>>> >>> would have been too expensive back in the interpreter days on slow
>>> >>> CPUs,
>>> >>> that's why the project is stored as an image-segment, and the
>>> >>> segment
>>> >>> is
>>> >>> written to a SmartRefStream with its out-pointers (references to
>>> >>> objects
>>> >>> outside the segment, e.g. classes).
>>> >>>
>>> >>> The SmartRefStream is only used to resolve the class references from
>>> >>> the
>>> >>> ImageSegment that stores the project.
>>> >>>
>>> >>>> This is different from the Etoys home screen (the clouds and
>>> >>>> drive-a-car)
>>> >>>> > which is simply a project that would be loaded by the deployment
>>> >>>> > script
>>> >>>> > that creates an Etoys image. It does not have to ship with the
>>> >>>> > general
>>> >>>> > Squeak image.
>>> >>>>
>>> >>>> I do not know if it will make sense, but I guess my mental image is
>>> >>>> an
>>> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk image.
>>> >>>> So
>>> >>>> I
>>> >>>> guess that I am thinking of the "clouds and drive-a-car" project
>>> >>>> being
>>> >>>> loaded the first time that I create a new EtoysProject from normal
>>> >>>> Squeak,
>>> >>>> and that somehow the subsequent project navigation within that new
>>> >>>> "hosted"
>>> >>>> Etoys would behave is if I were in a stand-alone Etoys image.
>>> >>>> Finally,
>>> >>>> I would want to be able to escape back to my normal Squeak.
>>> >>>
>>> >>>
>>> >>> ???That sounds good :)
>>> >>>
>>> >>> - Bert -???
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

In the previous mail instead change

"an empty pr file was created with an Etoys docking bar, actually"
to
an empty project was created with an Etoys docking bar, actually"

In addtion: a pr file dropped into an Etoys project did not trigger
the creation of a Sugar Navigation Bar.

On 10/23/17, H. Hirzel <[hidden email]> wrote:

> Dave,
>
> I started with an updated trunk image 6.0a-17435.
>
> Then I manually loaded from
>
> MCHttpRepository
> location: 'http://www.squeaksource.com/EtoysProject'
> user: ''
> password: ''
>
>
> Name: System-dtl.970
> Name: Collections-dtl.765
> Name: System-dtl.970
>
> I created a new (empty) 'Etoys project' by choosing 'Projects -> New
> project -> New Etoys project'.
>
> => an empty pr file was created with an Etoys docking bar, actually
> called 'Sugar Navigator Flap'.
>
> In a workspace
>
> Project current
> an EtoysProject (Unnamed2) in a PasteUpMorph(3017056) [world]
>
>
> Then I dropped a pr-file into that project and was expecting that a
> EtoysProject will result.
> But I still got
>
>
> Project current
> Project current a MorphicProject (JHexagon2) in a
> PasteUpMorph<world>(715845) [world]
>
>
>
> To load a pr file which contains an Etoys project as an EtoysProject
> makes sense.
>
> An Etoys project is a MorphicProject (isa-relationship).
>
> MorphicProject subclass: #EtoysProject
>
> So I wonder why the imported project object was not set to be an
> EtoysProject instance. I do not have the time to further look into
> the issue at the moment.
>
> --Hannes
>
>
> On 10/23/17, H. Hirzel <[hidden email]> wrote:
>> On 10/19/17, David T. Lewis <[hidden email]> wrote:
>>> Hannes,
>>>
>>> Thank you for this summary, it helps a lot. I can load the project,
>>
>> Dave,
>> that implies that you do not have the graphics problem Marcel
>> encountered, is this correct?
>>
>>> and I note that my VM crashes fairly often when playing with this, so
>>> that that will give me something to look into :-)
>>>
>>> I don't have time to look further now, but the (old) VM I am using at
>>> the moment is:
>>>
>>> /usr/local/lib/squeak/5.0-201608171728-64/squeak
>>> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
>>> VMMaker.oscog-cb.1919]
>>> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
>>> platform sources revision VM: 201608171728
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17
>>> 10:28:01 2016 -0700
>>> $ Plugins: 201608171728
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> CoInterpreter VMMaker.oscog-cb.1919 uuid:
>>> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>>> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid:
>>> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>>>
>>>
>>> Dave
>>>
>>>
>>>
>>> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
>>>> Update: It is now possible to load a project such as home.pr into the
>>>> 6.0a trunk image.
>>>> Drop a pr file (downloaded from
>>>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
>>>> desktop and it loads without blocking. This is due to fixes done this
>>>> month so far.
>>>>
>>>> The following notes are written in a way that you can jump in helping
>>>> to finalize Etoys project loading and setup without having read the
>>>> earlier messages in this thread.
>>>>
>>>>
>>>>
>>>> Issues:
>>>>
>>>>
>>>> 1. Walkback window left on screen after loading
>>>> --------------------------------------------------------------------
>>>>
>>>> A walk-back window still comes up after home.pr has been loaded.
>>>> The reason for this still needs to be found out. But just closing the
>>>> window does not seem to have a negative effect to the functioning of
>>>> the etoys project.
>>>>
>>>>
>>>>
>>>>
>>>> 2. Etoys tiles (TileMorph)
>>>> ------------------------------------
>>>>
>>>> Incrementing and decrementing values in tiles has been fixed so that
>>>> it is possible to use the project. It was a problem related to the
>>>> Environment code.
>>>>
>>>> More tests using the tiles are needed to see if there are more
>>>> problems such as this.
>>>>
>>>>
>>>>
>>>>
>>>> 3. Loading pr files
>>>> ---------------------------
>>>>
>>>> Please help testing with loading different pr files. Other loading
>>>> problems are likely to come up. Focus on projects created with Etoys5.
>>>> ( http://squeakland.org/download/).
>>>>
>>>> Etoys 5.0 uses the image format 6502
>>>> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
>>>> in Smalltalk code (not VM code) in 6.0a trunk (class
>>>> LegacyImageSegment / ImageSegmentLoader). [1]
>>>>
>>>> SmartRefStream does the conversion of the loaded objects if necessary.
>>>>
>>>>
>>>>
>>>>
>>>> 4. Cleanup of a loaded project
>>>> -------------------------------------------
>>>>
>>>> A loaded project is not yet properly set up. The button 'previous
>>>> project' does not work.
>>>>
>>>> To fix this
>>>>
>>>> EtoysProject >> #finalEnterActions:
>>>>
>>>> needs to be set up.
>>>>
>>>> The call
>>>>
>>>> self world actionMap removeKey: #aboutToLeaveWorld
>>>>
>>>> as discussed earlier in this thread is one a cleanup actions to be
>>>> here.
>>>>
>>>>
>>>> When loading a pr file an instance of MorphicProject is created as
>>>> currently
>>>>
>>>> MorphicProject->EtoysProject
>>>>
>>>> has not been mapped yet in SmartRefStream initKnownRenames. This needs
>>>> to be done.
>>>>
>>>>
>>>> --Hannes
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------
>>>>
>>>> [1] There are quite a number of etoys pr files around which are not in
>>>> the 6502 format.
>>>> http://wiki.squeak.org/squeak/6502
>>>>
>>>> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
>>>> are probably necessary.
>>>>
>>>> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
>>>> > Hi Hannes,
>>>> >
>>>> > if you have project instances that need clean-up, you can put that
>>>> > code
>>>> > at
>>>> > one of several checkpoints:
>>>> >
>>>> > - entering a project (EtoysProject >> #finalEnterActions:)
>>>> > - leaving a project (EtoysProject >> #finalExitActions:)
>>>> > - loading/merging a Monticello package (see postLoad scripts)
>>>> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
>>>> > - resuming the Squeak image (EtoysProject class >> #startUp:)
>>>> > - loading a ChangeSet (see postLoad scripts)
>>>> >
>>>> > Or if you plan to persist Etoys project in the file system, clean
>>>> > them
>>>> > up
>>>> > manually (e.g. with a workspace and object inspector) and write the
>>>> > clean
>>>> > version back to disk for everybody to share.
>>>> >
>>>> > Best,
>>>> > Marcel
>>>> >
>>>> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
>>>> > Thank you Dave for reviewing and merging and committing
>>>> > Morphic-hjh.1349.mcz.
>>>> >
>>>> > One of the next issues is that the loaded Etoys project has a key
>>>> >
>>>> > #aboutToLeaveWorld
>>>> >
>>>> > in the actionMap which causes an error message to appear when leaving
>>>> > the project.
>>>> >
>>>> > Executing
>>>> >
>>>> > Project current world actionMap removeKey: #aboutToLeaveWorld
>>>> >
>>>> > or just
>>>> >
>>>> > self world actionMap removeKey: #aboutToLeaveWorld
>>>> >
>>>> > if not called from a workspace
>>>> >
>>>> > solves that problem.
>>>> >
>>>> > But I am not sure if this is the right thing to do and where to put
>>>> > this.
>>>> >
>>>> > The event mechanism is not used much in Squeak6.0a. (see thread:
>>>> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
>>>> > need to do?', in particular answer by Bob Arning')
>>>> >
>>>> >
>>>> > Another issue is that
>>>> >
>>>> > SugarNavigatorBar showSugarNavigator: true.
>>>> >
>>>> > needs to be called.
>>>> >
>>>> >
>>>> > A third question: In which directory should the three projects to
>>>> > preload
>>>> > stay?
>>>> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
>>>> >
>>>> > Smalltalk imagePath
>>>> >
>>>> > ?
>>>> >
>>>> >
>>>> > --Hannes
>>>> >
>>>> > On 10/13/17, H. Hirzel wrote:
>>>> >> Thank you Bert for the links to the regular three projects (home,
>>>> >> gallery, tutorials) and the background information.
>>>> >>
>>>> >>
>>>> >> Update
>>>> >> -----------
>>>> >>
>>>> >> for the most recent trunk image Squeak6.0a-17417 with
>>>> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
>>>> >>
>>>> >>
>>>> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
>>>> >>
>>>> >> loads, and works but brings up an error window regarding a #script1.
>>>> >>
>>>> >> The car is moving around.
>>>> >>
>>>> >> To leave the project you need to open a workspace and paste and
>>>> >> execute
>>>> >> Project current world actionMap removeKey: #aboutToLeaveWorld
>>>> >>
>>>> >> The menu entry 'previous project' works fine.
>>>> >>
>>>> >> - Hannes -
>>>> >>
>>>> >> On 10/10/17, Bert Freudenberg wrote:
>>>> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
>>>> >>> wrote:
>>>> >>>
>>>> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>>>> >>>> > It's all class-based. E.g. if the shape of a class changed (new
>>>> >>>> > /
>>>> >>>> > renamed
>>>> >>>> > inst vars) that class can provide a "conversion method" that
>>>> >>>> > creates
>>>> >>>> > an
>>>> >>>> > instance with the new layout from the old inst vars (that are
>>>> >>>> > loaded
>>>> >>>> > as
>>>> >>>> > a
>>>> >>>> > dictionary). There still is a preference
>>>> >>>> > (conversionMethodsAtFileOut)
>>>> >>>> that
>>>> >>>> > used to prompt people to provide these conversion methods when
>>>> >>>> > they
>>>> >>>> changed
>>>> >>>> > a class. But it didn't survive the transition to Monticello, we
>>>> >>>> > now
>>>> >>>> > have
>>>> >>>> to
>>>> >>>> > remember to write conversion methods for instances that may be
>>>> >>>> > stored
>>>> >>>> > in
>>>> >>>> a
>>>> >>>> > project.
>>>> >>>>
>>>> >>>> To check my understanding, the "conversion method" might be
>>>> >>>> something
>>>> >>>> like
>>>> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
>>>> >>>> DateAndTime,
>>>> >>>> is that right?
>>>> >>>>
>>>> >>>
>>>> >>> ???No, it's those weirdly-named methods like Hannes just made
>>>> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
>>>> >>> per-object.
>>>> >>> This
>>>> >>> would have been too expensive back in the interpreter days on slow
>>>> >>> CPUs,
>>>> >>> that's why the project is stored as an image-segment, and the
>>>> >>> segment
>>>> >>> is
>>>> >>> written to a SmartRefStream with its out-pointers (references to
>>>> >>> objects
>>>> >>> outside the segment, e.g. classes).
>>>> >>>
>>>> >>> The SmartRefStream is only used to resolve the class references
>>>> >>> from
>>>> >>> the
>>>> >>> ImageSegment that stores the project.
>>>> >>>
>>>> >>>> This is different from the Etoys home screen (the clouds and
>>>> >>>> drive-a-car)
>>>> >>>> > which is simply a project that would be loaded by the deployment
>>>> >>>> > script
>>>> >>>> > that creates an Etoys image. It does not have to ship with the
>>>> >>>> > general
>>>> >>>> > Squeak image.
>>>> >>>>
>>>> >>>> I do not know if it will make sense, but I guess my mental image
>>>> >>>> is
>>>> >>>> an
>>>> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk
>>>> >>>> image.
>>>> >>>> So
>>>> >>>> I
>>>> >>>> guess that I am thinking of the "clouds and drive-a-car" project
>>>> >>>> being
>>>> >>>> loaded the first time that I create a new EtoysProject from normal
>>>> >>>> Squeak,
>>>> >>>> and that somehow the subsequent project navigation within that new
>>>> >>>> "hosted"
>>>> >>>> Etoys would behave is if I were in a stand-alone Etoys image.
>>>> >>>> Finally,
>>>> >>>> I would want to be able to escape back to my normal Squeak.
>>>> >>>
>>>> >>>
>>>> >>> ???That sounds good :)
>>>> >>>
>>>> >>> - Bert -???
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

In reply to this post by Hannes Hirzel

On Mon, Oct 23, 2017 at 05:18:22AM +0200, H. Hirzel wrote:
> On 10/19/17, David T. Lewis <[hidden email]> wrote:
> > Hannes,
> >
> > Thank you for this summary, it helps a lot. I can load the project,
>
> Dave,
> that implies that you do not have the graphics problem Marcel
> encountered, is this correct?
>

Yes, that is correct, I do not see the graphics problem on my PC. I note
that Marcel has a high resolution screen, so I am guessing that this may
be a factor.

Dave

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

In reply to this post by Hannes Hirzel

Hannes,

I think that it is at least partly working (but maybe buggy). Here is what I can do:

- Start in a Morphic project,

- Do "ProjectViewMorph openOn: EtoysProject new"

- Enter the new EtoysProject.

- Drag and drop a project file (Gallery.031.pr) from a Linux file browser
onto the Etoys workspace. New project is created and entered.

- In the Gallery project, open a new workspace and evaluate:

Project current ==> an EtoysProject (Gallery) in a PasteUpMorph<world>(4160077) [world]

Project current parent ==> an EtoysProject (Unnamed10) in a PasteUpMorph(247758) [world]

Project current parent parent ==> a MorphicProject (EtoysProject) in a PasteUpMorph(4153267) [world]

Note, the name of my original MorphicProject was 'EtoysProject' so that is why it
prints " ==> a MorphicProject (EtoysProject) " in the doIt above.

Dave

On Mon, Oct 23, 2017 at 05:37:37AM +0200, H. Hirzel wrote:

> Dave,
>
> I started with an updated trunk image 6.0a-17435.
>
> Then I manually loaded from
>
> MCHttpRepository
> location: 'http://www.squeaksource.com/EtoysProject'
> user: ''
> password: ''
>
>
> Name: System-dtl.970
> Name: Collections-dtl.765
> Name: System-dtl.970
>
> I created a new (empty) 'Etoys project' by choosing 'Projects -> New
> project -> New Etoys project'.
>
> => an empty pr file was created with an Etoys docking bar, actually
> called 'Sugar Navigator Flap'.
>
> In a workspace
>
> Project current
> an EtoysProject (Unnamed2) in a PasteUpMorph(3017056) [world]
>
>
> Then I dropped a pr-file into that project and was expecting that a
> EtoysProject will result.
> But I still got
>
>
> Project current
> Project current a MorphicProject (JHexagon2) in a
> PasteUpMorph<world>(715845) [world]
>
>
>
> To load a pr file which contains an Etoys project as an EtoysProject
> makes sense.
>
> An Etoys project is a MorphicProject (isa-relationship).
>
> MorphicProject subclass: #EtoysProject
>
> So I wonder why the imported project object was not set to be an
> EtoysProject instance. I do not have the time to further look into
> the issue at the moment.
>
> --Hannes
>
>
> On 10/23/17, H. Hirzel <[hidden email]> wrote:
> > On 10/19/17, David T. Lewis <[hidden email]> wrote:
> >> Hannes,
> >>
> >> Thank you for this summary, it helps a lot. I can load the project,
> >
> > Dave,
> > that implies that you do not have the graphics problem Marcel
> > encountered, is this correct?
> >
> >> and I note that my VM crashes fairly often when playing with this, so
> >> that that will give me something to look into :-)
> >>
> >> I don't have time to look further now, but the (old) VM I am using at
> >> the moment is:
> >>
> >> /usr/local/lib/squeak/5.0-201608171728-64/squeak
> >> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
> >> VMMaker.oscog-cb.1919]
> >> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
> >> platform sources revision VM: 201608171728
> >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17
> >> 10:28:01 2016 -0700
> >> $ Plugins: 201608171728
> >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> >> CoInterpreter VMMaker.oscog-cb.1919 uuid:
> >> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
> >> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid:
> >> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
> >>
> >>
> >> Dave
> >>
> >>
> >>
> >> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
> >>> Update: It is now possible to load a project such as home.pr into the
> >>> 6.0a trunk image.
> >>> Drop a pr file (downloaded from
> >>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
> >>> desktop and it loads without blocking. This is due to fixes done this
> >>> month so far.
> >>>
> >>> The following notes are written in a way that you can jump in helping
> >>> to finalize Etoys project loading and setup without having read the
> >>> earlier messages in this thread.
> >>>
> >>>
> >>>
> >>> Issues:
> >>>
> >>>
> >>> 1. Walkback window left on screen after loading
> >>> --------------------------------------------------------------------
> >>>
> >>> A walk-back window still comes up after home.pr has been loaded.
> >>> The reason for this still needs to be found out. But just closing the
> >>> window does not seem to have a negative effect to the functioning of
> >>> the etoys project.
> >>>
> >>>
> >>>
> >>>
> >>> 2. Etoys tiles (TileMorph)
> >>> ------------------------------------
> >>>
> >>> Incrementing and decrementing values in tiles has been fixed so that
> >>> it is possible to use the project. It was a problem related to the
> >>> Environment code.
> >>>
> >>> More tests using the tiles are needed to see if there are more
> >>> problems such as this.
> >>>
> >>>
> >>>
> >>>
> >>> 3. Loading pr files
> >>> ---------------------------
> >>>
> >>> Please help testing with loading different pr files. Other loading
> >>> problems are likely to come up. Focus on projects created with Etoys5.
> >>> ( http://squeakland.org/download/).
> >>>
> >>> Etoys 5.0 uses the image format 6502
> >>> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
> >>> in Smalltalk code (not VM code) in 6.0a trunk (class
> >>> LegacyImageSegment / ImageSegmentLoader). [1]
> >>>
> >>> SmartRefStream does the conversion of the loaded objects if necessary.
> >>>
> >>>
> >>>
> >>>
> >>> 4. Cleanup of a loaded project
> >>> -------------------------------------------
> >>>
> >>> A loaded project is not yet properly set up. The button 'previous
> >>> project' does not work.
> >>>
> >>> To fix this
> >>>
> >>> EtoysProject >> #finalEnterActions:
> >>>
> >>> needs to be set up.
> >>>
> >>> The call
> >>>
> >>> self world actionMap removeKey: #aboutToLeaveWorld
> >>>
> >>> as discussed earlier in this thread is one a cleanup actions to be here.
> >>>
> >>>
> >>> When loading a pr file an instance of MorphicProject is created as
> >>> currently
> >>>
> >>> MorphicProject->EtoysProject
> >>>
> >>> has not been mapped yet in SmartRefStream initKnownRenames. This needs
> >>> to be done.
> >>>
> >>>
> >>> --Hannes
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------------
> >>>
> >>> [1] There are quite a number of etoys pr files around which are not in
> >>> the 6502 format.
> >>> http://wiki.squeak.org/squeak/6502
> >>>
> >>> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
> >>> are probably necessary.
> >>>
> >>> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
> >>> > Hi Hannes,
> >>> >
> >>> > if you have project instances that need clean-up, you can put that
> >>> > code
> >>> > at
> >>> > one of several checkpoints:
> >>> >
> >>> > - entering a project (EtoysProject >> #finalEnterActions:)
> >>> > - leaving a project (EtoysProject >> #finalExitActions:)
> >>> > - loading/merging a Monticello package (see postLoad scripts)
> >>> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
> >>> > - resuming the Squeak image (EtoysProject class >> #startUp:)
> >>> > - loading a ChangeSet (see postLoad scripts)
> >>> >
> >>> > Or if you plan to persist Etoys project in the file system, clean them
> >>> > up
> >>> > manually (e.g. with a workspace and object inspector) and write the
> >>> > clean
> >>> > version back to disk for everybody to share.
> >>> >
> >>> > Best,
> >>> > Marcel
> >>> >
> >>> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
> >>> > Thank you Dave for reviewing and merging and committing
> >>> > Morphic-hjh.1349.mcz.
> >>> >
> >>> > One of the next issues is that the loaded Etoys project has a key
> >>> >
> >>> > #aboutToLeaveWorld
> >>> >
> >>> > in the actionMap which causes an error message to appear when leaving
> >>> > the project.
> >>> >
> >>> > Executing
> >>> >
> >>> > Project current world actionMap removeKey: #aboutToLeaveWorld
> >>> >
> >>> > or just
> >>> >
> >>> > self world actionMap removeKey: #aboutToLeaveWorld
> >>> >
> >>> > if not called from a workspace
> >>> >
> >>> > solves that problem.
> >>> >
> >>> > But I am not sure if this is the right thing to do and where to put
> >>> > this.
> >>> >
> >>> > The event mechanism is not used much in Squeak6.0a. (see thread:
> >>> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
> >>> > need to do?', in particular answer by Bob Arning')
> >>> >
> >>> >
> >>> > Another issue is that
> >>> >
> >>> > SugarNavigatorBar showSugarNavigator: true.
> >>> >
> >>> > needs to be called.
> >>> >
> >>> >
> >>> > A third question: In which directory should the three projects to
> >>> > preload
> >>> > stay?
> >>> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
> >>> >
> >>> > Smalltalk imagePath
> >>> >
> >>> > ?
> >>> >
> >>> >
> >>> > --Hannes
> >>> >
> >>> > On 10/13/17, H. Hirzel wrote:
> >>> >> Thank you Bert for the links to the regular three projects (home,
> >>> >> gallery, tutorials) and the background information.
> >>> >>
> >>> >>
> >>> >> Update
> >>> >> -----------
> >>> >>
> >>> >> for the most recent trunk image Squeak6.0a-17417 with
> >>> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
> >>> >>
> >>> >>
> >>> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
> >>> >>
> >>> >> loads, and works but brings up an error window regarding a #script1.
> >>> >>
> >>> >> The car is moving around.
> >>> >>
> >>> >> To leave the project you need to open a workspace and paste and
> >>> >> execute
> >>> >> Project current world actionMap removeKey: #aboutToLeaveWorld
> >>> >>
> >>> >> The menu entry 'previous project' works fine.
> >>> >>
> >>> >> - Hannes -
> >>> >>
> >>> >> On 10/10/17, Bert Freudenberg wrote:
> >>> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
> >>> >>> wrote:
> >>> >>>
> >>> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
> >>> >>>> > It's all class-based. E.g. if the shape of a class changed (new /
> >>> >>>> > renamed
> >>> >>>> > inst vars) that class can provide a "conversion method" that
> >>> >>>> > creates
> >>> >>>> > an
> >>> >>>> > instance with the new layout from the old inst vars (that are
> >>> >>>> > loaded
> >>> >>>> > as
> >>> >>>> > a
> >>> >>>> > dictionary). There still is a preference
> >>> >>>> > (conversionMethodsAtFileOut)
> >>> >>>> that
> >>> >>>> > used to prompt people to provide these conversion methods when
> >>> >>>> > they
> >>> >>>> changed
> >>> >>>> > a class. But it didn't survive the transition to Monticello, we
> >>> >>>> > now
> >>> >>>> > have
> >>> >>>> to
> >>> >>>> > remember to write conversion methods for instances that may be
> >>> >>>> > stored
> >>> >>>> > in
> >>> >>>> a
> >>> >>>> > project.
> >>> >>>>
> >>> >>>> To check my understanding, the "conversion method" might be
> >>> >>>> something
> >>> >>>> like
> >>> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
> >>> >>>> DateAndTime,
> >>> >>>> is that right?
> >>> >>>>
> >>> >>>
> >>> >>> ???No, it's those weirdly-named methods like Hannes just made
> >>> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
> >>> >>> per-object.
> >>> >>> This
> >>> >>> would have been too expensive back in the interpreter days on slow
> >>> >>> CPUs,
> >>> >>> that's why the project is stored as an image-segment, and the
> >>> >>> segment
> >>> >>> is
> >>> >>> written to a SmartRefStream with its out-pointers (references to
> >>> >>> objects
> >>> >>> outside the segment, e.g. classes).
> >>> >>>
> >>> >>> The SmartRefStream is only used to resolve the class references from
> >>> >>> the
> >>> >>> ImageSegment that stores the project.
> >>> >>>
> >>> >>>> This is different from the Etoys home screen (the clouds and
> >>> >>>> drive-a-car)
> >>> >>>> > which is simply a project that would be loaded by the deployment
> >>> >>>> > script
> >>> >>>> > that creates an Etoys image. It does not have to ship with the
> >>> >>>> > general
> >>> >>>> > Squeak image.
> >>> >>>>
> >>> >>>> I do not know if it will make sense, but I guess my mental image is
> >>> >>>> an
> >>> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk image.
> >>> >>>> So
> >>> >>>> I
> >>> >>>> guess that I am thinking of the "clouds and drive-a-car" project
> >>> >>>> being
> >>> >>>> loaded the first time that I create a new EtoysProject from normal
> >>> >>>> Squeak,
> >>> >>>> and that somehow the subsequent project navigation within that new
> >>> >>>> "hosted"
> >>> >>>> Etoys would behave is if I were in a stand-alone Etoys image.
> >>> >>>> Finally,
> >>> >>>> I would want to be able to escape back to my normal Squeak.
> >>> >>>
> >>> >>>
> >>> >>> ???That sounds good :)
> >>> >>>
> >>> >>> - Bert -???
> >>> >>>
> >>> >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

Dave

thank you for the detailed test case description. I followed the
instructions and can confirm that indeed I get an Etoys project for
the Gallery.pr file.

I used a fully updated trunk image and did

(MCConfiguration fromArray: #(

repository ('http://www.squeaksource.com/EtoysProject')

dependency ('System' 'System-dtl.970' '90db9247-00c0-4f0d-a205-c7121125b971')
dependency ('Collections' 'Collections-dtl.765'
'0109fe1c-9f9b-4826-ab6b-dac5db14ba18')
dependency ('Project-Etoys' 'Project-Etoys-dtl.2'
'7a7f7f95-c623-4024-be85-af380d03ca4f')

)) upgrade

I documented this process in a EtoysDeveloperNotesHelp class with
executable content. [1]

An issue to look into next is to make the back button work after the
project has been loaded.

This is the issue about placing

Project current world actionMap removeKey: #aboutToLeaveWorld

or in a method

self world actionMap removeKey: #aboutToLeaveWorld

at the proper place.

Hannes

[1] Name: Project-Etoys-hjh.3
Author: hjh
Time: 24 October 2017, 11:27:14.871709 am
UUID: 32159c50-03aa-48b5-9374-95dbc1184505
Ancestors: Project-Etoys-dtl.2

On 10/24/17, David T. Lewis <[hidden email]> wrote:

> Hannes,
>
> I think that it is at least partly working (but maybe buggy). Here is what I
> can do:
>
> - Start in a Morphic project,
>
> - Do "ProjectViewMorph openOn: EtoysProject new"
>
> - Enter the new EtoysProject.
>
> - Drag and drop a project file (Gallery.031.pr) from a Linux file browser
> onto the Etoys workspace. New project is created and entered.
>
> - In the Gallery project, open a new workspace and evaluate:
>
> Project current ==> an EtoysProject (Gallery) in a
> PasteUpMorph<world>(4160077) [world]
>
> Project current parent ==> an EtoysProject (Unnamed10) in a
> PasteUpMorph(247758) [world]
>
> Project current parent parent ==> a MorphicProject (EtoysProject) in a
> PasteUpMorph(4153267) [world]
>
>
> Note, the name of my original MorphicProject was 'EtoysProject' so that is
> why it
> prints " ==> a MorphicProject (EtoysProject) " in the doIt above.
>
> Dave
>
>
>
>
> On Mon, Oct 23, 2017 at 05:37:37AM +0200, H. Hirzel wrote:
>> Dave,
>>
>> I started with an updated trunk image 6.0a-17435.
>>
>> Then I manually loaded from
>>
>> MCHttpRepository
>> location: 'http://www.squeaksource.com/EtoysProject'
>> user: ''
>> password: ''
>>
>>
>> Name: System-dtl.970
>> Name: Collections-dtl.765
>> Name: System-dtl.970
>>
>> I created a new (empty) 'Etoys project' by choosing 'Projects -> New
>> project -> New Etoys project'.
>>
>> => an empty pr file was created with an Etoys docking bar, actually
>> called 'Sugar Navigator Flap'.
>>
>> In a workspace
>>
>> Project current
>> an EtoysProject (Unnamed2) in a PasteUpMorph(3017056) [world]
>>
>>
>> Then I dropped a pr-file into that project and was expecting that a
>> EtoysProject will result.
>> But I still got
>>
>>
>> Project current
>> Project current a MorphicProject (JHexagon2) in a
>> PasteUpMorph<world>(715845) [world]
>>
>>
>>
>> To load a pr file which contains an Etoys project as an EtoysProject
>> makes sense.
>>
>> An Etoys project is a MorphicProject (isa-relationship).
>>
>> MorphicProject subclass: #EtoysProject
>>
>> So I wonder why the imported project object was not set to be an
>> EtoysProject instance. I do not have the time to further look into
>> the issue at the moment.
>>
>> --Hannes
>>
>>
>> On 10/23/17, H. Hirzel <[hidden email]> wrote:
>> > On 10/19/17, David T. Lewis <[hidden email]> wrote:
>> >> Hannes,
>> >>
>> >> Thank you for this summary, it helps a lot. I can load the project,
>> >
>> > Dave,
>> > that implies that you do not have the graphics problem Marcel
>> > encountered, is this correct?
>> >
>> >> and I note that my VM crashes fairly often when playing with this, so
>> >> that that will give me something to look into :-)
>> >>
>> >> I don't have time to look further now, but the (old) VM I am using at
>> >> the moment is:
>> >>
>> >> /usr/local/lib/squeak/5.0-201608171728-64/squeak
>> >> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
>> >> VMMaker.oscog-cb.1919]
>> >> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
>> >> platform sources revision VM: 201608171728
>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug
>> >> 17
>> >> 10:28:01 2016 -0700
>> >> $ Plugins: 201608171728
>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>> >> CoInterpreter VMMaker.oscog-cb.1919 uuid:
>> >> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>> >> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid:
>> >> 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>> >>
>> >>
>> >> Dave
>> >>
>> >>
>> >>
>> >> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
>> >>> Update: It is now possible to load a project such as home.pr into the
>> >>> 6.0a trunk image.
>> >>> Drop a pr file (downloaded from
>> >>> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
>> >>> desktop and it loads without blocking. This is due to fixes done this
>> >>> month so far.
>> >>>
>> >>> The following notes are written in a way that you can jump in helping
>> >>> to finalize Etoys project loading and setup without having read the
>> >>> earlier messages in this thread.
>> >>>
>> >>>
>> >>>
>> >>> Issues:
>> >>>
>> >>>
>> >>> 1. Walkback window left on screen after loading
>> >>> --------------------------------------------------------------------
>> >>>
>> >>> A walk-back window still comes up after home.pr has been loaded.
>> >>> The reason for this still needs to be found out. But just closing the
>> >>> window does not seem to have a negative effect to the functioning of
>> >>> the etoys project.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 2. Etoys tiles (TileMorph)
>> >>> ------------------------------------
>> >>>
>> >>> Incrementing and decrementing values in tiles has been fixed so that
>> >>> it is possible to use the project. It was a problem related to the
>> >>> Environment code.
>> >>>
>> >>> More tests using the tiles are needed to see if there are more
>> >>> problems such as this.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 3. Loading pr files
>> >>> ---------------------------
>> >>>
>> >>> Please help testing with loading different pr files. Other loading
>> >>> problems are likely to come up. Focus on projects created with Etoys5.
>> >>> ( http://squeakland.org/download/).
>> >>>
>> >>> Etoys 5.0 uses the image format 6502
>> >>> (http://wiki.squeak.org/squeak/6502). Loading of this format is done
>> >>> in Smalltalk code (not VM code) in 6.0a trunk (class
>> >>> LegacyImageSegment / ImageSegmentLoader). [1]
>> >>>
>> >>> SmartRefStream does the conversion of the loaded objects if necessary.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 4. Cleanup of a loaded project
>> >>> -------------------------------------------
>> >>>
>> >>> A loaded project is not yet properly set up. The button 'previous
>> >>> project' does not work.
>> >>>
>> >>> To fix this
>> >>>
>> >>> EtoysProject >> #finalEnterActions:
>> >>>
>> >>> needs to be set up.
>> >>>
>> >>> The call
>> >>>
>> >>> self world actionMap removeKey: #aboutToLeaveWorld
>> >>>
>> >>> as discussed earlier in this thread is one a cleanup actions to be
>> >>> here.
>> >>>
>> >>>
>> >>> When loading a pr file an instance of MorphicProject is created as
>> >>> currently
>> >>>
>> >>> MorphicProject->EtoysProject
>> >>>
>> >>> has not been mapped yet in SmartRefStream initKnownRenames. This needs
>> >>> to be done.
>> >>>
>> >>>
>> >>> --Hannes
>> >>>
>> >>>
>> >>>
>> >>> -------------------------------------------------------------
>> >>>
>> >>> [1] There are quite a number of etoys pr files around which are not in
>> >>> the 6502 format.
>> >>> http://wiki.squeak.org/squeak/6502
>> >>>
>> >>> To fix this other versions of LegacyImageSegment / ImageSegmentLoader
>> >>> are probably necessary.
>> >>>
>> >>> On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
>> >>> > Hi Hannes,
>> >>> >
>> >>> > if you have project instances that need clean-up, you can put that
>> >>> > code
>> >>> > at
>> >>> > one of several checkpoints:
>> >>> >
>> >>> > - entering a project (EtoysProject >> #finalEnterActions:)
>> >>> > - leaving a project (EtoysProject >> #finalExitActions:)
>> >>> > - loading/merging a Monticello package (see postLoad scripts)
>> >>> > - quitting the Squeak image (EtoysProject class >> #shutDown:)
>> >>> > - resuming the Squeak image (EtoysProject class >> #startUp:)
>> >>> > - loading a ChangeSet (see postLoad scripts)
>> >>> >
>> >>> > Or if you plan to persist Etoys project in the file system, clean
>> >>> > them
>> >>> > up
>> >>> > manually (e.g. with a workspace and object inspector) and write the
>> >>> > clean
>> >>> > version back to disk for everybody to share.
>> >>> >
>> >>> > Best,
>> >>> > Marcel
>> >>> >
>> >>> > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
>> >>> > Thank you Dave for reviewing and merging and committing
>> >>> > Morphic-hjh.1349.mcz.
>> >>> >
>> >>> > One of the next issues is that the loaded Etoys project has a key
>> >>> >
>> >>> > #aboutToLeaveWorld
>> >>> >
>> >>> > in the actionMap which causes an error message to appear when
>> >>> > leaving
>> >>> > the project.
>> >>> >
>> >>> > Executing
>> >>> >
>> >>> > Project current world actionMap removeKey: #aboutToLeaveWorld
>> >>> >
>> >>> > or just
>> >>> >
>> >>> > self world actionMap removeKey: #aboutToLeaveWorld
>> >>> >
>> >>> > if not called from a workspace
>> >>> >
>> >>> > solves that problem.
>> >>> >
>> >>> > But I am not sure if this is the right thing to do and where to put
>> >>> > this.
>> >>> >
>> >>> > The event mechanism is not used much in Squeak6.0a. (see thread:
>> >>> > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
>> >>> > need to do?', in particular answer by Bob Arning')
>> >>> >
>> >>> >
>> >>> > Another issue is that
>> >>> >
>> >>> > SugarNavigatorBar showSugarNavigator: true.
>> >>> >
>> >>> > needs to be called.
>> >>> >
>> >>> >
>> >>> > A third question: In which directory should the three projects to
>> >>> > preload
>> >>> > stay?
>> >>> > ( Section 3 on http://wiki.squeak.org/squeak/6531)
>> >>> >
>> >>> > Smalltalk imagePath
>> >>> >
>> >>> > ?
>> >>> >
>> >>> >
>> >>> > --Hannes
>> >>> >
>> >>> > On 10/13/17, H. Hirzel wrote:
>> >>> >> Thank you Bert for the links to the regular three projects (home,
>> >>> >> gallery, tutorials) and the background information.
>> >>> >>
>> >>> >>
>> >>> >> Update
>> >>> >> -----------
>> >>> >>
>> >>> >> for the most recent trunk image Squeak6.0a-17417 with
>> >>> >> Morphic-hjh.1349.mcz loaded manually from the inbox:
>> >>> >>
>> >>> >>
>> >>> >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
>> >>> >>
>> >>> >> loads, and works but brings up an error window regarding a
>> >>> >> #script1.
>> >>> >>
>> >>> >> The car is moving around.
>> >>> >>
>> >>> >> To leave the project you need to open a workspace and paste and
>> >>> >> execute
>> >>> >> Project current world actionMap removeKey: #aboutToLeaveWorld
>> >>> >>
>> >>> >> The menu entry 'previous project' works fine.
>> >>> >>
>> >>> >> - Hannes -
>> >>> >>
>> >>> >> On 10/10/17, Bert Freudenberg wrote:
>> >>> >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
>> >>> >>> wrote:
>> >>> >>>
>> >>> >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>> >>> >>>> > It's all class-based. E.g. if the shape of a class changed (new
>> >>> >>>> > /
>> >>> >>>> > renamed
>> >>> >>>> > inst vars) that class can provide a "conversion method" that
>> >>> >>>> > creates
>> >>> >>>> > an
>> >>> >>>> > instance with the new layout from the old inst vars (that are
>> >>> >>>> > loaded
>> >>> >>>> > as
>> >>> >>>> > a
>> >>> >>>> > dictionary). There still is a preference
>> >>> >>>> > (conversionMethodsAtFileOut)
>> >>> >>>> that
>> >>> >>>> > used to prompt people to provide these conversion methods when
>> >>> >>>> > they
>> >>> >>>> changed
>> >>> >>>> > a class. But it didn't survive the transition to Monticello, we
>> >>> >>>> > now
>> >>> >>>> > have
>> >>> >>>> to
>> >>> >>>> > remember to write conversion methods for instances that may be
>> >>> >>>> > stored
>> >>> >>>> > in
>> >>> >>>> a
>> >>> >>>> > project.
>> >>> >>>>
>> >>> >>>> To check my understanding, the "conversion method" might be
>> >>> >>>> something
>> >>> >>>> like
>> >>> >>>> #storeDataOn: and #readDataFrom:size: like what I described for
>> >>> >>>> DateAndTime,
>> >>> >>>> is that right?
>> >>> >>>>
>> >>> >>>
>> >>> >>> ???No, it's those weirdly-named methods like Hannes just made
>> >>> >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
>> >>> >>> per-object.
>> >>> >>> This
>> >>> >>> would have been too expensive back in the interpreter days on slow
>> >>> >>> CPUs,
>> >>> >>> that's why the project is stored as an image-segment, and the
>> >>> >>> segment
>> >>> >>> is
>> >>> >>> written to a SmartRefStream with its out-pointers (references to
>> >>> >>> objects
>> >>> >>> outside the segment, e.g. classes).
>> >>> >>>
>> >>> >>> The SmartRefStream is only used to resolve the class references
>> >>> >>> from
>> >>> >>> the
>> >>> >>> ImageSegment that stores the project.
>> >>> >>>
>> >>> >>>> This is different from the Etoys home screen (the clouds and
>> >>> >>>> drive-a-car)
>> >>> >>>> > which is simply a project that would be loaded by the
>> >>> >>>> > deployment
>> >>> >>>> > script
>> >>> >>>> > that creates an Etoys image. It does not have to ship with the
>> >>> >>>> > general
>> >>> >>>> > Squeak image.
>> >>> >>>>
>> >>> >>>> I do not know if it will make sense, but I guess my mental image
>> >>> >>>> is
>> >>> >>>> an
>> >>> >>>> Etoys "deployed image" hosted inside my regular Squeak trunk
>> >>> >>>> image.
>> >>> >>>> So
>> >>> >>>> I
>> >>> >>>> guess that I am thinking of the "clouds and drive-a-car" project
>> >>> >>>> being
>> >>> >>>> loaded the first time that I create a new EtoysProject from
>> >>> >>>> normal
>> >>> >>>> Squeak,
>> >>> >>>> and that somehow the subsequent project navigation within that
>> >>> >>>> new
>> >>> >>>> "hosted"
>> >>> >>>> Etoys would behave is if I were in a stand-alone Etoys image.
>> >>> >>>> Finally,
>> >>> >>>> I would want to be able to escape back to my normal Squeak.
>> >>> >>>
>> >>> >>>
>> >>> >>> ???That sounds good :)
>> >>> >>>
>> >>> >>> - Bert -???
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>

Etoys2017DevNotesHelp.png (63K) Download Attachment

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

In reply to this post by David T. Lewis

Regarding loading the Etoys projects on 64-bit Spur, I think that there
are some (known) issues with project loading on the 64-bit image. I have
since switched to a 32-bit trunk image, and have had no further issues
with VM crashes.

Project loading generally works pretty well, modulo some of the issues
noted below, and it works when projects are dropped into either an
EtoysProject or a normal MorphicProject.

I do seem to be accumulating EtoysProject and MorphicProject instances
that do not seem to be getting garbage collected after the projects
are deleted, I'm not sure of the reason. I also am accumulating a lot
of Player subclasses, but I suspect that is normal, because
"Player freeUnreferencedSubclasses" seems to be the expected way to
clean these up.

I still have not quite figured out how to open a new EtoysProject
from Morphic or MVC and have it be initialized with the three pre-loaded
projects of the Etoys release image, but I'm sure there is a way to
make it happen given that the basic project loading is working.

Dave

On Thu, Oct 19, 2017 at 08:15:11AM -0400, David T. Lewis wrote:

> Hannes,
>
> Thank you for this summary, it helps a lot. I can load the project,
> and I note that my VM crashes fairly often when playing with this, so
> that that will give me something to look into :-)
>
> I don't have time to look further now, but the (old) VM I am using at
> the moment is:
>
> /usr/local/lib/squeak/5.0-201608171728-64/squeak
> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919]
> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
> platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700
> $ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>
>
> Dave
>
>
>
> On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:
> > Update: It is now possible to load a project such as home.pr into the
> > 6.0a trunk image.
> > Drop a pr file (downloaded from
> > https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the
> > desktop and it loads without blocking. This is due to fixes done this
> > month so far.
> >
> > The following notes are written in a way that you can jump in helping
> > to finalize Etoys project loading and setup without having read the
> > earlier messages in this thread.
> >
> >
> >
> > Issues:
> >
> >
> > 1. Walkback window left on screen after loading
> > --------------------------------------------------------------------
> >
> > A walk-back window still comes up after home.pr has been loaded.
> > The reason for this still needs to be found out. But just closing the
> > window does not seem to have a negative effect to the functioning of
> > the etoys project.
> >
> >
> >
> >
> > 2. Etoys tiles (TileMorph)
> > ------------------------------------
> >
> > Incrementing and decrementing values in tiles has been fixed so that
> > it is possible to use the project. It was a problem related to the
> > Environment code.
> >
> > More tests using the tiles are needed to see if there are more
> > problems such as this.
> >
> >
> >
> >
> > 3. Loading pr files
> > ---------------------------
> >
> > Please help testing with loading different pr files. Other loading
> > problems are likely to come up. Focus on projects created with Etoys5.
> > ( http://squeakland.org/download/).
> >
> > Etoys 5.0 uses the image format 6502
> > (http://wiki.squeak.org/squeak/6502). Loading of this format is done
> > in Smalltalk code (not VM code) in 6.0a trunk (class
> > LegacyImageSegment / ImageSegmentLoader). [1]
> >
> > SmartRefStream does the conversion of the loaded objects if necessary.
> >
> >
> >
> >
> > 4. Cleanup of a loaded project
> > -------------------------------------------
> >
> > A loaded project is not yet properly set up. The button 'previous
> > project' does not work.
> >
> > To fix this
> >
> > EtoysProject >> #finalEnterActions:
> >
> > needs to be set up.
> >
> > The call
> >
> > self world actionMap removeKey: #aboutToLeaveWorld
> >
> > as discussed earlier in this thread is one a cleanup actions to be here.
> >
> >
> > When loading a pr file an instance of MorphicProject is created as currently
> >
> > MorphicProject->EtoysProject
> >
> > has not been mapped yet in SmartRefStream initKnownRenames. This needs
> > to be done.
> >
> >
> > --Hannes
> >
> >
> >
> > -------------------------------------------------------------
> >
> > [1] There are quite a number of etoys pr files around which are not in
> > the 6502 format.
> > http://wiki.squeak.org/squeak/6502
> >
> > To fix this other versions of LegacyImageSegment / ImageSegmentLoader
> > are probably necessary.
> >
> > On 10/14/17, Marcel Taeumel <[hidden email]> wrote:
> > > Hi Hannes,
> > >
> > > if you have project instances that need clean-up, you can put that code at
> > > one of several checkpoints:
> > >
> > > - entering a project (EtoysProject >> #finalEnterActions:)
> > > - leaving a project (EtoysProject >> #finalExitActions:)
> > > - loading/merging a Monticello package (see postLoad scripts)
> > > - quitting the Squeak image (EtoysProject class >> #shutDown:)
> > > - resuming the Squeak image (EtoysProject class >> #startUp:)
> > > - loading a ChangeSet (see postLoad scripts)
> > >
> > > Or if you plan to persist Etoys project in the file system, clean them up
> > > manually (e.g. with a workspace and object inspector) and write the clean
> > > version back to disk for everybody to share.
> > >
> > > Best,
> > > Marcel
> > >
> > > Am 14.10.2017 12:21:20 schrieb H. Hirzel <[hidden email]>:
> > > Thank you Dave for reviewing and merging and committing
> > > Morphic-hjh.1349.mcz.
> > >
> > > One of the next issues is that the loaded Etoys project has a key
> > >
> > > #aboutToLeaveWorld
> > >
> > > in the actionMap which causes an error message to appear when leaving
> > > the project.
> > >
> > > Executing
> > >
> > > Project current world actionMap removeKey: #aboutToLeaveWorld
> > >
> > > or just
> > >
> > > self world actionMap removeKey: #aboutToLeaveWorld
> > >
> > > if not called from a workspace
> > >
> > > solves that problem.
> > >
> > > But I am not sure if this is the right thing to do and where to put this.
> > >
> > > The event mechanism is not used much in Squeak6.0a. (see thread:
> > > 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
> > > need to do?', in particular answer by Bob Arning')
> > >
> > >
> > > Another issue is that
> > >
> > > SugarNavigatorBar showSugarNavigator: true.
> > >
> > > needs to be called.
> > >
> > >
> > > A third question: In which directory should the three projects to preload
> > > stay?
> > > ( Section 3 on http://wiki.squeak.org/squeak/6531)
> > >
> > > Smalltalk imagePath
> > >
> > > ?
> > >
> > >
> > > --Hannes
> > >
> > > On 10/13/17, H. Hirzel wrote:
> > >> Thank you Bert for the links to the regular three projects (home,
> > >> gallery, tutorials) and the background information.
> > >>
> > >>
> > >> Update
> > >> -----------
> > >>
> > >> for the most recent trunk image Squeak6.0a-17417 with
> > >> Morphic-hjh.1349.mcz loaded manually from the inbox:
> > >>
> > >>
> > >> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
> > >>
> > >> loads, and works but brings up an error window regarding a #script1.
> > >>
> > >> The car is moving around.
> > >>
> > >> To leave the project you need to open a workspace and paste and execute
> > >> Project current world actionMap removeKey: #aboutToLeaveWorld
> > >>
> > >> The menu entry 'previous project' works fine.
> > >>
> > >> - Hannes -
> > >>
> > >> On 10/10/17, Bert Freudenberg wrote:
> > >>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis
> > >>> wrote:
> > >>>
> > >>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
> > >>>> > It's all class-based. E.g. if the shape of a class changed (new /
> > >>>> > renamed
> > >>>> > inst vars) that class can provide a "conversion method" that creates
> > >>>> > an
> > >>>> > instance with the new layout from the old inst vars (that are loaded
> > >>>> > as
> > >>>> > a
> > >>>> > dictionary). There still is a preference (conversionMethodsAtFileOut)
> > >>>> that
> > >>>> > used to prompt people to provide these conversion methods when they
> > >>>> changed
> > >>>> > a class. But it didn't survive the transition to Monticello, we now
> > >>>> > have
> > >>>> to
> > >>>> > remember to write conversion methods for instances that may be stored
> > >>>> > in
> > >>>> a
> > >>>> > project.
> > >>>>
> > >>>> To check my understanding, the "conversion method" might be something
> > >>>> like
> > >>>> #storeDataOn: and #readDataFrom:size: like what I described for
> > >>>> DateAndTime,
> > >>>> is that right?
> > >>>>
> > >>>
> > >>> ???No, it's those weirdly-named methods like Hannes just made
> > >>> in Morphic-hjh.1349.mcz. The store / read methods aren't used
> > >>> per-object.
> > >>> This
> > >>> would have been too expensive back in the interpreter days on slow CPUs,
> > >>> that's why the project is stored as an image-segment, and the segment is
> > >>> written to a SmartRefStream with its out-pointers (references to objects
> > >>> outside the segment, e.g. classes).
> > >>>
> > >>> The SmartRefStream is only used to resolve the class references from the
> > >>> ImageSegment that stores the project.
> > >>>
> > >>>> This is different from the Etoys home screen (the clouds and
> > >>>> drive-a-car)
> > >>>> > which is simply a project that would be loaded by the deployment
> > >>>> > script
> > >>>> > that creates an Etoys image. It does not have to ship with the
> > >>>> > general
> > >>>> > Squeak image.
> > >>>>
> > >>>> I do not know if it will make sense, but I guess my mental image is an
> > >>>> Etoys "deployed image" hosted inside my regular Squeak trunk image. So
> > >>>> I
> > >>>> guess that I am thinking of the "clouds and drive-a-car" project being
> > >>>> loaded the first time that I create a new EtoysProject from normal
> > >>>> Squeak,
> > >>>> and that somehow the subsequent project navigation within that new
> > >>>> "hosted"
> > >>>> Etoys would behave is if I were in a stand-alone Etoys image. Finally,
> > >>>> I would want to be able to escape back to my normal Squeak.
> > >>>
> > >>>
> > >>> ???That sounds good :)
> > >>>
> > >>> - Bert -???
> > >>>
> > >>
> > >
> > >
> >
>

LawsonEnglish

Re: MorphicProject subclass: #EtoysProject

In reply to this post by Hannes Hirzel

Hmmm?

What about if you want to implement a separate hierarchy in a separate System Window, or multiple textures embedded in OpenGL objects?

I’m not sure how Craig Latta’s done some of his Caffeine demos, but I doubt if all those Morphs in various independent Canvases are embedded in a single WorldMorph.

"Debugging is twice as hard as writing the code in the first place.

Therefore, if you write the code as cleverly as possible, you are,

by definition, not smart enough to debug it."

-Brian Kernighan

On Oct 3, 2017, at 06:03, Marcel Taeumel <[hidden email]> wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

Best,
Marcel
Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
On 10/3/17, H. Hirzel wrote:

> Dave
>
> your change set contains the class EtoysProject with
>
> EtoysProject selectors
>
> #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences
> #initializeProjectPreferences #configureOnFirstEntry
> #finalExitActions:)
>
> For complete configuration of a EtoysProject it might be necessary to do
>
> PasteUpMorph subclass: EtoysPasteUpMorph
>
> as well. http://wiki.squeak.org/squeak/6461
>
> Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

> And probably an Etoys specific subclass of WorldMenu would be fine as well
> http://wiki.squeak.org/squeak/6461
>
>
> there is a test project [2] and some more information about adaptions
> needed because of the UI changes in the thread 'Etoys in 2017?' - UI
> preferences [3]. And it would be good to have Etoys methods /
> configuration separate [4].
>
> I suggest that you start go ahead and start implementing this while
> using a test Etoys project dropped onto the desktop.
>
> --Hannes
>
>
> [2] > You simply drop it in. E.g. download this project
>> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
>
> [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM
>
> [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
> "I think it would be great if both Etoys and Scratch were easily
> loadable and unloadable in trunk."
>
> On 10/2/17, David T. Lewis wrote:
>> An EtoysProject is a project that is configured for running Etoys. On
>> first entry to a new EtoysProject, the playground and project preferences
>> are initialized to provide an environment similar to that of a
>> traditional
>> standalone Etoys image.
>>
>> Certain preferences that are required for Etoys are initialized on
>> project
>> entry, overriding their global preference values while this EtoysProject
>> is active. On leaving the project, these preferences are restored to
>> their
>> previous values.
>>
>> "ProjectViewMorph openOn: EtoysProject new"
>>
>> Change set attached for a minimal implementation.
>>
>> Anyone with Etoys knowledge care to help? I do not know enough about
>> Etoys
>> to fill in the rest of the initialization that will be required, but it
>> should not be hard to do.
>>
>> Dave
>>
>>
>

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

Hello

I think we should revive this thread and develop some test cases for
the release 5.2 to be executed manually which show what works and what
does not work

--Hannes

On 11/11/17, LEnglish <[hidden email]> wrote:

> Hmmm?
>
>
> What about if you want to implement a separate hierarchy in a separate
> System Window, or multiple textures embedded in OpenGL objects?
>
> I’m not sure how Craig Latta’s done some of his Caffeine demos, but I doubt
> if all those Morphs in various independent Canvases are embedded in a single
> WorldMorph.
>
> L
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it."
> -Brian Kernighan
>
>
>
>> On Oct 3, 2017, at 06:03, Marcel Taeumel <[hidden email]> wrote:
>>
>> +1 :)
>>
>> And then later: Rename PasteUpMorph to WorldMorph, and keep an empty
>> PasteUpMorph subclass around for compatibility reasons. So many ideas have
>> been ported down to Morph class over the past years. New applications have
>> no reason to ever use other instances of PasteUpMorph.
>>
>> Best,
>> Marcel
>>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
>>>
>>> On 10/3/17, H. Hirzel wrote:
>>> > Dave
>>> >
>>> > your change set contains the class EtoysProject with
>>> >
>>> > EtoysProject selectors
>>> >
>>> > #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences
>>> >
>>> > #initializeProjectPreferences #configureOnFirstEntry
>>> > #finalExitActions:)
>>> >
>>> > For complete configuration of a EtoysProject it might be necessary to
>>> > do
>>> >
>>> > PasteUpMorph subclass: EtoysPasteUpMorph
>>> >
>>> > as well. http://wiki.squeak.org/squeak/6461
>>> >
>>> > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.
>>>
>>> See screen shot attached.
>>>
>>> > And probably an Etoys specific subclass of WorldMenu would be fine as
>>> > well
>>> > http://wiki.squeak.org/squeak/6461
>>> >
>>> >
>>> > there is a test project [2] and some more information about adaptions
>>> > needed because of the UI changes in the thread 'Etoys in 2017?' - UI
>>> > preferences [3]. And it would be good to have Etoys methods /
>>> > configuration separate [4].
>>> >
>>> > I suggest that you start go ahead and start implementing this while
>>> > using a test Etoys project dropped onto the desktop.
>>> >
>>> > --Hannes
>>> >
>>> >
>>> > [2] > You simply drop it in. E.g. download this project
>>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
>>> >
>>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM
>>> >
>>> >
>>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
>>> > "I think it would be great if both Etoys and Scratch were easily
>>> > loadable and unloadable in trunk."
>>> >
>>> > On 10/2/17, David T. Lewis wrote:
>>> >> An EtoysProject is a project that is configured for running Etoys. On
>>> >>
>>> >> first entry to a new EtoysProject, the playground and project
>>> >> preferences
>>> >> are initialized to provide an environment similar to that of a
>>> >> traditional
>>> >> standalone Etoys image.
>>> >>
>>> >> Certain preferences that are required for Etoys are initialized on
>>> >> project
>>> >> entry, overriding their global preference values while this
>>> >> EtoysProject
>>> >> is active. On leaving the project, these preferences are restored to
>>> >> their
>>> >> previous values.
>>> >>
>>> >> "ProjectViewMorph openOn: EtoysProject new"
>>> >>
>>> >> Change set attached for a minimal implementation.
>>> >>
>>> >> Anyone with Etoys knowledge care to help? I do not know enough about
>>> >> Etoys
>>> >> to fill in the rest of the initialization that will be required, but
>>> >> it
>>> >> should not be hard to do.
>>> >>
>>> >> Dave
>>> >>
>>> >>
>>> >
>>>
>>
>
>

David T. Lewis

Re: MorphicProject subclass: #EtoysProject

Hello Hannes,

I do think that we should revive this thread, and I am sorry I have not
done more with it myself.

I also think that it is best to keep EtoysProject outside of trunk until
after the 5.2 release. I would not want to add anything to trunk right
now unless it is complete, well tested, and stable :-)

Dave

On Wed, Jun 06, 2018 at 08:54:21AM +0200, H. Hirzel wrote:

> Hello
>
> I think we should revive this thread and develop some test cases for
> the release 5.2 to be executed manually which show what works and what
> does not work
>
> --Hannes
>
> On 11/11/17, LEnglish <[hidden email]> wrote:
> > Hmmm?
> >
> >
> > What about if you want to implement a separate hierarchy in a separate
> > System Window, or multiple textures embedded in OpenGL objects?
> >
> > I???m not sure how Craig Latta???s done some of his Caffeine demos, but I doubt
> > if all those Morphs in various independent Canvases are embedded in a single
> > WorldMorph.
> >
> > L
> > "Debugging is twice as hard as writing the code in the first place.
> > Therefore, if you write the code as cleverly as possible, you are,
> > by definition, not smart enough to debug it."
> > -Brian Kernighan
> >
> >
> >
> >> On Oct 3, 2017, at 06:03, Marcel Taeumel <[hidden email]> wrote:
> >>
> >> +1 :)
> >>
> >> And then later: Rename PasteUpMorph to WorldMorph, and keep an empty
> >> PasteUpMorph subclass around for compatibility reasons. So many ideas have
> >> been ported down to Morph class over the past years. New applications have
> >> no reason to ever use other instances of PasteUpMorph.
> >>
> >> Best,
> >> Marcel
> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
> >>>
> >>> On 10/3/17, H. Hirzel wrote:
> >>> > Dave
> >>> >
> >>> > your change set contains the class EtoysProject with
> >>> >
> >>> > EtoysProject selectors
> >>> >
> >>> > #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences
> >>> >
> >>> > #initializeProjectPreferences #configureOnFirstEntry
> >>> > #finalExitActions:)
> >>> >
> >>> > For complete configuration of a EtoysProject it might be necessary to
> >>> > do
> >>> >
> >>> > PasteUpMorph subclass: EtoysPasteUpMorph
> >>> >
> >>> > as well. http://wiki.squeak.org/squeak/6461
> >>> >
> >>> > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.
> >>>
> >>> See screen shot attached.
> >>>
> >>> > And probably an Etoys specific subclass of WorldMenu would be fine as
> >>> > well
> >>> > http://wiki.squeak.org/squeak/6461
> >>> >
> >>> >
> >>> > there is a test project [2] and some more information about adaptions
> >>> > needed because of the UI changes in the thread 'Etoys in 2017?' - UI
> >>> > preferences [3]. And it would be good to have Etoys methods /
> >>> > configuration separate [4].
> >>> >
> >>> > I suggest that you start go ahead and start implementing this while
> >>> > using a test Etoys project dropped onto the desktop.
> >>> >
> >>> > --Hannes
> >>> >
> >>> >
> >>> > [2] > You simply drop it in. E.g. download this project
> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
> >>> >
> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM
> >>> >
> >>> >
> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
> >>> > "I think it would be great if both Etoys and Scratch were easily
> >>> > loadable and unloadable in trunk."
> >>> >
> >>> > On 10/2/17, David T. Lewis wrote:
> >>> >> An EtoysProject is a project that is configured for running Etoys. On
> >>> >>
> >>> >> first entry to a new EtoysProject, the playground and project
> >>> >> preferences
> >>> >> are initialized to provide an environment similar to that of a
> >>> >> traditional
> >>> >> standalone Etoys image.
> >>> >>
> >>> >> Certain preferences that are required for Etoys are initialized on
> >>> >> project
> >>> >> entry, overriding their global preference values while this
> >>> >> EtoysProject
> >>> >> is active. On leaving the project, these preferences are restored to
> >>> >> their
> >>> >> previous values.
> >>> >>
> >>> >> "ProjectViewMorph openOn: EtoysProject new"
> >>> >>
> >>> >> Change set attached for a minimal implementation.
> >>> >>
> >>> >> Anyone with Etoys knowledge care to help? I do not know enough about
> >>> >> Etoys
> >>> >> to fill in the rest of the initialization that will be required, but
> >>> >> it
> >>> >> should not be hard to do.
> >>> >>
> >>> >> Dave
> >>> >>
> >>> >>
> >>> >
> >>>
> >>
> >
> >
>

Hannes Hirzel

Re: MorphicProject subclass: #EtoysProject

On 6/7/18, David T. Lewis <[hidden email]> wrote:
> Hello Hannes,
>
> I do think that we should revive this thread, and I am sorry I have not
> done more with it myself.
>
> I also think that it is best to keep EtoysProject outside of trunk until
> after the 5.2 release. I would not want to add anything to trunk right
> now unless it is complete, well tested, and stable :-)

Yes

I downloaded
http://files.squeak.org/trunk/Squeak5.2alpha-18062-32bit/Squeak5.2alpha-18062-32bit-All-in-One.zip

Then I loaded
Name: Project-Etoys-dtl.4
Author: dtl
Time: 5 November 2017, 6:17:07.061654 pm

from

MCHttpRepository
location: 'http://www.squeaksource.com/EtoysProject'
user: ''
password: ''

Then the projects menu -> new projects -> new etoys project
allows me to create a etoys project.

Dowload of
Download

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

and droping it onto the desktop also works.

Going back brings up a deprecation warning but after hitting 'Proceed'
the parent project is brought in.

So the question is now how to open a new etoys project from WITHIN a
etoys project.

Actually the function

EtoysProject openViewOn: nil

Where should it go?

--Hannes

> On Wed, Jun 06, 2018 at 08:54:21AM +0200, H. Hirzel wrote:
>> Hello
>>
>> I think we should revive this thread and develop some test cases for
>> the release 5.2 to be executed manually which show what works and what
>> does not work
>>
>> --Hannes
>>
>> On 11/11/17, LEnglish <[hidden email]> wrote:
>> > Hmmm?
>> >
>> >
>> > What about if you want to implement a separate hierarchy in a separate
>> > System Window, or multiple textures embedded in OpenGL objects?
>> >
>> > I???m not sure how Craig Latta???s done some of his Caffeine demos, but
>> > I doubt
>> > if all those Morphs in various independent Canvases are embedded in a
>> > single
>> > WorldMorph.
>> >
>> > L
>> > "Debugging is twice as hard as writing the code in the first place.
>> > Therefore, if you write the code as cleverly as possible, you are,
>> > by definition, not smart enough to debug it."
>> > -Brian Kernighan
>> >
>> >
>> >
>> >> On Oct 3, 2017, at 06:03, Marcel Taeumel <[hidden email]> wrote:
>> >>
>> >> +1 :)
>> >>
>> >> And then later: Rename PasteUpMorph to WorldMorph, and keep an empty
>> >> PasteUpMorph subclass around for compatibility reasons. So many ideas
>> >> have
>> >> been ported down to Morph class over the past years. New applications
>> >> have
>> >> no reason to ever use other instances of PasteUpMorph.
>> >>
>> >> Best,
>> >> Marcel
>> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
>> >>>
>> >>> On 10/3/17, H. Hirzel wrote:
>> >>> > Dave
>> >>> >
>> >>> > your change set contains the class EtoysProject with
>> >>> >
>> >>> > EtoysProject selectors
>> >>> >
>> >>> > #(#finalEnterActions: #restoreGlobalPreferences
>> >>> > #saveGlobalPreferences
>> >>> >
>> >>> > #initializeProjectPreferences #configureOnFirstEntry
>> >>> > #finalExitActions:)
>> >>> >
>> >>> > For complete configuration of a EtoysProject it might be necessary
>> >>> > to
>> >>> > do
>> >>> >
>> >>> > PasteUpMorph subclass: EtoysPasteUpMorph
>> >>> >
>> >>> > as well. http://wiki.squeak.org/squeak/6461
>> >>> >
>> >>> > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.
>> >>>
>> >>> See screen shot attached.
>> >>>
>> >>> > And probably an Etoys specific subclass of WorldMenu would be fine
>> >>> > as
>> >>> > well
>> >>> > http://wiki.squeak.org/squeak/6461
>> >>> >
>> >>> >
>> >>> > there is a test project [2] and some more information about
>> >>> > adaptions
>> >>> > needed because of the UI changes in the thread 'Etoys in 2017?' - UI
>> >>> > preferences [3]. And it would be good to have Etoys methods /
>> >>> > configuration separate [4].
>> >>> >
>> >>> > I suggest that you start go ahead and start implementing this while
>> >>> > using a test Etoys project dropped onto the desktop.
>> >>> >
>> >>> > --Hannes
>> >>> >
>> >>> >
>> >>> > [2] > You simply drop it in. E.g. download this project
>> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
>> >>> >
>> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01
>> >>> > AM
>> >>> >
>> >>> >
>> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
>> >>> > "I think it would be great if both Etoys and Scratch were easily
>> >>> > loadable and unloadable in trunk."
>> >>> >
>> >>> > On 10/2/17, David T. Lewis wrote:
>> >>> >> An EtoysProject is a project that is configured for running Etoys.
>> >>> >> On
>> >>> >>
>> >>> >> first entry to a new EtoysProject, the playground and project
>> >>> >> preferences
>> >>> >> are initialized to provide an environment similar to that of a
>> >>> >> traditional
>> >>> >> standalone Etoys image.
>> >>> >>
>> >>> >> Certain preferences that are required for Etoys are initialized on
>> >>> >> project
>> >>> >> entry, overriding their global preference values while this
>> >>> >> EtoysProject
>> >>> >> is active. On leaving the project, these preferences are restored
>> >>> >> to
>> >>> >> their
>> >>> >> previous values.
>> >>> >>
>> >>> >> "ProjectViewMorph openOn: EtoysProject new"
>> >>> >>
>> >>> >> Change set attached for a minimal implementation.
>> >>> >>
>> >>> >> Anyone with Etoys knowledge care to help? I do not know enough
>> >>> >> about
>> >>> >> Etoys
>> >>> >> to fill in the rest of the initialization that will be required,
>> >>> >> but
>> >>> >> it
>> >>> >> should not be hard to do.
>> >>> >>
>> >>> >> Dave
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>
>> >
>> >
>>
>
>

1234