April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by Denis Kudriashov

Why #unregister: is not enough? 2011/4/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Yes > > Now is there a way that we could make sure that an object is really > unregistered? > I would write > > [ann hasSubscriber: anObject] whileTrue: [an unregister: anObject] > in the client code > but having > > fullyUnregister: anObject > > is good to have in special case. > > Stef > > > > Okay. But i would discourage from using such methods :) > > > >> Stef > >> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko AKA sig. > >>> > >> > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

April 24, 2011

Re: [Pharo-project] About testing that ensure works

by StÃ©phane Ducasse

> First question what i wanna ask is: > - why do you need to play with two different instances of organizer, > and especially in such manner (temporary swapping forth and back)? > > This code doesn't looks to be good. Igor can you reply to my question instead of questioning because it just slows me down. Now the answer: when we run the tests we do not run them in the default organizer because if something wrong happens then this is simply harakiri. So all the tests are performed in a separated created on the fly organizer. And I think that this is good to do it like that else I have to have a global variable and the rest. This design is the result of changes doru pushed me to do and they are good. Now this good is bad and not written my me and I'm trying to clean it and this is why I need to write tests because I want the Package code to be bullet proof. Stef > > > On 24 April 2011 00:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> in RPackage there is a method named withOrganizer:do: defined as follows and I would like to test it to understand really if it does >> what it says. >> >> withOrganizer: aNewOrganizer do: aBlock >> "Perform an action locally to aNewOrganizer. Does not impact any other organizers." >> >> | old shouldRegisterAtTheEnd| >> [ >> old := self organizer. >> shouldRegisterAtTheEnd := false. >> old hasRegistered ifTrue: [ >> old unregister. >> shouldRegisterAtTheEnd := true. >> ]. >> self organizer: aNewOrganizer. >> aBlock cull: aNewOrganizer.] ensure: [ >> self organizer: old. >> shouldRegisterAtTheEnd ifTrue: [ >> self organizer register. >> ]. >> aNewOrganizer unregister. >> ] >> >> >> So I wrote two tests >> >> testWithDoIsCorrectlyReinstallingDefault >> "self debug: #testWithDoIsCorrectlyReinstallingDefault" >> >> | current empty | >> current := RPackageOrganizer default. >> empty := RPackageOrganizer basicNew initialize. >> RPackage withOrganizer: empty >> do: [ self assert: (SystemAnnouncer announcer hasSubscriber: empty). >> self deny: (SystemAnnouncer announcer hasSubscriber: current)]. >> self assert: (SystemAnnouncer announcer hasSubscriber: current). >> self deny: (SystemAnnouncer announcer hasSubscriber: empty) >> >> >> and >> >> >> testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt >> "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" >> >> | current empty | >> current := RPackageOrganizer default. >> empty := RPackageOrganizer basicNew initialize. >> RPackage withOrganizer: empty >> do: [ self error. >> self assert: (SystemAnnouncer announcer hasSubscriber: empty). >> self deny: (SystemAnnouncer announcer hasSubscriber: current)]. >> self assert: (SystemAnnouncer announcer hasSubscriber: current). >> self deny: (SystemAnnouncer announcer hasSubscriber: empty) >> >> Now I would like to make sure that I raise an error or whaever to make sure that the ensure: block argument >> is executed. Does anybody have an idea how I can do that. because self error does not work. >> >> Stef >> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by StÃ©phane Ducasse

Yes Now is there a way that we could make sure that an object is really unregistered? I would write [ann hasSubscriber: anObject] whileTrue: [an unregister: anObject] in the client code but having fullyUnregister: anObject is good to have in special case. Stef > Okay. But i would discourage from using such methods :) > >> Stef >> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 24, 2011

[Pharo-project] Memory profiling

by Alexandre Bergel

Hi! I have been working on a memory profiler for Pharo. People who attended Smalltalks'10 may remember Mariano Coca's presentation. Unfortunately, I am not satisfied with what we can obtain from the execution of a piece of code in Pharo. The amount of memory consumed by a method _significantly varies_ across execution. I have the impression that memory consumption is a less stable metric than execution time. For example, I used this as a benchmark: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 7 timesRepeat: [ 5 timesRepeat: [ Smalltalk garbageCollect]. MemoryProfiler viewProfiling: [ 20 timesRepeat: [| view | 5 timesRepeat: [ Smalltalk garbageCollect]. Object new. Object new. 5 timesRepeat: [ Smalltalk garbageCollect]. view := MOViewRenderer new. view nodes: (1 to: 5000). view root applyLayout] ] inPackagesMatching: 'Mondrian-*' ] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It opens a simple visualization in Mondrian. I tried to clean as much as I can before executing the code with multiple garbage collect. This piece of code return 7 profiles. In a profile I have for the method MOBoundedShape>>heightFor: : Number of Young Allocated Bytes: 42,879,008 bytes Number of Old Allocated Bytes: 6,000,660 bytes Total Allocated Bytes: 48,879,668 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,415 Number of Full GC's: 0 Number of Tenures of Surving Objects: 164 In another profile I have: Number of Young Allocated Bytes: -7,857,156 bytes Number of Old Allocated Bytes: 6,008,872 bytes Total Allocated Bytes: -1,848,284 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,373 Number of Full GC's: 0 Number of Tenures of Surving Objects: 165 In another: Number of Young Allocated Bytes: -11,956,720 bytes Number of Old Allocated Bytes: 5,315,216 bytes Total Allocated Bytes: -6,641,504 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,354 Number of Full GC's: 0 Number of Tenures of Surving Objects: 145 And another: Number of Young Allocated Bytes: 59,132,472 bytes Number of Old Allocated Bytes: 6,177,772 bytes Total Allocated Bytes: 65,310,244 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,361 Number of Full GC's: 0 Number of Tenures of Surving Objects: 167 The metric "Number of Young Allocated Bytes", "Number of Old Allocated Bytes", "Total Allocated Bytes" are highly unpredictable: i.e., two profiles are likely to be completely different. I am not sure why is this so. I use the standard Pharo1.2 One click, without additional parameter to the VM. Do you think that other platforms and languages behave the same? However, the positive point is that it seems that the amount of incremental GC and the number of tenured objects may play an important role in estimating the memory consumption. These metrics are much more stable. What do you think on this? Does it make sense to say that more a method triggers incremental GC, more it consumes memory? What exactly triggers an incremental GC? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

[Pharo-project] What is a well documented class?

by Alexandre Bergel

Hi! I am dreaming about a tool to help me document source code. The question I have is what is a well documented class? What do you think about the following: A well documented class is a class: - that contains a class comment - its class comments contains either an example, or an associated unit test - without 'as yet unclassified' method category - each public method belongs to a method category named public* - each private method belongs to a method category named private* - each method contains a comment, located before the declaration of temporary variables - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' - without commented code contained in its methods. Is there anything else? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

Re: [Pharo-project] Fwd: [Vm-dev] Re: out of memory - cog on windows

by Andres Valloud

Interesting bit from the docs here: "Addresses near the 2-GB boundary are typically used by various system DLLs. Therefore, a 32-bit process cannot allocate more than 2 GB of contiguous memory, even if the entire 4-GB address space is available." http://msdn.microsoft.com/en-us/library/bb613473%28v=VS.85%29.aspx Maybe more fundamental changes are needed, such as the ability to change the image's memory footprint dynamically. On 4/23/11 17:34 , Andres Valloud wrote: > You can determine the switches better than me... for us, it was > /LARGEADDRESSAWARE, also a linker switch: > > http://msdn.microsoft.com/en-us/library/wz223b1z.aspx > > Now, keep in mind that expanding the address space capability of the app > doesn't mean Windows will give it 4gb. Under some Windows > configurations, that won't happen unless you change how Windows boots. > Under some versions, 4gb is just not possible. See here: > > http://msdn.microsoft.com/en-us/library/aa366778%28v=VS.85%29.aspx > > On 4/23/11 15:40 , Igor Stasenko wrote: >> On 23 April 2011 21:48, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net> wrote: >>> Some seemingly useful items to start tracing through Google appear >>> here... >>> >>> http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/b1548cd5e7… >>> >>> >> so we can add >> '-Wl,--large-address-aware'. >> option to linker. >> >> >>

April 24, 2011

Re: [Pharo-project] Fwd: [Vm-dev] Re: out of memory - cog on windows

by Andres Valloud

You can determine the switches better than me... for us, it was /LARGEADDRESSAWARE, also a linker switch: http://msdn.microsoft.com/en-us/library/wz223b1z.aspx Now, keep in mind that expanding the address space capability of the app doesn't mean Windows will give it 4gb. Under some Windows configurations, that won't happen unless you change how Windows boots. Under some versions, 4gb is just not possible. See here: http://msdn.microsoft.com/en-us/library/aa366778%28v=VS.85%29.aspx On 4/23/11 15:40 , Igor Stasenko wrote: > On 23 April 2011 21:48, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: >> Some seemingly useful items to start tracing through Google appear here... >> >> http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/b1548cd5e7… >> > so we can add > '-Wl,--large-address-aware'. > option to linker. > > >

April 24, 2011

Re: [Pharo-project] About testing that ensure works

by Igor Stasenko

First question what i wanna ask is: - why do you need to play with two different instances of organizer, and especially in such manner (temporary swapping forth and back)? This code doesn't looks to be good. On 24 April 2011 00:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > in RPackage there is a method named withOrganizer:do: Â defined as follows and I would like to test it to understand really if it does > what it says. > > withOrganizer: aNewOrganizer do: aBlock > Â Â Â Â "Perform an action locally to aNewOrganizer. Does not impact any other organizers." > > Â Â Â Â | old shouldRegisterAtTheEnd| > Â Â Â Â [ > Â Â Â Â old := self organizer. > Â Â Â Â shouldRegisterAtTheEnd := false. > Â Â Â Â old hasRegistered ifTrue: [ > Â Â Â Â Â Â Â Â old unregister. > Â Â Â Â Â Â Â Â shouldRegisterAtTheEnd := true. > Â Â Â Â Â Â Â Â ]. > Â Â Â Â self organizer: aNewOrganizer. > Â Â Â Â aBlock cull: aNewOrganizer.] ensure: [ > Â Â Â Â Â Â Â Â self organizer: old. > Â Â Â Â Â Â Â Â shouldRegisterAtTheEnd ifTrue: [ > Â Â Â Â Â Â Â Â Â Â Â Â self organizer register. > Â Â Â Â Â Â Â Â Â Â Â Â ]. > Â Â Â Â Â Â Â Â aNewOrganizer unregister. > Â Â Â Â Â Â Â Â ] > > > So I wrote two tests > > testWithDoIsCorrectlyReinstallingDefault > Â Â Â Â "self debug: #testWithDoIsCorrectlyReinstallingDefault" > > Â Â Â Â | current empty | > Â Â Â Â current := RPackageOrganizer default. > Â Â Â Â empty := RPackageOrganizer basicNew initialize. > Â Â Â Â RPackage withOrganizer: empty > Â Â Â Â Â Â Â Â do: [ self assert: (SystemAnnouncer announcer hasSubscriber: empty). > Â Â Â Â Â Â Â Â Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: current)]. > Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: current). > Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: empty) > > > and > > > testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt > Â Â Â Â "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" > > Â Â Â Â | current empty | > Â Â Â Â current := RPackageOrganizer default. > Â Â Â Â empty := RPackageOrganizer basicNew initialize. > Â Â Â Â RPackage withOrganizer: empty > Â Â Â Â Â Â Â Â do: [ self error. > Â Â Â Â Â Â Â Â Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: empty). > Â Â Â Â Â Â Â Â Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: current)]. > Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: current). > Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: empty) > > Now I would like to make sure that I raise an error or whaever to make sure that the ensure: block argument > is executed. Does anybody have an idea how I can do that. because self error does not work. > > Stef > > > > > -- Best regards, Igor Stasenko AKA sig.

April 23, 2011

Re: [Pharo-project] Fwd: [Vm-dev] Re: out of memory - cog on windows

by Igor Stasenko

On 23 April 2011 21:48, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Some seemingly useful items to start tracing through Google appear here... > > http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/b1548cd5e7… > so we can add '-Wl,--large-address-aware'. option to linker. -- Best regards, Igor Stasenko AKA sig.

April 23, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by Igor Stasenko

On 23 April 2011 21:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> hi guys >>> >>> >>> is there Â a way to know whether an object is registered to an announcer? >>> >>> I propose >>> >>> isRegistering: anObject >>> >>> registry subscriptionsOf: anObject Â do: [:each | ^ true]. >>> ^ false >>> >>> >> >> then more appropriate would be #hasSubscriber: > > yes much better. > >> May i ask why you need to test it? > > sure I'm trying to understand why I have 6 instances of RPackageOrganizer and also the code of cyrille. > So knowing if a given instance is registered is important for me to debug and also to write some tests. > >> Usually you don't need to test who subscribed to what. And if you do, >> then i suspect there are some design mistake. > > Exactly, still the API should let me do what I have to do when I need it. > Okay. But i would discourage from using such methods :) > Stef > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 23, 2011