djspiewak

Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

1. CPU-bound
2. Blocking IO
3. Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.

alexandru

import org.joda.time._
import monix.execution._
import monix.execution.Scheduler.Implicits.global
import java.util.concurrent.TimeUnit
import scala.util.control.NonFatal

def scheduleOncePerDay(time: LocalTime, now: DateTime = DateTime.now())(cb: () => Unit)
  (implicit s: Scheduler): Cancelable = {
    
  val nextTick = {

dwijnand

package p

/** Decodes strings into Ts */
trait Decoder[T] {
  def decode(s: String): Either[String, T]
}

object Decoder {
  def apply[T](f: String => Either[String, T]): Decoder[T] =
    new Decoder[T] { def decode(s: String) = f(s) }

djspiewak

Explaining Miles's Magic

Miles Sabin recently opened a pull request fixing the infamous SI-2712. First off, this is remarkable and, if merged, will make everyone's life enormously easier. This is a bug that a lot of people hit often without even realizing it, and they just assume that either they did something wrong or the compiler is broken in some weird way. It is especially common for users of scalaz or cats.

But that's not what I wanted to write about. What I want to write about is the exact semantics of Miles's fix, because it does impose some very specific assumptions about the way that type constructors work, and understanding those assumptions is the key to getting the most of it his fix.

For starters, here is the sort of thing that SI-2712 affects:

def foo[F[_], A](fa: F[A]): String = fa.toString

djspiewak

Collections Redesign Proposal

I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.

This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.

Problems

Generic Interfaces

cvogt

scala> def foo = { val x = Map[Any,Any](() -> ()).mapValues(_ => ???); () }
foo: Unit

scala> foo

scala> def foo = { val x = Map[Any,Any](() -> ()).map(_ => ???); () }
foo: Unit

scala> foo
scala.NotImplementedError: an implementation is missing

travisbrown

// Given the following ADT:

sealed trait Status
case object One extends Status
case object Two extends Status
case object Three extends Status

// They represent states. The natural progression, for this
// example, is : One -> Two -> Three

paulp

scala> case class Foo(x: Int = -12345)
defined class Foo

scala> def y = 5
y: Int

scala> val x = Foo(y)
x: Foo = Foo(5)

scala> val x = Foo{y}

djspiewak

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

milessabin

// Used in shapeless here: https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/syntax/singletons.scala#L42

scala> def narrow[T <: AnyRef](t: T): t.type = t
narrow: [T <: AnyRef](t: T)t.type

scala> val s1 = narrow("foo")  // Widened
s1: String = foo

scala> def narrow[T <: AnyRef](t: T): t.type {} = t  // Note empty refinement
narrow: [T <: AnyRef](t: T)t.type