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

[Pharo-project] [update 1.4] #14423

by Esteban Lorenzano

14423 ----- Issue 5583: Delete overlapping package FileSystem-Tests http://code.google.com/p/pharo/issues/detail?id=5583 Issue 5582: Fix #cleanUpForProduction: Unload Help, fix FileSystemTestUnloading http://code.google.com/p/pharo/issues/detail?id=5582 Issue 5581: split recreateSpecialObjectsArray in two methods http://code.google.com/p/pharo/issues/detail?id=5581 Issue 5250: Clicking on sound in Setting does not anything http://code.google.com/p/pharo/issues/detail?id=5250

April 6, 2012

[Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by Guillermo Polito

BasicClassOrganizer has no users... Is it there for any purpose? What about joining them? Guille

April 6, 2012

Re: [Pharo-project] CogVM segmentation fault (on linux) when running headless

by Sebastian Sastre

looking good! I've tested the r2540 (not the mt one) with UI and headless and it's standing I'll leave it there to see how behaves thanks! sebastian o/ On Apr 5, 2012, at 11:30 PM, Eliot Miranda wrote: > and with one of my VMs? > > On Thu, Apr 5, 2012 at 7:06 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi guys, > > I'm testing CogVM for one airflowing worker we have in stage and it looks quite promising when we start the image with UI but when we start it headless it immediately segfaults > > Below is the log > > sebastian > > o/ > > > :~$ sudo invoke-rc.d airflowing0 start > :~$ > Segmentation fault Thu Apr 5 21:00:09 2012 > > > Squeak VM version: 3.9-7 #1 Thu Apr 5 14:40:40 CEST 2012 gcc 4.1.2 > Built from: CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Apr 5 2012 > With: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Apr 5 2012 > Revision: https://git.gitorious.org/cogvm/blessed.git Commit: 846551630c3c10df1f59588a6e7131d602f00b45 Date: Thu Apr 5 14:13:41 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Build host: Linux pharo-build.lille.inria.fr 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 14:13:46 EST 2010 i686 i686 i386 GNU/Linux > plugin path: /home/prod/pharo/cog/ [default: /home/prod/pharo/cog/] > > > C stack backtrace: > /home/prod/pharo/cog/CogVM[0x80968b1] > /home/prod/pharo/cog/CogVM[0x8096a52] > [0xb77a8440] > /lib/tls/i686/cmov/libc.so.6(iconv+0x6e)[0xb761e4ee] > /home/prod/pharo/cog/CogVM(convertChars+0xb4)[0x8094384] > /home/prod/pharo/cog/CogVM(sq2uxPath+0x47)[0x80945d7] > /home/prod/pharo/cog/CogVM(dir_Lookup+0x73)[0x80b8703] > /home/prod/pharo/cog/CogVM[0x80b7180] > /home/prod/pharo/cog/CogVM(interpret+0x3f68)[0x808dcc8] > /home/prod/pharo/cog/CogVM[0x808fc97] > /home/prod/pharo/cog/CogVM[0x8090664] > /home/prod/pharo/cog/CogVM(main+0x38a)[0x809774a] > /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb761d460] > /home/prod/pharo/cog/CogVM[0x805acc1] > > > Smalltalk stack dump: > 0xbfdc45d8 I FSUnixStore(FSDiskStore)>directoryAt:ifAbsent:nodesDo: -1431671128: a(n) FSUnixStore > 0xbfdc4608 I FSUnixStore(FSDiskStore)>nodeAt:ifPresent:ifAbsent: -1431671128: a(n) FSUnixStore > 0xbfdc4634 I FSUnixStore(FSStore)>exists: -1431671128: a(n) FSUnixStore > 0xbfdc4658 I FSFilesystem>exists: -1431671120: a(n) FSFilesystem > 0xbfdc467c I FSReference>exists -1431667420: a(n) FSReference > 0xbfdc469c I FSLocator>exists -1431671980: a(n) FSLocator > 0xbfdc46bc I FLHelper>hasConfDirectory -1431672032: a(n) FLHelper > 0xbfdc46dc I FLHelper>start -1431672032: a(n) FLHelper > 0xbfdc46fc I FLHelper class>start -1446907784: a(n) FLHelper class > 0xbfdc471c I FLHelper class>startUp -1446907784: a(n) FLHelper class > 0xbfdc4734 M FLHelper class(Behavior)>startUp: -1446907784: a(n) FLHelper class > 0xbfdc4760 M [] in SmalltalkImage>send:toClassesNamedIn:with: -1478292160: a(n) SmalltalkImage > 0xbfdc4788 I OrderedCollection>do: -1480202612: a(n) OrderedCollection > 0xbfdc47b0 I SmalltalkImage>send:toClassesNamedIn:with: -1478292160: a(n) SmalltalkImage > 0xbfdc47dc I SmalltalkImage>processStartUpList: -1478292160: a(n) SmalltalkImage > 0xbfdc4804 I [] in SmalltalkImage>snapshot:andQuit: -1478292160: a(n) SmalltalkImage > 0xbfdc4824 M BlockClosure>ensure: -1436539624: a(n) BlockClosure > 0xbfdc4848 I MorphicUIManager(UIManager)>boot:during: -1441995864: a(n) MorphicUIManager > 0xbfdc4878 I SmalltalkImage>snapshot:andQuit: -1478292160: a(n) SmalltalkImage > -1436547788 s SmalltalkImage>saveSession > -1436547696 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > -1436547604 s BlockClosure>ensure: > -1437443620 s CursorWithMask(Cursor)>showWhile: > -1437443732 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > -1436547512 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: > -1436547420 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: > -1436547328 s MouseButtonEvent>sentTo: > -1436547236 s ToggleMenuItemMorph(Morph)>handleEvent: > -1436547144 s MorphicEventDispatcher>dispatchDefault:with: > -1436547052 s MorphicEventDispatcher>dispatchEvent:with: > -1436546960 s ToggleMenuItemMorph(Morph)>processEvent:using: > -1436546868 s MorphicEventDispatcher>dispatchDefault:with: > -1436546776 s MorphicEventDispatcher>dispatchEvent:with: > -1436546684 s MenuMorph(Morph)>processEvent:using: > -1436546592 s MenuMorph(Morph)>processEvent: > -1436546500 s MenuMorph>handleFocusEvent: > -1436546408 s [] in HandMorph>sendFocusEvent:to:clear: > -1436546316 s [] in PasteUpMorph>becomeActiveDuring: > -1437443244 s BlockClosure>on:do: > -1437444096 s PasteUpMorph>becomeActiveDuring: > -1437444216 s HandMorph>sendFocusEvent:to:clear: > -1436546224 s HandMorph>sendEvent:focus:clear: > -1437444332 s HandMorph>sendMouseEvent: > -1437444424 s HandMorph>handleEvent: > -1436546132 s HandMorph>processEvents > -1436546040 s [] in WorldState>doOneCycleNowFor: > -1436545948 s Array(SequenceableCollection)>do: > -1436545856 s WorldState>handsDo: > -1437444768 s WorldState>doOneCycleNowFor: > -1436545764 s WorldState>doOneCycleFor: > -1436545672 s PasteUpMorph>doOneCycle > -1441147720 s [] in Project class>spawnNewProcess > -1441147868 s [] in BlockClosure>newProcess > > Most recent primitives > value: > compare:with:collated: > compare:with:collated: > value: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > basicNew: > value:value: > at:put: > value:value: > at:put: > value:value: > at:put: > value:value: > at:put: > value:value: > at:put: > value:value: > at:put: > value:value: > at:put: > size > size > at: > compare:with:collated: > size > basicNew: > compare:with:collated: > new: > at:put: > basicNew > new: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > size > + > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > size > species > basicNew: > replaceFrom:to:with:startingAt: > at:put: > basicNew > new: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > basicNew: > value:value: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > basicNew > size > = > size > at: > compare:with:collated: > size > basicNew: > at: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > basicNew > size > size > new: > size > at:put: > size > size > at: > basicNew > new: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > basicNew: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > basicNew > size > size > compare:with:collated: > basicNew: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > basicNew: > basicNew > value: > at:put: > size > new > value: > replaceFrom:to:with:startingAt: > value > at:put: > <= > * > + > value: > at: > replaceFrom:to:with:startingAt: > value > at:put: > value: > replaceFrom:to:with:startingAt: > value > at:put: > value: > replaceFrom:to:with:startingAt: > value > at:put: > value: > replaceFrom:to:with:startingAt: > value > at:put: > value: > replaceFrom:to:with:startingAt: > species > basicNew: > replaceFrom:to:with:startingAt: > basicNew > basicNew: > basicNew > findFirstInString:inSet:startingAt: > replaceFrom:to:with:startingAt: > lookupEntryIn:index: > > (Segmentation fault) > > > > > -- > best, > Eliot >

April 6, 2012

[Pharo-project] [ANN] NBOpenGL update

by Igor Stasenko

Hi there, for those, who interested, i updated a NBOpenGL configuration. Changes are: - updated GL API to most recent available (taken directly from opengl specs). Now there is about 300 more methods to explore :) - finally dealt with win32 support code and made it working again - fixed the GLX function prefix , which should be 'glX' not 'glx' To load it in 1.4 use: Gofer new squeaksource: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. and then (ConfigurationOfNBOpenGL project version: '1.0.2') load I did not tested the update thoroughly.. so i would appreciate if people will try it out and tell how it goes. -- Best regards, Igor Stasenko.

April 6, 2012

Re: [Pharo-project] cog and libSqueakSSL.so

by Igor Stasenko

On 6 April 2012 10:43, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 06 Apr 2012, at 03:34, Sebastian Sastre wrote: > >> ok, I did. >> >> It fixed the undefined symbol problem (that isn't shown anymore) and SqueakSSL it's now listed among the list of loaded modules. >> >> At first the #testPlain didn't pass but after a couple of runs it started to pass. >> >> â¦but >> >> ZnEasy get: 'https://encrypted.google.com/search?q=Smalltalk'. >> >> is timming out the connection every time Â :( >> >> sounds familiar? ideas? > > No concrete idea, no, sorry. > > But I would suggest being more conservative on the vm side. > > Apparently, http://ci.lille.inria.fr/pharo/view/VM/job/Cog-Unix/lastSuccessfulBuild/art…, which I believe you used, is a bit too fresh and has incomplete SSL support. > Yes, Camillo just added SSL plugin into build, but its not yet even checked if it functional or not. > Maybe someone can suggest a link to an older pharo linux vm. The archive that I am using looks like this: > > $ ls -l cog-vm.zip > -rw-rw-r-- 1 ubuntu ubuntu 611334 2012-03-01 11:55 cog-vm.zip > > $ md5sum cog-vm.zip > 479ba1a66a91b10bdc2374a661771814 Â cog-vm.zip > > I could publish mine somewhere if that helps. > > Sven > -- Best regards, Igor Stasenko.

April 6, 2012

Re: [Pharo-project] CogVM and fn key

by Igor Stasenko

On 6 April 2012 10:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hmm, strange...Â I fixed it on january > > https://gitorious.org/~gpolito/cogvm/gpolito-cogvm > > and then pushed it to > > https://gitorious.org/cogvm/blessed > > But looking at the sources from the CI server, my fix is not there... > strange.. it should be there if you pushed to master branch. and for sure, there's nobody who rejected/reverted your change(s) maybe by a mistake.. -- Best regards, Igor Stasenko.

April 6, 2012

Re: [Pharo-project] SUnit and TestCase

by Benjamin

On Apr 6, 2012, at 1:19 PM, Guillermo Polito wrote: > > > On Fri, Apr 6, 2012 at 1:12 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote: > >> >> 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. > > It's not specific, I think it should be the default behavior. > > Because if you want to listen only the FooTestClass announcement, you can always record yourself as a listener for all TestAnnouncement, and then test if the announcement is relevant for you or not. > > > Because if you need to know which class emit the announcement to be able to register, then you create a strong dependency from your class to the test class. And this is wrong (and announcement have been introduced to break this pattern) > > But that way you are creating a strong dependency against another class like TestAnnouncement or just TestCase :P. And if you want to filter the announcements for a specific class, you will do it too! You create a dependency to the Announcer instead of the classes emitting announcement, I think this is the correct way to do it :) Of course if you filter you create a dependency to the test class. But you only create a strong dependency in the case you are really interested by this particular class. If you want to listen to every test classes, you do not have to create a strong dependency to all the classes Ben > Anyway, if you're metaprogramming, then for sure are other ways to get the class without having a static reference to it. > > > > > Ben > > >>> 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 6, 2012

Re: [Pharo-project] SUnit and TestCase

by Guillermo Polito

On Fri, Apr 6, 2012 at 1:12 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote: > > > 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. > > > It's not specific, I think it should be the default behavior. > > Because if you want to listen only the FooTestClass announcement, you can > always record yourself as a listener for all TestAnnouncement, and then > test if the announcement is relevant for you or not. > > > Because if you need to know which class emit the announcement to be able > to register, then you create a strong dependency from your class to the > test class. And this is wrong (and announcement have been introduced to > break this pattern) > But that way you are creating a strong dependency against another class like TestAnnouncement or just TestCase :P. And if you want to filter the announcements for a specific class, you will do it too! Anyway, if you're metaprogramming, then for sure are other ways to get the class without having a static reference to it. > > > Ben > > > 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 6, 2012

Re: [Pharo-project] SUnit and TestCase

by Benjamin

On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote: > > 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. It's not specific, I think it should be the default behavior. Because if you want to listen only the FooTestClass announcement, you can always record yourself as a listener for all TestAnnouncement, and then test if the announcement is relevant for you or not. Because if you need to know which class emit the announcement to be able to register, then you create a strong dependency from your class to the test class. And this is wrong (and announcement have been introduced to break this pattern) Ben >> 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 6, 2012

[Pharo-project] Docking windows

by Guillermo Polito

I wanted docking windows, so I did a little change over the MorphFrameGhost to support it. If anyone wants to try, filein the attached the changeset and then evaluate: UITheme currentSettings fastDragging: true. Guille

April 6, 2012