Horus 0.2.0

At this point, Horus should be considered Alpha and not production ready. The API will likely evolve and future releases will likely introduce breaking changes. The goal of this release is to make it easy for anyone to try it and possibly give feedback.

What's new in Horus 0.2.0

This release focuses on several new features.

Meaningful stacktraces

When the extracted standalone function throws an exception, the stacktrace points to the generated module by default. The file names and line numbers were already correct w.r.t. to the source code. However, the module and function names were the one from the generated module which don't make any sense for the reader. Horus 0.2.0 now reconstructs a meaningful stacktrace: it now looks like the exception comes from the correct function in the correct source file.

Let's take the following module to compare the regular stacktrace and the one after we extract and execute the failing function with Horus:

-module(readme).

-export([trigger_badmatch/0,
         try_with_horus/0]).

trigger_badmatch() ->
    1 = 2.

try_with_horus() ->
    Fun = fun() ->
                  trigger_badmatch()
          end,

    StandaloneFun = horus:to_standalone_fun(Fun),

    horus:exec(StandaloneFun, []).

If we execute readme:trigger_badmatch() directly, the shell shows:

** exception error: no match of right hand side value 2
     in function  readme:trigger_badmatch/0 (.../readme.erl, line 7)

With Horus 0.1.0, we would get the following exception and cryptic stacktrace:

** exception error: no match of right hand side value 2
     in function  'horus__readme__-try_with_horus/0-fun-0-__81480719':readme__trigger_badmatch/0 (.../readme.erl, line 7)

With Horus 0.2.0, we get the correct stacktrace:

** exception error: no match of right hand side value 2
     in function  readme:trigger_badmatch/0 (.../readme.erl, line 7)
     in call from horus:exec/2 (.../horus/src/horus.erl, line 1019)

See #2 and #5.

Support cover-compiled modules

Horus used to always get the Beam code from the code server. The returned code corresponds to the Beam file on disk.

However, when a module is compiled by cover as part of a testsuite for instance, cover stores the modified module in an ETS table. The modified module is instrumented with calls to cover to emit the execution counts.

To keep the emission of execution counts, Horus now takes the Beam code from that ETS table if the module is cover-compiled (i.e. cover:is_compiled/1 returns true). Thanks to this, an executed standalone function from a cover-compiled module will still record that the original source code is executed.

See #3 and #4.

Other changes

• Added support for the maybe ... end expression, introduced in Erlang 25 as an opt-in feature (#6, #7).

Download

Horus 0.2.0 is available from Hex.pm: https://hex.pm/packages/horus/0.2.0

Upgrade

Using Rebar:

1. Update your rebar.config:

   %% In rebar.config
   {deps, [{horus, "0.2.0"}]}.

2. Run rebar3 upgrade horus.

Using Erlang.mk:

1. Update your Makefile:

   %% In your Makefile
   dep_horus = hex 0.2.0

2. Remove the deps/horus directory. The new version will be fetched the next time you build your project.

Documentation

The documentation for Horus 0.2.0 is available on Hex.pm.