January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] allSubclassesDoGently: ?

by StÃ©phane Ducasse

Yes of course. Now since only a subpart of the system was using it it means that imageSegment are most of the time reloaded. So this is clearly a neat idea but not fully working. Stef On Jan 17, 2010, at 10:27 PM, John M McIntosh wrote: > I think you'll find it's documented in the class > ImageSegmentRootStub > > It's all tied up in image segments, projects, etoys and the like, so in the past an attempt to ensure > that objects (classes) that were bundled up and stuffed into an image segment aren't faulted back in > unless you really mean it... > > users of this are interesting, see for example > Dictionary>>at:ifPresentAndInMemory: > > On 2010-01-17, at 1:10 PM, StÃ©phane Ducasse wrote: > >> isInMemory > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] allSubclassesDoGently: ?

by John M McIntosh

I think you'll find it's documented in the class ImageSegmentRootStub It's all tied up in image segments, projects, etoys and the like, so in the past an attempt to ensure that objects (classes) that were bundled up and stuffed into an image segment aren't faulted back in unless you really mean it... users of this are interesting, see for example Dictionary>>at:ifPresentAndInMemory: On 2010-01-17, at 1:10 PM, StÃ©phane Ducasse wrote: > isInMemory -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 17, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testAllLocalCallsOn

by StÃ©phane Ducasse

I opened the following bug entry: - first allLocalCallsOn: should return methodRefernece and not strings - second we should get some fixture and tests http://code.google.com/p/pharo/issues/list?thanks=1844 I removed this tests Stef On Jan 16, 2010, at 7:35 PM, StÃ©phane Ducasse wrote: > Yes thanks. > I will probably kill them. > or create a fixture that is stable > > On Jan 16, 2010, at 2:47 PM, Nicolas Cellier wrote: > >> Same for testAllCallsOn, this test is obsolete as soon as you make >> modifications in Pharo :) >> >> Such test should use specific classes and messages specially crafted >> for the test >> >> Nicolas >> >> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> testAllLocalCallsOn >>> " >>> self debug: #testAllLocalCallsOn >>> " >>> >>> | set | >>> set := Array allLocalCallsOn: #printOn:. >>> self assert: (set asArray = #('WeakActionSequence printOn:' 'Object >>> fullPrintString' 'Array printOn:' 'SequenceableCollection >>> asStringWithCr' 'Behavior printOn:' 'Class fileOutPool:onFileStream:' >>> 'Object printStringLimitedTo:' 'Collection printNameOn:' >>> 'ActionSequence printOn:' 'FixedIdentitySet printOn:')). >>> "This is a bit strange that allLocalCallsOn: returns a list of string!" >>> >>> This one is bad for two reasons: >>> 1) it relies on an arbitrary order in Set. For example, just change >>> default size of sets and the order will change. Eventually you could >>> test set = #() asSet but see 2) >>> 2) it relies on a particular snapshot of pharo and prevent pharo from evolving. >>> >>> Moreover, if a user adds its own sender of printOn: in an extension or >>> a subclass, this will make the test fail... >>> >>> Such test should create a class hierarchy dedicated to the test with a >>> know set of senders and test >>> Either correct it or remove it. >>> >>> Nicolas >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by John M McIntosh

Let me provide a link to some more talks about GC and iPhone work, although theses are spread over various STS and ESUG sites I'll consolidate them here. Esug 09 talk on iPhone work https://docs.google.com/fileview?id=0BzM4orHA3iGxMjU0ZDU4MWEtOTQ2Zi00OGVlLT… Esug 08 talk on GStreamer work https://docs.google.com/fileview?id=0BzM4orHA3iGxNWJiYTMzOGUtOTI1Yy00NGI3LT… Esug 05 talk on garbage collection logic https://docs.google.com/fileview?id=0BzM4orHA3iGxNDViZjYwZDUtYzk5Yi00YTFmLW… Smalltalk Solutions 05 talk on garbage collection logic https://docs.google.com/fileview?id=0BzM4orHA3iGxZjBjMTQ4YTItZmVkNS00NjA1LT… Esug 04 talk on garbage collection logic https://docs.google.com/fileview?id=0BzM4orHA3iGxMjViYWM5MDAtMDJkMy00MmEwLW… Vancouver iPhone Developer group talk on Squeak on iPhone https://docs.google.com/fileview?id=0BzM4orHA3iGxM2FlNGNlMWMtMTM5My00YjlkLW… -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 17, 2010

[Pharo-project] allSubclassesDoGently: ?

by StÃ©phane Ducasse

Hi Does anybody know what is the purpose of this message? is it just the isInMemory that makes a difference? withAllSuperAndSubclassesDoGently: probably superfluous too :) Stef

Jan. 17, 2010

Re: [Pharo-project] strange local variable problem

by StÃ©phane Ducasse

Soon there will be a chapter on a nice book on that :) > Levente and Lukas, > > You both agree that this is not a bug, them we have to ascertain that 'average Smalltalker' will understand that using closures in Pharo changes the Smalltalk language definition. > > > > Em 17/01/2010 06:57, Lukas Renggli < renggli(a)gmail.com > escreveu: > > >> I believe this is a bug. > > That's the correct behavior. This is exactly how closures should > behave. The variable declaration is outside the block you store thus > one variable slot is shared among multiple block definitions inside. > See ClosureTests for more examples of that behavior. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] [bug] 1.0-10505 Saving image kills version browsers

by Mariano Martinez Peck

http://code.google.com/p/omnibrowser/issues/detail?id=10 On Sun, Jan 17, 2010 at 1:04 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I can confirm this problem. Please create a bug report in the bug tracker: > > http://code.google.com/p/omnibrowser/ > > Lukas > > > > 2010/1/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Sun, Jan 17, 2010 at 3:13 AM, Martin McClure <martin(a)hand2mouse.com> > > wrote: > >> > >> It looks like if you browse versions of a method, and save the image > >> while the versions browser is open, this sets the source pointers in all > >> of the versions in the browser to nil. > >> > >> Then you get a DNU if you click on any of the versions. > >> > >> Workaround: Close the bad version browser, open a new one. > > > > Wow! That's a cool bug :) Yes, I could reproduce it in 1.0 505 Dev, but > > not in the core. Would you mind trying also in core? > > > > Because if it works on core, but not in dev, it would be a problem maybe > > with OB. > > > > Cheers > > > > Mariano > > > >> > >> Regards, > >> > >> -Martin > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010

Re: [Pharo-project] strange local variable problem

by csrabak＠bol.com.br

Levente and Lukas, You both agree that this is not a bug, them we have to ascertain that 'average Smalltalker' will understand that using closures in Pharo changes the Smalltalk language definition. Em 17/01/2010 06:57, Lukas Renggli < renggli(a)gmail.com > escreveu: > I believe this is a bug. That's the correct behavior. This is exactly how closures should behave. The variable declaration is outside the block you store thus one variable slot is shared among multiple block definitions inside. See ClosureTests for more examples of that behavior. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] SystemWindow updatablePanes ivar

by StÃ©phane Ducasse

I'm bad with ui but I was laways wondering why we would like to have non pluggable widgets. Stef >>> Hello, >>> >>> I completely lost in the logic of this thing. >>> >>> why a SystemWindow cares about something called panes? >>> What if my window don't having/needs any of them? >>> Why Object cares about #updateListsAndCodeIn: aWindow ??? >>> >>> If model is updated, then it should just send #changed, or self >>> changed: #myPaneFoo >>> and if SystemWindow's pane is dependent, it will be updated. >> >> May be this is related to the fact that the style gets propagated to its subcomponent. >> I know I was bitten by that some years ago. >> >>> >>> What the point in using #verifyContents... >>> >>> This thing needs to be cleaned up. >> >> yes ;) >> > > I perusing the code in PluggableXXX classes, and i feel sick of it. > All PluggableXXX classes has many repeatable patterns, like > declaring getXXXSelector, > which then serves for fetching the properties from model , like list, > selected item, lable etc.. > And this is also related to #update: method, which these morphs > handling usually like: > > update: property > property == getXXXSelector ifTrue: [ propertyXValue := model > perform: getXXXSelector ] > property == getYYYSelector ifTrue: [ propertyYValue := model > perform: getYYYSelector ] > > So, each morph, which depends from model, has to pull the value from > model manually. > But, we could do the same, by pushing the property to dependents. > > MyModel>>setMyProperty: value > ^ self notifyChange: #myProperty from: myProperty to: (myProperty := value ) > > MyModel>>notifyChange: propertyName from: oldValue to: newValue > self dependents do: [:each | > ( each perform: ('update', propertyName) asSymbol ) value: oldValue > value: newValue > > > MyMorph>>updateMyProperty > ^ [:oldValue :newValue | self doSomethingWith: oldValue and: newValue ] > > in the above, a model just pushing new values, and morph handling > updates directly, > without need to keep getXXXSelector ivars to know, how to retrieve > some property from model, > or determine the correspondence between property name and way how to handle it. > >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by John M McIntosh

On 2010-01-17, at 9:08 AM, HernÃ¡n Morales Durand wrote: > Have you started experiments or do you plan to include information > about (dead) timestamped garbage collection mechanisms? Herman, I didn't understand this question at all, can you explain further? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 17, 2010