-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add console to bridge #1314
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
Add console to bridge #1314
Conversation
classpathString: String, | ||
initialCommands: String, | ||
cleanupCommands: String, | ||
loader: ClassLoader, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loader
isn't passed to the REPL, is that a TODO? If yes that should be noted in a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, it isn't necessary to pass the loader (here atm) - but if a modified loader is passed somehow, it makes sense that it be propagated to the REPL. Will add that in the morning :) thanks!
09f2195
to
b63b840
Compare
|
||
import scala.util.Try | ||
|
||
class CombinedClassLoader(loaders: List[ClassLoader]) extends ClassLoader { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this guy needs to go away - not sure how yet though. Every other solution seems to create a circular dependency on sbt 👎
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed? Does scalac do something similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They just set it as the class loader - but that doesn't work for us. So I decided that it would be a good idea to merge the ClassLoaders and look through both of them when searching for classes (which works).
But I don't like this solution - if you have a better one - I'm all ears.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why doesn't it work for us? Can't we replace parentClassLoader
in val classLoader
with the classloader given by sbt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I would advise against making a custom subclass of ClassLoader because it can very easily not do what you think it should do, and it's hard to debug, but I don't know enough about the situation here to say for sure.
28706f6
to
9e76529
Compare
9e76529
to
22b40bf
Compare
Since you still need to depend on multiple artifacts from within the dotty project, a unified project is not feasible. A plugin would work better of course.
This feels stable enough for review now - @DarkDimius |
val parent = new URLClassLoader(compilerClasspath.toArray, parentClassLoader) | ||
new AbstractFileClassLoader(virtualDirectory, parent) | ||
lazy val parent = new URLClassLoader(compilerClasspath.toArray, | ||
classOf[Interpreter].getClassLoader) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why Interpreter
instead of CompilingInterpreter
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question - I think this was originally written by @odersky
LGTM, otherwise. |
This PR does two things:
console
from within an sbt-session that is using the dotty-bridgesbt dotty-core/publishLocal
or to deploy real snapshots:sbt dotty-core/publish