Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
261 lines (219 sloc) 8.55 KB
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<title>Erlang Tools</title>
<prepared>Matthias Lang</prepared>
<section><title>Is there a pretty printer for Erlang?</title>
If you use the emacs mode (it comes with the open source
release, in <c>lib/emacs/erlang.el</c>),
you also get a pretty printer just by printing from emacs.
<section><title>Is there an erlang formatter for CI?</title>
<url href=''>
vim-erlang-runtime</url> can do that.
<section><title>Where is the source for LEEX (the erlang lexer)?</title>
Erlang's libraries provide an Erlang equivalent for
<c>YACC</c> called <c>YECC</c>, and also one for <c>LEX</c>
called <c>LEEX</c>. Robert Virding maintains a separate <c>LEEX</c> application,
which is available via Git on
<url href="">GitHub</url>.
<section><title>Is there a diagram tool specifically for Erlang?</title>
No. Most people use general-purpose diagram
Some people see
<url href="">SDL</url>
as the natural
way of expressing telecomms problems in diagrams,
while Maurice Castro presented some interesting work on an
<url href="">
alternative notation</url> at the Erlang User Conference 1999.
UML-based tools never caught on in the Erlang world. Here's
a post from the <url
mailing list archive</url> discussing some of the reasons.
<section><title>What code testing tools and suites exist for and in Erlang/OTP?</title>
A test suite is especially useful for making sure that
"improvements" to the system haven't broken something.
The <url href="">test system</url>
for Erlang 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 <em>cover</em>,
a test coverage tool.
<url href="">QuickCheck</url> 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.
There are several open-source tools either inspired by
QuickCheck or based on similar ideas to QuickCheck, including
<url href="">Proper</url>
and <url href="">Triq</url>.
<section><title>Is there a way to benchmark an Erlang implementation?</title>
Bjorn's benchmarks are <url href="">freely available</url>. The older ESTONE benchmark
has pretty much disappeared completely.
<section><title>Does anyone have a magic file for Erlang?</title>
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.
<codeinclude file="erlang_magic_file"/>
<section><title>Which IDE should I use for Erlang development?</title>
Whichever you like; Erlang works with any IDE/editor which
handles plain-text files.
Eclipse: there is an
<url href="">Eclipse plugin for Erlang</url>.
Emacs: the Erlang distribution includes an Erlang mode
(in <c>lib/emacs/erlang.el</c>).
VIM: VIM includes a Erlang plugin. A more advanced
<url href="">
erlang VIM plugin</url> is available on GitHub.
<c>vimerl</c> is also available via vundle, specify
<c>Bundle 'jimenezrick/vimerl'</c> in your <c>vimrc</c> and do
Ultraedit: Danie Schutte contributed
a <url href="">wordfile</url> which provides syntax highlighting.
NetBeans: <url href="">ErlyBird</url>
BBEdit: a
<url href="">BBEdit module</url>
Textmate: a
<url href="">Textmate bundle</url>
IntelliJ IDEA: an
<url href="">Erlang plugin</url>
<section><title>Are there Erlang Coding Guidelines?</title>
Yes. They can be found <url
<section><title>What refactoring tools are there for Erlang</title>
There are several third-party tools which help with
code refactoring. They can also be used for a range of
other purposes.
<em>Syntax Tools</em> do
proper source->source transforms. Among other things they
can be used to modify old code so that it no longer uses
deprecated functions. The <url href="">Syntax Tools Application</url> is a standard
part of Erlang.
<em>Distel/EMACS</em> supports refactoring and interactive debugging.
The <url href="">
homepage</url> has more information.
<section><title>What static code analysis tools are there?</title>
There are several tools which detect various classes of
likely programming errors in Erlang code.
<url href="">XREF</url>
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 <url href="">Erlang Compiler</url> 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 <url href="">Dialyzer</url> 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.
<marker id="decompiling"/>
<title>Is there a "reverse compiler" for BEAM files?</title>
Or: I've lost/deleted/whatever the .erl files for my project,
can I somehow recreate it from the .beam files?
<em>If</em> the code was compiled with
the <c>debug_info</c> flag, then the .beam file
contains a 'partially compiled' representation of the
source---basically the parse tree.
Here is a simple module:
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.
[{string,5,"this is my function"}]}]},
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 <url href="">
syntax_tools</url> application can do most of the hard work.
If the abstract code is <em>not</em> 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.