Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)
pay attention that there are two xtreams package frameworks from what I understand one presented at esug and one developed by nicolas Stef On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, every time I must warn and apologize because I'm guilty of hijacking the name. The goals are more or less the same, because I also hijacked some ideas (though not all invented at VW): - separate read/write stream - use stream wrappers - implement main sequenceable collection API (more to be found at http://www.squeaksource.com/XTream.html wiki page) There are also Squeak specific goals: - clean the mess by first principles (just an excerpt http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141786.... ) - accelerate MultiByteFileStream At time Squeak Xtream started, there was no license for VW Xtream, so it's a full rewrite from scratch. Thus implementation differs. Mainly I did not reify the Buffer (the master piece of original VW Xtream). Due to this, I've got a BufferedReadWriteStream, which is contradictory to goal 1). It might change in future. I also do not want to depend too much on Exception handling, which current VW Buffer implementation does. Also, I did not replace the whole protocol, but rather reused existing one. That's because further goal is to provide a replacement for Squeak Streams (could apply to Pharo too, but there's a possible overlap with Nile* See note below). However, I currently made no plan to reach this goal. I just have some toy images that I break regularly due to lack of compatibility... Either I implement all the messy protocol that flourished in Squeak, or I try to stay a bit cleaner but with uncompatibilities... Maybe a separate compatibility package with a deprecation policy might help... Be aware that recent Squeak and Pharo acceleration thanks to buffering was first experimented in Squeak Xtream, and then ported by talents of Levente, that's already a little reward. Some big acceleration could be gained other UTF8 streams when a majority of characters are ASCII (the case of source code management and most latin characters texts), both in cog and traditional vm. My current tests (cog) are: { [| tmp | tmp := (MultiByteFileStream readOnlyFileNamed: (SourceFiles at: 2) name) ascii; wantsLineEndConversion: false; converter: UTF8TextConverter new. 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. [| tmp | tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) readXtream binary buffered ~> UTF8Decoder) buffered. 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. } #(163 21) So, Xtream is around 8x faster at reading first 20000 lines of change log... No surprise it's more than 99% pure ASCII. Last, concerning the errors, it's more a matter of fixing the tests themselves... They use #squeakToUtf8 as a reference, and some tests are for other unloaded XTream packages. I started to change the test last night but did not publish all... See also: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153578... http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141539.... http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141647.... and more mails in november/december 2009 more dated material http://bugs.squeak.org/view.php?id=6755 and various attempts like LazyStream/LazyCollections... Nicolas * Note about Nile: Nile has a different approach: do not eliminate ReadWriteStreams, but compose with traits. Nile also has high test coverage level, which is good. Nile was designed as a Stream replacement for Squeak Stream... As such, it carries some cruft (same dilemna as Squeak Xtream). Pharo goal is to perform major clean-up. As a mean to reach this goal, it shall not encumber with backward compatibility. This means that once Nile adopted (with historical compatibility cruft), it should be cleaned up again... 2010/10/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pay attention that there are two xtreams package frameworks from what I understand
    one presented at esug and one developed by nicolas
Stef
On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked  http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ 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
On 07 Oct 2010, at 21:41, Nicolas Cellier wrote:
Yes, every time I must warn and apologize because I'm guilty of hijacking the name.
[....] Thank you Nicolas, for the elaborate explanation (I should have checked the wiki on SS first myself). With your latest updates, everything loads and all tests are green in Pharo 1.1.1 Is this a correct summary then ? You started Squeak XTreams based on both ideas in VW Xtreams and your own, at a time when VW Xtreams was not MIT licensed (and maybe incomplete). Your goal was/is not API level compatibility with VW Xtreams. Squeak XTreams values backwards compatibilty/integration a bit more, speed is important as well. I haven't looked deep enough into Squeak Xtreams yet. Reading the high level descriptions (slides and website docs) of VW Xtreams I get this warm feeling of 'Yes, this is it, this all makes perfect sense, feels good'. But apart from some historical influences, the relation with Squeak Xtreams seems rather limited. Sven
2010/10/8 Sven Van Caekenberghe <sven@beta9.be>:
On 07 Oct 2010, at 21:41, Nicolas Cellier wrote:
Yes, every time I must warn and apologize because I'm guilty of hijacking the name.
[....]
Thank you Nicolas, for the elaborate explanation (I should have checked the wiki on SS first myself).
With your latest updates, everything loads and all tests are green in Pharo 1.1.1
Is this a correct summary then ?
You started Squeak XTreams based on both ideas in VW Xtreams and your own, at a time when VW Xtreams was not MIT licensed (and maybe incomplete). Your goal was/is not API level compatibility with VW Xtreams. Squeak XTreams values backwards compatibilty/integration a bit more, speed is important as well.
I haven't looked deep enough into Squeak Xtreams yet. Reading the high level descriptions (slides and website docs) of VW Xtreams I get this warm feeling of 'Yes, this is it, this all makes perfect sense, feels good'. But apart from some historical influences, the relation with Squeak Xtreams seems rather limited.
Yes that's a correct description of the past and present. The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge. Nicolas
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pay attention that there are two xtreams package frameworks from what I understand
    one presented at esug and one developed by nicolas
Stef
Now, I wonder if I should not rename it SqueaXtream or something - apologize for not being Pharo-tically correct ;) Nicolas
On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked  http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ 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
Nicolas, the design of your version lacks composability. Also, i seriously think that read and write streams should not be married under same class. This could be a paradigm shift for many people, but not for me, since i dealt with real-time network communications in the past and can say that network communication based on bidirectional data flow really sucks, because it doesn't scale.. and don't works for more than 2 peers :) By its nature, data flow is unidirectional. Trying to unify things and present it as a bidirectional leads to bad code, bad usage patterns (see RemoteString) and endless discussions around 'do we need a multiple inheritance or not'. If i want to read from stream, i can do it like following: file := 'foo.txt' asFile. reader := file readXStream. reader next if i want to write something, i do writer := file writeXStream. writer nextPut: $x. and if i need to read & write both, then i probably should tell writer and reader to share same state, like file handle, cache, buffers etc, but not to be the same object. so, if i need to write, i should use writer, and if i need to read - i should use reader.. Concerning composability, this is a cornerstone of VW XTreams implementation. And after watching their presentation at ESUG, i can say that your implementation completely miss the point (sorry). Seeing how simple i can build complex parser(s) by composing multiple low-level parsers in PetitParser, nobody can convince me, that its a bad idea for streams. Why i can't simply do: reader := 'aaa.txt' asFile readXStream. utf8Reader := UTF8Reader on: reader. ? On 8 October 2010 00:51, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pay attention that there are two xtreams package frameworks from what I understand
    one presented at esug and one developed by nicolas
Stef
Now, I wonder if I should not rename it SqueaXtream or something - apologize for not being Pharo-tically correct ;)
Nicolas
On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked  http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ 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
_______________________________________________ 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.
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
Nicolas, the design of your version lacks composability. Also, i seriously think that read and write streams should not be married under same class. This could be a paradigm shift for many people, but not for me, since i dealt with real-time network communications in the past and can say that network communication based on bidirectional data flow really sucks, because it doesn't scale.. and don't works for more than 2 peers :)
I don't see what is not composable. Squeak Xtream is made exclusively of Xtream wrappers, except some terminal CollectionReadXtream and future IOHandleReadXtream (not yet existing see below). Track how the source/destination ivar are defined/used : most exclusively of other Xtreams. Also check the messages ~> and <~ for composition. I started using Stream wrappers in the 90s for my own applications, that's not a new idea.
By its nature, data flow is unidirectional. Trying to unify things and present it as a bidirectional leads to bad code, bad usage patterns (see RemoteString) and endless discussions around 'do we need a multiple inheritance or not'.
Agree. I have mostly separated ReadXtream and WriteXtream with one exception, the so called BufferedReadWriteXtream. This class was a quick hack and is not satisfying me. In Squeak, there is one major user of ReadWriteStream: the change log, so I needed this quick hack. We can for sure decompose it in two streams, one for read, one for write, code will be a lot cleaner. But beware, the two streams will have to share a common state, and implementation is not straightforward. If you look at VW implementation, you will see this kind of object is a (shared) Buffer and the implementation is quite involved... But if you want to help with this one, you're welcome.
If i want to read from stream, i can do it like following:
file := 'foo.txt' asFile.
reader := file readXStream. reader next
if i want to write something, i do
writer := file writeXStream. writer nextPut: $x.
and if i need to read & write both, then i probably should tell writer and reader to share same state, like file handle, cache, buffers etc, but not to be the same object. so, if i need to write, i should use writer, and if i need to read - i should use reader..
Concerning composability, this is a cornerstone of VW XTreams implementation. And after watching their presentation at ESUG, i can say that your implementation completely miss the point (sorry). Seeing how simple i can build complex parser(s) by composing multiple low-level parsers in PetitParser, nobody can convince me, that its a bad idea for streams.
Why i can't simply do:
reader := 'aaa.txt' asFile readXStream. utf8Reader := UTF8Reader on: reader. ?
1) asFile does not exist yet because I thought it would be much better to conect to FileSystem http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar rather than doing yet another one... 2) in the meantime, use an old StandardFileStream (yes I know, not sexy) 3) compose with message <~ for write and ~> for read By now your example shall be translated as (StandardFileStream readOnlyFileNamed: 'aaa.txt') readXtream buffered ~> UTF8Decoder. Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply 'aaa.txt' asFile readXtream gunzip utf8. Instead of #on:, I implemented #onStream: for readXtream wrappers and #toStream: for writeXtream wrappers. I concede current implementation is weak because those two messages are duplicated... But it's just a matter of gathering the transformers under a generic subclass as you proposed in Xtream-Wrappers Hope it helps, or maybe there are really neat things I missed ? VW Xtream is really a master piece, reach features, certainly many hours of development. Squeak Xtream is a few hours proof of concept. I invite you and every one interested to complete the work. Beside, VW Xtream is now MIT, so it's easy to pick any code and unify if there's a will in this community. Nicolas
On 8 October 2010 00:51, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pay attention that there are two xtreams package frameworks from what I understand
    one presented at esug and one developed by nicolas
Stef
Now, I wonder if I should not rename it SqueaXtream or something - apologize for not being Pharo-tically correct ;)
Nicolas
On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked  http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ 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
_______________________________________________ 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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/10/8 Igor Stasenko <siguctua@gmail.com>: snip...
Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply
'aaa.txt' asFile readXtream gunzip utf8.
Oops I forgot the .gz extension: 'aaa.txt.gz' asFile readXtream gunzip utf8. Nicolas
2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/10/8 Igor Stasenko <siguctua@gmail.com>: snip...
Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply
'aaa.txt' asFile readXtream gunzip utf8.
Oops I forgot the .gz extension:
'aaa.txt.gz' asFile readXtream gunzip utf8.
Nicolas
Oh, and VW features are more rich than reach... Time to sleep. Bye
On 8 October 2010 03:14, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
Nicolas, the design of your version lacks composability. Also, i seriously think that read and write streams should not be married under same class. This could be a paradigm shift for many people, but not for me, since i dealt with real-time network communications in the past and can say that network communication based on bidirectional data flow really sucks, because it doesn't scale.. and don't works for more than 2 peers :)
I don't see what is not composable. Squeak Xtream is made exclusively of Xtream wrappers, except some terminal CollectionReadXtream and future IOHandleReadXtream (not yet existing see below). Track how the source/destination ivar are defined/used : most exclusively of other Xtreams. Also check the messages ~> and <~ for composition.
I started using Stream wrappers in the 90s for my own applications, that's not a new idea.
By its nature, data flow is unidirectional. Trying to unify things and present it as a bidirectional leads to bad code, bad usage patterns (see RemoteString) and endless discussions around 'do we need a multiple inheritance or not'.
Agree. I have mostly separated ReadXtream and WriteXtream with one exception, the so called BufferedReadWriteXtream. This class was a quick hack and is not satisfying me. In Squeak, there is one major user of ReadWriteStream: the change log, so I needed this quick hack. We can for sure decompose it in two streams, one for read, one for write, code will be a lot cleaner. But beware, the two streams will have to share a common state, and implementation is not straightforward.
If you look at VW implementation, you will see this kind of object is a (shared) Buffer and the implementation is quite involved... But if you want to help with this one, you're welcome.
If i want to read from stream, i can do it like following:
file := 'foo.txt' asFile.
reader := file readXStream. reader next
if i want to write something, i do
writer := file writeXStream. writer nextPut: $x.
and if i need to read & write both, then i probably should tell writer and reader to share same state, like file handle, cache, buffers etc, but not to be the same object. so, if i need to write, i should use writer, and if i need to read - i should use reader..
Concerning composability, this is a cornerstone of VW XTreams implementation. And after watching their presentation at ESUG, i can say that your implementation completely miss the point (sorry). Seeing how simple i can build complex parser(s) by composing multiple low-level parsers in PetitParser, nobody can convince me, that its a bad idea for streams.
Why i can't simply do:
reader := 'aaa.txt' asFile readXStream. utf8Reader := UTF8Reader on: reader. ?
1) asFile does not exist yet because I thought it would be much better to conect to FileSystem http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar rather than doing yet another one...
it was rather a meta-message, indicating potential intent rather than existing code :)
2) in the meantime, use an old StandardFileStream (yes I know, not sexy) 3) compose with message <~ for write and ~> for read
By now your example shall be translated as
(StandardFileStream readOnlyFileNamed: Â 'aaa.txt') readXtream buffered ~> UTF8Decoder.
Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply
'aaa.txt' asFile readXtream gunzip utf8.
Instead of #on:, I implemented #onStream: Â for readXtream wrappers and #toStream: for writeXtream wrappers. I concede current implementation is weak because those two messages are duplicated... But it's just a matter of gathering the transformers under a generic subclass as you proposed in Xtream-Wrappers
Hope it helps, or maybe there are really neat things I missed ?
I don't know if there are slides available for XTreams@EGUG talk, but it could give good insights about XTreams design and usage. What i saw there, that it was quite easy to compose streams, without ad-hoc and elaborate messages. But it was so much happening on ESUG, that i don't remember concrete details :)
VW Xtream is really a master piece, reach features, certainly many hours of development. Squeak Xtream is a few hours proof of concept. I invite you and every one interested to complete the work. Beside, VW Xtream is now MIT, so it's easy to pick any code and unify if there's a will in this community.
Yes, this is i think would be better to do, so we can share same protocol(s) and behavior among multiple dialects.
Nicolas
On 8 October 2010 00:51, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pay attention that there are two xtreams package frameworks from what I understand
    one presented at esug and one developed by nicolas
Stef
Now, I wonder if I should not rename it SqueaXtream or something - apologize for not being Pharo-tically correct ;)
Nicolas
On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote:
On 06 Oct 2010, at 08:48, Nicolas Cellier wrote:
See also hijacked  http://www.squeaksource.com/XTream.html borrowing some of the ideas, but somehow less extreme. Most packages should now load in Pharo.
Hi Nicolas,
I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much.
Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now.
Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ?
Thx,
Sven
_______________________________________________ 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
_______________________________________________ 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.
_______________________________________________ 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.
I recalled one detail: VW Xtreams are composable from the beginning, its a core stream feature. Not like ours, which require wrappers, which i added (and thus a lot of clutter on proxying message sends). :) -- Best regards, Igor Stasenko AKA sig.
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
I recalled one detail:
VW Xtreams are composable from the beginning, its a core stream feature. Not like ours, which require wrappers, which i added (and thus a lot of clutter on proxying message sends).
:)
I still fail to see the difference. Squeak_XTream are composable from the beginning, ReadXtream all have a source, WriteXtream all have a destination, and most of the subclasses fill those ivars with another XTream. VW_XTream.ReadStream>> on: aSource source := aSource Squeak_Xtream.ReadXtream>>source: anObject "Set the source of this stream" source := anObject Or is it just a question of naming ? I adopted #source:, simply because #on: is harder to trace (too many implementors). Maybe the difference is just a convenient wrapping message or two missing in Squeak_XTream. The wrapper class you added are indeed unecessary in both Squeak_XTream and VW_Xtream. I should have given more feedback to you. If you want to look at differences between the two implementation, rather look at VW_Xtream.Buffer and subclasses. Also look at use of Exception handling in VW_Xtream (users of Incomplete). Don't look number of classes & methods, I obviously don't scale ;) Having only nights and week-ends left for programming, I just don't want to compete ;) Nicolas
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 8 October 2010 23:13, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
I recalled one detail:
VW Xtreams are composable from the beginning, its a core stream feature. Not like ours, which require wrappers, which i added (and thus a lot of clutter on proxying message sends).
:)
I still fail to see the difference. Squeak_XTream are composable from the beginning, ReadXtream all have a source, WriteXtream all have a destination, and most of the subclasses fill those ivars with another XTream.
VW_XTream.ReadStream>> on: aSource   source := aSource
Squeak_Xtream.ReadXtream>>source: anObject   "Set the source of this stream"
  source := anObject
Or is it just a question of naming ? I adopted #source:, simply because #on: is harder to trace (too many implementors). Maybe the difference is just a convenient wrapping message or two missing in Squeak_XTream.
The wrapper class you added are indeed unecessary in both Squeak_XTream and VW_Xtream. I should have given more feedback to you.
If you want to look at differences between the two implementation, rather look at VW_Xtream.Buffer and subclasses. Also look at use of Exception handling in VW_Xtream (users of Incomplete). Don't look number of classes & methods, I obviously don't scale ;) Having only nights and week-ends left for programming, I just don't want to compete ;)
One of ideas, i like in VW Xtreams is an ease of creating transforming streams: "hex encoding: #[0 1 2 ... 255] -> '000102...FF' " bytes := ByteArray withAll: (0 to: 255). digits := '0123456789ABCDEF'. byte2hex := [ :in :out || byte | byte := in get. out put: (digits at: (byte bitShift: -4) + 1). out put: (digits at: (byte bitAnd: 15) + 1) ]. (bytes reading transforming: byte2hex) contentsSpecies: String; rest here bytes reading, answers a reader xtream then by sending #transforming: aBlock you wrap this stream with transforming stream, which using a block for transformations. note, that block takes in and out arguments, which are streams instead of taking a single argument, like a next element read from source stream. In this way you can control transformation in any way you like: - read N elements from source and produce M elements as output. This is very powerful. Simplest example , which comes in mind is our beloved UTF8 reader - it may read 1, 2, 3 or 4 bytes from source to produce 1 character at output. What i like in it, that you don't need to create a separate class for each kind of transformation, since you can simply construct it on the fly using blocks, like: Xtream>>decodeUTF8 ^ self transforming: [:in :out | byte := in get. .... (utf 8 decoding logic ) out put: result ]
Nicolas
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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.
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
On 8 October 2010 23:13, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/8 Igor Stasenko <siguctua@gmail.com>:
I recalled one detail:
VW Xtreams are composable from the beginning, its a core stream feature. Not like ours, which require wrappers, which i added (and thus a lot of clutter on proxying message sends).
:)
I still fail to see the difference. Squeak_XTream are composable from the beginning, ReadXtream all have a source, WriteXtream all have a destination, and most of the subclasses fill those ivars with another XTream.
VW_XTream.ReadStream>> on: aSource   source := aSource
Squeak_Xtream.ReadXtream>>source: anObject   "Set the source of this stream"
  source := anObject
Or is it just a question of naming ? I adopted #source:, simply because #on: is harder to trace (too many implementors). Maybe the difference is just a convenient wrapping message or two missing in Squeak_XTream.
The wrapper class you added are indeed unecessary in both Squeak_XTream and VW_Xtream. I should have given more feedback to you.
If you want to look at differences between the two implementation, rather look at VW_Xtream.Buffer and subclasses. Also look at use of Exception handling in VW_Xtream (users of Incomplete). Don't look number of classes & methods, I obviously don't scale ;) Having only nights and week-ends left for programming, I just don't want to compete ;)
One of ideas, i like in VW Xtreams is an ease of creating transforming streams:
    "hex encoding: #[0 1 2 ... 255] -> '000102...FF' "     bytes := ByteArray withAll: (0 to: 255).     digits := '0123456789ABCDEF'.     byte2hex := [ :in :out || byte |         byte := in get.         out put: (digits at: (byte bitShift: -4) + 1).         out put: (digits at: (byte bitAnd: 15) + 1) ].     (bytes reading transforming: byte2hex)         contentsSpecies: String;         rest
here bytes reading, answers a reader xtream then by sending #transforming: aBlock you wrap this stream with transforming stream, which using a block for transformations. note, that block takes in and out arguments, which are streams instead of taking a single argument, like a next element read from source stream. In this way you can control transformation in any way you like: - read N elements from source and produce M elements as output.
This is very powerful. Simplest example , which comes in mind is our beloved UTF8 reader - it may read 1, 2, 3 or 4 bytes from source to produce 1 character at output.
What i like in it, that you don't need to create a separate class for each kind of transformation, since you can simply construct it on the fly using blocks, like:
Xtream>>decodeUTF8 Â ^ self transforming: [:in :out | Â byte := Â in get. Â .... (utf 8 decoding logic ) Â out put: result ]
Yes, this is a very nice generalization indeed. The Squeak_XTream-Parallel package has a totally screwed implementation of it. It's less simple than it sounds ;) Nicolas
Nicolas
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe