Background

When I started with Erlang I used a simple Makefile to call erlc and pretty much did things by hand. After a number of years in the wilderness I found out about rebar from Basho and started using that to compile my code. Everything was good, rebar knew how to compile OTP apps and pull down external dependencies. Except when I needed to generate releases. It’s not necessarily straight forward to get rebar to build you a nice release, not that it’s impossible it’s just not as simple as I’d like.

Enter Sinan, the somewhat forgotten erlang build tool.

Sinan is a build tool designed to build Erlang/OTP projects, releases and applications. It claims to be more OTP than rebar and uses the OTP metadata artefacts to build your project with little configuration needed.

Let’s see how well it delivers on the promise.

Sinan From Scratch

First you’ll need Erlang installed, which your friendly local package management tool should provide. I’m using Homebrew on OSX so I just did:

1
2
3
4
5
6
7

$ brew install erlang
...
$ erl -v
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1>

Linux should be similarly straight forward and Windows well you’re on your own.

Grab sinan from the downloads page on github, I’m using version 4.1.1. Put it somewhere on your PATH, I’ve got mine in ~/bin which is on my PATH, and chmod +x it so it’s executable.

Now for the fun bit, type sinan gen and fill in the details.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Please specify your name
your name> Tim McGilchrist
Please specify your email address
your email> timmcgil@gmail.com
Please specify the copyright holder
copyright holder ("Tim McGilchrist")>
Please specify name of your project
project name> sinan_demo
Please specify version of your project
project version> 0.0.1
Please specify the ERTS version ("5.9.1")>
Is this a single application project ("n")> y
Would you like a build config? ("y")> y
Project was created, you should be good to go!

From that Sinan has generated a project, filling in your details, with an OTP application and some build configuration. Your directories should look something similar to this.

1
2
3
4
5
6
7
8
9
10
11
12

sinan_demo
    ├── config
    │   └── sys.config
    ├── doc
    ├── ebin
    │   └── overview.edoc
    ├── include
    ├── sinan.config
    └── src
        ├── sinan_demo.app.src
        ├── sinan_demo_app.erl
        └── sinan_demo_sup.erl

It includes all the standard directories you’d expect plus a sinan.config file.

First a little diversion, we need to add a line to the sinan config file, which tells sinan to include the erlang runtime system when it generates a release. Open sinan.config and add {include_erts, true}. as the last line. It should look like this:

1
2
3
4
5
6
7
8
9
10

{project_name, sinan_demo}.
{project_vsn, "0.0.1"}.

{build_dir,  "_build"}.

{ignore_dirs, ["_", "."]}.

{ignore_apps, []}.

{include_erts, true}.

Back to making our generated code runnable.

By default the generated supervisor doesn’t point to a valid module so you’ll need to remedy that before trying to startup the application. Create a new file called sinan_demo_server.erl in src and drop the following code in.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

-module(sinan_demo_server).

-behaviour(gen_server).

%% API
-export([start_link/0, add_one/0, total/0]).

%% Callbacks
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).

-record(state, {count}).

%%%===================================================================
%%% API functions
%%%===================================================================

start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

total() ->
    gen_server:call(?MODULE, total).

add_one() ->
    gen_server:call(?MODULE, add).

%%%===================================================================
%%% Callbacks
%%%===================================================================

init([]) ->
    io:format("starting~n", []),
    {ok, #state{count = 0}, 0}.

handle_call(add, _From, State) ->
    NewCount = State#state.count + 1,
    NewState = State#state{count = NewCount},
    Reply    = {ok, NewState},
    {reply, Reply, NewState};
handle_call(total, _From, State = #state{ count = Count }) ->
    {reply, Count, State};
handle_call(Msg, _From, State) ->
    {reply, {ok, Msg}, State}.

handle_cast(_Msg, State) ->
    {noreply, State}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

It’s a pretty standard OTP gen_server application with 2 API methods. add_one/0 adds 1 to the counter and total/0 returns the value of the counter. The record definition setups up the state record for this server with just a count attribute. The 2 API functions use the gen_server:call/2 method to hit the OTP callback for handle_call/3.

Next we need to fix the supervisor so it starts the correct module. Change sinan_demo_sup.erl so it looks like the code below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

start_link() ->
    supervisor:start_link({local, ?SERVER}, ?MODULE, []).

%%%===================================================================
%%% Supervisor callbacks
%%%===================================================================

%% @private
-spec init(list()) -> {ok, {SupFlags::any(), [ChildSpec::any()]}} |
                            ignore | {error, Reason::any()}.
init([]) ->
    RestartStrategy = one_for_one,
    MaxRestarts = 1000,
    MaxSecondsBetweenRestarts = 3600,

    SupFlags = {RestartStrategy, MaxRestarts, MaxSecondsBetweenRestarts},

    Restart = permanent,
    Shutdown = 2000,
    Type = worker,

    AChild = {sinan_demo_server, {sinan_demo_server, start_link, []},
              Restart, Shutdown, Type, [sinan_demo_server]},

    {ok, {SupFlags, [AChild]}}.

The 2 changes we have make is to start_link/0 so we can call the server directly, and fix the child spec so it starts our new module.

Now we need to add the sinan_demo_server module to sinan_demo.app.src so we know about it when generating the OTP application. Just add it to the list of modules like so:

1
2
3
4
5
6
7
8
9
10
11
12

%% This is the application resource file (.app file) for the,
%% application.
{application, sinan_demo,
 [{description, "Sinan demo application."},
  {vsn, "0.0.1"},
  {modules, [sinan_demo_app,
             sinan_demo_sup,
             sinan_demo_server]},
  {registered,[sinan_demo_sup]},
  {applications, [kernel, stdlib]},
  {mod, {sinan_demo_app,[]}},
  {start_phases, []}]}.

Compile with sinan build and hopefully everything works.

From here you’ve got a few options to get your application running, but the easiest is just to use the sinan shell and start your application from there.

1
2
3
4
5
6
7
8
9
10
11
12
13

$ sinan shell
Eshell V5.9.1  (abort with ^G)
1> application:which_applications().
[{parsetools,"XLATETOOLS  CXC 138 xx","2.0.7"},
 {syntax_tools,"Syntax tools","1.6.8"},
 {compiler,"ERTS  CXC 138 10","4.8.1"},
 {getopt,"Command-line options parser for Erlang","0.4.2"},
 {erlware_commons,"Additional standard library for Erlang",
                  "0.6.1"},
 {stdlib,"ERTS  CXC 138 10","1.18.1"},
 {kernel,"ERTS  CXC 138 10","2.15.1"}]
2> application:start(sinan_demo).
ok

We’ve started a shell and checked what applications are started with application:which_applications(). Now start the demo application with:

1
2

3> application:start(sinan_demo).
ok

Now lets test that we can call the application.

1
2
3
4

4> sinan_demo_server:add_one().
{ok,{state,1}}
5> sinan_demo_server:add_one().
{ok,{state,2}}

As you can see it’s calling the server and incrementing the call count.

The next step is to create a release, which is as simple as running sinan release

Sinan has created a number of new directories under _build

1
2
3
4
5
6
7
8
9
10
11

$ tree -d _build/
    _build/
    `-- sinan_demo
        |-- bin
        |-- erts-5.9.1
        |-- lib
        |   |-- kernel-2.15.1
        |   |-- sinan_demo-0.0.1
        |   `-- stdlib-1.18.1
        `-- releases
            `-- 0.0.1

The bin directory is still there from last time but now we have an erts, lib and releases directories. erts is there because earlier we asked sinan to include an erlang runtime, so you can copy everything under _build/sinan_demo to another machine without erlang installed and run this application. The limitation being that the CPU and OS needs to match the machine you’ve built on. lib includes all the applications you asked sinan to include, they’ll match what you have in your collective .app.src files. releases contains configuration files specific to a particular release of the application.

Starting the release generated is as simple as

1
2
3
4
5
6
7
8
9
10

$ ./_build/sinan_demo/bin/sinan_demo
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

starting
Eshell V5.9.1  (abort with ^G)
1> application:which_applications().
 [{sinan_demo,"Sinan demo application.","0.0.1"},
  {stdlib,"ERTS  CXC 138 10","1.18.1"},
  {kernel,"ERTS  CXC 138 10","2.15.1"}]
2>

We’ll leave it there for now, but if you’re curious like me you’ll probably have a bunch of questions of where to take sinan next.

Next time I’m going to cover:

• Generating Version 2
• Doing an OTP upgrade to Version 2
• Downgrading to Version 1

But if you’ve got other suggestions please leave them in the comments.

I finally posting my slides for the WebMachine talk I gave at ErlSyd.

The content was fairly general WebMachine and REST stuff, going into how to setup, build and structure a WebMachine application.

I’m planning on putting together something more detailed in the future, as the current WebMachine resources are rather spartan. The plan is to do an extended series of posts or a github/ebook site ala learnyousomeerlang.

Again the slides are up on github @ github.com/tmcgilchrist/webmachine_talk/.

I recently presented a talk to RoRo Sydney, the local Ruby UG, on Riak and Ripple.

The content was more on the general side of things, with my purpose being to introduce the core Riak ideas and give some Ruby code for interacting with Riak.

The slides are up on github @ github.com/tmcgilchrist/riak_ripple_talk/.

New gist for using a rebase workflow with git.

Again probably not interesting to everyone but it gives the bare bones of what you need to do.

After reading a recent article about GNU Hurd on hacker news I’m struck by the thought that GNUs development of Hurd is a perfect example of a failed software project.

There was an initial great idea to build a microkernel based OS with all these cool features. But what crippled the project was a combination of:

• constantly switching priorities and technology. How many different kernels did they consider and start work on only to abandon work when something better/shinier came along.
• failure to focus on getting something working and out the door. Great teams ship software!
• they didn’t capture a community around developing Hurd like Linux and BSD have.
• seems like they followed the Big Design up front approach to software development whilst Linux went for the more agile iterative approach. Thus capturing all the positive feedback and momentum that comes with getting customer input and alway having a working product.

Despite all this the idea of a Hurd system is still attractive to many and personally I look upon it with some nostalgia. I was completely obsessed by operating systems and coding them around 2000.

I’d love to see a successful Hurd project running on something like L4. But would such a system gain enough interest in the current open source environment. If Hurd was available before Linux it seems like it would have taken off and they could have rode the wave of open source enthusiasm. Now it seems to me that the space is pretty full and a new os has little opportunity to gain real market share. Surely Linux and *BSDs are good enough for people interested in a Hurd system.

Anyway this is all irrelevant until they have something working that people can run, even in a limited sense. Debian has a port but it seems progress is slow.

Why people dont consider gnu projects? Poor public image, it doesn’t appear fun to work on gnu. Look at the buzz around rails for how to manage your public image. Restrictive coding standards and legal hassle.

Original link

I’ve been rather lax in my updates of late so here is a new site and a status update all rolled into 1.

So a few updates for those interested.

I attended both YOW! and Erlang Factory Lite in Brisbane late last year, and had an absolute blast. Met lots of cool people and got inspired to do more this year. The only downside is I have far too many things I want to do and only limited time.

Went to the YOW! workshop “REST in Practice: A Tutorial on Web-based Distributed Systems” by Jim Webber, and got a great new perspective about RESTful architectures along with some gentle ribbing about the deficiencies of Rails due to me being the only Ruby/Rails guy in attendance.

Shout out to OJ for organising the Erlang Factory Lite. He’s talking at Erlang Factory in San Francisco about Riak, so go along and say hi.

I’ve been wanting to update my blog for a while so I bought a domain name or two and converted the site off Wordpress. For now it’s living on github pages and is very much a work in progress. More updates and features to come.

Other than that I’ve been hard at work on a few Ruby and Erlang projects, and am excited to be attending more Sydney user groups. This month I was at RoRo and there is an Erlang group starting up next month which I’ll be at.

Just added some gist notes on my git and mercurial workflow.

Switching between the two does my head in sometimes.

Probably not that interesting for git or mercurial experts but just something to jog my memory when I have to switch. I’ve got them taped to my desk right beside my note book of Emacs keybindings.

Git & Github Gist

Mercurial Gist

Having recently caved and bought an iPad. It’s exceptionally good, much better than I expected, it’s just I need to fight to get it back off my wife and/or kids.

I’ve started changing over to using eBooks for all my new technical books, and getting rid of paper copies. I doing that I found that 2 of my favourite publishers offer eBook upgrades to paper books you’ve already bought.

O’Reilly offers this:

All you need to do is register an account with them.

Manning offers this:

And The Pragmatic Programmers offer something similar.

So out with the dead trees and in with the bits.

A few weeks ago I mentioned that I was going to start using Emacs regularly for my Ruby/Rails development.

Well it turned into a rather deep dive into Emacs customisation and the results so far are very pleasing. Something about starting from scratch is very liberating and I’ve found the customisation process very easy this time. So far I have Emacs 24 setup with ECB, Rinari, ELPA and a whole host of Ruby/Rails modes on both OS X and Ubuntu Linux.

Everything is up on github.

I’ve still got my old configuration files hanging around in personal-lisp, which I will gradually migrate over. The top of that list is getting my Erlang mode and Distel working again.

I’m trying out a little experiment for the next few week. I’ll be using Emacs as my Ruby/Rails environment today and hopefully every few days until I’m really rocking my emacs-fu. During the day I’ll note what I don’t know how to do or doesn’t work the way I’d like, and try to find a solution for that the next time I’m using Emacs.

I’ve been somewhat meh about IntelliJ/RubyMine for a bit. They’re both nice enough but it feels like I’m only using them as a fancy editor and everything else (git/rspec/cucumber/rails) gets run in a terminal. Plus a few things are really annoying me, code completion kind of sucks, memory usage of the IDE is quite high and the refactoring support is not what it should be.

I’ve started with a blank slate, forked the emacs-starter-kit and so far only customised the colour theme.

Here’s to more productive emacs sessions.