[squeak-dev] MorphicProject subclass: #EtoysProject

H. Hirzel hannes.hirzel at gmail.com
Mon Oct 23 03:18:22 UTC 2017


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 -???
>> >>>
>> >>
>> >
>> >
>>
>
>


More information about the Squeak-dev mailing list