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 |
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 > |
On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <[hidden email]> wrote:
When I need streams, I only use Xtreams. +1. Xtreams is great. |
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 |
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:
|
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 |
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 > > |
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 |
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:
|
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 >> >> > |
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 |
Free forum by Nabble | Edit this page |