Hi,
I am sorry to have missed the "single" feature and I see the issue with
declaring temp$ as a record type. But as mentioned before, only logical
operators need this and as of now, I don't see the need of comparing record
types in begin expressions. Please tell me if I am missing something.
Regards,
Atishay
On Fri, Mar 25, 2016 at 11:26 AM, ATISHAY JAIN <
[email protected]> wrote:
> Hi,
>
> I tried the manual conversion and it seems to be pretty simple as of now.
> Also, as far I understood chapel, record types can be assigned without any
> issues, however, operations are not available on record types so that
> should not be an issue. I didn't get why temp$ can't be declared as a
> record variable, because none of the binary operations except logical ones
> need to be supported.
>
> Also, I looked into the futures implementation and we could possibly use a
> similar approach with an implicit barrier at the end. The project states
> that runtime libraries can be implemented as a bonus result and I believe
> that this is an achievable target.
>
> I am preparing a proposal right now and would like to get it reviewed
> before submission. Till when can I send that to you before the deadline?
>
> Thanks
>
> On Tue, Mar 22, 2016 at 9:20 AM, Vassily Litvinov <[email protected]> wrote:
>
>> Hi Atishay Jain,
>>
>> To try out the project, implement begin expressions "by hand", i.e. by
>> manually converting a Chapel program with begin expressions to one that
>> compiles and executes today.
>>
>> For example, you would convert a statement containing:
>>
>> ... begin f(args) ...
>>
>> to several statements like this:
>>
>> var temp$: single int; // or whatever f() return type is
>> begin temp$ = f(args);
>> ... temp$ ...
>>
>> Write a simple program with begin expressions or use example(s)
>> mentioned below, and apply such conversion to them.
>>
>> As the next step, support the case where f() return type is a record R,
>> so you cannot declare temp$ to be a "single" variable.
>> Instead, develop a scheme like in the overview email below,
>> except without using lambdas.
>>
>>
>> Here are some resources.
>>
>> * There is an earlier implementation of begin expressions, a.k.a.
>> "futures".
>> Some of its valuable pieces are an overview email:
>>
>> https://sourceforge.net/p/chapel/mailman/message/30815892/
>>
>> and examples, esp. hello-world.chpl, fib.chpl, smith-waterman.chpl -
>> here:
>>
>>
>> https://github.com/chapel-lang/chapel-attic/tree/eec5ad5/test/release/examples/futures
>>
>> Beware that these examples are no longer available via the link provided
>> in the above email message.
>>
>> * "Futures" in C11 - background - we probably take a different approach -
>> e.g.:
>>
>>
>> https://code.facebook.com/posts/1661982097368498/futures-for-c-11-at-facebook/
>>
>>
>> Be sure to let me know if you have questions.
>>
>> Vassily
>>
>>
>>
>> On 03/21/16 04:03, ATISHAY JAIN wrote:
>>
>>> Hi,
>>>
>>> I am Atishay Jain, a Junior year Computer Science student from Birla
>>> Institute of Technology & Science, Pilani. I would like to contribute to
>>> Chapel as a part of GSoC 2016.
>>>
>>> I am interested in 'Begin expressions' project. I have studied compilers
>>> and implemented up to semantic analyzers in my studies. I am also doing a
>>> course on 'Parallel Computing' and have programmed using OpenMP and MPI.
>>> It
>>> would be helpful if someone could tell me the steps to get started.
>>> Since,
>>> there is little time left for the formal application, I plan to start
>>> drafting it within a day.
>>>
>>> Thank You
>>>
>>> Regards,
>>> Atishay Jain
>>>
>>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
