[Lift] Re: Removing Scala Actors from Lift
Hi Jonas, On Sep 30, 8:05 pm, Jonas Bonér jbo...@gmail.com wrote: Hi Martin and Philipp. Thanks for your email. What you are saying sounds great. I love Scala Actors and I know its an important thing that brings people over to Scala. I hope that I didn't offend you. You have done amazing things with and for Scala. I really respect you guys. But I saw and felt the need for something like Akka and went away and build it. I think you have done a great thing with Akka, and I'm very glad you did it! That's precisely the strength of Scala that experts can build great libraries and high-level domain specific languages on it. I really like where you are taking Akka, and I hope it will be very succesfull. As I wrote before, we are not at all defensive about our own actor library. I think Scala actors are very useful for lots of people who need easy and performant support for concurrent programs. If you need to take it further (such as remoting, supervising, persistence), there might be other more complete systems like Akka that can pick up there and provide these things. We at EPFL simply do not have the contributor base to do that ourselves, and that's also not our mission, I think. We need to concentrate on core language, tools, and some core libraries (if there's nobody else doing those). So I see Akka as a very important upgrade path from simple multicore concurrency to robust distributed systems. And I hope that other people will do the same in other areas, such as I/O, serialization, graphics, and so on. If we can collaborate on those, great, but if people find it easier to do their own thing, that's also perfectly fine. The only thing I am asking is to avoid confusion to outside people. Be clear what role you API serves, how it is different from others. Avoid using the same name for different things. Cheers -- Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
David, I concur that while progress has been made my meta-issues have not been addressed. I think that effectively addressing using the current model and retaining something resembling API compatibility would be a huge task, and probably would have meant that very little newness from a feature-functionality could have been included in Scala 2.8. -Erik On Thu, Oct 1, 2009 at 8:34 PM, David Pollak feeder.of.the.be...@gmail.comwrote: Martin and Philipp, My immediate problem is: http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=enlnk=gstq=oome# This has been a persistent problem with Scala Actors and I identified it last year in November or December. Philipp did the 2.7.4 release which did not address the issue. The 2.7.5 release was supposed to address the issue, but the use of Lift Actors masked the issue until the above issue was raised. I left my 2.7.5 related discussions with Philipp with the impression that the java.util.concurrent library was being used for thread pooling rather than the FJ library. On this, I backed out the Lift Actor changes from powering Lift's CometActors (Lift Actors power the long polling part of Lift). On Wed, Sep 30, 2009 at 8:18 AM, martin oder...@gmail.com wrote: About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. I responded politely. Granted this is not something I always do (note, I am not being facetious), but I simply said something like looks good to me. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. Do you have specific benchmarks that justify the tradeoff of baking in an external library (that could be as buggy as the one that's currently baked into Scala) versus java.util.concurrent? We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. I did a code review of the 2.8 Actors. I am not convinced that Erik's meta-concerns were addressed. I will be happy to be more descriptive off-list. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. While this is a nice thought, given the choice between debating with EPFL as to whether my changes are good enough or doing a Lift Actor implementation, I will opt for continuing to develop and maintain the Lift Actor library. This gives Lift users the assurance that bugs will be fixed in a timely manner, that we can add features based on community need, and that we can work with other library authors to insure common interfaces. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. Lift Actors allow for changing (and nesting) the message handler on a message-by-message basis and because the handler can be defined within a given partial function, it can close over the variables visible in that partial function. Granted the syntax for doing so in Scala Actors is much more pleasing, the functionality exists with Lift Actors. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion.
[Lift] Re: Removing Scala Actors from Lift
David, My immediate problem is:http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b... This has been a persistent problem with Scala Actors and I identified it last year in November or December. This is indeed supposed to be fixed in Scala 2.7.7 (to be released later today). It replaces the old (as opposed to the new one for JDK7) FJ framework with java.util.concurrent.ThreadPoolExecutor. Philipp did the 2.7.4 release which did not address the issue. The 2.7.5 release was supposed to address the issue, but the use of Lift Actors masked the issue until the above issue was raised. I left my 2.7.5 related discussions with Philipp with the impression that the java.util.concurrent library was being used for thread pooling rather than the FJ library. On this, I backed out the Lift Actor changes from powering Lift's CometActors (Lift Actors power the long polling part of Lift). So, I guess there was a mis-understanding. 2.7.5 tried to fix several issues related to memory leakage; however, it did not replace the use of the FJ library. This was, however, done in trunk a couple of weeks before 2.7.5 was released. At the time of JavaOne (beginning of June), the plan was still to release (a beta of) Scala 2.8 in July. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. Do you have specific benchmarks that justify the tradeoff of baking in an external library (that could be as buggy as the one that's currently baked into Scala) versus java.util.concurrent? We did some experiments that show that, indeed, a work-stealing thread pool is better than a java.util.concurrent.Executor with a central entry queue when running on an 8-core machine. You find a plot in this tech report: http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf I am talking about figure 7 on page 16. It shows the performance of a heat diffusion simulation implemented using actors. In the global version, actors use a thread pool with a global task queue (like java.util.concurrent.Executor). The local version uses FJ for task execution (each pool thread has its own local queue). One can see that when using more than 4 hardware threads, the performance of global decreases because the global task queue is contended. This is just one concrete experiment that I did. There is of course a lot more work out there that shows experimental results on the performance of work- stealing (for instance, Cilk, data-parallel Haskell, etc). So, I firmly believe that the ForkJoinPool of JDK 7 is the way to go. Doug Lea told me in person that the new version has virtually no line of code in common with the old FJTask library; it has been completely redesigned and rewritten. However, by default it compiles and runs only on JDK 1.6. It is possible to backport it to JDK 1.5; however, if your 1.5 JVM is not up-to-date, you can encounter unexpected InterruptedExceptions being thrown. That's the main reason why I am not in favor of using it on JDK 1.5. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. While this is a nice thought, given the choice between debating with EPFL as to whether my changes are good enough or doing a Lift Actor implementation, I will opt for continuing to develop and maintain the Lift Actor library. This gives Lift users the assurance that bugs will be fixed in a timely manner, that we can add features based on community need, and that we can work with other library authors to insure common interfaces. I'd be happier if more people would debate with us. :-) But there is a difference between a research vehicle and something that can be used in production systems. What Philipp has done is delivered a prototype and a vision of concurrency to the Scala community. What Jonas and I have done is built production-quality systems based on that vision, our experience, and other systems we have used or observed. I second Martin's view. You and Jonas are doing really great work. But, I also think that it is important to have a core set of concurrency abstractions in the standard library that can be used in production
[Lift] Re: Removing Scala Actors from Lift
On Fri, Oct 2, 2009 at 6:58 AM, Philipp hall...@gmail.com wrote: David, My immediate problem is: http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b... This has been a persistent problem with Scala Actors and I identified it last year in November or December. This is indeed supposed to be fixed in Scala 2.7.7 (to be released later today). It replaces the old (as opposed to the new one for JDK7) FJ framework with java.util.concurrent.ThreadPoolExecutor. Just to be very, very, very clear, I will not upgrade Lift to use any Scala release that has not gone through a reasonable release candidate testing cycle. While EPFL may choose to have a failed release policy, I will not subject users of Lift to such a policy. I will address the balance of the email when I have more time. Philipp did the 2.7.4 release which did not address the issue. The 2.7.5 release was supposed to address the issue, but the use of Lift Actors masked the issue until the above issue was raised. I left my 2.7.5 related discussions with Philipp with the impression that the java.util.concurrent library was being used for thread pooling rather than the FJ library. On this, I backed out the Lift Actor changes from powering Lift's CometActors (Lift Actors power the long polling part of Lift). So, I guess there was a mis-understanding. 2.7.5 tried to fix several issues related to memory leakage; however, it did not replace the use of the FJ library. This was, however, done in trunk a couple of weeks before 2.7.5 was released. At the time of JavaOne (beginning of June), the plan was still to release (a beta of) Scala 2.8 in July. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. Do you have specific benchmarks that justify the tradeoff of baking in an external library (that could be as buggy as the one that's currently baked into Scala) versus java.util.concurrent? We did some experiments that show that, indeed, a work-stealing thread pool is better than a java.util.concurrent.Executor with a central entry queue when running on an 8-core machine. You find a plot in this tech report: http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf I am talking about figure 7 on page 16. It shows the performance of a heat diffusion simulation implemented using actors. In the global version, actors use a thread pool with a global task queue (like java.util.concurrent.Executor). The local version uses FJ for task execution (each pool thread has its own local queue). One can see that when using more than 4 hardware threads, the performance of global decreases because the global task queue is contended. This is just one concrete experiment that I did. There is of course a lot more work out there that shows experimental results on the performance of work- stealing (for instance, Cilk, data-parallel Haskell, etc). So, I firmly believe that the ForkJoinPool of JDK 7 is the way to go. Doug Lea told me in person that the new version has virtually no line of code in common with the old FJTask library; it has been completely redesigned and rewritten. However, by default it compiles and runs only on JDK 1.6. It is possible to backport it to JDK 1.5; however, if your 1.5 JVM is not up-to-date, you can encounter unexpected InterruptedExceptions being thrown. That's the main reason why I am not in favor of using it on JDK 1.5. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. While this is a nice thought, given the choice between debating with EPFL as to whether my changes are good enough or doing a Lift Actor implementation, I will opt for continuing to develop and maintain the Lift Actor library. This gives Lift users the assurance that bugs will be fixed in a timely manner, that we can add features based on community need, and that we can work with other library authors to insure common interfaces. I'd be happier if more people would debate with us. :-) But there is a difference between a research vehicle and something that can be used in
[Lift] Re: Removing Scala Actors from Lift
David, Philipp did the 2.7.4 release which did not address the issue. The 2.7.5 release was supposed to address the issue, but the use of LiftActorsmasked the issue until the above issue was raised. I left my 2.7.5 related discussions with Philipp with the impression that the java.util.concurrent library was being used for thread pooling rather than the FJ library. On this, I backed out the Lift Actor changes from powering Lift's CometActors (LiftActorspower the long polling part of Lift). So, I guess there was a mis-understanding. 2.7.5 tried to fix several issues related to memory leakage; however, it did not replace the use of the FJ library. This was, however, done in trunk a couple of weeks before 2.7.5 was released. At the time of JavaOne (beginning of June), the plan was still to release (a beta of)Scala2.8 in July. Just to be clear, I am really sorry for how things went. I was just trying to reconstruct some of the events that seem important to me. Of course, I have to be blamed for the decisions I have taken. Honestly, if I would have known better, I would have done things differently. Otherwise, I apologize if I didn't get the balance of my response right; I tried to provide some helpful input. Sorry if it wasn't appropriate. Regards, Philipp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Martin and Philipp, My immediate problem is: http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=enlnk=gstq=oome# This has been a persistent problem with Scala Actors and I identified it last year in November or December. Philipp did the 2.7.4 release which did not address the issue. The 2.7.5 release was supposed to address the issue, but the use of Lift Actors masked the issue until the above issue was raised. I left my 2.7.5 related discussions with Philipp with the impression that the java.util.concurrent library was being used for thread pooling rather than the FJ library. On this, I backed out the Lift Actor changes from powering Lift's CometActors (Lift Actors power the long polling part of Lift). On Wed, Sep 30, 2009 at 8:18 AM, martin oder...@gmail.com wrote: About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. I responded politely. Granted this is not something I always do (note, I am not being facetious), but I simply said something like looks good to me. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. Do you have specific benchmarks that justify the tradeoff of baking in an external library (that could be as buggy as the one that's currently baked into Scala) versus java.util.concurrent? We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. I did a code review of the 2.8 Actors. I am not convinced that Erik's meta-concerns were addressed. I will be happy to be more descriptive off-list. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. While this is a nice thought, given the choice between debating with EPFL as to whether my changes are good enough or doing a Lift Actor implementation, I will opt for continuing to develop and maintain the Lift Actor library. This gives Lift users the assurance that bugs will be fixed in a timely manner, that we can add features based on community need, and that we can work with other library authors to insure common interfaces. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. Lift Actors allow for changing (and nesting) the message handler on a message-by-message basis and because the handler can be defined within a given partial function, it can close over the variables visible in that partial function. Granted the syntax for doing so in Scala Actors is much more pleasing, the functionality exists with Lift Actors. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. Quoting from Wikipedia http://en.wikipedia.org/wiki/Actor_model: An actor is a computational entity that, in response to a message it receives, can concurrently: - send a finite number of messages to other actors; - create a finite number of new actors; - designate the behavior to be used for the next message it receives. Lift Actors do all of these things. I think it's a great thing that Philipp and the EPFL team introduced Actors to the JVM and Scala
[Lift] Re: Removing Scala Actors from Lift
2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org
[Lift] Re: Removing Scala Actors from Lift
I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow
[Lift] Re: Removing Scala Actors from Lift
As someone coming in new I +1 to Derek’s vote. Stuart. On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote: I would vote for naming the new module lift-common and renaming lift- util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff.
[Lift] Re: Removing Scala Actors from Lift
Sounds like a fair trade off +1 On 30 Sep 2009, at 14:15, Stuart Roebuck wrote: As someone coming in new I +1 to Derek’s vote. Stuart. On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote: I would vote for naming the new module lift-common and renaming lift- util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning
[Lift] Re: Removing Scala Actors from Lift
+1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net
[Lift] Re: Removing Scala Actors from Lift
Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments?
[Lift] Re: Removing Scala Actors from Lift
my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so
[Lift] Re: Removing Scala Actors from Lift
But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernard david.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code -
[Lift] Re: Removing Scala Actors from Lift
Nice to see the intent to withstand little breakage for the right reason! I am +0 on lift-common. It possibly doesn't mean much, but the only reason I proposed it as an option is because most people with exposure to Java projects have encountered jakarta-common and in some sense have *-common hardwired in their brain and can relate to. Personally, I am -1 on liftx and lift-scalax. They either don't conform to naming convention or aren't unambiguous enough. +1 for lift-util to lift-webutil. Cheers, Indrajit NB: 0. Let's use one conversation trail to converge on the name(s) please. Reduce duplications ;-) 1. It's imperative that the package for the respective classes would have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar would be utterly confusing IMHO. 2. Once the package names are through, the Lift book would need to be updated too. On 30/09/09 7:09 PM, David Bernard wrote: But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com wrote: 2009/9/30 Josh Suerethjoshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollakfeeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala
[Lift] Re: Removing Scala Actors from Lift
lift-webutil is very a good name. It conveys exactly what the module is. But why not leave non-web-related functionality in lift-util? lift-util vs. lift-webutil seems very unambiguous. - Indrajit Raychaudhuriindraj...@gmail.com wrote: Nice to see the intent to withstand little breakage for the right reason! I am +0 on lift-common. It possibly doesn't mean much, but the only reason I proposed it as an option is because most people with exposure to Java projects have encountered jakarta-common and in some sense have *-common hardwired in their brain and can relate to. Personally, I am -1 on liftx and lift-scalax. They either don't conform to naming convention or aren't unambiguous enough. +1 for lift-util to lift-webutil. Cheers, Indrajit NB: 0. Let's use one conversation trail to converge on the name(s) please. Reduce duplications ;-) 1. It's imperative that the package for the respective classes would have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar would be utterly confusing IMHO. 2. Once the package names are through, the Lift book would need to be updated too. On 30/09/09 7:09 PM, David Bernard wrote: But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com wrote: 2009/9/30 Josh Suerethjoshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and
[Lift] Re: Removing Scala Actors from Lift
About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. And that's not good for the goal of convincing people that actors are a useful concurrency abstraction. So, nothing against lift actors and Akka, but we need to be precise about the tradeoffs. Maybe call them `flat actors' or something like that. Martin and Philipp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Jonas Bonér
[Lift] Re: Removing Scala Actors from Lift
Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that
[Lift] Re: Removing Scala Actors from Lift
Also, its pretty well documented. Read more here: http://akkasource.org/ We need feedback so please let me know what you think. 2009/9/30 Jonas Bonér jbo...@gmail.com: Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been
[Lift] Re: Removing Scala Actors from Lift
Hi Martin and Philipp. Thanks for your email. What you are saying sounds great. I love Scala Actors and I know its an important thing that brings people over to Scala. I hope that I didn't offend you. You have done amazing things with and for Scala. I really respect you guys. But I saw and felt the need for something like Akka and went away and build it. What you say about the trade-offs in Actor expressiveness is really true. I (and David I think) have not seen that much need for nested receive/react and therefore I have not included in the impl but rather focussing on other things that I find more important. This articles sums it up pretty well: http://erikengbrecht.blogspot.com/2009/06/pondering-actor-design-trades.html Looking forward to 2.8 and the new actor impl. /Jonas 2009/9/30 martin oder...@gmail.com: About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. And that's not good for the goal of convincing people that actors are a useful concurrency abstraction. So, nothing against lift actors and Akka, but we need to be precise about the tradeoffs. Maybe call them `flat actors' or something like that. Martin and Philipp -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hi David, Could you give some short step-by-step guide, how to change the most important stuff in case of compilation errors that are caused because of this? Maybe that would safe some time afterwards. I'm thinking about to start my application exclusively with -o to make sure that no updates are applied.good or bad? thanks Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: * Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) * If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code * Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Basically there are parts of lift where we are doing high volume creation and destruction of actors and over time, they leak memory ever-so-slightly which increases heap size incrementally. Of course, leaking memory is a bad thing for long-running processes and until EPFL fix there implementation we've decided to go and fix it ourselves. Does that clear it up for you? Cheers, Tim On 29 Sep 2009, at 10:35, Stuart Roebuck wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Has this been communicated? And if is there a bug number associated with this issue? Regards Stefan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Okay, I think I've now found the reference I was looking for... http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/ 200905.mbox/ %3ccdbebedf0905220957k7767c05emc0b6fb7812f1f...@mail.gmail.com%3e Stuart. On Sep 29, 10:35 am, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Dear David, i don't really see this as losing our Scala Actors so much as *gaining* an interface. Surely, someone can wire up Scala Actors to that interface if there is a need. ;-) Best wishes, --greg On Mon, Sep 28, 2009 at 7:30 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
On Tue, Sep 29, 2009 at 12:49 AM, Timothy Perrett timo...@getintheloop.euwrote: David, I'm not 100% clear on having Box not in lift-util? Lift-util then depends on lift-base which appears to be dependency bloat to me I use lift-util in several non-lift apps and libs - none of those would need lift-actors lift-util is weighted very much toward web development. lift-base will be generic. Cheers, Tim Sent from my iPhone On 29 Sep 2009, at 03:30, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpphttp://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? Because there are a lot of web-related things in lift-utils. I am going to for a separate package that is far more generic. In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
OK - that I can understand. Could I suggest however that we find a different name? Both myself and Marius were a little confused by that - nothing springs to mind, but perhaps lets bounce around some names. Cheers, Tim On 29 Sep 2009, at 18:41, David Pollak wrote: lift-util is weighted very much toward web development. lift-base will be generic. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett timo...@getintheloop.euwrote: OK - that I can understand. Could I suggest however that we find a different name? Both myself and Marius were a little confused by that - nothing springs to mind, but perhaps lets bounce around some names. Sure. Now's the time. In a week or so, I want to get the naming and the interfaces clean so people something stable to code against. Cheers, Tim On 29 Sep 2009, at 18:41, David Pollak wrote: lift-util is weighted very much toward web development. lift-base will be generic. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
+1, more so because other apps not using much of lift 'web'by stuff could use this too. Couple of options: 1. lift-common (along the lines of Jakarta Commons - not intuitive, but Java developers used to Jakarta Commons would be able to relate) 2. Actually naming lift-base as lift-util and lift-util as something else. This is backward incompatible though, but then again this is bleeding edge SNAPSHOT afterall :-P 3. Something else that's better ? Cheers, Indrajit On 29/09/09 11:38 PM, Timothy Perrett wrote: OK - that I can understand. Could I suggest however that we find a different name? Both myself and Marius were a little confused by that - nothing springs to mind, but perhaps lets bounce around some names. Cheers, Tim On 29 Sep 2009, at 18:41, David Pollak wrote: lift-util is weighted very much toward web development. lift-base will be generic. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
lift-webutil On Tue, Sep 29, 2009 at 2:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett timo...@getintheloop.eu wrote: OK - that I can understand. Could I suggest however that we find a different name? Both myself and Marius were a little confused by that - nothing springs to mind, but perhaps lets bounce around some names. Sure. Now's the time. In a week or so, I want to get the naming and the interfaces clean so people something stable to code against. Cheers, Tim On 29 Sep 2009, at 18:41, David Pollak wrote: lift-util is weighted very much toward web development. lift-base will be generic. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
+1 sounds like sense to me :-) Cheers, Tim Sent from my iPhone On 29 Sep 2009, at 19:20, Naftoli Gugenheim naftoli...@gmail.com wrote: If I was new to Lift and saw a lift-util module and a lift-base module and had to guess which did not depend on anything web related, I would probably pick lift-util without hesitation. After all, lift is the name of a web framework, and lift-base implies that it's basic but central classes etc. lift-util sounds like utilities that are useful to lift, even necessary, but not central to what lift is. Many libraries have a util that has code with broad applicability but that needed to be packaged with the library because it relies on it and it wan't worth it to get the functionality elsewhere. So if it's an option I would move the web-related functionality to lift-base and leave Box and Actor etc. in lift-util. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? Because there are a lot of web-related things in lift-utils. I am going to for a separate package that is far more generic. In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
It's true that technically it's not backward compatible, but how many users add lift-util as a dependency manually? If you only have lift-core as a dependency then as long as its dependencies are correct the user will get the jars he needs. Although that only helps maven-wise, not for package names. Also, what will be with Helpers? It mixes a lot of things. Since Helpers depends on things like BindHelpers it would have to go in the web-related package which can depend on the generic package. From there it could mix in things from both packages. Someone not writing a web ap could use the individual relevant helpers. Both Box and Helpers are very common imports from util, but I think that if one has to go, compatibility also prefers moving Helpers because although common, I'd assume Box is even more common. With 2.8 there's a way to move packages without breaking compatibility though. - Indrajit Raychaudhuriindraj...@gmail.com wrote: +1, more so because other apps not using much of lift 'web'by stuff could use this too. Couple of options: 1. lift-common (along the lines of Jakarta Commons - not intuitive, but Java developers used to Jakarta Commons would be able to relate) 2. Actually naming lift-base as lift-util and lift-util as something else. This is backward incompatible though, but then again this is bleeding edge SNAPSHOT afterall :-P 3. Something else that's better ? Cheers, Indrajit On 29/09/09 11:38 PM, Timothy Perrett wrote: OK - that I can understand. Could I suggest however that we find a different name? Both myself and Marius were a little confused by that - nothing springs to mind, but perhaps lets bounce around some names. Cheers, Tim On 29 Sep 2009, at 18:41, David Pollak wrote: lift-util is weighted very much toward web development. lift-base will be generic. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
2009/9/29 Heiko Seeberger heiko.seeber...@googlemail.com: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? We are trying to find a common interface for the Actors to work with both lift-actors and akka actors. Akka is not using Box but Option. Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.comwrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: - Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. - The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) - EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp:// github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
I'd vote for: lift-common instead of lift-base. lift-base can be easily misinterpreted as lift's base traits and classes? ... which is not the case. This can hold, Box, comb parsers (JSON, VCard etc), liftactors etc. lift-util - things that are in the current util but lean towards web realm. Br's, Marius On Sep 29, 2:17 pm, Timothy Perrett timo...@getintheloop.eu wrote: +1 sounds like sense to me :-) Cheers, Tim Sent from my iPhone On 29 Sep 2009, at 19:20, Naftoli Gugenheim naftoli...@gmail.com wrote: If I was new to Lift and saw a lift-util module and a lift-base module and had to guess which did not depend on anything web related, I would probably pick lift-util without hesitation. After all, lift is the name of a web framework, and lift-base implies that it's basic but central classes etc. lift-util sounds like utilities that are useful to lift, even necessary, but not central to what lift is. Many libraries have a util that has code with broad applicability but that needed to be packaged with the library because it relies on it and it wan't worth it to get the functionality elsewhere. So if it's an option I would move the web-related functionality to lift-base and leave Box and Actor etc. in lift-util. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? Because there are a lot of web-related things in lift-utils. I am going to for a separate package that is far more generic. In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hmmm. I still think that given lift-common and lift-util, lift-common is more core sounding than lift-util... Maybe lift-helpers? On Tue, Sep 29, 2009 at 11:14 PM, marius d. marius.dan...@gmail.com wrote: I'd vote for: lift-common instead of lift-base. lift-base can be easily misinterpreted as lift's base traits and classes? ... which is not the case. This can hold, Box, comb parsers (JSON, VCard etc), liftactors etc. lift-util - things that are in the current util but lean towards web realm. Br's, Marius On Sep 29, 2:17 pm, Timothy Perrett timo...@getintheloop.eu wrote: +1 sounds like sense to me :-) Cheers, Tim Sent from my iPhone On 29 Sep 2009, at 19:20, Naftoli Gugenheim naftoli...@gmail.com wrote: If I was new to Lift and saw a lift-util module and a lift-base module and had to guess which did not depend on anything web related, I would probably pick lift-util without hesitation. After all, lift is the name of a web framework, and lift-base implies that it's basic but central classes etc. lift-util sounds like utilities that are useful to lift, even necessary, but not central to what lift is. Many libraries have a util that has code with broad applicability but that needed to be packaged with the library because it relies on it and it wan't worth it to get the functionality elsewhere. So if it's an option I would move the web-related functionality to lift-base and leave Box and Actor etc. in lift-util. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? Because there are a lot of web-related things in lift-utils. I am going to for a separate package that is far more generic. In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hi Josh, I don't think it is such a bad sign that multiple actor libraries are popping up. There isn't one way to write actors. There are many. List seems to create lots of very short-lived actors if I have understood that correctly. Nothing wrong with that, but it doesn't mean that all implementations of the actor concept must absolutely support that use case. Some actors can be tuned to be short lived creatures, others designed for more stable, longer lives. Some actors can be designed primarily for being in one VM, others for existing in distributed systems, etc. Scala's focus on letting people design things in libraries is exactly why it is possible to do multiple actor designs. In Erlang it might not be as easy. That said, it would be nice to get the memory leak problem solved in Scala actors, and I'm confident that will happen eventually. But I use one simple Scala actor in ScalaTest and it works just fine for my use case, which is to collect events fired during parallel runs, serialize them, and report them in various ways. There's just one actor for each ScalaTest run, so I have no memory leak problem. I probably will remove that actor eventually though, not because of any problems with the implementation but just because I suspect it isn't the best fit performance-wise. Bill On Tue, Sep 29, 2009 at 7:37 PM, Josh Suereth joshua.suer...@gmail.com wrote: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official
