[Lift] Re: non-Lazy evaluation of bind FuncBindParam functions?
Thanks for the feedback. I'm not trying to be awkward here, just
trying to get my head around everything.
Oh, and I completely agree with the risks of premature optimisation.
Thanks,
Stuart
On Mar 10, 5:03 pm, David Pollak
wrote:
> On Wed, Mar 10, 2010 at 7:22 AM, Stuart Roebuck
> wrote:
>
> > Okay, so I now understand what is happening a little better.
>
> > When I saw a construct like:
>
> > bind("example",xhtml,
> > "first_name" -> SHtml.text(user.first_name, user.first_name(_)),
> > "last_name" -> SHtml.text(user.last_name, user.last_name(_))
>
> > it reminded me of a match with cases and my assumption was that each
> > match would only be called if and when the match was found. In reality
> > what appears to happen is that the item on the right hand side of the
> > "->" is usually evaluated and then placed into a Map with the String
> > like "first_name" being the key.
>
> You're welcome to take up laziness vs. strictness with the EPFL team.
> There's only so much we can do to be lazy and it does take extra syntax
> (see Ross's reply).
>
> > So, if every binding is used in every case there is no big issue here,
> > but if you have bindings that aren't all used they will none-the-less
> > be evaluated every time you try to bind.
>
> > Also every time the bind function is called a new Map appears to be
> > generated and indexed in memory which doesn't seem as efficient as it
> > could be.
>
> There's a sign over a urinal in a mens room at Google that reads "Premature
> Optimization is the root of all evil." Now, I think that's an
> overstatement, but in this case, it's applicable.
>
> Is there an *actual* problem with building a Map()? Can you measure the
> problem? Do you have a more efficient solution?
>
> Now, when I wrote that particular code, I was very cognizant of the
> performance implications.
>
> The cost of producing the Map() (backed by a HashMap) in the normal case (no
> hash collisions) is O(n). Worst case is O(n log n).
>
> For each element we're binding, we have look up the tag of the node to bind.
> If we are using our Map(), the look-up time is O(1) (or worst case O(log
> n)). If we have n elements that we're binding, the expected cost is O(n)
> and worst case is O(n log n).
>
> So, we have an algorithm that normally executes in 2xO(n) and worst case
> 2xO(n log n).
>
> Now, if we didn't create the Map, we'd have to cycle through the possible
> binds and we'd wind up with O(n ^ 2). Even if you have a PartialFunction
> (pattern matching) against strings, it's O(n) to match the pattern.
>
> So, would you rather have an O(n) algorithm that can degrade to O(n log n)
> and uses marginally more memory or would you rather have an O(n ^ 2)
> algorithm that uses marginally less memory?
>
> And if you're worried about the memory used by the Map(), on pre 1.6 build
> 16 JVMs, the Map will not likely escape the Eden memory pool (which means
> very quick GC). On the most recent JVMs, the escape analysis should kick in
> and the Map and its elements will be allocated on the heap and never be
> subject to GC.
>
>
>
> > I can't help but wonder whether this could be converted to a form of
> > match which would then be built at compile time and re-used and would
> > only evaluate those matches that matched.
>
> In the event that you can create a benchmark and a real-world situation that
> actually needs this, please open a ticket. But, I suspect that even if you
> pre-created a Map and passed it into bind(), that the performance would be
> nearly identical, but we'd have more public APIs to document which seems to
> be something that also annoys you.
>
>
>
>
>
>
>
> > In the meantime I see that you can convert the code above to:
>
> > bind("example",xhtml,
> > FuncBindParam("first_name", () => SHtml.text(user.first_name,
> > user.first_name(_)),
> > FuncBindParam("last_name", () => SHtml.text(user.last_name,
> > user.last_name(_))
>
> > to get a form of lazy evaluation.
>
> > On Mar 10, 11:01 am, Stuart Roebuck wrote:
> > > I've been trying to figure why some binding is giving me a stack
> > > overflow and I've discovered that if you use the BindHelpers.bind
> > > method with a set of function BindParams, all the functions are
> > > evaluated regardless of whether a match is found.
>
> > > So, for example, if you bind to an empty NodeSeq and have a BindParam
>
[Lift] Re: non-Lazy evaluation of bind FuncBindParam functions?
Okay, so I now understand what is happening a little better.
When I saw a construct like:
bind("example",xhtml,
"first_name" -> SHtml.text(user.first_name, user.first_name(_)),
"last_name" -> SHtml.text(user.last_name, user.last_name(_))
it reminded me of a match with cases and my assumption was that each
match would only be called if and when the match was found. In reality
what appears to happen is that the item on the right hand side of the
"->" is usually evaluated and then placed into a Map with the String
like "first_name" being the key.
So, if every binding is used in every case there is no big issue here,
but if you have bindings that aren't all used they will none-the-less
be evaluated every time you try to bind.
Also every time the bind function is called a new Map appears to be
generated and indexed in memory which doesn't seem as efficient as it
could be.
I can't help but wonder whether this could be converted to a form of
match which would then be built at compile time and re-used and would
only evaluate those matches that matched.
In the meantime I see that you can convert the code above to:
bind("example",xhtml,
FuncBindParam("first_name", () => SHtml.text(user.first_name,
user.first_name(_)),
FuncBindParam("last_name", () => SHtml.text(user.last_name,
user.last_name(_))
to get a form of lazy evaluation.
On Mar 10, 11:01 am, Stuart Roebuck wrote:
> I've been trying to figure why some binding is giving me a stack
> overflow and I've discovered that if you use the BindHelpers.bind
> method with a set of function BindParams, all the functions are
> evaluated regardless of whether a match is found.
>
> So, for example, if you bind to an empty NodeSeq and have a BindParam
> which will never match like:
> "you won't find me here" -> { print("Got here!");
> NodeSeq.Empty }
> …you find that the print statement is called.
>
> This really surprised me. Is this intentional behaviour as it seems
> to be a potential source of significant redundant processing?
>
> Stuart.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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] non-Lazy evaluation of bind FuncBindParam functions?
I've been trying to figure why some binding is giving me a stack
overflow and I've discovered that if you use the BindHelpers.bind
method with a set of function BindParams, all the functions are
evaluated regardless of whether a match is found.
So, for example, if you bind to an empty NodeSeq and have a BindParam
which will never match like:
"you won't find me here" -> { print("Got here!");
NodeSeq.Empty }
…you find that the print statement is called.
This really surprised me. Is this intentional behaviour as it seems
to be a potential source of significant redundant processing?
Stuart.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: NodeSeq to JsExp how to?
Thanks Ross and David… the code seems to be working great now.
Stuart.
On Mar 9, 10:16 pm, David Pollak
wrote:
> On Tue, Mar 9, 2010 at 1:11 PM, Stuart Roebuck
> wrote:
>
> > Once again, thanks for all of this. I will now go away and
> > contemplate it all.
>
> > On the face of it, as a newby, this JavaScript DSL adds another layer
> > of complexity to using Lift with JavaScript. Is there an option to
> > use mostly raw JavaScript? What are the advantages / disadvantages?
>
> JsRaw("my JavaScript Here")
>
> The disadvantage is type-safety/having the compiler help you.
>
> I wrote most of the JavaScript helpers (or at least wrote the core stuff and
> other followed my pattern.) A few months back, there was a discussion about
> changing that stuff around. I'd like to see Lift's JavaScript helper be a
> lot more composable than they are now... like the Lift-json stuff and also
> integrate better with Lift-json. But I don't see that happening with Lift
> 2.0 unless there's a huge block of time/effort that someone wants to throw
> at the issue.
>
>
>
>
>
>
>
> > Sorry, I thought I'd get my moneys worth from you and then try to put
> > something onto the wiki.
>
> > Best,
>
> > Stuart.
>
> > On Mar 9, 5:35 pm, Ross Mellgren wrote:
> > > That's why I factored this as a JQueryNodeSeq, so you can pass anything
> > to dialog (I've used JQuery, and figured you'd need to pass something in
> > there ;-)
>
> > > JQueryNodeSeq(ns) ~> JsFunc("dialog", JsObj("autoOpen" -> JsTrue, "width"
> > -> 500, ..., "close" -> AnonFunc(JsVal("this") ~> JsFunc("destroy"
>
> > > >>> case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft
> > with HtmlFixer {
>
> > > JsExp is the basic trait of the JavaScript DSL. Anything that can go into
> > a JavaScript expression should have this trait.
> > > JQueryLeft is a trait used by the JQuery portion of the JavaScript DSL to
> > indicate that you can chain JQuery calls onto this.
> > > HtmlFixer is a trait that provides fixHtml
>
> > > >>> override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> > ns)).toJsCmd + ")"
>
> > > fixHtml takes the given NodeSeq and does all the appropriate magics to
> > process lift: tags and then converts the NodeSeq to valid XHTML.
>
> > > >>> }
>
> > > And don't forget the security implications!
>
> > > Hope that helps,
> > > -Ross
>
> > > On Mar 9, 2010, at 12:30 PM, Stuart Roebuck wrote:
>
> > > > Thanks for that amazingly quick response!
>
> > > > I only wish I understood the proposed solution! :-)
>
> > > > So (confession time) I simplified things a little, the actual
> > > > JavaScript is…
>
> > > > var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
> > > > true, close: function() { theDialog.destroy; }; } )
>
> > > > How do I assemble this, or is there any documentation / examples you
> > > > can point me to.
>
> > > > Thanks very much,
>
> > > > Stuart.
>
> > > > On Mar 9, 5:14 pm, Ross Mellgren wrote:
> > > >> Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))
>
> > > >> -Ross
>
> > > >> On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:
>
> > > >>> Try this (I haven't tested it, so there could be lurking bugs):
>
> > > >>> case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft
> > with HtmlFixer {
> > > >>> override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> > ns)).toJsCmd + ")"
> > > >>> }
>
> > > >>> Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> > > >>> -Ross
>
> > > >>> On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
> > > >>>> I'm trying to produce a web page with editable content.
>
> > > >>>> When the user clicks an edit button on a line it uses jQuery to
> > > >>>> display a modal dialog which allows fields of that line to be
> > edited.
>
> > > >>>> I can easily produce a snippet to produce the lines using the
> > backend
> > > >>>> data and an XHTML template and binding etc.
>
> > > >>>
[Lift] Re: NodeSeq to JsExp how to?
Once again, thanks for all of this. I will now go away and
contemplate it all.
On the face of it, as a newby, this JavaScript DSL adds another layer
of complexity to using Lift with JavaScript. Is there an option to
use mostly raw JavaScript? What are the advantages / disadvantages?
Sorry, I thought I'd get my moneys worth from you and then try to put
something onto the wiki.
Best,
Stuart.
On Mar 9, 5:35 pm, Ross Mellgren wrote:
> That's why I factored this as a JQueryNodeSeq, so you can pass anything to
> dialog (I've used JQuery, and figured you'd need to pass something in there
> ;-)
>
> JQueryNodeSeq(ns) ~> JsFunc("dialog", JsObj("autoOpen" -> JsTrue, "width" ->
> 500, ..., "close" -> AnonFunc(JsVal("this") ~> JsFunc("destroy"
>
> >>> case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
> >>> HtmlFixer {
>
> JsExp is the basic trait of the JavaScript DSL. Anything that can go into a
> JavaScript expression should have this trait.
> JQueryLeft is a trait used by the JQuery portion of the JavaScript DSL to
> indicate that you can chain JQuery calls onto this.
> HtmlFixer is a trait that provides fixHtml
>
> >>> override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> >>> ns)).toJsCmd + ")"
>
> fixHtml takes the given NodeSeq and does all the appropriate magics to
> process lift: tags and then converts the NodeSeq to valid XHTML.
>
> >>> }
>
> And don't forget the security implications!
>
> Hope that helps,
> -Ross
>
> On Mar 9, 2010, at 12:30 PM, Stuart Roebuck wrote:
>
>
>
> > Thanks for that amazingly quick response!
>
> > I only wish I understood the proposed solution! :-)
>
> > So (confession time) I simplified things a little, the actual
> > JavaScript is…
>
> > var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
> > true, close: function() { theDialog.destroy; }; } )
>
> > How do I assemble this, or is there any documentation / examples you
> > can point me to.
>
> > Thanks very much,
>
> > Stuart.
>
> > On Mar 9, 5:14 pm, Ross Mellgren wrote:
> >> Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))
>
> >> -Ross
>
> >> On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:
>
> >>> Try this (I haven't tested it, so there could be lurking bugs):
>
> >>> case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
> >>> HtmlFixer {
> >>> override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> >>> ns)).toJsCmd + ")"
> >>> }
>
> >>> Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> >>> -Ross
>
> >>> On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
> >>>> I'm trying to produce a web page with editable content.
>
> >>>> When the user clicks an edit button on a line it uses jQuery to
> >>>> display a modal dialog which allows fields of that line to be edited.
>
> >>>> I can easily produce a snippet to produce the lines using the backend
> >>>> data and an XHTML template and binding etc.
>
> >>>> However, I also want the template to include the template for the
> >>>> dialog. So I want the ajax button callback to send JavaScript to
> >>>> instantiate the jQuery UI dialog based on the template and bindings.
>
> >>>> To build this I need to assemble a JsCmd containing the NodeSeq that
> >>>> comes from the XHTML sequence and the bindings.
>
> >>>> In short, if this was straight jQuery I would have some JavaScript of
> >>>> the form:
>
> >>>> $(theFormNodeSeq).dialog()
>
> >>>> But in my case theFormNodeSeq comes from a NodeSeq that was assembled
> >>>> from part of the XHTML template and the bindings and the end result
> >>>> needs to be a JsCmd.
>
> >>>> So I'm trying to do something like:
>
> >>>> JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>
> >>>> But I need to address escaping issues with the HTML and I also need to
> >>>> pre-process any "" commands in theFormNodeSeq.
>
> >>>> Any advice (please)?
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "Lift" group.
> >>>> To post to this group, send email to lift...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> liftweb+unsubscr...@googlegroups.com.
> >>>> For more options, visit this group
> >>>> athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: NodeSeq to JsExp how to?
Ross,
Thanks - yes, the NodeSeq is all generated from templates internally.
The end user does not have any access to change this stuff so this
particular security issue shouldn't be a problem in this case.
Stuart.
On Mar 9, 5:30 pm, Ross Mellgren wrote:
> Ah yes, the reason I went through the fixHtml route is because Stuart
> specifically mentioned he wanted to process those.
>
> Stuart, you should make sure to properly secure this stuff -- either as an
> admin-only thing (understanding that that person has as much rights as you)
> or by scrubbing the XML thoroughly.
>
> -Ross
>
> On Mar 9, 2010, at 12:26 PM, David Pollak wrote:
>
>
>
>
>
> > On Tue, Mar 9, 2010 at 9:14 AM, Ross Mellgren wrote:
> > Try this (I haven't tested it, so there could be lurking bugs):
>
> > case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
> > HtmlFixer {
> > override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> > ns)).toJsCmd + ")"
> > }
>
> > Ross,
>
> > This is good code, but introduces a potential security vulnerability. ;-)
>
> > fixHtml runs the NodeSeq through Lift's snippet handler. If you have
> > web-user input, a user could type in and cause server-side
> > code to be executed.
>
> > import net.liftweb.util._
> > import Helpers._
>
> > Personally, I'd suggest "jQuery(" + AltXML.toXML(nodeSeq, false,
> > true).encJs + ")"
>
> > Thanks,
>
> > David
>
> > Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> > -Ross
>
> > On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
> > > I'm trying to produce a web page with editable content.
>
> > > When the user clicks an edit button on a line it uses jQuery to
> > > display a modal dialog which allows fields of that line to be edited.
>
> > > I can easily produce a snippet to produce the lines using the backend
> > > data and an XHTML template and binding etc.
>
> > > However, I also want the template to include the template for the
> > > dialog. So I want the ajax button callback to send JavaScript to
> > > instantiate the jQuery UI dialog based on the template and bindings.
>
> > > To build this I need to assemble a JsCmd containing the NodeSeq that
> > > comes from the XHTML sequence and the bindings.
>
> > > In short, if this was straight jQuery I would have some JavaScript of
> > > the form:
>
> > > $(theFormNodeSeq).dialog()
>
> > > But in my case theFormNodeSeq comes from a NodeSeq that was assembled
> > > from part of the XHTML template and the bindings and the end result
> > > needs to be a JsCmd.
>
> > > So I'm trying to do something like:
>
> > > JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>
> > > But I need to address escaping issues with the HTML and I also need to
> > > pre-process any "" commands in theFormNodeSeq.
>
> > > Any advice (please)?
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > liftweb+unsubscr...@googlegroups.com.
> > > For more options, visit this group
> > > athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > 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 lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: NodeSeq to JsExp how to?
Thanks for that amazingly quick response!
I only wish I understood the proposed solution! :-)
So (confession time) I simplified things a little, the actual
JavaScript is…
var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
true, close: function() { theDialog.destroy; }; } )
How do I assemble this, or is there any documentation / examples you
can point me to.
Thanks very much,
Stuart.
On Mar 9, 5:14 pm, Ross Mellgren wrote:
> Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))
>
> -Ross
>
> On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:
>
>
>
> > Try this (I haven't tested it, so there could be lurking bugs):
>
> > case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
> > HtmlFixer {
> > override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> > ns)).toJsCmd + ")"
> > }
>
> > Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> > -Ross
>
> > On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
> >> I'm trying to produce a web page with editable content.
>
> >> When the user clicks an edit button on a line it uses jQuery to
> >> display a modal dialog which allows fields of that line to be edited.
>
> >> I can easily produce a snippet to produce the lines using the backend
> >> data and an XHTML template and binding etc.
>
> >> However, I also want the template to include the template for the
> >> dialog. So I want the ajax button callback to send JavaScript to
> >> instantiate the jQuery UI dialog based on the template and bindings.
>
> >> To build this I need to assemble a JsCmd containing the NodeSeq that
> >> comes from the XHTML sequence and the bindings.
>
> >> In short, if this was straight jQuery I would have some JavaScript of
> >> the form:
>
> >> $(theFormNodeSeq).dialog()
>
> >> But in my case theFormNodeSeq comes from a NodeSeq that was assembled
> >> from part of the XHTML template and the bindings and the end result
> >> needs to be a JsCmd.
>
> >> So I'm trying to do something like:
>
> >> JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>
> >> But I need to address escaping issues with the HTML and I also need to
> >> pre-process any "" commands in theFormNodeSeq.
>
> >> Any advice (please)?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Lift" group.
> >> To post to this group, send email to lift...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> liftweb+unsubscr...@googlegroups.com.
> >> For more options, visit this group
> >> athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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] NodeSeq to JsExp how to?
I'm trying to produce a web page with editable content.
When the user clicks an edit button on a line it uses jQuery to
display a modal dialog which allows fields of that line to be edited.
I can easily produce a snippet to produce the lines using the backend
data and an XHTML template and binding etc.
However, I also want the template to include the template for the
dialog. So I want the ajax button callback to send JavaScript to
instantiate the jQuery UI dialog based on the template and bindings.
To build this I need to assemble a JsCmd containing the NodeSeq that
comes from the XHTML sequence and the bindings.
In short, if this was straight jQuery I would have some JavaScript of
the form:
$(theFormNodeSeq).dialog()
But in my case theFormNodeSeq comes from a NodeSeq that was assembled
from part of the XHTML template and the bindings and the end result
needs to be a JsCmd.
So I'm trying to do something like:
JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
But I need to address escaping issues with the HTML and I also need to
pre-process any "" commands in theFormNodeSeq.
Any advice (please)?
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: superficial first impressions from a rails junkie
Thank you for writing your comments. As most have said in the thread, honest feedback is valuable if not essential and often hard to come by, so please don't be put off by the odd negative response. I'm fairly newbie here too and share some of your concerns about Lift. For what it's worth I thought I'd share my thoughts to add to the melting pot… I'm an ex-Java coder who ran a business using Apache Cocoon in it's early days. As an agile advocate I got frustrated with Java and had a flirted with Grails (Groovy on Rails) for one commercial project. But whilst I liked Groovy's conciseness I found it's loose typing and runtime 'magic' forced undue emphasis on writing test after test. Then I discovered Scala and fell in love! It's a really nice language with an amazing blend of conciseness, consistency and power. So, when I found Lift and read around it I felt that Lift was a next generation web framework built on the type safe solid functional Scala language, the speed of the JVM and it's mature libraries and with inherent and designed features that would lend itself to scalability in the new world of cloud computing. I checked out the community and it looked strong and high on common sense and expertise. Finally I checked out it's users and found some big organisations using it already. So in comment to others, Lift had a good image for me, it was trying to get started using it that was my biggest hurdle and I share much of what Miles said about this. The "Exploring Lift" PDF book is essential but certainly wasn't easy to find at first—I see it's linked from the front page now which I don't think it was when I started. The new wiki pages are starting to be a really useful source of info though it's a shame GitHub's wiki mechanism is so flat-file! If I was to make one criticism of the Exploring Lift book is that the example code tends to be unnecessarily complicated to demonstrate the particular thing that is being explained. One of the biggest problems I had in the early days of not knowing Scala was trying to understand what the missing code, substituted by "..." in the code listings would have been. Indeed in the really early days I was trying to figure out what "..." did in Scala—which isn't as stupid as it sounds! I have been a bit disappointed with the level of commenting in the major objects and methods of the framework. When I can't find any documentation I often go back to the source code and I sometimes find either no comments or comments that are out of date with parameter names not matching the actual parameters of the methods. I offered to help but found that contributing isn't as easy as it should be. Increasingly I feel that one of the problems with Scala and Lift is that the power and beauty of the language and framework are sometimes lost in code that has lost restraint. I think Lift would benefit from: * Tidier code - laid out and structured with concern given to making it easy to follow. Just because Scala can do it in one line doesn't mean that four lines wouldn't be better. Just because you can put multiple classes and objects in a single scala file doesn't mean it's bad to break code up into separate files. * Fewer public functions, function variants and implicits. Almost everything in Lift seems to be public and there seems to be a love of creating every possible variant of a function rather than letting the user do the odd extra step themselves. Finally, implicits get everywhere, and implicit conversions are basically unexplained magic to someone trying to make sense of unfamiliar code. It's not a bad thing to explicitly convert something—it helps to explain to you and others what you are trying to do. Okay, better leave it there! I'm currently using SBT rather than Maven which is really nice to use but currently underdocumented. Have grown to dislike Maven against all my attempts to like it. All in all Lift is really powerful, I'm using it, and I would really like it to succeed, but, like Scala, it currently lacks some marketing flare and is succeeding by it's brilliance alone. For those familiar with Crossing the Chasm, I'd surmise that most Lift users are "Technology enthusiasts" and the market won't grow until Lift becomes attractive to the "Visionaries" who basically need some documentation! Stuart. On Mar 6, 4:43 am, cageface wrote: > Like many other web developers, I abandoned some heavyweight Java web -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: New logging code is in master
Trying this on 2.8 with the 2.8 Lift Snapshot. The Logger trait seems to work fine though looking at the code I can't see how setup gets called. The Loggable trait is throwing a null pointer exception. I'm using Log4J. Stuart. P.S. I don't want to mess with other people's wiki pages, but I wonder whether it is worth consolidating the pages: "How To: Configure Logging" and "Logging in Lift". On Mar 2, 12:49 am, aw wrote: > Very nice! I am looking forward to this. > > On Feb 28, 8:14 am, Jeppe Nejsum Madsen wrote: > > > > > The newloggingcode is now in master and should be fully usable. > > Therefore, the existingloggingcode has been deprecated. > > > I've added a Wiki article > > here:http://wiki.github.com/dpp/liftweb/logging-in-lift > > > /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Documenting the source code / supplementing the API docs
Okay - I've added a page to the wiki: http://wiki.github.com/dpp/liftweb/sitemap-basics On Feb 26, 11:20 am, Stuart Roebuck wrote: > Tim, > > Thanks - that sounds like a good idea. > > Stuart. > > On 26 Feb 2010, at 10:50, Timothy Perrett wrote: > > > > > Stuart, > > > You can still contribute to the wiki and of your findings or musings - > > that is totally open. > > > Cheers, Tim -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Documenting the source code / supplementing the API docs
Tim, Thanks - that sounds like a good idea. Stuart. On 26 Feb 2010, at 10:50, Timothy Perrett wrote: > Stuart, > > You can still contribute to the wiki and of your findings or musings - > that is totally open. > > Cheers, Tim -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Documenting the source code / supplementing the API docs
I've spoken to David off- list and unfortunately I am not comfortable signing the particular IP assignment contract I was sent as it appears to me (but not to David) to be ambiguous in whether it covers what I commit or also any other code I am working on in connection with Lift (e.g. the code of my business). I have offered to alter the wording but David has made it clear that he will not move on the wording of this and, as a lawyer, that it he knows what he is talking about better than I do. Having previously contributed to Apache Ant, Apache Cocoon and Apache James as well as making various minor contributions and bug fixes to other open source projects I have never had a problem in the past with the wording of such agreements with open source projects and would happily of signed the type of agreement currently used by Apache. (http:// www.apache.org/licenses/icla.pdf) Unfortunately it looks like my attempt to contribute some documentation is at a dead end! Looking at the contract it is also clear that no other existing commiter may take my code or documentation and commit it, so thank you Ross for your offer, but it looks like that will not be possible. As I have said to David - I really don't think that it should be so hard to accept contributions to this project. Stuart. As this contract is the one signed by all other commiters to the project, I am On Feb 23, 3:22 am, David Pollak wrote: > The easiest thing is if Stuart signs an IP assignment, becomes a > full-fledged committer and thus we keep the IP clean. > > Stuart, if you're interested in learning more, please contact me off-list. > > In terms of the documentation standards, I'm okay with anything that the > rest of you-all want. I'm neither the best producer or consumer of docs, so > my voice is a small one on this issue, other than to give hearty thanks to > those who write documentation. > > On Mon, Feb 22, 2010 at 1:05 PM, Stuart Roebuck > wrote: > > > > > > > Great... okay, I’d better do some writing :-) > > > In the absence of a decision I’ll try to minimise special coding in > > comments but use Scaladoc 2 standard if necessary rather than HTML as that > > makes it future proof but still readable for both. > > > Stuart > > > On 22 Feb 2010, at 17:32, Ross Mellgren wrote: > > > > I will do this, and give feed back if it ever becomes too much load. > > > > -Ross > > > > On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote: > > > >> We are interested in the contribution of course... I think the issue is > > mostly about how we take patches for this. Someone on the team would need to > > own this and merge your documentation changes into the master (provided DPP > > has no objections to this - seeing as its documentation I doubt he has) > > > >> Any takers from the team? > > > >> Cheers, Tim > > > >> On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: > > > >>> Sorry for the slow response—was away for a family weekend! > > > >>> I have limited knowledge of Lift internals… > > > >>> However, my view is that it is often easier to document code when you > > >>> don't know it well than when you do, because you soon loose interest > > >>> in documenting things that are obvious to you. What I hope to do is > > >>> document the things that I need to know as I go along on the basis > > >>> that many of these things will also be important to others. It's an > > >>> agile rather than systematic approach if you see what I mean. > > > >>> I have no ego issues here. It's just a small way of giving to the > > >>> community in a win-win kind of way. If my contributions don't seem > > >>> helpful to anyone else then folk can say and I'm not going to > > >>> disappear in a torrent of abuse :-) > > > >>> Similarly, I'm not proposing some big project here. I'm talking about > > >>> a drip-drip of updates as I spot things that need documenting—I've got > > >>> plenty other stuff on my plate right now as I'm launching a company > > >>> based on a Lift based product in mid-year. > > > >>> Enough said… > > > >>> How do we resolve the documentation standard issue? (Scala 2.8 > > >>> Scaladoc2 or prior) David? > > > >>> Stuart. > > > >>> On Feb 19, 4:11 pm, Timothy Perrett wrote: > > >>>> This could work - although, some parts of lift are very non-trivial > > and require good knowledge of lift internals. Do you have su
Re: [Lift] Re: Documenting the source code / supplementing the API docs
Great... okay, I’d better do some writing :-) In the absence of a decision I’ll try to minimise special coding in comments but use Scaladoc 2 standard if necessary rather than HTML as that makes it future proof but still readable for both. Stuart On 22 Feb 2010, at 17:32, Ross Mellgren wrote: > I will do this, and give feed back if it ever becomes too much load. > > -Ross > > On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote: > >> We are interested in the contribution of course... I think the issue is >> mostly about how we take patches for this. Someone on the team would need to >> own this and merge your documentation changes into the master (provided DPP >> has no objections to this - seeing as its documentation I doubt he has) >> >> Any takers from the team? >> >> Cheers, Tim >> >> On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: >> >>> Sorry for the slow response—was away for a family weekend! >>> >>> I have limited knowledge of Lift internals… >>> >>> However, my view is that it is often easier to document code when you >>> don't know it well than when you do, because you soon loose interest >>> in documenting things that are obvious to you. What I hope to do is >>> document the things that I need to know as I go along on the basis >>> that many of these things will also be important to others. It's an >>> agile rather than systematic approach if you see what I mean. >>> >>> I have no ego issues here. It's just a small way of giving to the >>> community in a win-win kind of way. If my contributions don't seem >>> helpful to anyone else then folk can say and I'm not going to >>> disappear in a torrent of abuse :-) >>> >>> Similarly, I'm not proposing some big project here. I'm talking about >>> a drip-drip of updates as I spot things that need documenting—I've got >>> plenty other stuff on my plate right now as I'm launching a company >>> based on a Lift based product in mid-year. >>> >>> Enough said… >>> >>> How do we resolve the documentation standard issue? (Scala 2.8 >>> Scaladoc2 or prior) David? >>> >>> Stuart. >>> >>> On Feb 19, 4:11 pm, Timothy Perrett wrote: >>>> This could work - although, some parts of lift are very non-trivial and >>>> require good knowledge of lift internals. Do you have such knowledge or >>>> are you just hoping to contribute where you can with helpful information? >>>> Both are good, just trying to establish what you had in mind. >>>> >>>> Lift-util probably has the best docs at the moment, so if we could emulate >>>> that it would be good. >>>> >>>> Cheers, Tim >>>> >>>> On 19 Feb 2010, at 15:56, Ross Mellgren wrote: >>>> >>>> >>>> >>>>> If you can get an established standard on what the content and format >>>>> should be, I can work with you reviewing the patches and applying them. >>>> >>>>> But, need to get a concordance from the list on the content first. >>>> >>>>> -Ross >>>> >>>>> On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: >>>> >>>>>> I've had a bit of a break from Lift and coming back I find myself >>>>>> annoyed that I didn't write some notes last time and am having to go >>>>>> back to searching through the various bits of documentation to figure >>>>>> things out. >>>> >>>>>> Anyway, after much thought I decided that the best way to write my >>>>>> notes would be to supplement the API docs (ie. the Scaladoc >>>>>> documentation in the code base). so that I can view context sensitive >>>>>> help in my IDE of choice and others can benefit from my labours! >>>> >>>>>> So, question 1… >>>> >>>>>> The current API docs are very light on documentation and sometime ago >>>>>> I noticed some notice about removing documentation from the code >>>>>> base. Is there some policy about not having documentation in the >>>>>> code or any thought on whether it should adhere to the Scaladoc 2 >>>>>> syntax? >>>> >>>>>> Question 2… >>>> >>>>>> This is only really going to work if the process
Re: [Lift] Re: Documenting the source code / supplementing the API docs
Perhaps it's easier for me to do a fork on GitHub? Then any documentation submissions can be taken across at a time that suits whoever is doing it rather than synced with my submission timeline? On 22 Feb 2010, at 17:05, Timothy Perrett wrote: > We are interested in the contribution of course... I think the issue is > mostly about how we take patches for this. Someone on the team would need to > own this and merge your documentation changes into the master (provided DPP > has no objections to this - seeing as its documentation I doubt he has) > > Any takers from the team? > > Cheers, Tim > > On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: > >> Sorry for the slow response—was away for a family weekend! >> >> I have limited knowledge of Lift internals… >> >> However, my view is that it is often easier to document code when you >> don't know it well than when you do, because you soon loose interest >> in documenting things that are obvious to you. What I hope to do is >> document the things that I need to know as I go along on the basis >> that many of these things will also be important to others. It's an >> agile rather than systematic approach if you see what I mean. >> >> I have no ego issues here. It's just a small way of giving to the >> community in a win-win kind of way. If my contributions don't seem >> helpful to anyone else then folk can say and I'm not going to >> disappear in a torrent of abuse :-) >> >> Similarly, I'm not proposing some big project here. I'm talking about >> a drip-drip of updates as I spot things that need documenting—I've got >> plenty other stuff on my plate right now as I'm launching a company >> based on a Lift based product in mid-year. >> >> Enough said… >> >> How do we resolve the documentation standard issue? (Scala 2.8 >> Scaladoc2 or prior) David? >> >> Stuart. >> >> On Feb 19, 4:11 pm, Timothy Perrett wrote: >>> This could work - although, some parts of lift are very non-trivial and >>> require good knowledge of lift internals. Do you have such knowledge or are >>> you just hoping to contribute where you can with helpful information? Both >>> are good, just trying to establish what you had in mind. >>> >>> Lift-util probably has the best docs at the moment, so if we could emulate >>> that it would be good. >>> >>> Cheers, Tim >>> >>> On 19 Feb 2010, at 15:56, Ross Mellgren wrote: >>> >>> >>> >>>> If you can get an established standard on what the content and format >>>> should be, I can work with you reviewing the patches and applying them. >>> >>>> But, need to get a concordance from the list on the content first. >>> >>>> -Ross >>> >>>> On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: >>> >>>>> I've had a bit of a break from Lift and coming back I find myself >>>>> annoyed that I didn't write some notes last time and am having to go >>>>> back to searching through the various bits of documentation to figure >>>>> things out. >>> >>>>> Anyway, after much thought I decided that the best way to write my >>>>> notes would be to supplement the API docs (ie. the Scaladoc >>>>> documentation in the code base). so that I can view context sensitive >>>>> help in my IDE of choice and others can benefit from my labours! >>> >>>>> So, question 1… >>> >>>>> The current API docs are very light on documentation and sometime ago >>>>> I noticed some notice about removing documentation from the code >>>>> base. Is there some policy about not having documentation in the >>>>> code or any thought on whether it should adhere to the Scaladoc 2 >>>>> syntax? >>> >>>>> Question 2… >>> >>>>> This is only really going to work if the process of submitting the >>>>> documentation is reasonably straightforward so… What's the easiest >>>>> possible way of submitting documentation changes to the code base? (if >>>>> indeed this is something the core team would welcome). I was >>>>> thinking of perhaps emailing git patch files to someone in the core >>>>> team who can verify that the comments are right before checking them >>>>> in. Any thoughts? >>> >>>>> If t
[Lift] Re: Documenting the source code / supplementing the API docs
Sorry for the slow response—was away for a family weekend! I have limited knowledge of Lift internals… However, my view is that it is often easier to document code when you don't know it well than when you do, because you soon loose interest in documenting things that are obvious to you. What I hope to do is document the things that I need to know as I go along on the basis that many of these things will also be important to others. It's an agile rather than systematic approach if you see what I mean. I have no ego issues here. It's just a small way of giving to the community in a win-win kind of way. If my contributions don't seem helpful to anyone else then folk can say and I'm not going to disappear in a torrent of abuse :-) Similarly, I'm not proposing some big project here. I'm talking about a drip-drip of updates as I spot things that need documenting—I've got plenty other stuff on my plate right now as I'm launching a company based on a Lift based product in mid-year. Enough said… How do we resolve the documentation standard issue? (Scala 2.8 Scaladoc2 or prior) David? Stuart. On Feb 19, 4:11 pm, Timothy Perrett wrote: > This could work - although, some parts of lift are very non-trivial and > require good knowledge of lift internals. Do you have such knowledge or are > you just hoping to contribute where you can with helpful information? Both > are good, just trying to establish what you had in mind. > > Lift-util probably has the best docs at the moment, so if we could emulate > that it would be good. > > Cheers, Tim > > On 19 Feb 2010, at 15:56, Ross Mellgren wrote: > > > > > If you can get an established standard on what the content and format > > should be, I can work with you reviewing the patches and applying them. > > > But, need to get a concordance from the list on the content first. > > > -Ross > > > On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: > > >> I've had a bit of a break from Lift and coming back I find myself > >> annoyed that I didn't write some notes last time and am having to go > >> back to searching through the various bits of documentation to figure > >> things out. > > >> Anyway, after much thought I decided that the best way to write my > >> notes would be to supplement the API docs (ie. the Scaladoc > >> documentation in the code base). so that I can view context sensitive > >> help in my IDE of choice and others can benefit from my labours! > > >> So, question 1… > > >> The current API docs are very light on documentation and sometime ago > >> I noticed some notice about removing documentation from the code > >> base. Is there some policy about not having documentation in the > >> code or any thought on whether it should adhere to the Scaladoc 2 > >> syntax? > > >> Question 2… > > >> This is only really going to work if the process of submitting the > >> documentation is reasonably straightforward so… What's the easiest > >> possible way of submitting documentation changes to the code base? (if > >> indeed this is something the core team would welcome). I was > >> thinking of perhaps emailing git patch files to someone in the core > >> team who can verify that the comments are right before checking them > >> in. Any thoughts? > > >> If there is a reasonably explainable approach, it could be added as a > >> Wiki page to encourage wider participation. > > >> Best, > > >> Stuart. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Lift" group. > >> To post to this group, send email to lift...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> liftweb+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://groups.google.com/group/liftweb?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] Documenting the source code / supplementing the API docs
I've had a bit of a break from Lift and coming back I find myself annoyed that I didn't write some notes last time and am having to go back to searching through the various bits of documentation to figure things out. Anyway, after much thought I decided that the best way to write my notes would be to supplement the API docs (ie. the Scaladoc documentation in the code base). so that I can view context sensitive help in my IDE of choice and others can benefit from my labours! So, question 1… The current API docs are very light on documentation and sometime ago I noticed some notice about removing documentation from the code base. Is there some policy about not having documentation in the code or any thought on whether it should adhere to the Scaladoc 2 syntax? Question 2… This is only really going to work if the process of submitting the documentation is reasonably straightforward so… What's the easiest possible way of submitting documentation changes to the code base? (if indeed this is something the core team would welcome). I was thinking of perhaps emailing git patch files to someone in the core team who can verify that the comments are right before checking them in. Any thoughts? If there is a reasonably explainable approach, it could be added as a Wiki page to encourage wider participation. Best, Stuart. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Scheduling the San Francisco Scala Lift Off
Or Edinburgh? :-) On Jan 13, 12:22 pm, Mads Hartmann wrote: > Was is 'Scala Lift Off' ? > I live in Denmark so i might be able to make it in either London or > Norway :) > > On Jan 13, 12:32 pm, Miles Sabin wrote: > > > > > On Wed, Jan 13, 2010 at 3:31 AM, David Pollak > > > wrote: > > > For the last two years, the San Francisco Scala Lift Off has happened the > > > day after JavaOne. It's looking like JavaOne might not happen this year, > > > so > > > I'm starting to think about a time in the April-June timeframe when there > > > are a lot of Scala and/or Java folks in San Francisco. If you all have > > > any > > > ideas of good dates, please post them. > > > A bit early maybe, but EclipseCon 2010 is 22nd - 25th of March. > > > Cheers, > > > Miles > > > -- > > Miles Sabin > > tel: +44 (0)7813 944 528 > > skype: milessabinhttp://www.chuusai.com/http://twitter.com/milessabin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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
As someone coming in new I +1 to Derek’s vote. Stuart. On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote: > I would vote for naming the new module lift-common and renaming lift- > util to lift-webutil. It does mean some breakage but I think that > it's a clearer naming. lift-util and lift-common are just too close > for someone coming in new, IMHO. > > Derek > > On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér wrote: > > 2009/9/30 Josh Suereth : > > As much as I agree with your decision, it just makes me sad. I > know lots > > of people that learned scala for "actors are the way of the > future" I > > think we need to push harder. Hopefully all major projects > migrating off > > actors will give EPFL a wake up call? > > This is the reason I created Akka, to have a standard platform for > Actors with all the things one need to write production applications. > Akka already have 4 committers and honestly, looking at the pace EPFL > has had with bugfixing, features etc I think they will have a very > hard time keep up with what the market needs. I have unfortunately > given up up the Scala Actors library. I need the things Akka > implements now and don't have time to wait indefinitely. > > > > > - Josh > > > > On Tue, Sep 29, 2009 at 1:41 PM, David Pollak > > wrote: > >> > >> > >> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck > > >> wrote: > >>> > >>> Apologies if I've missed something obvious but my web search > hasn't > >>> turned anything up... > >>> > >>> What are the Scala Actors instability issues? I'm in the process > of > >>> doing some major Scala development work and this comment raises > >>> concerns that I'd like to understand. > >> > >> The issues (with the Scala Actors in general and Lift's use of > them) are: > >> > >> Scala Actors use a custom version of Doug Leah's Fork/Join > library. This > >> was necessary for JDK 1.4 support. With JDK 1.5, the > java.util.concurrent > >> stuff should have been used. I was led to understand that this > change was > >> made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff > still > >> contains fork-join. The FJ library has a memory retention issue > where it > >> trades memory for non-locking performance and, with many threads > in a > >> thread-pool, this leads to out of memory issues. > >> The Scala Actor code is very brittle. > >> See > >> http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html > >> The code has not been materially refactored, which means that > even in 2.8, > >> there will be significant potential problems with the Actors. > Those > >> potential problems have manifest themselves as real problems in > 2.7.x. I > >> have spent in aggregate nearly 3 weeks of my time since November > 2008 > >> working around the defects in the Actor library. It's easier to > have our > >> own Actors (the current Actor library is about 2 days of work on > my part and > >> the refactoring of Lift to work with the existing Actor library > is another 2 > >> days of work.) > >> EPFL has been generally slow to respond to bug reports. I am very > >> frustrated and quite frankly tired of having to cajole EPFL into > responding > >> to defects in one of the premier Scala libraries. > >> > >> I would strongly suggest that you look at Akka. It's got a > better view > >> and implementation of Actors than does the standard Scala > distribution. Akka > >> includes support for distributed actors, etc. > >> Hope this helps. > >> > >>> > >>> Best, > >>> > >>> Stuart > >>> > >>> On Sep 29, 3:30 am, David Pollak > >>> wrote: > >>> > Folks, > >>> > > >>> > Given the continued instability of Scala Actors, I've decided > to remove > >>> > them > >>> > from Lift. > >>> > > >>> > Specifically, I'm migrating CometActors to sit on top of > Lift's Actors. > >>> > But, you'll also be able to use Akka Actors to power Lift's > >>> > CometActors. > >>> > Specifically, I'm working with Jonas to make sure that we > share a > >>> > common > >>> > interface to Ac
[Lift] Re: Removing Scala Actors from Lift
Okay, I think I've now found the reference I was looking for... <http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/ 200905.mbox/ %3ccdbebedf0905220957k7767c05emc0b6fb7812f1f...@mail.gmail.com%3e> Stuart. On Sep 29, 10:35 am, Stuart Roebuck wrote: > Apologies if I've missed something obvious but my web search hasn't > turned anything up... > > What are the Scala Actors instability issues? I'm in the process of > doing some major Scala development work and this comment raises > concerns that I'd like to understand. > > Best, > > Stuart > > On Sep 29, 3:30 am, David Pollak > wrote: > > > > > Folks, > > > Given the continued instability of Scala Actors, I've decided to remove them > > from Lift. > > > Specifically, I'm migrating CometActors to sit on top of Lift's Actors. > > But, you'll also be able to use Akka Actors to power Lift's CometActors. > > Specifically, I'm working with Jonas to make sure that we share a common > > interface to Actors. > > > I've gotten Lift nearly completely migrated over to Lift's Actors on the > > dpp_wip_actorize branch. > > Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize > > > There will be some breaking changes to your applications. Specifically: > > > - Box will be moved to a new package, net.liftweb.base (this is where the > > interface for Actors will live as well) > > - If you make any assumptions about your CometActors being Scala Actors > > (e.g., using linking), you will have to rewrite this code > > - Some methods in Lift that currently take Scala Actors as parameters > > will take Lift Actors (e.g., ActorPing) > > > There will be a parallel Maven repository with the new Lift Actor stuff in > > it so you will be able to build you apps against the new code before the > > official switch-over. > > > Milestone 6 (which should be out next week) will be based on the existing > > Actor model. After we get feedback from the community about the new Actor > > stuff, we will switch -SNAPSHOT over to the new Actor stuff. > > > Questions, thoughts, or comments? > > > Thanks, > > > David > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. Best, Stuart On Sep 29, 3:30 am, David Pollak wrote: > Folks, > > Given the continued instability of Scala Actors, I've decided to remove them > from Lift. > > Specifically, I'm migrating CometActors to sit on top of Lift's Actors. > But, you'll also be able to use Akka Actors to power Lift's CometActors. > Specifically, I'm working with Jonas to make sure that we share a common > interface to Actors. > > I've gotten Lift nearly completely migrated over to Lift's Actors on the > dpp_wip_actorize branch. > Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize > > There will be some breaking changes to your applications. Specifically: > > - Box will be moved to a new package, net.liftweb.base (this is where the > interface for Actors will live as well) > - If you make any assumptions about your CometActors being Scala Actors > (e.g., using linking), you will have to rewrite this code > - Some methods in Lift that currently take Scala Actors as parameters > will take Lift Actors (e.g., ActorPing) > > There will be a parallel Maven repository with the new Lift Actor stuff in > it so you will be able to build you apps against the new code before the > official switch-over. > > Milestone 6 (which should be out next week) will be based on the existing > Actor model. After we get feedback from the community about the new Actor > stuff, we will switch -SNAPSHOT over to the new Actor stuff. > > Questions, thoughts, or comments? > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: 1.0.2 released
1.0.2 has certainly fixed the problem for me which I had encountered in 1.0.1. Stuart. On Sep 11, 6:39 pm, David Pollak wrote: > Did you update your pom.xml file to set the lift version to 1.0.2? > I just created a new project with 1.0.2 and it does not display this issue. > > > > > > On Thu, Sep 10, 2009 at 5:55 PM, DMB wrote: > > > You mean this guy? It's still there it seems. > > > java.lang.NoSuchFieldException: refSet > > at java.lang.Class.getDeclaredField(Class.java:1882) > > at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act > > $2$$anonfun$apply$2.apply(LiftServlet.scala:722) > > at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act > > $2$$anonfun$apply$2.apply(LiftServlet.scala:714) > > at scala.actors.Reaction.run(Reaction.scala:78) > > at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run > > (LiftServlet.scala:673) > > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask > > (ThreadPoolExecutor.java:886) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run > > (ThreadPoolExecutor.java:908) > > at java.lang.Thread.run(Thread.java:619) > > java.lang.NullPointerException > > at scala.runtime.BoxesRunTime.boxToInteger(Unknown Source) > > at scala.actors.Actor$$anonfun$scala$actors$Actor$$seq$1.apply > > (Actor.scala:800) > > at scala.actors.Actor$$anonfun$scala$actors$Actor$$seq$1.apply > > (Actor.scala:794) > > at scala.actors.Reaction.run(Reaction.scala:82) > > at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run > > (LiftServlet.scala:673) > > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask > > (ThreadPoolExecutor.java:886) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run > > (ThreadPoolExecutor.java:908) > > at java.lang.Thread.run(Thread.java:619) > > > On Sep 10, 2:03 pm, Derek Chen-Becker wrote: > > > The Lift team is pleased to announce the lift-1.0.2 release! > > > > Lift is an expressive and elegant framework for writing web applications. > > > Lift stresses the importance of security, maintainability, scalability > > > and performance while allowing for high levels of developer productivity. > > > Lift is a scala web framework. > > > > Changes in this version include: > > > > Fixed Bugs: > > > o Removed unnecessary fix for Actors issue now that we're on Scala 2.7.5 > > > > Have fun! > > > -Lift team > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ 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: Announcing 1.0.1!
I've switched a very simple test project from 1.0 to 1.0.1 and switched the scala version to 2.7.5 Now I've started seeing the following in my jetty log: ERROR - [MEMDEBUG] failure java.lang.NoSuchFieldException: refSet at java.lang.Class.getDeclaredField(Class.java:1882) at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act$2$ $anonfun$apply$2.apply(LiftServlet.scala:722) at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act$2$ $anonfun$apply$2.apply(LiftServlet.scala:714) at scala.actors.Reaction.run(Reaction.scala:78) at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run (LiftServlet.scala:673) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) I note that there is a reference to this on the mailing list some time ago and this was attributed to being a Scala 2.7.5 issue. ? Stuart On Sep 9, 5:45 pm, Derek Chen-Becker wrote: > Just a reminder for anyone out there who wants to use 1.0.1: you'll need to > update your pom.xml to use Scala 2.7.5 (and match what Lift was built with). > Typically this just means modifying the properties element in your pom.xml > like so: > > > 2.7.5 > > > Derek > > On Wed, Sep 9, 2009 at 10:22 AM, Derek Chen-Becker > wrote: > > > > > The Lift team is pleased to announce the lift-1.0.1 release! > > > Lift is an expressive and elegant framework for writing web applications. > > Lift stresses the importance of security, maintainability, scalability > > and performance while allowing for high levels of developer productivity. > > Lift is a scala web framework. > > > Changes in this version include: > > > New features: > > o Added custom type mapping to the DriverType class Issue: 37. > > o Added MappedDate and MappedTime to allow for better specification of time > > data Issue: 12. > > > Fixed Bugs: > > o Backported fixes for the Textile and XML parsers > > o Backported the Actor memory leak fixes > > o Backported a fix to S.params > > o Fixed PostgreSQL Double type mapping > > o Fixed support for Oracle Issue: 37. > > o Fixed MappedDateTime to use TIMESTAMP mapping Issue: 12. > > o Fixed ResultSet stringification for NUMERIC and DECIMAL Issue: 36. > > > Changes: > > o Refactored generated key support in DB/Mapper Issue: 37. > > o Modified DB Driver resolution to allow for version-specific drivers > > o Upgrade to Scala 2.7.5 > > > Have fun! > > -Lift team --~--~-~--~~~---~--~~ 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: Lift 1.1-SNAPSHOT under Scala 2.8 with NetBeans and the Scala plugin
David,
Thanks, that's very helpfully pulled me back from the abyss :-)
Stuart
On Sep 4, 11:28 pm, David Pollak
wrote:
> Lift does not yet compile under 2.8.
>
> I just had lunch with PaulP and will be working on a Lift branch that does
> work under 2.8, but it's going to be a little while before it all works (we
> need to get ScalaCheck working first and that's on one of Paul's branches).
>
> So, please use Lift with Scala 2.7.5.
>
> On Fri, Sep 4, 2009 at 3:26 PM, Stuart Roebuck
> wrote:
>
>
>
>
>
>
>
> > Being on the bleeding edge again, I'm trying to do some Lift stuff
> > using the nice new Scala plugin for NetBeans. However, this appears
> > to require me to be working under the latest Scala 2.8 release. So, I
> > have downloaded the Lift sources and built 1.1-SNAPSHOT under Scala
> > 2.8. Everything compiles fine but then I get this:
>
> > net.liftweb.mapper.MetaMegaProtoUser does not take type parameters
> > object User extends User with MetaMegaProtoUser[User] {
>
> > Can anyone shed light on this and give any hints on how I resolve it.
>
> > Consider me a Scala/Lift newbie.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
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] Lift 1.1-SNAPSHOT under Scala 2.8 with NetBeans and the Scala plugin
Being on the bleeding edge again, I'm trying to do some Lift stuff
using the nice new Scala plugin for NetBeans. However, this appears
to require me to be working under the latest Scala 2.8 release. So, I
have downloaded the Lift sources and built 1.1-SNAPSHOT under Scala
2.8. Everything compiles fine but then I get this:
net.liftweb.mapper.MetaMegaProtoUser does not take type parameters
object User extends User with MetaMegaProtoUser[User] {
Can anyone shed light on this and give any hints on how I resolve it.
Consider me a Scala/Lift 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
-~--~~~~--~~--~--~---
