[Pharo-dev] In-memory FileSystem write streams not being polymorphic

Frank Shearar frank.shearar at gmail.com
Tue Nov 12 17:52:18 EST 2013


Yep, they do. build.squeak.org uses this repo. See also
https://code.google.com/p/xtreams/issues/detail?id=2

About time for us to pick up this work?

frank

On 12 November 2013 21:29, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> And the tests pass, except the file tests which are based on creating a
> stream thru (FileDirectory default / ...)
>
>
> 2013/11/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>>
>> Hi Sven,
>> The last Squeak/Pharo locations I am aware of are:
>> - http://www.squeaksource.org/Xtreams for the Xtreams package
>> - http://www.squeaksource.org/MetacelloRepository for
>> ConfigurationOfXtreams (but I just copied the last Config to above repo)
>> A very important repository for resources of all kind from the original
>> authors is https://code.google.com/p/xtreams/
>>
>> Those versions above do not load in Pharo3.0 due to several problems
>> - FileDirectory deprecation (there is an extension method that should be
>> removed in Pharo branch)
>> - Xtras package of Xtreams depends on FFI, and FFI does not load cleanly
>> in Pharo (at least the one found from the ConfigurationOfXtreams) because
>> ShortRunArray is not found...
>>
>> I will try and publish a Pharo branch, but before I do so, is anyone aware
>> of more recent work, or repository?
>>
>>
>>
>>
>> 2013/11/12 Sven Van Caekenberghe <sven at stfx.eu>
>>>
>>> Nicolas,
>>>
>>> Is it currently possible to load some latest version of Xtream into Pharo
>>> 3.0 ?
>>>
>>> If yes, from which repository using which Configuration ?
>>>
>>> I know that at ESUG 2012, Sean and Martin worked a bit on getting all
>>> different versions better in sync.
>>>
>>> It would be cool if we could at least load it, separate from the
>>> transition strategy (I agree with your proposal BTW), because many people do
>>> not know or have not seen what we are actually talking about.
>>>
>>> The clean, start from scratch approach of Xtreams also includes a much
>>> tighter and semantically better defined API. IMHO, a consequence is that
>>> #get / #next and #put: / #nextPut: are not just plain aliases (a modern use
>>> of exception handling is one big difference). The compatibility layer might
>>> be more of a challenge.
>>>
>>> The biggest gain is of course if clients switch to the newer API ;-)
>>>
>>> Sven
>>>
>>> On 12 Nov 2013, at 14:31, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> > It's just a matter of selecting a strategy. I've proposed two:
>>> > A) create a wrapper class for legacy Stream compatibility selectors
>>> > B) create extensions for Legacy Stream compatibility selectors
>>> > My preference goes to A)
>>> >
>>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
>>> > upTo: ...), otherwise we will import all the cruft in Xtream and would go
>>> > back to our starting point...
>>> > Once the minimal support written (a few hours should be enough), we
>>> > should gradually switch each every legacy Stream usage -> Xtream.
>>> >
>>> > An area which require more work is those Streams that have mixed
>>> > conventions (one portion is interpreted as text, another as binary).
>>> > In theory that's easy, we just have two streams and they both wrap on a
>>> > low level binary stream, but that means we have to be very cautious with
>>> > buffers and caches.
>>> >
>>> > Another area of work is usage of ugly selectors like name (we try to
>>> > access the file name from the Stream API, arghh). Those usages are bad and
>>> > require a rewrite.
>>> >
>>> >
>>> > 2013/11/12 Stéphane Ducasse <stephane.ducasse at inria.fr>
>>> >
>>> >>
>>> >> or of course, you start looking at porting XStreams to pharo ;), which
>>> >> on the long run will
>>> >> solve many more problems. The current situation is not that
>>> >> satisfactory
>>> >
>>> > having experience with it and thinking about a plan for the beginning
>>> > of 40 would be great.
>>> > I know that nicolas ported XTream to pharo/squeak. Now understanding
>>> > how integrate it would be nice.
>>> > Stef
>>> >
>>> >
>>>
>>>
>>
>




More information about the Pharo-dev mailing list