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
