On Mar 16, 2012, at 12:32 PM, Tudor Girba wrote:
Yes. But, I am not sure what we want as a solution here. Perhaps FMMultivalue should mark some methods as shouldNotImplement, or maybe it should not be a subclass of Collection at all.
Yes it looks strange to me.
Stef
Doru
On Fri, Mar 16, 2012 at 12:21 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
This is a change in Pharo?
More precisely the crashes are due to the changes in the Collection>>union:
The original definition was: union: aCollection ^ self asSet addAll: aCollection; yourself
The new definition is: union: aCollection | set | set := self asSet addAll: aCollection; yourself. ^ self class withAll: set asArray
This breaks the assumptions behind FMMultivalueLink because although FMMultivalueLink is a subclass of Collection, it is not supposed to be created with a "withAll:" constructor.
Cheers, Doru
On 15 Mar 2012, at 22:45, Moose wrote:
I updated Pharo to the latest version.
It looks like multiple tests fail because something changed in the computation of allRecursiveTypes.
Cheers, Doru
On 15 Mar 2012, at 22:48, Alexandre Bergel wrote:
How comes there are so many failed tests ?
Alexandre
On 15 Mar 2012, at 16:46, admin@moosetechnology.org wrote:
See http://hudson.moosetechnology.org/job/moose-latest-dev/886/
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev