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

Re: [Pharo-project] ocompletion bug fix

by Adrian Lienhard

The issue I remembered was named "Issue 1567: Highlight all -> hit backspace -> debugger appears". As far as I can tell this is fixed in the latest Pharo image (10.01.1). It contains version Ocompletion-RomainRobbes.52. Please try with the most recent image and report back if you still see the problem. Please also note that doing a software update does not update packages like Ocompletion (this is confusing and will be changed). Cheers, Adrian On Jan 20, 2010, at 19:35 , Sean Allen wrote: > I see it was fixed once I went to check the Ocompletion version, in > the next version after what we had installed: > > Ocompletion-DannyChan.44 fixes the bug. > > I didn't find a ticket in the issue tracker though. > > > On Wed, Jan 20, 2010 at 1:06 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> It is best to create an issue in our tracker and put Romain Robbes, the maintainer of Ocompletion, in cc. Also post the issue URL to the mailing list. >> >> This problem, though, sounds familiar to me. Which versions are you using? You may find already closed reports of this problem in the tracker. >> >> Thanks, >> Adrian >> >> On Jan 20, 2010, at 18:59 , Sean Allen wrote: >> >>> I just fixed a bug that has been driving me crazy for a while in the >>> Ocompletion package. >>> >>> When you select an area of text and delete, if you are deleting all of >>> it, it throws a subscript out of bounds error. >>> >>> What is the proper process for getting this change integrated? >>> I'm not really sure who this small fix should be sent to. >>> >>> _______________________________________________ >>> 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] A dog-slow browser

by Levente Uzonyi

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. 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 >

Jan. 20, 2010

Re: [Pharo-project] ocompletion bug fix

by Sean Allen

On Wed, Jan 20, 2010 at 2:31 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 20.01.2010 19:35, Sean Allen wrote: >> I see it was fixed once I went to check the Ocompletion version, in >> the next version after what we had installed: >> >> Ocompletion-DannyChan.44 fixes the bug. >> >> I didn't find a ticket in the issue tracker though. >> > Did you try searching the closed issues? > obviously not. ;)

Jan. 20, 2010

Re: [Pharo-project] ocompletion bug fix

by Henrik Sperre Johansen

On 20.01.2010 19:35, Sean Allen wrote: > I see it was fixed once I went to check the Ocompletion version, in > the next version after what we had installed: > > Ocompletion-DannyChan.44 fixes the bug. > > I didn't find a ticket in the issue tracker though. > Did you try searching the closed issues? Just searching for OCompletion, I get: http://code.google.com/p/pharo/issues/detail?id=1554 http://code.google.com/p/pharo/issues/detail?id=1567 and http://code.google.com/p/pharo/issues/detail?id=1635 :) Cheers, Henry

Jan. 20, 2010

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

by Levente Uzonyi

On Wed, 20 Jan 2010, John M McIntosh wrote: > You have to adjust the gnufied interp.c and the compiler options based on your compiler version to > generate the most optimum code for bytecode execution and the common send block. How do you adjust interp.c? Levente > > I'm guessing Marcus is using a V5 VM? '419328419 bytecodes/sec; 11484087 sends/sec' > > Would like to know what machine Gary Chambers is using? > (1 tinyBenchmarks '566998892 bytecodes/sec; 16433596 sends/sec') here. > > > On 2010-01-20, at 11:07 AM, Levente Uzonyi wrote: >> What's tuned? >> >> >> Levente > > -- > =========================================================================== > 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] New profiler for Pharo: tester wanted!

by John M McIntosh

You know I"m trying to integrate a microsecond clock into the VM. It might be interesting if you run on a macintosh to try a test V5 VM I can supply to see what happens if you change your time collecting from the millisecond clock to the microsecond clock. On 2010-01-20, at 11:20 AM, 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 20, 2010

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

by John M McIntosh

You have to adjust the gnufied interp.c and the compiler options based on your compiler version to generate the most optimum code for bytecode execution and the common send block. I'm guessing Marcus is using a V5 VM? '419328419 bytecodes/sec; 11484087 sends/sec' Would like to know what machine Gary Chambers is using? (1 tinyBenchmarks '566998892 bytecodes/sec; 16433596 sends/sec') here. On 2010-01-20, at 11:07 AM, Levente Uzonyi wrote: > What's tuned? > > > Levente -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 20, 2010

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

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

by Tudor Girba

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."

Jan. 20, 2010

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

by John M McIntosh

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 ===========================================================================

Jan. 20, 2010