Script to run compiler

[DarkDimius]

Added a script to run compiler.
Though it still fails to compile even a single empty class.
review @VladUreche

[xeno-by]

I really recommend having a more intelligent runner like the one I took from Paul: https://github.com/xeno-by/dotx/blob/master/scala-runner. This one can later be symlinked to scala, scalac, scaladoc, etc.

[lrytz]

MINIBOXING_PATH?

[VladUreche]

Just to summarize the discussion we just had:

• the script fails due to the Scala library being on the classpath but not bootclasspath
• it is impossible to inject bootclasspath in a jar manifest

So, the course of action should be:

• see if Scala also has this bootclasspath restriction
• if so, check with scala-internals if this is a security measure
• if not, let dotty get the scala library from the classpath

[lrytz]

I don't fully understand yet.. You are saying that scala-library.jar needs to be on the bootclasspath to execute scalac, i.e., scala.tools.nsc.Main?

What does this have to do with dotty?

Also there might be confusion about the (JVM) classpath used to run scalac, and the classpath that scalac reads dependencies from. The two are independent. Only if you use -usejavacp, the scala compiler will put everything on the JVM classpath into its own classpath.

[DarkDimius]

@lrytz yes. scalac requires either scala-library.jar on bootclasspath or flag -Dscala.usejavacp=true (later is provided by default scalac script)
-usejavacp indeed works for scalac, but doesn't for dotty. I'm currenlty trying to find why
@VladUreche i believe it was done not as a security measure but to reduce time needed to find classes commonly used by compiler.

[lrytz]

The bootclasspath was only used because startup time was faster. For scalac / dotc it should not matter whether the scala library is on the boot classpath or on the normal (JVM) classpath.

Note that the system properties describing the two are not the same: sun.boot.class.path vs java.class.path (http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html)

The -usejavacp option should probably add all jars / directories from both (JVM) classpaths to the scala/dotty classpath. This should be handled in the compiler code, it has nothing to do with the runner script and this pull request.

[DarkDimius]

@lrytz

For scalac / dotc it should not matter whether the scala library is on the boot classpath or on the normal (JVM) classpath.

I completely agree that it shouldn't, but currently for dotty it matters

java -cp "/home/dark/opt/scala-2.11.0-M7/lib/scala-library.jar" -Dscala.usejavacp=true -jar /home/dark/workspace/dotty/target/scala-2.11.0-M7/dotty_2.11.0-M7-0.1-SNAPSHOT.jar -Dscala.usejavacp=true  1.scala

will die with error

Exception in thread "main" ERROR at ?: bad symbolic reference. A signature
refers to scala$ in package <root> which is not available.
It may be completely missing from the current classpath, or the version on
the classpath might be incompatible with the version used when compiling the signature.

while

java -Xbootclasspath/a:"/home/dark/opt/scala-2.11.0-M7/lib/scala-library.jar" -Dscala.usejavacp=true -jar /home/dark/workspace/dotty/target/scala-2.11.0-M7/dotty_2.11.0-M7-0.1-SNAPSHOT.jar 1.scala

succeeds.

Interesting though that removing -Dscala.usejavacp=true from last command line also makes it fail the same way

[lrytz]

Interesting though that removing -Dscala.usejavacp=true from last command line also makes it fail the same way

This is kind of expected.

[DarkDimius]

Works on my machine at least now.
@lrytz AFAIK you are using MacBook. Can you please check if script runs on mac?

[VladUreche]

You shouldn't rely on realpath -- it's not a standard unix util (needed apt-get to install it)

[VladUreche]

LGTM modulo the realpath usage. Since realpath recursively expands links, while readlink only does it once, I'd say the script is as good as we;re going to get.

Anyone against merging?

[VladUreche]

Just for reference, the answer to the question why do we need to set the bootclasspath to run dotty in eclipse/sbt: https://github.com/lampepfl/dotty/wiki/Classpaths-when-running-dotty

[lrytz]

when adding a new page to the wiki, consider adding it to the sidebar navigation. click "edit page" on the wiki, then there's a "sidebar" section.

[VladUreche]

Thanks @lrytz, I added the link under Getting Started.

[lrytz]

Running on my macbook i get realpath: command not found

lucmac:dotty luc$ ./dottyc 
./dottyc: line 10: realpath: command not found
Usage: scalac <options> <source files>
where possible standard options include:
-Dproperty=value   Pass -Dproperty=value directly to the runtime system.
-J<flag>           Pass <flag> directly to the runtime system.
...

I'd suggest

• moving the script to some directory (there might be more in the future)
• renaming it to dotc

Otherwise it seems to work

lucmac:dotty luc$ cat test.scala 
class C {
  val x = 1
  println(x)
}

lucmac:dotty luc$ ./dottyc test.scala -verbose
./dottyc: line 10: realpath: command not found
[loaded package loader classes.jar in 285ms]
...
[loaded class file /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar(java/lang/Object.class) in 20ms]
...
[loaded class file /Users/luc/scala/dotty/target/scala-2.11.0-M7/dotty_2.11.0-M7-0.1-SNAPSHOT.jar(dotty/DottyPredef.class) in 32ms]
...
[loaded class file /Users/luc/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.11.0-M7.jar(scala/Predef.class) in 45ms]
...

[DarkDimius]

I already have some commands called dotc and dotty in PATH(I believe they come from graphviz package).
I suggest we leave it as dottyc.

[lrytz]

That's unfortunate.. Are you sure it's from graphviz? I have it installed, so I do have dot, but i don't have dotc. Also, a google search does not show any results.

[DarkDimius]

dark@roll ~/workspace/dotty $ equery b dotty
 * Searching for dotty ... 
media-gfx/graphviz-2.26.3-r4 (/usr/bin/dotty)
dark@roll ~/workspace/dotty $ equery b dotc
 * Searching for dotc ... 
dark@roll ~/workspace/dotty $

Package manager doesn't know where does dotc come from. But dotty is definitely part of graphviz

[lrytz]

OK. I'd vote for dotc, it's consistent with the package name used in the source code.

[VladUreche]

Seems dotc is also available on Ubuntu 12.04:

$ dotc
Commande 'dotc' non trouvée, vouliez-vous dire :
 La commande 'dtc' du paquet 'device-tree-compiler' (main)
 La commande 'dot' du paquet 'graphviz' (main)
 La commande 'dots' du paquet 'dots' (universe)
 La commande 'ddtc' du paquet 'ddtc' (universe)
dotc : commande introuvable

[DarkDimius]

I will work on improving the script with features from paulp script. As well as rename it to dotc.

[adriaanm]

btw, I find the status quo for usejavacp backwards -- it should be opt-out
since the compiler doesn't work without it, we shouldn't have to specify it

[DarkDimius]

It seems that making repo public broke ling between my branch and this PR.
Please continue in #26