- Pharo-dev - lists.pharo.org

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

by Henrik Sperre Johansen

On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >> i am puzzled. You wanna to be sure that ensure block are executed? >> It is. > I want to write a test that shows and tests the withOrganizer:do: semantics. > In particular that the ensure is executed and that the context set by the withOrganizer: is only present > in the do: block. > In other words, another use case probably written more cleanly using the non-existing Announcer >> #suspend: subscriber while: aBlock ;) Cheers, Henry

April 26, 2011

Re: [Pharo-project] Better debugging...

by Alexandre Bergel

> In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. I have built a number of code profilers over the time. The instrumentation is done with Spy, a kind of method wrapper. It would cool to see whether Pinocchio can be a better replacement for my profilers. This will be a cool validation for Pinocchio Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

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

by Henrik Sperre Johansen

On 24.04.2011 14:13, StÃ©phane Ducasse wrote: > Ok I got it I ws confused by SUnit interference > > testDo > "self run: #testDo" > > self do: [ Error signal]. > self assert: x = 3 > > > > self run: #testDo -> red tests > > self debug: #testDo + proceed -> green tests The ensure runs, but at that point the test already failed, see it says "1 errors", not "1 failures" :) To see it manually, you could put Transcript show: 'Foo' or some such in the ensure block instead, and notice how the Transcript is written :) Cheers, Henry ps. It's easier to just write aBlock ensure: [blabla] instead of [aBlock value] ensure: [blabla] ... if aBlock REALLY is a block, and not aValuable, of course :=

April 26, 2011

Re: [Pharo-project] petit parser help

by Ricardo Moran

Hi Lukas, thanks for answering! Since all this stuff is pretty new to me sometimes is hard to see when something is an optimization or the right way to do it :) Cheers, Richo On Tue, Apr 26, 2011 at 2:27 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > I only played a little with PetitParser but I think the answer is in > > PetitXml>>#element. You see in the action block that it compares the > > "qualified" of the open and close tags and if they're different it > returns a > > PPFailure. It also takes care of the inlineTag in the same block by > asking > > if the fifth node is '/>'. > > This "taking care of the inlineTag" is just an ugly optimization, but > it makes the parser extremely fast :-) > > Ideally you start with a grammar as you propose and add then check if > open and close tag are the same in the callback, as in the example > above. > > Another subtlety that you see in the above example that is the parser: > > [ :stream | stream position ] asParser > > This object returns the position in the stream and makes it possible > to create the failure at the beginning of the close tag. Again, this > is not required to start with. You can create the failure object like > below, it just will not point you to the right place in the input > then: > > PPFailure message: 'tags not matching' at: 0 > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by Henrik Sperre Johansen

On 24.04.2011 15:57, Mariano Martinez Peck wrote: > I saw that package in PharoSound and I wonder if it should be added to > the Metacello conf > > cheers > > > -- > Mariano > http://marianopeck.wordpress.com > Yes, in a version 4.0 for 1.1 and 1.3 together with Sound-MarianoMartinezPeck.65 , as soon as we revert some stuff that was done in base which broke it. IE. change registration back to working with instances, and soundEnabled to use a class var of SoundService rather than that of it's registered class. It will not work with the code based on branch from PharoTaskForces (Sound-MarianoMartinezPeck.64), as that one just deleted all preferences rather than preserve them in a functionally correct way. Cheers, Henry

April 26, 2011

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Alexandre Bergel

Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class Alexandre On 26 Apr 2011, at 06:34, Mariano Martinez Peck wrote: > Hi. As far as I can see, > > Behavior >> flushCache > "Tell the interpreter to remove the contents of its method lookup cache, if it has > one. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 89> > self primitiveFailed > > > And primitive 89 does nothing in particular with the receiver (the class in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, there is NOTHING related to the receiver class. Of course, that's at least what it looks for me (please tell me if I am wrong). > So...if this is the case, wouldn't make sense to move it elsewhere? like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm flushCache, Smalltalk vm parameterAt: , etc.... > > If you don't like doing "Smalltalk vm" then we can create a VM class with all class methods, or a singleton and use #current or a singleton and put it in Smalltalk globals...etc > > We will need to fix a couple of senders, thus. > > What do you think? For me is really confusing, and you don't understand it until you see the primitive implementation. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] Memory profiling

by Henrik Sperre Johansen

On 24.04.2011 05:32, Alexandre Bergel wrote: > 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? It's not really surprising; since young space allocated size is shrunk by GC, a simple "value after block" - "value before block", for how much was actually allocated will give you rather random results. The amount of surviving objects (ie tenured into old allocated bytes)/tenures though is pretty much the same over the different runs, the differences can probably be explained by higher-priority process activity. > 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? http://wiki.squeak.org/squeak/1469 "Eden collections are triggered by either running out of eden space, or allocating more than a certain number of objects (currently 4000) since the last collection " Not sure if it's up to date, but I'd guess so. It's hard to build a Profiler for creation of non-transient objects during a run, since the creation and tenuring of created objects usually happens at entirely different places (around 200 incGC's per tenure in my image). In other words, you can't really say that a method is "consuming" memory simply because a tenure happened during it's execution, and there was an increase in old space allocation, as some/many of the surviving objects could have been created 200 incGC's earlier. The amount of incGC's is usually a good indication of how many/how large objects are created during a methods execution though, due to the above mentioned trigger conditions. In the context of determining overhead due to GC, those numbers are usually the interesting ones anyways. Cheers, Henry

April 26, 2011

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 2:19 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 26, 2011 at 1:56 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > >> How about putting such methods on an Interpreter class? >> >> > that's why I was saying by "reify the VM" > > but not Interpreter to avoid collisions with VMMaker. I would call it VirtualMachine- other ideas? > > >> On 2011-04-26, at 14:35, Alexandre Bergel wrote: >> >> > Not using the receiver is indeed misleading. I thought it simply flushes >> the cache for a particular class >> > >> > Alexandre >> > >> > >> > On 26 Apr 2011, at 06:34, Mariano Martinez Peck wrote: >> > >> >> Hi. As far as I can see, >> >> >> >> Behavior >> flushCache >> >> "Tell the interpreter to remove the contents of its method lookup >> cache, if it has >> >> one. Essential. See Object documentation whatIsAPrimitive." >> >> >> >> <primitive: 89> >> >> self primitiveFailed >> >> >> >> >> >> And primitive 89 does nothing in particular with the receiver (the >> class in this case). In both, InterpreterVM and Cog, the WHOLE cache is >> flushed, there is NOTHING related to the receiver class. Of course, that's >> at least what it looks for me (please tell me if I am wrong). >> >> So...if this is the case, wouldn't make sense to move it elsewhere? >> like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good >> moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak >> vm flushCache, Smalltalk vm parameterAt: , etc.... >> >> >> >> If you don't like doing "Smalltalk vm" then we can create a VM class >> with all class methods, or a singleton and use #current or a singleton and >> put it in Smalltalk globals...etc >> >> >> >> We will need to fix a couple of senders, thus. >> >> >> >> What do you think? For me is really confusing, and you don't >> understand it until you see the primitive implementation. >> >> >> >> Cheers >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> > >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 1:56 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > How about putting such methods on an Interpreter class? > > that's why I was saying by "reify the VM" > On 2011-04-26, at 14:35, Alexandre Bergel wrote: > > > Not using the receiver is indeed misleading. I thought it simply flushes > the cache for a particular class > > > > Alexandre > > > > > > On 26 Apr 2011, at 06:34, Mariano Martinez Peck wrote: > > > >> Hi. As far as I can see, > >> > >> Behavior >> flushCache > >> "Tell the interpreter to remove the contents of its method lookup > cache, if it has > >> one. Essential. See Object documentation whatIsAPrimitive." > >> > >> <primitive: 89> > >> self primitiveFailed > >> > >> > >> And primitive 89 does nothing in particular with the receiver (the class > in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, > there is NOTHING related to the receiver class. Of course, that's at least > what it looks for me (please tell me if I am wrong). > >> So...if this is the case, wouldn't make sense to move it elsewhere? > like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good > moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak > vm flushCache, Smalltalk vm parameterAt: , etc.... > >> > >> If you don't like doing "Smalltalk vm" then we can create a VM class > with all class methods, or a singleton and use #current or a singleton and > put it in Smalltalk globals...etc > >> > >> We will need to fix a couple of senders, thus. > >> > >> What do you think? For me is really confusing, and you don't understand > it until you see the primitive implementation. > >> > >> Cheers > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Camillo Bruni

How about putting such methods on an Interpreter class? On 2011-04-26, at 14:35, Alexandre Bergel wrote: > Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class > > Alexandre > > > On 26 Apr 2011, at 06:34, Mariano Martinez Peck wrote: > >> Hi. As far as I can see, >> >> Behavior >> flushCache >> "Tell the interpreter to remove the contents of its method lookup cache, if it has >> one. Essential. See Object documentation whatIsAPrimitive." >> >> <primitive: 89> >> self primitiveFailed >> >> >> And primitive 89 does nothing in particular with the receiver (the class in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, there is NOTHING related to the receiver class. Of course, that's at least what it looks for me (please tell me if I am wrong). >> So...if this is the case, wouldn't make sense to move it elsewhere? like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm flushCache, Smalltalk vm parameterAt: , etc.... >> >> If you don't like doing "Smalltalk vm" then we can create a VM class with all class methods, or a singleton and use #current or a singleton and put it in Smalltalk globals...etc >> >> We will need to fix a couple of senders, thus. >> >> What do you think? For me is really confusing, and you don't understand it until you see the primitive implementation. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 26, 2011