Charm++ parallel programming system

[Jonathan Lifflander <jliffl2 AT illinois.edu>]

Phil, you are correct about the bug, the closures need to be unraveled
at that point. I'm working on a fix and will push it soon.

Jonathan

On Wed, Dec 18, 2013 at 6:02 PM, Phil Miller 
<mille121 AT illinois.edu>
 wrote:
> I believe the issue described is that the closure in question should be
> 'opened' at the point where the forall bounds are being evaluated. Jonathan
> is probably best equipped to comment on this further. If it's as described,
> we'll open an issue and probably have it fixed shortly. Presumably, we can
> get this done before the 6.6 release.
>
>
> On Wed, Dec 18, 2013 at 7:04 PM, Kale, Laxmikant V 
> <kale AT illinois.edu>
> wrote:
>>
>> Joseph, I am posting this to the Charm++ mailing list (please post such
>> bug reports there in future). -- Sanjay
>>
>> ----------------------
>> Dear Professor Kale,
>>
>>     While working on my project, I noticed a neat little bug with the SDAG
>> 'forall' construct.
>>
>>     Let's say we want to execute a 'forall' inside a 'when' clause:
>>
>> when entryMethodA(int totalIterations) {
>>    forall [i] (1 : totalIterations, 1) {
>>        //do work here
>>    }
>> }
>>
>>     The variable 'totalIterations' should be in scope for the 'forall'
>> construct. But when we compile, the .def.h code gets a little bit wrong.
>> It'll throw an error like "totalIterations" not in scope.
>>
>> The offending line looks like: int __first = (1), __last =
>> (totalIterations), __stride = (1);
>> This is the 'forall''s iteration construct. It appears that there is
>> direct textual substitution from the SDAG code to the generated .def.h 
>> code.
>>
>> Yet, the closures (such as entryMethodA) are passed to this method as
>> parameters. Thus, the 'forall' generated code has access to the parameter
>> called totalIterations. Instead of "totalIterations", though, it would be
>> something like "gen0->getP0()"; (gen0 is the closure object representing 
>> the
>> "when entryMethodA" scope)
>>
>> Were 'forall's intended to have dynamic iteration? Given that it has
>> access to its parent closures' parameters, I think it is in the realm of
>> possibility.
>> ---
>> Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
>> Professor, Computer Science     
>> kale AT illinois.edu
>> 201 N. Goodwin Avenue           Ph:  (217) 244-0094
>> Urbana, IL  61801-2302          FAX: (217) 265-6582
>>
>>
>> _______________________________________________
>> 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
>>
>