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...> -> 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
