00:59 <diehlpk_work> https://www.osti.gov/biblio/1764191/

01:00 <diehlpk_work> The SC20 panel report is finally published

01:08 <hkaiser> \o/

02:10 <hkaiser> jaafar: I have not tried running ubsan

02:35 <diehlpk_work> hkaiser, ms[m] I started to build the rc-2 on Fedora's build system

02:35 <hkaiser> thanks!

02:36 <diehlpk_work> We should know by tomorrow morning if we are fine

08:43 <ms[m]> gnikunj: how did it go in the end with the cuda build? note that it's HPX_CUDA_CLANG_FLAGS without WITH

08:44 <ms[m]> you might have bumped into an HPX/Boost/whatever build problem that we don't test, currently the only cuda+clang build that we have is with cuda 10.2 and (cray) clang 10

08:44 <gnikunj[m]> ms I gave up yesterday on the build :/

08:44 <gnikunj[m]> I'll try fresh today. Thanks for note!

08:45 <ms[m]> diehlpk_work: are you using all the commits that gregor was using? kokkos from september should be ok (the commit gregor was using, or kokkos 3.2.0 onwards), hpx-kokkos should be close to latest master, but it looks like your hpx is not new enough... we made that change in the namespaces sometime after 1.5.1

08:45 <ms[m]> and thank you for doing the fedora packaging!

12:04 <hkaiser> ms[m]: yt?

13:14 <sawdey21> /!\ this channel has moved to #nyymit /!\

13:15 <codebamBG> /!\ this channel has moved to #nyymit /!\

13:17 <brynjaroc> /!\ this channel has moved to #nyymit /!\

13:18 <gonidelis[m]> let's run then

13:56 <ms[m]> grr, is it the annual spam swarm?

13:56 <ms[m]> hkaiser: sorry, here now

13:59 <hkaiser> ms[m]: hey

14:00 <hkaiser> ms[m]: I'm trying to replace boost.asio with asio standalone

14:00 <hkaiser> but that has no cmake build system, so I'm tryin to generate one on the fly

14:00 <ms[m]> I saw that, and it looks like a very nice idea, thank you!

14:00 <hkaiser> but obviously I have no idea what I'm doing....

14:00 <ms[m]> I had a quick look at it and noticed exactly that... I'd like to help with that if I can

14:01 <hkaiser> that's what I wanted to ask - if you found the time...

14:01 <ms[m]> I think we'd be fine with `find_library` and friends

14:01 <ms[m]> yeah, absolutely, no worries

14:01 <hkaiser> thanks!

14:02 <hkaiser> the errors I'm seeing don't make sense to me

14:02 <ms[m]> the only thing we have to do is make sure that the headers get installed if we use the fetchcontent version of it... which can be a bit ugly but let's see how it is

14:02 <ms[m]> ok, I'll have a look

14:02 <hkaiser> he good thing is that this gets rid of a large amount of boost dependencies with almost no effort on our end

14:04 <hkaiser> I think I have the header installation part under control

14:04 <k-ballo[m]> i tried the asio thing once, it was impossible with boost::error_code back then

14:04 <hkaiser> K-ballo: it maps it to std::error_code nowadays

14:05 <k-ballo[m]> that was the problem, std and boost error codes weren't compatible at that timr

14:05 <hkaiser> it gets rid of boost::error_code alltogether

14:06 <hkaiser> now, that we have too - this was straighforward

14:06 <k-ballo[m]> it should be fine now that boost got compatibility, and we migrated to std

14:06 <hkaiser> nod

14:30 <diehlpk_work> ms[m], Yes, I use the same HPX commit as Gregor

14:31 <diehlpk_work> Let me get the Kokkos commit

14:39 <ms[m]> diehlpk_work: ok, thanks

14:39 <ms[m]> could you also post the hpx commit?

14:41 <diehlpk_work> ms[m], git checkout 1774165304d81ea2db3818b7020f6c71fbefac97

14:41 <diehlpk_work> git apply ../../nvcc_wrapper_for_octotiger.patch

14:41 <diehlpk_work> Gregor gave me this kokkos commit and patch

14:42 <diehlpk_work> and this is the hpx commit a1305aa34dc38065d2a4d3eae42b2a6337c01e97

14:56 <ms[m]> diehlpk_work: something is most likely not right in your environment... the versions should be ok

14:56 <ms[m]> do you have another hpx installed somewhere visible system-wide?

14:57 <diehlpk_work> No, it is on Summit

14:57 <diehlpk_work> I only installed one hpx

15:00 <ms[m]> diehlpk_work: does it build on non-summit with the exact same versions?

15:00 <ms[m]> that error doesn't look like it would be caused by anything system-specific

15:02 <diehlpk_work> ms[m], Gregor said yes

15:07 <ms[m]> diehlpk_work: right... do you have the full error message?

19:28 <diehlpk_work> ms[m], hkaiser rc-2 succeed on Fedora 34 and rawhide

19:29 <diehlpk_work> https://koji.fedoraproject.org/koji/taskinfo?taskID=61694942

19:29 <diehlpk_work> http://koji.fedoraproject.org/koji/taskinfo?taskID=61695043

19:52 <diehlpk_work> ms[m], Please find here the full error log https://pastebin.com/PQjLvtHc

19:53 <diehlpk_work> if I update to HPX 1.5.1 I get some header issues with hpx::compute within octo-tiger.

19:53 <diehlpk_work> I will meet with Gregor tomorrow and we will double check if he provided the correct versions

20:01 <hkaiser> \o/

20:29 <ms[m]> hkaiser: still need to sleep on the changes to the asio pr... :P

20:30 <hkaiser> ms[m]: thanks a lot for looking into this

20:30 <ms[m]> also still seems to fail on gh actions, it doesn't for me locally so not sure yet what's happening there

20:30 <hkaiser> no rush!

20:52 <hkaiser> jaafar: actually, our github runner has ubsan enabled: https://github.com/STEllAR-GROUP/hpx/blob/master/.github/workflows/linux_sanitizers.yml#L31

21:54 <k-ballo[m]> hkaiser you can `return()` out of a cmake include()

21:56 <k-ballo[m]> we can also use cmake's own FetchContent now, introduced in 3.11 and we require 3.13

22:04 <k-ballo[m]> the error comes from linking the target and using it before it actually exist, the config tests in between linking to base libraries and eventually including setup-asio

22:07 <hkaiser> K-ballo: why return()?

22:09 <k-ballo[m]> to avoid nesting the entire file's content inside an if

22:14 <hkaiser> yah, sure - just as a readability aid