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. (...)
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
Labview in Erlang
Sun Aug 13 21:44:30 BST 2006
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.
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. (...)
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
- SQL = set theory
- Event driven programming
- object oriented programming
- communicating sequential processes
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. (...)
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. (...)