Hi Jonas,
On Sep 30, 8:05 pm, Jonas Bonér jbo...@gmail.com wrote:
Hi Martin and Philipp.
Thanks for your email. What you are saying sounds great. I love Scala
Actors and I know its an important thing that brings people over to
Scala.
I hope that I didn't offend you. You have done amazing
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
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
On Fri, Oct 2, 2009 at 6:58 AM, Philipp hall...@gmail.com wrote:
David,
My immediate problem is:
http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b...
This has been a persistent problem with Scala Actors and I identified it
last year in November or December.
This
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
Martin and Philipp,
My immediate problem is:
http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=enlnk=gstq=oome#
This has been a persistent problem with Scala Actors and I identified it
last year in November or December.
Philipp did the 2.7.4 release
2009/9/30 Josh Suereth joshua.suer...@gmail.com:
As much as I agree with your decision, it just makes me sad. I know lots
of people that learned scala for actors are the way of the future I
think we need to push harder. Hopefully all major projects migrating off
actors will give EPFL a
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
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
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
+1
2009/9/30 Derek Chen-Becker dchenbec...@gmail.com
I would vote for naming the new module lift-common and renaming lift-util
to lift-webutil. It does mean some breakage but I think that it's a clearer
naming. lift-util and lift-common are just too close for someone coming in
new, IMHO.
Aye
+1
On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
+1
2009/9/30 Derek Chen-Becker dchenbec...@gmail.com
I would vote for naming the new module lift-common and renaming lift-util
to lift-webutil. It does mean some breakage but I think that it's a
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
But my opinion == 0, I not a lift's user, but I see lot of case where
some lift lib could be used without working on a webapp.
On Wed, Sep 30, 2009 at 15:37, David Bernard david.bernard...@gmail.com wrote:
my salt
(I don't like lift-common, common of what ? )
If you don't want to move actors,
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
lift-webutil is very a good name. It conveys exactly what the module is.
But why not leave non-web-related functionality in lift-util? lift-util vs.
lift-webutil seems very unambiguous.
-
Indrajit Raychaudhuriindraj...@gmail.com wrote:
Nice to see the
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
Hi Jonas,
Can you list what the things Akka implements now are that Scala
actors don't have?
Thanks.
Bill
On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote:
2009/9/30 Josh Suereth joshua.suer...@gmail.com:
As much as I agree with your decision, it just makes me sad. I
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
Also, its pretty well documented.
Read more here: http://akkasource.org/
We need feedback so please let me know what you think.
2009/9/30 Jonas Bonér jbo...@gmail.com:
Hi Bill.
Here is a list of the things that Akka currently does (and that are
not in Scala Actors) and what I see needed in a
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
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
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,
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
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
Okay, I think I've now found the reference I was looking for...
http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/
200905.mbox/
%3ccdbebedf0905220957k7767c05emc0b6fb7812f1f...@mail.gmail.com%3e
Stuart.
On Sep 29, 10:35 am, Stuart Roebuck stuart.roeb...@gmail.com wrote:
Apologies if
Dear David,
i don't really see this as losing our Scala Actors so much as *gaining* an
interface. Surely, someone can wire up Scala Actors to that interface if
there is a need. ;-)
Best wishes,
--greg
On Mon, Sep 28, 2009 at 7:30 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
On Tue, Sep 29, 2009 at 12:49 AM, Timothy Perrett
timo...@getintheloop.euwrote:
David,
I'm not 100% clear on having Box not in lift-util? Lift-util then depends
on lift-base which appears to be dependency bloat to me
I use lift-util in several non-lift apps and libs - none of those
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
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
On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett
timo...@getintheloop.euwrote:
OK - that I can understand.
Could I suggest however that we find a different name? Both myself and
Marius were a little confused by that - nothing springs to mind, but
perhaps lets bounce around some names.
+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-webutil
On Tue, Sep 29, 2009 at 2:11 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett timo...@getintheloop.eu
wrote:
OK - that I can understand.
Could I suggest however that we find a different name? Both myself and
Marius
+1 sounds like sense to me :-)
Cheers, Tim
Sent from my iPhone
On 29 Sep 2009, at 19:20, Naftoli Gugenheim naftoli...@gmail.com
wrote:
If I was new to Lift and saw a lift-util module and a lift-base
module and had to guess which did not depend on anything web
related, I would
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
2009/9/29 Heiko Seeberger heiko.seeber...@googlemail.com:
What's the reason to have a new module (lift-base)? Why not put Actor to
lift-util and keep Box where it is?
In your branch def !?(timeout: Long, param: T) will return an Option.
Shouldn't this be a Box?
We are trying to find a common
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
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.
Hmmm. I still think that given lift-common and lift-util, lift-common
is more core sounding than lift-util...
Maybe lift-helpers?
On Tue, Sep 29, 2009 at 11:14 PM, marius d. marius.dan...@gmail.com wrote:
I'd vote for:
lift-common instead of lift-base. lift-base can be easily
misinterpreted
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
40 matches
Mail list logo
