08:17 <ste||ar-github> [hpx] msimberg pushed 1 new commit to master: https://github.com/STEllAR-GROUP/hpx/commit/411a9651e0a91e588790e4cb14241a5a15b49089

08:17 <ste||ar-github> hpx/master 411a965 Mikael Simberg: Merge pull request #3551 from STEllAR-GROUP/fix_3549...

09:04 <ste||ar-github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://github.com/STEllAR-GROUP/hpx/commit/64972e8c411383b39461a15baedbf57838a2e498

09:04 <ste||ar-github> hpx/gh-pages 64972e8 StellarBot: Updating Sphinx docs

13:38 <ste||ar-github> [hpx] msimberg deleted boost-signals2 at 89484c9: https://github.com/STEllAR-GROUP/hpx/commit/89484c9

13:58 <ste||ar-github> [hpx] K-ballo opened pull request #3557: Replace the last usages of boost::atomic (master...std-atomic) https://github.com/STEllAR-GROUP/hpx/pull/3557

14:39 <ste||ar-github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://github.com/STEllAR-GROUP/hpx/commit/426da92db75b9bfd3d93f2bd6827023ecf7037e7

14:39 <ste||ar-github> hpx/gh-pages 426da92 StellarBot: Updating Sphinx docs

15:05 <simbergm> jbjnr_: why don't you make a small test to see how the parallel for loop compares to a custom version with async/apply/latch/counting_semaphore or something like that?

15:06 <simbergm> and regarding launching more tasks to do a memcpy or similar, you only have n cores which can do n memcpy's at a time, so why launch (many) more tasks than that?

15:48 <jbjnr_> simbergm: you seem to be trying very hard from dissauding me from using the code I'm working on :) I would like to make simple test, but I need to work on my slides for Pavia, so shouldn't spend too much time on it. It's mostly to make the code look better rather than as a micro-optimization for performance. I don't like having to store a vector of futures that I don't really care about. I have an idea on using the apply with an

15:48 <jbjnr_> extra template param to call a function on completeion that would serve my purposes, but requires a bit of work. If I can't sleep tonight. I'll try it.

15:49 <simbergm> ok :) I'm just trying to make sure you don't end up reinventing the wheel

15:50 <simbergm> if performance isn't a big concern I'm still not sure why the parallel for loop doesn't work for you

16:39 <diehlpk_work> HPX was approved for fedora and should be there soon

16:39 <diehlpk_work> So one could do sudo dnf install hpx

16:39 <diehlpk_work> hpx-openmpi

16:39 <diehlpk_work> hx-mpich

16:40 <diehlpk_work> And people can play around with hpx on fedora 28/29

16:40 <diehlpk_work> And hpx-*-examples for the examples

16:40 <diehlpk_work> And hpx-devel for the headers and cmake stuff

16:41 <zao> Nice.

17:30 <dmarce1> Is calling hpx::new_ recursively within component constructors something that should work efficiently?

17:37 <hkaiser> dmarce1: I don't think that calling it recursively impacts performance in any way

18:43 <heller_> dmarce1: you just might not need the members to be components. Components do come at a cost

19:07 <ste||ar-github> [hpx] hkaiser created fixing_3550 (+1 new commit): https://github.com/STEllAR-GROUP/hpx/commit/bbe5308687cf

19:07 <ste||ar-github> hpx/fixing_3550 bbe5308 Hartmut Kaiser: Adding implicit constructor `exception(boost::system::error_code const&)`

19:08 <ste||ar-github> [hpx] hkaiser opened pull request #3558: Adding implicit constructor `exception(boost::system::error_code const&)` (master...fixing_3550) https://github.com/STEllAR-GROUP/hpx/pull/3558

19:26 <ste||ar-github> [hpx] hkaiser force-pushed fixing_3550 from bbe5308 to f5f8462: https://github.com/STEllAR-GROUP/hpx/commits/fixing_3550

19:26 <ste||ar-github> hpx/fixing_3550 f5f8462 Hartmut Kaiser: Adding implicit constructor `exception(boost::system::error_code const&)`

22:19 <maxwellr96> What does HPX_FALLTHROUGH do?

22:26 <maxwellr96> Oh wait, nevermind. I didn't realize that fallthrough was a C++ language feature

23:17 <K-ballo> I'm back home, safe and sound

23:18 <hkaiser> K-ballo: nice