j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
"Andreas Raab" Andreas.Raab@gmx.de wrote: We fixed this problem today. It turned out that there was a slight mismatch in boundary conditions with #to:do: loops - Squeak evaluates the upper bound only once whereas the equivalent C code (using for(;;)) may do this multiple times.
Er, I ran into a problem that was caused by Squeak doing the C thing here. I _wrote_ 1 to: n do: [: i | ... ] and got the same effect, in fact the same bytecodes, as for i := 1. [i <= n] whileTrue: [... i := i + 1]. or something like that. I was annoyed, because n was changing, and I had written it as a method call precisely so it _would_ be evaluated once.
Here's an example I just tried in Squeak 3.2:
n := 1. r := OrderedCollection new. 1 to: n do: [:i | r add: i. n _ n - 1]. r
select the lot in a workspace, and PrintIt.
==> an OreredCollection(1 2 3 4 5).
This does not look like #to:do: evaluating its upper bound just once...
squeak-dev@lists.squeakfoundation.org