2013/2/26 H. Hirzel <hannes.hirzel at gmail.com>:
> For the load script for Xtreams in the list archive, which Frank
> mentions, there is one here
>
>     http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165822.html
>
> But it refers to a copy Colin Putney keeps at his wiresong site.
>
> --Hannes
>

I don't have time to try, but do you mean that various snippets found
on http://www.squeaksource.com/Xtreams.html are failing?
Or is it just the part requiring FFI?

Nicolas


> On 2/25/13, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2013/2/26 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> 2013/2/25 Colin Putney <colin at wiresong.com>:
>>>>
>>>>
>>>>
>>>> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <frank.shearar at gmail.com>
>>>> wrote:
>>>>
>>>>> When I need streams, I only use Xtreams.
>>>>>
>>>>> (Yes, it is maintained, but it doesn't actually require much
>>>>> maintenance.)
>>>>
>>>>
>>>> +1.
>>>>
>>>> Xtreams is great.
>>>>
>>>
>>> Yes, great, maintainable and maintained.
>>> Compatible? it depends compatible with what...
>>> It is a quite stable cross-platform library, so yes it is compatible
>>> with other dialects.
>>> Let me remind this link http://code.google.com/p/xtreams/ just in case.
>>>
>>> If you mean compatible with legacy Stream, no, this was a deliberate
>>> choice.
>>> I guess this is the best way to avoid importing cruft, and probably a
>>> good choice.
>>>
>>> Now, providing a legacy Stream compatibility layer should be really
>>> easy, at least for the most common selectors (ANSI).
>>> Solution 1) create a new wrapper that offers the compatible API, and
>>> arrange to let that wrapper on top of Xtreams composition chain.
>>> Solution 2) create *LegacyStream extension messages in top category.
>>
>> Oops top classes, of course, I feel tired...
>>
>>>
>>> If we wish to take this path, the best is to ask author's advice, but
>>> I bet they will agree on 1).
>>> I'm quite sure this discussion already took place, but I feel too lazy
>>> to dig in mails this evening.
>>>
>>> The question is why you would wish such a compatibility thing?
>>> IMO, if you're going to create a new application, it's really worth
>>> trying with native Xtreams API.
>>> You'll acquire different reflex/adopt different patterns.
>>>
>>> Replacing the whole legacy Stream hierarchy in Squeak or Pharo is
>>> another matter.
>>> As already told, these classes have taken many responsabilities, so
>>> it's a really big work.
>>> The compatibility layer might serve for a transition period if we
>>> really wish to engage on this path.
>>>
>>> Last questions about alternatives: yes, plenty. Let's cite just two in
>>> Squeak/Pharo world:
>>> - Nile http://www.squeaksource.com/Nile/ : streams composed by Traits.
>>> Very complete. Main drawback IMO: tried to be a replacement of legacy
>>> streams, and thus failed to be simple.
>>> - SqueaXtream http://www.squeaksource.com/XTream/ which is my own
>>> playing with some of Xtreams ideas (composition) with Stream
>>> compatible API. It's focused on Squeak and performance.
>>> Frankly, you should better stick with Xtreams, it's the most solid and
>>> supported.
>>>
>>> Nicolas
>>
>>
>