Building Erlang OTP R14B on OpenBSD 4.7

Summary: OpenBSD is not GNU/Linux!

I just spent the last 20 minutes baffled by some weird errors as I was building Erlang on an OpenBSD box I am setting up.

$ make
make: "/home/acces/otp_src_R13B04/Makefile" line 88: Missing dependency operator
make: "/home/acces/otp_src_R13B04/Makefile" line 89: Missing dependency operator
...
100 similar lines follow
...

The problem is… that when you type make, OpenBSD — and probably NetBSD and FreeBSD — all use BSD make by default, NOT GNU make! Silly me. I even had just installed GNU make a couple hours earlier!

So anyway:

$ pkg_add -i -v gmake
...
[download, unzip, configure Erlang OTP]
...
$ make # WILL FAIL!
$ gmake
Advertisements

Bitstrings and Binaries (Erlang bit syntax minihowto part 2)

What’s the difference between the Binary and Bitstring types in Erlang? Well, a bitstring is a sequence of bits of any length; a binary is a sequence of bits where the number of bits is evenly divisible by 8. (So any binary is also a bitstring.)

Some examples:

1> <<2#11110000:5>>.
>
2> <<2#11110000:6>>.
>
3> erlang:is_bitstring(<<2#11110000:6>>).
true
4> erlang:is_binary(<<2#11110000:6>>).
false
5> erlang:is_bitstring(<<2#11110000:8>>).
true
6> erlang:is_binary(<<2#11110000:8>>).
true

In the Erlang bit syntax there are 2 clarifying (?) type synonyms:

bytes == binary
bits  == bitstring

which are basically telling you to think of binaries as sequence of bytes, and bitstrings as sequence of bits. Quite obvious right? Well, it wasn’t for me at first.

It’s also worth noting how binaries and bitstrings are converted into text strings. Given the binary <<16#50>> storing the letter ‘P’,

7> <<16#50>>
<<"P">>
8>erlang:bitstring_to_list(<<16#50>>). #I could've used binary_to_list()
"P"          %great!
9>erlang:bitstring_to_list(<<16#50:5>>).
[<<16:5>>]  %mmh...

The result of command #9 is not exactly what I had imagined. Yes, it’s a list, but it’s certainly not a text string, and I was expecting a text string. Why was I expecting a text string if the API is named bitstring_to_list() ? Because if I was in the middle of coding a text manipulation algorithm and called bitstring_to_list(), I would probably (wrongly) assume that it would do some magic and transform any bitstring in a usable text string. Why? Because we are used to treat text strings as lists. Why? Because we don’t have APIs that mention “strings”: all the builtin APIs only mention lists. That’s the problem. We are using a list API as if it was a string API, when a generic list is not necessarily a string.

Erlang bit syntax mini How-To

I don’t know why but Erlang bit syntax always confused me. I always skipped it while reading the docs, until, well, now that I need it. I should say this is not meant to be an exhaustive how-to by any means. It’s just a collection of notes, but howto sounded better. ūüôā There are better guides out there. [Reference docs too.]

Anyway. Here’s some binary data in Erlang:

<<16#1192c05a:32>>

What does all this mean? Let’s analyze it, left to right.

  1. 16# This specifies we want to express the number in base 16.
  2. We have an eight digits hex number.
  3. No type specification is provided: default is unsigned integer.
  4. No unit specification is provided: default for integer is 1, which means ‘bits’.
  5. :32 Size specification: this tells erlang to consider 32 units, which in our case means 32 bits, since we are dealing with bits.

Let’s evaluate it:

86> <<16#2092105a:32>>.
<<32,146,16,90>>

What if we forget to specify the size spec? In that case the default will apply and since we’re dealing with an integer type, the default is 8 (bits). For Erlang this means we are going to return the least significant byte:

87> <<16#2092105a>>.
<<90>>

Now that we know that, we can get a subset of bits by setting the size accordingly:

88> <<16#2092105a:16>>.
<<16,90>>     %two least significant bytes

We don’t need to specify a size multiple of 8:

89> <<16#1192FFFF:15>>.
<<255,127:7>>

It’s pretty cool how easy it is to slice bytes apart at the bit level. I was sort of surprised that if we slice some internal bits it looks like the bits at the right are moved to the left. E.g. here we take the 4 least significant bits of the first 0xFF:

90> <<16#FF:4,0,16#FF,0>>.

but instead of obtaining:

<<16:4,0,255,0>>
F 00 FF 00

we get:

<<240,15,240,0:4>>
F0 0F F0 0          [240 == F0]

Also, the value doesn’t need to be a literal, it can be an expression:

91> N = 16#FF00FF01.
4278255361
92> <<N:32>>.
<<255,0,255,1>>

And therefore, given some binary data, we can also pattern-match it super easily:

<SourcePort:16, DestinationPort:16, CheckSum:16, Payload/binary>> = SomeBinary.

There’s more to Erlang bit syntax than this, but I’ll stop here for now.

Purely functional game programming with State Machines

I read with great interest the articles by James Hague about¬†purely functional (retro)game programming.¬†For a guy with a OOP background like myself, the idea of writing games with “no state” comes out as absurdly fascinating, hence deserving further attention. So, in addition to the ideas presented there, here’s another tool of the trade: state machines.

Defining state machines’ states as static collections of {trigger, action, newstate} tuples, we can rethink the “Pac Man problem” as:

[{
    start_state,
    {
        {start_trigger, do_init, normal_play_state}
    }
 },
 {
    normal_play_state,
    {
        {ate_dot_trigger, calc_score, normal_play_state},
        {ate_powerpill_trigger, promote, can_eat_ghosts_state},
        {touched_ghost_trigger, die, killed_state},
        ...
    }
 },
 ...
]

We can have a separate process that receives state changing messages, and depending on the message it processes a corresponding action, such as promote(), calc_score(), etc. Supposing we use Erlang, we could exploit its messaging feature (which strictly speaking I suppose it’s not a purely functional concept yet it feels “clean” — certainly more than doing imperative programming in Common Lisp), and write something like:

compute(start_state) ->
    receive
        start_trigger ->
            do_init(),
            NewState = normal_play_state;
        _ ->
            NewState = start_state
    end,
    compute(NewState);

compute(normal_play_state) ->
    receive
        ate_dot_trigger ->
            calc_score(),
            NewState = normal_play_state;
        ate_powerpill_trigger ->
            promote(),
            NewState = can_eat_ghosts_state;
        touched_ghost_trigger ->
            die(),
            NewState = killed_state;
        ...
        ...
        _ ->
            NewState = normal_play_state
    end,
    compute(NewState);
...

Then, inside our game loop, if at the current frame we found that Pac Man ate a powerpill, a `ate_powerpill_trigger’ is sent to the state machine, making it transition to a new state:

...
ComputePID ! ate_powerpill_trigger
...

So instead of having a class with a PacMan::atePowerPill flag, we “moved” that state info into the state machine definition. ¬†The actual “state” is maintained on the stack, effectively overwritten via tail recursion.

A state machine of this sort will have a (very) long list of states, and for each state it will need to handle many different kinds of game events. In fact, theoretically speaking, we could have a single giant state machine that will recompute large portions of the game state at each transition. Alternatively, one could divide et impera, therefore having multiple state machines (one for each actor?) talking to each other.

This is pretty awkward to the OOP mindset. I can’t deny that representing it in terms of (e.g.) a pac-man object and a few ghosts objects seems straightforward. State is king, partly because we’re so used to reason in certain terms. But I can also imagine thinking in terms of “flow” instead of state, so to speak. In other words, a class can easily describe the current state in all its details, but not explicitly how it got to that state. A state machine can better describe the history across time, yet less directly describes the details.

technorati: 9GVT9D9CNX98

Why is my untested backend code more stable than my untested UI code?

Lately I’ve been quite annoyed with the bugs that sneak into my object systems, especially UI classes. Test-driven development helps out a lot against this, although for some reasons (not the topic of this post) there are cases where I skip writing the tests. Yeah, I know, it’s bad. Most of the times this happens with front end code, and sometimes with Java backend code. I just hate Java, its verbosity, its exceptions, and occasionally I fool myself into believing I can skip the tests to leave Java world ASAP. I’m often proven wrong. I’ll work on that.

Anyway the weird thing is, when I do not write unit tests, I feel like my backend code is relatively more stable than my front end code. They both lack unit tests, so in theory they should be equally bad. So why does the backend code feel more stable, and is it actually more stable?

Well, it is. I have less bugs, and the ones I get are pretty trivial compared to the front end ones. So: why is my untested backend code “better” than my equally untested UI code?

Fact is, whenever I write backend code I tend to write it in a more functional style, regardless of the language I’m using. I’m writing a service after all, so the functional paradigm kind of pushes itself in, breaking the task down into functions, using hardly any additional object hierarchies,¬†passing along whatever state I was dealing with, catching all the exceptions. Then, simply return a value. An inherently simpler design.

If I’m not modifying any object, I’m merely computing a new state. My function has no side effects, so all I really have to do is make sure it returns a correct value. With no side effects, my function is effectively decoupled from the rest of the system, and TDD becomes the most natural way to write code.

Hence I’m less likely to¬†cause bugs. There you go.

This is kind of obvious once you think about it, but it’s not that apparent when you’re knee deep into designing objects. It isn’t for me at least.

So this is my quest now.¬†Find ways to refactor object oriented systems (esp. UI) by extracting its “hidden” functional elements, whenever possible. I have some factual evidence to support this, but I need to develop a more systematic approach.