Xtreams vs become:
Locked
 
|
Michael and I talked about this today a bit and here's what we're thinking about doing.
We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: testBlah self write: [ :output | .... ] read: [ :input | ... ] Good enough ? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/10/13 <[hidden email]>:
> Michael and I talked about this today a bit and here's what we're thinking about doing. > We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. > > At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. > > To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: > > testBlah > > self write: [ :output | .... ] > read: [ :input | ... ] > > Good enough ? > Seems fair to me. Nicolas > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Or maybe I have something simple enough :
1) let setUp initialize the output but not the input 2) access input via a message send and lazy initialization For example, in collection tests, this would be input ^input ifNil:[input := output conclusion reading] in file tests: ^input ifNil:[input := file reading] What do you think ? Nicolas 2010/10/13 Nicolas Cellier <[hidden email]>: > 2010/10/13 <[hidden email]>: >> Michael and I talked about this today a bit and here's what we're thinking about doing. >> We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. >> >> At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. >> >> To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: >> >> testBlah >> >> self write: [ :output | .... ] >> read: [ :input | ... ] >> >> Good enough ? >> > > Seems fair to me. > > Nicolas > >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I've tested this strategy, and it works well:
- use accessors self input/self output instead of inst. var. - lazily initialize the input for Collection and File In collection tests, I have used ^input ifNil:[input := outer terminal reading] where: outer := output := collection writing. This is because some Block transforms can't access the terminal collection... I have a bug with File though - it looks like double closing. The symptoms are that no file can't be further opened untill we quit the image... Nicolas 2010/10/15 Nicolas Cellier <[hidden email]>: > Or maybe I have something simple enough : > > 1) let setUp initialize the output but not the input > 2) access input via a message send and lazy initialization > For example, in collection tests, this would be > input > ^input ifNil:[input := output conclusion reading] > in file tests: > ^input ifNil:[input := file reading] > > What do you think ? > > Nicolas > > 2010/10/13 Nicolas Cellier <[hidden email]>: >> 2010/10/13 <[hidden email]>: >>> Michael and I talked about this today a bit and here's what we're thinking about doing. >>> We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. >>> >>> At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. >>> >>> To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: >>> >>> testBlah >>> >>> self write: [ :output | .... ] >>> read: [ :input | ... ] >>> >>> Good enough ? >>> >> >> Seems fair to me. >> >> Nicolas >> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by mkobetic
"Nicolas Cellier"<[hidden email]> wrote:
> I've tested this strategy, and it works well: > > - use accessors self input/self output instead of inst. var. > - lazily initialize the input for Collection and File Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > In collection tests, I have used > ^input ifNil:[input := outer terminal reading] > where: outer := output := collection writing. > This is because some Block transforms can't access the terminal collection... Not sure what you mean, but it will probably get clearer when I go do it. BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/10/15 <[hidden email]>:
> "Nicolas Cellier"<[hidden email]> wrote: >> I've tested this strategy, and it works well: >> >> - use accessors self input/self output instead of inst. var. >> - lazily initialize the input for Collection and File > > Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > The tests interleaving read/write are #testWriteFromCollectionAt #testWriteFromStream #testWriteTransformHexToByte #testReadWriteLargeAmount Then #testGetPastEnd also relies on become: on close... If we change the grown policy: destination := destination grownBy: (destination size max: 10) instead of: destination := destination grownBy: (destination size max: 1) then the test does not pass. This also is because I used: input := outer terminal reading rather than: input := outer conclusion reading >> In collection tests, I have used >> ^input ifNil:[input := outer terminal reading] >> where: outer := output := collection writing. >> This is because some Block transforms can't access the terminal collection... > > Not sure what you mean, but it will probably get clearer when I go do it. > BlockWriteStream terminal answers a block... But yes, it will be clearer when debugging it. > BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. > > Martin > Nice. Squeak lack package comment.... :( Nicolas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |