Charm++ parallel programming system

[Evghenii Gaburov <egaburov AT dds.nl>]

Dear Phil,

On a similar topic:

One thing that is really missing is the ability to use multiple .ci files for 
a single module or an array.  Especially, with a heavy use of a structured 
dagger, the single .ci file because too cumbersome and big  to maintain. I 
was not also able to use "include "another_file.ci" inside a .ci file, was 
getting a syntax error. Ideally, it will be great to split a module or an 
array, especially structured dagger implementation, among multiple .ci files.

Is there a plan to support multiple .ci files in the near future, and if so, 
when do you think it  will be implemented.

Perhaps it is already in place, but I am just using it incorrectly..  Either 
way, this makes me keep bouncing between AMPI and Charm, while I would 
certainly prefer to use charm all the way..

Thanks!

Cheers,
  Evghenii

On Aug 15, 2012, at 7:00 PM, 
charm-request AT cs.uiuc.edu
 wrote:

> Send charm mailing list submissions to
>       
> charm AT cs.uiuc.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.cs.uiuc.edu/mailman/listinfo/charm
> or, via email, send a message with subject or body 'help' to
>       
> charm-request AT cs.uiuc.edu
> 
> You can reach the person managing the list at
>       
> charm-owner AT cs.uiuc.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of charm digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: [ppl]  Questions about developing in Charm++ (Phil Miller)
>   2. Re: [ppl]  Questions about developing in Charm++
>      (McCandless, Brian C.)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 14 Aug 2012 12:00:59 -0500
> From: Phil Miller 
> <mille121 AT illinois.edu>
> Subject: Re: [charm] [ppl]  Questions about developing in Charm++
> To: "McCandless, Brian C." 
> <mccandless3 AT llnl.gov>
> Cc: 
> "charm AT cs.illinois.edu"
>  
> <charm AT cs.illinois.edu>
> Message-ID:
>       
> <CAMDbWJGofKsKCqTump0bXUy0-8+2BLG=fcmgLoE6eAZOFH__6Q AT mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 14 Aug 2012 10:23:41 -0700
> From: "McCandless, Brian C." 
> <mccandless3 AT llnl.gov>
> Subject: Re: [charm] [ppl]  Questions about developing in Charm++
> To: Phil Miller 
> <mille121 AT illinois.edu>
> Cc: 
> "charm AT cs.illinois.edu"
>  
> <charm AT cs.illinois.edu>
> Message-ID: 
> <CC4FD6A3.8F9A%mccandless3 AT llnl.gov>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Thanks for the replies.
> The debugger issue was also a problem, so I'm glad that is being fixed as
> well.
> 
>  Brian
> 
> 
> On 8/14/12 10:00 AM, "Phil Miller" 
> <mille121 AT illinois.edu>
>  wrote:
> 
>> 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
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm
> 
> 
> End of charm Digest, Vol 58, Issue 10
> *************************************