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.nice@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.shearar@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.nice@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.nice@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 <sven@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.nice@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.ducasse@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