Daniel Ciocîrlan recently published a video showcasing a dependency-injection (DI) approach developed by Martin Odersky that uses Scala's implicit resolution to wire dependencies automatically. (See also his reddit post.)
The basic pattern for defining services in Odersky's approach is as follows:
class Service(using Provider[(Dep1, Dep2, Dep3)])
| import org.apache.ivy.core.cache.ArtifactOrigin | |
| import sbt.* | |
| import sbt.Keys.* | |
| import sbt.Project.inConfig | |
| import sbt.internal.RemoteCache.* | |
| import sbt.internal.inc.{HashUtil, JarUtils} | |
| import sbt.internal.librarymanagement.IvyActions.mapArtifacts | |
| import sbt.nio.Keys.* | |
| import sbt.plugins.SemanticdbPlugin |
Scala 2.13 is getting closer and closer!
We've been polishing the improved and simplified Scala collections library that first shipped in 2.13.0-M4. We expect the API to remain stable now, though there may still be minor changes in RC1.
M5 is our feature-freeze release for 2.13. From here forward, we’ll close existing open loops but not embark on or accept new work.
The major collections changes already landed in M4. See the M4 release notes for a summary.
| #!/bin/bash | |
| set -euo pipefail | |
| function is-git-repository { | |
| [[ -d "$1/.git" ]] || (cd "$1" && git rev-parse --git-dir > /dev/null 2>&1) | |
| } | |
| function echo-is-dirty { | |
| cd "$1" | |
| if [[ ! -z $(git status -s) ]] |
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
| @ case class Cross[T](items: T*){ | |
| def flatMap[V](f: T => Cross[V]): Cross[(T, V)] = { | |
| val flattened = for{ | |
| i <- items | |
| k <- f(i).items | |
| } yield (i, k) | |
| Cross(flattened:_*) | |
| } | |
| def map[V](f: T => V): Cross[(T, V)] = { | |
| Cross(items.map(i => i -> f(i)):_*) |
| /** | |
| * An Option class, without a few Ion's | |
| * | |
| * Never allocates, uses null instead. | |
| * | |
| * No primitives allowed. | |
| * | |
| * Flatmap is allowed, but nesting is not (no flatten) | |
| */ | |
| object Opt { |
| version: '3' | |
| services: | |
| # FRONT | |
| chronograf: | |
| # Full tag list: https://hub.docker.com/r/library/chronograf/tags/ | |
| image: chronograf | |
| deploy: | |
| replicas: 1 | |
| placement: | |
| constraints: |
| // Something like this will likely allow propagation of thread-local information | |
| val originalEc: ExecutionContext = ... // the actual execution context | |
| // This will get called every time an implicit EC is necessary, effectively preparing the context | |
| implicit def wrappedEc: ExecutionContext = { | |
| val ctx = ...// capture thread local context here | |
| new ExecutionContext { | |
| override def execute(r: Runnable): Unit = originalEc.execute(new Runnable() { | |
| override def run(): Unit { | |
| val oldCtx = ... // get old context |
