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
> >>
> >>
> >