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.n...@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.shea...@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.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 >> >>> > >> >>> > >> >>> >> >>> >> >> >> > >> >> >
