Css selectors not working

[Naftoli Gugenheim]

sbt:lift-framework:2.5-SNAPSHOT> lift-util/console

[warn] Credentials file /home/naftoli/.sbt/.credentials does not exist

[warn] Credentials file /home/naftoli/.sbt/.credentials does not exist

[warn] Credentials file /home/naftoli/.sbt/.credentials does not exist

[warn] Credentials file /home/naftoli/.sbt/.credentials does not exist

[info] Starting scala interpreter...

[info] 

Welcome to Scala version 2.10.0-M7 (OpenJDK 64-Bit Server VM, Java 1.7.0_07).

Type in expressions to have them evaluated.

Type :help for more information.

scala> import net.liftweb.util._

import net.liftweb.util._

scala> CssSelectorParser

res0: net.liftweb.util.CssSelectorParser.type = net.liftweb.util.CssSelectorParser$@26a5ef1d

scala> CssSelectorParser("button")

<console>:11: error: net.liftweb.util.CssSelectorParser.type does not take parameters

              CssSelectorParser("button")

                               ^

scala> CssSelectorParser parse ("button")

res2: net.liftweb.common.Box[net.liftweb.util.CssSelector] = Empty

scala> CssSelectorParser parse ("#button")

res3: net.liftweb.common.Box[net.liftweb.util.CssSelector] = Empty

scala> "button" #> "xxx"

<console>:11: error: value #> is not a member of String

              "button" #> "xxx"

                       ^

scala> import Helpers._

import Helpers._

scala> "button" #> "xxx"

res5: net.liftweb.util.CssSel = CssBind(Full(button), Empty)

scala> res5 apply <button/>

res6: scala.xml.NodeSeq = 

<div class="snippeterror" style="display: block; padding: 4px; margin: 8px; border: 2px solid red">

             <div>

        Syntax error in CSS selector definition:

        button

        .

        The selector will not be applied.

      </div>

          <i>note: this error is displayed in the browser because

          your application is running in &quot;development&quot; or &quot;test&quot; mode.If you

          set the system property run.mode=production, this error will not

          be displayed, but there will be errors in the output logs.

          </i>

          </div>

scala> new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

<console>:14: error: not found: value Full

              new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

                                    ^

<console>:14: error: not found: value str

              new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

                                                                       ^

scala> val str = "button"

str: String = button

scala> new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

<console>:15: error: not found: value Full

              new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

                                    ^

scala> import net.liftweb.common._

import net.liftweb.common._

scala> new ToCssBindPromoter(Full(str), CssSelectorParser.parse(str))

res9: net.liftweb.util.ToCssBindPromoter = ToCssBindPromoter(Full(button),Empty)

scala> res9 #> "xxx"

res10: net.liftweb.util.CssSel = CssBind(Full(button), Empty)

scala> res10 apply <button/>

res11: scala.xml.NodeSeq = 

<div class="snippeterror" style="display: block; padding: 4px; margin: 8px; border: 2px solid red">

             <div>

        Syntax error in CSS selector definition:

        button

        .

        The selector will not be applied.

      </div>

          <i>note: this error is displayed in the browser because

          your application is running in &quot;development&quot; or &quot;test&quot; mode.If you

          set the system property run.mode=production, this error will not

          be displayed, but there will be errors in the output logs.

          </i>

          </div>

scala> res10 calculate <button/>

<console>:20: error: value calculate is not a member of net.liftweb.util.CssSel

       res10 calculate <button/>

             ^

scala> res10.asInstanceOf[CssBind] calculate <button/>

res13: Seq[scala.xml.NodeSeq] = List(xxx)

[Naftoli Gugenheim]

It's only broken since the "multiple css selector" commit, and only on 2.10.

Incidentally what is 26.toChar supposed to be doing?

 private lazy val topParser: Parser[CssSelector] =
    phrase(rep1((_idMatch | _nameMatch | _classMatch | _attrMatch | _elemMatch |
      _colonMatch | _starMatch) <~ (rep1(' ') | 26.toChar)) ~ opt(subNode)) ^^ {

[Diego Medina]

On Thu, Sep 13, 2012 at 11:31 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> It's only broken since the "multiple css selector" commit, and only on 2.10.

So, is it a bug in scala 2.10?

>
> Incidentally what is 26.toChar supposed to be doing?
>
> private lazy val topParser: Parser[CssSelector] =
> phrase(rep1((_idMatch | _nameMatch | _classMatch | _attrMatch |
> _elemMatch |
> _colonMatch | _starMatch) <~ (rep1(' ') | 26.toChar)) ~ opt(subNode))
> ^^ {
>

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
>
>



--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Peter Petersson]

Diego it's seems more likely that this is a problem in lift that manifest itself when run with Scala 2.1 but I guess that's what you are asking?

2012/9/14 Diego Medina <di...@fmpwizard.com>

[Diego Medina]

On Fri, Sep 14, 2012 at 11:27 AM, Peter Petersson
<peterss...@gmail.com> wrote:
> Diego it's seems more likely that this is a problem in lift that manifest
> itself when run with Scala 2.1 but I guess that's what you are asking?
>

I meant to ask, is this a regression bug in scala 2.10, that should be
reported there? or have we been lucky and (not knowing) relied on a
bug that was finally fixed in scala 2.10?

Thanks

Diego

[Naftoli Gugenheim]

Josh Seureth (he searched the git history) says it was a fix to "phrase" for 2.10; the previous behavior was wrong.

In any case checking for CharSequenceReader.EofCh is a real hack. The important question is how to rewrite the parser.

[Peter Petersson]

Reading Natfoli's prev. post on this [1] and reading (and quoting from) M Odesky's Programing in Scala on implicit's rules "the implicit conversion must be in scope **as a single identifier**" I got the impression that, as the compiler checks seems to be more rigid in Scala 2.10, this (potential "ambiguity") has now manifest itself, but it is probably more to it than that, I am far from a expert on FP and Scala ;).

[1] http://mail.google.com/mail/u/0/#label/[Lift]/139c07ed2054d5b9

best regards
  Peter Petersson

[Diego Medina]

On Fri, Sep 14, 2012 at 6:06 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
> Josh Seureth (he searched the git history) says it was a fix to "phrase" for
> 2.10; the previous behavior was wrong.
> In any case checking for CharSequenceReader.EofCh is a real hack. The
> important question is how to rewrite the parser.

do you have a 2.10 branch, or does master work fine (except for this issue)?

Thanks for trying lift with scala 2.10

Diego

[Naftoli Gugenheim]

On Sat, Sep 15, 2012 at 9:00 AM, Diego Medina <di...@fmpwizard.com> wrote:

do you have a 2.10 branch, or does master work fine (except for this issue)?

Sorry, I didn't understand the question. I have a local branch which I'm trying to get to work with 2.10.0-M7 (all the main modules, i.e., mapper and all its dependencies, build). Master works fine and does not have this issue, since it doesn't build against 2.10.

[Naftoli Gugenheim]

This issue is unrelated to my previous post. That issue is indeed due to 2.10's more correct enforcement of the spec on imports. If two identifiers with the same name are imported from different places, it is ambiguous and an error to use them. I'm not even sure that that is what changed. It could be the only change was in regard to implicits keeping to the general rule (in other words, it could be that before, implicits worked in a way that "explicits" could not).

[Naftoli Gugenheim]

On Sun, Sep 16, 2012 at 3:44 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

This issue is unrelated to my previous post. That issue is indeed due to 2.10's more correct enforcement of the spec on imports. If two identifiers with the same name are imported from different places, it is ambiguous and an error to use them. I'm not even sure that that is what changed. It could be the only change was in regard to implicits keeping to the general rule (in other words, it could be that before, implicits worked in a way that "explicits" could not).

However this is a separate issue, and is due to fixing a bug in the parsers, that allowed for the 26.toChar hack.

[Naftoli Gugenheim]

I "updated" the hack: https://github.com/lift/framework/commit/b8e4419d988d336f17837b0b537552fbe11f8131

I haven't tested it on 2.9 yet.