[Lift] Re: Removing Scala Actors from Lift

2009-10-02 Thread martin

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

2009-10-02 Thread Erik Engbrecht
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

2009-10-02 Thread Philipp

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

2009-10-02 Thread David Pollak
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

2009-10-02 Thread Philipp

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

2009-10-01 Thread David Pollak
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-09-30 Thread Jonas Bonér

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

2009-09-30 Thread Derek Chen-Becker
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

2009-09-30 Thread Stuart Roebuck

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

2009-09-30 Thread Timothy Perrett

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

2009-09-30 Thread Heiko Seeberger
+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

2009-09-30 Thread Viktor Klang
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

2009-09-30 Thread David Bernard

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

2009-09-30 Thread David Bernard

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

2009-09-30 Thread Indrajit Raychaudhuri

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

2009-09-30 Thread Naftoli Gugenheim

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

2009-09-30 Thread martin

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

2009-09-30 Thread Bill Venners

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

2009-09-30 Thread Jonas Bonér

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

2009-09-30 Thread Jonas Bonér

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

2009-09-30 Thread Jonas Bonér

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

2009-09-29 Thread Tobias Daub

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

2009-09-29 Thread Stuart Roebuck

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

2009-09-29 Thread Timothy Perrett

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

2009-09-29 Thread Stefan Langer
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

2009-09-29 Thread Stuart Roebuck

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

2009-09-29 Thread Meredith Gregory
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

2009-09-29 Thread David Pollak
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

2009-09-29 Thread David Pollak
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

2009-09-29 Thread Timothy Perrett

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-09-29 Thread David Pollak
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

2009-09-29 Thread Indrajit Raychaudhuri

+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-09-29 Thread Rick R
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

2009-09-29 Thread Timothy Perrett

+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

2009-09-29 Thread Naftoli Gugenheim

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-09-29 Thread Jonas Bonér

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

2009-09-29 Thread Josh Suereth
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

2009-09-29 Thread marius d.

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

2009-09-29 Thread Naftoli Gugenheim

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

2009-09-29 Thread Bill Venners

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