About 512 MB changes patch

> So I did
>
> - loaded LargeSourceFilePointers-kwl.0.cs (said Proceed)
> - did the doit
> - loaded LargeSourceFilePointers-kwl.1.cs
> - did the doit
>
> loaded RefactoringEngine
> run Lint on a package, did some fixes, commited via Monticello
> run Lint on an other package, did some fixes, oops trace below
>
> As you can see a CompiledMethod is in the preamble.
> size of changes file:
> 31377626
>
> From: 2 October 2006 8:36:33 pm
>
> VM: unix - a SmalltalkImage
> Image: Squeak3.9alpha [latest update: #7051]
>
> SecurityManager state:
> Restricted: false
> FileAccess: true
> SocketAccess: true
>
> CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> Receiver: a CompiledMethod (614)
> Arguments and temporary variables:
> aMessage: findString: ''methodsFor:'' startingAt: 1
> Receiver''s instance variables:
> a CompiledMethod (614)
>
> CompiledMethod>>timeStamp
> Receiver: a CompiledMethod (614)
> Arguments and temporary variables:
> file: MultiByteFileStream:
> ''/home/upnip/data/uni/masterarbeit/images/7051/Squea...etc...
> preamble: a CompiledMethod (614)
> stamp: ''''
> tokens: nil
> tokenCount: nil
> ex: nil
> Receiver''s instance variables:
> a CompiledMethod (614)
>
> MethodReference>>timeStamp
> Receiver: a MethodReference PKBarLayout >> initialize
> Arguments and temporary variables:
>
> Receiver''s instance variables:
> classSymbol: #PKBarLayout
> classIsMeta: false
> methodSymbol: #initialize
> stringVersion: ''PKBarLayout initialize''
>
> MCMethodDefinition class>>forMethodReference:
> Receiver: MCMethodDefinition
> Arguments and temporary variables:
> aMethodReference: a MethodReference PKBarLayout >> initialize
> definition: nil
> Receiver''s instance variables:
> superclass: MCDefinition
> methodDict: a MethodDictionary(#=->a CompiledMethod (643)
> #accept:->a CompiledM...etc...
> format: 142
> instanceVariables: #(''classIsMeta'' ''source'' ''category''
> ''selector'' ''className'' ''...etc...
> organization: (''accessing'' actualClass category classIsMeta
> className fullTimeS...etc...
> subclasses: nil
> name: #MCMethodDefinition
> classPool: a Dictionary(#Definitions->a WeakIdentityKeyDictionary
> (size 239) )
> sharedPools: nil
> environment: a SystemDictionary(lots of globals)
> category: #''Monticello-Modeling''
> traitComposition: nil
> localSelectors: nil
>
>
> --- The full stack ---
> CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> CompiledMethod>>timeStamp
> MethodReference>>timeStamp
> MCMethodDefinition class>>forMethodReference:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> MethodReference>>asMethodDefinition
> [] in MCPackage>>snapshot {[:ea | definitions add: ea  
> asMethodDefinition]}
> [] in Array(SequenceableCollection)>>do:displayingProgress: {[:each :i
> |  bar value: i.  aBlock value: each]}
> Array(SequenceableCollection)>>withIndexDo:
> [] in Array(SequenceableCollection)>>do:displayingProgress: {[:bar |
> self   withIndexDo: [:each :i |     bar value: i.    aBlock value:
> e...]}
> [] in ProgressInitiationException>>defaultMorphicAction {[result :=
> workBlock value: progress]}
> BlockContext>>ensure:
> ProgressInitiationException>>defaultMorphicAction
> ProgressInitiationException>>defaultAction
> UndefinedObject>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> ProgressInitiationException(Exception)>>signal
> ProgressInitiationException>>display:at:from:to:during:
> ProgressInitiationException class>>display:at:from:to:during:
> ByteString(String)>>displayProgressAt:from:to:during:
> Array(SequenceableCollection)>>do:displayingProgress:
> MCPackage>>snapshot
> MCWorkingCopy>>changesRelativeToRepository:
> MCWorkingCopyBrowser>>viewChanges
> PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
> PluggableButtonMorphPlus>>performAction
> [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m |
> (m containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
> Array(SequenceableCollection)>>do:
> PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
> PluggableButtonMorphPlus>>mouseUp:
> PluggableButtonMorphPlus(Morph)>>handleMouseUp:
> MouseButtonEvent>>sentTo:
> PluggableButtonMorphPlus(Morph)>>handleEvent:
> PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
> ActiveEvent := anEvent.  result := focusHolder     han...]}
> [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
> BlockContext>>on:do:
> PasteUpMorph>>becomeActiveDuring:
> HandMorph>>sendFocusEvent:to:clear:
> HandMorph>>sendEvent:focus:clear:
> HandMorph>>sendMouseEvent:
> HandMorph>>handleEvent:
> HandMorph>>processEvents
> [] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h
> processEvents.  capturingGesture := capturingGest...]}
> ...etc...
>
> Cheers
> Philippe
>

> Hi
>
> Ok, I had an 3.9 7051 image that was very close at 32 MB. I could
> either rebuild a new image from scratch or use the patch from Klaus.
> Now I knew about the risks (wich are why it's not in 3.9) and that it
> has not seen enough testing. But if nobody tests it because it has not
> seen enough testing then nobody will test it and it will never see
> enogh testing. So it basically boiled down to 'Who if not me? When if
> not now?'
>
> So I did
>
> - loaded LargeSourceFilePointers-kwl.0.cs (said Proceed)
> - did the doit
> - loaded LargeSourceFilePointers-kwl.1.cs
> - did the doit
>
> loaded RefactoringEngine
> run Lint on a package, did some fixes, commited via Monticello
> run Lint on an other package, did some fixes, oops trace below
>
> As you can see a CompiledMethod is in the preamble.
> size of changes file:
> 31377626
>
> From: 2 October 2006 8:36:33 pm
>
> VM: unix - a SmalltalkImage
> Image: Squeak3.9alpha [latest update: #7051]
>
> SecurityManager state:
> Restricted: false
> FileAccess: true
> SocketAccess: true
>
> CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> Receiver: a CompiledMethod (614)
> Arguments and temporary variables:
> aMessage: findString: ''methodsFor:'' startingAt: 1
> Receiver''s instance variables:
> a CompiledMethod (614)
>
> CompiledMethod>>timeStamp
> Receiver: a CompiledMethod (614)
> Arguments and temporary variables:
> file: MultiByteFileStream:
> ''/home/upnip/data/uni/masterarbeit/images/7051/Squea...etc...
> preamble: a CompiledMethod (614)
> stamp: ''''
> tokens: nil
> tokenCount: nil
> ex: nil
> Receiver''s instance variables:
> a CompiledMethod (614)
>
> MethodReference>>timeStamp
> Receiver: a MethodReference PKBarLayout >> initialize
> Arguments and temporary variables:
>
> Receiver''s instance variables:
> classSymbol: #PKBarLayout
> classIsMeta: false
> methodSymbol: #initialize
> stringVersion: ''PKBarLayout initialize''
>
> MCMethodDefinition class>>forMethodReference:
> Receiver: MCMethodDefinition
> Arguments and temporary variables:
> aMethodReference: a MethodReference PKBarLayout >> initialize
> definition: nil
> Receiver''s instance variables:
> superclass: MCDefinition
> methodDict: a MethodDictionary(#=->a CompiledMethod (643)
> #accept:->a CompiledM...etc...
> format: 142
> instanceVariables: #(''classIsMeta'' ''source'' ''category''
> ''selector'' ''className'' ''...etc...
> organization: (''accessing'' actualClass category classIsMeta
> className fullTimeS...etc...
> subclasses: nil
> name: #MCMethodDefinition
> classPool: a Dictionary(#Definitions->a  
> WeakIdentityKeyDictionary(size 239) )
> sharedPools: nil
> environment: a SystemDictionary(lots of globals)
> category: #''Monticello-Modeling''
> traitComposition: nil
> localSelectors: nil
>
>
> --- The full stack ---
> CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> CompiledMethod>>timeStamp
> MethodReference>>timeStamp
> MCMethodDefinition class>>forMethodReference:
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> MethodReference>>asMethodDefinition
> [] in MCPackage>>snapshot {[:ea | definitions add: ea  
> asMethodDefinition]}
> [] in Array(SequenceableCollection)>>do:displayingProgress: {[:each :i
> |  bar value: i.  aBlock value: each]}
> Array(SequenceableCollection)>>withIndexDo:
> [] in Array(SequenceableCollection)>>do:displayingProgress: {[:bar |
> self   withIndexDo: [:each :i |     bar value: i.    aBlock value:
> e...]}
> [] in ProgressInitiationException>>defaultMorphicAction {[result :=
> workBlock value: progress]}
> BlockContext>>ensure:
> ProgressInitiationException>>defaultMorphicAction
> ProgressInitiationException>>defaultAction
> UndefinedObject>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> ProgressInitiationException(Exception)>>signal
> ProgressInitiationException>>display:at:from:to:during:
> ProgressInitiationException class>>display:at:from:to:during:
> ByteString(String)>>displayProgressAt:from:to:during:
> Array(SequenceableCollection)>>do:displayingProgress:
> MCPackage>>snapshot
> MCWorkingCopy>>changesRelativeToRepository:
> MCWorkingCopyBrowser>>viewChanges
> PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
> PluggableButtonMorphPlus>>performAction
> [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m |
> (m containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
> Array(SequenceableCollection)>>do:
> PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
> PluggableButtonMorphPlus>>mouseUp:
> PluggableButtonMorphPlus(Morph)>>handleMouseUp:
> MouseButtonEvent>>sentTo:
> PluggableButtonMorphPlus(Morph)>>handleEvent:
> PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
> ActiveEvent := anEvent.  result := focusHolder     han...]}
> [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
> BlockContext>>on:do:
> PasteUpMorph>>becomeActiveDuring:
> HandMorph>>sendFocusEvent:to:clear:
> HandMorph>>sendEvent:focus:clear:
> HandMorph>>sendMouseEvent:
> HandMorph>>handleEvent:
> HandMorph>>processEvents
> [] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h
> processEvents.  capturingGesture := capturingGest..]}
> ...etc...
>
> Cheers
> Philippe
>
>

> -
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/106542.html
>
> And while we are here: I do not expect such problems when .source and
> .changes are *both* produced in the 512 MB format (versus: as a mixture of
> the old and the new format).
>
> FWIW: now that Squeak-dev image is available (thanks again to Damien and
> contributors) I could use the Squeak-dev image tool mix for testing a
> reasonable set of clients ...
>
> If the 512 MB changes patch is planned for 3.10: I'm ready to completing
> the patch and tests (except during the 2nd half of November).
>
> /Klaus
>
> On Mon, 02 Oct 2006 20:41:55 +0200, Philippe Marschall wrote:
>
> > Hi
> >
> > Ok, I had an 3.9 7051 image that was very close at 32 MB. I could
> > either rebuild a new image from scratch or use the patch from Klaus.
> > Now I knew about the risks (wich are why it's not in 3.9) and that it
> > has not seen enough testing. But if nobody tests it because it has not
> > seen enough testing then nobody will test it and it will never see
> > enogh testing. So it basically boiled down to 'Who if not me? When if
> > not now?'
> >
> > So I did
> >
> > - loaded LargeSourceFilePointers-kwl.0.cs (said Proceed)
> > - did the doit
> > - loaded LargeSourceFilePointers-kwl.1.cs
> > - did the doit
> >
> > loaded RefactoringEngine
> > run Lint on a package, did some fixes, commited via Monticello
> > run Lint on an other package, did some fixes, oops trace below
> >
> > As you can see a CompiledMethod is in the preamble.
> > size of changes file:
> > 31377626
> >
> > From: 2 October 2006 8:36:33 pm
> >
> > VM: unix - a SmalltalkImage
> > Image: Squeak3.9alpha [latest update: #7051]
> >
> > SecurityManager state:
> > Restricted: false
> > FileAccess: true
> > SocketAccess: true
> >
> > CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> >       Receiver: a CompiledMethod (614)
> >       Arguments and temporary variables:
> >               aMessage:       findString: ''methodsFor:'' startingAt: 1
> >       Receiver''s instance variables:
> > a CompiledMethod (614)
> >
> > CompiledMethod>>timeStamp
> >       Receiver: a CompiledMethod (614)
> >       Arguments and temporary variables:
> >               file:   MultiByteFileStream:
> > ''/home/upnip/data/uni/masterarbeit/images/7051/Squea...etc...
> >               preamble:       a CompiledMethod (614)
> >               stamp:  ''''
> >               tokens:         nil
> >               tokenCount:     nil
> >               ex:     nil
> >       Receiver''s instance variables:
> > a CompiledMethod (614)
> >
> > MethodReference>>timeStamp
> >       Receiver: a MethodReference PKBarLayout >> initialize
> >       Arguments and temporary variables:
> >
> >       Receiver''s instance variables:
> >               classSymbol:    #PKBarLayout
> >               classIsMeta:    false
> >               methodSymbol:   #initialize
> >               stringVersion:  ''PKBarLayout initialize''
> >
> > MCMethodDefinition class>>forMethodReference:
> >       Receiver: MCMethodDefinition
> >       Arguments and temporary variables:
> >               aMethodReference:       a MethodReference PKBarLayout >> initialize
> >               definition:     nil
> >       Receiver''s instance variables:
> >               superclass:     MCDefinition
> >               methodDict:     a MethodDictionary(#=->a CompiledMethod (643)
> > #accept:->a CompiledM...etc...
> >               format:         142
> >               instanceVariables:      #(''classIsMeta'' ''source'' ''category''
> > ''selector'' ''className'' ''...etc...
> >               organization:   (''accessing'' actualClass category classIsMeta
> > className fullTimeS...etc...
> >               subclasses:     nil
> >               name:   #MCMethodDefinition
> >               classPool:      a Dictionary(#Definitions->a
> > WeakIdentityKeyDictionary(size 239) )
> >               sharedPools:    nil
> >               environment:    a SystemDictionary(lots of globals)
> >               category:       #''Monticello-Modeling''
> >               traitComposition:       nil
> >               localSelectors:         nil
> >
> >
> > --- The full stack ---
> > CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
> > CompiledMethod>>timeStamp
> > MethodReference>>timeStamp
> > MCMethodDefinition class>>forMethodReference:
> >  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > MethodReference>>asMethodDefinition
> > [] in MCPackage>>snapshot {[:ea | definitions add: ea
> > asMethodDefinition]}
> > [] in Array(SequenceableCollection)>>do:displayingProgress: {[:each :i
> > |  bar value: i.  aBlock value: each]}
> > Array(SequenceableCollection)>>withIndexDo:
> > [] in Array(SequenceableCollection)>>do:displayingProgress: {[:bar |
> > self   withIndexDo: [:each :i |     bar value: i.    aBlock value:
> > e...]}
> > [] in ProgressInitiationException>>defaultMorphicAction {[result :=
> > workBlock value: progress]}
> > BlockContext>>ensure:
> > ProgressInitiationException>>defaultMorphicAction
> > ProgressInitiationException>>defaultAction
> > UndefinedObject>>handleSignal:
> > MethodContext(ContextPart)>>handleSignal:
> > ProgressInitiationException(Exception)>>signal
> > ProgressInitiationException>>display:at:from:to:during:
> > ProgressInitiationException class>>display:at:from:to:during:
> > ByteString(String)>>displayProgressAt:from:to:during:
> > Array(SequenceableCollection)>>do:displayingProgress:
> > MCPackage>>snapshot
> > MCWorkingCopy>>changesRelativeToRepository:
> > MCWorkingCopyBrowser>>viewChanges
> > PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
> > PluggableButtonMorphPlus>>performAction
> > [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m |
> > (m containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
> > Array(SequenceableCollection)>>do:
> > PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
> > PluggableButtonMorphPlus>>mouseUp:
> > PluggableButtonMorphPlus(Morph)>>handleMouseUp:
> > MouseButtonEvent>>sentTo:
> > PluggableButtonMorphPlus(Morph)>>handleEvent:
> > PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
> > [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
> > ActiveEvent := anEvent.  result := focusHolder     han...]}
> > [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
> > BlockContext>>on:do:
> > PasteUpMorph>>becomeActiveDuring:
> > HandMorph>>sendFocusEvent:to:clear:
> > HandMorph>>sendEvent:focus:clear:
> > HandMorph>>sendMouseEvent:
> > HandMorph>>handleEvent:
> > HandMorph>>processEvents
> > [] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h
> > processEvents.  capturingGesture := capturingGest..]}
> > ...etc...
> >
> > Cheers
> > Philippe
> >
> >
>
>
>
>

> Philippe
>
>> -
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/106542.html
>>
>> And while we are here: I do not expect such problems when .source and
>> .changes are *both* produced in the 512 MB format (versus: as a mixture  
>> of
>> the old and the new format).
>>
>> FWIW: now that Squeak-dev image is available (thanks again to Damien and
>> contributors) I could use the Squeak-dev image tool mix for testing a
>> reasonable set of clients ...
>>
>> If the 512 MB changes patch is planned for 3.10: I'm ready to completing
>> the patch and tests (except during the 2nd half of November).
>>
>> /Klaus
>>
>> On Mon, 02 Oct 2006 20:41:55 +0200, Philippe Marschall wrote:
>>
>> > Hi
>> >
>> > Ok, I had an 3.9 7051 image that was very close at 32 MB. I could
>> > either rebuild a new image from scratch or use the patch from Klaus.
>> > Now I knew about the risks (wich are why it's not in 3.9) and that it
>> > has not seen enough testing. But if nobody tests it because it has not
>> > seen enough testing then nobody will test it and it will never see
>> > enogh testing. So it basically boiled down to 'Who if not me? When if
>> > not now?'
>> >
>> > So I did
>> >
>> > - loaded LargeSourceFilePointers-kwl.0.cs (said Proceed)
>> > - did the doit
>> > - loaded LargeSourceFilePointers-kwl.1.cs
>> > - did the doit
>> >
>> > loaded RefactoringEngine
>> > run Lint on a package, did some fixes, commited via Monticello
>> > run Lint on an other package, did some fixes, oops trace below
>> >
>> > As you can see a CompiledMethod is in the preamble.
>> > size of changes file:
>> > 31377626
>> >
>> > From: 2 October 2006 8:36:33 pm
>> >
>> > VM: unix - a SmalltalkImage
>> > Image: Squeak3.9alpha [latest update: #7051]
>> >
>> > SecurityManager state:
>> > Restricted: false
>> > FileAccess: true
>> > SocketAccess: true
>> >
>> > CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
>> >       Receiver: a CompiledMethod (614)
>> >       Arguments and temporary variables:
>> >               aMessage:       findString: ''methodsFor:'' startingAt:  
>> 1
>> >       Receiver''s instance variables:
>> > a CompiledMethod (614)
>> >
>> > CompiledMethod>>timeStamp
>> >       Receiver: a CompiledMethod (614)
>> >       Arguments and temporary variables:
>> >               file:   MultiByteFileStream:
>> > ''/home/upnip/data/uni/masterarbeit/images/7051/Squea...etc...
>> >               preamble:       a CompiledMethod (614)
>> >               stamp:  ''''
>> >               tokens:         nil
>> >               tokenCount:     nil
>> >               ex:     nil
>> >       Receiver''s instance variables:
>> > a CompiledMethod (614)
>> >
>> > MethodReference>>timeStamp
>> >       Receiver: a MethodReference PKBarLayout >> initialize
>> >       Arguments and temporary variables:
>> >
>> >       Receiver''s instance variables:
>> >               classSymbol:    #PKBarLayout
>> >               classIsMeta:    false
>> >               methodSymbol:   #initialize
>> >               stringVersion:  ''PKBarLayout initialize''
>> >
>> > MCMethodDefinition class>>forMethodReference:
>> >       Receiver: MCMethodDefinition
>> >       Arguments and temporary variables:
>> >               aMethodReference:       a MethodReference PKBarLayout  
>> >> initialize
>> >               definition:     nil
>> >       Receiver''s instance variables:
>> >               superclass:     MCDefinition
>> >               methodDict:     a MethodDictionary(#=->a CompiledMethod  
>> (643)
>> > #accept:->a CompiledM...etc...
>> >               format:         142
>> >               instanceVariables:      #(''classIsMeta'' ''source''  
>> ''category''
>> > ''selector'' ''className'' ''...etc...
>> >               organization:   (''accessing'' actualClass category  
>> classIsMeta
>> > className fullTimeS...etc...
>> >               subclasses:     nil
>> >               name:   #MCMethodDefinition
>> >               classPool:      a Dictionary(#Definitions->a
>> > WeakIdentityKeyDictionary(size 239) )
>> >               sharedPools:    nil
>> >               environment:    a SystemDictionary(lots of globals)
>> >               category:       #''Monticello-Modeling''
>> >               traitComposition:       nil
>> >               localSelectors:         nil
>> >
>> >
>> > --- The full stack ---
>> > CompiledMethod(Object)>>doesNotUnderstand: #findString:startingAt:
>> > CompiledMethod>>timeStamp
>> > MethodReference>>timeStamp
>> > MCMethodDefinition class>>forMethodReference:
>> >  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> > MethodReference>>asMethodDefinition
>> > [] in MCPackage>>snapshot {[:ea | definitions add: ea
>> > asMethodDefinition]}
>> > [] in Array(SequenceableCollection)>>do:displayingProgress: {[:each :i
>> > |  bar value: i.  aBlock value: each]}
>> > Array(SequenceableCollection)>>withIndexDo:
>> > [] in Array(SequenceableCollection)>>do:displayingProgress: {[:bar |
>> > self   withIndexDo: [:each :i |     bar value: i.    aBlock value:
>> > e...]}
>> > [] in ProgressInitiationException>>defaultMorphicAction {[result :=
>> > workBlock value: progress]}
>> > BlockContext>>ensure:
>> > ProgressInitiationException>>defaultMorphicAction
>> > ProgressInitiationException>>defaultAction
>> > UndefinedObject>>handleSignal:
>> > MethodContext(ContextPart)>>handleSignal:
>> > ProgressInitiationException(Exception)>>signal
>> > ProgressInitiationException>>display:at:from:to:during:
>> > ProgressInitiationException class>>display:at:from:to:during:
>> > ByteString(String)>>displayProgressAt:from:to:during:
>> > Array(SequenceableCollection)>>do:displayingProgress:
>> > MCPackage>>snapshot
>> > MCWorkingCopy>>changesRelativeToRepository:
>> > MCWorkingCopyBrowser>>viewChanges
>> > PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
>> > PluggableButtonMorphPlus>>performAction
>> > [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m |
>> > (m containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
>> > Array(SequenceableCollection)>>do:
>> > PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
>> > PluggableButtonMorphPlus>>mouseUp:
>> > PluggableButtonMorphPlus(Morph)>>handleMouseUp:
>> > MouseButtonEvent>>sentTo:
>> > PluggableButtonMorphPlus(Morph)>>handleEvent:
>> > PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
>> > [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
>> > ActiveEvent := anEvent.  result := focusHolder     han...]}
>> > [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
>> > BlockContext>>on:do:
>> > PasteUpMorph>>becomeActiveDuring:
>> > HandMorph>>sendFocusEvent:to:clear:
>> > HandMorph>>sendEvent:focus:clear:
>> > HandMorph>>sendMouseEvent:
>> > HandMorph>>handleEvent:
>> > HandMorph>>processEvents
>> > [] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h
>> > processEvents.  capturingGesture := capturingGest..]}
>> > ...etc...
>> >
>> > Cheers
>> > Philippe
>> >
>> >
>>
>>
>>
>>
>
>

> I've been looking at this code a while and whilst I congratulate Klaus
> on his valiant attempt to solve the file size problem I think we need to
> take a step back and try to clean things up a bit more.
>
> The problem here is that we have an extraordinary mess in our source
> pointer methods. It mostly stems from 'temporary' attempts to survive
> the problems of having source pointed to by four bytes stuck to the end
> of a nasty design of a hybrid object type that ought to have disappeared
> in 1998 after I first wrote the code to convert them to proper objects.
> If we stick any more patches on top of this nonsense we are in danger of
> looking like a part decomposed ancient egyptian mummy.
>
> Let's spend a little time and effort working out what we would like to
> end up with and then a way to get there from here.
>
> I would like to propose a fairly complete overhaul of CompiledMethod and
> its friends. Get rid of the hybrid object format (which would simplify
> the gc code a little too) and define CMs as
> bytecodes
> literals
> sourceaccess
> methodClass
> ...whatever other properties are needed...
>
> ie a plain object with named instance variables. A slight alternative
> that might be considered is for the literals to be indexed vars
> following the named ones (think OrderedCollection if this is not
> familiar to you).
>
> We would lose the algorithmic gymnastics about last literal is the
> class, second to last is the properties, first is the recipe for today's
> soup dish, etc.
>
> The source code access would be through any object understanding a small
> protocol along the lines of 'get source', 'setSourceTo:' and .... err, I
> think that's it. Again, back in '98 I demonstrated a system that used
> this and had example accessors that used a file, an encoded file, a
> plain string, a compressed string and a damp string. Using a database or
> a networked method source server or a connection to another image which
> held the source in some other way would all be possible.
>
> The cost is a loss of backwards compatibility for the image. Maybe it
> would be possible to make a vm that would run old images as well as new
> ones but I suspect it would cost some performance and I'm sure it would
> cost some tedious maintenance tax. You may not care about that but *I*
> sure do! Maybe it would be better to just abandon the current image
> lineage and jump ship to build this purely on top of Spoon? Maybe nobody
> cares?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SEXI: Sign EXtend Integer
>
>
>
>

> [snip]
> Yes, that is plausible and reasonable; except that I *do* think it is  
> way past time to do the CM rework and since to makes it trivial to also  
> clean up the source code representation I consider it a nice synergy.  
> Sure, we can improve the source code situation by putting a normal oop  
> in the properties. That would certainly be better.
>
> As I said, Klaus is to be congratulated for coming up with a concrete  
> proposal. I don't think it cleans up anywhere near enough of the mess,  
> but that could be worked on. For example, it appears to me to leave far  
> too much in the way of assumptions about the source pointer being an  
> encrypted integer for real comfort.

> Andreas Raab wrote:
>> Well, in that case all I can say is: "Code speaks" ;-) If you  
>> still have
>> that code from '98 and can update it to work with method  
>> properties I'd
>> like to see it and I'd like us to have the discussion about which
>> approach people like more.
>
> I'd very much like to see the code from 98 as it stands, without any
> changes, to get some feel for the scale of the change as proposed.

> Tim wrote:
>
> > > Maybe it would be better to just abandon the current image lineage
> > > and jump ship to build this purely on top of Spoon?
>
> and you responded:
>
> > Yeah, let's do that one. :)
>
> I know you are seriously smiling here.
>
> Yeah, let's do that one !!!
>
> I don't know if you are serious enough to use your Spoon to scoop out
> from the release Squeak 3.9 the KernelImage pioneered by Pavel and
> post the system and instructions for reproducing it...

> On 3-Oct-06, at 3:02 AM, Tony Garnock-Jones wrote:
>> Andreas Raab wrote:
>>> Well, in that case all I can say is: "Code speaks" ;-) If you still  
>>> have
>>> that code from '98 and can update it to work with method properties I'd
>>> like to see it and I'd like us to have the discussion about which
>>> approach people like more.
>>
>> I'd very much like to see the code from 98 as it stands, without any
>> changes, to get some feel for the scale of the change as proposed.
>
> See
>
> http://www.rowledge.org/tim/squeak/SqFiles/packages/NewCompiledMethod- 
> Archive.zip
>
> for the original released files. The new CM class is very simple and it  
> is the cloner changes that were the really tricky part - the earlier  
> cloner was very limited and need quite a bit of sneaky work to make it  
> possible to do the needed transmutations.
>
> Note that this bunch of files don't have anything much by way of clever  
> tricks for handling source; I can't find anything on my system from the  
> experiements I did at Interval.
> Also note that the chances of being able to filein this code to any  
> recent image is essentially zero. Don't waste your time!
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Gramen artificiosum odi = I hate Astroturf.
>
>
>
>

>
> /Klaus
>
> On Tue, 03 Oct 2006 21:22:38 +0200, tim Rowledge wrote:
>> On 3-Oct-06, at 3:02 AM, Tony Garnock-Jones wrote:
>>> Andreas Raab wrote:
>>>> Well, in that case all I can say is: "Code speaks" ;-) If you still
>>>> have
>>>> that code from '98 and can update it to work with method properties I'd
>>>> like to see it and I'd like us to have the discussion about which
>>>> approach people like more.
>>>
>>> I'd very much like to see the code from 98 as it stands, without any
>>> changes, to get some feel for the scale of the change as proposed.
>>
>> See
>>
>> http://www.rowledge.org/tim/squeak/SqFiles/packages/NewCompiledMethod-Archive.zip 
>>
>>
>> for the original released files. The new CM class is very simple and
>> it is the cloner changes that were the really tricky part - the
>> earlier cloner was very limited and need quite a bit of sneaky work to
>> make it possible to do the needed transmutations.
>>
>> Note that this bunch of files don't have anything much by way of
>> clever tricks for handling source; I can't find anything on my system
>> from the experiements I did at Interval.
>> Also note that the chances of being able to filein this code to any
>> recent image is essentially zero. Don't waste your time!
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful Latin Phrases:- Gramen artificiosum odi = I hate Astroturf.
>>
>>
>>
>>
>
>
>
>

> Hi Tim -
>
> >> As much as I agree with the idea of reworking CompiledMethod in
> >> general, it seems to me we shouldn't mix up two otherwise unrelated
> >> issues.
> > [snip]
> > Yes, that is plausible and reasonable; except that I *do* think it is
> > way past time to do the CM rework and since to makes it trivial to also
> > clean up the source code representation I consider it a nice synergy.
>
> And it is. However, I question whether to put the two into the same bag.
> I think we can agree that whatever a new compiled method format will be
> like, it'll have a variable representing the source code reference. If
> we know that, then we can discuss what the source reference should
> represent. And that's really all that this discussion should be about.
>
> Having said that, I don't claim that Klaus' proposal is the one that
> necessarily should be adopted - I like it because it's the simplest
> thing I could imagine for starters and it's not so alien that all of the
> client code needs to be changed. That said, there *is* room for
> discussing the alternatives, and if you're unhappy with Klaus' proposal,
> by all means, propose some alternative. All I'm asking for is that we
> don't mix it with the CompiledMethod discussion.
>
> > As I said, Klaus is to be congratulated for coming up with a concrete
> > proposal. I don't think it cleans up anywhere near enough of the mess,
> > but that could be worked on. For example, it appears to me to leave far
> > too much in the way of assumptions about the source pointer being an
> > encrypted integer for real comfort. I made a technically simple but
> > organisationally more complex proposal. It is what it is. If people
> > don't like it, they don't like it.
>
> Well, in that case all I can say is: "Code speaks" ;-) If you still have
> that code from '98 and can update it to work with method properties I'd
> like to see it and I'd like us to have the discussion about which
> approach people like more.
>
> > Perhaps it is not yet time to change the image format and break backward
> > compatability; then again, the 64bit images are not backward compatible,
> > the proposed 3.9 release requires a condensed changes and new sources
> > file (perhaps not if we adopt a source pointer cleanup?) and frankly the
> > place is in a mess that needs cleaning. I'm fairly amazed you haven't
> > been clamouring for such a cleanup for the OLPC work.
>
> We're steering a deliberately conservative course on OLPC. Right now our
> (effectively only) priority is to make sure that eToys work well and
> that we're on track for the first batch of machines.