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

Tobias Pape Das.Linux at gmx.de
Fri Oct 9 07:16:58 UTC 2015


Hi,

On 09.10.2015, at 08:43, 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.

Ah, that happens when I reply without actually look.
Yes, Eliot is right.

Best regards
	-Tobias

> 
> _,,,^..^,,,_ (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
>> 
>> 
> 



More information about the Squeak-dev mailing list