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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Nov 12 18:25:40 EST 2013


In original VW works, there is no FileDirectory nor FileReference nor
FileSystem nor...
So Xtreams-Terminals was thought as a dialect specific package...
Of course, these terminals are still 95% compatible between Squeak4.x and
Pharo3.x, so we can make a better packaging.

Before deciding what is a good package delimitation, and what's not, I
wanted to experiment a bit without compatibility constraints.
So I created a .Pharo3 branch in Terminals and TerminalsTests.
There's a little more than FileDirectory references: I also used the
FileHandle class provided by FileSystem package, rather than
Xtreams-Support XTIOFileHandle.

Anyway, the Squeak/Pharo version is way behind the visualworks version, so
yes, there is definitely some work needed.
Up to now, I diffed the versions in VW and manually ported to Squeak.
The good thing is that I can try to learn and understand the changes.
It is also mandatory to cop with the small differences (some VW method
might be absent in Squeak/Pharo and require a Xtreams-Support counterpart,
the classes need a XT prefix, ...).
The bad things are that
- there are many versions to integrate, and the history is not linear;
- I have only ten fingers, two eyes, and a single brain, the whole comes
with very limited multitasking capabilities.
There must be a better way, like trying to automate the port of shared
implementations, and review only the dialect-specific parts.
Or just put more brains, finger and eyes in the loop...


2013/11/12 Frank Shearar <frank.shearar at gmail.com>

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


More information about the Pharo-dev mailing list