[Pharo-project] Streams. Status and where to go?
siguctua at gmail.com
Fri Feb 26 10:14:47 EST 2010
I want to try it out.
I tried to load it (XTream-Core) into my image, and it bug me about
This package depends on the following classes:
You must resolve these dependencies before you will be able to load
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>:
>> 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
>> 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...).
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev