[Lift] Re: Removing Scala Actors from Lift

[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

[David Pollak]

On Fri, Oct 2, 2009 at 6:58 AM, Philipp  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

[Lift] Re: Removing Scala Actors from Lift

[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 abst

[Lift] Re: Removing Scala Actors from Lift

[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
wrote:

> Martin and Philipp,
> My immediate problem is:
>
> http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=en&lnk=gst&q=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  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 diffe

[Lift] Re: Removing Scala Actors from Lift

[martin]

Hi Jonas,

On Sep 30, 8:05 pm, Jonas Bonér  wrote:
> Hi Martin and Philipp.
>
> Thanks for your email. What you are saying sounds great. I love Scala
> Actors and I know its an important thing that brings people over to
> Scala.
>
> I hope that I didn't offend you. You have done amazing things with and
> for Scala. I really respect you guys.
>
> But I saw and felt the need for something like Akka and went away and build 
> it.
>
I think you have done a great thing with Akka, and I'm very glad you
did it! That's precisely the strength of Scala that experts can build
great libraries and high-level domain specific languages on it. I
really like where you are taking Akka, and I hope it will be very
succesfull.

As I wrote before, we are not at all defensive about our own actor
library. I think Scala actors are very useful for lots of people who
need easy and performant support for concurrent programs. If you need
to take it further (such as remoting, supervising, persistence), there
might be other more complete systems like Akka that can pick up there
and provide these things. We at EPFL simply do not have the
contributor base to do that ourselves, and that's also not our
mission, I think. We need to concentrate on core language, tools, and
some core libraries (if there's nobody else doing those). So I see
Akka as a very important upgrade path from simple multicore
concurrency to robust distributed systems. And I hope that other
people will do the same in other areas, such as I/O, serialization,
graphics, and so on.
If we can collaborate on those, great, but if people find it easier to
do their own thing, that's also perfectly fine.

The only thing I am asking is to avoid confusion to outside people. Be
clear what role you API serves, how it is different from others. Avoid
using the same name for different things.

Cheers

 -- Martin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Removing Scala Actors from Lift

[David Pollak]

Martin and Philipp,
My immediate problem is:
http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=en&lnk=gst&q=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  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 :

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 intr

[Lift] Re: Removing Scala Actors from Lift

[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 :
>
> 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

[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 :
> 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 :
>>
>> 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  wrote:
>>>
>>> 2009/9/30 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?
>>>
>>> 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
  wrote:
>
>
> On Tue, Sep 29, 2009 at 2:35 AM, 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.
>
> 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 

[Lift] Re: Removing Scala Actors from Lift

[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 :
>
> 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  wrote:
>>
>> 2009/9/30 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?
>>
>> 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
>>>  wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, 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.

 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 EPF

[Lift] Re: Removing Scala Actors from Lift

[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  wrote:
>
> 2009/9/30 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?
>
> 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
>>  wrote:
>>>
>>>
>>> On Tue, Sep 29, 2009 at 2:35 AM, 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.
>>>
>>> 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 
 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
 > Begi

[Lift] Re: Removing Scala Actors from Lift

[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

[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 Raychaudhuri 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 Bernard  
> 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  wrote:
>>> Aye
>>> +1
>>>
>>> On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
>>>   wrote:

 +1

 2009/9/30 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  wrote:
>>
>> 2009/9/30 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?
>>
>> 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
>>>   wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, 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.

 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

[Lift] Re: Removing Scala Actors from Lift

[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 Bernard  
> 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  wrote:
>>> Aye
>>> +1
>>>
>>> On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
>>>   wrote:

 +1

 2009/9/30 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  wrote:
>>
>> 2009/9/30 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?
>>
>> 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
>>>   wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, 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.

 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 o

[Lift] Re: Removing Scala Actors from Lift

[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  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  wrote:
>> Aye
>> +1
>>
>> On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
>>  wrote:
>>>
>>> +1
>>>
>>> 2009/9/30 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  wrote:
>
> 2009/9/30 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?
>
> 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
> >  wrote:
> >>
> >>
> >> On Tue, Sep 29, 2009 at 2:35 AM, 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.
> >>
> >> 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 
> >>> 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
> >>> > 

[Lift] Re: Removing Scala Actors from Lift

[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  wrote:
> Aye
> +1
>
> On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
>  wrote:
>>
>> +1
>>
>> 2009/9/30 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  wrote:

 2009/9/30 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?

 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
 >  wrote:
 >>
 >>
 >> On Tue, Sep 29, 2009 at 2:35 AM, 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.
 >>
 >> 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 
 >>> 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.

[Lift] Re: Removing Scala Actors from Lift

[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 
>
> 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  wrote:
>>
>>>
>>> 2009/9/30 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?
>>>
>>> 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
>>> >  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 
>>> >>> 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
>>> >>> >w

[Lift] Re: Removing Scala Actors from Lift

[Heiko Seeberger]

+1

2009/9/30 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  wrote:
>
>>
>> 2009/9/30 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?
>>
>> 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
>> >  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 
>> >>> 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
>> 

[Lift] Re: Removing Scala Actors from Lift

[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   
>> wrote:
>>
>> 2009/9/30 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?
>>
>> 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
>>>  wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, 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.

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

[Lift] Re: Removing Scala Actors from Lift

[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  wrote:
>
> 2009/9/30 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?
>
> 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
> >  wrote:
> >>
> >>
> >> On Tue, Sep 29, 2009 at 2:35 AM, 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.
> >>
> >> 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 
> >>> 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  
> befor

[Lift] Re: Removing Scala Actors from Lift

[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  wrote:

>
> 2009/9/30 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?
>
> 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
> >  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 
> >>> 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

[Lift] Re: Removing Scala Actors from Lift

[Jonas Bonér]

2009/9/30 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?

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
>  wrote:
>>
>>
>> On Tue, Sep 29, 2009 at 2:35 AM, 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.
>>
>> 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 
>>> 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://twitt

[Lift] Re: Removing Scala Actors from Lift

[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  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
>  wrote:
>>
>>
>> On Tue, Sep 29, 2009 at 2:35 AM, 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.
>>
>> 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 
>>> 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 r

[Lift] Re: Removing Scala Actors from Lift

[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.  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  wrote:
>> +1 sounds like sense to me :-)
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 29 Sep 2009, at 19:20, Naftoli Gugenheim 
>> 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 Pollak 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 
>>
>> >> 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

[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  wrote:
> +1 sounds like sense to me :-)
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 29 Sep 2009, at 19:20, Naftoli Gugenheim   
> 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 Pollak 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 
>
> >> 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

[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  wrote:

>
>
> On Tue, Sep 29, 2009 at 2:35 AM, 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.
>>
>
> 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 
>> 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

[Jonas Bonér]

2009/9/29 Heiko Seeberger :
> 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 
>>
>> 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

[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 Raychaudhuri 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

[Timothy Perrett]

+1 sounds like sense to me :-)

Cheers, Tim

Sent from my iPhone

On 29 Sep 2009, at 19:20, Naftoli Gugenheim   
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 Pollak 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 
>>
>> 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

[Rick R]

lift-webutil


On Tue, Sep 29, 2009 at 2:11 PM, David Pollak  wrote:

>
>
> On Tue, Sep 29, 2009 at 11:08 AM, 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.
>>
>
> 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

[Naftoli Gugenheim]

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 Pollak 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 
>
> 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

[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

[David Pollak]

On Tue, Sep 29, 2009 at 11:08 AM, 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.
>

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

[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

[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 
>
> 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

[David Pollak]

On Tue, Sep 29, 2009 at 12:49 AM, Timothy Perrett
wrote:

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


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

[David Pollak]

On Tue, Sep 29, 2009 at 2:35 AM, 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.
>

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

[David Pollak]

On Tue, Sep 29, 2009 at 3:33 AM, Stefan Langer
wrote:

> Has this been communicated? And if is there a bug number associated with
> this issue?
>

I have filed a number of bugs, had a number of on-list exchanges with
Philipp Haller, and others in the community have done the same.  We are not
keeping the issue a secret.


>
> Regards
> Stefan
>
>
> >
>


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

[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  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

[Stuart Roebuck]

Okay, I think I've now found the reference I was looking for...



Stuart.

On Sep 29, 10:35 am, 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 
> 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

[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

[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 
> 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

[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 
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

[Timothy Perrett]

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

Cheers, Tim

Sent from my iPhone

On 29 Sep 2009, at 03:30, David Pollak   
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
>
> >

--~--~-~--~~~---~--~~
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

[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

[Heiko Seeberger]

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?

Heiko

2009/9/29 David Pollak 

> 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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---