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

Re: [Pharo-project] Bug in ThreadSafeTranscript

by StÃ©phane Ducasse

stefan send code :) Stef On Jan 20, 2010, at 9:27 PM, Stefan Marr wrote: > Hi: > > ThreadSafeTranscript crShow: is not thread-safe, but definitely need to be thread-safe. > > The problem is, it is using a mutex currently. > (I guess thats the reason why there is no > accessSemaphore critical: [...]. > in crShow) > > Replacing it by a reentrant/recursive Monitor would probably allow to avoid code duplication. > > Best > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by StÃ©phane Ducasse

Excellent idea!!! On Jan 20, 2010, at 8:14 PM, John M McIntosh wrote: > Mmm That's the Cursor wait > look for senders > I've noticed if you bring up a sends of #wait then click on method, it takes *time* to build the senders lists/other stuff. > I suspect there is a ton of work going on.. > > I'm reminded that in the ftp://ftp.smalltalkconsulting.com/experimental/64bit > you find: > Squeak V5 SLOW VERSION FOR TESTING DO NOT USE FOR GENERAL USE.app > > which is a version 5.0 VM that will run very slow on your fast machines. You can use that to see why Igor thinks > things are slow. > > On 2010-01-20, at 8:16 AM, Igor Stasenko wrote: > >> 2010/1/20 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> Super quick here... (1.1 latest updates, admittedly a quad-core, only one >>> used though...) >> >> I have to take my words back. >> Strange, very strange.. its now magically started working quite fast.. >> As i said, first time i run it, it was flickering the hourglass mouse >> cursor each time i switching between methods in browser. >> What was it? And why it disappears? Any suggestions? >> > > -- > =========================================================================== > 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. 20, 2010

Re: [Pharo-project] O2: tester wanted!

by Henrik Sperre Johansen

On 19.01.2010 23:03, Alexandre Bergel wrote: > Dear All, > > For people who do not know, O2 is the browser David has implemented in > the last few years. It replaces class-categories on the left-hand side > pane with a list of packages. We are still away from having packages > as real first class entities, but this is a good step toward. Note > that some people find O2 a bit slower than other available code > browsers. > > David and I spent some time on fixing O2. O2 has now no dependencies > to OB anymore. > We would like that people try it and submit bug reports on the google > bug tracker. In a fresh 10505, you can load O2 by evaluating: > > Gofer new squeaksource: 'MetacelloRepository'; package: > 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) perform: > #loadDefault > > O2 does not need OB whatsoever. O2 loads in a Core (I tried in a > 11165). Before and after loading O2, running OB tests give "548 run, > 547 passes, 1 failures" [*]. > > Cheers, > Alexandre > > [*] the test have been loaded using (ConfigurationOfOmniBrowser > project version: '1.1') load: 'Dev Tests' > OR2PackageBrowser does not open, it lacks a defaultRootNode method returning other than nil. Is the focus mainly on the O2* browsers, or should OR2* also work? Cheers, Henry

Jan. 20, 2010

Re: [Pharo-project] O2: tester wanted!

by Henrik Sperre Johansen

On 20.01.2010 15:59, Igor Stasenko wrote: > Is it virtually possible to run it in Squeak image, since its not > depends on OB anymore? > Not quite. 1. In MCClassDefinition>> loadClass, isEmpty is sent to traitComposition, since O2 includes classes with trait definitions as a single trait, it'd have to be rewritten to: composition := self traitComposition ifNotNil:[: trait | Compiler evaluate: trait]. (composition isNil and:[class traitComposition isEmpty]) ifFalse:[ class setTraitComposition: composition asTraitComposition. ]. in order to load them correctly. 2. In ConfigurationOfO2, the baseline10 would have to change spec for: #pharo into spec for: #common. After those two changes, it still won't work, as O2 relies on one of the classes originally included (but really unrelated to) in the Traits category, and this has been removed from Squeak. If you make an external package with that, and modify the baseline to include a spec for: #squeak which imports said package, it might. Cheers, Henry

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by Igor Stasenko

2010/1/20 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 20 Jan 2010, John M McIntosh wrote: > >> >> On 2010-01-20, at 8:08 AM, Igor Stasenko wrote: >> >>> 2010/1/20 Marcus Denker <marcus.denker(a)inria.fr>: >>> Caching should in contrary increase the speed, isnt? >>> And i wouldn't say that my machine is slow >>> CPU0: AMD Phenom(tm) 8450 Triple-Core Processor stepping 03 >>> '85618729 bytecodes/sec; 4708854 sends/sec' >> >> >> *slow* > > I guess that vm is not gnuified. > I installed one that was avail for linux, latest one. Didn't built it myself. > > Levente > >> >> A *tuned* VM on Ubuntu on my macbook pro 2.33 intel Core 2 Duo gives >> 573,991,031 bytescodes/sec and 14,406,658 sends/sec. >> >> -- >> =========================================================================== >> 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 >> > > _______________________________________________ > 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.

Jan. 20, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Alexandre Bergel

> I didn't profile a real case yet, so I cannot say how useful it is > for me in real life. I would be glad to hear real life experiment. > It seems that you can quickly identify slow and often called methods > (is the latter really important because if the method is often > called but very fast, that's ok?!). This is the very idea. > On the other hand, what I miss compared to message tally is to > directly see the call relationship of methods. With your second view > you compensate for that a bit, but with the hover tooltips, it can > be cumbersome to understand a call graph. What would be the solution? Moving the tooltip next to the all graph? > BTW, to open a class you have the O2 browser hardcoded, which did > not work in my image because it was not loaded. I suggest to instead > use "ToolSet browse: ... selector: ..." instead. thanks, I fix this in Spy-Alexandre_Bergel.77. Cheers, Alexandre > > > On Jan 20, 2010, at 20:20 , Alexandre Bergel wrote: > >> Each implementor of #ensureMetacello is different. Even the one of >> ConfigurationOfMetacello is different from the one of the website :-) >> >> I update ConfigurationOfSpy. It loads now without any problem. >> >> Cheers, >> Alexandre >> >> >> On 20 Jan 2010, at 09:16, Mariano Martinez Peck wrote: >> >>> The problem is in ConfigurationOfSpy class >> ensureMetacello >>> >>> That method is wrong (it is old). You have to updated to something >>> like this: >>> >>> http://code.google.com/p/metacello/wiki/EnsureMetacello >>> >>> Cheers >>> >>> MAriano >>> >>> On Wed, Jan 20, 2010 at 12:11 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>> I also got the warnings and an error in the end. >>> >>> Adrian >>> >>> On Jan 20, 2010, at 12:06 , Alexandre Bergel wrote: >>> >>>> Strange, I tried in a 10505 and I got no warning. I will try later >>>> today. >>>> >>>> Alexandre >>>> >>>> >>>>> I tried it in a PharoCore 1.0 10506 and I get a lot of deprecation >>>>> warnings for gofer addPackage:, addVersion: >>>>> >>>>> The method Gofer addVersion: has been deprecated. >>>>> Instead of #addVersion: simply use #version: >>>>> >>>>> Select Proceed to continue, or close this window to cancel the >>>>> operation. >>>>> >>>>> I pressed proceed and then I got: >>>>> >>>>> >>>>> MetacelloGoferPackage(Object)>>doesNotUnderstand: #setName. >>>>> >>>>> Is this for 1.0, what version? >>>>> >>>>> Cheers >>>>>> >>>>>> To invoke the profiler, use the following template: >>>>>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] inPackage: >>>>>> 'YourPackageName' >>>>>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] >>>>>> inPackagesMatching: 'PackageName*' >>>>>> >>>>>> Replace "YOUR CODE" by an expression. Some examples are provided >>> in >>>>>> the class ProfilingPackageSpy (method category 'example'). You >>>>>> can >>>>>> find profilings of Mondrian, Glamour, Moose/CAnalyzer, O2. >>>>>> The profiling of Mondrian looks like this: >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> ProfilingPackageSpy >>>>>> viewProfiling: [ >>>>>> | view | >>>>>> view := MOViewRenderer new. >>>>>> view nodes: (1 to: 100) forEach: [:each | >>> view nodes: (1 to: >>>>>> 100)]. >>>>>> view root applyLayout >>>>>> ] >>>>>> inPackage: 'Mondrian' >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> >>>>>> There are two things you should keep in mind: >>>>>> - "YOUR CODE" will be executed twice. The first time with message >>>>>> Tally, then the second time with the full instrumentation. The >>> second >>>>>> execution should not be impacted by the first execution. >>>>>> - You cannot instrument the whole image. I need more time to make >>>>>> this >>>>>> happens. Therefore, you cannot provide '*' to inPackagesMatching: >>>>>> >>>>>> How to read the picture: >>>>>> - big rectangle are classes >>>>>> - edges represent class inheritance >>>>>> - inner rectangles are methods: >>>>>> * height = total time that the method has been executed >>>>>> * width = number of time the method has been executed >>>>>> * color = number of different receiver: white = the method has >>>>>> been executed on 1 receiver. black = many receivers >>>>>> >>>>>> You can do a right-click on a method, and select viewInvocation. >>> This >>>>>> opens a second view that show the execution flow. A different >>> mapping >>>>>> of metrics is used: >>>>>> - rectangle = methods >>>>>> - edges = invocation (upper invokes below) >>>>>> - gray color = method that always return 'self'. It corresponds >>> to >>>>>> void methods in Java or C++. It is therefore likely that the >>> method >>>>>> performs a side effect >>>>>> - yellow color = method that always returns the same value for a >>>>>> particular object >>>>>> - width and height are as in the first visualization >>>>>> >>>>>> Keep in mind that you mind encounter a freeze of your image if >>>>>> you >>>>>> instrument sensitive methods. >>>>>> >>>>>> I would be sincerely delighted to have experience report on this. >>>>>> >>>>>> Regards, >>>>>> Alexandre >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Miguel CobÃ¡ >>>>> http://miguel.leugim.com.mx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Mariano Martinez Peck

2010/1/20 Mike Hales <mike.hales(a)kscape.com> > Today on the squeak-dev list this link was posted, which I hadn't seen. > http://builder.seaside.st/ It lets you choose from the web page all the > options that you want, then it lets you download a build script or > monticello configuration to load all the parts. It seems like building one > of these for Pharo dev (or core) might be awesome. Just click the things you > want, if some are mutually exclusive the website can show that (radio button > rather than checkbox). Then download the base image, and drag your script > onto it. Everyone can get what they want, and nobody has to fight about > which browser is best. > > This, this will be a cool idea. We even talked about that with Dale so that you can download Metacello scripts. However, this is not also the best solution (from my point of view) to newcomers. They don't know what shout is, or what ocompletion, or RoelTyper, or whatever. We NEED a standard PharoDev image in a first step, that suits standard requirements. After that, we can focus on how to make better each customizations for each persons. Even more, we are going in that direction. Reading the 1hour tutorial of Metacello you will discover how you can very easily create your own script to load what you want. Even more, if there are similar "requirements", I can just create differents groups in ConfigurationOfMetacello, and thus, you only need to evaluate 1 line of code. > Mike > > Mike Hales > Engineering Manager > KnowledgeScape > www.kscape.com > > > 2010/1/20 laurent laffont <laurent.laffont(a)gmail.com> > > May be this is off topic, but when I was working in embedded linux >> development I have used a cool tool to customize its own linux image before >> downloading it. It's narcissus from angstrom distribution: >> http://www.angstrom-distribution.org/narcissus/ >> >> For me, a Pharo image and a linux distribution are quite similar when >> talking about packages. With Metacello, Loader and Seaside, may be such a >> tool to configure your image to download is not a big deal ? So everybody >> can easily choose between OB, O2 or both, WorkingSet / Algernon, AidaWeb / >> Seaside, .... >> >> Laurent >> >> >> >> On Wed, Jan 20, 2010 at 8:19 PM, Tudor Girba <tudor.girba(a)gmail.com>wrote: >> >>> I agree with this solution. >>> >>> As much as it pains me to work with OB (and I forced myself to do it >>> for 2 weeks :)), it is stable and this issue prevails at this moment >>> for 1.0. >>> >>> Cheers, >>> Doru >>> >>> >>> On 20 Jan 2010, at 19:10, Mariano Martinez Peck wrote: >>> >>> > >>> > >>> > On Wed, Jan 20, 2010 at 3:03 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> > wrote: >>> > Hi Mariano, >>> > >>> > > 2) Install only OB >>> > >>> > is a reasonable choice. We are very close to a 1.0 release and >>> > including OB again at this point does not make sense. The risk for >>> > unknown bugs that we needed to fix in maintenance releases of 1.0 is >>> > too high in my opinion. >>> > >>> > >>> > >>> > Thanks Adrian. I didn't want to say it, but yes. I think like you. >>> > WE NEED TO RELEASE 1.0 NOW!!!! and as much as stable possible. >>> > >>> > For new comers, I think it is even easier to have only one browser. >>> > Having two, bring to confussion, insecurity, etc. Once the newcomer >>> > stop to be newcomer, he will be able to install O2 by himself and >>> > take his own opinion on both browsers. >>> > >>> > And come on...that's the idea of Metacello!! that each people can >>> > load whatever they want. >>> > >>> > so.... +1 (ouch...I have already voted!) >>> > >>> > However, when we start building images for 1.1 we should consider to >>> > add it again. >>> > >>> > Cheers, >>> > Adrian >>> > >>> > On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: >>> > >>> > >> That's the reason of having OB and O2. While both now work >>> > together in the >>> > >> same image >>> > >> without inferring each other, this indeed increases the number of >>> > classes >>> > >> in the image >>> > >> quite a lot as they duplicate a whole bunch of code. So I >>> > strongly suggest >>> > >> to either use >>> > >> OB or O2, even though you can have both. But I do not see a >>> > reason why >>> > >> people want to >>> > >> switch between the two dynamically in the same image. >>> > >> >>> > >> >>> > > >>> > > We have two things to choose: which browser is default and which >>> > ones are >>> > > installed. Both ? only one ? The solution I like most, is in >>> > these options: >>> > > >>> > > 1) Install both: OB and O2. Let OB as default. >>> > > >>> > > 2) Install only OB, of course, as default, and those who wants can >>> > install >>> > > O2 in that dev image. They way to install O2 now is very easy. >>> > > >>> > > 3) Install only OB, of course, as default, but create a group in >>> > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those >>> > people who >>> > > want a dev image with O2 can just evaluate that in a core image >>> > and wala! >>> > > >>> > > With 1 the image will be smaller but won't have O2 preinstalled. >>> > With 2) and >>> > > 3) you will have also O2 but bigger image. >>> > > >>> > > I think I will coose 2) AND 3). Those who want to install O2 >>> > directly in a >>> > > dev image, use the ConfigurationOfO2 and those who wants to create >>> > a dev >>> > > image over the core, they use ConfigurationOfPharo with the new >>> > group I can >>> > > create. >>> > > >>> > > What do you think ? >>> > > >>> > > Mariano >>> > > _______________________________________________ >>> > > 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 >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Adrian Lienhard

Hi Alex That looks very interesting! I didn't profile a real case yet, so I cannot say how useful it is for me in real life. It seems that you can quickly identify slow and often called methods (is the latter really important because if the method is often called but very fast, that's ok?!). On the other hand, what I miss compared to message tally is to directly see the call relationship of methods. With your second view you compensate for that a bit, but with the hover tooltips, it can be cumbersome to understand a call graph. Cheers, Adrian BTW, to open a class you have the O2 browser hardcoded, which did not work in my image because it was not loaded. I suggest to instead use "ToolSet browse: ... selector: ..." instead. On Jan 20, 2010, at 20:20 , Alexandre Bergel wrote: > Each implementor of #ensureMetacello is different. Even the one of > ConfigurationOfMetacello is different from the one of the website :-) > > I update ConfigurationOfSpy. It loads now without any problem. > > Cheers, > Alexandre > > > On 20 Jan 2010, at 09:16, Mariano Martinez Peck wrote: > >> The problem is in ConfigurationOfSpy class >> ensureMetacello >> >> That method is wrong (it is old). You have to updated to something >> like this: >> >> http://code.google.com/p/metacello/wiki/EnsureMetacello >> >> Cheers >> >> MAriano >> >> On Wed, Jan 20, 2010 at 12:11 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >> I also got the warnings and an error in the end. >> >> Adrian >> >> On Jan 20, 2010, at 12:06 , Alexandre Bergel wrote: >> >>> Strange, I tried in a 10505 and I got no warning. I will try later >>> today. >>> >>> Alexandre >>> >>> >>>> I tried it in a PharoCore 1.0 10506 and I get a lot of deprecation >>>> warnings for gofer addPackage:, addVersion: >>>> >>>> The method Gofer addVersion: has been deprecated. >>>> Instead of #addVersion: simply use #version: >>>> >>>> Select Proceed to continue, or close this window to cancel the >>>> operation. >>>> >>>> I pressed proceed and then I got: >>>> >>>> >>>> MetacelloGoferPackage(Object)>>doesNotUnderstand: #setName. >>>> >>>> Is this for 1.0, what version? >>>> >>>> Cheers >>>>> >>>>> To invoke the profiler, use the following template: >>>>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] inPackage: >>>>> 'YourPackageName' >>>>> ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] >>>>> inPackagesMatching: 'PackageName*' >>>>> >>>>> Replace "YOUR CODE" by an expression. Some examples are provided >> in >>>>> the class ProfilingPackageSpy (method category 'example'). You can >>>>> find profilings of Mondrian, Glamour, Moose/CAnalyzer, O2. >>>>> The profiling of Mondrian looks like this: >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> ProfilingPackageSpy >>>>> viewProfiling: [ >>>>> | view | >>>>> view := MOViewRenderer new. >>>>> view nodes: (1 to: 100) forEach: [:each | >> view nodes: (1 to: >>>>> 100)]. >>>>> view root applyLayout >>>>> ] >>>>> inPackage: 'Mondrian' >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> There are two things you should keep in mind: >>>>> - "YOUR CODE" will be executed twice. The first time with message >>>>> Tally, then the second time with the full instrumentation. The >> second >>>>> execution should not be impacted by the first execution. >>>>> - You cannot instrument the whole image. I need more time to make >>>>> this >>>>> happens. Therefore, you cannot provide '*' to inPackagesMatching: >>>>> >>>>> How to read the picture: >>>>> - big rectangle are classes >>>>> - edges represent class inheritance >>>>> - inner rectangles are methods: >>>>> * height = total time that the method has been executed >>>>> * width = number of time the method has been executed >>>>> * color = number of different receiver: white = the method has >>>>> been executed on 1 receiver. black = many receivers >>>>> >>>>> You can do a right-click on a method, and select viewInvocation. >> This >>>>> opens a second view that show the execution flow. A different >> mapping >>>>> of metrics is used: >>>>> - rectangle = methods >>>>> - edges = invocation (upper invokes below) >>>>> - gray color = method that always return 'self'. It corresponds >> to >>>>> void methods in Java or C++. It is therefore likely that the >> method >>>>> performs a side effect >>>>> - yellow color = method that always returns the same value for a >>>>> particular object >>>>> - width and height are as in the first visualization >>>>> >>>>> Keep in mind that you mind encounter a freeze of your image if you >>>>> instrument sensitive methods. >>>>> >>>>> I would be sincerely delighted to have experience report on this. >>>>> >>>>> Regards, >>>>> Alexandre >>>>> >>>>> >>>> >>>> -- >>>> Miguel CobÃ¡ >>>> http://miguel.leugim.com.mx >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Mike Hales

Today on the squeak-dev list this link was posted, which I hadn't seen. http://builder.seaside.st/ It lets you choose from the web page all the options that you want, then it lets you download a build script or monticello configuration to load all the parts. It seems like building one of these for Pharo dev (or core) might be awesome. Just click the things you want, if some are mutually exclusive the website can show that (radio button rather than checkbox). Then download the base image, and drag your script onto it. Everyone can get what they want, and nobody has to fight about which browser is best. Mike Mike Hales Engineering Manager KnowledgeScape www.kscape.com 2010/1/20 laurent laffont <laurent.laffont(a)gmail.com> > May be this is off topic, but when I was working in embedded linux > development I have used a cool tool to customize its own linux image before > downloading it. It's narcissus from angstrom distribution: > http://www.angstrom-distribution.org/narcissus/ > > For me, a Pharo image and a linux distribution are quite similar when > talking about packages. With Metacello, Loader and Seaside, may be such a > tool to configure your image to download is not a big deal ? So everybody > can easily choose between OB, O2 or both, WorkingSet / Algernon, AidaWeb / > Seaside, .... > > Laurent > > > > On Wed, Jan 20, 2010 at 8:19 PM, Tudor Girba <tudor.girba(a)gmail.com>wrote: > >> I agree with this solution. >> >> As much as it pains me to work with OB (and I forced myself to do it >> for 2 weeks :)), it is stable and this issue prevails at this moment >> for 1.0. >> >> Cheers, >> Doru >> >> >> On 20 Jan 2010, at 19:10, Mariano Martinez Peck wrote: >> >> > >> > >> > On Wed, Jan 20, 2010 at 3:03 PM, Adrian Lienhard <adi(a)netstyle.ch> >> > wrote: >> > Hi Mariano, >> > >> > > 2) Install only OB >> > >> > is a reasonable choice. We are very close to a 1.0 release and >> > including OB again at this point does not make sense. The risk for >> > unknown bugs that we needed to fix in maintenance releases of 1.0 is >> > too high in my opinion. >> > >> > >> > >> > Thanks Adrian. I didn't want to say it, but yes. I think like you. >> > WE NEED TO RELEASE 1.0 NOW!!!! and as much as stable possible. >> > >> > For new comers, I think it is even easier to have only one browser. >> > Having two, bring to confussion, insecurity, etc. Once the newcomer >> > stop to be newcomer, he will be able to install O2 by himself and >> > take his own opinion on both browsers. >> > >> > And come on...that's the idea of Metacello!! that each people can >> > load whatever they want. >> > >> > so.... +1 (ouch...I have already voted!) >> > >> > However, when we start building images for 1.1 we should consider to >> > add it again. >> > >> > Cheers, >> > Adrian >> > >> > On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: >> > >> > >> That's the reason of having OB and O2. While both now work >> > together in the >> > >> same image >> > >> without inferring each other, this indeed increases the number of >> > classes >> > >> in the image >> > >> quite a lot as they duplicate a whole bunch of code. So I >> > strongly suggest >> > >> to either use >> > >> OB or O2, even though you can have both. But I do not see a >> > reason why >> > >> people want to >> > >> switch between the two dynamically in the same image. >> > >> >> > >> >> > > >> > > We have two things to choose: which browser is default and which >> > ones are >> > > installed. Both ? only one ? The solution I like most, is in >> > these options: >> > > >> > > 1) Install both: OB and O2. Let OB as default. >> > > >> > > 2) Install only OB, of course, as default, and those who wants can >> > install >> > > O2 in that dev image. They way to install O2 now is very easy. >> > > >> > > 3) Install only OB, of course, as default, but create a group in >> > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those >> > people who >> > > want a dev image with O2 can just evaluate that in a core image >> > and wala! >> > > >> > > With 1 the image will be smaller but won't have O2 preinstalled. >> > With 2) and >> > > 3) you will have also O2 but bigger image. >> > > >> > > I think I will coose 2) AND 3). Those who want to install O2 >> > directly in a >> > > dev image, use the ConfigurationOfO2 and those who wants to create >> > a dev >> > > image over the core, they use ConfigurationOfPharo with the new >> > group I can >> > > create. >> > > >> > > What do you think ? >> > > >> > > Mariano >> > > _______________________________________________ >> > > 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 >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> 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. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by Nicolas Cellier

2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok I understand. I will keep your energy for the important one. http://code.google.com/p/pharo/issues/detail?id=1856 > but since I'm nearly the only that have a look at fixes in squeak > may be I will simply just stop to look at them because the community > does not seem to interested in getting them or producing them for pharo. > Sure some people are interested as much as you are. But waiting for someone to do the job for you, or wasting your own time is rarely a dilemna except for the happy few owners of "own time" ;) It's important to keep up with what's going on in other branches : kind of technology forecasting :) Just lurking the daily commit logs, and registering interesting stuff as pharo issue is already valuable. Nicolas > Stef > > > On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: > >> Don't know if I'll have time, but changes are fairly easy to grab >> (independent of each other). > > Ok >> >> Nicolas >> >> 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi nicolas >>> >>> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >>> since in moose we are computing a lot LOC :) >>> By any chance could we get the same in pharo? >>> Else I will harvest them. >>> >>> Stef >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010