Thursday, September 10, 2009

Removing warnings from ct_expand

I use ct_expand alot (can you tell?). The released version outputs warnings about unused variables, which are harmless, except ... that it conditioned me to ignore unused variable warnings from the compiler. Then the other day I had a real bug which the compiler was warning me about (via an unused variable) that took me quite a bit of time to find. Lesson learned: make sure that a correct compile is as quiet as possible, so problems stand out.

Ulf gave me some pointers on how to prevent ct_expand from emitting these warnings. Basically, ensure that the temporary variables created by ct_expand are prefixed with an underbar. Here's a patch:

--- src/ct_expand.erl 5 Jun 2009 21:07:32 -0000 1.1
+++ src/ct_expand.erl 10 Sep 2009 04:12:07 -0000
@@ -139,6 +139,9 @@
{Fname, Arity} = erl_syntax_lib:analyze_function(Form),
VarNames = erl_syntax_lib:new_variable_names(
Arity,
+ fun (N) ->
+ list_to_atom ("_V" ++ integer_to_list (N))
+ end,
erl_syntax_lib:variables(Form)),
{Form, [{function, Fname},
{arity, Arity},

Tuesday, September 8, 2009

Application Variables during Upgrade

A quick note related to my previous post: it turns out the application controller gives "old values" for application variables during the code upgrade process. Therefore the call to

element (2, application:get_key (drurly, modules))

returns the old list of modules, i.e., is missing new modules. ct_expand to the rescue! I get the list of modules at compile time from the application specification via

Modules =
ct_expand:term (
begin
{ ok, [ { application, drurly, PropList } ] } =
file:consult ("drurly.app"),
case proplists:get_value (modules, PropList) of
Y when is_list (Y) -> Y
end
end
),

For this to work, you must ensure the application specification is generated prior to compiling the module with this function in it.