[erlang-questions] code:get_object_code/1

Kostis Sagonas <>
Mon Nov 3 22:32:09 CET 2014


A user of PropEr (http://proper.softlab.ntua.gr/) reported that he was 
not able to use the erlang:timestamp() type as generator. (I.e. be able 
to generate random time stamp values using the existing mechanisms that 
PropEr provides.)

The culprit was traced to function code:get_object_code/1 which returns 
'error' for the 'erlang' module, instead of returning a tuple with its 
binary data object and beam filename, as one would expect.

   1> code:get_object_code(erlang).
   error

While for pretty much all other modules, one gets:

   2> code:get_object_code(kernel).
   {kernel,<<70,79,82,49,0,0,86,252,66,69,65,77,65,116,111,
             109,0,0,2,228,0,0,0,65,6,107,101,...>>,
           "/home/kostis/HiPE/otp/lib/kernel/ebin/kernel.beam"}
   3> code:get_object_code(beam_lib).
   {beam_lib,<<70,79,82,49,0,1,239,188,66,69,65,77,65,116,
               111,109,0,0,10,19,0,0,0,225,8,98,101,...>>,
             "/home/kostis/HiPE/otp/lib/stdlib/ebin/beam_lib.beam"}

Is there a reason for this discrepancy?

There is a variety of tools that needs to be able to manipulate the 
object code or extract information from the abstract code of modules, 
such as the list of their exported types, and there needs to be some 
(preferably simple) way of getting access to this information.


In investigating further the issue, I discovered that the problem can be 
fixed if one manually adds the erts/preloaded/erl dir in the code path. 
  But in my opinion, having to do this is unnecessarily complicated, 
possibly error prone and breaks the principle of least astonishment.

   4> code:add_path("/home/kostis/HiPE/otp/erts/preloaded/ebin").
   true
   5> code:get_object_code(erlang).
   {erlang,<<70,79,82,49,0,1,126,172,66,69,65,77,65,116,111,
             109,0,0,15,110,0,0,1,92,6,101,114,...>>,
           "/home/kostis/HiPE/otp/erts/preloaded/ebin/erlang.beam"}

So, I can ask my question differently: Can we please have the preloaded 
modules in the code path, since they arguably are there?

Kostis


More information about the erlang-questions mailing list