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 <hannes.hirzel at gmail.com> wrote:
> On 10/19/17, David T. Lewis <lewis at mail.msen.com> 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 <marcel.taeumel at hpi.de> 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 <hannes.hirzel at gmail.com>:
>>> > 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 -???
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>
>>
>