Hi Sven, On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: > Somehow, somewhere there was a change to the implementation of the > primitive called by some streams' #atEnd.
That's a proposed change by me, but it hasn't been integrated yet. So the discussion below should apply to the current stable vm (from August last year). > IIRC, someone said it is implemented as 'remaining size being zero' > and some virtual unix files like /dev/random are zero sized. Currently, for files other than sdio (stdout, stderr, stdin) it is effectively defined as: atEnd := stream position >= stream size And, as you say, plenty of virtual unix files report size 0. > Now, all kinds of changes are being done image size to work around this. I would phrase this slightly differently :-) Some code does the right thing, while other code doesn't. E.g.: MultiByteFileStream>>upToEnd is good, while FileStream>>contents is incorrect > I am a strong believer in simple, real (i.e. infinite) streams, but I > am not sure we are doing the right thing here. > > Point is, I am not sure #next returning nil is official and universal. > > Consider the comments: > > Stream>>#next > "Answer the next object accessible by the receiver." > > ReadStream>>#next > "Primitive. Answer the next object in the Stream represented by the > receiver. Fail if the collection of this stream is not an Array or a String. > Fail if the stream is positioned at its end, or if the position is out of > bounds in the collection. Optional. See Object documentation > whatIsAPrimitive." > > Note how there is no talk about returning nil ! > > I think we should discuss about this first. > > Was the low level change really correct and the right thing to do ? The primitive change proposed doesn't affect this discussion. It will mean that #atEnd returns false (correctly) sometimes, while currently it returns true (incorrectly). The end result is still incorrect, e.g. #contents returns an empty string for /proc/cpuinfo. You're correct about no mention of nil, but we have: FileStream>>next (position >= readLimit and: [self atEnd]) ifTrue: [^nil] ifFalse: [^collection at: (position := position + 1)] which has been around for a long time (I suspect, before Pharo existed). Having said that, I think that raising an exception is a better solution, but it is a much, much bigger change than the one I proposed in https://github.com/pharo-project/pharo/pull/1180. Cheers, Alistair > Note also that a Guille introduced something new, #closed which is related to > the difference between having no more elements (maybe right now, like an open > network stream) and never ever being able to produce more data. > > Sven > > >