[squeak-dev] Moving methods (was: The Trunk: Graphics-fbs.209.mcz)

Frank Shearar frank.shearar at gmail.com
Wed Apr 24 09:24:59 UTC 2013


On 23 April 2013 15:14, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2013-04-23, at 11:41, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> I've pushed out a new config map, update-fbs.231, which loads Morphic
>> before Graphics, thus ensuring that there's always a #asGrafPort in
>> the image. I still don't like that Cog sprang a leak there, but at
>> least things are back on track.
>>
>> All I'd wanted to do was move a method from one package to another: I
>> really hadn't expected to completely smash updating. Is there anything
>> I could have done before pushing to trunk to prevent this?
>>
>> frank
>
> Moving an active method from one package to another is fragile, as you discovered. The moved-to package must be loaded first, otherwise the method is deleted from the system.
>
> The proper way to let MC handle this would be to load the two packages together, in which case the order would not matter. But this had worse consequences so we're using the update-map order instead.

Do you mean using slices? If so, what are the worse problems?

> A possible solution would be to go through the whole update map first and find the "bad" moves (those where a method or class would be deleted and later added again) and load only these. Since it only reclassifies, the actual system behavior would be unchanged. But the loading would succeed without introducing obsolete instances and missing methods.

That sounds like it could work. You have to get all those new updates
anyway, so getting them up front and "merging" them wouldn't be (much
of) a performance hit.

> - Bert -


More information about the Squeak-dev mailing list