[Lift] Re: Question about the Getting Started Guide

2009-09-30 Thread Indrajit Raychaudhuri

Great!

The downloaded files are stored in ${user.home}/.m2/repository.
${user.home} is the standard Java environment variable that defaults to 
$HOME in *nix and $USERPROFILE in Windows.

[1] Setting proxies and other environment stuff can be done via 
settings: http://maven.apache.org/settings.html
[2] More about repositories: 
http://maven.apache.org/guides/introduction/introduction-to-repositories.html

Cheers, Indrajit

On 30/09/09 11:36 AM, jli...@gmail.com wrote:
 Hello Indrajit and those who replied, thanks for all your help.
 Finally I got it working. It probably had something to do with
 the proxy in my work environment.

 BTW, do you know where maven stores those downloaded files?

 Tuesday, September 29, 2009, 10:49:20 PM, you wrote:


 Jack,

 maven-jetty-plugin belongs to the group org.mortbay.jetty, not
 org.apache.maven.plugins. This makes me suspect that your jetty plugin
 isn't configured properly.

 A minimal jetty plugin configuration would look like this:

 plugin
   groupIdorg.mortbay.jetty/groupId
   artifactIdmaven-jetty-plugin/artifactId
   configuration
 contextPath//contextPath
   /configuration
 /plugin

 Could you please ensure this config under build -  plugin section in
 your pom.xml and retry?

 Cheers, Indrajit



 On 30/09/09 10:09 AM, jlist9 wrote:

 I just tried it on another computer and got exactly the same error when
 running (below). I think something is broken. I checked the mvn output
 in the first run to create helloworld project and didn't see any mentioning
 of jetty...

 D:\Java\liftweb\workmvn jetty:run
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'jetty'.
 [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
 for updates from central
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
 not exist or no valid version c
 ould be found
 [INFO]
 
 [INFO] For more information, run Maven with the -e switch
 [INFO]
 
 [INFO] Total time:   1 second
 [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
 [INFO] Final Memory: 1M/4M
 [INFO]
 

 On Tue, Sep 29, 2009 at 8:59 PM, Naftoli
 Gugenheimnaftoli...@gmail.com   wrote:

 I had such an issue when it was confused about which version
 of Jetty. Is there any more detail? Try running with error details
 enabled (mvn -help should tell you how).

 -
 jlist9jli...@gmail.com   wrote:


 Yes, I have a network connection. Maven downloaded some other
 components and the end result was BUILD SUCCESSFUL...

 On Tue, Sep 29, 2009 at 8:29 PM, Naftoli
 Gugenheimnaftoli...@gmail.com   wrote:

 Do you have a network connection? The idea of maven is that it
 downloads whatever it's missing.

 On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com   wrote:

 Hi,

 I'm new to Lift. I'm trying to follow the getting started guide to
 build the first simple
 demo.helloworld project. At the end of Maven command output I see
 BUILD SUCCESSFUL.
 However, when I run mvn jetty:run, I get error:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
 exist or no valid version could be found

 I wonder if I need to manually install jetty? If so, is there any
 configuration instructions?

 Thanks
 Jack



--~--~-~--~~~---~--~~
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: Error reporting when snippet method not found

2009-09-30 Thread Derek Chen-Becker
Can you open a ticket on this? Lift uses reflection to locate the methods
unless you're using a DispatchSnippet (the preferred way to do it), so we
can probably enumerate all methods on the class and see if there is a method
with the same name but different args or return types when we fail to locate
something.

Derek

On Tue, Sep 29, 2009 at 7:03 AM, Kjetil Valstadsve valstad...@gmail.comwrote:


 Hi, I know I just raved about #liftweb error reporting on Twitter,
 but... now that I found out what was wrong, I still have a gripe about
 it. I am very unforgiving on error reporting logic, but most of the
 time people's error handling is so hopeless that I just throw up my
 arms and emit some mock Italian. When I bother to post this complaint,
 it's because I think lift is doing great and I want to help improve
 it.

 The case occurs when a lift:Foo.bar tag fails to match the bar
 method in Foo. The rendered red box (which is very nice) tells me that
 the method was not found. However, it would be very handy if it
 handled the special case of method found but the signature is wrong.
 As it is, I got the same message when I definitely had the method, per
 se. Before I knew it, I was on a quest to find the outdated class
 file, rebuilding here and there to make sure I had the war file in
 synch with my code.

 In my case, I hadn't specified the return type, and I was mistakenly
 using foreach instead of flatMap inside the method, implicitly giving
 Unit as return type. So lift was completely right, the method could
 not be found. However, this is siding with the compiler against the
 human, if you know what I mean. Also, since you cannot overload a
 method by varying only the return type, it is a pretty safe assumption
 that the mis-typed method is the one the user meant to use, especially
 if it takes the correct argument list, too.

 Kjetil

 


--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

2009-09-30 Thread jlist9

Hello Indrajit and those who replied, thanks for all your help.
Finally I got it working. It probably had something to do with
the proxy in my work environment.

BTW, do you know where maven stores those downloaded files?

Tuesday, September 29, 2009, 10:49:20 PM, you wrote:


 Jack,

 maven-jetty-plugin belongs to the group org.mortbay.jetty, not 
 org.apache.maven.plugins. This makes me suspect that your jetty plugin
 isn't configured properly.

 A minimal jetty plugin configuration would look like this:

plugin
  groupIdorg.mortbay.jetty/groupId
  artifactIdmaven-jetty-plugin/artifactId
  configuration
contextPath//contextPath
  /configuration
/plugin

 Could you please ensure this config under build - plugin section in
 your pom.xml and retry?

 Cheers, Indrajit



 On 30/09/09 10:09 AM, jlist9 wrote:

 I just tried it on another computer and got exactly the same error when
 running (below). I think something is broken. I checked the mvn output
 in the first run to create helloworld project and didn't see any mentioning
 of jetty...

 D:\Java\liftweb\workmvn jetty:run
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'jetty'.
 [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
 for updates from central
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
 not exist or no valid version c
 ould be found
 [INFO]
 
 [INFO] For more information, run Maven with the -e switch
 [INFO]
 
 [INFO] Total time:  1 second
 [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
 [INFO] Final Memory: 1M/4M
 [INFO]
 

 On Tue, Sep 29, 2009 at 8:59 PM, Naftoli
 Gugenheimnaftoli...@gmail.com  wrote:

 I had such an issue when it was confused about which version
 of Jetty. Is there any more detail? Try running with error details
 enabled (mvn -help should tell you how).

 -
 jlist9jli...@gmail.com  wrote:


 Yes, I have a network connection. Maven downloaded some other
 components and the end result was BUILD SUCCESSFUL...

 On Tue, Sep 29, 2009 at 8:29 PM, Naftoli
 Gugenheimnaftoli...@gmail.com  wrote:

 Do you have a network connection? The idea of maven is that it
 downloads whatever it's missing.

 On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com  wrote:

 Hi,

 I'm new to Lift. I'm trying to follow the getting started guide to
 build the first simple
 demo.helloworld project. At the end of Maven command output I see
 BUILD SUCCESSFUL.
 However, when I run mvn jetty:run, I get error:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
 exist or no valid version could be found

 I wonder if I need to manually install jetty? If so, is there any
 configuration instructions?

 Thanks
 Jack



--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

2009-09-30 Thread yk

Right on there, Indrajit. I was playing with liftweb examples from
http://github.com/dpp/liftweb/tree/dpp_wip_actorize and ran into
similar hiccup.

On Sep 30, 1:49 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 Jack,

 maven-jetty-plugin belongs to the group org.mortbay.jetty, not
 org.apache.maven.plugins. This makes me suspect that your jetty plugin
 isn't configured properly.

 A minimal jetty plugin configuration would look like this:

        plugin
          groupIdorg.mortbay.jetty/groupId
          artifactIdmaven-jetty-plugin/artifactId
          configuration
            contextPath//contextPath
          /configuration
        /plugin

 Could you please ensure this config under build - plugin section in
 your pom.xml and retry?

 Cheers, Indrajit

 On 30/09/09 10:09 AM, jlist9 wrote:



  I just tried it on another computer and got exactly the same error when
  running (below). I think something is broken. I checked the mvn output
  in the first run to create helloworld project and didn't see any mentioning
  of jetty...

  D:\Java\liftweb\workmvn jetty:run
  [INFO] Scanning for projects...
  [INFO] Searching repository for plugin with prefix: 'jetty'.
  [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
  for updates from central
  [INFO] 
  
  [ERROR] BUILD ERROR
  [INFO] 
  
  [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
  not exist or no valid version c
  ould be found
  [INFO] 
  
  [INFO] For more information, run Maven with the -e switch
  [INFO] 
  
  [INFO] Total time:  1 second
  [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
  [INFO] Final Memory: 1M/4M
  [INFO] 
  

  On Tue, Sep 29, 2009 at 8:59 PM, Naftoli Gugenheimnaftoli...@gmail.com  
  wrote:

  I had such an issue when it was confused about which version of Jetty. Is 
  there any more detail? Try running with error details enabled (mvn -help 
  should tell you how).

  -
  jlist9jli...@gmail.com  wrote:

  Yes, I have a network connection. Maven downloaded some other
  components and the end result was BUILD SUCCESSFUL...

  On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheimnaftoli...@gmail.com  
  wrote:

  Do you have a network connection? The idea of maven is that it
  downloads whatever it's missing.

  On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com  wrote:

  Hi,

  I'm new to Lift. I'm trying to follow the getting started guide to
  build the first simple
  demo.helloworld project. At the end of Maven command output I see
  BUILD SUCCESSFUL.
  However, when I run mvn jetty:run, I get error:

  The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
  exist or no valid version could be found

  I wonder if I need to manually install jetty? If so, is there any
  configuration instructions?

  Thanks
  Jack

--~--~-~--~~~---~--~~
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: Java 5 support?

2009-09-30 Thread Derek Chen-Becker
OK, here it is:

http://reviewboard.liftweb.net/r/18/

Derek

On Tue, Sep 29, 2009 at 10:10 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:

 I'll take a stab at it. I'm familiar with Dynamic Proxies but I've never
 implemented one before, so this would be a good experience. The only
 drawback is that I think I'm going to have to use reflection on the wrapped
 Statement/PreparedStatement since we won't know ahead of time which JDBC
 version the person is going to want to use. It's going to have ugly guts,
 but hopefully it will remain clean to the user other than the performance
 impact of double dynamic dispatch.

 Derek


 On Tue, Sep 29, 2009 at 9:57 AM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:


 Exactly. Thanks.
 Is that an opton?


 I think DynamicProxy is the way to go.

 Derek -- if you want, I can take a crack at getting to code working.



 -
 Viktor Klangviktor.kl...@gmail.com wrote:

 On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Another option: Java has a way to dynamically implement an interface. I
  forgot what the classes are called. You supply a delegate and you can
  pattern match on which method is being invoked. In Java 5 the
 nonexistent
  method will simply never be invoked, but it won't break code.
 

 Dynamic proxy?


 
  -
  Viktor Klangviktor.kl...@gmail.com wrote:
 
  On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
  wrote:
 
   Can you elaborate on what you mean? I was actually going to look at
 how
   log4jdbc does it and see if I could replicate it.
  
 
  I haven't really tried this, but if you do:
 
  if you implement methods with the correct signatures in the
 LoggedStatement
  and LoggedPreparedStatement, then wrap the invocations to the wrapped
  instances in a try-catch, and if there's an NoSuchMethodException,
 return
  some default value?
 
 
 
  
   Derek
  
   On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang 
 viktor.kl...@gmail.com
  wrote:
  
   Is it possible to have a  bridge trait for the Statement interface?
  
  
   On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   No. I hadn't foreseen this issue, but I understand the importance
 of
  have
   Java 5 support. I'm fine with writing and maintaining multiple
 versions
  of
   the impls for the various versions, but I wonder if there's any
 clean
  way to
   manage this with Maven.
  
   Derek
  
  
   On Mon, Sep 28, 2009 at 4:00 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   Crud.  This just isn't going to be easy, is it?
  
  
   On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   Another issue, which may be more problematic, is that in my case
 I'm
   compiling against the java.sql.Statement interface. If I remove
 the
   troublesome methods so that it compiles for 1.5, it no longer
  compiles for
   1.6 because of the missing methods:
  
   [WARNING]
  
 
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
   error: class LoggedStatement needs to be abstract, since method
  isPoolable
   in trait Statement of type ()Boolean is not defined
   [WARNING] class LoggedStatement(underlying : Statement) extends
   Statement with DBLog {
   [WARNING]   ^
   [WARNING]
  
 
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
   error: class LoggedPreparedStatement needs to be abstract, since
  method
   setNClob in trait PreparedStatement of type
 (Int,java.io.Reader)Unit
  is not
   defined
   [WARNING] class LoggedPreparedStatement (stmt : String,
 underlying :
   PreparedStatement) extends LoggedStatement(underlying) with
   PreparedStatement {
   [WARNING]   ^
  
  
   Derek
  
  
   On Mon, Sep 28, 2009 at 2:29 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
  
  
   On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   The issue (and I may be overthinking this) is that we need 1.5
  class
   libraries to compile against if we want to be able to verify
 that
  the code
   compiles under 1.5. If I, say, delete my JDK 5 install and
 decide
  to
   reinstall it down the road, it's not going to be available
 without
  a
   purchased license.
  
  
   I can stash away a bunch of different copies of the JDK and give
  them
   to you when you need them.
  
   A 32 bit Linux JDK 1.5 should be enough to at least do smoke
 test
   builds with.
  
  
  
   Derek
  
  
  
   On Mon, Sep 28, 2009 at 1:33 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
  
  
   On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   My main concern is that after October 30, Java 5 costs money
 (I'm
   guessing not 

[Lift] Re: Can we deploy lift webapp on Google App Engine?

2009-09-30 Thread justss

Thanks all, you guys are genius!!! I'll soon get started on this...

On Sep 30, 5:16 am, Randinn rand...@gmail.com wrote:
 Tryhttp://github.com/ymnk/lift-gae-jdofor a example, personally I
 don't care for the limited approach GEA gives you, but that's me

 On Sep 30, 9:22 am, Sury surysha...@gmail.com wrote:

  Thanks a lot ;-)

  On 29 Sep 2009, at 06:54 PM, TylerWeir tyler.w...@gmail.com wrote:

   google for lift appengine there a few out there.

   On Sep 29, 11:05 am, justss surysha...@gmail.com wrote:
   Great TylerWeir!!! Thanks a lot... Can you please suggest any kind of
   documentation for this... sorry to be bothering you for that. Any
   tutorial would be of great help.

   Cheers.

   On Sep 29, 2:08 pm, TylerWeir tyler.w...@gmail.com wrote:

  http://lift-example.appspot.com

   There are caveats though, the major one is the lack of actors.

   On Sep 29, 8:53 am, justss surysha...@gmail.com wrote:

   Hi All,

   I'm brand new to Scala and lift framework. I have created a very
   simple hello world web app in lift framework and deployed it
   successfully on tomcat.
   Now I want to know whether I can deploy the same lift application  
   on
   Google app engine or not? I have the war ready, so in I thought  
   that
   it should have been as simple as deploying any war on tomcat or
   websphere!!! But I see it is not ;-(
   Can anyone please guide me as to how I can deploy my mini lift  
   app on
   GAE?

   Thanks in advance.
   A Newbie

--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

2009-09-30 Thread Chris Lewis

Maven stores artifacts in your local repository, which by default is in 
~/.m2/repository.

jli...@gmail.com wrote:
 Hello Indrajit and those who replied, thanks for all your help.
 Finally I got it working. It probably had something to do with
 the proxy in my work environment.
 
 BTW, do you know where maven stores those downloaded files?
 
 Tuesday, September 29, 2009, 10:49:20 PM, you wrote:
 
 
 Jack,
 
 maven-jetty-plugin belongs to the group org.mortbay.jetty, not 
 org.apache.maven.plugins. This makes me suspect that your jetty plugin
 isn't configured properly.
 
 A minimal jetty plugin configuration would look like this:
 
plugin
  groupIdorg.mortbay.jetty/groupId
  artifactIdmaven-jetty-plugin/artifactId
  configuration
contextPath//contextPath
  /configuration
/plugin
 
 Could you please ensure this config under build - plugin section in
 your pom.xml and retry?
 
 Cheers, Indrajit
 
 
 
 On 30/09/09 10:09 AM, jlist9 wrote:
 I just tried it on another computer and got exactly the same error when
 running (below). I think something is broken. I checked the mvn output
 in the first run to create helloworld project and didn't see any mentioning
 of jetty...

 D:\Java\liftweb\workmvn jetty:run
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'jetty'.
 [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
 for updates from central
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
 not exist or no valid version c
 ould be found
 [INFO]
 
 [INFO] For more information, run Maven with the -e switch
 [INFO]
 
 [INFO] Total time:  1 second
 [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
 [INFO] Final Memory: 1M/4M
 [INFO]
 

 On Tue, Sep 29, 2009 at 8:59 PM, Naftoli
 Gugenheimnaftoli...@gmail.com  wrote:
 I had such an issue when it was confused about which version
 of Jetty. Is there any more detail? Try running with error details
 enabled (mvn -help should tell you how).

 -
 jlist9jli...@gmail.com  wrote:


 Yes, I have a network connection. Maven downloaded some other
 components and the end result was BUILD SUCCESSFUL...

 On Tue, Sep 29, 2009 at 8:29 PM, Naftoli
 Gugenheimnaftoli...@gmail.com  wrote:
 Do you have a network connection? The idea of maven is that it
 downloads whatever it's missing.

 On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com  wrote:
 Hi,

 I'm new to Lift. I'm trying to follow the getting started guide to
 build the first simple
 demo.helloworld project. At the end of Maven command output I see
 BUILD SUCCESSFUL.
 However, when I run mvn jetty:run, I get error:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
 exist or no valid version could be found

 I wonder if I need to manually install jetty? If so, is there any
 configuration instructions?

 Thanks
 Jack
 
 
 
  
 

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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Jonas Bonér

2009/9/30 Josh Suereth joshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know lots
 of people that learned scala for actors are the way of the future I
 think we need to push harder.  Hopefully all major projects migrating off
 actors will give EPFL a wake up call?

This is the reason I created Akka, to have a standard platform for
Actors with all the things one need to write production applications.
Akka already have 4 committers and honestly, looking at the pace EPFL
has had with bugfixing, features etc I think they will have a very
hard time keep up with what the market needs. I have unfortunately
given up up the Scala Actors library. I need the things Akka
implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them) are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.  This
 was necessary for JDK 1.4 support.  With JDK 1.5, the java.util.concurrent
 stuff should have been used.  I was led to understand that this change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
 contains fork-join.  The FJ library has a memory retention issue where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.
  See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
  The code has not been materially refactored, which means that even in 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have our
 own Actors (the current Actor library is about 2 days of work on my part and
 the refactoring of Lift to work with the existing Actor library is another 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that you look at Akka.  It's got a better view
 and implementation of Actors than does the standard Scala distribution. Akka
 includes support for distributed actors, etc.
 Hope this helps.


 Best,

 Stuart

 On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  Folks,
 
  Given the continued instability of Scala Actors, I've decided to remove
  them
  from Lift.
 
  Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
  But, you'll also be able to use Akka Actors to power Lift's
  CometActors.
  Specifically, I'm working with Jonas to make sure that we share a
  common
  interface to Actors.
 
  I've gotten Lift nearly completely migrated over to Lift's Actors on
  the
  dpp_wip_actorize branch.
   Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
 
  There will be some breaking changes to your applications.
   Specifically:
 
     - Box will be moved to a new package, net.liftweb.base (this is
  where the
     interface for Actors will live as well)
     - If you make any assumptions about your CometActors being Scala
  Actors
     (e.g., using linking), you will have to rewrite this code
     - Some methods in Lift that currently take Scala Actors as
  parameters
     will take Lift Actors (e.g., ActorPing)
 
  There will be a parallel Maven repository with the new Lift Actor stuff
  in
  it so you will be able to build you apps against the new code before
  the
  official switch-over.
 
  Milestone 6 (which should be out next week) will be based on the
  existing
  Actor model.  After we get feedback from the community about the new
  Actor
  stuff, we will switch -SNAPSHOT over to the new Actor stuff.
 
  Questions, thoughts, or comments?
 
  Thanks,
 
  David
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics





 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics




 




-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org


[Lift] Re: selecting random rows from a table

2009-09-30 Thread Derek Chen-Becker
Hmmm. I have no idea how the distinct could possibly be getting in there
since you're not using it as a QueryParam. Is that the exact code you're
using for the findAll?

Derek

On Tue, Sep 29, 2009 at 1:20 PM, harryh har...@gmail.com wrote:


 Let's say I want 10 random users from a table In SQL I would do this:

 SELECT * FROM users ORDER BY random() LIMIT 10;

 Is there any way (without resorting to a fully raw SQL query) to do
 this with lift-mapper?  I though this would work:

 Users.findAll(OrderBySql(random(), IHaveValidatedThisSQL(harryh,
 2009-9-29)),
  MaxRows(10))

 This does not work, however, because when using SELECT DISTINCT you
 can't ORDER BY something that you aren't selecting (in PostgreSQL at
 least, might be ok in MySQL).

 -harryh
 


--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

2009-09-30 Thread Derek Chen-Becker
If you want it stored somewhere else, you can edit your ~/.m2/settings.xml
file and add the localRepository element. Here's mine:

settings xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/settings-1.0.0.xsd;
  localRepository/home/software/mavenrepo/localRepository
/settings

In my case I do hourly backups of my home directory so I don't want all of
the artifacts there.

Derek

On Wed, Sep 30, 2009 at 5:26 AM, Chris Lewis burningodzi...@gmail.comwrote:


 Maven stores artifacts in your local repository, which by default is in
 ~/.m2/repository.

 jli...@gmail.com wrote:
  Hello Indrajit and those who replied, thanks for all your help.
  Finally I got it working. It probably had something to do with
  the proxy in my work environment.
 
  BTW, do you know where maven stores those downloaded files?
 
  Tuesday, September 29, 2009, 10:49:20 PM, you wrote:
 
 
  Jack,
 
  maven-jetty-plugin belongs to the group org.mortbay.jetty, not
  org.apache.maven.plugins. This makes me suspect that your jetty plugin
  isn't configured properly.
 
  A minimal jetty plugin configuration would look like this:
 
 plugin
   groupIdorg.mortbay.jetty/groupId
   artifactIdmaven-jetty-plugin/artifactId
   configuration
 contextPath//contextPath
   /configuration
 /plugin
 
  Could you please ensure this config under build - plugin section in
  your pom.xml and retry?
 
  Cheers, Indrajit
 
 
 
  On 30/09/09 10:09 AM, jlist9 wrote:
  I just tried it on another computer and got exactly the same error when
  running (below). I think something is broken. I checked the mvn output
  in the first run to create helloworld project and didn't see any
 mentioning
  of jetty...
 
  D:\Java\liftweb\workmvn jetty:run
  [INFO] Scanning for projects...
  [INFO] Searching repository for plugin with prefix: 'jetty'.
  [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
  for updates from central
  [INFO]
 
 
  [ERROR] BUILD ERROR
  [INFO]
 
 
  [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
  not exist or no valid version c
  ould be found
  [INFO]
 
 
  [INFO] For more information, run Maven with the -e switch
  [INFO]
 
 
  [INFO] Total time:  1 second
  [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
  [INFO] Final Memory: 1M/4M
  [INFO]
 
 
 
  On Tue, Sep 29, 2009 at 8:59 PM, Naftoli
  Gugenheimnaftoli...@gmail.com  wrote:
  I had such an issue when it was confused about which version
  of Jetty. Is there any more detail? Try running with error details
  enabled (mvn -help should tell you how).
 
  -
  jlist9jli...@gmail.com  wrote:
 
 
  Yes, I have a network connection. Maven downloaded some other
  components and the end result was BUILD SUCCESSFUL...
 
  On Tue, Sep 29, 2009 at 8:29 PM, Naftoli
  Gugenheimnaftoli...@gmail.com  wrote:
  Do you have a network connection? The idea of maven is that it
  downloads whatever it's missing.
 
  On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com  wrote:
  Hi,
 
  I'm new to Lift. I'm trying to follow the getting started guide to
  build the first simple
  demo.helloworld project. At the end of Maven command output I see
  BUILD SUCCESSFUL.
  However, when I run mvn jetty:run, I get error:
 
  The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
  exist or no valid version could be found
 
  I wonder if I need to manually install jetty? If so, is there any
  configuration instructions?
 
  Thanks
  Jack
 
 
 
  
 

 


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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Derek Chen-Becker
I would vote for naming the new module lift-common and renaming lift-util to
lift-webutil. It does mean some breakage but I think that it's a clearer
naming. lift-util and lift-common are just too close for someone coming in
new, IMHO.

Derek

On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:


 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I know
 lots
  of people that learned scala for actors are the way of the future I
  think we need to push harder.  Hopefully all major projects migrating off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck 
 stuart.roeb...@gmail.com
  wrote:
 
  Apologies if I've missed something obvious but my web search hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of them)
 are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join library.
  This
  was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
  stuff should have been used.  I was led to understand that this change
 was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
  contains fork-join.  The FJ library has a memory retention issue where
 it
  trades memory for non-locking performance and, with many threads in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
   See
 http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even in
 2.8,
  there will be significant potential problems with the Actors.  Those
  potential problems have manifest themselves as real problems in 2.7.x.
  I
  have spent in aggregate nearly 3 weeks of my time since November 2008
  working around the defects in the Actor library.  It's easier to have
 our
  own Actors (the current Actor library is about 2 days of work on my part
 and
  the refactoring of Lift to work with the existing Actor library is
 another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into
 responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a better view
  and implementation of Actors than does the standard Scala distribution.
 Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided to
 remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of Lift's
 Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's Actors on
   the
   dpp_wip_actorize branch.
Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
Specifically:
  
  - Box will be moved to a new package, net.liftweb.base (this is
   where the
  interface for Actors will live as well)
  - If you make any assumptions about your CometActors being Scala
   Actors
  (e.g., using linking), you will have to rewrite this code
  - Some methods in Lift that currently take Scala Actors as
   parameters
  will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift Actor
 stuff
   in
   it so you will be able to build you apps against the new code before
   the
   official switch-over.
  
   Milestone 6 (which should be out next week) will be based on the
   existing
   Actor model.  After we get feedback from the community about the new
   Actor
   stuff, we will switch -SNAPSHOT over to the new Actor stuff.
  
   Questions, thoughts, or comments?
  
   Thanks,
  
   David
  
   --
   Lift, the simply functional web frameworkhttp://liftweb.net
   Beginning Scalahttp://www.apress.com/book/view/1430219890
   Follow 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Stuart Roebuck

As someone coming in new I +1 to Derek’s vote.

Stuart.

On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote:

 I would vote for naming the new module lift-common and renaming lift- 
 util to lift-webutil. It does mean some breakage but I think that  
 it's a clearer naming. lift-util and lift-common are just too close  
 for someone coming in new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I  
 know lots
  of people that learned scala for actors are the way of the  
 future I
  think we need to push harder.  Hopefully all major projects  
 migrating off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com 
 
  wrote:
 
  Apologies if I've missed something obvious but my web search  
 hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process  
 of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of  
 them) are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join  
 library.  This
  was necessary for JDK 1.4 support.  With JDK 1.5, the  
 java.util.concurrent
  stuff should have been used.  I was led to understand that this  
 change was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff  
 still
  contains fork-join.  The FJ library has a memory retention issue  
 where it
  trades memory for non-locking performance and, with many threads  
 in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
   See 
  http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that  
 even in 2.8,
  there will be significant potential problems with the Actors.   
 Those
  potential problems have manifest themselves as real problems in  
 2.7.x.  I
  have spent in aggregate nearly 3 weeks of my time since November  
 2008
  working around the defects in the Actor library.  It's easier to  
 have our
  own Actors (the current Actor library is about 2 days of work on  
 my part and
  the refactoring of Lift to work with the existing Actor library  
 is another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into  
 responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a  
 better view
  and implementation of Actors than does the standard Scala  
 distribution. Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided  
 to remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of  
 Lift's Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we  
 share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's  
 Actors on
   the
   dpp_wip_actorize branch.
Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
Specifically:
  
  - Box will be moved to a new package, net.liftweb.base  
 (this is
   where the
  interface for Actors will live as well)
  - If you make any assumptions about your CometActors being  
 Scala
   Actors
  (e.g., using linking), you will have to rewrite this code
  - Some methods in Lift that currently take Scala Actors as
   parameters
  will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift  
 Actor stuff
   in
   it so you will be able to build you apps against the new code  
 before
   the
   official switch-over.
  
   Milestone 6 (which should be out next week) will be based on the
   existing
   Actor model.  After we get feedback from the community about  
 the new
   Actor
   stuff, we will switch -SNAPSHOT over to the new Actor stuff.
  
   

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Timothy Perrett

Sounds like a fair trade off +1

On 30 Sep 2009, at 14:15, Stuart Roebuck wrote:


 As someone coming in new I +1 to Derek’s vote.

 Stuart.

 On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote:

 I would vote for naming the new module lift-common and renaming lift-
 util to lift-webutil. It does mean some breakage but I think that
 it's a clearer naming. lift-util and lift-common are just too close
 for someone coming in new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com  
 wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I
 know lots
 of people that learned scala for actors are the way of the
 future I
 think we need to push harder.  Hopefully all major projects
 migrating off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com

 wrote:

 Apologies if I've missed something obvious but my web search
 hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process
 of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of
 them) are:

 Scala Actors use a custom version of Doug Leah's Fork/Join
 library.  This
 was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
 stuff should have been used.  I was led to understand that this
 change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff
 still
 contains fork-join.  The FJ library has a memory retention issue
 where it
 trades memory for non-locking performance and, with many threads
 in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.
 See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
 The code has not been materially refactored, which means that
 even in 2.8,
 there will be significant potential problems with the Actors.
 Those
 potential problems have manifest themselves as real problems in
 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November
 2008
 working around the defects in the Actor library.  It's easier to
 have our
 own Actors (the current Actor library is about 2 days of work on
 my part and
 the refactoring of Lift to work with the existing Actor library
 is another 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into
 responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that you look at Akka.  It's got a
 better view
 and implementation of Actors than does the standard Scala
 distribution. Akka
 includes support for distributed actors, etc.
 Hope this helps.


 Best,

 Stuart

 On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
 Folks,

 Given the continued instability of Scala Actors, I've decided
 to remove
 them
 from Lift.

 Specifically, I'm migrating CometActors to sit on top of
 Lift's Actors.
 But, you'll also be able to use Akka Actors to power Lift's
 CometActors.
 Specifically, I'm working with Jonas to make sure that we
 share a
 common
 interface to Actors.

 I've gotten Lift nearly completely migrated over to Lift's
 Actors on
 the
 dpp_wip_actorize branch.
 Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize

 There will be some breaking changes to your applications.
 Specifically:

   - Box will be moved to a new package, net.liftweb.base
 (this is
 where the
   interface for Actors will live as well)
   - If you make any assumptions about your CometActors being
 Scala
 Actors
   (e.g., using linking), you will have to rewrite this code
   - Some methods in Lift that currently take Scala Actors as
 parameters
   will take Lift Actors (e.g., ActorPing)

 There will be a parallel Maven repository with the new Lift
 Actor stuff
 in
 it so you will be able to build you apps against the new code
 before
 the
 official switch-over.

 Milestone 6 (which should be out next week) will be based on the
 existing
 Actor model.  After we get feedback from the community about
 the new
 Actor
 stuff, we will switch -SNAPSHOT over to the new Actor stuff.

 Questions, thoughts, or comments?

 Thanks,

 David

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning 

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread Kevin Wright

I thought there were issues here because anything starting lift: gets
executed as a snippet.

I'm still for an eval: prefix, as these proposals all relate to how a
page is evaluated.



On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:

 lift is already a reserved prefix for snippets. So I'd stay with
 simply lift prefix for these attributes as well.

 Br's,
 Marius

 On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 So what is your proposal? Am I interpreting you correctly that you are for a 
 prefix of 'lift'? And it will be a reserved suffix?

 -

 marius d.marius.dan...@gmail.com wrote:

 I realize that I may be a little late here but I do have second
 thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
 understand that these attributes are not really snippets or built is
 snippets but is this an enough reason to introduce a new prefix?
 Personally I don't think so. Historically lift reserved prefix names
 were heavily debated and argued and this is a little sensitive area.

 But the good news is that I may be the only one feeling this way about
 this and everyone else likes it so I'm just a negligible minority.

 Br's,
 Marius

 On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
  naftoli...@gmail.comwrote:

   If you like the idea of having them all as attributes but don't like the
   idea of using a single attribute ('xx:eager_eval=true 
   xx:parallel=true'
   rather than 'xx:eval=eager parallel' as I suggested, where xx is the
   prefix to be chosen) then maybe the prefix should be 'eval'.

  I've changed the code to:
  liftx:eager_eval=true
  liftx:par=true | liftx:parallel=true

  The reasons for not combining them:

     - They are evaluated in different parts of the code, thus eager/parallel
     doesn't make sense from a code path perspective
     - I am reserving the value of liftx:par for future implementation to
     allow farming the snippet evaluation to another mechanism.  Right now, 
  it's
     hard-coded to use LiftActors.  I can see a time when it would work with 
  Akka
     actors or some other parallelization mechanism

   As far as ajax evaluation I'm not sure I'm understanding. Could you 
   show
   me what you're thinking?
   If I have a snippet
   lift:MySnippet /
   what would be the syntax to have it inserted via ajax?

  lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
  --
    lift:MySnippet/
  /lift:Ajax

   -
   Ross Mellgrendri...@gmail.com wrote:

   My 2 cents,

   I'm not sure I'm a fan of do: namespace, though I agree it would be
   nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?

   -Ross

   On Sep 24, 2009, at 12:46 PM, David Pollak wrote:

On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim 
   naftoli...@gmail.com
 wrote:

What do you mean by as a normal snippet?

The parallel snippet processing is implemented deep inside
LiftSession.  It's not a snippet.  All the lift:xxx/ tags, even
those with defaults built into Lift, are implemented as snippets and
are invoked with normal snippet invocation mechanisms.

That you will nest your snippet inside a special snippet?

There is no special snippet.  I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.

To me it seems worthwhile to have a consistency between the two
syntax-wise, since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.

Anything that's prefixed with lift: is a snippet.  I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.

-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
   naftoli...@gmail.com
wrote:

 A snippet attribute can be invoked with something other than
 lift:snippet=Class.method? There's a short syntax? What is it?

There may be a short syntax (e.g., lift:Class.method) in the future.

 What was used for the feature that inserts a snippet
asynchronously via
 Ajax?

That feature isn't done yet, but that feature is likely to be done
as a
normal snippet.

 My concern is that as more features are thought up and added they
shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more
verbose
 parallel because otherwise it's not obvious what it does. If
it's prefixed
 with lift: at least you know it's a lift tag and 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Heiko Seeberger
+1

2009/9/30 Derek Chen-Becker dchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek


 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:


 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I know
 lots
  of people that learned scala for actors are the way of the future
 I
  think we need to push harder.  Hopefully all major projects migrating
 off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck 
 stuart.roeb...@gmail.com
  wrote:
 
  Apologies if I've missed something obvious but my web search hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of them)
 are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join library.
  This
  was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
  stuff should have been used.  I was led to understand that this change
 was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
  contains fork-join.  The FJ library has a memory retention issue where
 it
  trades memory for non-locking performance and, with many threads in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
   See
 http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even in
 2.8,
  there will be significant potential problems with the Actors.  Those
  potential problems have manifest themselves as real problems in 2.7.x.
  I
  have spent in aggregate nearly 3 weeks of my time since November 2008
  working around the defects in the Actor library.  It's easier to have
 our
  own Actors (the current Actor library is about 2 days of work on my
 part and
  the refactoring of Lift to work with the existing Actor library is
 another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into
 responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a better view
  and implementation of Actors than does the standard Scala distribution.
 Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided to
 remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of Lift's
 Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's Actors on
   the
   dpp_wip_actorize branch.
Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
Specifically:
  
  - Box will be moved to a new package, net.liftweb.base (this is
   where the
  interface for Actors will live as well)
  - If you make any assumptions about your CometActors being Scala
   Actors
  (e.g., using linking), you will have to rewrite this code
  - Some methods in Lift that currently take Scala Actors as
   parameters
  will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift Actor
 stuff
   in
   it so you will be able to build you apps against the new code before
   the
   official switch-over.
  
   Milestone 6 (which should be out next week) will be based on the
   existing
   Actor model.  After we get feedback from the community about the new
   Actor
   stuff, we will switch -SNAPSHOT over to the new Actor stuff.
  
   Questions, thoughts, or comments?
  
   Thanks,
  
   David
  
   --
   Lift, the simply functional web frameworkhttp://liftweb.net
   

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Viktor Klang
Aye
+1

On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger 
heiko.seeber...@googlemail.com wrote:

 +1

 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek


 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:


 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I know
 lots
  of people that learned scala for actors are the way of the future
 I
  think we need to push harder.  Hopefully all major projects migrating
 off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck 
 stuart.roeb...@gmail.com
  wrote:
 
  Apologies if I've missed something obvious but my web search hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of them)
 are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join library.
  This
  was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
  stuff should have been used.  I was led to understand that this change
 was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
  contains fork-join.  The FJ library has a memory retention issue where
 it
  trades memory for non-locking performance and, with many threads in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
   See
 http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even in
 2.8,
  there will be significant potential problems with the Actors.  Those
  potential problems have manifest themselves as real problems in 2.7.x.
  I
  have spent in aggregate nearly 3 weeks of my time since November 2008
  working around the defects in the Actor library.  It's easier to have
 our
  own Actors (the current Actor library is about 2 days of work on my
 part and
  the refactoring of Lift to work with the existing Actor library is
 another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into
 responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a better
 view
  and implementation of Actors than does the standard Scala
 distribution. Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided to
 remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of Lift's
 Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's Actors
 on
   the
   dpp_wip_actorize branch.
Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
Specifically:
  
  - Box will be moved to a new package, net.liftweb.base (this is
   where the
  interface for Actors will live as well)
  - If you make any assumptions about your CometActors being Scala
   Actors
  (e.g., using linking), you will have to rewrite this code
  - Some methods in Lift that currently take Scala Actors as
   parameters
  will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift Actor
 stuff
   in
   it so you will be able to build you apps against the new code
 before
   the
   official switch-over.
  
   Milestone 6 (which should be out next week) will be based on the
   existing
   Actor model.  After we get feedback from the community about the
 new
   Actor
   stuff, we will switch -SNAPSHOT over to the new Actor stuff.
  
   Questions, thoughts, or comments?
  

[Lift] Best way to create master/detail with CRUDify?

2009-09-30 Thread Jeppe Nejsum Madsen

Hi,

I need to create some master/detail crud screens and was thinking if the
existing CRUDify trait can be massaged into doing the right thing.

Basically, when navigating to e.g. orders/edit/1 I'm editing order with
id 1. On this screen I need to list order lines for this order,
ie. order/1/orderlines/list. I also need to do various actions on orderlines
ie order/1/orderlines/edit/42

Any good suggestions. The first level (order) is easily handled by
CRUDify, but was wondering if somebody have already created a
master/detail trait.

/Jeppe

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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread David Bernard

my salt
(I don't like lift-common, common of what ? )
If you don't want to move actors, box... to lift-util (xml
utilities,... aren't only for web)
As actor and box are language extension, I suggest lift-lang,
lift-langplus, liftx, lift-scalax

 ;)

/davidB

On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote:
 Aye
 +1

 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
 heiko.seeber...@googlemail.com wrote:

 +1

 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I know
  lots
  of people that learned scala for actors are the way of the
  future I
  think we need to push harder.  Hopefully all major projects migrating
  off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck
  stuart.roeb...@gmail.com
  wrote:
 
  Apologies if I've missed something obvious but my web search hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of them)
  are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join library.
   This
  was necessary for JDK 1.4 support.  With JDK 1.5, the
  java.util.concurrent
  stuff should have been used.  I was led to understand that this
  change was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff
  still
  contains fork-join.  The FJ library has a memory retention issue
  where it
  trades memory for non-locking performance and, with many threads in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
 
   See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even
  in 2.8,
  there will be significant potential problems with the Actors.  Those
  potential problems have manifest themselves as real problems in
  2.7.x.  I
  have spent in aggregate nearly 3 weeks of my time since November 2008
  working around the defects in the Actor library.  It's easier to have
  our
  own Actors (the current Actor library is about 2 days of work on my
  part and
  the refactoring of Lift to work with the existing Actor library is
  another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into
  responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a better
  view
  and implementation of Actors than does the standard Scala
  distribution. Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided to
   remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of Lift's
   Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's Actors
   on
   the
   dpp_wip_actorize branch.
    Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
    Specifically:
  
      - Box will be moved to a new package, net.liftweb.base (this is
   where the
      interface for Actors will live as well)
      - If you make any assumptions about your CometActors being
   Scala
   Actors
      (e.g., using linking), you will have to rewrite this code
      - Some methods in Lift that currently take Scala Actors as
   parameters
      will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift Actor
   stuff
   in
   it so 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread David Bernard

But my opinion == 0, I not a lift's user, but I see lot of case where
some lift lib could be used without working on a webapp.

On Wed, Sep 30, 2009 at 15:37, David Bernard david.bernard...@gmail.com wrote:
 my salt
 (I don't like lift-common, common of what ? )
 If you don't want to move actors, box... to lift-util (xml
 utilities,... aren't only for web)
 As actor and box are language extension, I suggest lift-lang,
 lift-langplus, liftx, lift-scalax

  ;)

 /davidB

 On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote:
 Aye
 +1

 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
 heiko.seeber...@googlemail.com wrote:

 +1

 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I know
  lots
  of people that learned scala for actors are the way of the
  future I
  think we need to push harder.  Hopefully all major projects migrating
  off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck
  stuart.roeb...@gmail.com
  wrote:
 
  Apologies if I've missed something obvious but my web search hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of them)
  are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join library.
   This
  was necessary for JDK 1.4 support.  With JDK 1.5, the
  java.util.concurrent
  stuff should have been used.  I was led to understand that this
  change was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff
  still
  contains fork-join.  The FJ library has a memory retention issue
  where it
  trades memory for non-locking performance and, with many threads in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
 
   See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even
  in 2.8,
  there will be significant potential problems with the Actors.  Those
  potential problems have manifest themselves as real problems in
  2.7.x.  I
  have spent in aggregate nearly 3 weeks of my time since November 2008
  working around the defects in the Actor library.  It's easier to have
  our
  own Actors (the current Actor library is about 2 days of work on my
  part and
  the refactoring of Lift to work with the existing Actor library is
  another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into
  responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a better
  view
  and implementation of Actors than does the standard Scala
  distribution. Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided to
   remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of Lift's
   Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's Actors
   on
   the
   dpp_wip_actorize branch.
    Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
    Specifically:
  
      - Box will be moved to a new package, net.liftweb.base (this is
   where the
      interface for Actors will live as well)
      - If you make any assumptions about your CometActors being
   Scala
   Actors
      (e.g., using linking), you will have to rewrite this code
      - 

[Lift] Re: Question about the Getting Started Guide

2009-09-30 Thread Indrajit Raychaudhuri

Derek,

Very nice trick indeed!

Cheers, Indrajit


On 30/09/09 6:28 PM, Derek Chen-Becker wrote:
 If you want it stored somewhere else, you can edit your
 ~/.m2/settings.xml file and add the localRepository element. Here's mine:

 settings xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/settings-1.0.0.xsd;
 localRepository/home/software/mavenrepo/localRepository
 /settings

 In my case I do hourly backups of my home directory so I don't want all
 of the artifacts there.

 Derek


--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

2009-09-30 Thread Derek Chen-Becker
I learned it the hard way when my incremental backups went from 1-2MB to
700MB :P

On Wed, Sep 30, 2009 at 7:44 AM, Indrajit Raychaudhuri
indraj...@gmail.comwrote:


 Derek,

 Very nice trick indeed!

 Cheers, Indrajit


 On 30/09/09 6:28 PM, Derek Chen-Becker wrote:
  If you want it stored somewhere else, you can edit your
  ~/.m2/settings.xml file and add the localRepository element. Here's mine:
 
  settings xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/settings-1.0.0.xsd;
  localRepository/home/software/mavenrepo/localRepository
  /settings
 
  In my case I do hourly backups of my home directory so I don't want all
  of the artifacts there.
 
  Derek
 

 


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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Indrajit Raychaudhuri

Nice to see the intent to withstand little breakage for the right reason!

I am +0 on lift-common. It possibly doesn't mean much, but the only 
reason I proposed it as an option is because most people with exposure 
to Java projects have encountered jakarta-common and in some sense have 
*-common hardwired in their brain and can relate to.

Personally, I am -1 on liftx and lift-scalax. They either don't conform 
to naming convention or aren't unambiguous enough.

+1 for lift-util to lift-webutil.

Cheers, Indrajit

NB:
0. Let's use one conversation trail to converge on the name(s) please. 
Reduce duplications ;-)

1. It's imperative that the package for the respective classes would 
have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar 
would be utterly confusing IMHO.

2. Once the package names are through, the Lift book would need to be 
updated too.


On 30/09/09 7:09 PM, David Bernard wrote:

 But my opinion == 0, I not a lift's user, but I see lot of case where
 some lift lib could be used without working on a webapp.

 On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com  
 wrote:
 my salt
 (I don't like lift-common, common of what ? )
 If you don't want to move actors, box... to lift-util (xml
 utilities,... aren't only for web)
 As actor and box are language extension, I suggest lift-lang,
 lift-langplus, liftx, lift-scalax

   ;)

 /davidB

 On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com  wrote:
 Aye
 +1

 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
 heiko.seeber...@googlemail.com  wrote:

 +1

 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a 
 clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com  wrote:

 2009/9/30 Josh Suerethjoshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know
 lots
 of people that learned scala for actors are the way of the
 future I
 think we need to push harder.  Hopefully all major projects migrating
 off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com  wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck
 stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them)
 are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.
   This
 was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
 stuff should have been used.  I was led to understand that this
 change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff
 still
 contains fork-join.  The FJ library has a memory retention issue
 where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.

   See 
 http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even
 in 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in
 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have
 our
 own Actors (the current Actor library is about 2 days of work on my
 part and
 the refactoring of Lift to work with the existing Actor library is
 another 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into
 responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that you look at Akka.  It's got a better
 view
 and implementation of Actors than does the standard Scala
 distribution. Akka
 includes support for distributed actors, etc.
 Hope this helps.


 Best,

 Stuart

 On Sep 29, 3:30 am, David Pollakfeeder.of.the.be...@gmail.com
 wrote:
 Folks,

 Given the continued instability of Scala 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Naftoli Gugenheim

lift-webutil is very a good name. It conveys exactly what the module is.
But why not leave non-web-related functionality in lift-util? lift-util vs. 
lift-webutil seems very unambiguous.


-
Indrajit Raychaudhuriindraj...@gmail.com wrote:


Nice to see the intent to withstand little breakage for the right reason!

I am +0 on lift-common. It possibly doesn't mean much, but the only 
reason I proposed it as an option is because most people with exposure 
to Java projects have encountered jakarta-common and in some sense have 
*-common hardwired in their brain and can relate to.

Personally, I am -1 on liftx and lift-scalax. They either don't conform 
to naming convention or aren't unambiguous enough.

+1 for lift-util to lift-webutil.

Cheers, Indrajit

NB:
0. Let's use one conversation trail to converge on the name(s) please. 
Reduce duplications ;-)

1. It's imperative that the package for the respective classes would 
have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar 
would be utterly confusing IMHO.

2. Once the package names are through, the Lift book would need to be 
updated too.


On 30/09/09 7:09 PM, David Bernard wrote:

 But my opinion == 0, I not a lift's user, but I see lot of case where
 some lift lib could be used without working on a webapp.

 On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com  
 wrote:
 my salt
 (I don't like lift-common, common of what ? )
 If you don't want to move actors, box... to lift-util (xml
 utilities,... aren't only for web)
 As actor and box are language extension, I suggest lift-lang,
 lift-langplus, liftx, lift-scalax

   ;)

 /davidB

 On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com  wrote:
 Aye
 +1

 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger
 heiko.seeber...@googlemail.com  wrote:

 +1

 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com

 I would vote for naming the new module lift-common and renaming lift-util
 to lift-webutil. It does mean some breakage but I think that it's a 
 clearer
 naming. lift-util and lift-common are just too close for someone coming in
 new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com  wrote:

 2009/9/30 Josh Suerethjoshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know
 lots
 of people that learned scala for actors are the way of the
 future I
 think we need to push harder.  Hopefully all major projects migrating
 off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com  wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck
 stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them)
 are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.
   This
 was necessary for JDK 1.4 support.  With JDK 1.5, the
 java.util.concurrent
 stuff should have been used.  I was led to understand that this
 change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff
 still
 contains fork-join.  The FJ library has a memory retention issue
 where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.

   See 
 http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that even
 in 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in
 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have
 our
 own Actors (the current Actor library is about 2 days of work on my
 part and
 the refactoring of Lift to work with the existing Actor library is
 another 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into
 responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that you look at Akka.  It's got a better
 view
 and 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread martin

About actors in Scala 2.8:

 . they have been refactored substantially compared to what's in the
   2.7.x branch
 . Philipp has sent mails about this to scala-internals (05/31)
 . Philipp has invited DPP to look at the refactorings in 2.8 (07/21)
to which
   he responded positively.
 . The ForkJoinPool in 2.8 is completely different from FJTask in
   2.7.5; it's the version that's going into JDK7. It has been
   battle-tested and should not suffer from any memory leaks.

The reason why Scala actors use the FJ framework is performance, in
particular on multi-core hardware. So we do not think it's a good idea
to go back to java.util.concurrent, except maybe for applications with
very specialized demands.

We think the main problem was that lift depends on Scala 2.7.x, and
that the actor refactorings have not gone into the 2.7.x branch. The
result is that people have not noticed the changes. For example, most
of the issues that Erik raises in his blog post no longer apply to
Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken
much longer than we have foreseen, because some of the problems were
harder than initially thought. We are sorry to have left the 2.7
branch relatively unattended for so long. It's difficult for us,
though, to provide the resources to support two diverging branches in
parallel. More community support with backports etc could help.

To fix the concrete issue at hand, we replaced FJTask with (a backport
of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch,
to be released as 2.7.7. That takes care of the memory leaks in
FJTask.

Now to the larger picture. We are not at all wedded to Scala actors
here; after all it's just a library. If there are others which fulfill
some needs better, great! But we have to be honest to avoid confusion.
One of the main differences between Scala actors and lift actors and
Akka seems to be that only Scala actors provide nested receives, so
only Scala actors really let you avoid an inversion of control. This
is a feature which complicates the implementation considerably, and
that's what all our main results are about. You might not care about
this particular feature in your code, and consequently you might
choose a different abstraction. But calling that abstraction simply
`actors' causes unnecessary confusion, in our opinion. And that's not
good for the goal of convincing people that actors are a useful
concurrency abstraction. So, nothing against lift actors and Akka, but
we need to be precise about the tradeoffs. Maybe call them `flat
actors' or something like that.

Martin and Philipp

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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Bill Venners

Hi Jonas,

Can you list what the things Akka implements now are that Scala
actors don't have?

Thanks.

Bill

On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know lots
 of people that learned scala for actors are the way of the future I
 think we need to push harder.  Hopefully all major projects migrating off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them) are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.  This
 was necessary for JDK 1.4 support.  With JDK 1.5, the java.util.concurrent
 stuff should have been used.  I was led to understand that this change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
 contains fork-join.  The FJ library has a memory retention issue where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.
  See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
  The code has not been materially refactored, which means that even in 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have our
 own Actors (the current Actor library is about 2 days of work on my part and
 the refactoring of Lift to work with the existing Actor library is another 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that you look at Akka.  It's got a better view
 and implementation of Actors than does the standard Scala distribution. Akka
 includes support for distributed actors, etc.
 Hope this helps.


 Best,

 Stuart

 On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  Folks,
 
  Given the continued instability of Scala Actors, I've decided to remove
  them
  from Lift.
 
  Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
  But, you'll also be able to use Akka Actors to power Lift's
  CometActors.
  Specifically, I'm working with Jonas to make sure that we share a
  common
  interface to Actors.
 
  I've gotten Lift nearly completely migrated over to Lift's Actors on
  the
  dpp_wip_actorize branch.
   Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
 
  There will be some breaking changes to your applications.
   Specifically:
 
     - Box will be moved to a new package, net.liftweb.base (this is
  where the
     interface for Actors will live as well)
     - If you make any assumptions about your CometActors being Scala
  Actors
     (e.g., using linking), you will have to rewrite this code
     - Some methods in Lift that currently take Scala Actors as
  parameters
     will take Lift Actors (e.g., ActorPing)
 
  There will be a parallel Maven repository with the new Lift Actor stuff
  in
  it so you will be able to build you apps against the new code before
  the
  official switch-over.
 
  Milestone 6 (which should be out next week) will be based on the
  existing
  Actor model.  After we get feedback from the community about the new
  Actor
  stuff, we will switch -SNAPSHOT over to the new Actor stuff.
 
  Questions, thoughts, or comments?
 
  Thanks,
 
  David
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics





 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics




 




 --
 Jonas Bonér

 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Jonas Bonér

Hi Bill.

Here is a list of the things that Akka currently does (and that are
not in Scala Actors) and what I see needed in a production actor based
system (not all in all projects though).

Transactors:
Marriage of Actors and STM. Allows, ACI (Atomic, Consistent 
Isolated) compositional message flows. IMO the best of both worlds,
since just actors is not sufficient in many scenarios. STM is based on
persistent datastructures and managed references.

Supervisor hierarchies:
Declarative and programatic API with same API and semantics as in
Erlang. This is IMO the most interesting part of Actors and is
fantastic to build fault-tolerant systems. This was the goal of Scala
OTP, but I have rewritten it and is much better now.

Pluggable message dispatchers:
Thread-based, event-based, single-thread-event-based. With DSL for
building and configuring up thread-pools etc. Even concurrent mode
which abandons the Actor model contract for best performance (if
needed). This exists to some extent in Scala Actors, but not as open
as easily configured.

Pluggable messagequeue implementation:
Choose between LinkedBlockingQueue, SynchronousQueue,
ArrayBlockingQueue. Bounded or unbounded, with different back-off
strategies and more.

NIO-based remote actors:
High-performance nio impl based on Netty and Protobuf. Actor
supervision (linking) for fault-tolerance works across remote machines
as expected.

Java API:
Through Active Objects. Use plain POJOs which are turned into
asynchronous non-blocking “actors” using bytecode munging.

RESTful Actors:
Expose Actors as restful services through JAX-RS.

Persistent Actors:
Pluggable persistence. Currently supporting Cassandra and MongoDB.
More to come. Works with the STM to create ACI *D* e.g. durable,
persistent actors. Persistent messagequeue is on its way.

Monitoring and mangament:
Through JMX and REST. Allows you to monitor and manage all moving
parts including internals such as messagequeues, dispatchers etc.

Can be used as a standalone kernel or as a library in webapps etc.

That pretty much sums it up.

/Jonas

2009/9/30 Bill Venners b...@artima.com:

 Hi Jonas,

 Can you list what the things Akka implements now are that Scala
 actors don't have?

 Thanks.

 Bill

 On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know lots
 of people that learned scala for actors are the way of the future I
 think we need to push harder.  Hopefully all major projects migrating off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them) are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.  This
 was necessary for JDK 1.4 support.  With JDK 1.5, the java.util.concurrent
 stuff should have been used.  I was led to understand that this change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
 contains fork-join.  The FJ library has a memory retention issue where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.
  See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
  The code has not been materially refactored, which means that even in 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have our
 own Actors (the current Actor library is about 2 days of work on my part 
 and
 the refactoring of Lift to work with the existing Actor library is another 
 2
 days of work.)
 EPFL has been generally slow to respond to bug reports.  I am very
 frustrated and quite frankly tired of having to cajole EPFL into responding
 to defects in one of the premier Scala libraries.

 I would strongly suggest that 

[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Jonas Bonér

Also, its pretty well documented.
Read more here: http://akkasource.org/
We need feedback so please let me know what you think.

2009/9/30 Jonas Bonér jbo...@gmail.com:
 Hi Bill.

 Here is a list of the things that Akka currently does (and that are
 not in Scala Actors) and what I see needed in a production actor based
 system (not all in all projects though).

 Transactors:
 Marriage of Actors and STM. Allows, ACI (Atomic, Consistent 
 Isolated) compositional message flows. IMO the best of both worlds,
 since just actors is not sufficient in many scenarios. STM is based on
 persistent datastructures and managed references.

 Supervisor hierarchies:
 Declarative and programatic API with same API and semantics as in
 Erlang. This is IMO the most interesting part of Actors and is
 fantastic to build fault-tolerant systems. This was the goal of Scala
 OTP, but I have rewritten it and is much better now.

 Pluggable message dispatchers:
 Thread-based, event-based, single-thread-event-based. With DSL for
 building and configuring up thread-pools etc. Even concurrent mode
 which abandons the Actor model contract for best performance (if
 needed). This exists to some extent in Scala Actors, but not as open
 as easily configured.

 Pluggable messagequeue implementation:
 Choose between LinkedBlockingQueue, SynchronousQueue,
 ArrayBlockingQueue. Bounded or unbounded, with different back-off
 strategies and more.

 NIO-based remote actors:
 High-performance nio impl based on Netty and Protobuf. Actor
 supervision (linking) for fault-tolerance works across remote machines
 as expected.

 Java API:
 Through Active Objects. Use plain POJOs which are turned into
 asynchronous non-blocking “actors” using bytecode munging.

 RESTful Actors:
 Expose Actors as restful services through JAX-RS.

 Persistent Actors:
 Pluggable persistence. Currently supporting Cassandra and MongoDB.
 More to come. Works with the STM to create ACI *D* e.g. durable,
 persistent actors. Persistent messagequeue is on its way.

 Monitoring and mangament:
 Through JMX and REST. Allows you to monitor and manage all moving
 parts including internals such as messagequeues, dispatchers etc.

 Can be used as a standalone kernel or as a library in webapps etc.

 That pretty much sums it up.

 /Jonas

 2009/9/30 Bill Venners b...@artima.com:

 Hi Jonas,

 Can you list what the things Akka implements now are that Scala
 actors don't have?

 Thanks.

 Bill

 On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
 As much as I agree with your decision, it just makes me sad.   I know lots
 of people that learned scala for actors are the way of the future I
 think we need to push harder.  Hopefully all major projects migrating off
 actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.


 - Josh

 On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:


 On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com
 wrote:

 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 The issues (with the Scala Actors in general and Lift's use of them) are:

 Scala Actors use a custom version of Doug Leah's Fork/Join library.  This
 was necessary for JDK 1.4 support.  With JDK 1.5, the java.util.concurrent
 stuff should have been used.  I was led to understand that this change was
 made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
 contains fork-join.  The FJ library has a memory retention issue where it
 trades memory for non-locking performance and, with many threads in a
 thread-pool, this leads to out of memory issues.
 The Scala Actor code is very brittle.
  See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
  The code has not been materially refactored, which means that even in 
 2.8,
 there will be significant potential problems with the Actors.  Those
 potential problems have manifest themselves as real problems in 2.7.x.  I
 have spent in aggregate nearly 3 weeks of my time since November 2008
 working around the defects in the Actor library.  It's easier to have our
 own Actors (the current Actor library is about 2 days of work on my part 
 and
 the refactoring of Lift to work with the existing Actor library is 
 another 2
 days of work.)
 EPFL has been 

[Lift] Re: Help with using JSExp and JsCmd traits

2009-09-30 Thread David Pollak
On Tue, Sep 29, 2009 at 1:22 PM, glenn gl...@exmbly.com wrote:


 I'd like to converting the following

 JsRaw(function() $('#item-save').html(this.id + ' was
 toggled'))

 into something more object-oriented, using JQuery support functions in
 Lift.

 I've tried various combiniations, including this

 AnonFunc(JqId(item-save)  JqEmptyAfter(div{JsRaw(this.id)} was
 toggled/div))


AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id} was
toggled/div))

No reason to promote this.id into some JavaScript thing.  It's part of the
XML literal.  The XML literal is generated server-side as part of the
JavaScript function.




 but nothing seems to work. It just treats this.id as ordinary text,
 not as a Javascript variable.

 Any ideas would be appreciated.

 Glenn
 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread Jonas Bonér

Hi Martin and Philipp.

Thanks for your email. What you are saying sounds great. I love Scala
Actors and I know its an important thing that brings people over to
Scala.

I hope that I didn't offend you. You have done amazing things with and
for Scala. I really respect you guys.

But I saw and felt the need for something like Akka and went away and build it.

What you say about the trade-offs in Actor expressiveness is really
true. I (and David I think) have not seen that much need for nested
receive/react and therefore I have not included in the impl but rather
focussing on other things that I find more important.

This articles sums it up pretty well:
http://erikengbrecht.blogspot.com/2009/06/pondering-actor-design-trades.html

Looking forward to 2.8 and the new actor impl.

/Jonas




2009/9/30 martin oder...@gmail.com:

 About actors in Scala 2.8:

  . they have been refactored substantially compared to what's in the
   2.7.x branch
  . Philipp has sent mails about this to scala-internals (05/31)
  . Philipp has invited DPP to look at the refactorings in 2.8 (07/21)
 to which
   he responded positively.
  . The ForkJoinPool in 2.8 is completely different from FJTask in
   2.7.5; it's the version that's going into JDK7. It has been
   battle-tested and should not suffer from any memory leaks.

 The reason why Scala actors use the FJ framework is performance, in
 particular on multi-core hardware. So we do not think it's a good idea
 to go back to java.util.concurrent, except maybe for applications with
 very specialized demands.

 We think the main problem was that lift depends on Scala 2.7.x, and
 that the actor refactorings have not gone into the 2.7.x branch. The
 result is that people have not noticed the changes. For example, most
 of the issues that Erik raises in his blog post no longer apply to
 Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken
 much longer than we have foreseen, because some of the problems were
 harder than initially thought. We are sorry to have left the 2.7
 branch relatively unattended for so long. It's difficult for us,
 though, to provide the resources to support two diverging branches in
 parallel. More community support with backports etc could help.

 To fix the concrete issue at hand, we replaced FJTask with (a backport
 of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch,
 to be released as 2.7.7. That takes care of the memory leaks in
 FJTask.

 Now to the larger picture. We are not at all wedded to Scala actors
 here; after all it's just a library. If there are others which fulfill
 some needs better, great! But we have to be honest to avoid confusion.
 One of the main differences between Scala actors and lift actors and
 Akka seems to be that only Scala actors provide nested receives, so
 only Scala actors really let you avoid an inversion of control. This
 is a feature which complicates the implementation considerably, and
 that's what all our main results are about. You might not care about
 this particular feature in your code, and consequently you might
 choose a different abstraction. But calling that abstraction simply
 `actors' causes unnecessary confusion, in our opinion. And that's not
 good for the goal of convincing people that actors are a useful
 concurrency abstraction. So, nothing against lift actors and Akka, but
 we need to be precise about the tradeoffs. Maybe call them `flat
 actors' or something like that.

 Martin and Philipp

 




-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org

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



[Lift] Re: Help with using JSExp and JsCmd traits

2009-09-30 Thread David Pollak
On Wed, Sep 30, 2009 at 11:36 AM, glenn gl...@exmbly.com wrote:


 David,

 I can't do this, AnonFunc(JqId(item-save)  JqEmptyAfter
 (divthis.id was
  toggled/div)) , if that's what you mean.


That's not what I wrote.  Please look again at the curly braces around the
this.id:

AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id}
was toggled/div))



 This generates the following JavaScript:

 function() {jQuery('#'+item-save).empty().after(divthis.id was
 toggled/div);

 and that won't do. What's needed is something more akin to:

 function() {jQuery('#'+item-save).empty().after(div + this.id +
 was toggled/div);

 So, I guess my question is how do I define a NodeSeq to accomplish
 this?

 Glenn



 On Sep 30, 10:40 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  On Tue, Sep 29, 2009 at 1:22 PM, glenn gl...@exmbly.com wrote:
 
   I'd like to converting the following
 
   JsRaw(function() $('#item-save').html(this.id + ' was
   toggled'))
 
   into something more object-oriented, using JQuery support functions in
   Lift.
 
   I've tried various combiniations, including this
 
   AnonFunc(JqId(item-save)  JqEmptyAfter(div{JsRaw(this.id)} was
   toggled/div))
 
  AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id} was
  toggled/div))
 
  No reason to promote this.id into some JavaScript thing.  It's part of
 the
  XML literal.  The XML literal is generated server-side as part of the
  JavaScript function.
 
 
 
   but nothing seems to work. It just treats this.id as ordinary text,
   not as a Javascript variable.
 
   Any ideas would be appreciated.
 
   Glenn
 
  --
  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] Change net.liftweb.mapper.ByList to take a Seq[T] instead of a List[T]?

2009-09-30 Thread harryh

Subject says it all.  Is there any reason why this should not be done?

-harryh

--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

2009-09-30 Thread glenn

David,

The problem with writting the NodeSeq as div{this.id} was toggled/
div)
is that it generates the following JavaScript:

function() {jQuery('#'+item-save).empty().after(div-1 was
toggled/div);

that is, Lift evaluates {this.id} in relation to the snippet, then
outputs the value
in the JavaScript - not the result I'm after.

Glenn...

On Sep 30, 11:41 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Wed, Sep 30, 2009 at 11:36 AM, glenn gl...@exmbly.com wrote:

  David,

  I can't do this, AnonFunc(JqId(item-save)  JqEmptyAfter
  (divthis.id was
   toggled/div)) , if that's what you mean.

 That's not what I wrote.  Please look again at the curly braces around the
 this.id:

 AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id}
 was toggled/div))





  This generates the following JavaScript:

  function() {jQuery('#'+item-save).empty().after(divthis.id was
  toggled/div);

  and that won't do. What's needed is something more akin to:

  function() {jQuery('#'+item-save).empty().after(div + this.id +
  was toggled/div);

  So, I guess my question is how do I define a NodeSeq to accomplish
  this?

  Glenn

  On Sep 30, 10:40 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   On Tue, Sep 29, 2009 at 1:22 PM, glenn gl...@exmbly.com wrote:

I'd like to converting the following

JsRaw(function() $('#item-save').html(this.id + ' was
toggled'))

into something more object-oriented, using JQuery support functions in
Lift.

I've tried various combiniations, including this

AnonFunc(JqId(item-save)  JqEmptyAfter(div{JsRaw(this.id)} was
toggled/div))

   AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id} was
   toggled/div))

   No reason to promote this.id into some JavaScript thing.  It's part of
  the
   XML literal.  The XML literal is generated server-side as part of the
   JavaScript function.

but nothing seems to work. It just treats this.id as ordinary text,
not as a Javascript variable.

Any ideas would be appreciated.

Glenn

   --
   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 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: Help with using JSExp and JsCmd traits

2009-09-30 Thread David Pollak
On Wed, Sep 30, 2009 at 1:08 PM, glenn gl...@exmbly.com wrote:


 David,

 The problem with writting the NodeSeq as div{this.id} was toggled/
 div)
 is that it generates the following JavaScript:

 function() {jQuery('#'+item-save).empty().after(div-1 was
 toggled/div);

 that is, Lift evaluates {this.id} in relation to the snippet, then
 outputs the value
 in the JavaScript - not the result I'm after.


What are you after?  What is this in the context?



 Glenn...

 On Sep 30, 11:41 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  On Wed, Sep 30, 2009 at 11:36 AM, glenn gl...@exmbly.com wrote:
 
   David,
 
   I can't do this, AnonFunc(JqId(item-save)  JqEmptyAfter
   (divthis.id was
toggled/div)) , if that's what you mean.
 
  That's not what I wrote.  Please look again at the curly braces around
 the
  this.id:
 
  AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id}
  was toggled/div))
 
 
 
 
 
   This generates the following JavaScript:
 
   function() {jQuery('#'+item-save).empty().after(divthis.id was
   toggled/div);
 
   and that won't do. What's needed is something more akin to:
 
   function() {jQuery('#'+item-save).empty().after(div + this.id +
   was toggled/div);
 
   So, I guess my question is how do I define a NodeSeq to accomplish
   this?
 
   Glenn
 
   On Sep 30, 10:40 am, David Pollak feeder.of.the.be...@gmail.com
   wrote:
On Tue, Sep 29, 2009 at 1:22 PM, glenn gl...@exmbly.com wrote:
 
 I'd like to converting the following
 
 JsRaw(function() $('#item-save').html(this.id + ' was
 toggled'))
 
 into something more object-oriented, using JQuery support functions
 in
 Lift.
 
 I've tried various combiniations, including this
 
 AnonFunc(JqId(item-save)  JqEmptyAfter(div{JsRaw(this.id)}
 was
 toggled/div))
 
AnonFunc(JqId(item-save)  JqEmptyAfter(div{this.id} was
toggled/div))
 
No reason to promote this.id into some JavaScript thing.  It's part
 of
   the
XML literal.  The XML literal is generated server-side as part of the
JavaScript function.
 
 but nothing seems to work. It just treats this.id as ordinary
 text,
 not as a Javascript variable.
 
 Any ideas would be appreciated.
 
 Glenn
 
--
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 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: Change net.liftweb.mapper.ByList to take a Seq[T] instead of a List[T]?

2009-09-30 Thread harryh

 We're going to have to turn it into a List under the covers anyway, so it's
 a performance wash.

Taking a look at the code it does no appear to be the case that it
will have to be turned into a List under the covers.  It's just mapped
over and then mkStringed.

-harryh

--~--~-~--~~~---~--~~
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: Concurrent Web Service Requests?

2009-09-30 Thread marius d.


On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
 I thought there were issues here because anything starting lift: gets
 executed as a snippet.

Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution semantics.
So I'm still questioning the need for a new prefix.


 I'm still for an eval: prefix, as these proposals all relate to how a
 page is evaluated.

 On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:

  lift is already a reserved prefix for snippets. So I'd stay with
  simply lift prefix for these attributes as well.

  Br's,
  Marius

  On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
  So what is your proposal? Am I interpreting you correctly that you are for 
  a prefix of 'lift'? And it will be a reserved suffix?

  -

  marius d.marius.dan...@gmail.com wrote:

  I realize that I may be a little late here but I do have second
  thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
  understand that these attributes are not really snippets or built is
  snippets but is this an enough reason to introduce a new prefix?
  Personally I don't think so. Historically lift reserved prefix names
  were heavily debated and argued and this is a little sensitive area.

  But the good news is that I may be the only one feeling this way about
  this and everyone else likes it so I'm just a negligible minority.

  Br's,
  Marius

  On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
   naftoli...@gmail.comwrote:

If you like the idea of having them all as attributes but don't like 
the
idea of using a single attribute ('xx:eager_eval=true 
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
prefix to be chosen) then maybe the prefix should be 'eval'.

   I've changed the code to:
   liftx:eager_eval=true
   liftx:par=true | liftx:parallel=true

   The reasons for not combining them:

      - They are evaluated in different parts of the code, thus 
   eager/parallel
      doesn't make sense from a code path perspective
      - I am reserving the value of liftx:par for future implementation to
      allow farming the snippet evaluation to another mechanism.  Right 
   now, it's
      hard-coded to use LiftActors.  I can see a time when it would work 
   with Akka
      actors or some other parallelization mechanism

As far as ajax evaluation I'm not sure I'm understanding. Could you 
show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?

   lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
   --
     lift:MySnippet/
   /lift:Ajax

-
Ross Mellgrendri...@gmail.com wrote:

My 2 cents,

I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?

-Ross

On Sep 24, 2009, at 12:46 PM, David Pollak wrote:

 On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim 
naftoli...@gmail.com
  wrote:

 What do you mean by as a normal snippet?

 The parallel snippet processing is implemented deep inside
 LiftSession.  It's not a snippet.  All the lift:xxx/ tags, even
 those with defaults built into Lift, are implemented as snippets and
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight
 that it's functionality that doesn't require a change to LiftSession
 or other parts of Lift to function correctly.

 To me it seems worthwhile to have a consistency between the two
 syntax-wise, since they have some common denominator semantics-wise.
 Actually, maybe throw in eager_eval to the mix. Maybe we could have
 one eval or lift:eval or liftx:eval or whatever attribute, which can
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a
 unified namespace.

 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
naftoli...@gmail.com
 wrote:

  A snippet attribute can be invoked with something other than
  lift:snippet=Class.method? There's a short syntax? What is it?

 There may be a short syntax (e.g., lift:Class.method) in the future.

  What was used for the feature that inserts a snippet
 asynchronously via
  Ajax?

 That feature isn't done yet, but that feature is likely to be done
 as a

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread Naftoli Gugenheim

Could you elaborate on why adding a new prefix may not be a good idea? And is 
it better or worse than having it unprefixed?

-
marius d.marius.dan...@gmail.com wrote:



On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
 I thought there were issues here because anything starting lift: gets
 executed as a snippet.

Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution semantics.
So I'm still questioning the need for a new prefix.


 I'm still for an eval: prefix, as these proposals all relate to how a
 page is evaluated.

 On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:

  lift is already a reserved prefix for snippets. So I'd stay with
  simply lift prefix for these attributes as well.

  Br's,
  Marius

  On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
  So what is your proposal? Am I interpreting you correctly that you are for 
  a prefix of 'lift'? And it will be a reserved suffix?

  -

  marius d.marius.dan...@gmail.com wrote:

  I realize that I may be a little late here but I do have second
  thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
  understand that these attributes are not really snippets or built is
  snippets but is this an enough reason to introduce a new prefix?
  Personally I don't think so. Historically lift reserved prefix names
  were heavily debated and argued and this is a little sensitive area.

  But the good news is that I may be the only one feeling this way about
  this and everyone else likes it so I'm just a negligible minority.

  Br's,
  Marius

  On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
   naftoli...@gmail.comwrote:

If you like the idea of having them all as attributes but don't like 
the
idea of using a single attribute ('xx:eager_eval=true 
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
prefix to be chosen) then maybe the prefix should be 'eval'.

   I've changed the code to:
   liftx:eager_eval=true
   liftx:par=true | liftx:parallel=true

   The reasons for not combining them:

      - They are evaluated in different parts of the code, thus 
   eager/parallel
      doesn't make sense from a code path perspective
      - I am reserving the value of liftx:par for future implementation to
      allow farming the snippet evaluation to another mechanism.  Right 
   now, it's
      hard-coded to use LiftActors.  I can see a time when it would work 
   with Akka
      actors or some other parallelization mechanism

As far as ajax evaluation I'm not sure I'm understanding. Could you 
show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?

   lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
   --
     lift:MySnippet/
   /lift:Ajax

-
Ross Mellgrendri...@gmail.com wrote:

My 2 cents,

I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?

-Ross

On Sep 24, 2009, at 12:46 PM, David Pollak wrote:

 On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim 
naftoli...@gmail.com
  wrote:

 What do you mean by as a normal snippet?

 The parallel snippet processing is implemented deep inside
 LiftSession.  It's not a snippet.  All the lift:xxx/ tags, even
 those with defaults built into Lift, are implemented as snippets and
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight
 that it's functionality that doesn't require a change to LiftSession
 or other parts of Lift to function correctly.

 To me it seems worthwhile to have a consistency between the two
 syntax-wise, since they have some common denominator semantics-wise.
 Actually, maybe throw in eager_eval to the mix. Maybe we could have
 one eval or lift:eval or liftx:eval or whatever attribute, which can
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a
 unified namespace.

 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
naftoli...@gmail.com
 wrote:

  A snippet attribute can be invoked with something other than
  lift:snippet=Class.method? There's a short syntax? What is it?

 There may be a short syntax (e.g., 

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread marius d.

It has been debated many times in slightly different contexts. To me
it is more about clarity. We add a new prefix now, tomorrow add
another one and so on. People would have to remember what goes where
and  mix things up. To me lift prefix is enough and quite clear. It is
more than just s snippet thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.

I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.


Br's,
Marius

On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 Could you elaborate on why adding a new prefix may not be a good idea? And is 
 it better or worse than having it unprefixed?

 -

 marius d.marius.dan...@gmail.com wrote:

 On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
 wrote:

  I thought there were issues here because anything starting lift: gets
  executed as a snippet.

 Correct BUT lift:par or lift:parallel attributes are also applicable
 to snippets context. They determine the snippet's execution semantics.
 So I'm still questioning the need for a new prefix.



  I'm still for an eval: prefix, as these proposals all relate to how a
  page is evaluated.

  On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:

   lift is already a reserved prefix for snippets. So I'd stay with
   simply lift prefix for these attributes as well.

   Br's,
   Marius

   On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
   So what is your proposal? Am I interpreting you correctly that you are 
   for a prefix of 'lift'? And it will be a reserved suffix?

   -

   marius d.marius.dan...@gmail.com wrote:

   I realize that I may be a little late here but I do have second
   thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
   understand that these attributes are not really snippets or built is
   snippets but is this an enough reason to introduce a new prefix?
   Personally I don't think so. Historically lift reserved prefix names
   were heavily debated and argued and this is a little sensitive area.

   But the good news is that I may be the only one feeling this way about
   this and everyone else likes it so I'm just a negligible minority.

   Br's,
   Marius

   On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:

On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
naftoli...@gmail.comwrote:

 If you like the idea of having them all as attributes but don't like 
 the
 idea of using a single attribute ('xx:eager_eval=true 
 xx:parallel=true'
 rather than 'xx:eval=eager parallel' as I suggested, where xx is 
 the
 prefix to be chosen) then maybe the prefix should be 'eval'.

I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true

The reasons for not combining them:

   - They are evaluated in different parts of the code, thus 
eager/parallel
   doesn't make sense from a code path perspective
   - I am reserving the value of liftx:par for future implementation to
   allow farming the snippet evaluation to another mechanism.  Right 
now, it's
   hard-coded to use LiftActors.  I can see a time when it would work 
with Akka
   actors or some other parallelization mechanism

 As far as ajax evaluation I'm not sure I'm understanding. Could 
 you show
 me what you're thinking?
 If I have a snippet
 lift:MySnippet /
 what would be the syntax to have it inserted via ajax?

lift:Ajax !-- the snippet name will not be ajax, but you get the 
idea --
  lift:MySnippet/
/lift:Ajax

 -
 Ross Mellgrendri...@gmail.com wrote:

 My 2 cents,

 I'm not sure I'm a fan of do: namespace, though I agree it would be
 nice to have a common one. Maybe snippet:parallel, 
 snippet:eager_eval?

 -Ross

 On Sep 24, 2009, at 12:46 PM, David Pollak wrote:

  On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim 
 naftoli...@gmail.com
   wrote:

  What do you mean by as a normal snippet?

  The parallel snippet processing is implemented deep inside
  LiftSession.  It's not a snippet.  All the lift:xxx/ tags, even
  those with defaults built into Lift, are implemented as snippets 
  and
  are invoked with normal snippet invocation mechanisms.

  That you will nest your snippet inside a special snippet?

  There is no special snippet.  I used the 

[Lift] JE Abstractions

2009-09-30 Thread sunanda

Hi,
Can any one provide a simple example to explain how to use JE
abstractions (Call,JsFunc) in lift code . I am new to  Lift Framework

Thanks.

--~--~-~--~~~---~--~~
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: Concurrent Web Service Requests?

2009-09-30 Thread Naftoli Gugenheim

I think everyone agrees in concept, that an arbitrary prefix sets a bad 
precendent, which is why it is no longer do:par. But on the other hand, if the 
part after lift: is either a reserved word or a user word--a snippet 
name--then the more reserved words, the more you limit snippet names. (Should 
S.mapSnippet(parallel, ...) throw an exception?) 
So we have these two considerations on either end of the spectrum. Arguably, 
liftx as a prefix satisfies both--it is sufficiently generic to include 
almost any special attribute that may be added, it clearly spells out 
extended lift attribute, and on the other hand it keeps reserved lift 
attributes separate from the user's snippet namespace.
Now let's bear in mind that this is all only relevant in the future, when lift: 
attributes indeed will be interpreted as lift:snippet=... is now. At that 
point it might make sense for the explicit :snippet format to be moved to the 
liftx prefix-- liftx:snippet=... --for the same reason, not to encroach on 
the snippet namespace.


-
marius d.marius.dan...@gmail.com wrote:


It has been debated many times in slightly different contexts. To me
it is more about clarity. We add a new prefix now, tomorrow add
another one and so on. People would have to remember what goes where
and  mix things up. To me lift prefix is enough and quite clear. It is
more than just s snippet thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.

I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.


Br's,
Marius

On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 Could you elaborate on why adding a new prefix may not be a good idea? And is 
 it better or worse than having it unprefixed?

 -

 marius d.marius.dan...@gmail.com wrote:

 On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
 wrote:

  I thought there were issues here because anything starting lift: gets
  executed as a snippet.

 Correct BUT lift:par or lift:parallel attributes are also applicable
 to snippets context. They determine the snippet's execution semantics.
 So I'm still questioning the need for a new prefix.



  I'm still for an eval: prefix, as these proposals all relate to how a
  page is evaluated.

  On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:

   lift is already a reserved prefix for snippets. So I'd stay with
   simply lift prefix for these attributes as well.

   Br's,
   Marius

   On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
   So what is your proposal? Am I interpreting you correctly that you are 
   for a prefix of 'lift'? And it will be a reserved suffix?

   -

   marius d.marius.dan...@gmail.com wrote:

   I realize that I may be a little late here but I do have second
   thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
   understand that these attributes are not really snippets or built is
   snippets but is this an enough reason to introduce a new prefix?
   Personally I don't think so. Historically lift reserved prefix names
   were heavily debated and argued and this is a little sensitive area.

   But the good news is that I may be the only one feeling this way about
   this and everyone else likes it so I'm just a negligible minority.

   Br's,
   Marius

   On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:

On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
naftoli...@gmail.comwrote:

 If you like the idea of having them all as attributes but don't like 
 the
 idea of using a single attribute ('xx:eager_eval=true 
 xx:parallel=true'
 rather than 'xx:eval=eager parallel' as I suggested, where xx is 
 the
 prefix to be chosen) then maybe the prefix should be 'eval'.

I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true

The reasons for not combining them:

   - They are evaluated in different parts of the code, thus 
eager/parallel
   doesn't make sense from a code path perspective
   - I am reserving the value of liftx:par for future implementation to
   allow farming the snippet evaluation to another mechanism.  Right 
now, it's
   hard-coded to use LiftActors.  I can see a time when it would work 
with Akka
   actors or some other parallelization mechanism

 As far as ajax evaluation I'm not sure I'm understanding. Could 
 you show
 me what 

[Lift] json extraction problem

2009-09-30 Thread Lincoln
Hi, I've been playing around with lift-json and I keep running into basic
problems.  I'm hoping someone can point out my mistake.
I'm using net.liftweb % lift-json % 1.1-M5

Here's the code I'm trying to run:

implicit val formats = net.liftweb.json.DefaultFormats
case class Name(first: String, last: String)
case class User(name: Name, email: String)
import net.liftweb.json.JsonParser._
val u = {
import JsonDSL._
(name -
(first - Lincoln) ~
(last - Hochberg)
) ~
(email - linxbet...@gmail.com)
}
val json = JsonDSL.pretty(JsonAST.render(u))
val jsonAST = JsonParser.parse(json)
val user = jsonAST.extract[User]

This blows up with the following exception:

net.liftweb.json.MappingException: Parsed JSON values do not match with
class constructor
args=
arg types=
constructor=public
pkg.TestSpec$$anonfun$1$$anonfun$apply$1(pkg.TestSpec$$anonfun$1)
at
net.liftweb.json.Extraction$.net$liftweb$json$Extraction$$fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.newInstance$1(Extraction.scala:72)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at
com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:48)
at
com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:14)
at
org.specs.specification.ExampleExecution$$anonfun$3$$anonfun$apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at
org.specs.specification.ExampleLifeCycle$class.executeTest(ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at
org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:207)
at
org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:194)
at
org.specs.specification.ExampleExecution$$anonfun$2.apply(Example.scala:185)
at org.specs.specification.ExampleExecution.execute(Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at
org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
at
org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at
sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$$reportSpecification(TestFrameworkImpl.scala:140)
at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
at sbt.BasicTestRunner.run(TestFramework.scala:38)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1(TestFramework.scala:136)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
at sbt.NamedTestTask.run(TestFramework.scala:57)
at
sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
at
sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
at sbt.impl.RunTask.runTask(RunTask.scala:78)
at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot(RunTask.scala:63)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply(RunTask.scala:49)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply(RunTask.scala:49)
at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:130)
at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:130)
at sbt.Control$.trapUnit(Control.scala:19)
at sbt.Distributor$Run$Worker.run(ParallelRunner.scala:130)

Any ideas?

Thanks,
Lincoln

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