Erlang logo

Erlang Tools

Cover

Expand All
Contract All

Table of Contents

7 Erlang Tools

7.1  Is there a pretty printer for Erlang?

If you use the emacs mode (it comes with the open source release, in lib/emacs/erlang.el), you also get a pretty printer just by printing from emacs.

7.2  Where is the source for LEEX (the erlang lexer)?

Erlang's libraries provide an Erlang equivalent for YACC called YECC, but there is no equivalent for LEX. Robert Virding wrote one called LEEX, which is available as a 'user contribution' on trapexit.

7.3  Is there a diagram tool for Erlang?

Not really, most people use general-purpose diagram tools like tcm or xfig. TCM, in particular, is highly recommended. Some people see SDL as the natural way of expressing telecomms problems in diagrams, while Maurice Castro presented some interesting work on an alternative notation at the Erlang User Conference 1999.

The first thing many people say is "what about Rose". An Ericsson project took a look at using Rose for Erlang projects, and concluded that it wasn't worth using for a whole host of reasons (you can read Ulf Wiger's post about an investigation into using Rose as much more than just a diagram tool in the mailing list archive.

The essential reason for Rose and such not looking promising for use with Erlang is that the way you model a problem in Erlang is rather different to the way you decompose a problem with OO. While you're worrying about processes, gen_servers, asynchronous messages and supervision trees the tool wants to help you with singletons, exceptions, threads and templates.

7.4  What code testing tools and suites exist for and in Erlang/OTP?

A test suite is especially useful for making sure that "improvements" to the system haven't broken something. The test system for Erlang. The test server can be used for testing your project and it includes test suites for the Erlang emulator and erlang stdlib.

The standard Erlang/OTP installation includes cover, a test coverage tool.

QuickCheck is a commercial tool for automatically generating random test cases from a property written in Erlang itself. When a failing test case is detected, this test case is automatically reduced to a minimal failing case to simplify fault analysis.

7.5  Is there a way to benchmark an Erlang implementation?

Bjorn's benchmarks are freely available. The older ESTONE benchmark has pretty much disappeared completely.

7.6  Does anyone have a magic file for Erlang?

Magic files are used on unix systems with a tool called "file" to identify files. Here's an addition to /etc/magic which allows "file" to identify BEAM and JAM files.

7.7  Is there an Erlang IDE?

The "official" development environment for Erlang is Emacs, and there's a special emacs mode for Erlang. This can be found in lib/emacs/erlang.el under the source tree.

VI fans have several options. There is a colouring mode for nedit. VIM has a fully-fledged Erlang mode. A basic version is included in VIM as of version 5.6, a much more complete version is available for download.

There is an Eclipse plugin for Erlang.

Some Windows developers use Ultraedit. Danie Schutte contributed a wordfile which provides syntax highlighting.

There is an Erlang editor for NetBeans : ErlyBird

There is a BBEdit module

There is a Textmate bundle

There is a defunct X IDE for unix systems called "xerl". It isn't worth using.

7.8  Are there Erlang Coding Guidelines?

Yes. They can be found here

7.9  What refactoring tools are there for Erlang

There are several third-party tools which help with code refactoring. They can also be used for a range of other purposes.

Syntax ToolsRichard Carlsson's syntax tools do proper source->source transforms. Among other things they can be used to modify old code so that it no longer uses deprecated functions. It is available on the user contributions page

Distel/EMACS is an EMACS monstrosity with support for refactoring and interactive debugging. The homepage has more information.

7.10  What static code analysis tools are there?

There are several tools which detect various classes of likely programming errors in Erlang code.

XREF finds all undefined module calls in a set of modules, i.e. it catches errors caused by mistyping module or function names, among others.

The Erlang Compiler has several in-built options which help detect problems. Most of these (e.g. reporting unused variables, unused functions and some classes of dead code) are enabled by default.

The Dialyzer is a dedicated static code analysis tool which examines .beam object files. Among other things, it does a global analysis and reports dead code and some classes of type error. Highly recommended.

7.11  Is there a "reverse compiler" for BEAM files?

Or: I've lost/deleted/whatever the .erl files for my project, can I somehow recreate it from the .beam files?

If the code was compiled with the debug_info flag, then the .beam file contains a 'partially compiled' representation of the source---basically the parse tree.

Here is a simple module:

     -module(hw).
     -export([go/0]).

     go() when true ->
       "this is my function".

and the corresponding abstract code:


     3> {ok, {hw, [{abstract_code, Abs}]}} =  beam_lib:chunks("hw.beam", [abstract_code]), Abs.
         {raw_abstract_v1,[{attribute,1,file,{"./hw.erl",1}},
                  {attribute,1,module,hw},
                  {attribute,2,export,[{go,0}]},
                  {function,4,
                            go,
                            0,
                            [{clause,4,
                                     [],
                                     [],
                                     [{string,5,"this is my function"}]}]},
                  {eof,6}]}

Writing a decompiler which can turn the above example back to source is a fifteen minute job. Writing a decompiler which handles more complex Erlang code is more time consuming, but not much harder. The syntax_tools package from the jungerl can be used to do most of the hard work.

If the abstract code is not present in the beam file, the problem gets much harder. It is possible to study the remaining information and draw some conclusions about what the original .erl file might have looked like, for instance which functions were exported. But a lot of other important information, such as variable names, is not present. In general, recreating the source code from a beam file without abstract code is not practical.