Latest blog entries

Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides


Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace


Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

See all Inaka's blog posts >>

Some Erlang Magic for Beginners

Fernando "Brujo" Benavides wrote this on December 03, 2012 under beginners, dev, erlang, tricks .

A Typical Development Session

I'll start by showing you how a regular development session goes on my computer. Let's say I have a module like the following one:


-export([whats_in/1, say/1]).

-spec whats_in(term()) -> term().
whats_in(this_hat) ->
   case get(magic) of
      undefined -> nothing;
      Something -> Something

-spec say(term()) -> ok.
say(abracadabra) -> put(magic, 'a rabbit').

This is an otp-style project, so the module is in the src folder and there's an ebin folder with the corresponding magic.beam file. I open an Erlang console (using $ erl -pa ebin) and I try the module out:

1> magic:whats_in(this_hat).
2> magic:say(abracadabra).

Oops! That didn't return ok as expected. Let's fix that! To fix it, I leave that console open, I edit the file in my favorite editor so that it ends up like this:


-export([whats_in/1, say/1]).

-spec whats_in(term()) -> term().
whats_in(this_hat) ->
    case get(magic) of
        undefined -> nothing;
        Something -> Something

-spec say(term()) -> ok.
say(abracadabra) ->
    _ = put(magic, 'a rabbit'),

Then I go back to the console and:

3> mk().
Recompile: src/magic
4> magic:say(abracadabra).
5> magic:whats_in(this_hat).
'a rabbit'

What Just Happened?

Now you may be wandering: How did that mk(). thing recompile your code? And where did you get that shell function anyway?

The mk/0 Function

Let's start by answering the second question. I'll show you how to do it using the Erlang shell. You won't get the same results on your machine right now because you don't have any mk/0 function yet, but just walk with me and you may learn a couple of debugging tricks along the way.

To start with, we know it's a shell function because the syntax matches the syntax with, say i()., h()., etc. But I'm sure if you try to run mk(). on any Erlang console but mine it won't run. That's because unlike all those functions which are in the shell_default module, mk/0 is not. You can check that out like this:

7> shell_default:module_info(exports).

Ok, then. If it's not there, where is it? Again, we can use Erlang commands to find that out (Remember: it will only work in my computer for now but you'll be able to try it out yourself by the end of this article.) Let's start by listing all loaded modules in the system:

Modules = code:all_loaded().

We can be pretty sure mk's module is not preloaded nor it will be on the default Erlang distribution (otherwise you would already have it). Let's filter those out, then…

15> lists:filter(
>     fun ({M, Path}) when is_list(Path) ->
>             string:str(Path, code:root_dir()) == 0;
>         ({M, preloaded}) ->
>             false
>     end, Modules).

There it is!! magic is our own module, so mk/0 must be in user_default. Let's check that…

16> user_default:module_info(exports).

We've found it, that's great! It turns out that, if you have a user_default module loaded in your console, you can run any function from it straight in the shell. And if you want to know how that module got loaded even when "/Users/elbrujohalcon/Documents/" was not in the path when we started the shell, you can read Hint on that same man page. This is what my ~/.erlang file looks like:


What does mk/0 do?

The next question is how does mk/0 recompile our code. To do that, what we want is mk/0 source code. We could just open the source file for user_default.erl, but that's boring, so let's go a little bit wilder and find out mk/0 source straight from the console following the instructions from this man page

23> {ok, {user_default, [{abstract_code, {_, AC}}]}} =
>     beam_lib:chunks(code:which(user_default), [abstract_code]).
24> io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).



mk() -> up_to_date = make:all([load]).


As you can see, all mk/0 is doing is calling make:all([load]). Let's check the man page for make then. As you can see, make:all/1 will…

…[look] in the current working directory for a file named Emakefile (see below) specifying the set of modules to compile and the compile options to use. If no such file is found, the set of modules to compile defaults to all modules in the current working directory. Traversing the set of modules, it then recompiles every module for which at least one of the following conditions apply:

  • there is no object file, or
  • the source file has been modified since it was last compiled, or,
  • an include file has been modified since the source file was last compiled. […] And, since we used the load option, it will load all recompiled modules.

This is what my Emakefile looks like:

{"src/*", [warn_unused_vars, warn_export_all, […many other warning options…],
   debug_info, {outdir, "ebin"}, {i, "include"}]}.
{"src/*/*", [warn_unused_vars, warn_export_all, […many other warning options…],
   debug_info, {outdir, "ebin"}, {i, "include"}]}.
{"test/*", [warn_unused_vars, warn_export_all, […many other warning options…],
   debug_info, {outdir, "ebin"}, {i, "include"}]}.

And that's it! That's how I can do mk(). on my console and have the newest version of my modules available to use in any project with an Emakefile -- and rest assured, I put that file in every project that I work on! :)