On Wed, Apr 24, 2013 at 11:24 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> 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.
>
Could a preamble with the method in concern inlined work ?

Karl


>
>
> 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 -
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130424/1f20cefd/attachment.html