[erlang-bugs] code:get_object_code/1
Kostis Sagonas
kostis@REDACTED
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-bugs
mailing list