I am learning scala course on coursera.
The assignment can be submit like this:
$ sbt shell
> submit myemail mypassword
This works well. However, I was wondering whether I can submit in Bash directly instead of in sbt shell, I tried like this:
$ sbt submit myemail mypassword
And this
$ sbt submit "myemail mypassword"
But neither works.. Does anyone have ideas about this? Thanks!
After reading the manual, I found
$ sbt "submit myemail mypassword"
works well...
Related
I am trying to access an environment variable in my sbt build file.
As told I set the environment variable with the jvm -D Option
sbt -DaccessToken=***** compile
but scala cannot find the variable
sys.env.get("accessToken").getOrElse(throw new RuntimeException("System variable 'accessToken' with the credentials is not set."))
Why does the -D option have no effect?
If I set the variable with export in linux everything works fine.
Anything you pass as -D is not environment variable and cannot be read as sys.env.get.
You need to use Java API to read them
System.getProperty("accessToken")
Other option is to assign an environment variable before you launch your sbt. In bash, for example, it can be done like this but this, of course, depends on your environment.
accessToken=***** sbt compile
I'm moving my first steps with Scala (2.12.7) and SBT (1.2.7).
At some point, I want to get secret value from the environment:
sys.env("SECRET_TOKEN")
The problem is that, in the sbt shell, SECRET_TOKEN is not defined, therefore the application crashes.
So:
$ export SECRET_TOKEN="xxx"
$ sbt
[... sbt loads]
sbt> run
[ crashes because of the env var not found ]
It's like the sbt shell would get only a subset of the current environment.
Am I missing something?
Thanks
sbt (script + launcher) just launches a fancy java process, which should inherit the environment variables from the parent process.
Given
$ export SECRET_TOKEN="xxx"
Both build.sbt and your application during run should have access to sys.env("SECRET_TOKEN").
In the comment section, Bruno suggested SECRET_TOKEN="xxx" sbt, which apparently worked, but I don't know how that's different from export.
In any case,
object Hello extends App {
println(sys.env("SECRET_TOKEN"))
}
works for me
sbt:hello> run
[info] Running Hello
xxx
I'm using Intellij Idea community edition. When I run
new https://github.com/sbt/scala-seed.g8
or
new PlayFramework/play-scala-seed.g8
from sbt shell it gives me following error :
Error: Unknown argument 'idea-shell' g8 0.7.2 Usage: giter8 [options] <template> <template> git or file URL, or github user/repo -b, --branch <value> Resolve a template within a given branch -f, --force Force overwrite of any existing files in output directory --version Display version number
--paramname=paramval Set given parameter value and bypass interaction EXAMPLES Apply a template from github
g8 foundweekends/giter8 Apply using the git URL for the same template
g8 git://github.com/foundweekends/giter8.git Apply template from a remote branch
g8 foundweekends/giter8 -b some-branch Apply template from a local repo
g8 file://path/to/the/repo Apply given name parameter and use defaults for all others.
g8 foundweekends/giter8 --name=template-test
This happens due to how the sbt shell is implemented in the IntelliJ Scala plugin. Also the new command isn't really meant to be run from a live shell session.
Run new from the terminal instead:
sbt new https://github.com/sbt/scala-seed.g8
You should use it from the terminal like:
sbt new scala/scala-seed.g8
If you still have problems:
Maybe you have to run it from a directory that is not a SBT project (no build.sbt)
Of course you need sbt installed.
I've added a REPL (read eval print loop) to may Java project1 which is build with maven. The REPL can be started with a script. The relevant parts are
declare -r GRADLE_CLASSPATH="$(gradle :minidns-repl:printClasspath --quiet |tail -n1)"
java \
-Dscala.usejavacp=true \
-classpath "${GRADLE_CLASSPATH}" \
scala.tools.nsc.MainGenericRunner \
-i minidns-repl/scala.repl
This works so far. The only thing that is missing which would make the REPL perfect is tab completion. I know from Scala that it does support this.
How can I enable it for MainGenericRunner?
1: Feel free to test the REPL:
git clone https://github.com/rtreffer/minidns.git \
&& cd minidns \
&& ./repl`
Then perform a DNS query, e.g. c.query("wikipedia.org", TYPE.A)
Although current scala repl has autocompletion feature right now it is not working very well. (that's aside the issue mentioned by som-snytt).
If you need the working completions in repl you best bet would be Ammonite REPL which also has some more features then the standard repl.
NOTE: I haven't tested tab completions in 2.11.8, but it looks like they had been rewritten from scratch and are looking very promising.
There's a known issue with the way -i is handled, that breaks completion.
There's also a fix pending, but I don't if it will get into 2.11.8, which also has an entirely new completion feature.
If I run the below script (saved as jarAccessTest.sh, which is an executable file) in a command line, nothing happens:
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0-SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
# import sanskritnlp.transliteration._;
print "hello"
I just see no output. Nothing. Command prompt does not return either.
What is happening here? I have to type Ctrl+C to stop whatever is happening.
EDIT: Using scala 2.9 in ubuntu 14.04 : http://i.imgur.com/VMYKnUX.png
Your pre-packaged version of Scala is from a long time ago and a galaxy far, far away.
You'll do better to download the latest 2.11.6 from the website.
When the scala runner runs a script, it starts a compile server process. If that process is borked, you may have to kill it or run fsc -shutdown to ask it nicely to go away.
You can try adding the -nc option to your script to eliminate that factor, i.e., scala -nc says no compile daemon.
Finally, if you're just testing your library, it's more common to run scala -cp my.jar and experiment from the REPL. Or if you are using SBT, start the console from there.
Anonymous suggests adding: "They seriously let you type anything on here"
To which I'll append the advice from the other answer, to run fsc -verbose. And note that they threaten to stop supporting fsc because it has issues which are maddening when they occur. For that reason, I prefer scala -nc for brief testing and scalac -d script.jar script.scala where script is an App.
The problem on the original computer was never really explained, though it is pointed out that use of the '-nc' flag worked.
The original problem might with the compilation daemon's ability to open a port. From the man page for fsc:
The first time it is executed, the daemon is started automatically.
On subsequent runs, the same daemon can be reused, thus resulting in a faster compilation. The tool is especially effective when repeatedly
compiling with the same class paths, because the
compilation daemon can reuse a compiler instance.
One way to check if this is the problem is to run fsc on its own with the verbose flag. For example, make a script called hello.scala with
println("Hello")
in it, and run
fsc -verbose hello.scala
If this shows the compile server unable to connect, you've identified your problem. A first thing to try in that case would be to check that your hosts file is kosher.
(I had a similar problem, and this is what I found).
you have a few changes to do on your code, mainly on the # line which is not a comment in scala.
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0- SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
// import sanskritnlp.transliteration._;
print ("hello\n")