As a quick note today, if you’re working on a Scala project and get a compiler error message like this:
I had read that Bloop was faster than Scala compiler tools like
fsc, so I wondered if it was faster than SBT, and if so, how much faster. So I downloaded Eric Torreborre’s specs2 source code, which has 880 source code files, and compiled the entire project with both SBT and Bloop.
To test SBT’s speed, I ran all the commands from inside the SBT command prompt, which I usually do anyway to avoid the SBT/JVM startup lag time. I also ran
compile several times before recording SBT’s speed, because I thought that would be a better reflection of real-world usage and performance. I ran the tests four times, and the average time with SBT was 49 seconds, and that was very consistent, always coming in between 48 and 50 seconds.
Without any explanation, here are a couple of source code examples from my book, Learning Functional Programming in Scala. The only thing I’ll say about this code is that I created it in the process of writing that book, and the examples show how the Scala compiler translates for-expressions into map and flatMap calls behind the scenes.
I recently learned how to use the Java javapackager command to build a macOS application bundle — i.e., a regular macOS application — from a Java application. In this tutorial I’ll show how to create a Mac application bundle from a simple Java class, in this case a Java Swing class.
Answer: Use the
consoleQuick commands inside the SBT shell:
consoleto start a REPL session from inside SBT. This (a) compiles your Scala project and then (b) starts a REPL session.
consoleQuickif you don’t want to compile your project before starting a REPL session inside of SBT.
console command process looks like this:
> sbt [info] Loading project definition from /Users/al/Projects/Cats101/project [info] Set current project to Cats101 (in build file:/Users/al/Projects/Cats101/) > console [info] Starting scala interpreter... [info] Welcome to Scala 2.12.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_131). Type in expressions for evaluation. Or try :help. scala> _
If you wanted to see how to start a Scala REPL session from inside SBT, I hope this helps.
This morning I was curious about how Scala curried functions and partially-applied functions are really compiled at a bytecode level. Earlier this morning I made this post that Higher order functions are the Haskell experience — which is also implicitly about curried functions — and it got me thinking about Scala, in particular why we might use one function syntax versus another, i.e., why would I use this syntax:
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 18.2, “How to compile, run, and package a Scala project with SBT.”Back to top
You want to use SBT to compile and run a Scala project, and package the project as a JAR file.Back to top
Create a directory layout to match what SBT expects, then run
sbt compile to compile your project,
sbt run to run your project, and
sbt package to package your project as a JAR file.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is a short recipe, Recipe 14.13, “How to make your Scala shell scripts run faster by pre-compiling them.”
You love using Scala as a scripting language, but you’d like to eliminate the lag time in starting up a script.
-savecompiled argument of the Scala interpreter to save a compiled version of your script.
A basic Scala script like this:
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is a short recipe, Recipe 14.9, “How to compile your Scala code faster with the 'fsc' command-line compiler.”
You’re making changes to a project and recompiling it with
scalac, and you’d like to reduce the compile time.
fsc command instead of
scalac to compile your code: