It seems to work fine.

On Fri, Oct 9, 2015 at 8:47 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> Chris,
>
> When you get a chance, can you please try updating a 4.6 image and see
> if the result looks good to you? I get one dirty package, which maybe just
> means we need to add another update map (or fix an existing one).
>
> I was basically just trying to make sure that my attempt to fix the empty
> MCZ files was the right thing to do, and that the resulting updated image
> was in fact correct. I was not trying to provide any additional updates to
> the 4.6 stream unless they are really necessary.
>
> Thanks,
> Dave
>
>
> On Fri, Oct 09, 2015 at 10:07:17AM -0500, Chris Muller wrote:
>> Introducing MC overrides into the standard package structure created a
>> giant PITA for the already-delayed release.  Frankly, I think
>> Breakpoints should be moved an external package at this point.  It
>> introduces package dependency hackings, compiled method hackings, and
>> file-out hackings.  All just so I can put an IMPLICIT "self halt" at
>> the TOP of a method ONLY.  I'm sorry Eliot, maybe I'm just not seeing
>> it, but it seems like an insanely bad trade-off..
>>
>> On Fri, Oct 9, 2015 at 1:43 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> > Hi David,
>> >
>> >     Re hasBreakpoint, IIRC BreakpointManager is in System, so the right thing is that the ^false version is in the Kernel package but that it is overridden by the ^BreakpointManager methodHasBreakpoint: self version in System.  I think I failed in achieving this in 5.0.
>> >
>> > _,,,^..^,,,_ (phone)
>> >
>> >> On Oct 8, 2015, at 6:01 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> >>
>> >>> On Thu, Oct 08, 2015 at 08:31:09PM -0400, David T. Lewis wrote:
>> >>>> On Thu, Oct 08, 2015 at 08:05:39PM -0400, David T. Lewis wrote:
>> >>>>> On Thu, Oct 08, 2015 at 07:55:51PM -0400, David T. Lewis wrote:
>> >>>>> For squeak4.6, this fixes the bug that Craig reported on vm-dev
>> >>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2015-October/019562.html
>> >>>>>
>> >>>>> I also see at least one mcz in the squeak46 repository that is empty, apparently
>> >>>>> originally loaded from trunk for the release image, but somehow copied with
>> >>>>> errors from trunk to squeak46.
>> >>>>>
>> >>>>> I fixed System-topa.753 by copying the good one in trunk into squeak46. There
>> >>>>> may be a few more bad mcz files in squeak46. I'll fix them as I spot them.
>> >>>>
>> >>>> Compiler-eem.304 and Collections-topa.638 were also empty in the squeak46 repo,
>> >>>> so I copied the good ones from trunk to squeak46.
>> >>>
>> >>> I hope I am not doing something stupid here. I wanted to fix the recreateSpecialObjectsArray
>> >>> bug that remained in the squeak46 repo, and in doing so noticed some empty MCZ
>> >>> packages in that repo. I presume that this is an error, some artifact of copying
>> >>> them from trunk during the 4.6/5.0 release process. So I fixed (?) this by
>> >>> copying the good (not empty) MCZ files from trunk to squeak46.
>> >>>
>> >>> All is well, except that I now have a dirty package in Kernel after doing an
>> >>> updateFromServer. The conflicting method is CompiledMethod>>hasBreakpoint, which
>> >>> is one that was moved around and refactored in the later trunk development.
>> >>>
>> >>> Before I do anything dangerous to try to "fix" this (after all, hasBreakpoint
>> >>> will hang the system if it goes missing), can someone (Chris?) please confirm
>> >>> that those packages were *not* supposed to be empty, and that the good copies
>> >>> from trunk would be the right thing to have in squeak46?
>> >>
>> >> And I guess that the related question would be - for a fully updated Squeak 4.6
>> >> image, what is the correct implementation of CompiledMethod>>hasBreakpoint ?
>> >>
>> >> Is it this:
>> >>
>> >>  CompiledMethod>>hasBreakpoint
>> >>      ^ false
>> >>
>> >>
>> >> Or this:
>> >>
>> >>  CompiledMethod>>hasBreakpoint
>> >>      ^BreakpointManager methodHasBreakpoint: self
>> >>
>> >> I think that the former version is the pre-Spur implementation, and the
>> >> latter came from the Spur transition in trunk Kernel-cmm.936.
>> >>
>> >> I note also that WrappedBreakpoint>>hasBreakpoint just answers true in
>> >> squeak46 so I am guessing the corresponding CompiledMethod>>hasBreakpoint
>> >> would just answer false.
>> >>
>> >> Is that right?
>> >>
>> >> Thanks,
>> >> Dave
>> >>
>> >>
>> >
>