- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: scalacheck + trunk almost there
Mon, 2009-08-24, 14:24
On Mon, Aug 24, 2009 at 3:23 PM, Adriaan
Moors wrote:
> ok, working on it now.
> adriaan
>
Thanks! -- Martin
> On Mon, Aug 24, 2009 at 3:20 PM, martin odersky
> wrote:
>>
>> 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
>>
>> -- Martin
>>
>> On Mon, Aug 24, 2009 at 3:03 PM, martin odersky
>> wrote:
>> > 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
>> >
>> > -- Martin
>> >
>> > init:
>> > [echo] Build number is '2.8.0.r18557-b20090824144434'
>> > [echo] Built 24 August 2009, 14:44:34 from revision 18557 with
>> > Java HotSpot(TM) Server VM 1.5.0_16
>> >
>> > locker.start:
>> >
>> > locker.pre-lib:
>> >
>> > locker.lib:
>> > [mkdir] Created dir:
>> > /home/odersky/scala-old/2.8.0/build/locker/classes/library
>> > [javac] Compiling 12 source files to
>> > /home/odersky/scala-old/2.8.0/build/locker/classes/library
>> > [scalacfork] Compiling 1 file to
>> > /home/odersky/scala-old/2.8.0/build/locker/classes/library
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/collection/generic/LinkedListTemplate.scala:14:
>> > error: tailrec is not a member of annotation
>> > [scalacfork] import annotation.tailrec
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/collection/mutable/MutableList.scala:102:
>> > error: not found: value Nil
>> > [scalacfork] override def toList: List[A] = if (first0 eq null) Nil
>> > else first0.toList
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/reflect/Manifest.scala:43:
>> > error: not found: value Nil
>> > [scalacfork] (if (subSuperClass == null) Nil else
>> > List(subSuperClass)) ::: subSuperInterfaces
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/xml/dtd/ExternalID.scala:76:
>> > error: not found: value Nil
>> > [scalacfork] def child = Nil
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/xml/parsing/FactoryAdapter.scala:191:
>> > error: not found: value Nil
>> > [scalacfork] var v: List[Node] = Nil
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/xml/factory/NodeFactory.scala:55:
>> > error: not found: value Nil
>> > [scalacfork] case None => cons(Nil)
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/xml/factory/NodeFactory.scala:61:
>> > error: not found: value Nil
>> > [scalacfork] if (ignoreComments) Nil else List(Comment(s))
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/xml/factory/NodeFactory.scala:63:
>> > error: not found: value Nil
>> > [scalacfork] if (ignoreProcInstr) Nil else List(ProcInstr(t, s))
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/collection/mutable/Stack.scala:26:
>> > error: not found: value Nil
>> > [scalacfork] def this() = this(Nil)
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/collection/mutable/Stack.scala:102:
>> > error: not found: value Nil
>> > [scalacfork] def clear(): Unit = elems = Nil
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/util/automata/WordBerrySethi.scala:129:
>> > error: not found: value Nil
>> > [scalacfork] case _ => Nil
>> > [scalacfork] ^
>> > [scalacfork]
>> > /home/odersky/scala-old/2.8.0/src/library/scala/util/automata/WordBerrySethi.scala:159:
>> > error: not found: value Nil
>> > [scalacfork] defaultq(j) = Nil
>> > [scalacfork] ^
>> > [scalacfork] 12 errors found
>> >
>> > BUILD FAILED
>> > /home/odersky/scala-old/2.8.0/build.xml:232:
>> > java.lang.RuntimeException: Compilation failed because of an internal
>> > compiler error; see the error output for details.
>> >
>>
>>
>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
Mon, 2009-08-24, 14:47
#2
Re: scalacheck + trunk almost there
On Mon, Aug 24, 2009 at 3:32 PM, Adriaan
Moors wrote:
> The newstarr build is running with the changes you indicated. I'll commit as
> soon as it's done.
> In the meantime, I'm still puzzled while the exact same starr works fine on
> linux&mac, but fails on windows. This seems indicative of an additional
> problem (besides the bootstrapping problem, which I thought I had fixed by
> leaving `def identity` in there, though stripped from its `implicit`
> status), although I have to admit I don't even know where to look...
> adriaan
>
Bootstrap issues can be rather mind-blowing. Better do real baby-steps there.
Cheers
Mon, 2009-08-24, 14:57
#3
nightly output
Not to belabor that point, but as long as we're on the subject: here is
what my mailer shows as the subject lines of all the messages I've
received on scala-reports since july 1st with scala-nightly-windows in
the subject line. At least two reasons it's super easy to overlook
something like windows unable to build:
1) Failure is the normal case. That's the killer.
2) The cause of the failure is typically at the very end after many
screenfuls of the computer equivalent of an employee saying "first the
good news! this works, this works, this works..." before he gets around
to telling you that your primary data center just burned down and you
have no insurance.
(Third might be very few of us who are paying some attention use
windows.)
1308 Jul 01 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #2d2d2d
1316 Jul 02 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #2f2f2f
1328 Jul 03 scala-devel@epfl.ch ( 0.1K) [scala-reports] Hudson build is back to normal: scala-nightly-windows #313131
1383 Jul 12 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #393939
1387 Jul 13 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #3b3b3b
1397 Jul 14 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #3d3d3d
1408 Jul 15 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #3f3f3f
1415 Jul 16 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #414141
1428 Jul 17 scala-devel@epfl.ch ( 20K) [scala-reports] Build failed in Hudson: scala-nightly-windows #434343
1444 Jul 18 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #3c3c3c
1453 Jul 19 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #3e3e3e
1456 Jul 20 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #404040
1466 Jul 21 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #414141
1487 Jul 22 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #434343
1495 Jul 23 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #454545
1501 Jul 24 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #474747
1514 Jul 25 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #494949
1523 Jul 26 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4b4b4b
1532 Jul 27 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4d4d4d
1543 Jul 28 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #464646
1555 Jul 29 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #484848
1570 Jul 30 scala-devel@epfl.ch ( 12K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4a4a4a
1581 Jul 31 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4b4b4b
1595 Aug 01 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4d4d4d
1597 Aug 02 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #4f4f4f
1601 Aug 03 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #515151
1611 Aug 04 scala-devel@epfl.ch ( 0.1K) [scala-reports] Hudson build is back to normal: scala-nightly-windows #535353
1616 Aug 05 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #555555
1619 Aug 06 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #575757
1654 Aug 12 scala-devel@epfl.ch ( 0.1K) [scala-reports] Hudson build is back to normal: scala-nightly-windows #505050
1660 Aug 13 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #525252
1669 Aug 14 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #545454
1680 Aug 15 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #565656
1684 Aug 16 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #575757
1704 Aug 17 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #595959
1726 Aug 18 scala-devel@epfl.ch ( 19K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5b5b5b
1740 Aug 19 scala-devel@epfl.ch ( 18K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5d5d5d
1756 Aug 20 scala-devel@epfl.ch ( 11K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5f5f5f
1782 Aug 21 scala-devel@epfl.ch ( 14K) [scala-reports] Build failed in Hudson: scala-nightly-windows #616161
1810 Aug 22 scala-devel@epfl.ch ( 13K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5a5a5a
1826 Aug 23 scala-devel@epfl.ch ( 13K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5c5c5c
1835 Aug 24 scala-devel@epfl.ch ( 10K) [scala-reports] Build failed in Hudson: scala-nightly-windows #5e5e5e
Mon, 2009-08-24, 15:07
#4
Re: nightly output
I agree. We need to make sure that failure is the exception not the rule.
That means if some build (such as msil) is expected to fail for some
longer period, we need to remove it from the mails.
Cheers
Mon, 2009-08-24, 15:17
#5
Re: scalacheck + trunk almost there
Martin,
I just committed a new starr (http://lampsvn.epfl.ch/trac/scala/changeset/18559/scala/trunk) that is based on r18539(*) and your changes (http://lampsvn.epfl.ch/trac/scala/changeset/18558/scala/trunk)
The newstarr target is still running, but it has successfully completed the *second* quick.lib on my machine, so I hope it'll work...
sorry about the mess :-(
adriaan
ps: (*) sorry, being in a hurry, I forgot to update to head first -- building another starr based on your changes applied to trunk's head now...
On Mon, Aug 24, 2009 at 3:43 PM, martin odersky <martin.odersky@epfl.ch> wrote:
I just committed a new starr (http://lampsvn.epfl.ch/trac/scala/changeset/18559/scala/trunk) that is based on r18539(*) and your changes (http://lampsvn.epfl.ch/trac/scala/changeset/18558/scala/trunk)
The newstarr target is still running, but it has successfully completed the *second* quick.lib on my machine, so I hope it'll work...
sorry about the mess :-(
adriaan
ps: (*) sorry, being in a hurry, I forgot to update to head first -- building another starr based on your changes applied to trunk's head now...
On Mon, Aug 24, 2009 at 3:43 PM, martin odersky <martin.odersky@epfl.ch> wrote:
On Mon, Aug 24, 2009 at 3:32 PM, Adriaan
Moors<adriaan.moors@cs.kuleuven.be> wrote:
> The newstarr build is running with the changes you indicated. I'll commit as
> soon as it's done.
> In the meantime, I'm still puzzled while the exact same starr works fine on
> linux&mac, but fails on windows. This seems indicative of an additional
> problem (besides the bootstrapping problem, which I thought I had fixed by
> leaving `def identity` in there, though stripped from its `implicit`
> status), although I have to admit I don't even know where to look...
> adriaan
>
Bootstrap issues can be rather mind-blowing. Better do real baby-steps there.
Cheers
Mon, 2009-08-24, 16:17
#6
Re: scalacheck + trunk almost there
Hi Adriaan,
I confirmed that it builds again for me (note that I was always on
Linux, did not test Windows yet). GThanks for the quick reaction!
In the meantime, I'm still puzzled while the exact same starr works fine on linux&mac, but fails on windows. This seems indicative of an additional problem (besides the bootstrapping problem, which I thought I had fixed by leaving `def identity` in there, though stripped from its `implicit` status), although I have to admit I don't even know where to look...
adriaan
On Mon, Aug 24, 2009 at 3:24 PM, martin odersky <martin.odersky@epfl.ch> wrote: