Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)
I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks! Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-). As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side). Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc. That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this. Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there). Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc. Martin "Nicolas Cellier"<nicolas.cellier.aka.nice@gmail.com> wrote:
Yes that's a correct description of the past and present.
The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream
There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge.
Nicolas
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Martin, Michael. thanks for this feedback, that's usefull. 2010/10/8 <mkobetic@gmail.com>:
I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well.
First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks!
Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-).
More example than the site http://code.google.com/p/xtreams/ ? If so, I'm interested.
As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side).
Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc.
Yes, I think this is even worse in Squeak, because of proliferation of subclasses. I played with it, but that can't be a transparent replacement. Rather a huge rewrite (not counting external packages...)
That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this.
Yes, that makes sense, what I call the Xtreme approach... Less confusion. However it would be wonderfull to get feedback from average programmer about this on real application. Maybe this will be a matter of adding one missing convenient message or two...
Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there).
Hehe, I've got the feeling to surf on your hard work with low investment ;) Xtream ideas should definitly continue to attract. J'espère que la mayonnaise va prendre. Of course the best option is to share. Though I don't think Xtream was developped with portability as main goal, it's not sure it has so many external dependencies. Is there a tool to identify the dependency on classes outside the package in VW ? We know in advance a few concerning the system, File & Sockets, DLLCC, compression... With good package delimitation, that can be worked out. The problem with Squeak is that we don't have a good File library (non blocking). The good point with Xtream is that we don't need that many primitives. And last good point is the huge effort you made to coverage tests... That should ease porting. Then, there is the question of using Exception handling or not. In Squeak, this isn't going to be a matter of compatibility (though the difference might be subtle), rather a matter of efficiency. However, Incomplete is a corner stone of Xtream implementation if I understand correctly... Squeak is not using EndOfStream http://bugs.squeak.org/view.php?id=6755 and some of the efficiency reasons are there http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122434.... On the other hand, the endOfStreamAction of Squeak_Xtream is pleasant at first, but hard to handle across wrappers. I don't yet have an answer whether it scales on a more complete xtream library or not (thinking of blocking streams...).
Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc.
Martin
"Nicolas Cellier"<nicolas.cellier.aka.nice@gmail.com> wrote:
Yes that's a correct description of the past and present.
The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream
There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge.
Nicolas
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Martin & Michael, Thank you first for coming up with xtreams and second for taking the open source route and doing the effort to promote it. I've been browsing a bit in vwnc 7.7 and it really shows that you guys have been thinking about this for quite some time and that this is not the first implementation. This is Smalltalk code that confirms my belief why Smalltalk is better. I am happy with your reaction and I agree with the goal that xstreams should be loadable and usable next to the standard stuff. Selector names are clearly carefully chosen to make this possible, class names are a bit harder for Smalltalks without name spaces ;-) I think we (for me, that is Pharo users, for others that might be Squeak users) should really take this opportunity (your invitation) and help turn the xstreams codebase into something portable to multiple Smalltalk implementations. With Nicolas there is already somebody with great concrete experience and actual code to help make this a reality. If I can, I will at least be an interested user and hopefully also capable of contributing. Sven On 08 Oct 2010, at 22:04, mkobetic@gmail.com wrote:
I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well.
First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks!
Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-).
As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side).
Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc.
That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this.
Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there).
Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc.
Martin
"Nicolas Cellier"<nicolas.cellier.aka.nice@gmail.com> wrote:
Yes that's a correct description of the past and present.
The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream
There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge.
Nicolas
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
mkobetic＠gmail.com -
Nicolas Cellier -
Sven Van Caekenberghe