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 <mailto: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/9e442addff3790af0c78dbc73f1f34... <https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f34...> )
cheers Johan
On 22 Jul 2018, at 10:52, Johan Brichau <johan@inceptive.be <mailto: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 <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