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

Re: [Pharo-project] Pharo 1.4 - browse slow??

by Schwab,Wilhelm K

I'll have to look around, but that would probably explain what I saw. I'll play around later to see if it holds up. I'm not sure about the ID of the browser though: it's listed as Browser, and there are no other choices. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Thursday, April 05, 2012 2:41 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo 1.4 - browse slow?? I found myself that Nautilus is slow the first time you open a class. Probablt it needs to cache something...then the second time you open it, it is fast. I would recommend to fill that cache during ConfigurationOfNautilus to avoid a wrong impression to the final user. Cheers On Thu, Apr 5, 2012 at 10:30 AM, Camillo Bruni <camillobruni(a)gmail.com<mailto:camillobruni@gmail.com>> wrote: On 2012-04-05, at 01:16, Sean P. DeNigris wrote: > > Schwab,Wilhelm K wrote >> >> something is causing delays in either asking for a new browser or >> (particularly) references to the currently selected class. The browser is >> the only one in the image, which is listed simply as Browser > > Maybe related to > http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-td4173491.html ? > I was on Mac OS X (probably Lion at the time...) with the Cog VM (probably > carbon)... > > Sean that bug report is in vapor-mode as well... if you find the time tryout a nautilus image: https://ci.lille.inria.fr/pharo/job/Nautilus-Release/lastSuccessfulBuild/ar… cami -- Mariano http://marianopeck.wordpress.com

April 5, 2012

Re: [Pharo-project] Pharo 1.4 - browse slow??

by Mariano Martinez Peck

I found myself that Nautilus is slow the first time you open a class. Probablt it needs to cache something...then the second time you open it, it is fast. I would recommend to fill that cache during ConfigurationOfNautilus to avoid a wrong impression to the final user. Cheers On Thu, Apr 5, 2012 at 10:30 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-04-05, at 01:16, Sean P. DeNigris wrote: > > > > Schwab,Wilhelm K wrote > >> > >> something is causing delays in either asking for a new browser or > >> (particularly) references to the currently selected class. The browser > is > >> the only one in the image, which is listed simply as Browser > > > > Maybe related to > > > http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-td4173491.html? > > I was on Mac OS X (probably Lion at the time...) with the Cog VM > (probably > > carbon)... > > > > Sean > > that bug report is in vapor-mode as well... > if you find the time tryout a nautilus image: > > > https://ci.lille.inria.fr/pharo/job/Nautilus-Release/lastSuccessfulBuild/ar… > > cami > -- Mariano http://marianopeck.wordpress.com

April 5, 2012

[Pharo-project] Pharo 1.3 - Build # 28 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

April 5, 2012

Re: [Pharo-project] [squeak-dev] Fwd: type-inference: it works!

by Eliot Miranda

On Wed, Apr 4, 2012 at 4:59 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 4 Apr 2012, Frank Shearar wrote: > > I ported Francisco Garau's TypeInference engine to Squeak (well, >> changed the one thing I needed to make it run on Squeak), and Marcus >> noted the following: >> >> Marcus Denker <marcus.denker(a)inria.fr> says: >> >> >>>> It turns out that in Pharo we use Association and in Squeak we use >>>> ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode >>>> >>> >> You should think about cleaning that up... in the SystemDictonary, old >>> classes >>> are ReadOnlyVariableBinding, new ones are Associations. The code to make >>> a binding into a ReadOnlyVariableBinding is never called... >>> >> >> Given that I know next to nothing about this part of Squeak, I offer >> it up to those more knowledgeable than I for assessment! >> > > Markus is right, the code is not called, but I'm not sure it shouldn't be > called. Just try the following in a throw-away image: > > Object subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Foo'. > Foo := 1. > > The value of Foo will be 1 and your browser will go nuts when you try to > browse the Foo category. > Right. ReadOnlyVariableBinding is a *good* idea! (with ReadOnlyVariableBinding evaluating Foo := 1 will raise an error). > > > Levente > > >> frank >> >> >> > -- best, Eliot

April 5, 2012

Re: [Pharo-project] [Pharo 1.4] Please test!

by Hilaire Fernandes

You may want to add these clean-up as well. Strangely, 'FileSystem-Tests-Disk' and 'FileSystem-Tests-Memory' are not cleaned up. Although there is instance class in memory. May be order matter in cleaning and those need to be cleaned first. (MCPackage named: 'Announcements-Help') unload. (MCPackage named: 'FileSystem-Tests-Core') unload. (MCPackage named: 'FileSystem-Tests-AnsiStreams') unload. (MCPackage named: 'FileSystem-Tests-Disk') unload. (MCPackage named: 'FileSystem-Tests-Memory') unload. (MCPackage named: 'Metacello-Help') unload. (MCPackage named: 'Regex-Help') unload. Le 04/04/2012 17:30, Marcus Denker a Ã©crit : > What you should check is that #cleanUpForProduction changes a bit, it is much simpler now (I move more stuff > to the #cleanUp: methods and we cleaned up the image in general a little): -- Dr. Geo -- http://www.drgeo.eu

April 5, 2012

Re: [Pharo-project] [update 1.4] #14422

by StÃ©phane Ducasse

thanks esteban I deeply appreciate :) Stef On Apr 5, 2012, at 5:16 PM, Esteban Lorenzano wrote: > 14422 > ----- > > Issue 5579: Another Zn Update > http://code.google.com/p/pharo/issues/detail?id=5579 > > Issue 5057: Time and DateAndTime #now inconsistent > http://code.google.com/p/pharo/issues/detail?id=5057 >

April 5, 2012

[Pharo-project] [update 1.4] #14422

by Esteban Lorenzano

14422 ----- Issue 5579: Another Zn Update http://code.google.com/p/pharo/issues/detail?id=5579 Issue 5057: Time and DateAndTime #now inconsistent http://code.google.com/p/pharo/issues/detail?id=5057

April 5, 2012

Re: [Pharo-project] SUnit and TestCase

by Alexandre Bergel

I proposed this test announcement facilities some times ago to get notified when tests are being executed and when they are done. You said: "It means that you have to know which class to register to instead of which announcer." Which unit to register you mean? Yes, the one you are interested in. I do not see why it break the pattern. Consider TestCaseTest>>testAnnouncement. What is wrong with it? Cheers, Alexandre On 5 Apr 2012, at 06:14, Benjamin wrote: > Hello guys, > > I was implementing in Nautilus a listener to TestCaseStarted, and then I figured out that each TestCase subclasses have its own Announcer. > > It means that you have to know which class to register to instead of which announcer. In a way, it breaks the Observer pattern. > > Is there any good reason I am missing ? > > I think it has been done in a way you can spy a particular test class, but since you have this info in the announcement itself, you can always filter with this info. > Cause for me, replacing all those announcer by TestAnnouncer seems to be a better solution. > > > > Thanks in advance, > > Ben -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2012

Re: [Pharo-project] SUnit and TestCase

by Guillermo Polito

On Thu, Apr 5, 2012 at 3:17 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > per instance ? > I you wanna know when a test instance you run started, I think there are > better solutions than announcement. > Hehe, actually, if you are the one firing the test, then you do need nothing :). Also the tests instances are discarded to have independent state so what I said is nonsense :). > > For me the goal of announcement is to emit, and than everyone can catch > this information. > Hmm, that's one specific use for them... You can build for example a small application using announcements to decouple the UI from the model, and there you probably will not make the announcer accessible for everyone. > On Thu, Apr 5, 2012 at 2:57 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Since there is an announcer per test class, you need to write something >> like >> >> MyClass>>#register >> MyTestClass announcer >> on: TestCaseStarted send: #foo to: self. >> >> It means than here you force a link from MyClass to MyTestClass. >> And if you want to be aware of all test case started, you need something >> like >> >> TestCase withAllSubclasses do: [:e | e announcer >> >> on: TestCaseStarted send: #foo to: self ]. >> >> Why not using only one Announcer (and TestAnnouncer already exists and is >> already integrated) for all test class ? >> >> And then you lack the possibility to subscribe to a specific one... Maybe you can add a method in TestCase hiding the subscriptions to all the subclasses. > >> Ben >> >> >> On Apr 5, 2012, at 3:50 PM, Alexandre Bergel wrote: >> >> > I proposed this test announcement facilities some times ago to get >> notified when tests are being executed and when they are done. >> > >> > You said: "It means that you have to know which class to register to >> instead of which announcer." >> > Which unit to register you mean? Yes, the one you are interested in. I >> do not see why it break the pattern. Consider >> TestCaseTest>>testAnnouncement. What is wrong with it? >> > >> > Cheers, >> > Alexandre >> > >> > >> > On 5 Apr 2012, at 06:14, Benjamin wrote: >> > >> >> Hello guys, >> >> >> >> I was implementing in Nautilus a listener to TestCaseStarted, and then >> I figured out that each TestCase subclasses have its own Announcer. >> >> >> >> It means that you have to know which class to register to instead of >> which announcer. In a way, it breaks the Observer pattern. >> >> >> >> Is there any good reason I am missing ? >> >> >> >> I think it has been done in a way you can spy a particular test class, >> but since you have this info in the announcement itself, you can always >> filter with this info. >> >> Cause for me, replacing all those announcer by TestAnnouncer seems to >> be a better solution. >> >> >> >> >> >> >> >> Thanks in advance, >> >> >> >> Ben >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> > >> >> >> > >

April 5, 2012

Re: [Pharo-project] SUnit and TestCase

by Benjamin

per instance ? I you wanna know when a test instance you run started, I think there are better solutions than announcement. For me the goal of announcement is to emit, and than everyone can catch this information. Ben On Apr 5, 2012, at 3:03 PM, Guillermo Polito wrote: > Why not using one announcer per instance test instance? That way you are only coupled to test runs you and only you fire. > > On Thu, Apr 5, 2012 at 2:57 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Since there is an announcer per test class, you need to write something like > > MyClass>>#register > MyTestClass announcer > on: TestCaseStarted send: #foo to: self. > > It means than here you force a link from MyClass to MyTestClass. > And if you want to be aware of all test case started, you need something like > > TestCase withAllSubclasses do: [:e | e announcer > on: TestCaseStarted send: #foo to: self ]. > > Why not using only one Announcer (and TestAnnouncer already exists and is already integrated) for all test class ? > > > Ben > > > On Apr 5, 2012, at 3:50 PM, Alexandre Bergel wrote: > > > I proposed this test announcement facilities some times ago to get notified when tests are being executed and when they are done. > > > > You said: "It means that you have to know which class to register to instead of which announcer." > > Which unit to register you mean? Yes, the one you are interested in. I do not see why it break the pattern. Consider TestCaseTest>>testAnnouncement. What is wrong with it? > > > > Cheers, > > Alexandre > > > > > > On 5 Apr 2012, at 06:14, Benjamin wrote: > > > >> Hello guys, > >> > >> I was implementing in Nautilus a listener to TestCaseStarted, and then I figured out that each TestCase subclasses have its own Announcer. > >> > >> It means that you have to know which class to register to instead of which announcer. In a way, it breaks the Observer pattern. > >> > >> Is there any good reason I am missing ? > >> > >> I think it has been done in a way you can spy a particular test class, but since you have this info in the announcement itself, you can always filter with this info. > >> Cause for me, replacing all those announcer by TestAnnouncer seems to be a better solution. > >> > >> > >> > >> Thanks in advance, > >> > >> Ben > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > >

April 5, 2012