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: ByteTextConverter You must resolve these dependencies before you will be able to load these definitions: ByteTextConverter>>nextFromXtream: ByteTextConverter>>nextPut:toXtream: ByteTextConverter>>readInto:startingAt:count:fromXtream: ---- 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, like: myStream := UTFReaderStream on: otherStream. myString := myStream contents. or using other way: myString := (someBaseStream wrapWith: UTFReaderStream) contents. or.. 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@gmail.com> wrote:
2010/2/25 Igor Stasenko <siguctua@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.