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")
Related
I am trying to run scala program in cmd prompt. And I get the message.
"No, such file or class on class path exists."
Things that may be relevant:
I had several warnings from Windows about downloading and running the scala executable from the site. (I ignored them all )
I had to enter a Admin Command Line to use scala, and it did not show up in my program files after install.
The installer never actually popped up for me. So I ran the executable as administration, now
it appears in my program X86 folder. and I can enter scala mode without being in Admin mode. 4. The .scala file does compile. with scalac hello.scala
The code given to me by my instructor, in a file I named hello.scala object hello extends App{ println("Hello") }
Finally, I have looked at 2 Youtube videos and 2 Stack posts before asking this question. Thank you all for your time.
Here's a complete transcript of a successful session compiling and running on this code:
% echo 'object hello extends App{ println("Hello") }' > hello.scala
% scalac hello.scala
% scala hello
Hello
Are you doing something different? If so, what is it? Show a transcript of your entire effort, including all commands you entered and all error messages you got.
When using sbt console I find myself repeatedly entering some import statements. It would be great if there was a way to tell sbt to always run commands. Is there a way?
At the moment I have a kinda crufty solution:
( echo "import my.app._
import my.app.is.sooo.cool._" && cat ) | sbt console
Googleability words:
Initial commands, first commands, initial expressions, build file, initial statements, startup expressions, startup commands, startup statements.
You can use initialCommands:
initialCommands in console := """import my.app._
import my.app.is.sooo.cool._"""
Given that "sbt console" lets you run the scala repl, why not just create a custom .scala file (say "default.scala") where to store all the imports, and then just run :load /path/to/default.scala? This would achieve what you need in a persistent way.
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.
I am trying to launch an application using sbt's application launcher.
This application is defined as:
#!/bin/sh
java -jar /home/salil.wadnerkar/.conscript/sbt-launch.jar #"/home/salil.wadnerkar/.conscript/n8han/conscript/cs/launchconfig" "$#"
However, when I launch it, it gives me this error:
$ ~/bin/cs n8han/giter8
Error during sbt execution: Could not find configuration file 'C:/MinGW/msys/1.0/home/salil.wadnerkar/.conscript/n8han/conscript/cs/launchconfig'. Searched:
file:/C:/MinGW/msys/1.0/home/salil.wadnerkar/
file:/C:/Users/salil.wadnerkar/
file:/C:/MinGW/msys/1.0/home/salil.wadnerkar/.conscript/
However, the file is present there. So, I think it's because of some quirk in the way sbt handles mingw file path.
Does anybody know how I can get it working?
In Cygwin I used
java -jar "`cygpath -m "$HOME/.conscript/sbt-launch.jar"`" "#file:///C:/Users/cvanvranken/.conscript/n8han/conscript/cs/launchconfig" "$#"
I expect you will be able to get yours to work with something similar, perhaps this:
java -jar /home/salil.wadnerkar/.conscript/sbt-launch.jar "#file:///C:/Users/salil.wadnerkar/.conscript/n8han/conscript/cs/launchconfig" "$#"
or
java -jar /home/salil.wadnerkar/.conscript/sbt-launch.jar "#file:///C:/MinGW/msys/1.0/home/salil.wadnerkar/.conscript/n8han/conscript/cs/launchconfig" "$#"
if those fail, you still definitely need to use the file:// protocol.
Also note the three directories it is searching in the error message
file:/C:/MinGW/msys/1.0/home/salil.wadnerkar/
file:/C:/Users/salil.wadnerkar/
file:/C:/MinGW/msys/1.0/home/salil.wadnerkar/.conscript/
no matter what you put in the launchconfig parameter, if it is not recognized then those directories are searched by default. So you could have gibberish in your parameter and still see the same exact error you are getting now.
you can set the launch config path relative to the .conscript folder -
java -jar /home/salil.wadnerkar/.conscript/sbt-launch.jar #n8han/conscript/cs/launchconfig "$#"
May I ask a question about the CC compiler in Solaris environment.
I try to compile a Solaris release library with "-O" using Solaris CC compiler. I can compile the debug library previously using "-g".
However, when I change the "-g" to "-O", after some time, the compilation stop without any error. There is no output however.
I am thinking it is related to memory. So I try to compile a very simple cpp using -O flag. This time, the output is there.
May I know if any one has any idea on it? If it is a memory issue, can we use some commend or compile flag to solve it? Maybe increase the virtual memory assigned to CC?
Thanks,
You could increase virtual memory by making a swapfile:
mkswap 4096M /where/you/want/your/swapfile
swap -a /where/you/want/your/swapfile
Alternatively, you can run your truss your compilation to see exactly what's going on:
truss -f <build command>