Debug halo handle

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug halo handle

Bert Freudenberg
On 19.03.2012, at 22:35, Bert Freudenberg wrote:

> I built the image and uploaded to svn. New example projects are in. However, there now is an error on startup, some how the home project's world go broken :/
>
> - Bert -

I now found the ultimate cause for the wrong value of the debugHaloHandle preference was the Morphic-kfr.88 commit. Here is what happened:

* Morphic-kfr.88 removed an instance variable from PasteUpMorph
* when I built the release, the home screen project was loaded from file. it had an old (now obsolete) PasteUpMorph in it.
* I saved the image. Until this point, the debugHaloHandle was correct.

* when testing the new image, I got an error about "AnObsoleteFake37PasteUpMorph". This prompted me to write the above message to Karl.
* I went into the project and fixed the script manually.
* then saved the image without running the release builder
* that caused my personal preference setting of debugHaloHandle to be saved

So PasteUpMorph changed its shape, and that somehow caused problems when loading an older project. I'm not quite sure why, it should have been fine, but for now I just added back that inst var.

- Bert -
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Image segment loading problem

Bert Freudenberg
Hi Ted,

we have a strange problem with a class reshape. We removed an inst var from PasteUpMorph. When loading an old project, somehow an ObsoleteFake37PasteUpMorph survives, and is sent a message, which blows up of course. But the Fake37 classes should only be temporary. So I wonder how that could happen?

The project in question is the Home.007.pr project in Etoys. The easiest way to reproduce it would be to run Etoys-To-Go-5.0-RC1 from
        http://squeakland.org/download/
and drag Home.007.pr into it (which is in the Contents/Resources folder inside the app bundle). Or if you don't want to download that new version, just use some Etoys4 release, remove PasteUpMorph's unused autoLineLayout variable, and then load the project.

The interesting thing is that the project including its world loads fine, but somehow the world's "script1" (which I think you wrote) accesses that obsolete paste-up.

Oh, you know what, spelling this out after having stepped through the loading/conversion code, is it possible that the Fake37PasteUpMorph *class* is never converted into the real PasteUpMorph class?! I only saw instances being converted - but the script in question is special because it refers to the class.

- Bert -

Begin forwarded message:

> From: Bert Freudenberg <[hidden email]>
> Subject: [etoys-dev] Debug halo handle
> Date: 22. März 2012 21:06:02 MEZ
> To: etoys dev <[hidden email]>
>
> On 19.03.2012, at 22:35, Bert Freudenberg wrote:
>
>> I built the image and uploaded to svn. New example projects are in. However, there now is an error on startup, some how the home project's world go broken :/
>>
>> - Bert -
>
> I now found the ultimate cause for the wrong value of the debugHaloHandle preference was the Morphic-kfr.88 commit. Here is what happened:
>
> * Morphic-kfr.88 removed an instance variable from PasteUpMorph
> * when I built the release, the home screen project was loaded from file. it had an old (now obsolete) PasteUpMorph in it.
> * I saved the image. Until this point, the debugHaloHandle was correct.
>
> * when testing the new image, I got an error about "AnObsoleteFake37PasteUpMorph". This prompted me to write the above message to Karl.
> * I went into the project and fixed the script manually.
> * then saved the image without running the release builder
> * that caused my personal preference setting of debugHaloHandle to be saved
>
> So PasteUpMorph changed its shape, and that somehow caused problems when loading an older project. I'm not quite sure why, it should have been fine, but for now I just added back that inst var.
>
> - Bert -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image segment loading problem

Bert Freudenberg
On 22.03.2012, at 21:45, Bert Freudenberg wrote:

> Oh, you know what, spelling this out after having stepped through the loading/conversion code, is it possible that the Fake37PasteUpMorph *class* is never converted into the real PasteUpMorph class?! I only saw instances being converted - but the script in question is special because it refers to the class.
>
> - Bert -

Looks like I was on the right track. See attached change. It forward-becomes the class too, and that lets the project load just fine. Unless you see a problem in this, we'll use it :)

- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

ImageSegment-comeFullyUpOnReload.st (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Image segment loading problem

Ted Kaehler-2
Bert,
        Your fix, ImageSegment-comeFullyUpOnReload.st, looks good.  It work.
        We should put this into other Squeak images, too.

--Ted.


--
Ted Kaehler
If at first you don't succeed  ...  get new batteries.    --anon
Viewpoints Research Institute
http://www.vpri.org/html/team_bios/kaehler.html
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev