Smalltalk › Squeak › Squeak - Dev

replaceFrom:to:with:startingAt:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Bert Freudenberg

replaceFrom:to:with:startingAt:

I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't have believed that any code actually relied on the following behavior:

| a |
a := (1 to: 20) asArray.
a replaceFrom: 11 to: 20 with: a startingAt: 8.

==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)

In my (buggy) VM it answered

==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)

which apparently did not at all match what The Creators intended ;)

- Bert -

[*] specifically, #decompressBlock:with:

smime.p7s (5K) Download Attachment

Ron Teitelbaum

RE: replaceFrom:to:with:startingAt:

> From: Bert Freudenberg
> Sent: Monday, September 22, 2014 4:00 PM
>
> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
> have believed that any code actually relied on the following behavior:
>
> | a |
> a := (1 to: 20) asArray.
> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>
> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>

That's funky! Hope it wasn't my code! Seems wrong to not copy the array
before modifying it (Like your buggy VM did).

Ron

> In my (buggy) VM it answered
>
> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>
> which apparently did not at all match what The Creators intended ;)
>
> - Bert -
>
> [*] specifically, #decompressBlock:with:

Bert Freudenberg

Re: replaceFrom:to:with:startingAt:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

smime.p7s (5K) Download Attachment

Nicolas Cellier

Re: replaceFrom:to:with:startingAt:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.

The primitive should use memmove rather than memcpy.

So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

Nicolas Cellier

Re: replaceFrom:to:with:startingAt:

2014-09-22 22:47 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

Well, if memcpy was used, it seems not last time I inquired:

https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/2014-April/048910.html

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

Nicolas Cellier

Re: replaceFrom:to:with:startingAt:

2014-09-22 22:52 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-09-22 22:47 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

Well, if memcpy was used, it seems not last time I inquired:

https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/2014-April/048910.html

And another link if you don't have access to fogbugz

https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/2014-April/048812.html

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

LawsonEnglish

Re: replaceFrom:to:with:startingAt:

In reply to this post by Ron Teitelbaum

If you told the average person that it didn't copy first, I think they would have assumed it was the wrong behavior.

If I told someone to do such a procedure using English words to numbers found 20 text-boxes, they would do it the "erroneous way," I am pretty sure.

L

On 9/22/14, 1:34 PM, Bert Freudenberg wrote:

On 22.09.2014, at 22:21, Ron Teitelbaum [hidden email] wrote:

From: Bert Freudenberg
Sent: Monday, September 22, 2014 4:00 PM

I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
have believed that any code actually relied on the following behavior:

	| a |
	a := (1 to: 20) asArray.
	a replaceFrom: 11 to: 20 with: a startingAt: 8.

	==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)

That's funky!  Hope it wasn't my code!  Seems wrong to not copy the array
before modifying it  (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

Ron

In my (buggy) VM it answered

	==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)

which apparently did not at all match what The Creators intended ;)

- Bert -

[*] specifically, #decompressBlock:with:

-- 
Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner).
https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all 

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

Bert Freudenberg

Re: replaceFrom:to:with:startingAt:

In reply to this post by Nicolas Cellier

On 22.09.2014, at 22:47, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

What I'm saying is that there is code which will actually fail in subtle ways if we change that behavior. The LZW decode *relies* on this. If we change the primitive it would fail.

So rather than changing what the "stringReplace" primitive does we might rather want to add a "stringMove" primitive.

Btw, BitBlt has "move" semantics and I believe this is even used in some places (via #hackBits:).

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

smime.p7s (5K) Download Attachment

Nicolas Cellier

Re: replaceFrom:to:with:startingAt:

2014-09-22 23:16 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:47, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

What I'm saying is that there is code which will actually fail in subtle ways if we change that behavior. The LZW decode *relies* on this. If we change the primitive it would fail.

Ah, oh !

I missread your post!

Relying on an undefined behavior is not a clever thing...

OK, since we never changed the implementation, it's a stable behavior... but it is for sure unspecified.

There is no limit to the hackish nature of some Squeak code, really...

Hang it in the hall of shame.

So rather than changing what the "stringReplace" primitive does we might rather want to add a "stringMove" primitive.

Btw, BitBlt has "move" semantics and I believe this is even used in some places (via #hackBits:).

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

Nicolas Cellier

Re: replaceFrom:to:with:startingAt:

2014-09-23 21:20 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-09-22 23:16 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:47, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

What I'm saying is that there is code which will actually fail in subtle ways if we change that behavior. The LZW decode *relies* on this. If we change the primitive it would fail.

Ah, oh !
I missread your post!
Relying on an undefined behavior is not a clever thing...
OK, since we never changed the implementation, it's a stable behavior... but it is for sure unspecified.
There is no limit to the hackish nature of some Squeak code, really...
Hang it in the hall of shame.

Is it decompressBlock:with: ?

So rather than changing what the "stringReplace" primitive does we might rather want to add a "stringMove" primitive.

Btw, BitBlt has "move" semantics and I believe this is even used in some places (via #hackBits:).

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

Bert Freudenberg

Re: replaceFrom:to:with:startingAt:

On 23.09.2014, at 21:51, Nicolas Cellier <[hidden email]> wrote:

2014-09-23 21:20 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-09-22 23:16 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:47, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

What I'm saying is that there is code which will actually fail in subtle ways if we change that behavior. The LZW decode *relies* on this. If we change the primitive it would fail.

Ah, oh !
I missread your post!
Relying on an undefined behavior is not a clever thing...
OK, since we never changed the implementation, it's a stable behavior... but it is for sure unspecified.
There is no limit to the hackish nature of some Squeak code, really...
Hang it in the hall of shame.

Is it decompressBlock:with: ?

Yep.

- Bert -

So rather than changing what the "stringReplace" primitive does we might rather want to add a "stringMove" primitive.

Btw, BitBlt has "move" semantics and I believe this is even used in some places (via #hackBits:).

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

smime.p7s (5K) Download Attachment

timrowledge

Re: replaceFrom:to:with:startingAt:

In reply to this post by Nicolas Cellier

On 23-09-2014, at 12:20 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Ah, oh !
> I missread your post!
> Relying on an undefined behavior is not a clever thing...
> OK, since we never changed the implementation, it's a stable behavior... but it is for sure unspecified.
> There is no limit to the hackish nature of some Squeak code, really...
> Hang it in the hall of shame.
>
>

It’s not like the PNG code doesn’t need some fixes anyway.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Calling her stupid would be an insult to stupid people.

Eliot Miranda-2

Re: replaceFrom:to:with:startingAt:

In reply to this post by Nicolas Cellier

On Mon, Sep 22, 2014 at 1:47 PM, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

Um, no. It has ever been so and must therefore remain. This is the method (as in the Smalltalk-80 V2 sources) that the primitive optimizes:

replaceFrom: start to: stop with: replacement startingAt: repStart

"This destructively replaces elements from start to stop in the receiver

starting at index, repStart, in the collection, replacement. Answer the

receiver. No range checks are performed - this may be primitively implemented."

| index repOff |

repOff _ repStart - start.

index _ start - 1.

[(index _ index + 1) <= stop]

whileTrue: [self at: index put: (replacement at: repOff + index)]

So the primitive is correct. This is memcpy behaviour. IIRC BitBlt is the same. There were some BitBlt ticks played with image fill that depended on this.

| oc |

oc := OrderedCollection withAll: (1 to: 20).

oc replaceFrom: 11 to: 20 with: oc startingAt: 8.

oc => an OrderedCollection(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

--
best,

Eliot

Eliot Miranda-2

Re: replaceFrom:to:with:startingAt:

In reply to this post by Bert Freudenberg

On Mon, Sep 22, 2014 at 2:16 PM, Bert Freudenberg <[hidden email]> wrote:

On 22.09.2014, at 22:47, Nicolas Cellier <[hidden email]> wrote:

2014-09-22 22:34 GMT+02:00 Bert Freudenberg <[hidden email]>:

On 22.09.2014, at 22:21, Ron Teitelbaum <[hidden email]> wrote:

>
>> From: Bert Freudenberg
>> Sent: Monday, September 22, 2014 4:00 PM
>>
>> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't
>> have believed that any code actually relied on the following behavior:
>>
>> | a |
>> a := (1 to: 20) asArray.
>> a replaceFrom: 11 to: 20 with: a startingAt: 8.
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8)
>>
> That's funky! Hope it wasn't my code! Seems wrong to not copy the array
> before modifying it (Like your buggy VM did).

It's not a copy. It moved the numbers 8-17 to index 11. Which is what I erroneously had assumed to be the desired behavior.

- Bert -

It's a known problem.
The primitive should use memmove rather than memcpy.
So the solution is quite simple, it's just that it's waiting for a good soul to integrate it.

What I'm saying is that there is code which will actually fail in subtle ways if we change that behavior. The LZW decode *relies* on this. If we change the primitive it would fail.

So rather than changing what the "stringReplace" primitive does we might rather want to add a "stringMove" primitive.

+1. An implement a move family, e.g.

SequenceableCollection>>moveFrom: start to: stop with: replacement startingAt: repStart

| index repOff |

repOff := repStart - start.

start > repStart

ifTrue:

[index := stop + 1.

[(index := index - 1) >= start] whileTrue:

[self at: index put: (replacement at: repOff + index)]]

ifFalse:

[index := start - 1.

[(index := index + 1) <= stop] whileTrue:

[self at: index put: (replacement at: repOff + index)]]

But more reasonably

SequenceableCollection>>moveFrom: start to: stop to: repStart

| index repOff |

repOff := repStart - start.

start > repStart

ifTrue:

[index := stop + 1.

[(index := index - 1) >= start] whileTrue:

[self at: index put: (self at: repOff + index)]]

ifFalse:

[index := start - 1.

[(index := index + 1) <= stop] whileTrue:

[self at: index put: (self at: repOff + index)]]

Btw, BitBlt has "move" semantics and I believe this is even used in some places (via #hackBits:).

Yes, you're right. But I think there was a time when you could turn that off and get interesting effects :-).

- Bert -

> Ron
>
>> In my (buggy) VM it answered
>>
>> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17)
>>
>> which apparently did not at all match what The Creators intended ;)
>>
>> - Bert -
>>
>> [*] specifically, #decompressBlock:with:
>
>

--
best,

Eliot