Squeak 4.6: System-dtl.754.mcz

> David T. Lewis uploaded a new version of System to project Squeak 4.6:
> http://source.squeak.org/squeak46/System-dtl.754.mcz
>
> ==================== Summary ====================
>
> Name: System-dtl.754
> Author: dtl
> Time: 8 October 2015, 7:47:37.644 pm
> UUID: 7875a786-e95b-47c8-ba8d-10ec0bcf5f63
> Ancestors: System-topa.753
>
> Fix ancient typo in recreateSpecialObjectsArray. Bug introduced April 2013 in System-eem.521, present in trunk through July 2015 System-topa.753, resolved in (Spur) trunk System-cmm.754.
>
> =============== Diff against System-topa.753 ===============
>
> Item was changed:
>   ----- Method: SmalltalkImage>>recreateSpecialObjectsArray (in category 'special objects') -----
>   recreateSpecialObjectsArray
>   "Smalltalk recreateSpecialObjectsArray"
>  
>   "To external package developers:
>   **** DO NOT OVERRIDE THIS METHOD.  *****
>   If you are writing a plugin and need additional special object(s) for your own use,
>   use addGCRoot() function and use own, separate special objects registry "
>  
>   "The Special Objects Array is an array of objects used by the Squeak virtual machine.
>   Its contents are critical and accesses to it by the VM are unchecked, so don't even
>   think of playing here unless you know what you are doing."
>   | newArray |
>   newArray := Array new: 58.
>   "Nil false and true get used throughout the interpreter"
>   newArray at: 1 put: nil.
>   newArray at: 2 put: false.
>   newArray at: 3 put: true.
>   "This association holds the active process (a ProcessScheduler)"
>   newArray at: 4 put: (self specialObjectsArray at: 4) "(self bindingOf: #Processor) but it answers an Alias".
>   "Numerous classes below used for type checking and instantiation"
>   newArray at: 5 put: Bitmap.
>   newArray at: 6 put: SmallInteger.
>   newArray at: 7 put: ByteString.
>   newArray at: 8 put: Array.
>   newArray at: 9 put: Smalltalk.
>   newArray at: 10 put: Float.
>   newArray at: 11 put: MethodContext.
>   newArray at: 12 put: BlockContext.
>   newArray at: 13 put: Point.
>   newArray at: 14 put: LargePositiveInteger.
>   newArray at: 15 put: Display.
>   newArray at: 16 put: Message.
>   newArray at: 17 put: CompiledMethod.
>   newArray at: 18 put: (self specialObjectsArray at: 18).
>   "(low space Semaphore)"
>   newArray at: 19 put: Semaphore.
>   newArray at: 20 put: Character.
>   newArray at: 21 put: #doesNotUnderstand:.
>   newArray at: 22 put: #cannotReturn:.
>   newArray at: 23 put: nil. "This is the process signalling low space."
>   "An array of the 32 selectors that are compiled as special bytecodes,
>   paired alternately with the number of arguments each takes."
>   newArray at: 24 put: #( #+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1
>   #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1
>   #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0
>   #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0 ).
>   "An array of the 255 Characters in ascii order.
>   Cog inlines table into machine code at: prim so do not regenerate it."
>   newArray at: 25 put: (self specialObjectsArray at: 25).
>   newArray at: 26 put: #mustBeBoolean.
>   newArray at: 27 put: ByteArray.
>   newArray at: 28 put: Process.
>   "An array of up to 31 classes whose instances will have compact headers"
>   newArray at: 29 put: self compactClassesArray.
>   newArray at: 30 put: (self specialObjectsArray at: 30). "(delay Semaphore)"
>   newArray at: 31 put: (self specialObjectsArray at: 31). "(user interrupt Semaphore)"
>   "Entries 32 - 34 unreferenced. Previously these contained prototype instances to be copied for fast initialization"
>   newArray at: 32 put: nil. "was (Float new: 2)"
>   newArray at: 33 put: nil. "was (LargePositiveInteger new: 4)"
>   newArray at: 34 put: nil. "was Point new"
>   newArray at: 35 put: #cannotInterpret:.
>   "Note: This must be fixed once we start using context prototypes (yeah, right)"
>   "(MethodContext new: CompiledMethod fullFrameSize)."
>   newArray at: 36 put: (self specialObjectsArray at: 36). "Is the prototype MethodContext (unused by the VM)"
>   newArray at: 37 put: BlockClosure.
>   "(BlockContext new: CompiledMethod fullFrameSize)."
>   newArray at: 38 put: (self specialObjectsArray at: 38). "Is the prototype BlockContext (unused by the VM)"
>   "array of objects referred to by external code"
>   newArray at: 39 put: (self specialObjectsArray at: 39). "preserve external semaphores"
>   newArray at: 40 put: nil. "Reserved for Mutex in Cog VMs"
>   newArray at: 41 put: nil. "Reserved for a LinkedList instance for overlapped calls in CogMT"
>   "finalization Semaphore"
>   newArray at: 42 put: ((self specialObjectsArray at: 42) ifNil: [Semaphore new]).
>   newArray at: 43 put: LargeNegativeInteger.
>   "External objects for callout.
>   Note: Written so that one can actually completely remove the FFI."
>   newArray at: 44 put: (self at: #ExternalAddress ifAbsent: []).
>   newArray at: 45 put: (self at: #ExternalStructure ifAbsent: []).
>   newArray at: 46 put: (self at: #ExternalData ifAbsent: []).
>   newArray at: 47 put: (self at: #ExternalFunction ifAbsent: []).
>   newArray at: 48 put: (self at: #ExternalLibrary ifAbsent: []).
>   newArray at: 49 put: #aboutToReturn:through:.
>   newArray at: 50 put: #run:with:in:.
>   "51 reserved for immutability message"
>   "newArray at: 51 put: #attemptToAssign:withIndex:."
>   newArray at: 51 put: (self specialObjectsArray at: 51 ifAbsent: []).
>   newArray at: 52 put: #(nil "nil => generic error" #'bad receiver'
>   #'bad argument' #'bad index'
>   #'bad number of arguments'
>   #'inappropriate operation'  #'unsupported operation'
>   #'no modification' #'insufficient object memory'
>   #'insufficient C memory' #'not found' #'bad method'
>   #'internal error in named primitive machinery'
>   #'object may move' #'resource limit exceeded'
>   #'object is pinned').
>   "53 to 55 are for Alien"
>   newArray at: 53 put: (self at: #Alien ifAbsent: []).
> + newArray at: 54 put: #invokeCallbackContext:. "use invokeCallback:stack:registers:jmpbuf: for old Alien callbacks."
> - newArray at: 54 put: #invokeCallbackContext::. "use invokeCallback:stack:registers:jmpbuf: for old Alien callbacks."
>   newArray at: 55 put: (self at: #UnsafeAlien ifAbsent: []).
>  
>   "Weak reference finalization"
>   newArray at: 56 put: (self at: #WeakFinalizationList ifAbsent: []).
>  
>   "reserved for foreign callback process"
>   newArray at: 57 put: (self specialObjectsArray at: 57 ifAbsent: []).
>  
>   newArray at: 58 put: #unusedBytecode.
>  
>   "Now replace the interpreter's reference in one atomic operation"
>   self specialObjectsArray becomeForward: newArray
>   !
>

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

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

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

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

> On Oct 8, 2015, at 6:01 PM, David T. Lewis <[hidden email]> 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
>
>

>
> _,,,^..^,,,_ (phone)
>
>> On Oct 8, 2015, at 6:01 PM, David T. Lewis <[hidden email]> 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
>>
>>
>

>
> _,,,^..^,,,_ (phone)
>
>> On Oct 8, 2015, at 6:01 PM, David T. Lewis <[hidden email]> 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
>>
>>
>

> 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 <[hidden email]> 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
>>
>>
>

> 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 <[hidden email]> 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 <[hidden email]> 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
> >>
> >>
> >

> 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 <[hidden email]> 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 <[hidden email]> 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
>> >>
>> >>
>> >
>