Nice! Seems to work somehow. Graphics are kind of messed up:


Still, it is running. It reacts to user input. :)

Best,
Marcel
Am 19.10.2017 08:48:20 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
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 -​
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171019/2b7b925f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 782989 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171019/2b7b925f/attachment-0001.png>