<br><br><div class="gmail_quote">On Wed, Dec 2, 2009 at 8:26 AM, Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/12/2 Colin Putney &lt;<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>&gt;:<br>
<div><div></div><div class="h5">&gt;<br>
&gt; On 1-Dec-09, at 9:55 PM, Andreas Raab wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; file := FileHandle open: &#39;file.txt&#39; mode: &#39;rb&#39;.<br>
&gt;&gt; stream := UTF8EncodingXTream on: BufferedXtream on: FileXtream on: file.<br>
&gt;<br>
&gt; For Filesystem, I&#39;ve been working on something like this:<br>
&gt;<br>
&gt; stream := aReference writeStream<br>
&gt;        encoding: #utf8;<br>
&gt;        buffer: 1024;<br>
&gt;        yourself<br>
&gt;<br>
&gt; The stream is responsible for managing the pipeline between its self and the<br>
&gt; handle.<br>
&gt;<br>
&gt; If Nicolas is writing a separate Xtreams package, though, it&#39;s going to<br>
&gt; overlap a lot with Filesystem. Perhaps I should just depend on Xtreams,<br>
&gt; rather than duplicate the functionality.<br>
&gt;<br>
&gt; Colin<br>
&gt;<br>
&gt;<br>
<br>
</div></div>Xtream is not functional yet, it is just a three evenings shot.<br>
Especially pipelines are quite tricky with a forked process... I got<br>
to rest a bit and think.<br>
This kind of implementation natively has good parallelism properties,<br>
unfortunately this won&#39;t exploit multi-core/processors any time soon<br>
in Smalltalk...<br>
A few month ago, I implemented a simple Wrapper-like scheme, but was<br>
not satisfied with end of stream handling. Both EndOfStream exception<br>
capture and atEnd tests are expensive when processing elements 1 by 1.<br>
Maybe I&#39;ll have to turn to such a more simple scheme though.<br>
Definitely, we should exchange code/ideas.<br></blockquote><div><br></div><div>The scheme that works is to use an endOfStreamValue which can take a value (e.g. the stream itself) that causes EndOfStream to be raised when at end of stream.  e.g.</div>
<div><br></div><div>pastEnd</div><div>    ^endOfStreamValue == self</div><div>        ifTrue: [(EndOfStream for: self) signal]</div><div>        ifFalse: [endOfStreamValue]</div><div><br></div><div>Then the only argument is over what the default should be.  Providing convenience methods on the class side can take the pain out of that.</div>
<div><br></div><div>N.B.  The EndOfStream exception has no inst var or accessor for the stream on which it is raised.  This is a bug :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<font color="#888888"><br>
Nicolas<br>
<br>
</font></blockquote></div><br>