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 <hannes.hirzel at gmail.com> 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 <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 -???
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>