Charm++ parallel programming system

[Gengbin Zheng <gzheng AT illinois.edu>]

Hi Evghenii,

  You can write multiple ci files.  One of them needs to be a
mainmodule, and then you use "extern module M"  to link them together.

Gengbin

On Fri, Aug 17, 2012 at 6:36 AM, Evghenii Gaburov 
<egaburov AT dds.nl>
 wrote:
> 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
>> *************************************
>
>
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm
> _______________________________________________
> ppl mailing list
> ppl AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/ppl