Phantom types are designed to support compile time type evidences without any overhead costs to runtime. Phantom evidences are usually in the form of implicit arguments, which once resolved, can be erased by the compiler.
Because of these properties, phantom types are completely outside of the normal
type lattice, and as such these phantom types do not inherit the semantics of
Any.
Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).
The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA
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.
| (* author: Dimitur Krustev *) | |
| (* started: 20130616 *) | |
| (* based on: http://siek.blogspot.com/2013/05/type-safety-in-three-easy-lemmas.html *) | |
| Require Import Arith List Bool. | |
| Set Implicit Arguments. | |
| Section Lang. |
| ## Get FFMpeg working on heroku by building binaries using vulcan | |
| gem install vulcan | |
| vulcan create foo | |
| git clone --depth 1 git://source.ffmpeg.org/ffmpeg | |
| cd ffmpeg |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
by Jonathan Rochkind, http://bibwild.wordpress.com
Capistrano automates pushing out a new version of your application to a deployment location.
I've been writing and deploying Rails apps for a while, but I avoided using Capistrano until recently. I've got a pretty simple one-host deployment, and even though everyone said Capistrano was great, every time I tried to get started I just got snowed under not being able to figure out exactly what I wanted to do, and figured I wasn't having that much trouble doing it "manually".
# This example does an AJAX lookup and is in CoffeeScript
$('.typeahead').typeahead(
# source can be a function
source: (typeahead, query) ->
# this function receives the typeahead object and the query string
| var mongoose = require('mongoose') | |
| , Futures = require('futures') | |
| , Schema = mongoose.Schema | |
| , db = mongoose.connect('mongodb://localhost/mongoose-db'); | |
| var UserSchema = new Schema({ | |
| "name": {type: String}, | |
| "location": { | |
| "latitude": {type: Number, required: true, min: -90, max: 90}, | |
| "longitude": {type: Number, required: true, min: -180, max: 180} |
