[Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)
siguctua at gmail.com
Fri Oct 8 09:57:41 EDT 2010
On 8 October 2010 03:14, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/10/8 Igor Stasenko <siguctua at gmail.com>:
>> 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'.
> 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 at 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.
>> On 8 October 2010 00:51, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> 2010/10/7 Stéphane Ducasse <stephane.ducasse at inria.fr>:
>>>> pay attention that there are two xtreams package frameworks from what I understand
>>>> one presented at esug and one developed by nicolas
>>> Now, I wonder if I should not rename it SqueaXtream or something -
>>> apologize for not being Pharo-tically correct ;)
>>>> 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 ?
>>>>> Pharo-project mailing list
>>>>> Pharo-project at lists.gforge.inria.fr
>>>> Pharo-project mailing list
>>>> Pharo-project at lists.gforge.inria.fr
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Best regards,
>> Igor Stasenko AKA sig.
>> 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