Linear Programming with Erlang

So you have to solve a linear program, so naturally the first language you think of is Erlang. Actually, it's not a natural first choice for most people, but if you are solving a linear program as part of an automatic control strategy for an internet facing application, the choice is better motivated.

Since I faced this situation recently I wrote a binding for GLPK for Erlang. Writing port drivers is a drag so I actually wrote a program to generate the C and Erlang for me. Perhaps with the new FFI these sort of games will not be necessary, but I was happy with the approach because I anticipate experimenting with several linear programming packages, which should be much easier to accommodate.

Available at Google code.

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},

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.