[Pharo-project] Infinite loop in new Collection Tests
While running TestRunner, i noticed this: LinkedListTest>>testTAdd does an infinite loop. This is because: self collection first == self element since the test does: self collection add: self element this results in: self collection firstLink next next == firstLink and consequently any loop will loop infinitely... My base image is not well equipped with a Trait-aware Browser, so i let this one to Trait experts. Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process. This is regularly bugging newcomers, and I would recommend an evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html That is, Link should be a transparent-implementation-defined-intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value. Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features. Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association. Nicolas
a link should also have some state :) StackLink is ok for that. On Nov 1, 2008, at 3:57 PM, nicolas cellier wrote:
While running TestRunner, i noticed this:
LinkedListTest>>testTAdd does an infinite loop.
This is because: self collection first == self element
since the test does: self collection add: self element
this results in: self collection firstLink next next == firstLink
and consequently any loop will loop infinitely...
It seems to me that this is bug of damien P. so he will probably fix that. Stef
My base image is not well equipped with a Trait-aware Browser, so i let this one to Trait experts.
Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process. This is regularly bugging newcomers, and I would recommend an evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html
That is, Link should be a transparent-implementation-defined- intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value. Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features.
Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association.
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier <ncellier@ifrance.com> wrote:
While running TestRunner, i noticed this:
LinkedListTest>>testTAdd does an infinite loop.
yes, this is fixed in the next commit in PharoInbox.
Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process.
Exactly. The tests do not loop anymore, but now some fail because LinkedList is not polymorphic with other SequenceableCollections, e.g you cannot do LinkedList new add: 42 because it expects instances of Link as elements.
This is regularly bugging newcomers, and I would recommend an evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html
Great! I will have a look at that.
That is, Link should be a transparent-implementation-defined-intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value.
Well I think there should be a linked-list-specific protocol for dealing with links, either via link objects or by delegation through LinkedList. But this should not overlap with the SequenceableCollection protocol.
Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features. Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association.
Exactly -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
damien so may be we should have valueAt: or elementAt: Now may be we should have different tests. This is important to get the tests green since this is a goal of pharo 1.0 Ste On Nov 1, 2008, at 5:11 PM, Damien Pollet wrote:
On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier <ncellier@ifrance.com> wrote:
While running TestRunner, i noticed this:
LinkedListTest>>testTAdd does an infinite loop.
yes, this is fixed in the next commit in PharoInbox.
Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process.
Exactly. The tests do not loop anymore, but now some fail because LinkedList is not polymorphic with other SequenceableCollections, e.g you cannot do LinkedList new add: 42 because it expects instances of Link as elements.
This is regularly bugging newcomers, and I would recommend an evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html
Great! I will have a look at that.
That is, Link should be a transparent-implementation-defined- intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value.
Well I think there should be a linked-list-specific protocol for dealing with links, either via link objects or by delegation through LinkedList. But this should not overlap with the SequenceableCollection protocol.
Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features. Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association.
Exactly
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Nov 1, 2008 at 8:47 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
damien so may be we should have valueAt: or elementAt:
Good idea, that would reinforce the parallel with Dictionary.
Now may be we should have different tests. This is important to get the tests green since this is a goal of pharo 1.0
Well, it's easy to have green tests, just comment out the assertions. Or remove the broken code. I mean, there is a problem with how that class behaves, compared to the other collections.
On Nov 1, 2008, at 5:11 PM, Damien Pollet wrote:
On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier <ncellier@ifrance.com> wrote:
While running TestRunner, i noticed this:
LinkedListTest>>testTAdd does an infinite loop.
yes, this is fixed in the next commit in PharoInbox.
Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process.
Exactly. The tests do not loop anymore, but now some fail because LinkedList is not polymorphic with other SequenceableCollections, e.g you cannot do LinkedList new add: 42 because it expects instances of Link as elements.
This is regularly bugging newcomers, and I would recommend an evolution toward something like
http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html
Great! I will have a look at that.
That is, Link should be a transparent-implementation-defined-intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value.
Well I think there should be a linked-list-specific protocol for dealing with links, either via link objects or by delegation through LinkedList. But this should not overlap with the SequenceableCollection protocol.
Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features. Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association.
Exactly
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ 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
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (3)
-
Damien Pollet -
nicolas cellier -
Stéphane Ducasse