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...>                   -> Args... (Ready fixed-range)
>   - hpx::future<Tuple<Args...>>      -> Args... (Waitable fixed-range futures)
>     > Where Tuple is an object that is unwrappable through a sequenced call
>     > of std::get<I>(tuple)..., which includes `std::pair`, `std::tuple`,
>     > `hpx::tuple` and potentially `std::array`.
>   - Container<hpx::future<Arg>>      -> Container<Arg>
>     > 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
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Reply via email to