andytill

erlang_spawn_1:spawn_sleep_fun_on_one_proc in 1.057355s
erlang_spawn_1:spawn_fun_on_one_proc in 0.246039s
erlang_spawn_link_1:spawn_link_sleep_fun_on_one_proc in 1.132972s
erlang_spawn_link_1:spawn_link_fun_on_one_proc in 0.421424s
erlang_split_binary_2:split_binary_small_2 in 0.004270s
erlang_split_binary_2:split_binary_large_2 in 0.004266s
erlang_split_binary_2:split_binary_very_large_2 in 0.004171s
erlang_split_binary_2:syntax_split_binary_small_2 in 0.016963s
erlang_split_binary_2:syntax_split_binary_large_2 in 0.019240s
erlang_split_binary_2:syntax_split_binary_very_large_2 in 0.018668s

andytill

xref:start(lol).
[xref:add_directory(lol, Dir) || Dir <- code:get_path()].
Exports = riak_object:module_info(exports).
Analyze_fn = fun({F,A}) -> {ok, Use} = xref:analyze(lol, {use, {riak_object, F, A}}), Use end.
[{{riak_object,F,A}, Analyze_fn(FA)} || {F,A} = FA <- Exports, F =/= module_info].

andytill

[
	{ "keys": ["ctrl+forward_slash"], "command": "toggle_comment", "args": { "block": false } },
	{ "keys": ["ctrl+alt+forward_slash"], "command": "toggle_comment", "args": { "block": true } },
	{ "keys": ["f3"], "command": "goto_definition" },
	{ "keys": ["super+alt+r"], "command": "reveal_in_side_bar" }
]

andytill

# set prefix key to Ctrl-a
unbind-key C-b
set-option -g prefix C-a

# set the window index to base 1
set -g base-index 1

setw -g pane-base-index 1

# Highlight active window

andytill

Covering more with unit tests

Unit tests are quick to run, quick to write in bulk, target a small area of code, are not prone to timing issues and other intermittent failures and have excellent reporting tools.

However, actual usage is often prevented by side effects which require resources such as processes, ports and ets tables to exist or will crash the test.

Separating code into pure and impure functions can help and is typically beneficial. It can also harm readability, and even then not enable full coverage using unit testing. For example:

receive_message(Msg) ->

andytill

Quiz

There are ten tasks in a project and they all need to be completed within their estimate for the project to be delivered on time. Each task has a 10% chance that is mis-estimated and will take longer.

What is the probability that the project will be delivered on time?

If a task has a 10% chance of being late it has a 90% (0.9) probability of success. Probability of multiple events is calculated by multiplying all the probabilties: 0.9 * 0.9 * 0.9 etc. In the contrived example where all probabilites are the same we can do a simple power of:

Eshell V5.10.2 (abort with ^G)

andytill

public class Engine
{
    final static int MAX_NUM_OF_PARTICLES = 200000;
    
    Vect3D gravity;
    double drag;
    
    int NUM_OF_PARTICLES;
    Particle particles[];

andytill

When I started erlang, I had a hard time thinking of ideas for projects to improve my skills. Now I have way too many ideas to possibly implement Myself. Since I actually want these projects to exist so I can use them (everlasting glory coming secondary to some handy tools) I have written them up here. Feel free to try them out. I'm open to questions and suggestions.

swagger for erlang

swagger is a JSON spec for REST APIs. Once you have written a spec in swagger, it can generate documentation (demo) and REST handlers.

An erlang swagger library should take swagger specs and generate cowboy_rest handlers for them.

Difficulty: low

andytill

-module(bench).
-compile(export_all).

%% Luke Gorrie's favourite profiling macro.
-define(TIME(Tag, Expr),
        (fun() ->
             %% NOTE: timer:tc/4 does an annoying 'catch' so we
             %% need to wrap the result in 'ok' to be able to
             %% detect an unhandled exception.
             {__TIME, __RESULT} =

andytill

import sublime
import sublime_plugin
import re

class IntroduceVariableCommand(sublime_plugin.TextCommand):

    var_name = "NewVar"

    def run(self, edit):