Releases: scalacenter/bloop
v1.4.0-RC1
bloop v1.4.0-RC1
1.4.0-RC1
is a temporary release to test all of the changes that have
happened since 1.3.4
and 1.3.5
. It fixes many bugs, improves overall
performance and adds support for user-facing features such as debugging and
the experimental "offloading compilation from sbt".
v1.3.4
v1.3.3
v1.3.2
bloop v1.3.2
Bloop is a build server and CLI tool for the Scala programming
language developed by the Scala
Center.
Bloop v1.3.2
is a bugfix release for v1.3.1
.
Upgrade guide 📥
These are only the upgrade steps. If you don't have bloop installed, you
must read the installation instructions instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop # Note a restart is required in case a server still runs!
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ bloop server # in a long-running terminal session
If you're on Arch Linux, upgrade to the latest version with:
$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop
Otherwise, use the generic installation method:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.3.2/install.py | python
$ bloop ng-stop
$ systemctl --user start bloop # or similar way to run server in a long-running session
Read the complete installation instructions in our Installation page.
Fixed directory resource leak
v1.3.0
had a piece of code listing directories via Files.list()
that
ended up not freeing up open file pointers. Over a long bsp session, these
open file pointers would add up and eventually lead to fatal exceptions in
systems such as macOS.
A wrong git push tag of v1.3.1
made this fix not available in master,
despite the fact that it was merged, so v1.3.2
is the release containing
the fix that closes the resources opened by Files.list()
.
Contributors 👥
According to git shortlog -sn --no-merges v1.3.1..v1.3.2
, 1 people
contributed to this v1.3.1
release: Jorge Vicente Cantero.
v1.3.1
bloop v1.3.1
Bloop is a build server and CLI tool for the Scala programming
language developed by the Scala
Center.
Bloop v1.3.1
is a bugfix release for v1.3.0
.
Upgrade guide 📥
These are only the upgrade steps. If you don't have bloop installed, you
must read the installation instructions instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop # Note a restart is required in case a server still runs!
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ bloop server # in a long-running terminal session
If you're on Arch Linux, upgrade to the latest version with:
$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop
Otherwise, use the generic installation method:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.3.1/install.py | python
$ bloop ng-stop
$ systemctl --user start bloop # or similar way to run server in a long-running session
Read the complete installation instructions in our Installation page.
Fixed Ammonite integration in CLI client
v1.3.0
added an Ammonite integration in Bloop. Every time bloop console
is run, bloop compiles the project and then creates an Ammonite REPL
session. This integration required the cooperation of the nailgun script that
ended up misfunctioning due to a git revert
error. The bug would print the Ammonite command to run but would not actually run it.
A workaround would be to run sh -c $(bloop console $PROJECT)
, however
v1.3.1
fixes the CLI client so that this workaround is no longer needed.
Contributors 👥
According to git shortlog -sn --no-merges v1.2.4..v1.2.5
, 1 people
contributed to this v1.3.1
release: Jorge Vicente Cantero.
v1.3.0
bloop v1.3.0
Bloop is a build server and CLI tool for the Scala programming language
developed by the Scala Center.
Bloop v1.3.0
is the biggest release of this project to this date.
With over 520 commits since the v1.2.5
release, ~26000 additions and ~9500
deletions, it aggregates together fundamental changes in the compilation
pipeline, novel build server features, user-facing improvements and bug fixes
together.
Upgrade guide 📥
These are only the upgrade steps. If you don't have bloop installed, you must read
the [installation instructions][] instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop # Note a restart is required in case a server still runs!
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ bloop server # in a long-running terminal session
🆕 If you're on Arch Linux, upgrade to the latest version with:
$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop
Otherwise, use the generic installation method:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.3.0/install.py | python
$ bloop ng-stop
$ systemctl --user start bloop # or similar way to run server in a long-running session
Read the complete installation instructions in our [Installation page][installation instructions].
New compilation engine with client guarantees 💪 👪
v1.3.0
features a redesigned compilation engine built to solve tooling
challenges already present in our current developer workflow but brought to
the foreground by the formalized use of a client-server architecture. This
compilation engine sports a more efficient way of doing IO work (with no
compromises in correctness) and provides a new contract to build clients.
Bloop v1.3.0
and onwards guarantees clients that their actions will have
the smallest usage footprint possible and will not conflict with those of
other concurrent clients being served by the same server in the same build.
For example, if [Metals] is compiling your project via Bloop and you spawn a
bloop CLI command such as bloop test foo --watch
at the same time, Bloop
guarantees that:
- The server heavily caches compilations for the same inputs (aka compile deduplication)
If inputs haven't changed between the requests, only the first client
request will trigger a compilation. The compilation of the second client
will be deduplicated based on the compilation side effects recorded by the
build server, so only one compilation will happen. - Different compilation requests in the same build can run concurrently (aka
compile isolation)If inputs have changed between requests, Bloop will compile the changed
projects concurrently, avoiding shared state and conflicts with ongoing
compilations. - The outputs produced by both requests are independent in the file system.
The compilation products will be stored in independent target
directories only owned by the client. This independence is essential to
allow clients to independently run any build action without altering task
executions. Think avoiding crashing JVMs because other processes are
writing contents to open class file pointers!
This is the first step towards modelling these build actions as pure
functions despite their pervasive side effects. Bloop manages any internal
state as best as possible to provide the best developer experience to end
users. There will be more work in this area in the future!
Related pull requests
- Isolate and deduplicate compilation and Zipkin tracing support by [jvican]
- Pre-populate client classes dir if empty by [jvican]
- Deduplicate compilation if project inputs change by [jvican]
- Invalidate symbols with forked and local javac by [jvican]
- Don't create and delete empty classes dirs by [jvican]
- Cancel deduplication if ongoing compilation looks dead by [jvican]
- Use generic classes dir for the pipelined traversal by [jvican]
- Log to the user a deduplication is happening by [jvican]
- Revalidate class files compiled by dependent projects by [jvican]
- Fix not found type errors during incremental compilation by [jvican]
- Add CLI lock timeout and be more flexible when locking CLI clients
- Fix remaining issues around handling of compile products by [jvican]
- Catch exceptions when computing the bundle by [jvican]
New Zipkin tracing support 📡
Bloop v1.3.0
traces any compilation request to Zipkin if a Zipkin server is
running in the background. Here's a screenshots showing collected compilation
traces for the akka/akka
project.
And another screenshot showing the top part of a detailed compilation trace.
The zipkin integration is explained in the performance guide below.
In-depth compiler performance guide 🚀
The compiler performance
guide is a new
addition to our documentation that explains users how to:
- Get familiar with the performance characteristics of project builds
- Compare the performance of Bloop with that of other tools compiling Scala code
- Modify a complicated build to optimize build times
The guide is rich in details and written to provide pointers to those users
wanting to speed up their workflow with Bloop and optimize their current
build times further.
It is open for any community addition, so if you'd like to add something,
help us improve it!
Faster build pipelining 🏇
Build pipelining is a compilation performance technique to start the
compilation of modules in a build before their dependencies have finished
compilation.
Build pipelining was merged back in December, 2018 and made available in
bloop v1.2.1
, making bloop the first Scala developer tool to implement this
technique and support it under an experimental flag.
Bloop v1.3.0
changes its internal implementation to make it faster. We're
very excited about what this entails for any Scala build in the wild. The
bloop project will publish benchmarks and a concise guide in a follow-up
post, keep tuned! 😄
Use Ammonite by default in bloop console
🎮
Contributed by @[torkelrogstad].
Ammonite is a modernized Scala REPL with syntax highlighting, multi-line
editing, the ability to load maven artifacts directly in the REPL, and many
other quality-of-life improvements missing in the default Scala REPL.
Bloop v1.3.0
defaults on Ammonite every time you run bloop console
on a
project. Unlike running amm
in your terminal, the Ammonite integration will
automatically start an Ammonite REPL using the classpath of a project in your
build. That allows you to use all the code defined in that classpath and
experiment with its behavior.
Interested in the implementation details? Have a look at
Add support for Ammonite REPL by default.
Better Metals and BSP integration 🤘 💯
BSP support in bloop v1.3.0
is vastly superior to that in v1.2.5
. The new
release implements a few non-implemented endpoints, fixes several
non-reported issues in diagnostics and improves connection support and
cancellation capabilities.
The Metals integration is superior to that in v1.2.5
thanks to this
non-exhaustive list of PRs:
- Guarantee cancellation upon sudden BSP client dropouts by [jvican]
- Upgrade to BSP 2.0.0-M4 by [tgodzik]
- Implement BSP
buildTarget/scalaMainClasses
by [marek1840] - Implement BSP
buildTarget/scalaTestClasses
by [marek1840] - Send out server BSP responses/notifications in order by [jvican]
- A few unlisted PRs that casually fix issues in BSP semantics
Add support for Scala 2.13 ▶️
Bloop v1.3.0
finally adds support for Scala
2.13.x.
Add support for JDK 9 and 11 ⏩
Contributed by @[er1c], bloop v1.3.0
supports JDK 9 and JDK 11. If you run
bloop with these Java runtimes, it is recommended to enable the full parallel
GC with -XX:+UseParallelGC
as compilation is faster.
For this reason, Java 8 still remains the recommended runtime for the time
being and our installers might install it by default. In the future, we might
consider upgrading to a newer Java runtime.
- Compile on Java9+ by [er1c]
- Add Java9+ reverse-compatible changes by [er1c]
New Arch ...
v1.3.0-RC1
bloop v1.3.0
Bloop is a build server and CLI tool for the Scala programming language developed by the Scala Center.
Bloop v1.3.0
is the biggest release of this project to this date.
With over 520 commits since the v1.2.5
release, ~26000 additions and ~9500
deletions, it aggregates together fundamental changes in the compilation
pipeline, novel build server features, user-facing improvements and bug fixes
together.
Upgrade guide 📥
These are only the upgrade steps. If you don't have bloop installed, you must read
the [installation instructions][] instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
🆕 If you're on Arch Linux, upgrade to the latest version with:
$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop
Otherwise, use the generic installation method:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.5/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Read the complete installation instructions in our [Installation page][installation instructions].
New compilation engine with client guarantees 💪 👪
v1.3.0
features a redesigned compilation engine built to solve tooling
challenges already present in our current developer workflow but brought to
the foreground by the formalized use of a client-server architecture. This
compilation engine sports a more efficient way of doing IO work (with no
compromises in correctness) and provides a new contract to build clients.
Bloop v1.3.0
and onwards guarantees clients that their actions will have
the smallest usage footprint possible and will not conflict with those of
other concurrent clients being served by the same server in the same build.
For example, if Metals is compiling
your project via Bloop and you spawn a bloop CLI command such as bloop test foo --watch
at the same time, Bloop guarantees that:
- The server heavily caches compilations for the same inputs (aka compile deduplication)
If inputs haven't changed between the requests, only the first client
request will trigger a compilation. The compilation of the second client
will be deduplicated based on the compilation side effects recorded by the
build server, so only one compilation will happen. - Different compilation requests in the same build can run concurrently (aka
compile isolation)If inputs have changed between requests, Bloop will compile the changed
projects concurrently, avoiding shared state and conflicts with ongoing
compilations. - The outputs produced by both requests are independent in the file system.
The compilation products will be stored in independent target
directories only owned by the client. This independence is essential to
allow clients to independently run any build action without altering task
executions. Think avoiding crashing JVMs because other processes are
writing contents to open class file pointers!
This is the first step towards modelling these build actions as pure
functions despite their pervasive side effects. Bloop manages any internal
state as best as possible to provide the best developer experience to end
users. There will be more work in this area in the future!
Related pull requests
- Isolate and deduplicate compilation and Zipkin tracing support by [jvican]
- Pre-populate client classes dir if empty by [jvican]
- Deduplicate compilation if project inputs change by [jvican]
- Invalidate symbols with forked and local javac by [jvican]
- Don't create and delete empty classes dirs by [jvican]
- Cancel deduplication if ongoing compilation looks dead by [jvican]
- Use generic classes dir for the pipelined traversal by [jvican]
- Log to the user a deduplication is happening by [jvican]
- Revalidate class files compiled by dependent projects by [jvican]
- Fix not found type errors during incremental compilation by [jvican]
- Add CLI lock timeout and be more flexible when locking CLI clients
- Fix remaining issues around handling of compile products by [jvican]
- Catch exceptions when computing the bundle by [jvican]
New Zipkin tracing support 📡
Bloop v1.3.0
traces any compilation request to Zipkin if a Zipkin server is
running in the background. Here's a screenshots showing collected compilation
traces for the akka/akka
project.
And another screenshot showing the top part of a detailed compilation trace.
The zipkin integration is explained in the performance guide below.
In-depth compiler performance guide 🚀
The compiler performance
guide is a new
addition to our documentation that explains users how to:
- Get familiar with the performance characteristics of project builds
- Compare the performance of Bloop with that of other tools compiling Scala code
- Modify a complicated build to optimize build times
The guide is rich in details and written to provide pointers to those users
wanting to speed up their workflow with Bloop and optimize their current
build times further.
It is open for any community addition, so if you'd like to add something,
help us improve it!
Faster build pipelining 🏇
Build pipelining is a compilation performance technique to start the
compilation of modules in a build before their dependencies have finished
compilation.
Build pipelining was merged back in December, 2018 and made available in
bloop v1.2.1
, making bloop the first Scala developer tool to implement this
technique and support it under an experimental flag.
Bloop v1.3.0
changes its internal implementation to make it faster. We're
very excited about what this entails for any Scala build in the wild. The
bloop project will publish benchmarks and a concise guide in a follow-up
post, keep tuned! 😄
Use Ammonite by default in bloop console
🎮
Contributed by @[torkelrogstad].
Ammonite is a modernized Scala REPL with syntax highlighting, multi-line
editing, the ability to load maven artifacts directly in the REPL, and many
other quality-of-life improvements missing in the default Scala REPL.
Bloop v1.3.0
defaults on Ammonite every time you run bloop console
on a
project. Unlike running amm
in your terminal, the Ammonite integration will
automatically start an Ammonite REPL using the classpath of a project in your
build. That allows you to use all the code defined in that classpath and
experiment with its behavior.
Interested in the implementation details? Have a look at Add support for Ammonite REPL by default.
Better Metals and BSP integration 🤘 💯
BSP support in bloop v1.3.0
is vastly superior to that in v1.2.5
. The new release implements a few non-implemented endpoints, fixes several non-reported issues in diagnostics and improves connection support and cancellation capabilities.
The Metals integration is superior to that in v1.2.5
thanks to this
non-exhaustive list of PRs:
- Guarantee cancellation upon sudden BSP client dropouts by [jvican]
- Upgrade to BSP 2.0.0-M4 by [tgodzik]
- Implement BSP
buildTarget/scalaMainClasses
by [marek1840] - Implement BSP
buildTarget/scalaTestClasses
by [marek1840] - Send out server BSP responses/notifications in order by [jvican]
- A few unlisted PRs that casually fix issues in BSP semantics
Add support for Scala 2.13 ▶️
Bloop v1.3.0
finally adds support for Scala
2.13.x.
Add support for JDK 9 and 11 ⏩
Contributed by @[er1c], bloop v1.3.0
supports JDK 9 and JDK 11. If you run
bloop with these Java runtimes, it is recommended to enable the full parallel
GC with -XX:+UseParallelGC
as compilation is faster.
For this reason, Java 8 still remains the recommended runtime for the time
being and our installers might install it by default. In the future, we might
consider upgrading to a newer Java runtime.
- Compile on Java9+ by [er1c]
- Add Java9+ reverse-compatible changes by [er1c]
New Arch Linux installer 🏄
Co...
v1.2.5
bloop v1.2.5
🏄
Upgrade guide 🔌
This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.5/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Read the complete installation instructions in our Installation page.
Highlights 📚
v1.2.5
is only a bugfix release.
Report diagnostics better via BSP
Fix clearing of missing diagnostics when previous incremental compiler cycles
have failed, see #804 for more
information.
Contributors 👥
According to git shortlog -sn --no-merges v1.2.4..v1.2.5
, 1 people contributed to this v1.2.5
release: Jorge Vicente Cantero.
v1.2.4
bloop v1.2.4
🏄
Upgrade guide 🔌
This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.4/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Read the complete installation instructions in our Installation page.
Highlights 📚
v1.2.4
is only a bugfix release.
Don't deduplicate diagnostics too aggressively
Fix an error where the deduplication logic of diagnostics to avoid duplicated scalac errors
relied on pointer
instead of offset
.
Contributors 👥
According to git shortlog -sn --no-merges v1.2.3..v1.2.4
, 1 people contributed to this v1.2.4
release: Jorge Vicente Cantero.
v1.2.3
bloop v1.2.3
🏄
Upgrade guide 🔌
This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.
If you're on macOS, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop
If you're on Windows using scoop
, upgrade to the latest version with:
$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.3/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)
Read the complete installation instructions in our Installation page.
Highlights 📚
v1.2.3
is only a bugfix release.
Don't fail installation when Python 3 is used and http_proxy is defined
See scalacenter/homebrew-bloop#4 for more details.
Disable failed process logs in launcher (#798)
This change clears up the logs of the launcher when processes are run and
they fail. See the linked pull request for more details.
Contributors 👥
According to git shortlog -sn --no-merges v1.2.2..v1.2.2
, 2 people contributed to this v1.2.2
release: Jorge Vicente Cantero, marek1840.