[Pharo-project] Sunit3.2
lukas what should we do? SUnit-lr.76.mczFilename: SUnit-lr.76.mcz Author: Timestamp: 13 September 2009 1:07:41 pm UUID: df933429-8228-4ae9-938b-3565231fd2f5 Ancestors: SUnit-adrian_lienhard.75.mcz Message: Trying to merge the SUnit 3.2 changes, but the difference of Pharo with SUnit 3.1 seems to be so substantial that nearly half of the complete code base conflicts with the SUnit 3.2 code. This code should incorporate the code, but it somehow seems to be subtly broken. Downloads: Web: 5
Hi Stef, I tried to merge the changes with mcz packages that Niall prepared. As it says in the commit comment the code is broken. The difference of SUnit in Pharo is so substantial that almost every method was a conflict. I spent a few hours and tried to merge the changes manually, but in the end it did not work as expected. There are some subtle bugs in the SUnit code and some tools we have in Squeak are broken afterwards. A better strategy would probably be to apply the changes manually as they are described on the slides of Niall. Merging the code definitely does not work. Lukas 2009/9/27 Stéphane Ducasse <stephane.ducasse@inria.fr>:
lukas
what should we do?
SUnit-lr.76.mczFilename: Â Â Â Â SUnit-lr.76.mcz Author: Timestamp: Â Â Â 13 September 2009 1:07:41 pm UUID: Â df933429-8228-4ae9-938b-3565231fd2f5 Ancestors: Â Â Â SUnit-adrian_lienhard.75.mcz Message:
Trying to merge the SUnit 3.2 changes, but the difference of Pharo with SUnit 3.1 seems to be so substantial that nearly half of the complete code base conflicts with the SUnit 3.2 code. This code should incorporate the code, but it somehow seems to be subtly broken. Downloads: Â Â Â Web: 5
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
On Sun, Sep 27, 2009 at 10:55 AM, Lukas Renggli <renggli@gmail.com> wrote:
I tried to merge the changes with mcz packages that Niall prepared. As it says in the commit comment the code is broken. The difference of SUnit in Pharo is so substantial that almost every method was a conflict. I spent a few hours and tried to merge the changes manually, but in the end it did not work as expected. There are some subtle bugs in the SUnit code and some tools we have in Squeak are broken afterwards.
What about replacing Pharo's SUnit by Nial's and then re-add lost features? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
I have the impression that Sunit should be an API specification not a implementation common to all the dialect. So I would really like to see if nial has some tests for SUnit3.2 and which ones pass and fail on pharo. Stef On Sep 27, 2009, at 11:06 AM, Damien Cassou wrote:
On Sun, Sep 27, 2009 at 10:55 AM, Lukas Renggli <renggli@gmail.com> wrote:
I tried to merge the changes with mcz packages that Niall prepared. As it says in the commit comment the code is broken. The difference of SUnit in Pharo is so substantial that almost every method was a conflict. I spent a few hours and tried to merge the changes manually, but in the end it did not work as expected. There are some subtle bugs in the SUnit code and some tools we have in Squeak are broken afterwards.
What about replacing Pharo's SUnit by Nial's and then re-add lost features?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What about replacing Pharo's SUnit by Nial's and then re-add lost features?
Yes, that's what I wrote in the second paragraph :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi lukas
Yes, that's what I wrote in the second paragraph :-)
I could not find your second paragraph. I would prefer to avoid to lose what have been added to SUnit. Now I read the SUnit version of keith and there are only a couple of methods that do not exist in pharo from his version. I did not check the SUnit-Extensions (because the package was empty). But it would be good to have a way to integrate that too. AddSuite... and others seems obvious good addition. Now I checked SUnit3.2 and well.... if we restart from it then a lot of what marcus did to clean it will be lost. Behavior>>sunitAllSelectors ^self allSelectors asSortedCollection asOrderedCollection BTW our version does not have the last fixes of marcus from the SUnit repository. BlockContext>>sunitOn: anException do: aHandlerBlock ^self on: anException do: aHandlerBlock Class>>sunitName ^ self name Do we want this kind of crap? Now we could do that incrementally. Do you know if SUnit3.2 has tests? Stef
Now we could do that incrementally. Do you know if SUnit3.2 has tests?
Yes, more than SUnit 3.1. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I also think that SUnit 3.2 should be packaged differently. Now this is annoying to get all the wrapper code. Any idea how to get rid of them in a reproduceable way? Stef
I also think that SUnit 3.2 should be packaged differently. Now this is annoying to get all the wrapper code. Any idea how to get rid of them in a reproduceable way?
Ideally we had an SUnit-Base package that is identical to SUnit on other platforms and then have the rest of the code as a separate package. Unfortunately the extensions of Pharo do not really package (not doable without overrides). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Sep 27, 2009, at 9:05 PM, Lukas Renggli wrote:
I also think that SUnit 3.2 should be packaged differently. Now this is annoying to get all the wrapper code. Any idea how to get rid of them in a reproduceable way?
Ideally we had an SUnit-Base package that is identical to SUnit on other platforms and then have the rest of the code as a separate package. Unfortunately the extensions of Pharo do not really package (not doable without overrides).
Yes SUnit is the coolest framework on earth but not extensible :) What a pity. Stef
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
may be we should say that to niall. why can we have extensions in this great frameworks of 3 class long?
I also think that SUnit 3.2 should be packaged differently. Now this is annoying to get all the wrapper code. Any idea how to get rid of them in a reproduceable way?
Ideally we had an SUnit-Base package that is identical to SUnit on other platforms and then have the rest of the code as a separate package. Unfortunately the extensions of Pharo do not really package (not doable without overrides).
Yes SUnit is the coolest framework on earth but not extensible :) What a pity.
Stef
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I tried to load 32.fullNiall in pharo and it -> DNU TestCase class>>methodChanged: I checked and I do not understand where this method is coming from. valueWithArguments: anArray startingFrom: startIndex "Do the same as my parent, but make sure that all actions that do not give errors are evaluated before resignaling the ones that gave errors (giving the chance to clients to handle them)." "Note: I currently trap Halt,Error so that I am sure to get a Halt event in case of a Halt. This is being fixed in the exception system - when the fix is done it will be enough to capture only Error." | each answer | startIndex to: self size do: [:index | each := self at: index. each isReceiverOrAnyArgumentGarbage ifFalse: [ [answer := each "each is bound to WeakMessageSend(#methodChanged: -> TestCase)" alueWithArguments: anArray] on: Halt, Error do: [:exc | self valueWithArguments: anArray startingFrom: index + 1. exc pass]]]. ^ answer triggerEvent: anEventSelector withArguments: anArgumentList ^(self actionForEvent: anEventSelector) valueWithArguments: anArgumentList (self actionForEvent: anEventSelector) with self = aSystemEventManager anEventSelector = 'methodRemovedEvent:' -> #(WeakMessageSend(#event: -> a SmalltalkImage) WeakMessageSend(#event: -> Utilities) WeakMessageSend(#methodRemoved: -> MCWorkingCopy) WeakMessageSend(#methodChanged: -> ServiceRegistry) WeakMessageSend(#updateInstances: -> TheWorldMainDockingBar) WeakMessageSend(#methodChanged: -> TestCase) WeakMessageSend(#classChanged: -> a RequiredSelectors) WeakMessageSend(#classChanged: -> a ProvidedSelectors) WeakMessageSend(#classChanged: -> a LocalSends) WeakMessageSend(#event: -> a ChangeSet named SUnit-niall.FULL.3.22)) I have no idea where WeakMessageSend(#methodChanged: -> TestCase) comes from. Stef On Sep 27, 2009, at 12:19 PM, Lukas Renggli wrote:
What about replacing Pharo's SUnit by Nial's and then re-add lost features?
Yes, that's what I wrote in the second paragraph :-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I tried to load 32.fullNiall in pharo and it -> DNU TestCase class>>methodChanged:
I checked and I do not understand where this method is coming from.
That's because TestCase registers for change notification and these methods are suddenly gone. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (3)
-
Damien Cassou -
Lukas Renggli -
Stéphane Ducasse