[squeak-dev] Empty packages in squeak46 repo (was: Re: Squeak
Das.Linux at gmx.de
Fri Oct 9 05:25:31 UTC 2015
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
>>>> 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:
> ^ false
> Or this:
> ^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.
More information about the Squeak-dev