How to compile with TypeScript and run with Node.js

As a brief note to self, you compile a TypeScript source code file with the tsc command:

tsc Foo.ts

Depending on what you’re doing, you can also run the resulting JavaScript file from the command line with this node command:

tsc Foo.ts && node Foo.js

That command can be read as, “Compile the TypeScript file and then if that compiles successfully, run the resulting JavaScript file.” Note the ts and js extensions on those files.

Fixing the Scala error: java.lang.NoSuchMethodError: scala.Product.$init$

As a note to self, when you see a Scala error message that looks like this:

java.lang.NoSuchMethodError: scala.Product.$init$(Lscala/Product;)V

it probably means that you have a mismatch in the Scala versions you’re using in your project. For instance, I just tried to use a library I compiled with Scala 2.12 with Spark, which was compiled with Scala 2.11, and I got that error message. In this case I was able to resolve the problem by recompiling my library with Scala 2.11.

Bloop’s compiler performance is ~29% faster than SBT (on at least one project)

I had read that Bloop was faster than Scala compiler tools like scalac and 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.

SBT performance

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 clean and 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.

Bloop performance

The Scala java.lang.NoSuchMethodError compiler error message alvin January 13, 2018 - 10:59am

As a quick note today, if you’re working on a Scala project and get a compiler error message like this:

Scala: Examples of for-expressions being converted to map and flatMap

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.

Example: How to use javapackager to build a MacOS application bundle

Table of Contents1 - Building a MacOS application bundle with javapackager2 - The longer story3 - The Mac/Java class4 - The three scripts5 - javapackager notes6 - A “Production” javapackager script

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.

How to start a Scala REPL session inside SBT (Simple Build Tool)

Scala FAQ: How do I start a Scala REPL session from SBT (i.e., inside the Simple Build Tool)?

Answer: Use the console or consoleQuick commands inside the SBT shell:

  • Type console to start a REPL session from inside SBT. This (a) compiles your Scala project and then (b) starts a REPL session.
  • Type consoleQuick if you don’t want to compile your project before starting a REPL session inside of SBT.

The 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...
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.

How curried functions and partially-applied functions compile in Scala

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: