(Note: I'm totally new to Scala and still wrapping my head around sbt tooling)
I have a small command line app using decline and I am confused about how to build it so as to execute that from console.
I referred the quick-start tutorial for decline - https://ben.kirw.in/decline/ that has below example.
import cats.implicits._
import com.monovore.decline._
object HelloWorld extends CommandApp(
name = "hello-world",
header = "Says hello!",
main = {
val userOpt =
Opts.option[String]("target", help = "Person to greet.").withDefault("world")
val quietOpt = Opts.flag("quiet", help = "Whether to be quiet.").orFalse
(userOpt, quietOpt).mapN { (user, quiet) =>
if (quiet) println("...")
else println(s"Hello $user!")
}
}
)
And it shows the resulting app can be executed from console like below.
$ hello-world --help
Usage: hello-world [--target <string>] [--quiet]
Says hello!
Options and flags:
--help
Display this help text.
--target <string>
Person to greet.
--quiet
Whether to be quiet.
$ hello-world --target friend
Hello, friend!
Could someone please guide me how to build the source code to have this executable app?
I have read through sbt tasks but could not find anything that works.
Appreciate any pointers on this.
Related
In the book, Programming in Scala 5th Edition, the author says the following for two classes:
Neither ChecksumAccumulator.scala nor Summer.scala are scripts, because they end in a definition. A script, by contrast, must end in a result expression.
The ChecksumAccumulator.scala is as follows:
import scala.collection.mutable
class CheckSumAccumulator:
private var sum = 0
def add(b: Byte): Unit = sum += b
def checksum(): Int = ~(sum & 0XFF) + 1
object CheckSumAccumulator:
private val cache = mutable.Map.empty[String, Int]
def calculate(s: String): Int =
if cache.contains(s) then
cache(s)
else
val acc = new CheckSumAccumulator
for c<-s do
acc.add((c >> 8).toByte)
acc.add(c.toByte)
val cs = acc.checksum()
cache += (s -> cs)
cs
whereas the Summer.scala is as follows:
import CheckSumAccumulator.calculate
object Summer:
def main(args: Array[String]): Unit =
for arg <- args do
println(arg + ": " + calculate(arg))
But when I run the Summer.scala file, I get a different error than what mentioned by the author:
➜ learning-scala git:(main) ./scala3-3.0.0-RC3/bin/scala Summer.scala
-- [E006] Not Found Error: /Users/avirals/dev/learning-scala/Summer.scala:1:7 --
1 |import CheckSumAccumulator.calculate
| ^^^^^^^^^^^^^^^^^^^
| Not found: CheckSumAccumulator
longer explanation available when compiling with `-explain`
1 error found
Error: Errors encountered during compilation
➜ learning-scala git:(main)
The author mentioned that the error would be around not having a result expression.
I also tried to compile CheckSumAccumulator only and then run Summer.scala as a script without compiling it:
➜ learning-scala git:(main) ./scala3-3.0.0-RC3/bin/scalac CheckSumAccumulator.scala
➜ learning-scala git:(main) ✗ ./scala3-3.0.0-RC3/bin/scala Summer.scala
<No output, given no input>
➜ learning-scala git:(main) ✗ ./scala3-3.0.0-RC3/bin/scala Summer.scala Summer of love
Summer: -121
of: -213
love: -182
It works.
Obviously, when I compile both, and then run Summer.scala, it works as expected. However, the differentiation of Summer.scala as a script vs normal file is unclear to me.
Let's start top-down...
The most regular way to compile Scala is to use a build tool like SBT/Maven/Mill/Gradle/etc. This build tool will help with a few things: downloading dependencies/libraries, downloading Scala compiler (optional), setting up CLASS_PATH and most importantly running scalac compiler and passing all flags to it. Additionally it can package compiled class files into JARs and other formats and do much more. Most relevant part is CP and compilation flags.
If you strip off the build tool you can compile your project by manually invoking scalac with all required arguments and making sure your working directory matches package structure, i.e. you are in the right directory. This can be tedious because you need to download all libraries manually and make sure they are on the class path.
So far build tool and manual compiler invocation are very similar to what you can also do in Java.
If you want to have an ah-hoc way of running some Scala code there are 2 options. scala let's you run scripts or REPL by simply compiling your uncompiled code before it executes it.
However, there are some caveats. Essentially REPL and shell scripts are the same - Scala wraps your code in some anonymous object and then runs it. This way you can write any expression without having to follow convention of using main function or App trait (which provides main). It will compile the script you are trying to run but will have no idea about imported classes. You can either compile them beforehand or make a large script that contains all code. Of course if it starts getting too large it's time to make a proper project.
So in a sense there is no such thing as script vs normal file because they both contain Scala code. The file you are running with scala is a script if it's an uncompiled code XXX.scala and "normal" compiled class XXX.class otherwise. If you ignore object wrapping I've mentioned above the rest is the same just different steps to compile and run them.
Here is the traditional 2.xxx scala runner code snippet with all possible options:
def runTarget(): Option[Throwable] = howToRun match {
case AsObject =>
ObjectRunner.runAndCatch(settings.classpathURLs, thingToRun, command.arguments)
case AsScript if isE =>
ScriptRunner(settings).runScriptText(combinedCode, thingToRun +: command.arguments)
case AsScript =>
ScriptRunner(settings).runScript(thingToRun, command.arguments)
case AsJar =>
JarRunner.runJar(settings, thingToRun, command.arguments)
case Error =>
None
case _ =>
// We start the repl when no arguments are given.
if (settings.Wconf.isDefault && settings.lint.isDefault) {
// If user is agnostic about -Wconf and -Xlint, enable -deprecation and -feature
settings.deprecation.value = true
settings.feature.value = true
}
val config = ShellConfig(settings)
new ILoop(config).run(settings)
None
}
This is what's getting invoked when you run scala.
In Dotty/Scala3 the idea is similar but split into multiple classes and classpath logic might be different: REPL, Script runner. Script runner invokes repl.
I have to go to the path of an application to deploy it, I tried using scala.sys.process and did "cd /home/path/somepath" !
It is throwing an exception, Can anyone guide me how I can go to the directory, I cannot deploy it using absolute path because of the dependency the run file has.
Thanks in advance
Although this question is a couple of years old, it's a good question.
To use scala.sys.process to execute something from a specific working directory, pass the required directory as a parameter to ProcessBuilder, as in this working example:
import scala.sys.process._
val scriptPath = "/home/path/myShellScript.sh"
val command = Seq("/bin/bash","-c",scriptPath)
val proc = Process(command,new java.io.File("."))
var output = Vector.empty[String]
val exitValue = proc ! ProcessLogger (
(out) => if( out.trim.length > 0 )
output +:= out.trim,
(err) =>
System.err.printf("e:%s\n",err) // can be quite noisy!
)
printf("exit value: %d\n",exitValue)
printf("output[%s]\n",output.mkString("\n"))
If the goal instead is to insure that the environment of the caller defaults to a specific working directory, that can be accomplished by setting the required working directory before launching the jvm.
I would like to change the following batch script to Scala (just for fun), however, the script must keep running and listen for changes to the *.mkd files. If any file is changed, then the script should re-generate the affected doc. File IO has always been my Achilles heel...
#!/bin/sh
for file in *.mkd
do
pandoc --number-sections $file -o "${file%%.*}.pdf"
done
Any ideas around a good approach to this will be appreciated.
The following code, taken from my answer on: Watch for project files also can watch a directory and execute a specific command:
#!/usr/bin/env scala
import java.nio.file._
import scala.collection.JavaConversions._
import scala.sys.process._
val file = Paths.get(args(0))
val cmd = args(1)
val watcher = FileSystems.getDefault.newWatchService
file.register(
watcher,
StandardWatchEventKinds.ENTRY_CREATE,
StandardWatchEventKinds.ENTRY_MODIFY,
StandardWatchEventKinds.ENTRY_DELETE
)
def exec = cmd run true
#scala.annotation.tailrec
def watch(proc: Process): Unit = {
val key = watcher.take
val events = key.pollEvents
val newProc =
if (!events.isEmpty) {
proc.destroy()
exec
} else proc
if (key.reset) watch(newProc)
else println("aborted")
}
watch(exec)
Usage:
watchr.scala markdownFolder/ "echo \"Something changed!\""
Extensions have to be made to the script to inject file names into the command. As of now this snippet should just be regarded as a building block for the actual answer.
Modifying the script to incorporate the *.mkd wildcards would be non-trivial as you'd have to manually search for the files and register a watch on all of them. Re-using the script above and placing all files in a directory has the added advantage of picking up new files when they are created.
As you can see it gets pretty big and messy pretty quick just relying on Scala & Java APIs, you would be better of relying on alternative libraries or just sticking to bash while using INotify.
I have the Akka microkernel below:
class ServiceKernel extends Bootable {
val system = ActorSystem("service-kernel")
def startup = {
system.actorOf(Props(new Boot(false))) ! Start
}
def shutdown = {
system.shutdown()
}
}
Because the kernel extends Bootable and not App, how would I access command line arguments used when starting the kernel? For instance if I run the kernel using start namespace.ServiceKernel -d rundevmode or similar. Thanks!
Additional Info
I thought it would be worth adding this information about the start up script in the microkernel. In /bin/start you notice the following:
#!/bin/sh
AKKA_HOME="$(cd "$(cd "$(dirname "$0")"; pwd -P)"/..; pwd)"
AKKA_CLASSPATH="$AKKA_HOME/config:$AKKA_HOME/lib/*"
JAVA_OPTS="-Xms256M -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:ParallelGCThreads=2"
java $JAVA_OPTS -cp "$AKKA_CLASSPATH" -Dakka.home="$AKKA_HOME" akka.kernel.Main "$#"
Although om-nom-nom originally suggested -D options, it looks like it's in use and the main start up parameter is being passed to the akka.kernel.Main class (which in this case would be the ServiceKernel class above).
Here is the minimal example:
object Foo extends App {
val debugModeOn = System.getProperty("debugmode") != null
val msg = if (debugModeOn) "in debug mode" else "not in debug mode"
println(msg)
}
» scala Foo -Ddebugmode
in debug mode
» scala Foo
not in debug mode
You can do extra check to overcome this issue:
» scala Foo -Ddebugmode=false
in debug mode
P.S. you might also want to use Properties helper, that contains bunch of methods like propOrNone, propOrElse, etc
It looks like in the sh script that they give you an opportunity to provide JAVA_OPTS, and if not, they give you one that they pre-define. I suppose you could just set JAVA_OPTS in a script that then calls this one, specifying a -D option for your custom args in the JAVA_OPTS. That way you can be sure your custom args get passed in via the -D system property you specify. Hackish but I think it should work. The beauty of -D is that you can supply as many as you want, so the fact that they are already using it for some of their own system properties should not matter.
I am new to Play and GWT and following the documentation given here. But I see the following errors:
bash-3.2$ play deps test-gwt
!! Error whileloading /opt/play-1.2.1/modules/gwt-1.0/commands.py: name 'play_command' is not defined
~
~ Resolving dependencies using /Users/Harit/Documents/personal/projects/test-gwt/conf/dependencies.yml,
~
~ play->gwt 1.0 (from playLocalModules)
~
~ Installing resolved dependencies,
~
~ modules/gwt-1.0 -> /opt/play-1.2.1/modules/gwt-1.0
~
~ Done!
I see that there is a corresponding bug here, and status is fix_commited, but I don't know what shall I do?
Isn't it just because play-gwt module is not compatible with play 1.2 ?
Apparently this module is quite old and not very active and command syntax has changed in version 1.1.x or something like that.
Before, you wrote commands.py like that:
...
if play_command.startswith('gwt:'):
...
and now, it is like that:
...
MODULE = "secure"
COMMANDS = ["secure:", "secure:ov", "secure:override"]
HELP = {
"secure:": "Show help for the secure module",
"secure:override": "Override the CSS, login or layout"
}
def execute(**kargs):
command = kargs.get("command")
app = kargs.get("app")
args = kargs.get("args")
env = kargs.get("env")
if command == 'secure:':
...
In my opinion, the modification is really light so you can either ask the module owner if he would accept to do it or even do it by yourself ;)
There is also a GWT2 module which seems much more active: http://www.playframework.org/modules/gwt2 (apparently no new version since last october but the github project shows very recent commits with play1.2 support)