How do you run a Scala shellscript with Activator?
Before using Activator you would use
#!/bin/sh
exec scala "$0" "$#"
but with Activator
#!/bin/sh
exec activator "$0" "$#"
does not work. I would prefer not having both Activator and a separate Scala install to avoid duplicate repositories if possible. If it is not possible knowing that would be helpful.
http://www.scala-lang.org/documentation/getting-started.html#script_it
We don't have the scala executable rolled into the activator download yet, so to do this you have to download Scala separately (http://www.scala-lang.org/download/ pick the "scala binaries" instead of activator). We would like activator to come with a bin/ directory that has the scala executable in it, but it currently doesn't.
Related
If you follow the steps at the official Scala 3 sites, like Dotty or Scala Lang then it recommends using Coursier to install Scala 3. The problem is that neither or these explain how to run a compiled Scala 3 application after following the steps.
Scala 2:
> cs install scala
> scalac HelloScala2.scala
> scala HelloScala2
Hello, Scala 2!
Scala 3:
> cs install scala3-compiler
> scala3-compiler HelloScala3.scala
Now how do you run the compiled application with Scala 3?
Currently there does not seem to be a way to launch a runner for Scala 3 using coursier, see this issue. As a workaround, you can install the binaries from the github release page. Scroll all the way down passed the contribution list to see the .zip file and download and unpack it to some local folder. Then put the unpacked bin directory on your path. After a restart you will get the scala command (and scalac etc) in terminal.
Another workaround is using the java runner directly with a classpath from coursier by this command:
java -cp $(cs fetch -p org.scala-lang:scala3-library_3:3.0.0):. myMain
Replace myMain with the name of your #main def function. If it is in a package myPack you need to say myPack.myMain (as usual).
Finally, it seems that is possible to run scala application like scala 2 version using scala3 in Coursier:
cs install scala3
Then, you can compile it with scala3-compiler and run with scala3:
scala3-compiler Main.scala
scala3 Main.scala
This work-around seems to work for me:
cs launch scala3-repl:3+ -M dotty.tools.MainGenericRunner -- YourScala3File.scala
This way, you don't even have to compile the source code first.
In case your source depends on third-party libraries, you can specify the dependencies like this:
cs launch scala3-repl:3+ -M dotty.tools.MainGenericRunner -- -classpath \
$(cs fetch --classpath io.circe:circe-generic_3:0.14.1):. \
YourScala3File.scala
This would be an example where you use the circe library that's compiled with Scala 3. You should be able to specify multiple third-party libraries with the fetch sub-command.
I have a cd alias for project so it's possible to start sbt then cd into a sub-project and do whatever. Is it possible to complement this somehow so that if sbt is started from some foo sub-project directory then it's as if I ran cd ..; sbt "project foo" "$#"? (I could hack some shell script wrapper, but it's a project with many people so that won't help.)
If not, then is it possible to make it spit out an error when started in a sub-project instead of pretending that that's a project and messing stuff up?
I have Activator installed. Which means I have a full SBT on my system. I don't want to create a brand new activator project. All I want to do is compile a single scala file as we used to do with the scalac command. How can I do this please? Thanks.
You go into the directory containing your scala file and type "sbt compile" on the command line.
To run the program, you type "sbt run"
see also
http://www.scala-sbt.org/0.13/tutorial/Hello.html
I'm using sbt for building my Scala project and I was looking for a way to filter output of any command (like compile) by sub-string. In particular, I want to use grep in combination with sbt commands. For example > compile | grep MyFile.scala, should print only lines where MyFile.scala was mentioned.
Is there any way to do that?
$ sbt --version
sbt launcher version 0.13.5
The best way to grep the output of SBT in interactive mode (tested with sbt 0.13.11) is to use the last-grep.
This will re-print the output of the last command and it will take different grep-like arguments.
I'm not sure about doing it from within the sbt console, but how about from your shell?
$ sbt "tasks" | grep 'clean'
clean Deletes files produced by the build, such as generated sources, compiled classes, and task caches.
Or for substrings as you mention:
$ sbt "tasks" | grep 'class'
clean Deletes files produced by the build, such as generated sources, compiled classes, and task caches.
console Starts the Scala interpreter with the project classes on the classpath.
consoleProject Starts the Scala interpreter with the sbt and the build definition on the classpath and useful imports.
consoleQuick Starts the Scala interpreter with the project dependencies on the classpath.
run Runs a main class, passing along arguments provided on the command line.
runMain Runs the main class selected by the first argument, passing the remaining arguments to the main method.
A scalacheck jar was accidentally included in the standard distribution of Scala 2.9.2, in the lib directory, along with the standard scala runtime classes (e.g. scala-library.jar). This was discovered, and fixed for subsequent Scala distributions.
I'd like to run the scala 2.9.2 interpreter and use a different version of scalacheck, but I can't get it to ignore the version in lib.
I tried:
$ LOAD_SCALACHECK='import org.scalacheck.Gen; println(Gen.choose(0, 1).sample.get)'
$ scala -e "$LOAD_SCALACHECK"
$ scala -nobootcp -e "$LOAD_SCALACHECK"
$ scala -Dscala.usejavacp=false -e "$LOAD_SCALACHECK"
$ scala -Dscala.usejavacp=false -nobootcp -e "$LOAD_SCALACHECK"
All of these still used the scalacheck.jar. Is there any way, aside from deleting the jar from lib, to run the interpreter excluding a jar from lib on the classpath?
You could always just excise the interloper, at least for a non-SBT-managed Scala... If you did that in a an SBT-managed Scala I'm pretty sure SBT would just put it back.
In the SBT case, you might try revoking all permissions to read that JAR. I don't know what the classloader would do in that case, but one hopes it's robust enough to skip over it and keep looking through the class-path...