Erlang logo

Erlang 工具

封面

展开全部
收缩全部

目录

7 Erlang 工具

7.1  Erlang 是否有漂亮打印机?

如果您使用 emacs 模式(它随开源版本一起提供,在 lib/emacs/erlang.el 中),您只需从 emacs 打印即可获得漂亮打印机。

7.2  CI 是否有 Erlang 格式化程序?

vim-erlang-runtime 可以做到这一点。

7.3  LEEX(Erlang 词法分析器)的源代码在哪里?

Erlang 的库为 YACC 提供了等效的 Erlang 版本,称为 YECC,也为 LEX 提供了一个版本,称为 LEEX。Robert Virding 维护了一个独立的 LEEX 应用程序,可以通过 GitHub 上的 Git 获取。

7.4  是否有专门针对 Erlang 的图表工具?

没有。大多数人使用通用图表工具。

有些人认为 SDL 是在图表中表达电信问题的自然方式,而 Maurice Castro 在 1999 年的 Erlang 用户大会上展示了一些关于 替代表示法 的有趣工作。

基于 UML 的工具从未在 Erlang 世界中流行起来。以下是来自 邮件列表存档 的一篇帖子,讨论了一些原因。

7.5  Erlang/OTP 有哪些代码测试工具和套件?

测试套件对于确保对系统的“改进”没有破坏任何东西特别有用。Erlang 的 测试系统 可以用于测试您的项目,它还包括用于 Erlang 模拟器和 Erlang stdlib 的测试套件。

标准 Erlang/OTP 安装包括 cover,这是一个测试覆盖率工具。

QuickCheck 是一款商业工具,用于从用 Erlang 本身编写的属性中自动生成随机测试用例。当检测到失败的测试用例时,此测试用例将自动缩减为最小的失败用例,以简化故障分析。

有几个开源工具,要么受 QuickCheck 的启发,要么基于与 QuickCheck 相似的理念,包括 ProperTriq

7.6  有没有办法对 Erlang 实现进行基准测试?

Bjorn 的基准测试是 免费提供 的。旧的 ESTONE 基准测试几乎完全消失了。

7.7  是否有人拥有 Erlang 的魔术文件?

魔术文件用于 Unix 系统,并与名为“file”的工具一起使用来识别文件。以下是 /etc/magic 的补充内容,它允许“file”识别 BEAM 和 JAM 文件。

7.8  我应该使用哪个 IDE 进行 Erlang 开发?

您喜欢哪个都可以;Erlang 可以与处理纯文本文件的任何 IDE/编辑器配合使用。

Eclipse:有一个 Erlang 的 Eclipse 插件

Emacs:Erlang 发行版包含一个 Erlang 模式(在 lib/emacs/erlang.el 中)。

VIM:VIM 包含一个 Erlang 插件。一个更高级的 Erlang VIM 插件 可在 GitHub 上获得。 vimerl 也可以通过 vundle 获得,在您的 vimrc 中指定 Bundle 'jimenezrick/vimerl',然后执行 BundleInstall

Ultraedit:Danie Schutte 贡献了一个 wordfile,它提供了语法高亮显示。

BBEdit:一个 BBEdit 模块

Textmate:一个 Textmate 捆绑包

IntelliJ IDEA:一个 Erlang 插件

7.9  是否有 Erlang 编码指南?

是的。可以在 此处 找到它们。

7.10  Erlang 有哪些重构工具?

有几个第三方工具可以帮助进行代码重构。它们还可以用于一系列其他目的。

语法工具 执行正确的源代码->源代码转换。除其他外,它们可以用于修改旧代码,使其不再使用已弃用的函数。语法工具应用程序 是 Erlang 的标准部分。

Distel/EMACS 支持重构和交互式调试。主页 提供了更多信息。

7.11  有哪些静态代码分析工具?

有几个工具可以检测 Erlang 代码中各种可能出现的编程错误。

XREF 查找一组模块中所有未定义的模块调用,即它捕获由模块或函数名称拼写错误造成的错误,以及其他错误。

Erlang 编译器 有几个内置选项可以帮助检测问题。这些选项中的大多数(例如,报告未使用的变量、未使用的函数和某些类型的死代码)默认情况下是启用的。

Dialyzer 是一款专门的静态代码分析工具,它检查 .beam 对象文件。除其他外,它执行全局分析并报告死代码和某些类型的类型错误。强烈推荐。

7.12  BEAM 文件是否有“反编译器”?

或者:我已经丢失/删除/或者其他原因导致我的项目中的 .erl 文件不见了,我能不能从 .beam 文件中重建它呢?

**如果**代码在编译时使用了 debug_info 标志,那么 .beam 文件中包含一个源代码的“部分编译”表示——基本上就是解析树。

这是一个简单的模块

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

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

以及相应的抽象代码

     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}]}

编写一个反编译器将上面的例子还原成源代码,这只需十五分钟的工作量。编写一个能够处理更复杂 Erlang 代码的反编译器需要更多的时间,但难度并没有大很多。 syntax_tools 应用可以完成大部分繁重的工作。

如果 .beam 文件中**没有**抽象代码,问题就变得更加困难了。可以通过研究剩余的信息并得出一些关于原始 .erl 文件可能是什么样子的结论,例如哪些函数是导出的。但许多其他重要的信息,比如变量名,就不存在了。通常来说,在没有抽象代码的情况下从 .beam 文件重建源代码是不切实际的。