Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Denis Blank 
Hi Zahra,

I'm glad that you like my GitHub projects.

The proposal of "Applying Machine Learning Techniques on HPX Parallel 
Algorithms"
seems like to be an interesting project.

However I think, that my knowledge in Machine Learning isn't good enough yet,
for selecting the proposal as a potential GSoC project,
although I'm experienced in using LLVM and LibClang.

Best regards
Denis



From: Zahra Khatami 
Sent: 30 March 2017 17:56
To: denis.bl...@outlook.com
Cc: hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] [GSoC 2017] Proposal for re-implementing 
hpx::util::unwrapped

Hi Denis,

I am so glad that you are interested in HPX GSOC.
I have looked at your github and your projects seems so interesting for me. 
Feel free to write your proposal and submit it before April 3rd. I would be 
happy to be your mentor, as I have found your background match with my current 
projects as well. If you go through

https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2017-Project-Ideas#re-implement-hpxutilunwrapped


You will find a project "Applying machine learning techniques on HPX 
algorithms", which I think it could be a good fit for you too. Our team has 
been working on it since 2-3 months ago and so far we have got interesting 
results, which are going to be prepared for a conference paper. In this project 
we are using LLVM and Clang LibTooling to implement a machine learning 
techniques on an HPX parallel algorithm, and we have applied and tested them on 
an hpx loop.
So as another option, you could look at this GSOC project idea and write a 
brief proposal about how you can implement it.

Best Regards,

Zahra Khatami | PhD Student
Center for Computation & Technology (CCT)
School of Electrical Engineering & Computer Science
Louisiana State University
2027 Digital Media Center (DMC)
Baton Rouge, LA 70803


On Thu, Mar 30, 2017 at 10:55 AM, Patrick Diehl 
mailto:patrickdie...@gmail.com>> wrote:
Hi Denis,

the ides sounds good, for GSoC, you should submit your proposal at their
official website. You can use this template [0] and our guidelines [1]
to prepare your proposal.  The deadline for the submission is

> April 3 16:00 UTC Student application deadline

We are looking forward to review your proposal.

Best,

Patrick

[0] https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template

[1] https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-Successful-Proposals

On 30/03/17 11:29 AM, Denis Blank wrote:
> Hello HPX Developers,
>
> I'm Denis, an Informatics Student at the Technical University of Munich, 
> Germany.
>
> In the summer semester, I'm transitioning to my master's program and
> thus I will finally have enough time to have a chance on participating at 
> GSoC.
>
> I'm very keen on Open-Source because you always learn something new about 
> various topics
> not covered in studies, and you get connected to other developers around the 
> world.
>
> Thus I'm highly active on GitHub (https://github.com/Naios), also, I recently 
> started
> to attend various conferences such as the MeetingC++ or EuroLLVM.
>
> In my spare time, I'm working on side projects very related to the field HPX 
> is covering,
> like a library for compile-time known continuation chaining - continuable [0].
>
> I'm also a member of the TrinityCore [1] Open-Source project where I'm 
> contributing
> for 6 years now (beside of other projects like fmtlib or ANTLR).
>
> HPX is very attractive for me as a potential GSoC project,
> because of its high-quality codebase as well as its impact on
> the today's important infrastructure for parallel computing.
>
> During my work on previous side projects and contributions, I gathered
> significant knowledge in C++ template meta-programming as well as designing 
> good API's.
> My bachelor's thesis was also about improving meta-programming in static 
> languages.
>
> Thus I want to work on improving the API of HPX especially the 
> `hpx::util::unwrapped` function.
> While browsing the issue tracker I spotted other related issues,
> not mentioned in the existing proposal, such as the requirement
> of a unified waiter API for arbitrary objects (#1132 [2]).
>
> My plans for a potential GSoC stipend embrace a complete rewrite of the
> `hpx::util::unwrapped` function, in order to use a new designed waiter
> and unwrapping internal API which picks up the ideas mentioned in #1132,
> to fully support the requirements of issue #1404, #1400 and #1126.
> The API should also replace the existing internal solutions of:
>
>   - `dataflow`
>   - `wait_all`
>   - `when_all`
>
> in order to remove a lot of duplicated code (`when_all_frame` and 
> `wait_all_frame`),
> as well as to make the API consistent acros

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread #SESHADRI MADHAVAN# 
Hi Zahra,

I have proposed the idea for working on HPXCL with Patrick, hence I shall not 
be proposing this as my GSoC project, but I would love to jump into "Applying 
machine learning techniques on HPX algorithms". The project seems interesting 
and I have had some background implementing Machine Learning algorithms on 
Hadoop, predominantly in Java. But I have been through the process of designing 
and optimizing algorithms for execution in parallel which I believe will be 
useful for this. Let me know how I can get started.

Best Regards,
Madhavan

From: hpx-users-boun...@stellar.cct.lsu.edu 
[mailto:hpx-users-boun...@stellar.cct.lsu.edu] On Behalf Of Zahra Khatami
Sent: Thursday, March 30, 2017 11:56 PM
To: denis.bl...@outlook.com
Cc: hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] [GSoC 2017] Proposal for re-implementing 
hpx::util::unwrapped

Hi Denis,

I am so glad that you are interested in HPX GSOC.
I have looked at your github and your projects seems so interesting for me. 
Feel free to write your proposal and submit it before April 3rd. I would be 
happy to be your mentor, as I have found your background match with my current 
projects as well. If you go through

https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2017-Project-Ideas#re-implement-hpxutilunwrapped

You will find a project "Applying machine learning techniques on HPX 
algorithms", which I think it could be a good fit for you too. Our team has 
been working on it since 2-3 months ago and so far we have got interesting 
results, which are going to be prepared for a conference paper. In this project 
we are using LLVM and Clang LibTooling to implement a machine learning 
techniques on an HPX parallel algorithm, and we have applied and tested them on 
an hpx loop.
So as another option, you could look at this GSOC project idea and write a 
brief proposal about how you can implement it.

Best Regards,

Zahra Khatami | PhD Student
Center for Computation & Technology (CCT)
School of Electrical Engineering & Computer Science
Louisiana State University
2027 Digital Media Center (DMC)
Baton Rouge, LA 70803


On Thu, Mar 30, 2017 at 10:55 AM, Patrick Diehl 
mailto:patrickdie...@gmail.com>> wrote:
Hi Denis,

the ides sounds good, for GSoC, you should submit your proposal at their
official website. You can use this template [0] and our guidelines [1]
to prepare your proposal.  The deadline for the submission is

> April 3 16:00 UTC Student application deadline

We are looking forward to review your proposal.

Best,

Patrick

[0] https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template

[1] https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-Successful-Proposals

On 30/03/17 11:29 AM, Denis Blank wrote:
> Hello HPX Developers,
>
> I'm Denis, an Informatics Student at the Technical University of Munich, 
> Germany.
>
> In the summer semester, I'm transitioning to my master's program and
> thus I will finally have enough time to have a chance on participating at 
> GSoC.
>
> I'm very keen on Open-Source because you always learn something new about 
> various topics
> not covered in studies, and you get connected to other developers around the 
> world.
>
> Thus I'm highly active on GitHub (https://github.com/Naios), also, I recently 
> started
> to attend various conferences such as the MeetingC++ or EuroLLVM.
>
> In my spare time, I'm working on side projects very related to the field HPX 
> is covering,
> like a library for compile-time known continuation chaining - continuable [0].
>
> I'm also a member of the TrinityCore [1] Open-Source project where I'm 
> contributing
> for 6 years now (beside of other projects like fmtlib or ANTLR).
>
> HPX is very attractive for me as a potential GSoC project,
> because of its high-quality codebase as well as its impact on
> the today's important infrastructure for parallel computing.
>
> During my work on previous side projects and contributions, I gathered
> significant knowledge in C++ template meta-programming as well as designing 
> good API's.
> My bachelor's thesis was also about improving meta-programming in static 
> languages.
>
> Thus I want to work on improving the API of HPX especially the 
> `hpx::util::unwrapped` function.
> While browsing the issue tracker I spotted other related issues,
> not mentioned in the existing proposal, such as the requirement
> of a unified waiter API for arbitrary objects (#1132 [2]).
>
> My plans for a potential GSoC stipend embrace a complete rewrite of the
> `hpx::util::unwrapped` function, in order to use a new designed waiter
> and unwrapping internal API which picks up the ideas mentioned in #1132,
> to fully support the requirements of issue #1404, #1400 and #1126.
> The API should also replace the existing inter

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Patrick Diehl 
And in addition, you could join our irc channel #ste||ar at freenode to
discuss with the community about your ideas.

Best,

Patrick

On 30/03/17 11:54 AM, zahra khatami wrote:
> Hi Denis,
>
> I am so glad that you are interested in HPX GSOC. 
> I have looked at your github and your projects seems
> so interesting for me. Feel free to write your proposal and submit it
> before April 3rd. I would be happy to be your mentor, as I have found
> your background match with my current projects as well. If you go through 
>
> https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2017-Project-Ideas#re-implement-hpxutilunwrapped
>
> You will find a project "Applying machine learning techniques on HPX
> algorithms", which I think it could be a good fit for you too. Our
> team has been working on it since 2-3 months ago and so far we have
> got interesting results, which are going to be prepared for a
> conference paper. In this project we are using LLVM and Clang
> LibTooling to implement a machine learning techniques on an HPX
> parallel algorithm, and we have applied and tested them on an hpx loop. 
> So as another option, you could look at this GSOC project idea and
> write a brief proposal about how you can implement it. 
>
>
>
> Best Regards,*
>
> Zahra Khatami* | PhD Student
> Center for Computation & Technology (CCT)
> School of Electrical Engineering & Computer Science
> Louisiana State University
> 2027 Digital Media Center (DMC)
> Baton Rouge, LA 70803
>
>
> On Thu, Mar 30, 2017 at 10:29 AM, Denis Blank  > wrote:
>
> Hello HPX Developers,
>
> I'm Denis, an Informatics Student at the Technical University of
> Munich, Germany.
>
> In the summer semester, I'm transitioning to my master's program and
> thus I will finally have enough time to have a chance on
> participating at GSoC.
>
> I'm very keen on Open-Source because you always learn something
> new about various topics
> not covered in studies, and you get connected to other developers
> around the world.
>
> Thus I'm highly active on GitHub (https://github.com/Naios), also,
> I recently started
> to attend various conferences such as the MeetingC++ or EuroLLVM.
>
> In my spare time, I'm working on side projects very related to the
> field HPX is covering,
> like a library for compile-time known continuation chaining -
> continuable [0].
>
> I'm also a member of the TrinityCore [1] Open-Source project where
> I'm contributing
> for 6 years now (beside of other projects like fmtlib or ANTLR).
>
> HPX is very attractive for me as a potential GSoC project,
> because of its high-quality codebase as well as its impact on
> the today's important infrastructure for parallel computing.
>
> During my work on previous side projects and contributions, I gathered
> significant knowledge in C++ template meta-programming as well as
> designing good API's.
> My bachelor's thesis was also about improving meta-programming in
> static languages.
>
> Thus I want to work on improving the API of HPX especially the
> `hpx::util::unwrapped` function.
> While browsing the issue tracker I spotted other related issues,
> not mentioned in the existing proposal, such as the requirement
> of a unified waiter API for arbitrary objects (#1132 [2]).
>
> My plans for a potential GSoC stipend embrace a complete rewrite
> of the
> `hpx::util::unwrapped` function, in order to use a new designed waiter
> and unwrapping internal API which picks up the ideas mentioned in
> #1132,
> to fully support the requirements of issue #1404, #1400 and #1126.
> The API should also replace the existing internal solutions of:
>
>   - `dataflow`
>   - `wait_all`
>   - `when_all`
>
> in order to remove a lot of duplicated code (`when_all_frame` and
> `wait_all_frame`),
> as well as to make the API consistent across these functions.
> Also we could make the following mapping for the following
> parameter types available
> to all functions I mentioned above:
>
>   - Args...  -> Args... (Ready types)
>   - Tuple   -> Args... (Ready fixed-range)
>   - hpx::future>  -> Args... (Waitable
> fixed-range futures)
> > Where Tuple is an object that is unwrappable through a
> sequenced call
> > of std::get(tuple)..., which includes `std::pair`,
> `std::tuple`,
> > `hpx::tuple` and potentially `std::array`.
>   - Container>  -> Container
> > Where Container is an object satisfying the range requirements
> > (`begin()` and `end()`), which makes it possible to use
> > any arbitrary standard or user-given container.
>
> The new internal API could use function overloading instead of
> heavy SFINAE,
> so we can also slightly improve the build performance there
> (issued i

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread zahra khatami 
Hi Denis,

I am so glad that you are interested in HPX GSOC.
I have looked at your github and your projects seems so interesting for me.
Feel free to write your proposal and submit it before April 3rd. I would be
happy to be your mentor, as I have found your background match with my
current projects as well. If you go through

https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2017-Project-Ideas#re-implement-hpxutilunwrapped

You will find a project "Applying machine learning techniques on HPX
algorithms", which I think it could be a good fit for you too. Our team has
been working on it since 2-3 months ago and so far we have got interesting
results, which are going to be prepared for a conference paper. In this
project we are using LLVM and Clang LibTooling to implement a machine
learning techniques on an HPX parallel algorithm, and we have applied and
tested them on an hpx loop.
So as another option, you could look at this GSOC project idea and write a
brief proposal about how you can implement it.



Best Regards,

*Zahra Khatami* | PhD Student
Center for Computation & Technology (CCT)
School of Electrical Engineering & Computer Science
Louisiana State University
2027 Digital Media Center (DMC)
Baton Rouge, LA 70803


On Thu, Mar 30, 2017 at 10:29 AM, Denis Blank 
wrote:

> Hello HPX Developers,
>
> I'm Denis, an Informatics Student at the Technical University of Munich,
> Germany.
>
> In the summer semester, I'm transitioning to my master's program and
> thus I will finally have enough time to have a chance on participating at
> GSoC.
>
> I'm very keen on Open-Source because you always learn something new about
> various topics
> not covered in studies, and you get connected to other developers around
> the world.
>
> Thus I'm highly active on GitHub (https://github.com/Naios), also, I
> recently started
> to attend various conferences such as the MeetingC++ or EuroLLVM.
>
> In my spare time, I'm working on side projects very related to the field
> HPX is covering,
> like a library for compile-time known continuation chaining - continuable
> [0].
>
> I'm also a member of the TrinityCore [1] Open-Source project where I'm
> contributing
> for 6 years now (beside of other projects like fmtlib or ANTLR).
>
> HPX is very attractive for me as a potential GSoC project,
> because of its high-quality codebase as well as its impact on
> the today's important infrastructure for parallel computing.
>
> During my work on previous side projects and contributions, I gathered
> significant knowledge in C++ template meta-programming as well as
> designing good API's.
> My bachelor's thesis was also about improving meta-programming in static
> languages.
>
> Thus I want to work on improving the API of HPX especially the
> `hpx::util::unwrapped` function.
> While browsing the issue tracker I spotted other related issues,
> not mentioned in the existing proposal, such as the requirement
> of a unified waiter API for arbitrary objects (#1132 [2]).
>
> My plans for a potential GSoC stipend embrace a complete rewrite of the
> `hpx::util::unwrapped` function, in order to use a new designed waiter
> and unwrapping internal API which picks up the ideas mentioned in #1132,
> to fully support the requirements of issue #1404, #1400 and #1126.
> The API should also replace the existing internal solutions of:
>
>   - `dataflow`
>   - `wait_all`
>   - `when_all`
>
> in order to remove a lot of duplicated code (`when_all_frame` and
> `wait_all_frame`),
> as well as to make the API consistent across these functions.
> Also we could make the following mapping for the following parameter types
> available
> to all functions I mentioned above:
>
>   - Args...  -> Args... (Ready types)
>   - Tuple   -> Args... (Ready fixed-range)
>   - hpx::future>  -> Args... (Waitable fixed-range
> futures)
> > Where Tuple is an object that is unwrappable through a sequenced call
> > of std::get(tuple)..., which includes `std::pair`, `std::tuple`,
> > `hpx::tuple` and potentially `std::array`.
>   - Container>  -> Container
> > Where Container is an object satisfying the range requirements
> > (`begin()` and `end()`), which makes it possible to use
> > any arbitrary standard or user-given container.
>
> The new internal API could use function overloading instead of heavy
> SFINAE,
> so we can also slightly improve the build performance there (issued in
> #950 [3]).
>
> Because of my current knowledge I'm sure to complete these features,
> as well as appropriate unit-tests, in 2 months.
> Also since I've implemented similar capabilities into my continuable
> library [4] before.
>
> For the remaining month, I plan to propose generic project improvements
> into the timeline.
>
> How do you think about the proposed changes?
>
> Are there any other similar defects or requirements related to
> template meta-programming, at which,
> I could possibly work for the planned remaining time?
>
> Kind

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Zahra Khatami 
Hi Denis,

I am so glad that you are interested in HPX GSOC.
I have looked at your github and your projects seems so interesting for me.
Feel free to write your proposal and submit it before April 3rd. I would be
happy to be your mentor, as I have found your background match with my
current projects as well. If you go through

https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2017-
Project-Ideas#re-implement-hpxutilunwrapped

You will find a project "Applying machine learning techniques on HPX
algorithms", which I think it could be a good fit for you too. Our team has
been working on it since 2-3 months ago and so far we have got interesting
results, which are going to be prepared for a conference paper. In this
project we are using LLVM and Clang LibTooling to implement a machine
learning techniques on an HPX parallel algorithm, and we have applied and
tested them on an hpx loop.
So as another option, you could look at this GSOC project idea and write a
brief proposal about how you can implement it.

Best Regards,

*Zahra Khatami* | PhD Student
Center for Computation & Technology (CCT)
School of Electrical Engineering & Computer Science
Louisiana State University
2027 Digital Media Center (DMC)
Baton Rouge, LA 70803


On Thu, Mar 30, 2017 at 10:55 AM, Patrick Diehl 
wrote:

> Hi Denis,
>
> the ides sounds good, for GSoC, you should submit your proposal at their
> official website. You can use this template [0] and our guidelines [1]
> to prepare your proposal.  The deadline for the submission is
>
> > April 3 16:00 UTC Student application deadline
>
> We are looking forward to review your proposal.
>
> Best,
>
> Patrick
>
> [0] https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template
>
> [1] https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-
> Successful-Proposals
>
> On 30/03/17 11:29 AM, Denis Blank wrote:
> > Hello HPX Developers,
> >
> > I'm Denis, an Informatics Student at the Technical University of Munich,
> Germany.
> >
> > In the summer semester, I'm transitioning to my master's program and
> > thus I will finally have enough time to have a chance on participating
> at GSoC.
> >
> > I'm very keen on Open-Source because you always learn something new
> about various topics
> > not covered in studies, and you get connected to other developers around
> the world.
> >
> > Thus I'm highly active on GitHub (https://github.com/Naios), also, I
> recently started
> > to attend various conferences such as the MeetingC++ or EuroLLVM.
> >
> > In my spare time, I'm working on side projects very related to the field
> HPX is covering,
> > like a library for compile-time known continuation chaining -
> continuable [0].
> >
> > I'm also a member of the TrinityCore [1] Open-Source project where I'm
> contributing
> > for 6 years now (beside of other projects like fmtlib or ANTLR).
> >
> > HPX is very attractive for me as a potential GSoC project,
> > because of its high-quality codebase as well as its impact on
> > the today's important infrastructure for parallel computing.
> >
> > During my work on previous side projects and contributions, I gathered
> > significant knowledge in C++ template meta-programming as well as
> designing good API's.
> > My bachelor's thesis was also about improving meta-programming in static
> languages.
> >
> > Thus I want to work on improving the API of HPX especially the
> `hpx::util::unwrapped` function.
> > While browsing the issue tracker I spotted other related issues,
> > not mentioned in the existing proposal, such as the requirement
> > of a unified waiter API for arbitrary objects (#1132 [2]).
> >
> > My plans for a potential GSoC stipend embrace a complete rewrite of the
> > `hpx::util::unwrapped` function, in order to use a new designed waiter
> > and unwrapping internal API which picks up the ideas mentioned in #1132,
> > to fully support the requirements of issue #1404, #1400 and #1126.
> > The API should also replace the existing internal solutions of:
> >
> >   - `dataflow`
> >   - `wait_all`
> >   - `when_all`
> >
> > in order to remove a lot of duplicated code (`when_all_frame` and
> `wait_all_frame`),
> > as well as to make the API consistent across these functions.
> > Also we could make the following mapping for the following parameter
> types available
> > to all functions I mentioned above:
> >
> >   - Args...  -> Args... (Ready types)
> >   - Tuple   -> Args... (Ready fixed-range)
> >   - hpx::future>  -> Args... (Waitable fixed-range
> futures)
> > > Where Tuple is an object that is unwrappable through a sequenced
> call
> > > of std::get(tuple)..., which includes `std::pair`, `std::tuple`,
> > > `hpx::tuple` and potentially `std::array`.
> >   - Container>  -> Container
> > > Where Container is an object satisfying the range requirements
> > > (`begin()` and `end()`), which makes it possible to use
> > > any arbitrary standard or user-given container.
> >
> > The new internal AP

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Patrick Diehl 


On 30/03/17 11:55 AM, Patrick Diehl wrote:
> Hi Denis,
>
> the ides sounds good, for GSoC, you should submit your proposal at their
> official website. You can use this template [0] and our guidelines [1]
> to prepare your proposal.  The deadline for the submission is
>
>> April 3 16:00 UTC Student application deadline
> We are looking forward to review your proposal.
>
> Best,
>
> Patrick
>
> [0] https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template
>
> [1] https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-Successful-Proposals
>
> On 30/03/17 11:29 AM, Denis Blank wrote:
>> Hello HPX Developers,
>>
>> I'm Denis, an Informatics Student at the Technical University of Munich, 
>> Germany.
>>
>> In the summer semester, I'm transitioning to my master's program and
>> thus I will finally have enough time to have a chance on participating at 
>> GSoC.
>>
>> I'm very keen on Open-Source because you always learn something new about 
>> various topics
>> not covered in studies, and you get connected to other developers around the 
>> world.
>>
>> Thus I'm highly active on GitHub (https://github.com/Naios), also, I 
>> recently started
>> to attend various conferences such as the MeetingC++ or EuroLLVM.
>>
>> In my spare time, I'm working on side projects very related to the field HPX 
>> is covering,
>> like a library for compile-time known continuation chaining - continuable 
>> [0].
>>
>> I'm also a member of the TrinityCore [1] Open-Source project where I'm 
>> contributing
>> for 6 years now (beside of other projects like fmtlib or ANTLR).
>>
>> HPX is very attractive for me as a potential GSoC project,
>> because of its high-quality codebase as well as its impact on
>> the today's important infrastructure for parallel computing.
>>
>> During my work on previous side projects and contributions, I gathered
>> significant knowledge in C++ template meta-programming as well as designing 
>> good API's.
>> My bachelor's thesis was also about improving meta-programming in static 
>> languages.
>>
>> Thus I want to work on improving the API of HPX especially the 
>> `hpx::util::unwrapped` function.
>> While browsing the issue tracker I spotted other related issues,
>> not mentioned in the existing proposal, such as the requirement
>> of a unified waiter API for arbitrary objects (#1132 [2]).
>>
>> My plans for a potential GSoC stipend embrace a complete rewrite of the
>> `hpx::util::unwrapped` function, in order to use a new designed waiter
>> and unwrapping internal API which picks up the ideas mentioned in #1132,
>> to fully support the requirements of issue #1404, #1400 and #1126.
>> The API should also replace the existing internal solutions of:
>>
>>   - `dataflow`
>>   - `wait_all`
>>   - `when_all`
>>
>> in order to remove a lot of duplicated code (`when_all_frame` and 
>> `wait_all_frame`),
>> as well as to make the API consistent across these functions.
>> Also we could make the following mapping for the following parameter types 
>> available
>> to all functions I mentioned above:
>>
>>   - Args...  -> Args... (Ready types)
>>   - Tuple   -> Args... (Ready fixed-range)
>>   - hpx::future>  -> Args... (Waitable fixed-range 
>> futures)
>> > Where Tuple is an object that is unwrappable through a sequenced call
>> > of std::get(tuple)..., which includes `std::pair`, `std::tuple`,
>> > `hpx::tuple` and potentially `std::array`.
>>   - Container>  -> Container
>> > Where Container is an object satisfying the range requirements
>> > (`begin()` and `end()`), which makes it possible to use
>> > any arbitrary standard or user-given container.
>>
>> The new internal API could use function overloading instead of heavy SFINAE,
>> so we can also slightly improve the build performance there (issued in #950 
>> [3]).
>>
>> Because of my current knowledge I'm sure to complete these features,
>> as well as appropriate unit-tests, in 2 months.
>> Also since I've implemented similar capabilities into my continuable library 
>> [4] before.
>>
>> For the remaining month, I plan to propose generic project improvements into 
>> the timeline.
>>
>> How do you think about the proposed changes?
>>
>> Are there any other similar defects or requirements related to
>> template meta-programming, at which,
>> I could possibly work for the planned remaining time?
>>
>> Kind regards
>> Denis
>>
>> - [0] https://github.com/Naios/continuable
>> - [1] https://github.com/TrinityCore/TrinityCore
>> - [2] https://github.com/STEllAR-GROUP/hpx/issues/1132
>> - [3] https://github.com/STEllAR-GROUP/hpx/issues/950
>> - [4] 
>> https://github.com/Naios/continuable/blob/6d9680905acc8a7ba3812eddf02f2d69f3172e3f/include/continuable/continuable-base.hpp#L856
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

___

Re: [hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Patrick Diehl 
Hi Denis,

the ides sounds good, for GSoC, you should submit your proposal at their
official website. You can use this template [0] and our guidelines [1]
to prepare your proposal.  The deadline for the submission is

> April 3 16:00 UTC Student application deadline

We are looking forward to review your proposal.

Best,

Patrick

[0] https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template

[1] https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-Successful-Proposals

On 30/03/17 11:29 AM, Denis Blank wrote:
> Hello HPX Developers,
>
> I'm Denis, an Informatics Student at the Technical University of Munich, 
> Germany.
>
> In the summer semester, I'm transitioning to my master's program and
> thus I will finally have enough time to have a chance on participating at 
> GSoC.
>
> I'm very keen on Open-Source because you always learn something new about 
> various topics
> not covered in studies, and you get connected to other developers around the 
> world.
>
> Thus I'm highly active on GitHub (https://github.com/Naios), also, I recently 
> started
> to attend various conferences such as the MeetingC++ or EuroLLVM.
>
> In my spare time, I'm working on side projects very related to the field HPX 
> is covering,
> like a library for compile-time known continuation chaining - continuable [0].
>
> I'm also a member of the TrinityCore [1] Open-Source project where I'm 
> contributing
> for 6 years now (beside of other projects like fmtlib or ANTLR).
>
> HPX is very attractive for me as a potential GSoC project,
> because of its high-quality codebase as well as its impact on
> the today's important infrastructure for parallel computing.
>
> During my work on previous side projects and contributions, I gathered
> significant knowledge in C++ template meta-programming as well as designing 
> good API's.
> My bachelor's thesis was also about improving meta-programming in static 
> languages.
>
> Thus I want to work on improving the API of HPX especially the 
> `hpx::util::unwrapped` function.
> While browsing the issue tracker I spotted other related issues,
> not mentioned in the existing proposal, such as the requirement
> of a unified waiter API for arbitrary objects (#1132 [2]).
>
> My plans for a potential GSoC stipend embrace a complete rewrite of the
> `hpx::util::unwrapped` function, in order to use a new designed waiter
> and unwrapping internal API which picks up the ideas mentioned in #1132,
> to fully support the requirements of issue #1404, #1400 and #1126.
> The API should also replace the existing internal solutions of:
>
>   - `dataflow`
>   - `wait_all`
>   - `when_all`
>
> in order to remove a lot of duplicated code (`when_all_frame` and 
> `wait_all_frame`),
> as well as to make the API consistent across these functions.
> Also we could make the following mapping for the following parameter types 
> available
> to all functions I mentioned above:
>
>   - Args...  -> Args... (Ready types)
>   - Tuple   -> Args... (Ready fixed-range)
>   - hpx::future>  -> Args... (Waitable fixed-range futures)
> > Where Tuple is an object that is unwrappable through a sequenced call
> > of std::get(tuple)..., which includes `std::pair`, `std::tuple`,
> > `hpx::tuple` and potentially `std::array`.
>   - Container>  -> Container
> > Where Container is an object satisfying the range requirements
> > (`begin()` and `end()`), which makes it possible to use
> > any arbitrary standard or user-given container.
>
> The new internal API could use function overloading instead of heavy SFINAE,
> so we can also slightly improve the build performance there (issued in #950 
> [3]).
>
> Because of my current knowledge I'm sure to complete these features,
> as well as appropriate unit-tests, in 2 months.
> Also since I've implemented similar capabilities into my continuable library 
> [4] before.
>
> For the remaining month, I plan to propose generic project improvements into 
> the timeline.
>
> How do you think about the proposed changes?
>
> Are there any other similar defects or requirements related to
> template meta-programming, at which,
> I could possibly work for the planned remaining time?
>
> Kind regards
> Denis
>
> - [0] https://github.com/Naios/continuable
> - [1] https://github.com/TrinityCore/TrinityCore
> - [2] https://github.com/STEllAR-GROUP/hpx/issues/1132
> - [3] https://github.com/STEllAR-GROUP/hpx/issues/950
> - [4] 
> https://github.com/Naios/continuable/blob/6d9680905acc8a7ba3812eddf02f2d69f3172e3f/include/continuable/continuable-base.hpp#L856
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

[hpx-users] [GSoC 2017] Proposal for re-implementing hpx::util::unwrapped

2017-03-30 Thread Denis Blank 
Hello HPX Developers,

I'm Denis, an Informatics Student at the Technical University of Munich, 
Germany.

In the summer semester, I'm transitioning to my master's program and
thus I will finally have enough time to have a chance on participating at GSoC.

I'm very keen on Open-Source because you always learn something new about 
various topics
not covered in studies, and you get connected to other developers around the 
world.

Thus I'm highly active on GitHub (https://github.com/Naios), also, I recently 
started
to attend various conferences such as the MeetingC++ or EuroLLVM.

In my spare time, I'm working on side projects very related to the field HPX is 
covering,
like a library for compile-time known continuation chaining - continuable [0].

I'm also a member of the TrinityCore [1] Open-Source project where I'm 
contributing
for 6 years now (beside of other projects like fmtlib or ANTLR).

HPX is very attractive for me as a potential GSoC project,
because of its high-quality codebase as well as its impact on
the today's important infrastructure for parallel computing.

During my work on previous side projects and contributions, I gathered
significant knowledge in C++ template meta-programming as well as designing 
good API's.
My bachelor's thesis was also about improving meta-programming in static 
languages.

Thus I want to work on improving the API of HPX especially the 
`hpx::util::unwrapped` function.
While browsing the issue tracker I spotted other related issues,
not mentioned in the existing proposal, such as the requirement
of a unified waiter API for arbitrary objects (#1132 [2]).

My plans for a potential GSoC stipend embrace a complete rewrite of the
`hpx::util::unwrapped` function, in order to use a new designed waiter
and unwrapping internal API which picks up the ideas mentioned in #1132,
to fully support the requirements of issue #1404, #1400 and #1126.
The API should also replace the existing internal solutions of:

  - `dataflow`
  - `wait_all`
  - `when_all`

in order to remove a lot of duplicated code (`when_all_frame` and 
`wait_all_frame`),
as well as to make the API consistent across these functions.
Also we could make the following mapping for the following parameter types 
available
to all functions I mentioned above:

  - Args...  -> Args... (Ready types)
  - Tuple   -> Args... (Ready fixed-range)
  - hpx::future>  -> Args... (Waitable fixed-range futures)
> Where Tuple is an object that is unwrappable through a sequenced call
> of std::get(tuple)..., which includes `std::pair`, `std::tuple`,
> `hpx::tuple` and potentially `std::array`.
  - Container>  -> Container
> Where Container is an object satisfying the range requirements
> (`begin()` and `end()`), which makes it possible to use
> any arbitrary standard or user-given container.

The new internal API could use function overloading instead of heavy SFINAE,
so we can also slightly improve the build performance there (issued in #950 
[3]).

Because of my current knowledge I'm sure to complete these features,
as well as appropriate unit-tests, in 2 months.
Also since I've implemented similar capabilities into my continuable library 
[4] before.

For the remaining month, I plan to propose generic project improvements into 
the timeline.

How do you think about the proposed changes?

Are there any other similar defects or requirements related to
template meta-programming, at which,
I could possibly work for the planned remaining time?

Kind regards
Denis

- [0] https://github.com/Naios/continuable
- [1] https://github.com/TrinityCore/TrinityCore
- [2] https://github.com/STEllAR-GROUP/hpx/issues/1132
- [3] https://github.com/STEllAR-GROUP/hpx/issues/950
- [4] 
https://github.com/Naios/continuable/blob/6d9680905acc8a7ba3812eddf02f2d69f3172e3f/include/continuable/continuable-base.hpp#L856
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users