| object NettyFutureBridge { | |
| import scala.concurrent.{ Promise, Future } | |
| import scala.util.Try | |
| import java.util.concurrent.CancellationException | |
| import org.jboss.netty.channel.{ Channel, ChannelFuture, ChannelFutureListener } | |
| def apply(nettyFuture: ChannelFuture): Future[Channel] = { | |
| val p = Promise[Channel]() | |
| nettyFuture.addListener(new ChannelFutureListener { | |
| def operationComplete(future: ChannelFuture): Unit = p complete Try( |
| import rapture.io._ | |
| // Let's parse some JSON | |
| val src: Json = Json.parse(""" | |
| { | |
| "foo": "Hello world", | |
| "bar": { | |
| "baz": 42 | |
| } | |
| } |
These guidelines are meant to be a living document that should be changed and adapted as needed. We encourage changes that makes it easier to achieve our goals in an efficient way.
These guidelines mainly applies to Typesafe’s “mature” projects - not necessarily to projects of the type ‘collection of scripts’ etc.
This is the process for committing code into master. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc.
This gist is a collection of my rough notes from Strange Loop 2012.
De-virtualizing abstract collections would increase performance and decrease bytecode bloat for common use cases–without tying the hands of implementors. Conceptually, operations on abstract collections become syntactic sugar for inlined code templates. You opt-in to dynamic behavior by choosing subtypes that override extension methods with virtual ones. The root collections then become an encapsulation of their elements, but not an abstraction over operations on those elements; you can still perform such operations on these collections, but the compiler statically binds the implementation rather than indirecting to the run-time type's vtable-provided version. Collection sub-families–parallel, non-strict, and the like–override generic extension methods with virtual ones, and any value statically typed to such a collection works in the usual object-oriented way.
import collection.generic.CanBuildFrom
import language.imThis post aims to document a practical design implementation we came up with when designing some APIs in Scala. Of course the concept is not Scala specific and applies to other functional languages.
If you don't want to go into the full introduction, this post talks about how Applicatives are too restrictive and breaking them into two independent components can be interesting for Contravariant and Invariant Functors. Jump to implementation attached.
We are taking JSON serialization/deserialization as a motivating example.
JsValue is the name of the type that represents the JSON AST. What we need is to be able to read a JsValue and produce an A:
trait Reads[A]{
Too much for teh twitterz :)
JVM + invokedynamic is in a completely different class than CLR + DLR, for the same reasons that JVM is in a different class than CLR to begin with.
CLR can only do its optimization up-front, before executing code. This is a large part of the reason why C# is designed the way it is: methods are non-virtual by default so they can be statically inlined, types can be specified as value-based so their allocation can be elided, and so on. But even with those language features CLR simply cannot optimize code to the level of a good, warmed-up JVM.
The JVM, on the other hand, optimizes and reoptimizes code while it runs. Regardless of whether methods are virtual/interface-dispatched, whether objects are transient, whether exception-handling is used heavily...the JVM sees through the surface and optimizes code appropriate for how it actually runs. This gives it optimization opportunities that CLR will never have without adding a comparable profiling JIT.
So how does this affect dynamic
| case class ZeeingEvent( | |
| zid: String, | |
| kind: String, | |
| showId: String, | |
| show_name: Option[String], | |
| time: DateTime | |
| ) { | |
| require (kind == "StartedZeeing" || kind == "EndedZeeing") | |
| } |
| <project xmlns="http://maven.apache.org/POM/4.0.0" | |
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |
| xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 | |
| http://maven.apache.org/maven-v4_0_0.xsd"> | |
| <modelVersion>4.0.0</modelVersion> | |
| <groupId>com.gordondickens.sample</groupId> | |
| <artifactId>sample-parent</artifactId> | |
| <version>1.0.0</version> | |
| <packaging>pom</packaging> |
If your csv doesn't contain escaped newlines then it is pretty easy to do a progressive parsing without putting the whole file into memory. The iteratee library comes with a method search inside play.api.libs.iteratee.Parsing :
def search (needle: Array[Byte]): Enumeratee[Array[Byte], MatchInfo[Array[Byte]]]which will partition your stream into Matched[Array[Byte]] and Unmatched[Array[Byte]]
Then you can combine a first iteratee that takes a header and another that will fold into the umatched results. This should look like the following code:
// break at each match and concat unmatches and drop the last received element (the match)