On 23 Jul 2018, at 20:12, Johan Brichau <johan@inceptive.be> wrote:

Hi Richard,

Thanks for pointing out the difference between #on: and #with: instance creation methods.

This lead me to discover that ReadWriteStream>>on: strangely sets the readLimit instvar to the end��� which is not what I would expect.

Removing that method and reversing the change in the commit I mentioned fixes all the tests on ReadWriteStream in Grease.

The Grease tests have been written to test the ANSI behavior and, afaik, they make sense.

Johan

On 23 Jul 2018, at 17:51, Richard O'Keefe <raoknz@gmail.com> wrote:

(ReadWriteStream on: 'abc') contents

==> 'abc' in GNU Smalltalk and Dolphin

==> '' in Squeak 6.0 and ST/X

Here I think we see why ANSI Smalltalk defined #with:

for {Read,}WriteStreams but not #on:.

When you recall that ReadWriteStream is a subclass of

WriteStream in most Smalltalks, and that

(WriteStream on: (String new: 20))

or whatever is normally used with the argument of #on:

expected to provide *workspace*, not *content*, 

why on earth would you expect

(ReadWriteStream on: 'abc') contents

to be different from

(WriteStream on: 'abc') contents

which is ''?

On 23 July 2018 at 21:50, Johan Brichau <johan@inceptive.be> wrote:

Hi,

As I���m diving into the changes and why it fails:

(ReadWriteStream on: ���abc���) contents

-> = ���abc��� on Pharo 6

-> = ������ on Pharo 7

That seems wrong to me.

(I���ve also sent this question via github on the commit itself https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04 )

cheers

Johan

On 22 Jul 2018, at 10:52, Johan Brichau <johan@inceptive.be> wrote:

Hi,

I am taking a look at making Grease and Seaside work correctly on Pharo7.

There have been a number of changes to the ReadWriteStream implementation in Pharo that break Grease tests: https://travis-ci.org/SeasideSt/Grease/jobs/406766720

It seems ReadWriteStream is broken: the readLimit is almost always wrong meaning that the stream `atEnd`, `contents` etc.. return wrong values 

Before I dive into this, I wanted to inquire if anyone is working on this as I cannot seem to find any open cases on this on the issue tracker.

cheers

Johan