Bluish Coder: erlang

Building Erlang for Android

2015-06-21T19:00:00+12:00

Support for building Erlang on Android is provided in the standard Erlang source.

Build setup

I use the Erlang git version for building. Cloning can be done with:

git clone https://github.com/erlang/otp

In the xcomp directory of the cloned repository there is an erl-xcomp-arm-android.conf file that contains details for cross compiling to Android. This can be modified per the instructions in the Erlang cross compilation documentation but the defaults are probably fine.

Some environment variables need to be set to locate the Android NDK:

export NDK_ROOT=/path/to/ndk/root
export NDK_PLAT=android-21

The NDK_PLAT environment variable identifies the Android API version to use for building. In this case android-21 is for KitKat (See STABLE-APIS.html).

Add the path to the Android version of the gcc compiler:

export PATH=$PATH:$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin

When building from the git repository an initial step of generating configuration files needs to be done. This requires autoconf version 2.59. If autoconf2.59 is the command to run this version you may need to change some symlinks or defaults for your OS or you can edit the otp_build file to replace occurences of autoconf with autoconf2.59.

Building

Building from git requires generating build configuration files first:

./otp_build autoconf

Once generated, run the configure step. This will configure both a host version of Erlang for bootstrapping and the Android version:

./otp_build configure --xcomp-conf=xcomp/erl-xcomp-arm-android.conf

Build a bootstrap system of Erlang for the host machine, followed by one for the Android target:

./otp_build boot -a

Installing

Installing to an Android device involves running a build step to copy the files to a temporary directory, run a script to change paths to the directory where the installation will be on the Android device and pushing the final result to the device.

In the following series of commands I use /tmp/erlang as the temporary directory on the host system and /data/local/tmp/erlang as the install directory on the Android device. The directory /data/local/tmp is writable on non-rooted Android KitKat devices. It's useful for testing.

./otp_build release -a /tmp/erlang
cd /tmp/erlang
./Install -cross -minimal /data/local/tmp/erlang

One of the files bin/epmd is a symlink which adb push has problems with. For the copying of the files below I delete the file and manually recreate the symlink after the push:

adb shell mkdir /data/local/tmp/erlang
cd /tmp
rm erlang/bin/epmd
adb push erlang /data/local/tmp/erlang/
adb shell ln -s /data/local/tmp/erlang/erts-6.4.1/bin/epmd \
                /data/local/tmp/erlang/bin/epmd

The adb commands assume the device is already connected and can be accessed via adb.

Running

Once the final push completes Erlang can be run via adb shell or a terminal application on the device:

$ adb shell
$ cd /data/local/tmp/erlang
$ sh bin/erl    
Eshell V6.4.1  (abort with ^G)
1>

You may get an error about sed not being found. This is due to a sed command run on the first argument of the erl shell script. A workaround for this is to build an Android version of sed and install it along with Erlang.

Networking

I've tested with some basic Erlang functionality and it works fine. Some tweaks need to be made for networking however. The method Erlang uses for DNS lookup doesn't work on Android. By default it's using native system calls. With a configuration file it can be changed to use its own internal DNS method. Create a file with the following contents:

{lookup, [file,dns]}.
{nameserver, {8,8,8,8}}.

In this case the nameserver for DNS lookups is hardcoded to Google's DNS. Ideally this would be looked up somehow using Android functionality for whatever is configured on the phone but this works for test cases. Push this file to the device and run erl with it passed as an argument like so (inetrc is the name I used for the file in this case):

$ adb push inetrc /data/local/tmp/erlang/
$ adb shell
$ cd/data/local/tmp/erlang
$ sh bin/erl -kernel inetrc '"./inetrc"'

Network examples should now work:

1> inets:start().
ok
2> inet_res:getbyname("www.example.com",a).
{ok,{hostent,"www.example.com",[],inet,4,[{93,184,216,34}]}}
3> httpc:request(get, {"http://bluishcoder.co.nz/index.html", []}, [], []).
{ok,...}

More information on the inetrc file format is available in the Erlang documentation.

Conclusion

This showed that a basic installation of Erlang works on Android. I've also tested on a Firefox OS phone with root access. An interesting project would be to install Erlang on either a Firefox OS or an Android AOSP build as a system service and write phone services in Erlang as a test for an Erlang based device.

Erlang on the OpenMoko Cellphone

2007-09-16T15:32:00+12:00

Tony Garnock-Jones has got Erlang running on the OpenMoko phone:

Running the interactive erlang shell on a cellphone is pretty cool. Erlang's built-in clustering support works fine: I've successfully connected an erlang node on my pc to a node on the phone using the USB ethernet support the phone provides.

Erlang and Mobile Phones

2007-01-05T14:55:00+13:00

Luke Gorrie has started a new weblog and he's posting about his experiences learning Squeak Smalltalk. In his first post to the weblog he mentions what he's been working on the past couple of years:

The past couple of years I've instead worked really hard with some friends to build up a happy little Erlang company with an office where we drink our coffee. We've developed and marketed a system for mobile phone companies to keep track of all the mobile phones their customers are using and to automatically send configurations for picture messaging, web browsing, and so on. We've installed these systems in over 60 countries and have more than 200 million of you puny humans represented in our Mnesia databases. We're the market leaders and have only a fraction of our competitors' staff size, but of course you guessed this when I said "Erlang". :-)

Trapexit is back

2006-07-19T15:00:00+12:00

Trapexit, one of the best Erlang resource websites is back in action. The forum on trapexit mirrors the Erlang mailing list and has a much better search mechanism it's a great resource and I missed it while Trapexit was down. Announcement of Trapexit coming back is here.

Lightweight Erlang with Package Management

2006-07-01T15:32:00+12:00

A post on the Erlang mailing points to a lightweight distribution of Erlang with package management facilities to enable installing extra functionality.

The first install is a 1.4MB file which expands to 3MB. This is compares favourably to a full Erlang installation of 35MB (for the windows download).

Functions are included to list, install, remove and upgrade packages.

Little Smalltalk and Javascript for Minix

2006-06-22T01:17:00+12:00

I've been working on porting some small programs to Minix to get familiar with what's required for ports. From there I hope to get some bigger stuff working that I really want to use like Factor and Erlang.

So far I have Little Smalltalk working (including the web based class browser and editor) and SpiderMonkey Javascript.

Porting is a little bit painful as there's quite a few things different under Minix. Eventually I want to try and develop some simple device drivers using these languages to see if the idea of user space device drivers in alternate languages is workable.

HTML Template Languages

2006-06-20T11:56:00+12:00

There's a discussion going on in the Erlang mailing list about HTML template engines. This is JSP-style definition of HTML pages with portions replaced dynamically with data from an application.

I've leaned towards building HTML pages in code using Lisp style S-expressions for HTML, or Seaside style building of pages. This is also the approach I took in building the Factor continuation based web server and examples.

For the recent Factor program I built I wanted to use a template engine though. It was a bigger program and it was easier to modify templates and see the change automatically. For that I used an engine that another contributer had provided which allowed embedded Factor code.

The mailing list post pointed to a paper called 'Enforcing Strict Model-View Separation in Template Engines' which describes limiting the power of a template engine to prevent developers from embedding to much application logic in the template page. I was dubious but the paper is quite convincing.

It mentions 'StringTemplate', an engine built on these ideas. I'm still looking for a good way of doing templates in Factor, Erlang, and other languages, so this might be a good source of ideas.

If anyone has pointers to other articles or ideas on the topics please feel free to leave a comment or email me.

Real-time Wiki

2006-06-15T16:24:00+12:00

From the Erlang mailing list comes a pointer to 'Real-time Wiki'.

It's a Google Summer of Code project that allows using XMPP (ie. Jabber) from a browser based client. Values can be changed from the server and the change is broadcast to the clients and instantly updated. It seems that the application for this is a Wiki that updates automatically when others change it.

The implementation on the server side uses ejabberd, a Jabber server written in Erlang.

Handling X-Forwarded-For in Yaws

2006-05-25T01:44:00+12:00

I run a Yaws webserver behind a Pound proxy. This works really well but all the IP addresses logged by Yaws appear as the localhost (127.0.0.1). This is due to Yaws picking up the IP address of the proxy as it forwards the request.

Pound sends the original IP address as a header in the HTTP request called X-Forwarded-For. This finally bugged me enough to modify Yaws to display the X-Forwarded-For IP address if the header was there, otherwise display the normal IP address.

The 'quick hack' change was quite simple. I modified the include/yaws_api.hrl file to add x_fowarded_for to the headers record:

-record(headers, {
   connection,
   accept,
   host,
   if_modified_since,
   if_match,
   if_none_match,
   if_range,
   if_unmodified_since,
   range,
   referer,
   user_agent,
   accept_ranges,
   cookie = [],
   keep_alive,
   location,
   content_length,
   content_type,
   content_encoding,
   authorization,
   transfer_encoding,
   x_forwarded_for,
   other = []   %% misc other headers
  }).

The idea being that this value will be set by Yaws when it first parses the HTTP request headers. This is done by modifying the http_collect_headers function in 'src/yaws.erl' to contain the following code:

{ok, {http_header, _Num, 'X-Forwarded-For',_, X}} ->
     http_collect_headers(CliSock, Req, H#headers{x_forwarded_for = X},SSL)

This was basically a copy and paste of the way the other headers are handled. In the code that handles the logging I just check for the header and output the IP address if it is there, otherwise use the IP address from the request itself. This is done by a helper function I added to src/yaws_server.erl:

x_forwarded_for_or_ip(Ip, Item)->
    case Item of
        undefined -> Ip;
        Item -> yaws:parse_ip(Item)
    end.

The 'Item' passed to this function is the x_forwarded_for element of the 'headers' record. If the 'X-Forwarded-For' header exists I parse the string into an IP address using yaws:parse_ip/1.

All that remains is to change the maybe_access_log/3 in src/yaws_server.erl to call this helper function:

     TrueIp = x_forwarded_for_or_ip(Ip, H#headers.x_forwarded_for),
     yaws_log:accesslog(SC#sconf.servername, TrueIp, User,
          [Meth, $\s, Path, $\s, Ver], 
          Status, Len, Referrer, UserAgent);

Now all my IP's appear correctly forwarded from Pound in the Yaws server.

Erlang SMP Benchmarks

2006-03-10T08:01:00+13:00

Joe Armstrong has started a weblog and on it he has posted results of some testing of the Erlang SMP snapshot.

Program 1 spawned N (typically 1000) processes on 4 processors. Each process then pings all the other processes. This an 3.6 times faster on 4 CPUs than on a single CPU.

...

Program 2 is a SIP stack - this ran 1.8 times faster on 4 processors than on 1 processor.

...

These result are pretty good - to start with the Erlang system is unoptimized, as is the application. Despite this fact the application runs almost twice as fast on a four CPU system as it ran on a single CPU system.