[Seaside-dev] GROrderedCollectionTest>>#testSort

Latest load test results. So is OrderedCollection>>#'sorted' supposed to exist in PharoCore1.0rc2 (Latest update: #10508)?

Loaded Grease-Core-jf.23.mcz
Loaded Grease-Pharo-Core-jf.11.mcz
Loaded Grease-Tests-Core-lr.36.mcz
Loaded Grease-Tests-Pharo-Core-jf.5.mcz
        346 run, 343 passes, 2 expected failures, 0 failures, 1 errors, 0 unexpected passes
                GROrderedCollectionTest>>#testSort

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

#sort you mean? Not yet... we either need to add it in Pharo, fix it
in the one click, or add it to the Grease package. Lukas was looking
into that...

On Tue, Feb 16, 2010 at 12:44 PM, James Foster <[hidden email]> wrote: _______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> #sort you mean? Not yet... we either need to add it in Pharo, fix it
> in the one click, or add it to the Grease package.

OrderedCollection>>#sort and OrderedCollection>>#sort: is already part
of Pharo 1.1. The Seaside tests pass in Pharo 1.1.

I understand and I agree with Pharo not to implement #sort and #sort:
in SequenceableCollection, because it does not make sense for most
subclasses. SortedCollection, Heap and Interval are already sorted;
and for LinkedList sorting does not really make sense.

So I don't really know what to do to fix the Seaside test. We could
ask the Pharo guys to integrate OrderedCollection>>#sort and
OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too
late?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> I understand and I agree with Pharo not to implement #sort and #sort:
> in SequenceableCollection, because it does not make sense for most
> subclasses. SortedCollection, Heap and Interval are already sorted;

Interval and SortedCollection are only sorted according to one
particular sort block, which may not be the default sort block (e.g. for
decreasing intervals).  For Interval the only sensible solution is
#shouldNotImplement, but for SortedCollection it is plausible to make
#sort or #sort: change the collection's sort block.

> and for LinkedList sorting does not really make sense.

Why not?  Unlike arrays you can do linked list mergesort without
auxiliary space (though the linked list already has O(n) overhead so
that means without extra space compared to what the data structure
already needs), and it is still guaranteed O(n log n).  Of course I'm
not really suggesting to implement LinkedList>>#sort. :-)

> So I don't really know what to do to fix the Seaside test. We could
> ask the Pharo guys to integrate OrderedCollection>>#sort and
> OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too
> late?

Grease-Squeak should provide it.

Paolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Wed, Feb 17, 2010 at 5:13 AM, Lukas Renggli <[hidden email]> wrote:
As Paolo points out, they are not necessarily sorted by the desired
block. For SortedCollection, I agree the correct behaviour is to set
the sortBlock. VW handles subclasses (like Interval) that cannot be
sorted in place very simply: the sorter is implemented in terms of
#at: and #at:put: and classes that cannot be modified with #at:put:
just return an error saying that they can't be stored into. This also
covers, for example, Arrays that are marked as immutable. There are
many many subclasses of SequenceableCollection that do implement
#at:put: and can be sorted properly...

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev