13:37 <diehlpk_work> ms[m]1, Could you please have a look into the Fedora issue?

13:37 <diehlpk_work> I would really like to ship hpx 1.6.0 with the next Fedora release?

14:08 <diehlpk_work> hkaiser, I changed a few things for hpxcl. 1) I updated to Cuda 11 2) I removed the dependecy on master and updated it to work with 1.5 and 1.6

14:09 <diehlpk_work> Recommending master is not a good choice, since we would need to adapt hpxcl too often

14:09 <diehlpk_work> I think align it with the latest release is much less work for us

14:12 <jedi18[m]> hkaiser: I'd add steps on how to adapt an algorithm to C++20 in the proposal right? If so it would end up looking very similar to gonidelis 's post here https://github.com/STEllAR-GROUP/hpx/issues/4822. I hope that's not an issue?

15:22 <gonidelis[m]> <K-ballo "merge your find_package calls, f"> so `INCLUDE_DIRECTORIES`, uses -I?

15:23 <gonidelis[m]> ahh... I just pass SYSTEM as an arg

15:23 <gonidelis[m]> <K-ballo "and prefer using targets instead"> K-ballo: what's the difference?

15:27 <gonidelis[m]> K-ballo: although it worked with those fixes, but still

15:38 <gonidelis[m]> K-ballo: does range-based for loop accept ranges that have different begin/end iters?

15:41 <K-ballo> whether INCLUDE_DIRECTORIES uses -I or something else depends on how the property is consumed

15:41 <K-ballo> as for differences between variables and targets, try some google

15:42 <K-ballo> just changing to targets would have been enough to fix the issue

15:44 <gonidelis[m]> K-ballo: acutally i get their difference but i don't get why one could substitute the other

15:44 <gonidelis[m]> they server different purposes

15:45 <gonidelis[m]> serve*

15:47 <K-ballo> the ones you are using don't, they serve the same purpose

15:47 <K-ballo> specifying usage requirements

15:48 <gonidelis[m]> K-ballo: ah you talk about the `CMAKE_CXX_FLAGS` one

15:48 <hkaiser> jedi18[m]: sounds good

15:48 <hkaiser> diehlpk_work: ok, cool

15:49 <hkaiser> diehlpk_work: btw, I'm not able to reproduce the new fedora issue - is it caused by a new compiler version?

15:49 <K-ballo> the other one too

15:50 <diehlpk_work> hkaiser, -- The CXX compiler identification is GNU 11.0.1

15:51 <hkaiser> diehlpk_work: could you try with this patch, pease: https://gist.github.com/hkaiser/554e5866ab5ac0111901cbcdaa19b69c

15:51 <diehlpk_work> hkaiser, It seems that the boost version changed

15:51 <hkaiser> I have no idea what's going on, just guessing...

15:52 <diehlpk_work> hkaiser, it seems to be related to 64 arch

15:52 <diehlpk_work> All 64 builds fail and all 32 are still working

16:03 <srinivasyadav227> I have couple of queries regarding GSoC Project.

16:03 <srinivasyadav227> For GCC and msvc we can only provide hint to compiler to vectorize, and it will vectorize only when we pass optimiser flags -ftree-vectorize -O2. And in GCC, mostly autovectorization takes places,so pragma directives really could not help much. And gcc implements std::execution::unseq and std::execution::par_unseq with openmp as backend, so even I would like to use openmp as backend, is that fine?,

16:03 <srinivasyadav227> I strictly use openmp only for simd or vectorization.

16:05 <srinivasyadav227> hkaiser: *

16:06 <srinivasyadav227> hkaiser: sorry, I forgot to tag ;-)

16:12 <hkaiser> srinivasyadav227: the latest versions of msvc support the llvm openmp runtime, so I would assume that the simd options are now supported as well

16:13 <srinivasyadav227> hkaiser: you mean, use openmp for msvc also?

16:15 <srinivasyadav227> here, https://docs.microsoft.com/en-us/cpp/parallel/openmp/openmp-simd?view=msvc-160 msvc supports openmp, this is what i am planning to use

16:17 <srinivasyadav227> same for gcc, and clang has built in support for openmp i.e openmp is a part of clang https://openmp.llvm.org

18:24 <gonidelis[m]> K-ballo: should i also unify my `find_package`s if including multiple libs?

18:29 <hkaiser> hey rori! would you be able to help with this: https://cdash.cscs.ch/viewBuildError.php?buildid=154639? (that's related to https://github.com/STEllAR-GROUP/hpx/pull/5247)

18:37 <gonidelis[m]> hkaiser: what's the `#include <hpx/config.hpp>` for?

18:38 <hkaiser> it includes various configuration headers

18:40 <gonidelis[m]> is it mandatory for an external hpx app

18:40 <gonidelis[m]> ?

18:40 <hkaiser> no

18:40 <gonidelis[m]> or just hpx/hpx.hpp could do the work?

18:40 <hkaiser> yes

18:41 <hkaiser> except for the file that defines main(), there you want to have hpx/hpx_main.hpp additionally

18:43 <gonidelis[m]> thanks :)

18:49 <rori> hkaiser: I'll have a look tomorrow I'm not home at the moment :)

18:49 <hkaiser> rori: sure, thanks a lot!

20:43 <hkaiser> rori: makes perfect sense, thanks!

22:44 <K-ballo> is cleaning up the cpu_mask implementations something a student could do?

22:45 <K-ballo> is there any design aspect to it, or just guaranteeing a common interface for the different implementations?

23:20 <hkaiser> K-ballo: just a common interface

23:21 <hkaiser> K-ballo: asking a student is a good idea, I have a lady that just has started, I think she might be interested in doing it

23:30 <hkaiser> gnikunj[m]: yt?