<div dir="ltr">This has to do with overrides... The Kernel version was overriden or something like that.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-09 7:25 GMT+02:00 Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 09.10.2015, at 03:01, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
<br>
> On Thu, Oct 08, 2015 at 08:31:09PM -0400, David T. Lewis wrote:<br>
>> On Thu, Oct 08, 2015 at 08:05:39PM -0400, David T. Lewis wrote:<br>
>>> On Thu, Oct 08, 2015 at 07:55:51PM -0400, David T. Lewis wrote:<br>
>>>> For squeak4.6, this fixes the bug that Craig reported on vm-dev<br>
>>>> <a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2015-October/019562.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/2015-October/019562.html</a><br>
>>>><br>
>>>> I also see at least one mcz in the squeak46 repository that is empty, apparently<br>
>>>> originally loaded from trunk for the release image, but somehow copied with<br>
>>>> errors from trunk to squeak46.<br>
>>>><br>
>>>> I fixed System-topa.753 by copying the good one in trunk into squeak46. There<br>
>>>> may be a few more bad mcz files in squeak46. I'll fix them as I spot them.<br>
>>>><br>
>>><br>
>>> Compiler-eem.304 and Collections-topa.638 were also empty in the squeak46 repo,<br>
>>> so I copied the good ones from trunk to squeak46.<br>
>>><br>
>><br>
>> I hope I am not doing something stupid here. I wanted to fix the recreateSpecialObjectsArray<br>
>> bug that remained in the squeak46 repo, and in doing so noticed some empty MCZ<br>
>> packages in that repo. I presume that this is an error, some artifact of copying<br>
>> them from trunk during the 4.6/5.0 release process. So I fixed (?) this by<br>
>> copying the good (not empty) MCZ files from trunk to squeak46.<br>
>><br>
>> All is well, except that I now have a dirty package in Kernel after doing an<br>
>> updateFromServer. The conflicting method is CompiledMethod>>hasBreakpoint, which<br>
>> is one that was moved around and refactored in the later trunk development.<br>
>><br>
>> Before I do anything dangerous to try to "fix" this (after all, hasBreakpoint<br>
>> will hang the system if it goes missing), can someone (Chris?) please confirm<br>
>> that those packages were *not* supposed to be empty, and that the good copies<br>
>> from trunk would be the right thing to have in squeak46?<br>
>><br>
><br>
> And I guess that the related question would be - for a fully updated Squeak 4.6<br>
> image, what is the correct implementation of CompiledMethod>>hasBreakpoint ?<br>
><br>
> Is it this:<br>
><br>
> CompiledMethod>>hasBreakpoint<br>
> ^ false<br>
><br>
><br>
> Or this:<br>
><br>
> CompiledMethod>>hasBreakpoint<br>
> ^BreakpointManager methodHasBreakpoint: self<br>
><br>
> I think that the former version is the pre-Spur implementation, and the<br>
> latter came from the Spur transition in trunk Kernel-cmm.936.<br>
><br>
> I note also that WrappedBreakpoint>>hasBreakpoint just answers true in<br>
> squeak46 so I am guessing the corresponding CompiledMethod>>hasBreakpoint<br>
> would just answer false.<br>
<br>
</div></div>No, these are two coexisting mechanisms of breakpointing<br>
<br>
a) breakpoint manager has an external list of breakpointed messages and does the<br>
breakpointing. Hence the second version is correct.<br>
b) wrapped breakpoint is a method wrapper that wraps a compiled method in the<br>
method dict and thus can, imposing the CM, just answer true.<br>
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888"> -Tobias<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>