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
>
>
>
