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

Re: [Pharo-project] Test Resources

by Frank Shearar

On 28 February 2013 17:37, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi, > > Jannik and I are having trouble dealing with resources in our robotic project. > It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources. > > My understanding of resources is that they should be reset only once for a whole test suite. > For every test case, they should be setUp/tearDown, but not fully reset. > > We couldn't find a clean way of working this out. > We ended up defining our own subclass of TestSuite, which I believe is dirty. > Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this. Are you looking for TestResources? frank

Feb. 28, 2013

Re: [Pharo-project] Kind of Stuff I would like to change in 3.0

by Frank Shearar

On 28 February 2013 15:46, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > TestCase>>cleanUpInstanceVariables > self class allInstVarNames do: [ :name | > name = 'testSelector' ifFalse: [ > self instVarNamed: name put: nil ] ] What is it that you find wrong about this? Its absence would cause a problem with Fuel, where the TestCases end up hanging onto obsolete classes. frank

Feb. 28, 2013

[Pharo-project] Test Resources

by Noury Bouraqadi

Hi, Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources. My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset. We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this. Any hint, idea is welcome, Noury 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

Feb. 28, 2013

[Pharo-project] [update 2.0] #20575

by Esteban Lorenzano

20575 ----- Issue 7621: Protocols are sometimes messed up https://code.google.com/p/pharo/issues/detail?id=7621 Issue 7620: remove IslandVMTweaksTestCase https://code.google.com/p/pharo/issues/detail?id=7620 Issue 7615: unload NativeBoost tests for now... https://code.google.com/p/pharo/issues/detail?id=7615 Issue 7609: [Horrible Error]: Class creation not logged in changes https://code.google.com/p/pharo/issues/detail?id=7609 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tests-EstebanLorenzano.517.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-EstebanLorenzano.794.diff http://ss3.gemstone.com/ss/Pharo20/System-Changes-EstebanLorenzano.198.diff http://ss3.gemstone.com/ss/Pharo20/KernelTests-EstebanLorenzano.472.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1322.diff

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Henrik Johansen

In reply to the reference to #deprecation, removal is the only viable option in this case. The implementations of WideString >> #asPacked and WideString class >> #fromPacked: fundamentally disagree in what it means for a WideString to be packed, and there's no telling how long it's been that way. In other words; straight up remove it, and leave it up to whichever user may require it to provide a consistent implementation as per his/her usage. Cheers, Henry

Feb. 28, 2013

Re: [Pharo-project] Is this possible with XMLWriter?

by stephane ducasse

Please use the version that is now published in PharoExtras. If you add tests please commit them :) On Feb 27, 2013, at 6:55 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I am using XMLWriter from http://www.squeaksource.com/XMLWriter to write a specific XML that a protocol expects. > What I need is to build the XML file from parent to children and dynamically. For example, I want to be able to define a tag, but then, later on, add more tags to a parent element. > I found this impossible to do with the current XMLWriter. Here, messages like #tag:with: , #with: do not help. > I know I will need to build everything in memory and send a "write contents" at the end to get the final XML string... > > For example, say I wanna build this XML: > > <root> > <parent1> > <child1>grrr<child1> > <child2>grrr<child2> > </parent1> > <parent2> > <child3>buhhh<child3> > </parent2> > </root> > > i would like an API like this: > > | xmlWriter | > xmlWriter := XMLWriter new. > xmlWriter tag: 'root'. > (xmlWriter named: 'root') tag: 'parent1'. > (xmlWriter named: 'parent1') tag: 'child' with: 'grrr'. > (xmlWriter named: 'root') tag: 'parent2'. > .... > xmlWriter write contents. > > > Or even if I don't have #named: but I can store them in instVars it would be fine: > > | xmlWriter rootTag parent1Tag | > xmlWriter := XMLWriter new. > rootTag xmlWriter tag: 'root'. > parent1Tag rootTag tag: 'parent1'. > parent1Tag tag: 'child' with: 'grrr'. > rootTag tag: 'parent2' > xmlWriter write contents. > > > Any ideas how to do this? > > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 28, 2013

[Pharo-project] Kind of Stuff I would like to change in 3.0

by Noury Bouraqadi

TestCase>>cleanUpInstanceVariables self class allInstVarNames do: [ :name | name = 'testSelector' ifFalse: [ self instVarNamed: name put: nil ] ] Jannik & Noury -- http://twitter.com/#!/NouryBouraqadi 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

Feb. 28, 2013

Re: [Pharo-project] IslandVMTweaksTestCase and Memory corruption

by Marcus Denker

On Feb 28, 2013, at 4:15 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > No, I think that those tests should be shipped... And fix the VM to not corrupt the memory. That's only in the case these test are wrote in pure smalltalk. If they use ffi then yeah they should be removed > They have primitives in methods for which the primitive was not written. > On Feb 28, 2013 3:11 PM, "Marcus Denker" <marcus.denker(a)inria.fr> wrote: > > On Feb 28, 2013, at 3:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> I was looking for VM tests in the Pharo image and I found the class IslandVMTweaksTestCase. The strange thing is its comments : >> "Test case for some tweaks to the VM that Islands requires. These tests are largely for documentation; with an un-tweaked VM, the tests mostly still succeed, albeit with possible memory corruption." >> >> Does that really mean if I run those tests it might result into memory corruption ? >> >> I don't think it is a good idea to ship Pharo with this memory corruption tests in IslandVMTweaksTestCase. I suggest that if the tests may really corrupt memory we remove them from Pharo, or if they cannot corrupt memory then we fix the memory corruption comment. >> > Yes, we should not ship code like that. > > Marcus >

Feb. 28, 2013

Re: [Pharo-project] IslandVMTweaksTestCase and Memory corruption

by Ciprian Teodorov

No, I think that those tests should be shipped... And fix the VM to not corrupt the memory. That's only in the case these test are wrote in pure smalltalk. If they use ffi then yeah they should be removed On Feb 28, 2013 3:11 PM, "Marcus Denker" <marcus.denker(a)inria.fr> wrote: > > On Feb 28, 2013, at 3:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > I was looking for VM tests in the Pharo image and I found the > class IslandVMTweaksTestCase. The strange thing is its comments : > "Test case for some tweaks to the VM that Islands requires. These tests > are largely for documentation; with an un-tweaked VM, the tests mostly > still succeed, albeit *with possible memory corruption*." > > Does that really mean if I run those tests it might result into memory > corruption ? > > I don't think it is a good idea to ship Pharo with this memory corruption > tests in IslandVMTweaksTestCase. I suggest that if the tests may really > corrupt memory we remove them from Pharo, or if they cannot corrupt memory > then we fix the memory corruption comment. > > Yes, we should not ship code like that. > > Marcus > >

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Martin Dias

Thank you Sean and Marcus. I tried to find all methods that are only referenced by MethodFinder (like asPacked), but I gave up after some minutes... Yeti sounds good. I remember a guy from Germany that come to Smalltalks 2009 (IIRC) that showed the testing tools from his company, made in smalltalk. It was a nice presentation. Martin On Thu, Feb 28, 2013 at 3:00 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > tinchodias wrote >> Are you talking about an specific pragma for deprecation? I didn't catch >> it. > > I was thinking of something like <safeForMethodFinder>, but agree with > Marcus's objection that those would have to be sprinkled everywhere in the > system. It solves one problem, but creates another... > > > > -- > View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672713.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 28, 2013