I had also written a post about iWatch and phpunit to follow source directories and automatically run a [...]]]> I had written a post about how to set up reloader.erl about a year ago. Reloader.erl is an incredibly useful library included in mochiweb for automatically reloading erlang libraries if they’ve been recompiled.

I had also written a post about iWatch and phpunit to follow source directories and automatically run a unit test (or other command) when src files change. Really great for rapid development – you can code in one window and just glance over to know if things are working as expected.

Today I started using iWatch to automatically recompile my erlang files, and reloader automatically runs the tests on those files for me as well. It’s kind of awesome.

iwatch -e modify -v -c '/usr/local/bin/erlc -o ebin/ %f' src

Enjoy constant compilation and testing with the above 1 liner.

First, get the reloader. It [...]]]> I wrote this post a few months ago when I was developing a new Erlang application. I eventually ended up using the reloader I mentioned at the end, but never documented it. Now I’m about to start writing a new app, and I’m on a different machine.

First, get the reloader. It was developed as part of mochiweb but functions just fine on it’s own. Just put it somewhere accessible – I use the ebin directory in my home folder. (yes, I just copied & pasted the source) Then compile it like so:

erlc reloader.erl

Now you can load the reloader automatically on startup by adding this to your ~/.erlang config file:

code:load_abs(“/path/to/your/ebin/reloader”).
reloader:start().

Change your path to match your reloader. Do not add the .beam extension. See the code module documentation.

When you start your Eshell, you’ll automatically get the reloader running. If you didn’t do it right, you’ll get output that looks like this:

computer:~ jhaddad$ erl
Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

{“init terminating in do_boot”,{undef,[{reloader,start,[]},{init,start_it,1},{init,start_em,1}]}}

After loading a module, if you rebuild it, it’ll automatically get reloaded. If you’ve added the eunit .hrl file, it’ll also run your unit tests for you.

There’s not a lot of documentation out there on this incredibly useful library – hopefully this helps a few of you out.

Lets use the Emakefile that Erlang supports to let us recompile and reload our code on the fly.

My Erlang Makefile:

http://www.trapexit.org/Running_Erlang_Code_From_The_Command_Line

For some reason, figuring out how the gen_server behavior works in erlang was kind of a pain for me. I think it’s because I can’t just implement [...]]]> Gen_server is a great way to create simple servers without having to write a lot of code at all. Here’s a brief overview to get you started.

For some reason, figuring out how the gen_server behavior works in erlang was kind of a pain for me. I think it’s because I can’t just implement something, I need to know why it works. Well, now I know.

So, lets get started. Gen_server is built into erlang. It abstracts the message passing away. As far as I can tell, yes, you could write this functionality yourself. But why would you want to when it’s done for you?

For starters, there’s a few functions you need to implement. If you’re using Erlide, you can create a new module and choose gen_server as the behavior, and it’ll give you a skeleton. Nifty. I strongly recommend going this route, as it has a lot of helpful comments in the code.

Lets write an addition and subtraction server. It’s really not that useful, but it’s enough to get started and understand what’s happening.

Init

%% ——————————————————————–
%% Function: init/1
%% Description: Initiates the server
%% Returns: {ok, State} |
%% {ok, State, Timeout} |
%% ignore |
%% {stop, Reason}
%% ——————————————————————–
init([]) ->
{ok, 0}.

Here’s a very important thing to understand. A gen_server maintains a state. The State that’s returned above is the starting state of the server. In our case, the initial state will be zero.

handle_call
Now we want to add some functionality. Lets add addition and subtraction. We’ll need to export our new functions as well, so lets make sure we put this in with the exports:

-export([add/1, start/0, subtract/1]).

And the actual code:

add(Num) -> gen_server:call( ?MODULE, {add, Num}).
subtract(Num) -> gen_server:call( ?MODULE, {subtract, Num}).

handle_call({add, Num}, _From, State) -> {reply, State + Num, State + Num};
handle_call({subtract, Num}, _From, State) -> {reply, State – Num, State – Num};

When you call counting:add, it will in turn call the gen_server:call function, which takes a module and a parameter. It will then call “handle_call” with this paramater, the Pid it came from, and the State of the server. The parameter can be anything, so if we use a tuple, we can take advantage of erlang’s pattern matching. handle_call will return what the gen_server should do next – reply (return a result), noreply, or stop. In this case, we’re replying.

The second parameter is the reply. We’re just going to return the current count here.

We also need to return the new server state in parameter 3. I chose to put the new state in param 2 because it’s useful, but we could just as easily put anything there – an atom, a random string, whatever.

There’s a lot of options within there, so you might want to check the docs.

I STRONGLY recommend using Erlide for your development. It auto compiles and gives you an interactive shell right in the editor. It made Erlang development so much easier. It’ll also create the stubs for the other functions you’ll need (terminate, code change, handle_info, handle_cast).

FYI, If you get an error like this:

** exception exit: {noproc,{gen_server,call,[calculator,{add,1}]}}
in function gen_server:call/2

It’s because your gen_server isn’t actually running. Make sure you start it before you test with

calculator:start().

Hopefully this is enough to get you started. Read up more in the official Erlang docs for gen_server. Scroll to the bottom to find the specifications on what functions you must implement, and what they need to return.

Enjoy!

opt_disc. Directory “c:/Documents and Settings/jhaddad/workspace/Mnesia.localhost@whatever” is NOT used.

Define a record:

-record( rule, {ruleid, site, rule, original} ).

You can define a record in the shell using rd:

99> rd(rule, {ruleid, site, rule, original} ).
rule

Leex is a tokenizer. It breaks the pieces of your file or text into tokens. You can then use a [...]]]> Leex is an erlang version of Lex, a Lexical Analyzer Generator written by Robert Virding. Robert (and several others in #erlang on freenode) were incredibly helpful and considerate in helping me understand these tools.

Leex is a tokenizer. It breaks the pieces of your file or text into tokens. You can then use a tool like yecc to take these tokens and generate useful parsers.

First, you’ll need the source. Leex source is available here. Go down to the last post in the forum, download the attached file.

1. Create a directory for your erlang packages. I chose ~/erlang.
2. Drop the leex directory in your new erlang package directory.
3. Edit your ~/.erlang file (it probably doesn’t exist yet) to include this line, making sure to use the path to your erlang package directory instead of mine:
   

   code:add_pathz(“/Users/jhaddad/erlang/leex/ebin”).

You should be able to use the leex libraries now.