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 >> > >> > >> >> >> >
