How to run partest with class files

36 views
Skip to first unread message

Simon Schäfer

unread,
Nov 22, 2013, 5:53:48 AM11/22/13
to scala-i...@googlegroups.com
I do not want to create jar files every time I want to run partest after
I did a change to scalac.

The hacker guide[1] told me that it is possible to launch Scala directly
from build/quick/classes. But how?

I tried

./test/partest -cp ~/dev/Scala/scala/build/quick/classes/compiler <file>

but it gave me an exception:

Uncaught exception on thread Thread[main,5,main]:
java.lang.RuntimeException: Error running
/home/antoras/dev/Scala/scala/build/quick/classes/compiler
java.lang.RuntimeException: Error running
/home/antoras/dev/Scala/scala/build/quick/classes/compiler
at scala.tools.partest.nest.SuiteRunner.liftedTree1$1(Runner.scala:778)
at scala.tools.partest.nest.SuiteRunner.runTest(Runner.scala:776)
at
scala.tools.partest.nest.SuiteRunner$$anonfun$19$$anonfun$apply$6.apply(Runner.scala:791)
at
scala.tools.partest.nest.SuiteRunner$$anonfun$19$$anonfun$apply$6.apply(Runner.scala:791)
at scala.tools.partest.package$$anon$2.call(package.scala:133)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.UnsupportedOperationException: tail of empty list
at scala.collection.immutable.Nil$.tail(List.scala:339)
at scala.collection.immutable.Nil$.tail(List.scala:334)
at scala.tools.partest.nest.Runner.groupedFiles(Runner.scala:398)
at scala.tools.partest.nest.Runner.compilationRounds(Runner.scala:480)
at
scala.tools.partest.nest.Runner$$anonfun$runTestCommon$1.apply$mcZ$sp(Runner.scala:509)
at scala.tools.partest.nest.Runner.runInContext(Runner.scala:392)
at scala.tools.partest.nest.Runner.runTestCommon(Runner.scala:508)
at scala.tools.partest.nest.Runner.run(Runner.scala:684)
at
scala.tools.partest.nest.SuiteRunner$$anonfun$liftedTree1$1$1.apply(Runner.scala:776)
at
scala.tools.partest.nest.SuiteRunner$$anonfun$liftedTree1$1$1.apply(Runner.scala:776)
at scala.tools.partest.package$.timed(package.scala:127)
at scala.tools.partest.nest.SuiteRunner.liftedTree1$1(Runner.scala:776)


[1]: http://www.scala-lang.org/contribute/hacker-guide.html

Jason Zaugg

unread,
Nov 22, 2013, 6:01:59 AM11/22/13
to scala-i...@googlegroups.com
On Fri, Nov 22, 2013 at 11:53 AM, Simon Schäfer <ma...@antoras.de> wrote:
I do not want to create jar files every time I want to run partest after I did a change to scalac.

I don't think that has worked (reliably? at all?) since modularization or partest. But I could be wrong there as I haven't tried passing the classpath directly to partest.

I believe that error you see is an unrelated bug in partest that shows up when you have empty directories under `test/files`.

-jason
 


--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Simon Schäfer

unread,
Nov 22, 2013, 6:13:04 AM11/22/13
to scala-i...@googlegroups.com

On 11/22/2013 12:01 PM, Jason Zaugg wrote:
On Fri, Nov 22, 2013 at 11:53 AM, Simon Schäfer <ma...@antoras.de> wrote:
I do not want to create jar files every time I want to run partest after I did a change to scalac.

I don't think that has worked (reliably? at all?) since modularization or partest.
I just run ant, which creates jars that later are used by partest (at least my changes are available, thus it works somehow).

But I could be wrong there as I haven't tried passing the classpath directly to partest.
I would also be satisfied with another way to run the tests without creating jars each time I do a change to scalac.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

Som Snytt

unread,
Nov 22, 2013, 12:57:26 PM11/22/13
to scala-internals
Using test/partest, you can (apparently) modify build/pack/partest.properties to point the classpath at your build/quick/classes/whatever.

That file is generated by ant test.suite.init from the path with the jars.

But it looks like ant test just uses the path directly (not the props file) so you don't get a chance to intervene.

See the comment:

"What's on the compiler's compilation path when compiling partest tests," you ask?

I guess --buildpath and --classpath are still around but unused.  In the old days, last Spring, partest options would just disappear altogether, like a dying cat.  Now it's more of a Cheshire cat, its grin reminding you of the absent feature.

I also saw the empty dir bug recently.  There was once an amusing comment on a filter that said something like, "if you don't like partest crashes and hangs, don't touch this," but that was refactored at some point.  I used to think refactor meant rewrite, but now I think it just means delete.

Adriaan Moors

unread,
Nov 22, 2013, 12:58:56 PM11/22/13
to scala-i...@googlegroups.com
This actually got easier with the new partest. The relevant classpath, partest.compilation.path, is constructed at https://github.com/scala/scala/blob/master/build.xml#L922.

To use the quick.bin classpath, I think it should suffice to replace

      <pathelement location="${library.jar}"/>
      <pathelement location="${reflect.jar}"/>
      <pathelement location="${compiler.jar}"/>

with

  <path refid="quick.bin.tool.path"/>
  <path refid="quick.interactive.build.path"/>

Note that it's serialized at https://github.com/scala/scala/blob/master/build.xml#L1881 to build/pack/partest.properties, so you may need to delete that file while changing the way it's generated.


Som Snytt

unread,
Nov 22, 2013, 3:14:14 PM11/22/13
to scala-internals
Would this be useful?

It seems macrodef attributes must be stringified properties?  Is there any reason not to do that?

Alternatively, set test.suite.path selectively at each invocation of testSuite (eight of them or so) and use that in the macrodef template.

  <target name="test.suite.quick" depends="test.suite.init">
    <path id="test.suite.path">

      <path refid="quick.bin.tool.path"/>
      <path refid="quick.interactive.build.path"/>
    </path>
    <property name="pcp" value="${toString:test.suite.path}"/>
    <testSuite colors="8" kinds="pos neg run jvm res scalap scalacheck specialized instrumented" pcp="${pcp}"/>
  </target>


and then in the macrodef

    <attribute name="pcp" default="${toString:partest.compilation.path}"/>
    <attribute name="kinds"/>
    <sequential>
      <echo message="@{pcp}"/>
      <property name="partest.dir" value="@{dir}" />
      <partest    srcdir="@{srcdir}"
                   kinds="@{kinds}"
                  colors="@{colors}"
              scalacOpts="@{scalacOpts}"
         compilationpath="@{pcp}"/>
    </sequential>
  </macrodef>


This means it's doing the right thing?

  [partest] baseDir:             /home/apm/clones/scala/build/quick/classes





Paul Phillips

unread,
Nov 22, 2013, 4:29:36 PM11/22/13
to scala-i...@googlegroups.com
On Fri, Nov 22, 2013 at 9:58 AM, Adriaan Moors <adr...@typesafe.com> wrote:
Note that it's serialized at https://github.com/scala/scala/blob/master/build.xml#L1881 to build/pack/partest.properties, so you may need to delete that file while changing the way it's generated.

Note also that the paths are absolute. https://issues.scala-lang.org/browse/SI-7964
 
Reply all
Reply to author
Forward
0 new messages