-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:cp does not work #6502
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6502?orig=1 |
Markus Kahl (machisuji) said (edited on Sep 4, 2013 7:55:31 AM UTC): 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. So either IMain#reset must provide a way of passing new settings or ILoop should recreate the interpreter in #addClasspath. |
Markus Kahl (machisuji) said: |
Markus Kahl (machisuji) said: 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. |
@som-snytt said (edited on Sep 6, 2013 4:53:07 PM UTC): (My old fix was nontrivial, so it was on the back burner.) |
Markus Kahl (machisuji) said: |
@som-snytt said (edited on Sep 6, 2013 6:34:37 PM UTC): 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 My fix was to use a custom |
Prashant Sharma (scrapcodes) said: |
Markus Kahl (machisuji) said: It doesn't matter who will do it how as long as it gets done I suppose. |
Jeff Hammerbacher (hammer) said: |
Prashant Sharma (scrapcodes) said: https://github.com/ScrapCodes/scala/tree/si-6502-fix @som-snytt thoughts ? |
Chip Senkbeil (senkwich) said (edited on Aug 14, 2014 7:07:06 PM UTC): I did that through reflection with regard to Spark: 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? |
@paulp said: |
@som-snytt said: The fact that there's not an associated ticket means it was never a feature. |
Chip Senkbeil (senkwich) said: |
@paulp said: |
@som-snytt said: |
@gkossakowski said: However, for :cp command to work, we need less ambitious API compared to what sbt needed. If you are interested in just appending to classpath you need to deal with two concerns: what should happen when appended jar contains package that overlap with what's already on classpath?what should happen when appended jar contains a class that shadows existing class?We have to handle properly the first concern for appending to classpath to be any useful. Fortunately, it's fairly easy to specify and implement what should happen: we should merge packages. There might be some subtle issues with implicit search changing it's outcomes for certain queries due to different package contents. However, it's extremely unlikely any user would run into those problems in practice. When it comes to shadowing (or reloading) existing class, that's order of magnitude more difficult. I don't think it's realistic :cp command could support that. For that reason, we should just detect duplicated classes when entries are being appended and throw an error. If we narrow down the scope of classpath manipulation logic to what I outlined above we have a good chance to implement it as part of official compiler's API, with tests, documentation and long-term support. I don't have plans to work on this myself for now. I'm happy to help in case someone is interested in tackling this issue. |
Francois Armand (fanf) said: At least, please, please: do put a message when the user try to use cp, or display something like ":cp : no more supported because we think you don't need external dependencies, see SI-6502" in the help. That's not pro at all. |
@som-snytt said: An alternative approach is to distinguish :cp that discards the compiler from :require that does not. Then :cp, which could be renamed so it doesn't say copy, but not to :path because :pa is the prefix of :paste, would be shorthand for, in sbt, quit, edit build.sbt, reload, console. Maybe :reset could take args, :reset -cp my.jar. If you want replay as well, then :replay -cp my.jar. That solution also obviates the need to improve upon the error message proposed in the previous post. |
@paulp said: |
@gkossakowski said: |
Sonnenschein (sonnenschein) said: |
@som-snytt said: This is convenient because some settings get baked in, so :settings doesn't take. And :replay -Xlint is handy to show behavior under different settings. Also, my impression is that the world belongs to the shapeless. |
@som-snytt said: No one has asked to put a jar on the child class path (that loads REPL artifacts; currently one location), but that could be a thing. |
@heathermiller said: still to do: clean ups, doc comments, tests |
@heathermiller said: |
@retronym said: |
David Perez said: Welcome to Scala version 2.11.5 (OpenJDK 64-Bit Server VM, Java 1.7.0_65).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :require /home/d/.m2/repository/junit/junit/4.11/junit-4.11.jar
java.lang.NoClassDefFoundError: junit/framework/TestCase
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
at scala.tools.nsc.interpreter.ILoop$InfoClassLoader$1.classOf(ILoop.scala:638)
at scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$classNameOf$1(ILoop.scala:657)
at scala.tools.nsc.interpreter.ILoop$$anonfun$10.apply(ILoop.scala:659)
at scala.tools.nsc.interpreter.ILoop$$anonfun$10.apply(ILoop.scala:659)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:370)
at scala.collection.Iterator$class.exists(Iterator.scala:776)
at scala.collection.AbstractIterator.exists(Iterator.scala:1202)
at scala.tools.nsc.interpreter.ILoop.require(ILoop.scala:659)
at scala.tools.nsc.interpreter.ILoop$$anonfun$standardCommands$13.apply(ILoop.scala:221)
at scala.tools.nsc.interpreter.ILoop$$anonfun$standardCommands$13.apply(ILoop.scala:221)
at scala.tools.nsc.interpreter.LoopCommands$LineCmd.apply(LoopCommands.scala:62)
at scala.tools.nsc.interpreter.ILoop.colonCommand(ILoop.scala:712)
at scala.tools.nsc.interpreter.ILoop.command(ILoop.scala:703)
at scala.tools.nsc.interpreter.ILoop.processLine(ILoop.scala:404)
at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:430)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:918)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:904)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:904)
at scala.reflect.internal.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:97)
at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:904)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:74)
at scala.tools.nsc.MainGenericRunner.run$1(MainGenericRunner.scala:87)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:98)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
Caused by: java.lang.ClassNotFoundException: junit.framework.TestCase
at java.lang.ClassLoader.findClass(ClassLoader.java:531)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 28 more
Unrecoverable error.
Failed to initialize compiler: NoClassDefFoundError.
This is most often remedied by a full clean and recompile.
Otherwise, your classpath may continue bytecode compiled by
different and incompatible versions of scala.
java.lang.NoClassDefFoundError: junit/framework/TestCase
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
at scala.tools.nsc.interpreter.ILoop$InfoClassLoader$1.classOf(ILoop.scala:638)
at scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$classNameOf$1(ILoop.scala:657)
at scala.tools.nsc.interpreter.ILoop$$anonfun$10.apply(ILoop.scala:659)
at scala.tools.nsc.interpreter.ILoop$$anonfun$10.apply(ILoop.scala:659)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:370)
at scala.collection.Iterator$class.exists(Iterator.scala:776)
at scala.collection.AbstractIterator.exists(Iterator.scala:1202)
at scala.tools.nsc.interpreter.ILoop.require(ILoop.scala:659)
at scala.tools.nsc.interpreter.ILoop$$anonfun$standardCommands$13.apply(ILoop.scala:221)
at scala.tools.nsc.interpreter.ILoop$$anonfun$standardCommands$13.apply(ILoop.scala:221)
at scala.tools.nsc.interpreter.LoopCommands$LineCmd.apply(LoopCommands.scala:62)
at scala.tools.nsc.interpreter.ILoop.colonCommand(ILoop.scala:712)
at scala.tools.nsc.interpreter.ILoop.command(ILoop.scala:703)
at scala.tools.nsc.interpreter.ILoop.processLine(ILoop.scala:404)
at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:430)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:918)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:904)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:904)
at scala.reflect.internal.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:97)
at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:904)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:74)
at scala.tools.nsc.MainGenericRunner.run$1(MainGenericRunner.scala:87)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:98)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
Caused by: java.lang.ClassNotFoundException: junit.framework.TestCase
at java.lang.ClassLoader.findClass(ClassLoader.java:531)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 28 more Is this a bug? |
@retronym said:
|
@retronym said: /cc @heathermiller |
@retronym said (edited on Jan 16, 2015 1:44:43 AM UTC): |
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
The text was updated successfully, but these errors were encountered: