05:54 <kordejong> <weilewei "Kor de Jong have you solved apex"> No, I haven't found a solution for this. A RelWithDebInfo build with the commit I used was not usable for me.

11:39 <Yorlik> hkaiser: Can any function returning a future yield? E.g. local_new?

11:41 <hkaiser> Yorlik: the function can or cannot yield, that has no relation to whether it returns a future or not

11:41 <Yorlik> OK. So it's not a general rule.

11:42 <hkaiser> the code calling .get() or similar on the future will possibly yield, however

11:42 <Yorlik> Allright. Probably itÄs not related to my current issue - hunting down a weird crash which might or might not be some sort of race.

11:43 <Yorlik> I think I'm still discarding futures where I shouldn't at one place.

14:42 <weilewei> @kordejong Thanks for getting back to me quickly. How about Debug or Release build? Will they cause any issue?

14:50 <kordejong> weilewei: I think I did not test that. At that time I was specifically interested in a RelWithDebInfo build with the APEX/OTF2 fixes.

14:51 <weilewei> kordejong I see, so shall I assume that you have not used APEX since then?

15:05 <kordejong> weilewei: Actually I did, a bit with 1.4.1, but I did not get the annotations I was interested in. Trying out the current master commit, which now has the APEX fixes merged in is on my list. I tried building two weeks ago and the build failed. Reporting this failing build is also on my list. But fixing a bug in my code is the top item on my list... ;-)

15:08 <weilewei> kordejong so 1.4.1 is workable commit for using HPX + APEX? Totally understood your situation and priority... I was just trying to use APEX to run some performance check to see if there is any interesting results. I am building a recent HPX commit with APEX in Debug version, let's see how it goes

15:11 <kordejong> Indeed, the issue with `pthread_setaffinity_np` was local to the (then) branch with APEX fixes. With 1.4.1 there is no such issue. Which commit are you using?

15:12 <weilewei> I am using commit d5627bec7efa8688f61bb450e41edc24b8d316d4, from May 3rd

15:14 <weilewei> But ideally, I am free to use latest master of HPX actually. But 1.4.1 doesn't give me hpx mpi future I need in my project. So if this commit not working, then I will try latest master HPX

15:15 <kordejong> Gtg now, back tomorrow. I will also try out a recent commit + APEX soon. Am interested to learn about your results.

15:15 <weilewei> kordejong I will keep you posted

15:22 <ms[m]> hkaiser, heller, jbjnr I can submit jobs again... so pycicle will slowly come up again

15:23 <ms[m]> I've updated some things so I'll bring them up slowly to avoid spamming all PRs with potentially broken builds, but I should have it all up by the weekend again

16:20 <heller1> Awesome!

17:19 <gonidelis[m]> When a teplate struct inherits some other template struct does the inhereted struct have to be specified??

17:34 <K-ballo> struct template, not template struct.. a struct template is not a struct, it's a template for one

17:35 <K-ballo> not sure what the actual question is.. I hope that helps

17:40 <gonidelis[m]> K-ballo: Yeah you are right.

17:40 <gonidelis[m]> Was talking about this line of code

17:40 <gonidelis[m]> https://github.com/STEllAR-GROUP/hpx/blob/7a07598fbfcb4a871d16d568e31dbd211dc74d4f/libs/algorithms/tests/regressions/count_3646.cpp#L19

17:41 <gonidelis[m]> Could `BitCountingIterator` inherit `Iterator`'s template parameters as template parameters. Because I think that in this case `Iterator<>` is specified

17:41 <K-ballo> and by "specified" I assume you meant to give it arguments (specialize it)?

17:42 <gonidelis[m]> Ahhh sorry... yeah specialize is the word i wanted to use. My bad

17:42 <K-ballo> note `BitcountingIterator` has one param and `Iterator` has two

17:45 <gonidelis[m]> btw hkaiser I just pushed `count_3646`. Everything compiles for me and all the tests are passed but I have one doubt on removing that line (` template <std::int64_t stopValue> `) from `BitCountingIterator` so now it's just a struct and not a struct template. The only template argument that `BitCountingIterator` was using is the stop value and the stopvalue is accepted by the Sentinel so there seem to be no template

17:45 <gonidelis[m]> paramters left for `BitCountingIterator`.

17:46 <gonidelis[m]> https://github.com/STEllAR-GROUP/hpx/pull/4667/commits/8f4a39e366056daa86ab1800f940a32dacfa7b50

17:47 <hkaiser> gonidelis[m]: is that a different branch?

17:47 <hkaiser> could you add that to your PR to make it pass?

17:48 <gonidelis[m]> ahh... I pushed it to the same branch. I think that it's the same PR (#4667)

17:52 <K-ballo> code for the new sentinel looks much better

18:16 <hkaiser> gonidelis[m]: thanks

18:21 <gonidelis[m]> I can see there is a build error on the Windows test...

18:28 <Guest40323> parsa

19:13 <ms[m]> gonidelis: you can ignore the failure on the windows builds, it's unrelated to your pr

19:20 <gonidelis[m]> ms[m] thanks a lot