On 8 October 2010 03:14, Nicolas Cellier <[email protected]> wrote: > 2010/10/8 Igor Stasenko <[email protected]>: >> 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 xtre...@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 >> <[email protected]> wrote: >>> 2010/10/7 Stéphane Ducasse <[email protected]>: >>>> 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 >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
