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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Nov 12 16:23:58 EST 2013


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
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131112/94dede2b/attachment-0002.html>


More information about the Pharo-dev mailing list