opinion on xtreams wanted

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

opinion on xtreams wanted

Martin Kuball
Hi,

now and than you read about xtreams and the stream implementation in squeak being bad. So I wonder what is your opinion of xtreams. Is it compatible with squeak 4.4? Is it maintained? Are there alternatives?

Martin

Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Frank Shearar-3
On 25 February 2013 20:14, Martin Kuball <[hidden email]> wrote:
> Hi,
>
> now and than you read about xtreams and the stream implementation in squeak being bad. So I wonder what is your opinion of xtreams. Is it compatible with squeak 4.4? Is it maintained? Are there alternatives?

Xtreams is _wonderful_ to use. It's a bit... tricky to install at the
moment, in both 4.4 and 4.5. There is an install script someone wrote,
back in the list archives.

Mainly it needs someone to write a SqueakMap entry... Nicolas? S'il vous plaît?

When I need streams, I only use Xtreams.

(Yes, it is maintained, but it doesn't actually require much maintenance.)

frank

> Martin
>

Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Colin Putney-3



On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]> 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. 


Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Nicolas Cellier
2013/2/25 Colin Putney <[hidden email]>:

>
>
>
> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

douglas mcpherson
In reply to this post by Colin Putney-3
+1.

Xtreams are awesome. I find stacking and transforms especially useful.


On Feb 25, 2013, at 14:30 , Colin Putney wrote:




On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]> 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. 




Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Nicolas Cellier
In reply to this post by Nicolas Cellier
2013/2/26 Nicolas Cellier <[hidden email]>:

> 2013/2/25 Colin Putney <[hidden email]>:
>>
>>
>>
>> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Hannes Hirzel
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

On 2/25/13, Nicolas Cellier <[hidden email]> wrote:

> 2013/2/26 Nicolas Cellier <[hidden email]>:
>> 2013/2/25 Colin Putney <[hidden email]>:
>>>
>>>
>>>
>>> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]>
>>> 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
>
>

Reply | Threaded
Open this post in threaded view
|

[ANN] SqueakRos4dot4.12098 ready for try (was Re: [squeak-dev] opinion on xtreams wanted)

Edgar De Cleene



On 2/26/13 1:34 AM, "H. Hirzel" <[hidden email]> wrote:

> 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.h
> tml
>
> But it refers to a copy Colin Putney keeps at his wiresong site.
>
> --Hannes

Thanks all who work, so the growing list of my fork of "official" Squeak
have now:

Environments
Gofer
HV
Kom
Metacello
OB (OmniBrowser)
Scheduler
VB-Regex
XML-Parser
CommandShell
OSProcess
Fuel
FFI
Xtreams

Here you find the rare pet
http://squeakros.org/SqueakRos4dot4.12098.zip

Edgar





Reply | Threaded
Open this post in threaded view
|

Re: [squeakRos] [ANN] SqueakRos4dot4.12098 ready for try (was Re: [squeak-dev] opinion on xtreams wanted)

tinchodias
Thank you for including Fuel. We are releasing a new version (1.9) this week. It is working but seems that still we have to fix something in the compatibility packages so it can work out of the box in squeak. Max is the expert in that!

Cheers,
Martin


On Tue, Feb 26, 2013 at 7:48 AM, Edgar J. De Cleene <[hidden email]> wrote:
 



On 2/26/13 1:34 AM, "H. Hirzel" [hidden email]> wrote:

> 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.h
> tml
>
> But it refers to a copy Colin Putney keeps at his wiresong site.
>
> --Hannes

Thanks all who work, so the growing list of my fork of "official" Squeak
have now:

Environments
Gofer
HV
Kom
Metacello
OB (OmniBrowser)
Scheduler
VB-Regex
XML-Parser
CommandShell
OSProcess
Fuel
FFI
Xtreams

Here you find the rare pet
http://squeakros.org/SqueakRos4dot4.12098.zip

Edgar

__._,_.___
Actividad reciente:

correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

.

__,_._,___



Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Nicolas Cellier
In reply to this post by Hannes Hirzel
2013/2/26 H. Hirzel <[hidden email]>:
> 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 <[hidden email]> wrote:
>> 2013/2/26 Nicolas Cellier <[hidden email]>:
>>> 2013/2/25 Colin Putney <[hidden email]>:
>>>>
>>>>
>>>>
>>>> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]>
>>>> 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: opinion on xtreams wanted

Martin Kuball
In reply to this post by douglas mcpherson
Am Tuesday 26 February 2013 schrieb Douglas McPherson:

> +1.
>
> Xtreams are awesome. I find stacking and transforms especially useful.
>
>
> On Feb 25, 2013, at 14:30 , Colin Putney wrote:
>
> >
> >
> >
> > On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]> 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.
> >
>
>

Thank you very much for your answers. I'l give it a try next weekend. And stacking is exactly what I'm looking for. At least I think so ;).

Martin