I’m going to try to work on something small everyday during december. see the original December Adventure.
my goal: work on sbt 2.x, other open source like sbt 1.x and plugins, or some post on this site, like music or recipe.
2024-12-19
at the outer most layer, sbt runner is a shell script, and sometimes the features and bugs appear in that layer. tonight I looked into a few issues related to sbt’s working directory check, which confirms if the user wants to continue when sbt is launched a directory without build.sbt file. for most users, this feature is not enabled.
the reason why it’s not enabled by default in most cases is because sbt reads default options from sbtopts file that ships with the installer, and in the installer currently contains:
-create-sbt
there are a number of issues related to this.
-create-sbt as option name isn’t great
there’s no clear mechanism for people to opt into this feature
apparently this mechanism could get triggered for sbt --script-version
Now that sbt 2.0.0-M3 is out, I tried sbt-ci-release 1.9.0 for back publishing, but immediate ran into a bug related to version setting, so I had to fix that in sbt-ci-release 1.9.2.
Hi everyone. On behalf of the sbt project, I am happy to announce sbt 2.0.0-M3, a beta version of sbt 2.x. Please try it out, and report any issues you might come across. Note that sbt 2.x is released under Semantic Versioning, and the plugins will need to be published for the specific milestone version.
I work on sbt in my own time with collaboration with Adrien Piquerez at Scala Center and other volunteers, like Kenji Yoshida, Jerry Tan, Matthias Kurz (Play maintainer), and recently Billy at EngFlow to name a few.
In this post, I want to talk about Hedgehog for Scala, a property-based testing framework created by Charles O’Farrell around 2018, and has been maintained by Kevin Lee more recently, based on Haskell Hedgehog, which was cofounded by Jacob Stanley and Nikos Baxevanis.
Over the weekend, I created Scala 3 Manifesto 0.1.0, a small library to re-implement scala.reflect.Manifest in Scala 3.
Programming languages operate at two levels. First, the material level where bits and bytes are moved to take actions. Second, there is a higher, spiritual level that describes the material level. The first level is the runtime. The second level is the compile-time. Scala programs are written using val terms that are typed, but at the JVM bytecode, JS, or Native, the variables turn into something different, often more general. For example, a variable typed to List[Int] becomes List[AnyRef] at runtime.
sbt-assembly 2.3.0, Contraband 0.6.0, and sbt-pgp 2.3.0 are released. Those plugins are cross published to Maven Central for sbt 1.x and sbt 2.0.0-M2, which came out two days ago. Many thanks to Kenji Yoshida (@xuwei-k) for many pull requests he’s been sending.
Hi everyone. On behalf of the sbt project, I am happy to announce sbt 2.0.0-M2, a beta version of sbt 2.x. Please try it out, and report any issues you might come across. Note that sbt 2.x is released under Semantic Versioning, and the plugins will need to be published for the specific milestone version.
I work on sbt in my own time with collaboration with Adrien Piquerez at Scala Center and other volunteers, like Kenji Yoshida, Jerry Tan, Matthias Kurz (Play maintainer), and recently Billy at EngFlow to name a few.
To preventing blocking the sbt server, we should consider shipping off long-running tasks to persistent workers, similar to today’s fork or bgRun. The candidate tasks are run, test, and console, but compile could be one too.
This is a blog post on sbt 2.x development, continuing from part 3, sbt 2.x remote cache, sbt 2.x remote cache with Bazel compatibility, sudori part 4 etc. I work on sbt 2.x in my own time with collaboration with the Scala Center and other volunteers, like Billy at EngFlow. These posts are extended PR descriptions to share the features that will come to a future version of sbt.
introduction
I was on a late summer vacation in a beach town in Connecticut this week — checking out local skate spots, dipping into cool Long Island Sound, and comparing lobster rolls. In between skateboarding and beach going, I worked on remote test caching in sbt, and a few experiments related to the idea. I’d like to share some of my findings here, mostly as a development write-up.
In sudori part 4 we looked into remote caching of compile task. While caching compile is useful, most of the CI (continuous integration) systems spend their time running tests, not just compiling code. Bazel achieves orders-of-magnitude faster CI in part due the default test command being remote cached. In other words, using Bazel, if a test runs once on a CI machine, the test result will be cached until its input changes.
An advanced sbt user might note that sbt already includes the testQuick task for local incremental testing. The issue with testQuick is that its invalidation relies on timestamps, which are non-hermetic, and thus not reproducible across machines. In this post, we’ll discuss test caching for sbt 2.x that can be shared safely across the machines. The corresponding pull request is sbt/sbt#7644.
I’m a permanently beginner-level staker, who cannot ollie, but I’ve been thinking about ollie, and here’s a memo to collect various ideas.
Mark Suciu’s ollie from 2014
It would be good to have a reference ollie. Here’s Mark Suciu from ten years go:
It’s not easy to find a plain ollie in a part, but this one captures one from the side angle. The whole thing takes place in the first 3s of the clip, and the actual Ollie probably in a second.
This is a blog post on sbt 2.x development, continuing from sudori part3, sbt 2.x remote cache, and sbt 2.x remote cache with Bazel compatibility. I work on sbt 2.x in my own time with collaboration with the Scala Center. These posts are extended PR descriptions to share the features that will come to the future version of sbt, hopefully.
August 2024 status quo
Since April, 2024, we have had Bazel-compatible remote cache capability. The implementation currently supports file output as a cached side effect. In other words, even if we start from a fresh machine, if the remote cache is hydrated, we can download JAR files from the cache instead of running the compiler.
Hi everyone. On behalf of the tree-sitter-scala project, I am happy to announce tree-sitter-scala 0.22.1. The first two segments of the version number comes from the tree-sitter-cli that was used to generate the parser, and the last segment is our actual version number. tree-sitter-scala 0.22.0 uses tree-sitter 0.22.x.
About tree-sitter-scala
tree-sitter-scala is a Scala parser in C language, generated using Tree-sitter CLI, and conforming to the Tree-sitter API. Tree-sitter parsers are generally fast, incremental, and robust (ok with partial errors). We publish Rust binding to crates.io.
Here’s a memo on how to show trees using the Scala compilers. While this likely won’t be relevant for normal usage of Scala, having the direct knowledge of the tree can be useful when developing tooling or during metaprogramming.
Scala 2.13.14
Let’s use the following example:
package example
objectMainextendsApp{ println("hello")}
Here’s how you can show the AST using Scala 2.13.14:
$ sdk install scala 2.13.14
$ sdk use scala 2.13.14
$ scalac --version
Scala compiler version 2.13.14 -- Copyright 2002-2024, LAMP/EPFL and Lightbend, Inc.
$ scalac -Vprint:parser,typer -Ystop-after:typer -Yprint-trees:format Hello.scala
I am sometimes asked what I like so much about Scala 3, so here’s a list in no particular order. Note that this is based on my personal taste informed by how I use Scala 3, and how I’d like to use Scala 3 more.
I hate it when you make me laugh,
even worse when you make me cry
I hate it when you’re not around and the fact that you didn’t call
but mostly I hate the way I don’t hate you,
not even close,
not even a little bit,
not even at all
Hi everyone. On behalf of the tree-sitter-scala project, I am happy to announce tree-sitter-scala 0.22.0. The first two segments of the version number comes from the tree-sitter-cli that was used to generate the parser, and the last segment is our actual version number. tree-sitter-scala 0.22.0 uses tree-sitter 0.22.x.
About tree-sitter-scala
tree-sitter-scala is a Scala parser in C language, generated using Tree-sitter CLI, and conforming to the Tree-sitter API. Tree-sitter parsers are generally fast, incremental, and robust (ok with partial errors). We publish Rust binding to crates.io.
Hi everyone. On behalf of the sbt project, I am happy to announce sbt 1.10.0. This is the tenth feature release of sbt 1.x, a binary compatible release focusing on new features. sbt 1.x is released under Semantic Versioning, and the plugins are expected to work throughout the 1.x series. Please try it out, and report any issues you might come across.
Hi everyone. On behalf of the sbt project, I am happy to announce sbt 1.10.0-RC2. This is the tenth feature release of sbt 1.x, a binary compatible release focusing on new features. sbt 1.x is released under Semantic Versioning, and the plugins are expected to work throughout the 1.x series. Please try it out, and report any issues you might come across.
This is part 3 of the sbt 2.x remote cache series. I’ve have been developing sbt 2.x for a few years in my own free time, and lately Scala Center is joining the effort. These posts are extended PR descriptions to share the features that will come to the future version of sbt, hopefully.
About a year ago I proposed a design for automatic cached task for sbt 2.x in RFC-1: sbt cache ideas, and in the sbt 2.x remote cache post I implemented and dug into the details of caching:
Hi everyone. On behalf of the tree-sitter-scala project, I am happy to announce tree-sitter-scala 0.20.3 and 0.21.0. The first two segments of the version number comes from the tree-sitter-cli that was used to generate the parser, and the last segment is our actual version number.
tree-sitter-scala is a Scala parser in C language, generated using Tree-sitter CLI, and conforming to the Tree-sitter API. Tree-sitter parsers are generally fast, incremental, and robust (ok with partial errors). We publish Rust binding to crates.io.
@eed3si9n I think this can be reopened, given that Github finally released free Apple Silicon workers - I think it’s best to modify the Github workflow to build all binaries automatically: sbt/sbtn-dist#11
I guess somehow I missed the memo for a whole month, but I’m happy that ARM macOS runners are here! In this post, let’s dig into how we automated GraalVM native image creation using GitHub Actions. If you’re in a hurry, see the working example native.yaml.
Hi everyone. On behalf of the sbt project, I’m happy to announce sbt 1.9.9, a Scala 2.13.13 commemorative patch release. Full release note is here - https://github.com/sbt/sbt/releases/tag/v1.9.9
To fix console task on Scala 2.13.13, sbt 1.9.9 backports updates to JLine 3.24.1 and JAnsi 2.4.0 by @hvesalai in #7503 / #7502
To fix sbt 1.9.8’s UnsatisfiedLinkError with stat, sbt 1.9.9 removes native code that was used to get the millisecond-precision timestamp that was broken (JDK-8177809) on JDK 8 prior to OpenJDK 8u302 by @eed3si9n in io#367
This is a writeup on sbt’s website scala-sbt.org updates, some concrete, others more of half-baked ideas.
Background
I’ve been the primary maintainer of the site since 2014. Though I have written some of the pages, most of the content had been written by Mark and Havoc by the time I took over. You can see on 2014 archive that the site was Sphinx doc.
The first things I did in 2014 on the site was to migrate from Sphix, which used reStructuredText, to Markdown on Pamflet, a static site generator created by Nathan, and later I inherited.
My wife and I prepare osechi (お節), japanese new year food some vegan, others non-veg. Some homemade, others store-bought. This year, we tried to stick to vegan, and documented the process. This is mostly for our own reference, but we hope it might help others out there.
toshikoshi soba (年越し蕎麦)
For good luck, we eat soba noodle at midnight, crossing into new year. I have no idea what the noodle is supposed to symbolize. The goal is to finish up most of the cooking by the end of the year, so you can coast the next day.
A remote cache, or a cloud build system, can speed up builds dramatically by sharing build results (Mokhov 2018). This is a feature that I’ve been interested ever since heard about Blaze (now open sourced as Bazel). In 2020, I implemented cached compilation in sbt 1.x. reibitto has reported that “what was once 7 minutes to compile everything now takes 15 seconds.” Others have also reported 2x ~ 5x speedup. While this is promising, it’s a bit clunky and it works only for the compile task. In March 2023, I jotted down RFC-1: sbt cache ideas to outline the current issues and a solution design. Here are some of the problems:
Problem 1: sbt 1.x implements remote caching for compile, and disk caching for some other tasks, but we would like a solution that custom tasks can participate
Problem 2: sbt 1.x has separate mechanism for disk cache and remote cache, but we would like one mechanism that build user can switch between local or remote cache
Problem 3: sbt 1.x used Ivy resolver as the cache abstration, but we’d like a more open design for remote cache backend
As my december adventure 2023 project I decided to tackle the sbt 2.x remote cache feature in my free time. The proposal is on GitHub #7464. This post explores the details of the change. Note: It shouldn’t require too much of sbt internal knowledge, but the target audience is advanced since this is more of an extended PR description.
JDK 21 just came out, and given its LTS status projects are encouraged to test their code on JDK 21. A few projects are already starting to test on JDK 22-ea as well. Here’s a quick tutorial of how to test your project on GitHub Actions with JDK 21 or JDK 22-ea using actions/setup-java.
CVE-2023-46122. sbt 1.9.7 updates its IO module to 1.9.7, which fixes parent path traversal vulnerability in IO.unzip. This was discovered and reported by Kenji Yoshida (@xuwei-k), and fixed by @eed3si9n in io#360.
This is part 2 of implementing Rust’s cfg attribute in Scala. In part 1, I tried the annotation macro with a mixed result. I’ve implemented a version of @ifdef that works better.
When I first heard about this, it sounded a bit absurd since I’ve never used languages that embeds tests into the main source code. But now that I’ve been working with Rust occasionally, I like the idea of being able to write the tests in the same source, especially for kind of code that can be exercised as functions. When it gets too messy, you can always split them out in src/test/scala/ or tests/ in Rust.
