Yup, so just run mix run image.exs
on this sucker. You'll have to open the image manually if you're on a mac, and hey, storing it in my home dir might not work either :)
defmodule MsTest do | |
use ExUnit.Case | |
doctest Ms | |
@bob %{name: "Bob", job: "developer"} | |
@alice %{name: "Alice", job: "musician"} | |
@john %{name: "John", job: "musician"} | |
@ada %{name: "Ada", job: "developer"} | |
@alan %{name: "Alan", job: "developer"} | |
@table :users |
Benchfella.start duration: 1.0#, format: :machine | |
defmodule StringDuplicateBench do | |
use Benchfella | |
@iterations [100, 1000, 10000, 100000] | |
Enum.each(@iterations, fn n -> | |
@str "1234567890" | |
@n n |
@proto_version "1.0" | |
def process_options(opts) do | |
env_args() | |
|> (&process_in(opts, &1)).() | |
|> (&process_err(opts, &1)).() | |
|> (&process_dir(opts, &1)).() | |
end | |
defp process_in(opts, args) do |
There has been some discussion on what versions of Erlang CouchDB should support, and what versions of Erlang are detrimental to use. Sadly there were some pretty substantial problems in the R15 line and even parts of R16 that are landmines for CouchDB. This post will describe the current state of things and make some potential recommendations on approach.
def open_port(executable, args) do | |
Port.open({:spawn_executable, executable}, [:stream, :binary, {:args, args}, :use_stdio, :stderr_to_stdout, :exit_status]) | |
end | |
def process_port(port) do | |
case collect_output(InternalData[port: port], []) do | |
{status, data} -> Result[status: status, output: to_string(data)] | |
end | |
end |
iex> use PipeInspect | |
nil | |
iex> "hello" |> String.reverse |> String.upcase |> String.downcase | |
"olleh" | |
"OLLEH" | |
"olleh" |
Having read a few proofs that the halting problem is undecidable, I found that they were quite inaccessible, or that they glossed over important details. To counter this, I've attempted to re-hash the proof using a familiar language, JavaScript, with numerous examples along the way.
This famous proof tells us that there is no general method to determine whether a program will finish running. To illustrate this, we can consider programs as JavaScript function calls, and ask whether it is possible to write a JavaScript function which will tell us
Problems with shell script: | |
* no builtin string processing | |
* obscure escaping rules | |
* no numbers | |
* no types | |
* insane functions | |
* bad argument parsing | |
* i18n? | |
* no config parsing | |
* no dry run of the whole script |
#include <stdlib.h> | |
#include <stdio.h> | |
#include <math.h> | |
typedef int i; //Save space by using 'i' instead of 'int' | |
typedef float f; //Save even more space by using 'f' instead of 'float' | |
//Define a vector class with constructor and operator: 'v' | |
struct v { | |
f x,y,z; // Vector has three float attributes. |