<div dir="ltr"><div><div><div>See also <a href="http://bugs.squeak.org/view.php?id=6755">http://bugs.squeak.org/view.php?id=6755</a><br></div>For Andreas, the first problem was performance.<br></div><div>For me, there is another one: a Notification can get miss-interpreted at the wrong level (see post below).<br>
</div>I later started SqueaXTream to steal Stream composition idea from Xtreams and also have a versatile end of stream handling and let programmer choose whether he wants returning nil, another special object or get an Exception when a stream reaches its end.<br>
See <a href="http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/139338">http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/139338</a><br><br></div>Sure, Xtreams supersedes all that stuff, so my experiments staled.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/22 Bob Arning <span dir="ltr"><<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Georgia">Well, I dug around a bit more. Seems Andreas
was concerned about performance, although I did not see an issue.
A week later it was rolled back.<br>
<br>
Also in question was the correct superclass for EndOfStream. I
just made the change in a 4.2 image and TestRunner is not happy
with it being an Error. Make it an Exception and that problem goes
away.<br>
<br>
Cheers,<br>
Bob<br>
<br>
5/24/00 Re: RE: EndOfStream an Error???<br>
<br>
On Wed, 24 May 2000 01:32:44 -0700 "Raab, Andreas"
<a href="mailto:Andreas.Raab@disney.com" target="_blank"><Andreas.Raab@disney.com></a> wrote:<br>
>As it is right now, we're paying the<br>
>price of an error recovery for something that happens quite
often. There are<br>
>many places where senders of #next rely returning nil quickly
if at the end<br>
>of the collection. Such as in #next:into:startingAt:,
#nextChunk,<br>
>#nextDelimited:, #peekFor: etc. With the changes we have a
slowdown of<br>
>approx. 500 for a simple test case like<br>
><br>
> | s |<br>
> s _ ReadStream on: Array new.<br>
> [1 to: 100000 do:[:i| s next]] timeToRun.<br>
><br>
>While the slowdown is okay for an error recovery it is most
definitely not<br>
>okay for those users who do in fact rely on the opposite -
which is a quick<br>
>return of nil for a past end read operation. And as it stands
ALL those<br>
>users are affected by the modification.<br>
<br>
Andreas,<br>
<br>
Do you have an example that's a little more realistic? I was
wondering what the effect would be on typical code, so I made a
change to count the number of times that EndOfStream was actually
signalled. Then I browsed around for a while and when I checked
the number, it was still zero! So, I thought, filing in some code
ought to do it. Nope - still zero. It wasn't until I evaluated
"(ReadStream on: '1') nextChunk" that I actually got a hit. Hmm...<br>
<br>
Cheers,<br>
Bob<br>
======================<br>
5/24/00 Re: RE: EndOfStream an Error???<br>
<br>
On Wed, 24 May 2000 12:32:32 -0700 "Raab, Andreas"
<a href="mailto:Andreas.Raab@disney.com" target="_blank"><Andreas.Raab@disney.com></a> wrote:<br>
>What I do know, however, is that not too long ago we've
integrated a change<br>
>set (I think from Bert) which modified quite some places to
use the<br>
>#next/#isNil test instead of #atEnd. Which leads me to the
assumption that<br>
>there ought to be places in which a quick return might be
really critical.<br>
<br>
I think there is an important distinction here. If you have code
like:<br>
<br>
[s atEnd] whileFalse: [el _ s next. el whatEver]<br>
<br>
then you will be sending #atEnd for each element in the stream and
sending #next one less time. By changing that to<br>
<br>
[(el _ s next) isNil] whileFalse: [el whatEver]<br>
<br>
you are essentially substituting #isNil for #atEnd for every
element. That can add up to substantial savings. The change to
EndOfStream changes only the performance of the *last* #next while
all the others (assuming there are elements in the stream) remain
as fast as ever. There will clearly be some performance penalty,
but the magnitude will depend on the number of elements processed
before end of stream. If the typical case involves empty streams,
then the cost will be quite high. If the typical stream processed
as above has tens or hundreds (or more) of elements, then the cost
of EndOfStream will be a much smaller fraction of the total
processing time.<br>
<br>
I think, as has already been suggested, it might be wise to back
off this change until we resolve whether Error or Exception is a
better place for it (I lean toward Exception, Notification or
perhaps ErrorsForWhichTheDefaultActionIsUsuallyAcceptable rather
than Error). Once that is decided, we can see if there are any
noticeable performance hits, especially once EndOfStream is added
to the other places where it can be detected
(StandardFileStream>>next, e.g.).<br>
<br>
Cheers,<br>
Bob<br>
<br>
==============================================<br>
<br>
<br>
<br>
</font><div><div class="h5">
<div>On 7/22/13 2:31 PM, Chris Muller wrote:<br>
</div>
<blockquote type="cite">
<pre>Interesting, I wonder what the consequences were..
On Mon, Jul 22, 2013 at 11:22 AM, Bob Arning <a href="mailto:arning315@comcast.net" target="_blank"><arning315@comcast.net></a> wrote:
</pre>
<blockquote type="cite">
<pre>For the historically-obsessed,
Change Set: 069EOS-hh (really2192EOS-hh)
Date: 18 May 2000
Author: Helge Horch
Requires: Squeak 2.8a
Modifies ReadStream>>next to signal an Error (EndOfStream) on attempts to
read
at or beyond the end of the stream. Thanks to Bob Arning (who is silently
credited
in the stamps <g>), existing applications relying on seeing nils should not
be
affected.
Change Set: 102ReadStreamUndo-sma (really 2272ReadStreamUndo-sma)
Date: 1 June 2000
Author: Stefan Matthias Aust
Undo #2192. The consequences of raising an exception for EOF during
ReadStream>>next should be worked out in 2.9a but not for 2.8.
and, AFAIK, that was the end of that.
Cheers,
Bob
On 7/22/13 12:09 PM, Chris Muller wrote:
What if a system needs to allow nil objects in a Stream of objects and
have it be treated as just another object in the stream rather than
the EOS marker?
So, maybe ReadStream>>#next _should_ be signaling EndOfStream, so the
sender of #next can know the difference in that scenario. Since the
defaultAction is ^nil, presumably we could simply change #next to do
that with no breakage...
On Mon, Jul 22, 2013 at 9:02 AM, Frank Shearar <a href="mailto:frank.shearar@gmail.com" target="_blank"><frank.shearar@gmail.com></a>
wrote:
EndOfStream has no references in the base image. It claims to be used
by ReadStream >> #next, but that's not true.
Time to die/deprecate?
frank
</pre>
</blockquote>
<pre>
</pre>
</blockquote>
<br>
</div></div></div>
<br><br>
<br></blockquote></div><br></div>