October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to test the same behavior with different data

by Noury Bouraqadi

Hi, Just published my blog post on ParametrizedTests that is a proposal that addresses the question we have been discussing in this thread. http://car.mines-douai.fr/2013/10/parametrized-tests/ I believe it can be easily integrated into Pharo's SUnit. Noury On 25 sept. 2013, at 12:38, Frank Shearar wrote: > Hi Noury, > > At the moment it's hard-coded to 100 data points. It'd be better to > pull that out into some kind of configuration object though. > > frank > > On 25 September 2013 11:19, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> Hi Frank, >> >> This sounds cool. But, how do you decide how many data you generate per test run ? >> >> Noury >> On 23 sept. 2013, at 11:19, Frank Shearar wrote: >> >>> I played around with a combination of data driven testing and random >>> data generation a while back: >>> * http://www.lshift.net/blog/2011/09/13/checking-squeak-quickly >>> * http://www.squeaksource.com/SqueakCheck/ >>> >>> There is a ConfigurationOf there. It integrates with SUnit by adding a >>> new kind of TestCase that knows how to run theories, identified by >>> pragmas. It also features the recording of a counterexample to your >>> theory by generating a normal test method on the relevant TestCase >>> subclass. >>> >>> I haven't touched the code in a while, but if there's interest I'd be >>> happy to hack on it once more. >>> >>> frank >>> >>> On 22 September 2013 21:43, laurent laffont <laurent.laffont(a)gmail.com> wrote: >>>> Hi, >>>> >>>> in phpunit there's a @dataProvider annotation, so one method returns a >>>> several data sets for a test method. I'm not sure that's the best design but >>>> it's nice to have one unit test result per data set. See >>>> http://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-… >>>> >>>> >>>> Translating the example to Pharo that should give something like: >>>> >>>> TestCase subclass: #DataTest >>>> >>>> DataTest>>testAdd: a to: b shouldAnswer: c >>>> <dataProvider: #provider> >>>> self assert: c equals: a + b >>>> >>>> DataTest>>provider >>>> ^ { {0. 0. 0}. >>>> {1. 0. 1}. >>>> {0. 1. 1}. >>>> {1. 2. 3} } >>>> >>>> It may not be to difficult to implement in SUnit. What do you think about >>>> this ? >>>> >>>> Laurent >>>> >>>> >>>> On Sat, Sep 21, 2013 at 1:47 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I actually already thought on this as I have similar problems. >>>>> So far I just create a bunch of tests, passing the actual set of >>>>> parameters to a common test method as message arguments. >>>>> >>>>> For different framework (not SUnit, but similar spirit), I introduced a >>>>> notion of "parameter", each having a domain. When running test, the runner >>>>> computes all possible combinations of parameter values and run the test on >>>>> each such combination. I would like to have something similar >>>>> in SUnit, but there are some issues. This is the feature I would like to >>>>> see in SUnit 6.x, but I/we have to finish 5.0 first - I wonder if I ever >>>>> find a time to do push it :-( >>>>> >>>>> >>>>> On 21/09/13 11:06, Noury Bouraqadi wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Last ESUG I attended the cool katas session organized by Stephan >>>>>> Eggermont and Laurent Laffont. >>>>>> That was a good opportunity to step back and think about my TDD practices >>>>>> . >>>>>> >>>>>> To experiment with the style proposed by Laurent, I started writing tests >>>>>> for a pong. >>>>>> I ended up having groups of nearly identical tests: >>>>>> -they use exactly the same objects, send the same messages, >>>>>> -but they differ only by values. >>>>>> >>>>>> An example, is testing the motion of the ball towards different >>>>>> directions or collisions with obstacles at different locations or speeds. >>>>>> >>>>>> Now, I wonder what is the best way to express those similar tests? >>>>>> >>>>>> In a short discussion before I leave, Stephane told me about tables of >>>>>> values. It seem that there is such a support in the ruby world in the >>>>>> cucumber framework. Do we have anything similar in Smalltalk world? >>>>>> >>>>>> BTW, the full ESUG conference was great. Thanx to local organizers, and >>>>>> all people that contributed to make it a success. >>>>>> >>>>>> Thanx, >>>>>> Noury >>>>>> Ecole des Mines de Douai >>>>>> http://car.mines-douai.fr/noury >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> http://car.mines-douai.fr/noury >> >> Noury Bouraqadi >> Ecole des Mines de Douai >> http://car.mines-douai.fr/noury >> -- >> >> >> >> >> Afin de contribuer au respect de l'environnement, >> merci de n'imprimer ce courriel qu'en cas de necessite >> >> Please consider the environment before you print >> >> >> >> > Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury

Oct. 7, 2013

Re: [Pharo-dev] External Semaphores leaking in Socket

by Norbert Hartl

Am 07.10.2013 um 14:16 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Oct 6, 2013, at 12:51 , Norbert Hartl <norbert(a)hartl.name> wrote: > >> I took some time to analyze my current problem with external semaphores. I was just reluctant to raise the limit in my image because I want the problem solved. I logged the management of external semaphores and discovered that the table fills if a connection times out. >> >> The problem turns out to be in >> >> Socket>>#connectTo: hostAddress port: port waitForConnectionFor: timeout >> "Initiate a connection to the given port at the given host >> address. Waits until the connection is established or time outs." >> self connectNonBlockingTo: hostAddress port: port. >> self >> waitForConnectionFor: timeout >> ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' >> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] >> >> When a socket is created three external semaphores are registered in the ExternalSemaphoreTable. If a connection times out the exception is thrown but the Socket still has his resources attached. >> >> So e.g. in >> >> SocketStream class>>#openConnectionToHost: hostIP port: portNumber timeout: timeout >> | socket | >> socket := Socket new. >> socket connectTo: hostIP port: portNumber waitForConnectionFor: timeout. >> ^self on: socket >> >> it holds locally a socket (with semaphores registered) but on exception time the reference to the socket gets lost and the semaphores stay registered. The only way to unregister is on finalization time but I think it should work better. So I would add a destroy before the exception is raised. >> >> Socket>>#connectTo: hostAddress port: port waitForConnectionFor: timeout >> "Initiate a connection to the given port at the given host >> address. Waits until the connection is established or time outs." >> self connectNonBlockingTo: hostAddress port: port. >> self >> waitForConnectionFor: timeout >> ifTimedOut: [ >> self destroy. >> ConnectionTimedOut signal: 'Cannot connect to ' >> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] >> >> I opened a ticket at https://pharo.fogbugz.com/f/cases/11797 but I'm not sure how I am supposed to provide fixes made against a pharo2.0 image. Probably I should fix this againt 3.0 but then I'm still a 2.0 user :) >> >> Norbert > Destroying the socket manually there would only be an optimization, right? Yes. Even if it is not necessary I think freeing resources at the earliest possible time is a good thing. The problem with my change is that I have this gut feeling it is not a good one. At least I didn't see my image hang with this change applied. > It's still cleaned eventually by a finalization action? Yes, that is what makes me wonder. Why do you say "eventually"? What would be the conditions for finalize not being called on an object at garbage collection time? I log some details and print the external objects size into a lock file. The time of the last hangs the last printed lines where about an external objects size between 230 and 240. I had one test where I interacted with the image and did a manual garbage collect but the external object size was much higher than expected. This is all not very detailed but you get confused very easily hunting problems that are hard to reproduce. So I don't have a glue what it is. Need more time to look into it. But I'm running out of ideas what it could be. I'm not even sure it is the external semaphores directly. Norbert > Finalization all of a sudden stopping to work is an unlikely culprit of running out of external object space, load above what the size can handle, or actual leak(s) are much more probable. > > Thankfully, there are a limited number of places leaks could occur, for Socket you have improper uses of acceptFrom:/initialize: (multiple sends to the same socket). > > In a stock image, there's an obscure way that might occur afaict, if class methods acceptFrom:/newXXX are called, and the primitive calls in the new instance's acceptFrom:/initialize: returns a handle with status InvalidSocket instead of nil. > Then, the external objects will not be unregistered before repeatWithGCIf: clears them by calling them again. > (No idea if this can ever really happen though...) > > To flush out if such leaks are the cause, it might be useful to adjust initialize:/acceptFrom: with helpful logging/errors, as per > https://pharo.fogbugz.com/f/cases/5465/Prevent-accidental-semaphore-leaks-w… > > There's a few other users of registerExternalObject:, > - InputEventFetcher >> #startUp (Used to leak when saving but not quitting due to missing symmetric unregister in #shutDown, should be fixed in 2.0 ) > - AsynchFile (none uses this anyways right, so didn't bother checking) > - NetNameResolver >> initializeNetwork - (This potentially leaked if network could ever be in an uninitialized state 2x in a session, but should be fixed in 2.0) > > As long as both the above are fixed in your image, checking if there are non-stock users of registerExternalObject:/initialize:/acceptFrom: is probably the best bet to find trouble spots without waiting for another crash. > > Cheers, > Henry

Oct. 7, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Norbert Hartl

Am 07.10.2013 um 16:36 schrieb Igor Stasenko <siguctua(a)gmail.com>: > 1 thing. > > can you tell me what given expression yields for your VM/image: > > Smalltalk vm maxExternalSemaphores > > (if it gives you number less than 10000000 then i think i know what is your problem :) > It is 10000000 What would be the problem if it would be smaller? > i just found that after one merge, my changes get lost > we're just plugged them back in, and it should be back again with newer VMs.. > but the problem could be more than just semaphores.. if merge broken this, it may break > many other things, so we need time to check > I try to look at it some more time. I'm using the pharo-vm from the launchpad build. Are the changes supposed to be in this one? Norbert > > > > > On 7 October 2013 12:31, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 07.10.2013 um 11:28 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> >> On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> As I need an image that runs longer than 24 hours I'm looking at some stuff and wonder. Can anybody explain me the rationale for a code like this >>> >>> maxExternalSemaphores: aSize >>> "This method should never be called as result of normal program >>> execution. If it is however, handle it differently: >>> - In development, signal an error to promt user to set a bigger size >>> at startup immediately. >>> - In production, accept the cost of potentially unhandled interrupts, >>> but log the action for later review. >>> >>> See comment in maxExternalObjectsSilently: why this behaviour is >>> desirable, " >>> "Can't find a place where development/production is decided. >>> Suggest Smalltalk image inProduction, but use an overridable temp >>> meanwhile. " >>> | inProduction | >>> self maxExternalSemaphores >>> ifNil: [^ 0]. >>> inProduction := false. >>> ^ inProduction >>> ifTrue: [self maxExternalSemaphoresSilently: aSize. >>> self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use'; >>> crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:'; >>> crTrace: 'Current table size: ' , self maxExternalSemaphores printString] >>> ifFalse: ["Smalltalk image" >>> self error: 'Not enough space for external objects, set a larger size at startup!' >>> "Smalltalk image"] >>> >>> I have reported this once but got no feedback so I like to have a few opinions. >>> >>> The report is here: https://pharo.fogbugz.com/f/cases/10839/ >>> >>> Norbert >> >> The rationale is that inProduction would be some global setting, not yet in place when the code was writtenâ¦ >> Excessive simultaneous Semaphore usage is something that should be caught during development, in which case it's better to get an active notification, than having it logged somewhere. > > Agreed. But didn't work in my case because it needed roughly 20 hours and an instable remote backend to trigger the problem. And somehow I forgot to install my logger as Transcript so there is no warning message. I saw only dead images in the morning. > This not satisfactory but on the other hand this type of problems are hard to solve anyway. My feeling tells me there is more to discover. Sockets resources get unregistered at finalization time but this didn't work either. I would have said that the unlikely situation that no garbage collection ran could be the case. But it can't because in ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is explicit garbage collection. > >> If I've understood correctly, it's moot on newer Pharo VM's, where there's no limit on the semtable size, but for legacy code a startup item setting size using maxExternalObjectsSilently: (as suggested in the Warning text), is still a more proper fix than setting inProduction to true and crossing your fingers hoping no signals will be lost during table growth. > > Ah, I didn't know about the risk of loosing signals while resizing the table. Thanks for that. Don't get me wrong I wasn't proposing to set inProduction in effect. I don't think that automatically growing resource management is a proper way to design a system. There is always a range of resources you need for your use case. Not setting an upper bound for this just covers leaking behavior. > > Norbert > > > > > > -- > Best regards, > Igor Stasenko.

Oct. 7, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Henrik Johansen

On Oct 7, 2013, at 5:40 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 7 October 2013 17:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > 1 thing. > > > > can you tell me what given expression yields for your VM/image: > > > > Smalltalk vm maxExternalSemaphores > > > > (if it gives you number less than 10000000 then i think i know what is your problem :) > > > > Uhm, I didn't read your implementation, but the proper thing to do for a VM which doesn't care about the external objects table (splObjs at: 39) growing, is returning nil from maxExternalSemaphores, like it will for pre-Cog VM's. > > or.. release VM + image, where image aware of current VM capabilities, and refuses to run on older ones, and get rid of all this stuff altogether. > > i changed the low-level implementation (C level), but not primitive level. sure thing more cleanup & polishing can be done, > but the changes i made never get reviewed and properly tested (though, there was no problems reported since year from when it was introduced, > except from last unfortunate rollback to Eliot's original implementation). I know, which is why I thought you might like the feedback :P AFAICT, it would be nice to couple the changes you made with changing parameterAt: 49 back to returning nil, as well as returning an error for parameterAt: 49 put: that the section is not in use/obsolete, instead of returning bogus values. Though, sounds a bit strange how parameterAt: 49 can return a huge number without any changes to the related code (which would then still be reading from a 16bit field :P) > > > Otherwise, you'll get a domain error when you eventually (yes,yes, it'll take awhile) run out, and maxExternalSemaphoresSilently: tries to set the new max to a value that won't fit in the 16bit header field where it expects to put itâ¦ > > yes.. theoretically.. but i have gut feeling that your image/setup will experience a lot of other different problems (memory consumption/amount of available OS handles etc), before you get to that point. And at that point, you will need to modify VM/OS/image anyways (or figure how to work around limits in other way).. > Yap, I guess you could say changing to a nil return would be more a change to play by established conventions when reporting capabilities/needs of the VM than anything with practical impact. Cheers, Henry

Oct. 7, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Igor Stasenko

On 7 October 2013 17:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: > > On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > 1 thing. > > > > can you tell me what given expression yields for your VM/image: > > > > Smalltalk vm maxExternalSemaphores > > > > (if it gives you number less than 10000000 then i think i know what is > your problem :) > > > > Uhm, I didn't read your implementation, but the proper thing to do for a > VM which doesn't care about the external objects table (splObjs at: 39) > growing, is returning nil from maxExternalSemaphores, like it will for > pre-Cog VM's. > or.. release VM + image, where image aware of current VM capabilities, and refuses to run on older ones, and get rid of all this stuff altogether. i changed the low-level implementation (C level), but not primitive level. sure thing more cleanup & polishing can be done, but the changes i made never get reviewed and properly tested (though, there was no problems reported since year from when it was introduced, except from last unfortunate rollback to Eliot's original implementation). > Otherwise, you'll get a domain error when you eventually (yes,yes, it'll > take awhile) run out, and maxExternalSemaphoresSilently: tries to set the > new max to a value that won't fit in the 16bit header field where it > expects to put itâ¦ > > yes.. theoretically.. but i have gut feeling that your image/setup will experience a lot of other different problems (memory consumption/amount of available OS handles etc), before you get to that point. And at that point, you will need to modify VM/OS/image anyways (or figure how to work around limits in other way).. > Cheers, > Henry > -- Best regards, Igor Stasenko.

Oct. 7, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Henrik Johansen

On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua(a)gmail.com> wrote: > 1 thing. > > can you tell me what given expression yields for your VM/image: > > Smalltalk vm maxExternalSemaphores > > (if it gives you number less than 10000000 then i think i know what is your problem :) > Uhm, I didn't read your implementation, but the proper thing to do for a VM which doesn't care about the external objects table (splObjs at: 39) growing, is returning nil from maxExternalSemaphores, like it will for pre-Cog VM's. Otherwise, you'll get a domain error when you eventually (yes,yes, it'll take awhile) run out, and maxExternalSemaphoresSilently: tries to set the new max to a value that won't fit in the 16bit header field where it expects to put itâ¦ Cheers, Henry

Oct. 7, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30461 Home: https://github.com/pharo-project/pharo-core

Oct. 7, 2013

[pharo-project/pharo-core] fda431: 30461

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: fda431fecd8dea237857af496c265b289a1b4f13 https://github.com/pharo-project/pharo-core/commit/fda431fecd8dea237857af49… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-07 (Mon, 07 Oct 2013) Changed paths: M Monticello-Announcements.package/MCVersionCreated.class/definition.st R Monticello-Announcements.package/MCVersionCreated.class/instance/accessing/name_.st M Monticello-Repositories.package/MCFtpRepository.class/definition.st A Monticello-Repositories.package/MCVersionNotification.class/instance/accessing/messageText.st R Monticello-Repositories.package/MCVersionNotification.class/instance/as yet unclassified/initializeWithVersion_repository_.st R Monticello-Repositories.package/MCVersionNotification.class/instance/as yet unclassified/messageText.st R Monticello-Repositories.package/MCVersionNotification.class/instance/as yet unclassified/notify_.st A Monticello-Repositories.package/MCVersionNotification.class/instance/error handling/notify_.st A Monticello-Repositories.package/MCVersionNotification.class/instance/initialize-release/initializeWithVersion_repository_.st M Monticello-Storing.package/MCDataStream.class/instance/write and read/next.st M Monticello-Versioning.package/MCMergeRecord.class/README.md M Monticello-Versioning.package/MCMergeRecord.class/definition.st M Monticello-Versioning.package/MCWorkingCopy.class/definition.st R Monticello.package/MCDirtyPackageInfo.class/class/as yet unclassified/initialize.st R Monticello.package/MCDirtyPackageInfo.class/class/as yet unclassified/wantsChangeSetLogging.st A Monticello.package/MCDirtyPackageInfo.class/class/compiling/wantsChangeSetLogging.st A Monticello.package/MCDirtyPackageInfo.class/class/initialization/initialize.st A Monticello.package/MCMockDefinition.class/class/accessing/token_.st R Monticello.package/MCMockDefinition.class/class/as yet unclassified/token_.st R Monticello.package/MCMockDefinition.class/class/as yet unclassified/wantsChangeSetLogging.st A Monticello.package/MCMockDefinition.class/class/compiling/wantsChangeSetLogging.st M Ring-Core-Containers.package/RGAbstractContainer.class/instance/iterating elements/elementsDo_.st M Ring-Core-Containers.package/RGAbstractContainer.class/instance/testing/includesElementNamed_in_.st M Ring-Core-Containers.package/RGContainer.class/instance/image class and method loading/loadTraitUsers.st M Ring-Core-Kernel.package/RGBehaviorDefinition.class/instance/accessing class hierarchy/allSuperclassesDo_.st M Ring-Core-Kernel.package/RGBehaviorDefinition.class/instance/testing/includesProtocol_.st M Ring-Core-Kernel.package/extension/SourceFileArray/instance/sourcedDataAt_.st M Ring-Core-Kernel.package/extension/Trait/instance/asRingDefinitionWithMethods_withSuperclasses_withSubclasses_withPackageKeys_in_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script116.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30461.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SystemNavigation.class/instance/message sends/allSendersOf_inClass_.st R System-Support.package/SystemNavigation.class/instance/query/allPrimitiveMethodsInCategories_.st R Tools.package/extension/SystemNavigation/instance/doWithProgressBar_forUnsentMessagesInPackageNamed_.st R Tools.package/extension/SystemNavigation/instance/unsentMessagesWithProgressBarInPackageNamed_.st Log Message: ----------- 30461 11808 Small critic cleanup if Ring https://pharo.fogbugz.com/f/cases/11808 11809 Fix failing tests SystemNavigation https://pharo.fogbugz.com/f/cases/11809 11788 Trivial critic cleanup of Monticello https://pharo.fogbugz.com/f/cases/11788

Oct. 7, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

Oct. 7, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=ma… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

Oct. 7, 2013