[erlang-questions] Finding inconsistencies in record definitions and pretty printing records

Joe Armstrong erlang@REDACTED
Wed Oct 15 08:45:57 CEST 2008


On Wed, Oct 15, 2008 at 8:22 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi,
>
> On Tue, Oct 14, 2008 at 21:57, Joe Armstrong <erlang@REDACTED> wrote:
>> On Tue, Oct 14, 2008 at 6:16 PM, mats cronqvist
>>> "Joe Armstrong" <erlang@REDACTED> writes:
>>>>     - compile record definitions into the modules
>>>>       (uses a simple parse transform)
>>>
>>>  this is the problematic bit. as has been hashed several times on
>>>  this list, were record info exported (perhaps as a field in
>>>  module_info), all kinds of cool things could be accomplished.
>>
>> It's not problematic - the parse transform in the enclosed code does
>> exactly that.
>>
>> The enclosed code compiles record defs into the modules
>> concerned - sets up the servers, detects module inconsitencies at run
>> time and retrieves record definitions at run time *from any module*
>> (not just the definition module).
>
> This is cool!
>
> Am I right that the "any module" above should be "any module compiled
> with this parse_transform"? If yes, it restricts a little working with
> legacy code, but it's still cool :-)

Yes - you have to recompile the modules

  erlc  +'{parse_transform, jalib_records}' *.erl

The point to recognise is that you have to add an "on_load" trigger -
that puts the record definition
into a *global* store of some kind.

In fact It might be better to do this

ensure_loaded(Module) ->
    Self = self(),
    case whereis(code_server) of
         Self ->
            Error = "The code server called the unloaded module `" ++
                atom_to_list(Module) ++ "'",
            halt(Error);
        Pid when is_pid(Pid) ->
            Val = code:ensure_loaded(Module),
            (catch load_daemon ! {loaded, Module}),        %% <----
the nifty  bit
            Val;
        _ ->
            init:ensure_loaded(Module)
    end.

Then  if there is a registered load_daemon process it can do whatever
it likes, for example

      receive
           {loaded, Mod} ->
                  case  erlang:function_exported(Mod, auto_exec_bat, 0) of
                       true ->
                             spawn(fun() -> Mod:auto_exec_bat() end);
                       false ->
                             void
                   end ,
             ...

   Loading a module is so important that perhaps it deserves a
standard trigger !

/Joe







>
> regards,
> Vlad
>



More information about the erlang-questions mailing list