[Lift] Re: Question about the Getting Started Guide
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
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
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
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?
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?
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
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/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
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
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
I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow
[Lift] Re: Removing Scala Actors from Lift
As someone coming in new I +1 to Derek’s vote. Stuart. On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote: I would vote for naming the new module lift-common and renaming lift- util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff.
[Lift] Re: Removing Scala Actors from Lift
Sounds like a fair trade off +1 On 30 Sep 2009, at 14:15, Stuart Roebuck wrote: As someone coming in new I +1 to Derek’s vote. Stuart. On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote: I would vote for naming the new module lift-common and renaming lift- util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning
[Lift] Re: Removing Scala Actors from Lift
+1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net
[Lift] Re: Removing Scala Actors from Lift
Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments?
[Lift] Best way to create master/detail with CRUDify?
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
my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so
[Lift] Re: Removing Scala Actors from Lift
But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernard david.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klang viktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Becker dchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code -
[Lift] Re: Question about the Getting Started Guide
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
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
Nice to see the intent to withstand little breakage for the right reason! I am +0 on lift-common. It possibly doesn't mean much, but the only reason I proposed it as an option is because most people with exposure to Java projects have encountered jakarta-common and in some sense have *-common hardwired in their brain and can relate to. Personally, I am -1 on liftx and lift-scalax. They either don't conform to naming convention or aren't unambiguous enough. +1 for lift-util to lift-webutil. Cheers, Indrajit NB: 0. Let's use one conversation trail to converge on the name(s) please. Reduce duplications ;-) 1. It's imperative that the package for the respective classes would have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar would be utterly confusing IMHO. 2. Once the package names are through, the Lift book would need to be updated too. On 30/09/09 7:09 PM, David Bernard wrote: But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com wrote: 2009/9/30 Josh Suerethjoshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollakfeeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala
[Lift] Re: Removing Scala Actors from Lift
lift-webutil is very a good name. It conveys exactly what the module is. But why not leave non-web-related functionality in lift-util? lift-util vs. lift-webutil seems very unambiguous. - Indrajit Raychaudhuriindraj...@gmail.com wrote: Nice to see the intent to withstand little breakage for the right reason! I am +0 on lift-common. It possibly doesn't mean much, but the only reason I proposed it as an option is because most people with exposure to Java projects have encountered jakarta-common and in some sense have *-common hardwired in their brain and can relate to. Personally, I am -1 on liftx and lift-scalax. They either don't conform to naming convention or aren't unambiguous enough. +1 for lift-util to lift-webutil. Cheers, Indrajit NB: 0. Let's use one conversation trail to converge on the name(s) please. Reduce duplications ;-) 1. It's imperative that the package for the respective classes would have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar would be utterly confusing IMHO. 2. Once the package names are through, the Lift book would need to be updated too. On 30/09/09 7:09 PM, David Bernard wrote: But my opinion == 0, I not a lift's user, but I see lot of case where some lift lib could be used without working on a webapp. On Wed, Sep 30, 2009 at 15:37, David Bernarddavid.bernard...@gmail.com wrote: my salt (I don't like lift-common, common of what ? ) If you don't want to move actors, box... to lift-util (xml utilities,... aren't only for web) As actor and box are language extension, I suggest lift-lang, lift-langplus, liftx, lift-scalax ;) /davidB On Wed, Sep 30, 2009 at 15:29, Viktor Klangviktor.kl...@gmail.com wrote: Aye +1 On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: +1 2009/9/30 Derek Chen-Beckerdchenbec...@gmail.com I would vote for naming the new module lift-common and renaming lift-util to lift-webutil. It does mean some breakage but I think that it's a clearer naming. lift-util and lift-common are just too close for someone coming in new, IMHO. Derek On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonérjbo...@gmail.com wrote: 2009/9/30 Josh Suerethjoshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and
[Lift] Re: Removing Scala Actors from Lift
About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. And that's not good for the goal of convincing people that actors are a useful concurrency abstraction. So, nothing against lift actors and Akka, but we need to be precise about the tradeoffs. Maybe call them `flat actors' or something like that. Martin and Philipp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Jonas Bonér
[Lift] Re: Removing Scala Actors from Lift
Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that
[Lift] Re: Removing Scala Actors from Lift
Also, its pretty well documented. Read more here: http://akkasource.org/ We need feedback so please let me know what you think. 2009/9/30 Jonas Bonér jbo...@gmail.com: Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been
[Lift] Re: Help with using JSExp and JsCmd traits
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
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
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]?
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
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
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]?
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?
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?
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?
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
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?
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
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
-~--~~~~--~~--~--~---
