Feeds:
Posts
Comments

Posts Tagged ‘Erlang’

$ uptime
14:27:19 up 566 days, 23:34, 4 users, load average: 0.29, 0.57, 0.74

Advertisements

Read Full Post »

Akka actors

I’ve been following the Coursera course titled “Principles of Reactive Programming” (link), which is almost over (next week will be the last one), and in the last two lessons we learnt how the Akka implementation of actors works.

Now, since in the last four years I have developed code using Erlang for my Ph.D. thesis (and for other secondary projects in between), I am quite used to the actors principles and architecture, but it has been quite interesting to look at them in a different implementation, and I wanted to write a couple of paragraphs on the differences with respect to Erlang, and my (brief) opinion on these differences (beside the fact that Scala is statically typed, which is huuuuuge):

  • Akka actors take TONS of syntax from Erlang, in particular: BANG! 🙂
  • seeing the messages in Scala as case classes instead of tuples is very very strange at the beginning, and it is even stranger when you assign a message to a variable: it looks like you are calling a function…
  • Akka actors have automatic supervision: processes are automatically linked (to use Erlang terminology) to their parents, and a father kills all its children by default when he dies; then you can add specifications on the supervision behavior and tune it better, and as in Erlang you need to explicitly handle the termination messages when needed. Now, this is a characteristic that I am not really sure I really like: I mean, I prefer to decide if I want to spawn a linked process or not, and to decide if I want a process to be supervised or to live by itself. Maybe this is due to the fact that in Erlang supervision works basically when you are using predefined behaviors, while here it works for everyone… I don’t know, I have to try it a little bit more to decide on this
  • the receive primitive does not fail if there is no match to a message: this is an improvement on one side, because you can freely ignore some messages that arrive to a process (they are still consumed, see below), but on the other hand you need to remember to implement the function that receives the non-matched messages in your actors, otherwise they will go to the event stream (more on this later), while in Erlang you typically write a case to catch everything else in the end of each receive block, where you log the unforeseen message. Again, mixed feelings: you need to remember stuff, but at the same time you can separate unknown messages and the reaction to them in different blocks of code, which is not bad.
  • Akka actors have the concept of context, which basically allows you to change state from time to time and create a sort-of finite state machine for actors behavior; this means that you can divide messages belonging to different phases of the actor in different blocks of code, which helps maintaining everything clearer. I really like this feature.
  • Akka has an internal pub-sub system, where actors can publish messages (using topics) and subscribe to topics; this is also the place where everything not catched goes (it is called event stream). It is an interesting concept, and I can imagine it can be quite useful (logging is the first thing that comes to mind).
  • Finally, Akka gives developers the possibility of persisting state: I don’t know this characteristic that well, essentially because I have not used it yet (only seen on slides), but it looks interesting and helps overriding the single assignment vs actors with a state…

All in all, I have to say that I like Akka actors, even if I have mixed feelings on a couple of characteristics (especially the automatic supervision, I still have to fully digest it…). Anyway, this is another reason that convinces me that if I had to start a new project from scratch today, I would use Scala for sure.

Read Full Post »

A few weeks ago I ported the Firmata library to Lua, as a first step of an experiment of a DIY Arduino Yun. For several reasons I had to postpone that experiment (reasons being writing my Ph.D. thesis, and the fact that the Carambola board has the wrong pin distance to do anything good with it), and now I have an Arduino Yun, which essentially is a Carambola done well (and I couldn’t expect less by the Arduino people).

So, the next step is to run my Erlang framework, ELIoT, on it (the fact that the Yun has double the internal flash memory of the Carambola and support for external SD cards is simply great), and to interact with the microcontroller (the usual Atmega 32u4) I needed a porting of Firmata to Erlang. The Yun team gives you a Python library for intercommunication, but since it is not C/C++ I couldn’t make a wrapper to an Erlang driver, so I decided to go (Erlang) native.

Thus, meet the library: as before, it is a simple port of the Java Processing one, meaning that it supports only analog and digital write/read operations, among the other operations of Firmata. I have tested it on the Arduino Yun: the Atmega 32u4 was running the Standard Firmata sketch, and a computer was running Erlang and the library (I still have to install Erlang on the Yun microprocessor itself), and it works, at least with the usual simple test of enabling the integrated LED and read from one of the analog sensors.

The library itself is structured as a gen_server: just one instance each time, of course.

*** UPDATE ***

Now the library works in both push and pull modes: a client can query the server to obtain the current values of sensors, or it can receive the updates directly from the server by subscribing to a specific (analog or digital) pin.

Beware that the latter will generate a new update message for each Firmata update from the Arduino (for example, the StandardFirmata sketch running on my Yun produces about 50 messages per second, one update every 20 ms). You may need to filter these messages, e.g., taking action when a certain threshold between consecutive values is exceeded.

Read Full Post »

Nexus 7

Nexus 7

VM

VM

As you know, for my Ph.D. I’m developing a specialized version of Erlang for IoT scenarios, called ELIoT (ErLang for the Internet of Things); we had it running on some known (or less known) devices, such as the Raspberry Pi or the Carambola, and in the last few days I decided it was time for Android to enter the scene.

So I ported the framework forward a couple of minor versions (from Erlang 15B to 15B03.1), and used the existing patches to cross-compile it on Android. The screenshots show it running on my Nexus 7, pinging a Linux VM running on my computer. Unfortunately, for now it has to be run as root, so the next step is to try this SL4A stuff (which was in the original patch set, but as of now it simply crashes, so being root was the easiest way to try everything).

P.S.: don’t worry about the debugging prints on the VM side, they were there simply to check that no strange bytes were passing as messages on the network.

Read Full Post »

Just a little wrapper around the SPIdev userspace kernel module; it works brilliantly on the Raspberry Pi, but before trying it you need to load the SPI module and chown the devices as follows:

sudo modprobe spi_bcm2708
sudo chown `id -u`.`id -g` /dev/spidev0.*

You can find the code here.

Read Full Post »

Edit: too much rush, looks like the code may need a slight addition, I will update it later…

So, after Martin Odersky’s lesson and its example of phone mnemonics (inspired by this article), I spent a little time and wrote an implementation in Erlang.

It may not be the best one, but it seems to work; you can find it here, for using it you need to fill in the WORDS constant with the strings which you can translate from numbers and call the translate method passing a number as string (i.e., mnemonics:translate(“5828”)).

The code follows the solution provided by Martin in his slides, maybe the code could be even more compact by using a different workflow, but I’m not sure.

Read Full Post »

This slideshow requires JavaScript.

Farò un post rapido e senza estratti di codice, dato che al momento tutta l’applicazione è un po’ messy: questo weekend ho installato una piccola Wireless Sensor Network a casa, così da avere (finalmente!) una misurazione delle temperature presenti sul soppalco e nel soggiorno del posto dove abito, ed allo stesso tempo per testare il software che stiamo per usare in un’installazione per un progetto che sto seguendo in università.

Il giro software ammetto che è lievemente complicato, e sarebbe stato più semplice usare un servizio tipo Cosm per risolverlo in parte, ma dove sarebbe il divertimento? I due nodi della WSN che fungono da sensori rilevano una volta al minuto la temperatura e l’umidità dell’ambiente dove si trovano, utilizzando un piccolo programma TinyOS che utilizza un protocollo di disseminazione sviluppato da alcuni colleghi; un terzo nodo funge da sink e riceve i dati dai primi due, ed è collegato alla porta USB di una Carambola; un secondo programma viene eseguito in quest’ultima, appoggiandosi ad una libreria C già presente in TinyOS, e da un lato riceve i messaggi e li inoltra al server che raccoglie i dati, dall’altro lato permette di modificare alcuni parametri dell’applicazione situata nei sensori.

Il server è un free tier su Amazon, ed un terzo programma, scritto in Erlang, riceve i messaggi tramite la rete, li deserializza (operazione estremamente semplice data la bit syntax del linguaggio) e li salva in un database Mnesia; un Web server poi pubblica tali dati tramite JSON verso una pagina Web estremamente semplice (presente in una delle figure), scritta utilizzando Highcharts, la quale mostra i grafici (con tanto di possibilità di zoom e cose simili).

Tutto questo ha permesso di sperimentare tutta una serie di tecnologie, dall’applicazione TinyOS (che riutilizzeremo altrove) alla libreria C, dalla bit syntax in un contesto reale all’utilizzo di Mnesia come database; ammetto inizialmente di aver pensato ad un NoSQL serio, mentre Mnesia è più una sorta di via di mezzo tra SQL e NoSQL, nel senso che non supporta questo linguaggio ma allo stesso tempo richiede uno schema dei dati (a differenza di altri tipo CouchDB).

La parte messy sta in realtà nell’applicazione Erlang, che è mescolata con una versione precedente che avevo usato accoppiata con un Arduino per raccogliere dati da un accelerometro; tra l’altro, ho anche sperimentato la generazione (semi-)automatica di releases di un programma con Erlang, e l’installazione a caldo degli aggiornamenti: spettacolare!

Read Full Post »

Older Posts »