On Wed, Dec 2, 2009 at 8:26 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2009/12/2 Colin Putney <cputney at wiresong.ca>:
> >
> > On 1-Dec-09, at 9:55 PM, Andreas Raab wrote:
> >
> >>
> >> file := FileHandle open: 'file.txt' mode: 'rb'.
> >> stream := UTF8EncodingXTream on: BufferedXtream on: FileXtream on: file.
> >
> > For Filesystem, I've been working on something like this:
> >
> > stream := aReference writeStream
> >        encoding: #utf8;
> >        buffer: 1024;
> >        yourself
> >
> > The stream is responsible for managing the pipeline between its self and
> the
> > handle.
> >
> > If Nicolas is writing a separate Xtreams package, though, it's going to
> > overlap a lot with Filesystem. Perhaps I should just depend on Xtreams,
> > rather than duplicate the functionality.
> >
> > Colin
> >
> >
>
> Xtream is not functional yet, it is just a three evenings shot.
> Especially pipelines are quite tricky with a forked process... I got
> to rest a bit and think.
> This kind of implementation natively has good parallelism properties,
> unfortunately this won't exploit multi-core/processors any time soon
> in Smalltalk...
> A few month ago, I implemented a simple Wrapper-like scheme, but was
> not satisfied with end of stream handling. Both EndOfStream exception
> capture and atEnd tests are expensive when processing elements 1 by 1.
> Maybe I'll have to turn to such a more simple scheme though.
> Definitely, we should exchange code/ideas.
>

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.

pastEnd
    ^endOfStreamValue == self
        ifTrue: [(EndOfStream for: self) signal]
        ifFalse: [endOfStreamValue]

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.

N.B.  The EndOfStream exception has no inst var or accessor for the stream
on which it is raised.  This is a bug :)

>
> Nicolas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091202/ebd2daa3/attachment.htm