Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

On Tue, Jul 31, 2012 at 11:16 AM, McCandless, Brian C.
<mccandless3 AT llnl.gov>
 wrote:
> 1.  The error message when there is a syntax error in the .ci file is not
> very helpful.   I get a line number and a message that says "syntax error",
> and that's it.  For example, I recently had the bug of typing
> "[reductionTarget]" instead of "[reductiontarget]" and the line number was
> no where near my mistake.  Is there a better way to find bugs like these?

This is something that we are well aware of (we write a lot of Charm++
code), and intend to fix. When there's dedicated effort toward it, we
plan to catalog various erroneous inputs and see what we can do to the
translator's grammar to get them reported cleanly. This is somewhat
difficult because we're just using yacc, but should be doable over the
next several months.

> 2.  The other sort of error is a C++ error in the SDAG coding.  Here I get
> the C++ error message, but the line number is at the <chareName>_SDAG_CODE
> macro.  Sometimes it's easy to figure these out from the context, but
> sometimes it's not.  What is normally an automatic process of jumping to the
> next compiler warning/error in my editor,  now requires a bit more mental
> energy to figure out.

This is partially addressed in the current development version, and
may be fully addressed in the development version fairly soon.

Basically, I've already implemented code to emit SDAG-generated
function definitions one-by-one in the foo.def.h file, with only their
declaration remaining inside that macro. Early reports on it so far
say that it makes this debugging much easier, including bugs
encountered at runtime and tackled with gdb, because you can actually
see the source listed there, too.

A new student in the lab, Ralf, is working on teaching the translator
to emit line number information from the original .ci file in those
function declarations. After this week, I'll have some spare cycles to
review what he's done and hopefully help wrap that up and integrate
it.

> What do Charm++ developers typically do to speed up the development cycle in
> these cases?

As you can hopefully get from the above: we fix it :-).

Thanks for writing, and I hope your explorations with Charm++ take you far.

Phil