:cp does not work

[scabug]

import reports "not found: value x" for values on the additional classpath. For instance, the following no more works in 2.10.0-Mx:

scala> :cp C:\Users\u637116.ivy2\cache\junit\junit\jars\junit-4.10.jar
scala> import junit.runner.Version
:7: error: not found: value junit

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-6502?orig=1
Reporter: Sonnenschein (sonnenschein)
Affected Versions: 2.10.0-M7, 2.10.3

[scabug]

Markus Kahl (machisuji) said (edited on Sep 4, 2013 7:55:31 AM UTC):
I have checked the difference between 2.9.1 (where it works) and 2.10.+ (where it doesn't). The reason is that the compilerClasspath is not updated.

That happened in 2.9.1 because the interpreter is closed and recreated (passing the settings with the updated classpath from ILoop) during #replay() when :cp is executed.
In 2.10.+, however, in ILoop#replay() the interpreter is merely reset which means it reuses the same compilerClasspath.

So either IMain#reset must provide a way of passing new settings or ILoop should recreate the interpreter in #addClasspath.

[scabug]

Markus Kahl (machisuji) said:
I know someone else was already assigned but I still fixed it myself.
Wrote a test and all. Now I just have to see if it breaks any of the other tests which will probably take a day and a half ...

[scabug]

Markus Kahl (machisuji) said:
Here's the commit by the way: machisuji/scala@9a92b97

Unless it's been done before I will look into the contribution guidelines, check if it merges cleanly into master and create a pull request later on after/if the other tests are ok.

[scabug]

@som-snytt said (edited on Sep 6, 2013 4:53:07 PM UTC):
Please go ahead and help yourself to a bug fix. I'll help review.

(My old fix was nontrivial, so it was on the back burner.)

[scabug]

Markus Kahl (machisuji) said:
Ah alright. So how exactly does this work? I assign it to myself and then how does the review work? I created a topic on scala-internals.

[scabug]

@som-snytt said (edited on Sep 6, 2013 6:34:37 PM UTC):
I think this is the use case (shown in your version):

scala> :cp /tmp
Added '/tmp'.  Your new classpath is:
".:/tmp"
Nothing to replay.

scala> getClass.getResource("/sample/Test.class")
res0: java.net.URL = file:/tmp/sample/Test.class

scala> sample.Test main null
<console>:8: error: not found: value sample
              sample.Test main null
              ^

That is, we want to put something on the compiler's class path, not just the runtime class path of the interpreter.

The trick is to do that without blowing away the interpreter.

Replaying might be OK; sometimes I find I have res6 references that depend on how things are replayed.

My fix was to use a custom ClassPath for ReplGlobal that lets you modify it in-flight. The replay option might turn out to be more robust.

[scabug]

Prashant Sharma (scrapcodes) said:
Hey, Is this still being looked at ? Would be great if this bug can be fixed ! or at least A.P. Marki, can you point me to your solution to this problem ?

[scabug]

Markus Kahl (machisuji) said:
Hey, I didn't have a lot of time in the last two months but it's getting better and I'm still working on it.
Although I'm currently stuck with my plan for a solution. So perhaps APM's path is a better idea.
I'm still working on figuring out my problems in the meantime.

It doesn't matter who will do it how as long as it gets done I suppose.

[scabug]

Jeff Hammerbacher (hammer) said:
Any progress on this issue? Adding jars to the classpath in the REPL is particularly useful for Scala notebooks, so breaking this functionality with 2.10 is quite unfortunate.

[scabug]

Prashant Sharma (scrapcodes) said:
One not so ideal way of fixing this is in my branch.

https://github.com/ScrapCodes/scala/tree/si-6502-fix

@som-snytt thoughts ?

[scabug]

Chip Senkbeil (senkwich) said (edited on Aug 14, 2014 7:07:06 PM UTC):
Do any of you know if dynamically updating the compiler's classpath and invalidating the new entries to reload them has any unexpected consequences?

I did that through reflection with regard to Spark:
apache/spark#1929

I can't imagine it would aside from the fact that older compiled code wouldn't have the new dependencies brought in, which might cause some weirdness.

Isn't this similar to what you did with the modifiable classpath, A. P. Marki?

[scabug]

@paulp said:
Given that invalidateClassPathEntries is never called from sbt, never called within the compiler itself, and has not a single test, you should expect nothing but unexpected consequences. (Russell's paradox, scalac edition.)

[scabug]

@som-snytt said:
I commented on the spark PR, but to note here:

scala/scala#3884

The fact that there's not an associated ticket means it was never a feature.

[scabug]

Chip Senkbeil (senkwich) said:
So, is there a recommended way to append to the compiler's classpath and get the entries reloaded (in case the jar has been updated)? For commands like :cp, throwing out the interpreter and replaying commands is not an ideal solution, especially not in Spark's case.