failing tests

Hi,

A ton of tests are still failing due to the issue of Collection>>union:. Most of these issues seem to come from the metrics that seem to overuse this functionality:
http://ci.moosetechnology.org/job/moose-latest-dev/lastCompletedBuild/testReport/

It would be great if the authors would look over it.

Cheers,
Doru


--
www.tudorgirba.com

"Live like you mean it."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I fixed the problems related to allRecursiveTypes. However, there are still several usages of union: in the KGB API. I would be so happy if we would take the opportunity to simply remove most of this API and use Chef instead.

Anyone interested? :)

Doru


On 18 Mar 2012, at 20:41, Tudor Girba wrote:

--
www.tudorgirba.com

"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I am not sure how I can help. Produce a new jenkins version and I will look at the history of allRecursiveTypes to understand better.

Alexandre

 
On 18 Mar 2012, at 16:59, Tudor Girba wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Mar 18, 2012, at 9:59 PM, Tudor Girba wrote:

> I fixed the problems related to allRecursiveTypes. However, there are still several usages of union: in the KGB API. I would be so happy if we would take the opportunity to simply remove most of this API and use Chef instead.
Yes

>
> Anyone interested? :)

I'm more than full.
2 days of meetings a week for 3 weeks :(
Not counting travel.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Thanks! I checked the implementation of allRecursiveTypes
It went from

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FAMIXType>>allRecursiveTypes
        "Retrieves all types recursively"

        ^ self types union: (self types flatCollect: [:each | each allRecursiveTypes]).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
to

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FAMIXType>>allRecursiveTypes
        "Retrieves all nested types recursively (including directly nested types and those nested in methods)"
       
        | result |
        result := Set new.
        self allRecursiveTypesDo: [:each | result add: each ].
        ^ result
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I am a bit puzzled. How comes that a new version of #union: break down so many tests.
#union: is a simple operation.

Refactoring what is already existing. How should I refactor:
-=-=-=-=-=-=-=-=-=-=-=-=
FAMIXType>>providerNamespaces
        "returns a set of all the namespaces that the receiver depends on (they include some classes that the receiver inherites, staticly accesses, or uses some of their methods)"
        ^ self inheritedNamespaces union: self invokedNamespaces
-=-=-=-=-=-=-=-=-=-=-=-=

I have the impression that we are bumping into something we should not have bumped into.

Cheers,
Alexandre


On 18 Mar 2012, at 16:59, Tudor Girba wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Mar 18, 2012, at 10:08 PM, Alexandre Bergel wrote:

> I am a bit puzzled. How comes that a new version of #union: break down so many tests.
> #union: is a simple operation.

Yes I would like to know it too.
Do you have one single case that we can understand?

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

The problem is that the new implementation of union: and intersection: makes reference to class directly. Instead, they should use species.

I opened a an issue:
http://code.google.com/p/pharo/issues/detail?id=5523

and created the corresponding slice:
Name: SLICE-Issue-5523-Collection-union-and-intersection-should-use-species-TudorGirba.1
Author: TudorGirba
Time: 20 March 2012, 7:25:55 am
UUID: b3944736-b2d8-4c30-ad24-3c39c2a18cf9
Ancestors:
Dependencies: Collections-Abstract-TudorGirba.158

use species instead of class for Collection>>union: and intersection:



Cheers,
Doru



On 19 Mar 2012, at 20:10, Stéphane Ducasse wrote:

--
www.tudorgirba.com

If you can't say why something is relevant,
it probably isn't.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

thanks good catch!

Stef

On Mar 20, 2012, at 7:34 AM, Tudor Girba wrote:


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev