K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
patrick22 has quit [Ping timeout: 272 seconds]
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
bita has quit [Read error: Connection reset by peer]
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
shahrzad has quit [Quit: Leaving]
akheir has quit [Remote host closed the connection]
bita has quit [Ping timeout: 240 seconds]
patrick22 has joined #ste||ar
hkaiser has joined #ste||ar
<parsa>
hkaiser: ping
<hkaiser>
parsa: here
<parsa>
hkaiser: your fix works
<parsa>
see pm
diehlpk_work_ has quit [Ping timeout: 260 seconds]
patrick22 has quit [Ping timeout: 272 seconds]
akheir has joined #ste||ar
patrick22 has joined #ste||ar
diehlpk_work has joined #ste||ar
shahrzad has joined #ste||ar
patrick22 has quit [Ping timeout: 272 seconds]
<gonidelis[m]>
ms[m]: How do you handle segmented counterpart when adapting algos to C++20?
bita has joined #ste||ar
patrick22 has joined #ste||ar
patrick22 has quit [Ping timeout: 272 seconds]
<gonidelis[m]>
regression tests are still failing right?
<ms[m]>
gonidelis[m]: I have done nothing special about them, if the algorithm had support for it from before that stayed but I've done nothing to check that the new overloads also work with segmented iterators
<ms[m]>
how? which tests? and where?
<gonidelis[m]>
ms[m]: yeah right. I mean, whether you change the return type if necessary
<gonidelis[m]>
since the wrapper point is sth like `algo_()`
<gonidelis[m]>
which redirects either to the parallel algorithms or the segmented ones
<gonidelis[m]>
(of course i am talking only about the cases when the result type is changing due to adaptation)
<ms[m]>
right, I don't think I've had to deal with that so far...
<ms[m]>
but if the new overloads require changing the segmented overloads as well, then they require changing :P
<ms[m]>
does transform have segmented overloads?
<gonidelis[m]>
1. yes it has
<gonidelis[m]>
2. i think it produces some mini errors on continuous integration tests
<gonidelis[m]>
2b. I think the problem can be solve by just changing the result type though (?). Not sure...
<gonidelis[m]>
ms[m]: plus do you know if these unit tests errors are supposed to fail
<ms[m]>
gonidelis[m]: they're definitely not supposed to fail, they also don't fail on master
<ms[m]>
it looks like most of those are deprecation warnings
<ms[m]>
the error messages should in most cases tell you what to use instead
<ms[m]>
if they don't tell you, or if there are non-deprecation errors please ping me again
<ms[m]>
mainly you need to change hpx::parallel::transform to hpx::transform/hpx::ranges::transform and hpx::parallel::execution::seq/par to hpx::execution::seq/par
patrick22 has joined #ste||ar
<gonidelis[m]>
ms[m]: ok great. Already done that. I will take for the CI tests to tell more...
<gonidelis[m]>
Thanks a lot!
<ms[m]>
also, it's a good idea to set HPX_WITH_COMPILER_WARNINGS=ON and HPX_WITH_COMPILER_WARNINGS_AS_ERRORS=ON if you want to catch those before pushing and having ci run
<gonidelis[m]>
ms[m]: hmmm great... actually I had already cought them
<gonidelis[m]>
I just didn't know that they would produce CI errors
<ms[m]>
we enforce cleaning those warnings up before merging to master to avoid having them linger around, cleaning them up later is much more work than doing it per pr
Vir has quit [Ping timeout: 272 seconds]
Vir has joined #ste||ar
<gonidelis[m]>
ms[m] sure I will tackle them before merge then