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