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

[Pharo-project] new Cog VMs uploaded

by Eliot Miranda

...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/. These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin. best, Eliot

April 26, 2011

Re: [Pharo-project] [update 1.3] #13173

by StÃ©phane Ducasse

thanks marcus! Stef On Apr 26, 2011, at 10:57 PM, Marcus Denker wrote: > 13173 > ----- > > Issue 4094: Object>>chooseUniqueClassName can be removed > Issue 2177: Generalize stream protocol #readInto:startingAt:count: > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 26, 2011

[Pharo-project] [update 1.3] #13173

by Marcus Denker

13173 ----- Issue 4094: Object>>chooseUniqueClassName can be removed Issue 2177: Generalize stream protocol #readInto:startingAt:count: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 26, 2011

Re: [Pharo-project] roeltyper problem

by Tudor Girba

Hi, Strange that it works for you. I just loaded your version in 1.2.1 and I still get the same problem (actually now I have only 28 classes with problems). What version of Pharo did you try it in? Cheers, Doru On 26 Apr 2011, at 21:03, Lukas Renggli wrote: > It works for me, please try the version here: > http://source.lukas-renggli.ch/unsorted > > Lukas > > On 26 April 2011 20:31, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I am trying to use RoelTyper, but I encountered subscript out of bounds and empty collection errors. It looks like this problem can be reproduced on 29 classes from Pharo 1.2.1. You can test it using: >> >> classes := Dictionary new. >> Object withAllSubclassesDo: [:each | >> [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. >> classes inspect >> >> I am not knowledgeable enough to dive into this. Can anyone help? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Value is always contextual." >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

April 26, 2011

Re: [Pharo-project] Memory profiling

by Alexandre Bergel

Thanks Adrian and Henrik. I will check this... Cheers, Alexandre On 26 Apr 2011, at 08:21, Henrik Sperre Johansen wrote: > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] Process for fixing a package in stable but not in core?

by StÃ©phane Ducasse

Hi michael this pharoseound settings is a mess. I probably contributed also because Beep beep was not working. I should take some time to really have a look. So far I a bit busy. we got some concurrent updates. The configurationOfSound if it exist should tell us which version to load. Or configurationOfPharo. In the future we will clean all that. Sorry for the problem. Stef On Apr 26, 2011, at 6:47 PM, Michael Forster wrote: > Hi, > > Forgive me, but I'm still new to the Pharo development process, and my > problem lies somewhere between being a Pharo developer and user. > > First, "Beeper beep" does not work in the current 1.2.1 image that I'm > using for production. I need to fix it and would like to share that > fix with the community. > > Second, I see from (closed) Issue 3489 that this is not a Pharo core > problem, but one with the PharoSound package, and that, apparently, it > might be fixed in the latest package version. > > Third, I fire up my 1.2.1 image, open the PharoSound squeaksource > repository in the monticello browser and discover that, as expected, > squeaksource does have some newer packages than the image. For > example, > > 1.2.1-image: Sound-GuillermoPolito.63 > > vs. > > squeaksource: Sound-MarianoMartinezPeck.65 > > > However, in other cases, the squeaksource package is _older_ than the > image's. For example, > > squeaksource: ConfigurationOfPharoSound-GuillermoPolito.17 > > vs. > > 1.2.1-image: ConfigurationOfPharoSound-GuillermoPolito.22. > > > How does one make sense of this? While can I reliably get the latest > version of PharoSound loaded in a 1.2.1 image so that I know I'm > writing and testing my fixes against a version that I can give back to > the community -- and, more importantly, won't be blown away by some > upcoming package version juggling? > > > Thanks, > > Mike >

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 11:10 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I support the idea. However, I am not sure I want this from the > PreDebugger. > > Yes, exactly. For the context menu I am sure I want it :) The question is in the pre debugger...and I am not quite sure... > Alexandre > > > > On 26 Apr 2011, at 15:59, Mariano Martinez Peck wrote: > > > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > > Going to PharoDebug.log is anoying: > > > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > > 2) then I need to go to such folder, and open the PharoDebug.log > > 3) most of the times, PharoDebug has appended a lot of other (un) issues > so it is quite confusing to use such file for a bug report. Hence I need to: > > 4) remove PharoDebug.log and > > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > > 6) finally search it again, open, and do the copy paste :) > > > > So....I think it should be muuuch easier from the debugger. So I added > two possibilities > > > > 1) copy to clipboard from the "pre debugger windows" > > See attached screenshot. > > > > 2) copy to clipboard from the debugger context menu. > > See attached screenshot. > > > > So...do you like it? which one do you want of them ? both ? > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > <pre debugger .png><debugger context menu.png> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 10:07 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > But is it linking the debugger to host whatever? > > No...it just copy past the text which was written in a stream. Look the changeset > On Apr 26, 2011, at 9:59 PM, Mariano Martinez Peck wrote: > > > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > > Going to PharoDebug.log is anoying: > > > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > > 2) then I need to go to such folder, and open the PharoDebug.log > > 3) most of the times, PharoDebug has appended a lot of other (un) issues > so it is quite confusing to use such file for a bug report. Hence I need to: > > 4) remove PharoDebug.log and > > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > > 6) finally search it again, open, and do the copy paste :) > > > > So....I think it should be muuuch easier from the debugger. So I added > two possibilities > > > > 1) copy to clipboard from the "pre debugger windows" > > See attached screenshot. > > > > 2) copy to clipboard from the debugger context menu. > > See attached screenshot. > > > > So...do you like it? which one do you want of them ? both ? > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > <pre debugger .png><debugger context menu.png> > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by StÃ©phane Ducasse

But is it linking the debugger to host whatever? On Apr 26, 2011, at 9:59 PM, Mariano Martinez Peck wrote: > Hi guys...with just 2 little methods, I am able to add a button to the debuger and a button to the context of the debugger, to copy the stakctrace to clipboard. > Going to PharoDebug.log is anoying: > > 1) I never know where my image is, so I first need to do print Smalltlak imagePharo > 2) then I need to go to such folder, and open the PharoDebug.log > 3) most of the times, PharoDebug has appended a lot of other (un) issues so it is quite confusing to use such file for a bug report. Hence I need to: > 4) remove PharoDebug.log and > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > 6) finally search it again, open, and do the copy paste :) > > So....I think it should be muuuch easier from the debugger. So I added two possibilities > > 1) copy to clipboard from the "pre debugger windows" > See attached screenshot. > > 2) copy to clipboard from the debugger context menu. > See attached screenshot. > > So...do you like it? which one do you want of them ? both ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > <pre debugger .png><debugger context menu.png>

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Guillermo Polito

+1 :) This solves my needs of putting the stack trace into the transcript :P. On Tue, Apr 26, 2011 at 4:59 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > Going to PharoDebug.log is anoying: > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > 2) then I need to go to such folder, and open the PharoDebug.log > 3) most of the times, PharoDebug has appended a lot of other (un) issues so > it is quite confusing to use such file for a bug report. Hence I need to: > 4) remove PharoDebug.log and > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > 6) finally search it again, open, and do the copy paste :) > > So....I think it should be muuuch easier from the debugger. So I added two > possibilities > > 1) copy to clipboard from the "pre debugger windows" > See attached screenshot. > > 2) copy to clipboard from the debugger context menu. > See attached screenshot. > > So...do you like it? which one do you want of them ? both ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

April 26, 2011