This week's LFE Friday was translated with permission from the Erlang Thursday series by Steven Proctor. This week's translator: Robert Virding.

Today's slightly late1 LFE Friday continues to take a look at the c module with c:m/1.

c:m/1 takes an atom of a module name, and returns information about the module. It prints out information about the compilation date, time, and options; the object (BEAM) file that it was loaded from, and a list of functions exported by the module.

We'll start with taking a look at the string module in Erlang/LFE.

> (c:m 'string)
Module: string
MD5: 3b8eb035faf8214518977e6ad77eec52
Compiled: June 24 2015, 08:50
Object file: /usr/local/lib/erlang/lib/stdlib-2.5/ebin/string.beam
Compiler options:  [{outdir,"/Users/karolurbanski/build-dir_15-06-24_10-40-57/otp-support/lib/stdlib/src/../ebin"},
                    {i,"/Users/karolurbanski/build-dir_15-06-24_10-40-57/otp-support/lib/stdlib/src/../include"},
                    {i,"/Users/karolurbanski/build-dir_15-06-24_10-40-57/otp-support/lib/stdlib/src/../../kernel/include"},
                    warnings_as_errors,debug_info]
Exports: 
centre/2                      rstr/2
centre/3                      span/2
chars/3                       str/2
chars/2                       strip/1
chr/2                         strip/2
concat/2                      strip/3
copies/2                      sub_string/2
cspan/2                       sub_string/3
equal/2                       sub_word/2
join/2                        sub_word/3
left/2                        substr/2
left/3                        substr/3
len/1                         to_float/1
module_info/0                 to_integer/1
module_info/1                 to_lower/1
rchr/2                        to_upper/1
right/2                       tokens/2
right/3                       words/1
                              words/2
ok

We can see that this was compiled on my machine on June 24th of 2015, and had the warnings_as_errors and debug_info turned on, as well as the location of the beam file, and all of the different functions the string module exports.

Next, we will look at a module compiled from inside the shell.

> (c 'test_guard)
#(module test_guard)
> (c:m 'test_guard)
Module: test_guard
MD5: bda831a10e0d8653346d2eff87015ac9
Compiled: August 9 2015, 16:29
Object file: /Users/rv/lfe/lfe/test_guard.beam
Compiler options:  [from_core,no_bopt]
Exports: 
         module_info/0
         module_info/1
         seq/3
ok

(c:m 'test_guard) shows that it was compiled, and was loaded from my lfe/lfe directory, and exports seq/3 along with the two versions of module_info that every module exports. The module_info functions are automatically added by the compiler and these are where the actual information displayed by c:m/1 comes from.

> (test_guard:module_info)
(#(module test_guard)
 #(exports (#(seq 3) #(module_info 0) #(module_info 1)))
 #(attributes (#(vsn (336746549112612576229741835227603093049))))
 #(compile
   (#(options (from_core no_bopt))
    #(version "6.0")
    #(time #(2015 8 9 23 49 16))
    #(source "/Users/rv/lfe/lfe/tmp/test_guard.lfe")))
 #(native false)
 #(md5 #B(253 87 6 185 2 41 22 187 175 38 61 88 207 155 70 57)))

Again, this is one of those functions that you might not use everyday, but when it comes to debugging and inspecting your LFE application becomes a very useful function to know about.

This c function exists as an LFE repl built-in command which can be called from the repl with just (m 'strings)2.

-Proctor, Robert

  1. Trips and holidays take their toll.

  2. While the c:m/1 function and the m/1 LFE repl command now print their data in the same format the repl command will in the future prints its data using LFE formats.



Author

Published

10 August 2015

Category

tutorials

Tags