Charm++ parallel programming system

[Gengbin Zheng <gzheng AT illinois.edu>]

I understand we can not split an array (by entry functions), but I
really doubt this is needed.
But instead of crowding the array declaration with SDAG entry
implementations, we probably should move the SDAG entry implementation
out of the array declaration, and be able to put it separately at end
of the ci file.

Gengbin

On Fri, Aug 17, 2012 at 1:25 PM, Gengbin Zheng 
<gzheng AT illinois.edu>
 wrote:
> yeah, you split a single module to multiple ci files, and use "extern 
> module".
> You do need to have unique module name for each ci file (which might
> be the inconvenient part)
>
> Gengbin
>
>
> On Fri, Aug 17, 2012 at 1:07 PM, Jim Phillips 
> <jim AT ks.uiuc.edu>
>  wrote:
>>
>> He wants to split a single module across multiple files.
>>
>> -Jim
>>
>> On Fri, 17 Aug 2012, Gengbin Zheng wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>>