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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>:


--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sun, Sep 27, 2009 at 10:55 AM, Lukas Renggli <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
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?



_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project