# i

### MODULE

i

### MODULE SUMMARY

Interpreter (debugger) Interface.

### DESCRIPTION

The module `i` provides short forms for some of the functions in the `int` module.

This module also provides facilities for displaying status information about interpreted processes and break points.

It is possible to attach interpreted processes by giving the corresponding process identity only. By default, an attachment window pops up. Processes at other Erlang nodes can be attached manually or automatically .

By preference, these functions can be included in the module `shell_default`. By default, they are.

### EXPORTS

`im() -> pid()`

Starts a new graphical monitor. This is the main window of the interpreter. All of the interpreter functionality is accessed from the monitor window. The monitor window displays the status of all processes that are running interpreted modules.

`ii(AbsModule) -> {module, Module} | error`

Types:

`AbsModule = atom() | string() | [atom() | string()]`
`Module = atom()`

Marks `Module` as being interpreted. The `Module` parameter can either be a single module name, or a list of module names. `Module` is compiled into an abstract form which is loaded into the interpreter. The actual paths are searched for the corresponding source file(s) (`Module`.erl). `Module` can be given with an absolute path.

| If `Module` is a list of modules, the result of the last module is returned.

| If an interpreted module is compiled using the c:c function, this module is reloaded into the interpreter.

`iq(Module) -> ok`

Types:

`Module = atom() | string() | [atom() | string()]`

Does not interpret `Module`. The `Module` parameter can either be a single module name, or a list of module names. `Module` is removed from the set of modules currently being interpreted.

`ini(Module) -> {module,Module} | error | ok`
`inq(Module) -> ok`

Behaves as the corresponding `ii/1` and `iq/1` functions described above, but on all nodes in the network. It returns `ok` if we are `alive`, otherwise as above.

`il() -> ok`

Makes a printout of all interpreted modules. Modules are printed together with the full path name of the corresponding source code file.

`ip() -> ok`

Makes a printout of the current status of all interpreted processes. Processes on all known nodes are printed.

`ic() -> ok`

Deletes (clears) information about all terminated processes from the interpreter.

`iaa(Flag) -> true`

Types:

`Flag = FlagItem | [FlagItem]`
`FlagItem = init | break | exit | false`

Interpreted processes can be attached automatically, without the need to attach to a process using the monitor window, `i:im()` or `int:m()`. An attachment window - not described here - pops up for the attached process. `Flag` specifies at which point interpreted processes are automatically attached.

`Flag` is one of:

- `init`. Attach to a process the very first time it calls an interpreted function.
- `break`. Attach to a process whenever it reaches a break point.
- `exit`. Attach to a process when it terminates.
- `false`. Deactivate the automatic attach facility.

If several conditions are to be active, a list of flags must be given.

`iaa(Flag,Function) -> true`

Types:

`Flag = FlagItem | [FlagItem]`
`FlagItem = init | break | exit | false`
`Function = {Mod,Func}`
`Mod = atom()`
`Fun = atom()`

As above, but instead of using the default attachment window, the specified `Function` is used in order to start the interaction with the attached process. The `Function` parameter must be the tuple `{Mod,Func}`, and this function should implement the corresponding functionality in the same way as the `int_show:a_start/3,4` functions.

`ist(Flag) -> true`

Types:

`Flag = all | true | no_tail | false`

The interpreter can keep call frames in the stack for future inspections. Typically, you can go up and down in the stack in order to inspect the flow of control when the execution has been stopped - at a break point, when the process has terminated, or in a single step execution.

By default, the whole stack is kept (`Flag` = `all` or `true`). If processes with a very long life time and with a lot of tail recursive calls are interpreted, the `no_tail` flag should be used. No tail recursive calls are kept in the stack if this flag is used.

The `false` flag should be used if the interpreter is not to keep call frames.

`ia(Pid) -> ok | no_proc`

Types:

`Pid = pid()`

Attaches to the `Pid` process. An attachment window pops up.

`ia(X,Y,Z) -> ok | no_proc`

Types:

`X = Y = Z = int()`

Attaches to the process with process identity c:pid(`X`,`Y`,`Z`). An attachment window pops up.

`ia(Pid,Function) -> ok | no_proc`

Types:

`Pid = pid()`
`Function = {Mod, Fun}`
`Mod = atom()`
`Fun = atom()`

Attaches to the `Pid` process. Use `Function` for the interaction with the attached process, as for the `i:iaa/2` function.

`ia(X,Y,Z,Function) -> ok | no_proc`

Types:

`X = Y = Z = int()`
`Function = {Mod, Fun}`
`Mod = atom()`
`Fun = atom()`

Attaches to the process with process identity c:pid(`X`,`Y`,`Z`). Use `Function` for the interaction with the attached process, as for the `i:iaa/2` function.

`ib(Module,Line) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`What = badarg | break_exists`

Creates a new break point at `Line` in `Module`. The execution of an interpreted process will be stopped before the expression at `Line` in `Module` is executed.

`ib(Module,Function,Arity) -> ok | {error, What}`

Types:

`Module = atom()`
`Function = atom()`
`Arity = int()`
`What = badarg | function_not_found`

Creates break points at the first line in every clause of the `Module`:`Function`/`Arity` function.

`ir(Module,Line) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`What = badarg | no_break_exists`

Deletes the break point located at `Line` in `Module`.

`ir() -> ok`

Deletes all existing break points.

`ir(Module) -> ok`

Types:

`Module = atom()`

Deletes all existing break points in `Module`.

`ir(Module,Function,Arity) -> ok | {error, What}`

Types:

`Module = atom()`
`Function = atom()`
`Arity = int()`
`What = badarg | function_not_found`

Deletes break points at the first line in every clause of the `Module`:`Function`/`Arity` function.

`ibd(Module,Line) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`What = badarg | no_break`

Makes the break point at `Line` in `Module` inactive. The break point still exists, but no processes will be stopped at the break point.

`ibe(Module,Line) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`What = badarg | no_break`

Makes the break point at `Line` in `Module` active. Processes will again be stopped at the break point.

`iba(Module,Line,Action) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`Action = enable | disable | delete`
`What = badarg | no_break`

Sets the status of the break point at `Line` in `Module` after it is triggered the next time. `Action` is: `enable`, `disable`, or `delete`.

`ibc(Module,Line,Function) -> ok | {error, What}`

Types:

`Module = atom()`
`Line = int()`
`Function = {M,F}`
`Mod = atom()`
`Func = atom()`
`What = badarg | no_break`

Makes the break point at `Line` in `Module` conditional. `Function` is called whenever the break point is reached. `Function` is a tuple `{Mod,Func}`. `Function` must have `arity 1` and return either `true` or `false`. This way, the break point either triggers, or not. The argument to `Function` is the current variable bindings of the process at the place of the break point. The bindings can be inspected using `int:get_binding/2`.

`ipb() -> ok`

Makes a printout of all existing break points.

`ipb(Module) -> ok`

Types:

`Module = atom()`

Makes a printout of all existing break points located in `Module`.

`iv() -> atom()`

Returns the current version number of the interpreter.

`help() -> ok`

Prints help text.

### Usage

Refer to the Debugger User's Guide for information about the graphical interface.

### See Also

int(3), code(3)

### AUTHORS

Magnus Fröberg - support@erlang.ericsson.se

debugger 2.3.2
Copyright © 1991-2005 Ericsson AB