[squeak-dev] Empty packages in squeak46 repo (was: Re: Squeak 4.6: System-dtl.754.mcz)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Oct 9 06:40:13 UTC 2015


This has to do with overrides... The Kernel version was overriden or
something like that.

2015-10-09 7:25 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:

>
> On 09.10.2015, at 03:01, 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.
>
> No, these are two coexisting mechanisms of breakpointing
>
> a) breakpoint manager has an external list of breakpointed messages and
> does the
>    breakpointing. Hence the second version is correct.
> b) wrapped breakpoint is a method wrapper that wraps a compiled method in
> the
>    method dict and thus can, imposing the CM, just answer true.
>
> Best regards
>         -Tobias
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20151009/5d230f11/attachment.htm


More information about the Squeak-dev mailing list