[scala] Lift will be sitting out RC1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
dpp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[scala] Lift will be sitting out RC1

dpp
Folks,

I've spent most of the morning trying to port Lift to Scala 2.8.0.RC1 and have hit some serious problems:
  • XML comparison behaves differently than in prior versions of Scala.  This means that many tests that compare XML fail.  I don't know where this will impact production code, but anywhere that there's XML comparison will silently behave differently.
  • There seems to be a problem with duplicate names for objects that are created inside of methods (if the same object name is used across multiple methods, the compiler crashes.)  The particularly difficult issue here is that in Maven if the compiler crashes while compiling tests, the tests are silently ignored.
  • I have run into cases where the compiler is not able to generate a Manifest for a parameter that's passed in.
  • JDK 1.4 annotations that expect a java.lang.Class as a parameter are not happy with a java.lang.Class[_] (this means JPA doesn't work)
  • The type signature that Lift's Mapper uses for foreign key references causes the compiler to crash in the type checker
So, basically, Lift does not compile under 2.8 RC1 and even when I modify Lift to work around these defects, simple Lift apps don't compile correctly.

I will spend time on Monday (I'm behind on today's work and my day tomorrow is completely booked) writing up the defects.  In the mean time, you can check out http://github.com/dpp/liftweb/tree/280_failures to see the failures.

Indrajit -- Please roll the 280_port_refresh branch back to compiling against 2.8.0.Beta1 so that projects (including a couple of mine) that are running against the 2.8.0 code can continue to run.

EPFL -- In the future, before dropping an RC on the world, how about doing an explicit SNAPSHOT of the pre-release and letting the ecosystem give you some early feedback, get the various dependencies compiled and running, etc. so that when the RC does land, it's reasonably stable and the ecosystem is ready to update sbt scripts/poms/whatever and push builds out.

I personally, the Lift committers and the Lift community as a whole are committed to supporting EPFL and the greater Scala ecosystem.  We all want Scala to be great and the Scala ecosystem  to grow, to thrive and that Scala is regarded by the broader developer communities as a place the delivers reliable, high quality systems that can be trusted.  Let's all work together to take the steps necessary to insure both the reality and the perception that Scala is rock solid.

Thanks,

David

--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Paul Phillips-3
On Thu, Apr 15, 2010 at 11:17:12AM -0700, David Pollak wrote:
>    - XML comparison behaves differently than in prior versions of Scala.
>    This means that many tests that compare XML fail.  I don't know where this
>    will impact production code, but anywhere that there's XML comparison will
>    silently behave differently.

That is true.  I was really looking for some help on this one.  I sent
out an email laying it out and asking for that way back when I did it.  
The changes I made were the minimum I could see to not have outright
inconsistencies and asymmetries in the equality of classes we ship with
the standard distribution.  I can't see how anyone else can be expected
to write a symmetric equals if we can't do it ourselves.

I was afraid that warning with Xmigration (did you use this?) would add
up to a lot of warnings, but I can have it do that if you like.  
Specific examples of where it actually came up in practice would be
helpful too.

--
Paul Phillips      | Every election is a sort of advance auction sale
Caged Spirit       | of stolen goods.
Empiricist         |     -- H. L. Mencken
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Alex Cruise-2
On 10-04-15 12:37 PM, Paul Phillips wrote:
> [...]
> Specific examples of where it actually came up in practice would be
> helpful too.
>    
I second this!

David,

If "your people" could collect examples of the top 5-10 types of
situations in which x.equalsInScala27(y) but !x.equalsInScala28(y)  that
would be most helpful--at least then we'd have something very concrete
to discuss and write test cases against.

Maybe an URL to a failing Hudson build log would be a good start?  I've
tried to find Lift's Hudson but failed.

-0xe1a
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Paul Phillips-3
On Thu, Apr 15, 2010 at 01:51:15PM -0700, Alex Cruise wrote:
> If "your people" could collect examples of the top 5-10 types of
> situations in which x.equalsInScala27(y) but !x.equalsInScala28(y)
> that would be most helpful--at least then we'd have something very
> concrete to discuss and write test cases against.

Oh, also, here's an excerpt from the commit message.  Me and community
had a nice time discussing the patch, although he was a little quieter
than usual.

    For anyone who was relying upon the 2.7 equality behavior for
    scala.xml.* classes, using "xml_==" instead of "==" for comparisons
    will restore the old behavior.  The standard == on xml elements
    now attempts to behave in such a way that symmetry and hashCode
    contracts will be preserved.  It's probably not 100% there yet,
    but I can tell you this: it is closer today than it was yesterday.
   
    Review by community.

--
Paul Phillips      | We must respect the other fellow's religion, but only
Future Perfect     | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
slap pi uphill!    |     -- H. L. Mencken
dpp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

dpp


On Thu, Apr 15, 2010 at 2:16 PM, Paul Phillips <[hidden email]> wrote:
On Thu, Apr 15, 2010 at 01:51:15PM -0700, Alex Cruise wrote:
> If "your people" could collect examples of the top 5-10 types of
> situations in which x.equalsInScala27(y) but !x.equalsInScala28(y)
> that would be most helpful--at least then we'd have something very
> concrete to discuss and write test cases against.

Oh, also, here's an excerpt from the commit message.  Me and community
had a nice time discussing the patch, although he was a little quieter
than usual.

   For anyone who was relying upon the 2.7 equality behavior for
   scala.xml.* classes, using "xml_==" instead of "==" for comparisons
   will restore the old behavior.  The standard == on xml elements
   now attempts to behave in such a way that symmetry and hashCode
   contracts will be preserved.  It's probably not 100% there yet,
   but I can tell you this: it is closer today than it was yesterday.

   Review by community.

Paul,

My concern is not that the XML comparison stuff changed, my concern is how the change was presented.  I learned of it along with a series of regressions.  If there had been monthly milestone builds, we would have been able to work through issues like this without the concern that EPFL (1) expects that the APIs are stable and (2) EPFL may declare 2.8 final at any moment.

Given that RC1 is a material regression from Beta1 based on the code bases I've ported to 2.8,  I'm sending up a flag that says, "Whoa buck.  Slow it down.  Let's increase the level of communication and coordination so the community knows what's coming and when and can plan and test.  And no, nightlies are not enough.  Well defined snapshots that come at a predictable frequency are an absolute necessity for the library authors to coordinate and give feedback before 2.8 is finalized."

Thanks,

David
 

--
Paul Phillips      | We must respect the other fellow's religion, but only
Future Perfect     | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
slap pi uphill!    |     -- H. L. Mencken



--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Paul Phillips-3
On Thu, Apr 15, 2010 at 04:13:05PM -0700, David Pollak wrote:
> My concern is not that the XML comparison stuff changed, my concern is
> how the change was presented.  I learned of it along with a series of
> regressions.  If there had been monthly milestone builds, we would
> have been able to work through issues like this without the concern
> that EPFL (1) expects that the APIs are stable and (2) EPFL may
> declare 2.8 final at any moment.

As you know, I'm not the one who needs convincing.  I'm just pointing
out that when it comes to that change, I did my best to get input before
now.  It's a pretty quiet echo chamber most of the time, and it'd be
better for everyone if there was a little more regular feedback.

--
Paul Phillips      | Those who can make you believe absurdities
In Theory          | can make you commit atrocities.
Empiricist         |     -- Voltaire
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Jan Kriesten
In reply to this post by dpp

Hi David,

>     * There seems to be a problem with duplicate names for objects that
>       are created inside of methods (if the same object name is used
>       across multiple methods, the compiler crashes.)  The particularly
>       difficult issue here is that in Maven if the compiler crashes
>       while compiling tests, the tests are silently ignored.

I stumbled over exactly this one today morning as well - will you file a bug for
this?

Best regards, --- Jan.

dpp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

dpp


On Fri, Apr 16, 2010 at 2:48 AM, Jan Kriesten <[hidden email]> wrote:

Hi David,

>     * There seems to be a problem with duplicate names for objects that
>       are created inside of methods (if the same object name is used
>       across multiple methods, the compiler crashes.)  The particularly
>       difficult issue here is that in Maven if the compiler crashes
>       while compiling tests, the tests are silently ignored.

I stumbled over exactly this one today morning as well - will you file a bug for
this?

Jan,

I'd appreciate it if you could file the bug.  I'm not going to have a chance to build a repro case until Monday, so the sooner the Scala team has to get started, the better the next RC will be.

Thanks,

David
 

Best regards, --- Jan.




--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Martin Odersky
We are aware that specialization currently has issues and will hopefully fix this quickly for an RC2. Meanwhile, if you get a compiler crash, check the stacktrace if there's some SpecializeTypes instances in there and compile again with -no-specialization. That should let you identify any other issues without getting side-tracked by specialization problems which will hopefully be sorted out soon.

Thanks

 -- Martin


On Fri, Apr 16, 2010 at 6:07 PM, David Pollak <[hidden email]> wrote:


On Fri, Apr 16, 2010 at 2:48 AM, Jan Kriesten <[hidden email]> wrote:

Hi David,

>     * There seems to be a problem with duplicate names for objects that
>       are created inside of methods (if the same object name is used
>       across multiple methods, the compiler crashes.)  The particularly
>       difficult issue here is that in Maven if the compiler crashes
>       while compiling tests, the tests are silently ignored.

I stumbled over exactly this one today morning as well - will you file a bug for
this?

Jan,

I'd appreciate it if you could file the bug.  I'm not going to have a chance to build a repro case until Monday, so the sooner the Scala team has to get started, the better the next RC will be.

Thanks,

David
 

Best regards, --- Jan.




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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Lift will be sitting out RC1

Jan Kriesten

Hi Martin,

> We are aware that specialization currently has issues and will hopefully
> fix this quickly for an RC2. Meanwhile, if you get a compiler crash,
> check the stacktrace if there's some SpecializeTypes instances in there
> and compile again with -no-specialization. That should let you identify
> any other issues without getting side-tracked by specialization problems
> which will hopefully be sorted out soon.

using -no-specialization fixed the compiler crash for me. So I wait before
opening a ticket for RC2.

Best regards, --- Jan.


Loading...