[Lift] Re: [scala-internals] RC8 candidate for the first 2.8.0 beta

2010-01-21 Thread martin odersky
(Un)fortunately I have an idea what the problem is. It's probably my
fix for #2867. I have now rolled back that fix in r20629. Can you
check again whether it works with that revision (should be in the
nightly tomorrow)? If it does we might be able to make an exception to
our RC = final rule, because this one just rolls back a non-critical
patch, so I fail to see how this could affect anything but the
original ticket.

Cheers

 -- Martin
-- 
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: [scala-internals] RC8 candidate for the first 2.8.0 beta

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 I've written a work-around and am currently testing the code more in a
 few minutes.

If you can make it work, so much the better. To give some info: The
original ticket had a vararg parameter of the form List[_]* in a case
class. This caused type inference for the synthetic equals method
(which uses sameElements for varargs) to fail, because the existential
in List[_] made the problem underconstrained. The patch passed the
argument type explicitly as the type parameter. In the lift case, it
seems that this explicit type parameter violated some type bound, so
the type inferencer should have chosen a more general type which would
not violate the bound. The easiest fix is probably to just roll back
and leave ticket #2867 open until we find a better solution. That's
what I have done.

Cheers

 -- Martin
-- 
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: [scala-internals] RC8 candidate for the first 2.8.0 beta

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:37 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 Okay... the work-around is checked into the Lift repo.

 I say, Ship RC8 as the beta and we'll work through this (and likely other)
 issues during the beta period.

Sounds good. Thanks! -- Martin

 On Thu, Jan 21, 2010 at 11:36 AM, martin odersky martin.oder...@epfl.ch
 wrote:

 On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
  I've written a work-around and am currently testing the code more in
  a
  few minutes.
 
 If you can make it work, so much the better. To give some info: The
 original ticket had a vararg parameter of the form List[_]* in a case
 class. This caused type inference for the synthetic equals method
 (which uses sameElements for varargs) to fail, because the existential
 in List[_] made the problem underconstrained. The patch passed the
 argument type explicitly as the type parameter. In the lift case, it
 seems that this explicit type parameter violated some type bound, so
 the type inferencer should have chosen a more general type which would
 not violate the bound. The easiest fix is probably to just roll back
 and leave ticket #2867 open until we find a better solution. That's
 what I have done.

 Cheers

  -- Martin



 --
 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 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth joshua.suer...@gmail.com wrote:
 I think staying in maven would require the least amount of typing, but the
 most amount of time as you'd have to publish local snapshots of Scala 2.8.0
 to use them in the lift build.  I remember how annoying this is ;).   Also
 note that deploying maven requires a full scala build, but if needed I can
 make a short-cut that will just publish the quick libraries.  This would
 help immensely in testing trunk against projects, but is not very helpful
 otherwise.  Would this be desirable?

 What was already suggested (runing mvn dependency:copy-dependencies) is very
 viable.   However, if lift-mapper relies on lift-util, you'll have to
 rebuild one before you rebuild the other if you're somehow changing the ABI.

 If you still wanted to use maven, I recommend using the reactor plugin.   If
 you identify the project that is failing you can run:

 mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper

 Where net.liftweb:lift-mapper is the groupId:artifactId containing the
 failing module.  This will only build the lift-mapper module and other
 modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
 (and only lift-util) just those two will be built.

 I have a local VM where I was setting up a scala nightly build that would
 feed maven.  Perhaps when I finish I'll make a write-up on how to do this,
 or have some kind of template/script you can use to do it by hand.

 - Josh

Hi Josh,

The problem is not so much building individual maven modules, but
building them with experimental compilers. I need to be able to put a
println into scalac, rebuild that (takes 10sec with fsc) and then
recompile the offending maven part with that compiler. That's why I
need a version of lift that can be compiled without maven. It need not
be perfect, for instance one can probably throw out all the tests. But
I need to be able to use lift as a rapid experimentation tool for the
scala compiler itself.

Unfortunately, LAMP is pretty much shutting down for the holidays
right now. So any outside help that you can give is appreciated.
Ideally: I get the right lift version as a tarball, together with all
jars that it needs. Then, instructions what to compile in what order
(I can probably figure them out in a pinch, but if someone knows that
already, it would help).

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth joshua.suer...@gmail.com wrote:
 For curiousities sake, if you're building using fsc, are you running scalac
 via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to come
 up with a longer-term solution for this.

Yes, exactly. My usual setup is that my output directory is the first
item on the classpath. So any files I recompile get chosen first.


 If we allowed you to do the following:

 mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
 -Dscala.local.classpath=classfiledir

 would that be sufficient?  We could also have this do conditional
 computation in the future.

Does that mean that the scala compiler would then be run out of
classfiledir? Yes, that could work.

Cheers

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
 Martin,
 OK, now I got it working (almost) without Maven:
 1. step:
 Check out 280_port branch from ...@github.com:dpp/liftweb.git
 2. step:
 cd into liftweb/lift-persistence/lift-mapper and run
 mvn dependency:copy-dependencies
 3. step:
 run the following command
 PATH-TO-SCALAC-OR-FSC-2.8-BETA1-RC5 -classpath `find target/dependency
 -name *.jar | xargs scala -e 'println(args mkString :)'` -sourcepath
 src/main/scala -d target/classes `find src/main/scala -name *.scala`
 This will only use Maven to download the dependencies, but you can compile
 with scalac or fsc.

Great! Can you provide me with a tarball or zip of the lift sources? I
don't have git installed here yet.

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
Thanks for all the help. I tried to do

mvn clean
mvn install

After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch
of packages including lift-mapper, so it seems it did not in fact take
RC6 as its compiler?

But then it stopped due to a build error here.

Any idea what I need to do to solve this?

Thanks

 -- martin



[INFO] [INFO] 

[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] 

[INFO] [INFO] Failed to resolve artifact.
[INFO]
[INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19,
6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]
[INFO] [INFO] 

[INFO] [INFO] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
[INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
[INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO]  at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]  at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO]  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO]  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO]  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] Caused by:
org.apache.maven.artifact.versioning.OverConstrainedVersionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
[INFO]  ... 17 more
[INFO] [INFO] 

[INFO] [INFO] Total time: 6 seconds
[INFO] [INFO] Finished at: Tue Dec 22 17:26:55 CET 2009
[INFO] [INFO] Final Memory: 12M/127M
[INFO] [INFO] 

Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
I just verified that it did indeed use 2.7.7, because the generated
classfiles still have version 4.1.

My new strategy is to build with the last working RC3, and then
recompile just the failing file with the current compiler and all lift
classes on the classpath. That should work.

But I need to know how to build lift with a 2.8.0 compiler. Or
alternatively, if a kind soul can send me a lift 2.8.0 tarball with
all the classfiles in there I can take it from there.

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:
 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

 See if that works.

But even then I only get a 2.7.7 build, which is not what I need?

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:
 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

... and, which test:sample are you referring to?

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:

 On 22/12/09 10:44 PM, martin odersky wrote:

 On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 indraj...@gmail.com  wrote:

 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

 ... and, which test:sample are you referring to?

 Thanks

  -- Martin

 The test:sample:war:0.1 artifact for which it fails. By your question, I
 realize that you are encountering this during archetype generation. It's
 completely unnecessary.

 edit the top level pom.xml and remove all the modules other than lift-base,
 lift-persistence and lift-modules for now. They are really all that you
 need.

 The modules section in your top level pom.xml should have just this.

  modules
    modulelift-base/module
    modulelift-persistence/module
    modulelift-modules/module
    !--modulelift-archetypes/module--
    !--modulelift-examples/module--

    !-- the 'meta' module --
    !--modulelift-core/module--
  /modules

 - Indrajit


OK, that will help, I hope.

But I still have no luck. When I download from

  http://github.com/dpp/liftweb/tree/280_port

I get something that's different than the layout on the webpage.
Subdirectories in dpp-liftweb-12d1bf0/
are flatter than what I see on the webpage. When I compile with 2.8 it
dies because it wants jcl.Conversions which sure does not exist
anymore. So it seems to me that versions are mixed up? I really need a
tarball or zip with the right lift to test against!

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
I found someone who could download the repository with git. So trying
again now.

 -- Martin

On Tue, Dec 22, 2009 at 6:36 PM, martin odersky martin.oder...@epfl.ch wrote:
 On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
 indraj...@gmail.com wrote:

 On 22/12/09 10:44 PM, martin odersky wrote:

 On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 indraj...@gmail.com  wrote:

 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

 ... and, which test:sample are you referring to?

 Thanks

  -- Martin

 The test:sample:war:0.1 artifact for which it fails. By your question, I
 realize that you are encountering this during archetype generation. It's
 completely unnecessary.

 edit the top level pom.xml and remove all the modules other than lift-base,
 lift-persistence and lift-modules for now. They are really all that you
 need.

 The modules section in your top level pom.xml should have just this.

  modules
    modulelift-base/module
    modulelift-persistence/module
    modulelift-modules/module
    !--modulelift-archetypes/module--
    !--modulelift-examples/module--

    !-- the 'meta' module --
    !--modulelift-core/module--
  /modules

 - Indrajit


 OK, that will help, I hope.

 But I still have no luck. When I download from

  http://github.com/dpp/liftweb/tree/280_port

 I get something that's different than the layout on the webpage.
 Subdirectories in dpp-liftweb-12d1bf0/
 are flatter than what I see on the webpage. When I compile with 2.8 it
 dies because it wants jcl.Conversions which sure does not exist
 anymore. So it seems to me that versions are mixed up? I really need a
 tarball or zip with the right lift to test against!

  -- Martin


--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:48 PM, martin odersky martin.oder...@epfl.ch wrote:
 I found someone who could download the repository with git. So trying
 again now.

... and it builds with RC3. Great! So now I have something to work with ...

Cheers

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips pa...@improving.org wrote:
 On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote:
 But I need to know how to build lift with a 2.8.0 compiler. Or
 alternatively, if a kind soul can send me a lift 2.8.0 tarball with
 all the classfiles in there I can take it from there.

 FYI until you have git you can always download a tarball snapshot of the
 current head at github.  There's a download link here:

  http://github.com/dpp/liftweb

 Except you need the 280_port branch, so here:

  http://github.com/dpp/liftweb/tree/280_port

 And that download link goes here:

 http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156

 Assuming that gets the files it should, typing mvn install will try to
 build with 2.80 Beta1 RC3.  To use RC5 edit pom.xml with this diff:

 -    scala.version2.8.0.Beta1-RC3/scala.version
 +    scala.version2.8.0.Beta1-RC5/scala.version

 Instructions from earlier in this thread should get you to the point
 where you can build with the local compiler.

yes I got that working. The problem was that the download at 280_port
was not 280_port but (I guess) 280_dev. That got me stuck for a while,
but we sorted it out eventually.

Cheers

 -- Martin

--

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: [scala-internals] RC4 candidate for the first 2.8.0 beta

2009-12-21 Thread martin odersky
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky martin.oder...@epfl.ch wrote:
 Thanks for letting us know. This looks like something stirred up by
 the change in erasure. We'll investigate Monday what it is.

 Cheers

  -- Martin

I could reproduce the fault and think I found the underlying problem:
There was a problem with the erasure of self types  and it looks like
this problem was unmasked by my previous, unrelated change to erasure.
I'll think about a fix now.

Cheers

 -- Martin

--

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: [scala-internals] RC4 candidate for the first 2.8.0 beta

2009-12-20 Thread martin odersky
Thanks for letting us know. This looks like something stirred up by
the change in erasure. We'll investigate Monday what it is.

Cheers

 -- Martin

On Sun, Dec 20, 2009 at 11:43 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
 Lift built against RC3, but with RC4 we get this error:
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151)
 at
 org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26)
 Caused by: java.lang.AssertionError: assertion failed: type error: can't
 convert from REFERENCE(net.liftweb.util.StringHelpers) to
 REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit
 BasicTypesHelpers.scala
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79)
 at
 scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
 at
 scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
 at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48)
 at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281)
 at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
 at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
 at scala.collection.Iterator$class.foreach(Iterator.scala:582)
 at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285)
 at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72)
 at scala.tools.nsc.Global$Run.compileSources(Global.scala:749)
 at scala.tools.nsc.Global$Run.compile(Global.scala:839)
 at scala.tools.nsc.Main$.process(Main.scala:109)
 at scala.tools.nsc.Main$.main(Main.scala:123)
 at scala.tools.nsc.Main.main(Main.scala)
 ... 6 more
 Heiko
 My job: weiglewilczek.com
 My blog: heikoseeberger.name
 Follow me: