It's not very important, because most of the Xtreams packages are already loaded when the failure occurs.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...FFI is required only by Xtreams-Xtra which is not (or should not be) in the 'default' group for #'pharo3.x'
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...
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...There's a little more than FileDirectory references: I also used the FileHandle class provided by FileSystem package, rather than Xtreams-Support XTIOFileHandle.
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.
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
>>> >
>>> >
>>>
>>>
>>
>