In Erlide we often use the terms runtime and backend. Here we will try to make clear what each of them means.
Describes an Erlang installation by pointing to its home directory and optionally adding extra code path entries and/or arguments. For example, one might want to have two R15B runtimes defined, one with and one without SMP enabled, and be able to refer to them quickly. At the moment, this installation must be a full installation (from the source with documentation) but at a future time we want to support other repository formats (CEAN, Faxien).
A backend definition is a set of startup parameters for an Erlang node, based on a specific runtime (as above) and identified by a node name. Any other command-line parameter can be specified.
A backend is an instance of an Erlang node described (possibly started) with the parameters specified by a backend definition. It has erlide-specific code running on it.
There are two kinds of backends: managed and standalone. The Erlang node behind a managed backend is started and stopped by Erlide. The one behind a standalone one has an independent life cycle. A managed backend’s definition must include a runtime; for a standalone one, the reference is informative only since the Erlang node is already started.
There are several kinds of backends: ide, build and execution. A single Erlang node may very well be behind several backends, but only at most one of them must be managed.
Execution backend – The execution backend is where the code is loaded and run/debugged. It is specified in an Eclipse run or debug configuration.
version(build) <= version(execution).
In some environments, Java and Erlang don’t look for the default
.erlang.cookiefile in the same places. This will result in failure to connect the two nodes. There are two ways to solve that:
- check where the two VMs look for the file and make sure that identical copies are found in each place. Usually this happens if the
HOMEvariable points to some other place than the real home, for example to
- enter some value in the cookie field. If the Erlang node is already running, then of course the entered value should be identical to the one it uses.
Did you find errors in the documentation? Do you have improvements to suggest? Suggest edits!