Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2014-July/007182.html

Name: System-kfr.678
Ancestors: System-kfr.677

When collapsing windows pay attention to the height of the docking bar

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-July/007183.html

Name: System-kfr.679
Ancestors: System-kfr.678

Utilities class>>commandKeyMappings is now a help topic. This menthod is removed to avoid dupication
Utilities class>>openCommandKeyHelp opens a HelpBrowser

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-July/007184.html

Name: Morphic-nice.737
Ancestors: Morphic-nice.736

Remove another bit of Read/Write madness.
There is NO reason why a text selection stream should be Read/Write.
As the comment says, the intention is to answer a ReadStream and each and every usage will be that of a ReadStream.
If ever some edition has to happen on the selection, it won't be thru the selectionAsStream, no never. It will be thru another channel, the editor itself (see compile:notifying:)

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-July/007185.html

Name: ST80-nice.173
Ancestors: ST80-cmm.172

Remove another bit of Read/Write madness.
There is NO reason why a text selection stream should be Read/Write.
As the comment says, the intention is to answer a ReadStream and each and every usage will be that of a ReadStream.
If ever some edition has to happen on the selection, it won't be thru the selectionAsStream, no never. It will be thru another channel, the editor itself (see compile:notifying:)

I should stop repeating myself, but there is so many duplicated code.
I should stop repeating myself, but there is so many duplicated code.

=============================================

http://lists.squeakfoundation.org/pipermail/packages/2014-July/007186.html

Name: Graphics-nice.296
Ancestors: Graphics-nice.295

Don't try to accelerate GIF reading by copying the stream in memory.
This should be the purpose of a decent file buffering policy, and if ever that was not the case, then we should fix the file buffering policy rather than trying to patch each and every client site.

Especially when the patch is testing that the stream is in memory with a class identity to ReadWriteStream!!!
Frankly, how do we know that it's not a RWBinaryOrTextStream ;)

So why reading an image with a ReadWriteStream?
Oh, sure, this is in ImageReadWriter, so we may need a ReadWriteStream?
No, no, and no!
This thing will either read or write but NEVER read and write.
One simple role, one simple class, no UberPotentSwissKnifeStream with UberComplexStateToManage (readPosition + writePosition + readLimit + writeLimit + readBuffer + writeBuffer + readWriteBufferInteraction).

What's coming next?
Easy to guess, see what (ImageReadWriter>>on:) does frivously to our stream:
reset??? Hey, ImageReadWriter, why do you take the responsibility to reset the stream? Did you ask the permission? Did you think of possible side effects?
I'm quite sure those reset has something to do with following usage:
    (ReadWriteStream with: 'foo') next -> nil
but:
    (ReadWriteStream with: 'foo') reset; next -> $f
Pure Read/Write madness.
There is more room for cleanup here, but only after I get rid of more R/WThing (TM), otherwise I could break some insane expectations.

=============================================