ToolBoxes and running multiple trees

[Chris Hodapp]

First, I feel like ToolBox's "runExpr" is misleadingly-named. Shouldn't it be "runTree"?

Second, I seem to be having a repeatable problem. The first tree I run works fine. The second tree I try to run will always fail with the same error (see below). All subsequent trees will fail until I run <ToolBoxInstance>.frontEnd.reset(). After that, I seem to be able to run as many trees as I want.

code:

"""

import reflect.mirror._

var i = 0

val action = reify { i += 1; println(i) }.tree

val tb1 = newToolBox()

tb1.runExpr(action) // works

tb1.runExpr(action) // error

tb1.runExpr(action) // error

tb1.frontEnd.reset()

tb1.runExpr(action) // works

tb1.runExpr(action) // works

val tb2 = new ToolBox()

tb2.runExpr(action) // works

tb2.frontEnd.reset()

tb2.runExpr(action) // error

tb2.frontEnd(action) // error

tb2.frontEnd.reset()

tb2.runExpr(action)  // works

tb2.runExpr(action) // works

"""

The error is always:

"""

scala.reflect.runtime.ToolBoxes$ToolBox$ToolBoxError: reflective compilation has failed: 

name clash between inherited members:

method ==:(x$1: AnyRef)Boolean in class Object and

method ==:(x$1: Any)Boolean in class Any

have same type after erasure: (x$1: Object)Boolean

name clash between inherited members:

method !=:(x$1: AnyRef)Boolean in class Object and

method !=:(x$1: Any)Boolean in class Any

have same type after erasure: (x$1: Object)Boolean

        at scala.reflect.runtime.ToolBoxes$ToolBox$ToolBoxGlobal.throwIfErrors(ToolBoxes.scala:252)

        at scala.reflect.runtime.ToolBoxes$ToolBox$ToolBoxGlobal.compileExpr(ToolBoxes.scala:200)

        at scala.reflect.runtime.ToolBoxes$ToolBox$ToolBoxGlobal.runExpr(ToolBoxes.scala:227)

        at scala.reflect.runtime.ToolBoxes$ToolBox.runExpr(ToolBoxes.scala:344)

        at .<init>(<console>:17)

        at .<clinit>(<console>)

        at .<init>(<console>:7)

        at .<clinit>(<console>)

        at $print(<console>)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:616)

        at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:775)

        at scala.tools.nsc.interpreter.IMain$Request$$anonfun$18.apply(IMain.scala:1037)

        at scala.tools.nsc.interpreter.Line.scala$tools$nsc$interpreter$Line$$runAndSetState(Line.scala:41)

        at scala.tools.nsc.interpreter.Line$$anonfun$2.apply$mcV$sp(Line.scala:47)

        at scala.tools.nsc.io.package$$anon$2.run(package.scala:22)

        at java.lang.Thread.run(Thread.java:679)

"""

[Eugene Burmako]

Thanks for the detailed issue description! I will look into it.

[Chris Hodapp]

Any progress, Eugene?

[Eugene Burmako]

Well... Martin and I are totally swamped with this reflection refactoring. 

Is this bug a blocker for you? If yes, I could take a look tomorrow.

On 16 May 2012 18:37, Chris Hodapp <clho...@gmail.com> wrote:

Any progress, Eugene?

[Chris Hodapp]

That is totally understandable.

I care about this because I want to reuse the ToolBox in DynamicProxy in order to improve performance (unscientifically, it makes method calls on the proxy take about half as long to resolve and execute). I can work around the issue by just catching the exception and resetting the FrontEnd. However, it really doesn't seem like ToolBoxes should have this limitation when there  is a performance cost to making a new one. You make the call. If you don't have time, I'll just catch the exception.