- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] SUnit and TestCase

by Guillermo Polito

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

Re: [Pharo-project] SUnit and TestCase

by Benjamin

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

[Pharo-project] SUnit and TestCase

by Benjamin

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

April 5, 2012

Re: [Pharo-project] How to query the owner package of a RPackage ?

by StÃ©phane Ducasse

Yes! No subclass package. Stef > It was decided a long time ago that RPackage should not have a nested structure. > > Doru > > On Thu, Apr 5, 2012 at 11:31 AM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: >> Hi all, >> Since a RPackage can have sub-packages (see RPackage>>systemSubPackages) >> I'm wondering how to get the parent package of a package. >> >> btw: why are subPackages computed ? >> I mean it seems to me that a package can be considered as a composite, so >> why >> not directly associate a package with its children ? >> (and maybe have a two ways association between a child and a parent >> package). >> >> ----- >> RPackage>>systemSubPackages >> >> "return all RPackages matching with systemCategories of this RPackage" >> |tmpPackages| >> tmpPackages := OrderedCollection new. >> self systemCategories do: [:aString | >> (aString asSymbol = self name) ifFalse: [ >> |tmpPackage| >> "Maybe a RPackage matching the subcategory name does not yet >> exist in the organizer (Because packageInfo lazily register category from >> system). In this case, We should also lazily register a new RPackage with >> the right contents inside:" >> tmpPackage := RPackageOrganizer default packageNamed: aString >> asSymbol ifAbsent: [RPackageOrganizer default importFromPackageInfo: >> (PackageInfo named: aString)]. >> tmpPackages add: (tmpPackage). >> ]. >> ]. >> ^ tmpPackages >> ----- >> >> Thanks >> Alain >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 5, 2012