ScalaCheck 1.14.0 was just released with support for deterministic testing using seeds. Some folks have asked for examples, so I wanted to produce a Gist to help people use this feature.
These examples will assume the following imports:
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
This note outlines a principled way to meta-programming in Scala. It tries to combine the best ideas from LMS and Scala macros in a minimalistic design.
LMS: Types matter. Inputs, outputs and transformations should all be statically typed.
Macros: Quotations are ultimately more easy to deal with than implicit-based type-lifting
LMS: Some of the most interesting and powerful applications of meta-programming
val AsyncToIO: NaturalTransformation[Async, IO] { | |
def apply[A](fa: Async[A]): IO[A] = { | |
for { | |
ref <- newIORef[Either[Throwable, A]](Left(new Error("No value"))) | |
counter <- IO(new java.util.concurrent.CountDownLatch(1)) | |
_ <- fa.register(v => ref.set(v).flatMap(_ => IO(counter.countDown())) | |
_ <- IO(counter.await()) | |
v <- ref.get | |
a <- v match { | |
case Left(e) => IO.fail(e) |
The IO
scaladoc mentions that the attempt
function can be used to violate the functor laws. This seems like an odd claim, especially since one would expect such a violation would be a bug to be fixed! Specifically:
Materializes any sequenced exceptions into value space, where they may be handled. This is analogous to the
catch
clause intry
/catch
. Please note that there are some impure implications which arise from observing caught exceptions. It is possible to violate the monad laws (and indeed, the functor laws) by using this function! Uh... don't do that.
So how does this happen exactly? Conspicuously, IO
passes the functor laws (as well as all of the other laws) in its unit test suite, so either the functor laws must be under-specified, the scaladoc is wrong, or something very fishy is going on.
The answer is something of a mix of the three. Here is the law (in Haskell syntax) which is violated:
With the recent announcement of cats-effect, a relevant question from the past resurfaces: why does IO
, which is otherwise quite Task
-like, not define both
or race
? To be clear, the type signatures of these functions would be as follows:
object IO {
def both[A, B](ioa: IO[A], iob: IO[B])(implicit EC: ExecutionContext): IO[(A, B)] = ???
def race[A, B](ioa: IO[A], iob: IO[B])(implicit EC: ExecutionContext): IO[Either[A, B]] = ???
}
#!/bin/bash | |
TABLE_NAME=TableName | |
KEY=id | |
aws dynamodb scan --table-name $TABLE_NAME --attributes-to-get "$KEY" --query "Items[].id.S" --output text | tr "\t" "\n" | xargs -t -I keyvalue aws dynamodb delete-item --table-name $TABLE_NAME --key '{"id": {"S": "keyvalue"}}' |
/* | |
* Copyright 2014–2017 SlamData Inc. | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at | |
* | |
* http://www.apache.org/licenses/LICENSE-2.0 | |
* | |
* Unless required by applicable law or agreed to in writing, software |