[Pharo-project] Streams. Status and where to go?

Igor Stasenko siguctua at gmail.com
Fri Feb 26 10:14:47 EST 2010

Hello, Nicolas.
I want to try it out.
I tried to load it (XTream-Core) into my image, and it bug me about
unresolved dependencies:
This package depends on the following classes:
You must resolve these dependencies before you will be able to load
these definitions:
I ignored these warnings, pressing continue, and here what it warns
about in my trunk image:

TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared)
TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared)
TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared)

Is ByteTextConverter a Pharo-specific class?

If you seen my previous message, i think you noticed that
XXXTextConverter is abdominations (IMO), and should be reimplemented
as a wrapping-streams instead.
Would you be willing to change that in XStreams? I mean implementing a
conversion streams model, which can wrap around any other stream,

myStream := UTFReaderStream on: otherStream.
myString := myStream contents.

or using other way:

myString := (someBaseStream wrapWith: UTFReaderStream) contents.

myDecodedString := (someBaseStream wrapWith: (DecodingStreams
decoderFor: myEncoding) contents.

That's would be much nicer than using converters.

Wrappers is more flexible comparing to TextConverters, since they are
not obliged to convert to/from text-based collections only.
For example, we can use same API for wrapping with ZIP stream:

myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) contents.

and many other (ab)uses.. Like reading changeset chunks:

nextChunk := (fileStream wrapWith: ChunkReaderStream) next.

On 25 February 2010 21:19, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/2/25 Igor Stasenko <siguctua at gmail.com>:
>> Hello,
>> i am cross-posting, since i think it is good for all of us to agree on
>> some common points.
>> 1. Streams needs to be rewritten.
>> 2. What do you think is good replacement for current Streams?
>> personally, i currently need a fast and concise UTF8 reader.
>> The UTF8TextConverter is closest thing what i would take, but i don't
>> understand, why
>> it implemented as a non-stream?
>> The #nextFromStream:
>> and #nextPut:toStream:
>> crying out of loud to be just
>> #next
>> and
>> #nextPut:
>> Another thing which makes me sad is this line:
>> nextFromStream: aStream
>>        | character1 value1 character2 value2 unicode character3 value3
>> character4 value4 |
>>        aStream isBinary ifTrue: [^ aStream basicNext].   <<<<<<<
>> All external streams is initially binary , but UTF8TextConverter wants
>> to play with characters, instead of octets..
>> But hey... UTF8 encoding is exactly about encoding unicode characters
>> into binary form..
>> I'm not even mentioning that operating with bytes (smallints) is times
>> more efficient than operating with characters (objects), because first
>> thing it does:
>>        character1 := aStream basicNext.  " a #basicNext, obviously, reads a
>> byte from somewhere and then converts it to instance of Character.
>> 'Bonus' overhead here. "
>>        character1 isNil ifTrue: [^ nil].
>>        value1 := character1 asciiValue.  " and... what a surprise, we
>> converting a character back to integer value.. What a waste! "
>>        value1 <= 127 ifTrue: [
>> I really hope, that eventually we could have a good implementation,
>> where horse runs ahead of cart, not cart ahead of horse :)
>> Meanwhile i think i have no choice but make yet-another implementation
>> of utf8 reader in my own package, instead of using existing one.
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
> Obviously right. encoded in bytes, decoded in Characters.
> There are also ideas experimented at http://www.squeaksource.com/XTream.html
> Sorry I hijacked VW name...
> You can download it, it coexist pacificly with Stream.
> - use endOfStreamAction instead of Exception... That means abandonning
> primitives next nextPut: (no real performance impact, and expect a
> boost in future COG).
> - separate CollectionReadStream=concrete class, ReadStream=abstract class
> - use a wrapper rather than a subclass for MultiByteFileStream
> - implement sequenceable collection API
> - buffer I/O (mostly in Squeak thanks Levente)
> Of course, alternate ideas to pick from Nile, VW XTream, gst generators etc...
> I think mutating existing library is doable (just a bit tricky because
> both Compiler and source code management use Stream extensively...).
> Nicolas
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Best regards,
Igor Stasenko AKA sig.

More information about the Pharo-dev mailing list