int
INT
模块
int
模块摘要
解释器接口
描述
Erlang解释器提供断点和逐步执行代码的机制。它主要用于调试器，请参阅用户指南和debugger(3)。
可以从shell执行以下操作：
- 指定要解释的模块。
- 指定断点。
- 监视在解释模块中执行代码的所有进程的当前状态，以及其他Erlang节点上的进程。
通过附加到执行解释代码的进程，可以检查变量绑定并逐步执行。这是通过第三个进程（称为元进程）向进程发送信息和从进程接收信息来完成的。你可以实现你自己的附加过程。查看int.erl可用功能和dbg_wx_trace.erl可能的消息。
解释器依赖于内核、STDLIB和GS应用程序。这意味着不允许解释属于这些应用程序中任何一个的模块，因为它可能导致死锁或模拟器崩溃。这也适用于属于调试器应用程序的模块。
断点
断点是以行为基础指定的。当执行解释模块中的代码的进程到达断点时，它停止。这意味着断点必须设置在可执行的行，也就是包含可执行表达式的代码行。
断点具有以下内容：
- 一个状态，这是
活性或无活性。一个不活动的断点被忽略。
- 触发器动作。当达到断点时，触发器动作指定断点是继续激活（
启用），还是变为非激活（禁用）或删除（删除）。
- 可选地，关联的条件。条件是一个元组
{Module,Name}。当达到断点时，Module:Name(Bindings)被调用。如果评估结果为true执行停止。如果评估为false，则忽略断点。Bindings包含当前的变量绑定。要检索指定变量的值，请使用get_binding。
默认情况下，断点处于活动状态，具有触发器操作enable，并且没有关联条件。有关断点的详细信息，请参阅用户指南。
出口
i(AbsModule) -> {module,Module} | errori(AbsModules) -> okni(AbsModule) -> {module,Module} | errorni(AbsModules) -> ok
类型
解释指定的模块。i/1仅在当前节点解释模块。ni/1解释所有已知节点上的模块。
模块可以通过模块名称（原子）或文件名来指定。
如果由其模块名称指定，则Module.beam在当前路径中搜索目标代码。Module.erl首先在与目标代码相同的目录中搜索源代码，然后在其src旁边的目录中搜索源代码。
如果通过文件名指定，文件名可以包含路径，.erl扩展名可以省略。Module.beam首先在与源代码相同的目录中搜索目标代码，然后在其ebin旁边的目录中搜索目标代码，然后在当前路径中搜索目标代码。
注
解释器需要源代码和目标代码。目标代码必须包含调试信息，也就是说，只有用选项debug_info集编译的模块才能被解释。
如果模块被解释，则函数返回{module,Module}，否则error返回。
参数也可以是模块或文件名列表，在这种情况下，函数会尝试按照前面指定的方式解释每个模块。然后该函数总是返回ok，但是stdout如果模块不能被解释则打印一些信息。
n(AbsModule) -> oknn(AbsModule) -> ok
类型
停止解释指定的模块。n/1仅在当前节点停止解释模块。nn/1停止在所有已知节点解释模块。
至于i/1和ni/1，模块可以通过其模块名称或文件名来指定。
interpreted() -> [Module]
类型
返回所有解释模块的列表。
file(Module) -> File | {error,not_loaded}
类型
返回File解释模块的源代码文件名Module。
interpretable(AbsModule) -> true | {error,Reason}
类型
检查是否可以解释模块。该模块可以通过其模块名称Module或其源文件名来指定File。如果通过模块名称指定，则在代码路径中搜索模块。
如果以下所有条件都适用，则函数返回true：
- 找到了模块的源代码和目标代码。
- 该模块已使用选项
debug_info集进行编译。
- 该模块不属于任何应用程序内核，STDLIB，GS或调试器。
如果模块不能被解释，则函数返回{error,Reason}。Reason可以具有以下值：
no_src
没有找到源代码。据推测，在源代码和目标代码都位于任一在相同的目录，或在src和ebin目录相互下。
no_beam
没有找到目标代码。据推测，在源代码和目标代码都位于任一在相同的目录，或在src和ebin目录相互下。
no_debug_info
该模块尚未使用选项debug_info集进行编译。
badarg
AbsModule未找到。这可能是因为指定的文件不存在，或者因为code:which/1没有返回BEAM文件名，这种情况不仅适用于不存在的模块，而且也适用于预加载或覆盖编译的模块。
{app,App}
App是kernel，stdlib，gs，或debugger，如果AbsModule属于这些应用程序中的一个。
请注意，该函数可以返回true一个模块，该模块实际上在模块被标记为粘滞或驻留在标记为粘滞的目录中的情况下不可解释。原因是直到解释器试图加载模块时才发现它。
auto_attach() -> false | {Flags,Function}auto_attach(false)auto_attach(Flags, Function)
类型
获取并设置何时以及如何自动附加到解释模块中执行代码的流程。false意味着不会自动附加，这是默认设置。否则，自动附加由标志和功能列表定义。可以指定以下标志：
init-当进程第一次调用解释函数时附加。
break-每当进程到达断点时附加。
exit-进程结束时附加。
当发生指定事件时，函数Function称为：
spawn(Module, Name, [Pid | Args])
Pid执行解释代码的进程的PID。
stack_trace() -> Flagstack_trace(Flag)
类型
获取并设置如何在堆栈中保存呼叫帧。保存调用帧可以检查进程的调用链，并且如果发生错误（类错误的异常），也可以用它来模拟堆栈跟踪。可以指定以下标志：
all
保存有关所有当前调用的信息，即尚未返回值的函数调用。
no_tail
保存关于当前呼叫的信息，但在进行尾递归调用时放弃先前的信息。此选项消耗较少的内存，并且可能需要用于具有较长生命周期和多次尾递归调用的进程。这是默认设置。
false
保存关于currentcalls的信息。
break(Module, Line) -> ok | {error,break_exists}
类型
在Linein 创建一个断点Module。
delete_break(Module, Line) -> ok
类型
删除断点Line在Module。
break_in(Module, Name, Arity) -> ok | {error,function_not_found}
类型
在函数的每个子句的第一行创建一个断点Module:Name/Arity。
del_break_in(Module, Name, Arity) -> ok | {error,function_not_found}
类型
在函数的每个子句的第一行删除断点Module:Name/Arity。
no_break() -> okno_break(Module) -> ok
删除所有断点或所有断点Module。
disable_break(Module, Line) -> ok
类型
使得断点Line在Module无效。
enable_break(Module, Line) -> ok
类型
使得断点Line在Module活跃。
action_at_break(Module, Line, Action) -> ok
类型
在设置断点的触发行动Line中Module来Action。
test_at_break(Module, Line, Function) -> ok
类型
在设置断点的条件测试Line中Module来Function。该功能必须满足章节中规定的要求Breakpoints。
get_binding(Var, Bindings) -> {value,Value} | unbound
类型
检索Var此函数用于断点的条件函数。
all_breaks() -> [Break]all_breaks(Module) -> [Break]
类型
获取所有断点或所有断点Module。
snapshot() -> [Snapshot]
类型
获取有关执行解释代码的所有进程的信息。
Pid-进程标识符。
Function-程序调用的第一个解释函数。
Status-进程的现状。
Info-更多信息。
Status为下列之一：
idle- 该进程不再执行解释代码。Info={}。
running- 进程正在运行。Info={}。
waiting- 这个过程正在等待receive。Info={}。
break- 进程执行停止，通常在断点处。Info={Module,Line}。
exit- 过程终止。Info=ExitReason。
no_conn- 连接到运行进程的节点。Info={}。
clear() -> ok
通过删除有关终止进程的所有信息，清除有关执行解释代码的进程的信息。
continue(Pid) -> ok | {error,not_interpreted}continue(X,Y,Z) -> ok | {error,not_interpreted}
类型
恢复Pid或执行流程执行c:pid(X,Y,Z)。
