Blog - erlang

Labview dataflow programming in Erlang

Tue Nov 28 21:09:38 EST 2006

Labview is a commonly used language for setting up experiments. It has a number of nice features:

• programs are written in a graphical programming language, ie by moving icons around a diagram to create a schematic representation of the experiment
• program execution is data-flow oriented, ie each icon has a number of inputs and outputs, and only outputs data once all of its inputs have received data. This seems a natural way of modelling signal processing tasks.

Erlang is a language where concurrency is the main consideration. The Erlang virtual machine can create independent lightweight processes at very little cost, with the processes communicating via message passing to unique process identifiers (PIDs).
Here I am going to consider the problem of programming Labview-like data-flow oriented programming in Erlang. (...)

[code] [erlang]

[permalink]

Ideas for Erlang server software

Thu Aug 17 08:42:35 BST 2006

From the Erlang mailing list, Dário Abdulrehman wrote:

Erlang is well suited for writing scalable server software and I am currently looking for interesting server software projects that can be done.

Ideas proposed in that message and the following thread:

• VOD Video On Demand http://vodka.lfcia.org/
• Instant Messaging (ejabberd)
• Joel Reymont is working on trading software
• [A cometd implementation:]
• Radiosity based tracer.
• An AJAX/Comet-based online chess game.
• web based chat with yaws, dojo 0.3, suffering, and endurance
• an RTP implementation in Erlang

[code] [erlang]

[permalink]

Labview in Erlang

Sun Aug 13 21:44:30 BST 2006

Introduction

Labview is the common programming language used for data acquisition in the experimental sciences (although Matlab is also very popular). The main selling point of Labview is the ability to write programs in a graphical programming language where functions are "virtual instruments" with defined inputs and outputs joined together by wires. This allows for "data flow" based programming where the output of a virtual instrument is calculated as soon as all of the inputs are available.

Initial thoughts

In Erlang the input and output messages can be represented by messages, and the virtual instruments by processes. The tricky thing is to represent the data flow of the input messages so that the process calculates the outputs only when all of the input messages have arraived. Take a simple example of a process that requires three data inputs to calculate its output. (...)

[code] [erlang] [ideas]

[permalink]

Is concurrency hard?

Fri May 5 11:50:20 BST 2006

• [Erlang mailing list]
• Concurrency is not hard, it is just a different way of modelling the world than we are used to with traditional programming languages. There are a number of other non-sequential programming paradigms
  • SQL = set theory
  • Event driven programming
  • object oriented programming
  • communicating sequential processes

[erlang]

[permalink]

OTP behaviours from Joe Armstrong's thesis

Wed Apr 19 17:09:07 BST 2006

• "let it crash", only write code to respond to messages that you expect, not catch-all clauses. It is best that the module crashes as soon and a noisily as possible if something unexpected happens, and in an OTP application it will be restarted anyway.
• gen_event responds to streams of events, doesn't necessarily reply to the process sending the event to the handler
• "The application is built bottom up starting with the worker nodes"
• gen_events are used for applications such as error logging, alarm handling, debugging and equipment management (p138)
• gen_fsm can be modelled as a set of rules of the form State x Event -> Action x State'
• supervisors are "meta-behaviours" that are used to glue the primitive behaviours into a supervision tree
• behaviours use callback modules that must implement a number of predefined functions for each behaviour eg handlecall for a genserver, handleevent for a genfsm. (...)

[erlang]

[permalink]

OTP behaviours from the man pages

Wed Apr 19 17:03:38 BST 2006

• gen_server A behaviour module for implementing the server of a client-server relation.
• gen_fsm A behaviour module for implementing a finite state machine.
• gen_event A behaviour module for implementing event handling functionality. The OTP event handling model consists of a generic event manager process with an arbitrary number of event handlers which are added and deleted dynamically. Each event handler is implemented as a callback module exporting a pre-defined set of functions.
• supervisor A behaviour module for implementing a supervisor, a process which supervises other processes called child processes. A child process can either be another supervisor or a worker process. Worker processes are normally implemented using one of the genevent, genfsm, or gen_server behaviours. The supervisor is responsible for starting, stopping and monitoring its child processes. (...)

[erlang]

[permalink]