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.n...@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.n...@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 <s...@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.n...@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.duca...@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 >>> > >>> > >>> >>> >> >
