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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > > > >> > >> 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 > > > > > > >
