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

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Nov 12 21:03:36 EST 2013


Thanks nicolas for checking that.

Stef


> So the latest ConfigurationOfXtreams found either in http://www.squeaksource.org/Xtreams or http://www.squeaksource.org/MetacelloRepository more or less load in Pharo3.0...
> More or less means that it still tries to load FFI which fails to compile...
> And I don't know why it loads, and i don't know why it fails...
> FFI is required only by Xtreams-Xtra which is not (or should not be) in the 'default' group for #'pharo3.x'
> It's not very important, because most of the Xtreams packages are already loaded when the failure occurs.
> 
> When i check with this, it does not tell me that it will load FFI (maybe because I have a version loaded?):
> ConfigurationOfXtreams project latestVersion fetch loadDirective.
> 
> But when I load with this, it tries to compile FFI again:
> ConfigurationOfXtreams project latestVersion load.
> 
> 
> 2013/11/13 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> 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/9515a2a9/attachment-0002.html>


More information about the Pharo-dev mailing list