scalacheck + trunk almost there

On Mon, Aug 24, 2009 at 1:26 AM, Paul Phillips wrote:
> Scala patched along the lines of ticket #2201 and randomizing some of
> adriaan's recent changes re HK/raw types:
>
>  http://github.com/paulp/scala/tree/scalacheck
>
> Scalacheck with almost all the necessary patches (there is an inference
> failure that might be another bug, but you can fiddle around it.)
>
>  http://scalacheck.googlecode.com/svn/branches/HEAD-Scala2.8/
>
> And scala passes all its own tests and scalacheck built with that scala
> also passes all its own tests.

At least for me I never get that far. Every version after 18537 fails
to build for me. Adriaan noticed some random failures, and it seems
they are systematic on my machine. We urgently need to get this under
control!

Here's some samle output. I believe it is related to the change from
identity to conforms.

The other question is, why does Hudson not complain?

Very mysterious

Looking some more at it, I believe it's a bootstrap problem, caused by
the change from identity to conforms. I am not sure what exactly is in
starr, but that's clearly the problem. The only way out I see is to
retrace partially our steps: Instead of replacing Predef.identity by
Predef.conforms, we need to have both as implicits for the time being.
To avoid ambiguities, <:< should not have an apply method and should
not inherit from Function1. replace it by a convert method that's
explicitly invoked from code that needs the conversion. Once we have
this working, we can make a new starr. And only after that we can
start making identity not implicit. Once that works, we can give
conforms full function status.

Adriaan, can you look into his, please? I am pretty much blocked by the issue.

Thanks

Looking some more at it, I believe it's a bootstrap problem, caused by
the change from identity to conforms. I am not sure what exactly is in
starr, but that's clearly the problem. The only way out I see is to
retrace partially our steps: Instead of replacing Predef.identity by
Predef.conforms, we need to have both as implicits for the time being.
To avoid ambiguities, <:< should not have an apply method and should
not inherit from Function1. replace it by a convert method that's
explicitly invoked from code that needs the conversion. Once we have
this working, we can make a new starr. And only after that we can
start making identity not implicit. Once that works, we can give
conforms full function status.

Adriaan, can you look into his, please? I am pretty much blocked by the issue.

Thanks

On Mon, Aug 24, 2009 at 03:03:21PM +0200, martin odersky wrote:
> The other question is, why does Hudson not complain?

It did, but unfortunately there is enough noise in the nightly output
that I expect we are all automatically tuning out everything to do with
windows, msil, etc. I know I am. The subject line says "Build failed
in Hudson" whether it's a slightly changed position in a single test
case or a total inability to build locker.

Here is the nightly windows job failing, unable to find Nil:

http://scala-webapps.epfl.ch/hudson/job/scala-nightly-windows/282/console