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/
<LiliumAtratum>
Hi! Just wanted to report a small issue. Using hpx 1.5.0, included `<hpx/include/parallel_sort.hpp>`, and got a series of errors of type "'return_temporary_buffer': is not a member of 'std'". Seems `#include <memory>` is missing somewhere?
<LiliumAtratum>
Tried `#include <hpx/algorithm.hpp>` with the same result
<hkaiser>
LiliumAtratum: could you create a ticket with your configuration/cmake config options, please?
<LiliumAtratum>
oh... my apologies... I just realized it is a bit deeper. We have switched to C++20 recently, and `return_temporary_buffer` was removed
<hkaiser>
ahh
<LiliumAtratum>
You probably didn't switch just yet ;)
<K-ballo>
good catch
<K-ballo>
why are we still using temporary buffer anyhow?
<hkaiser>
I wasn't even aware we did
<LiliumAtratum>
or is there some newer version than 1.5.0 that I should pull?
<LiliumAtratum>
hpx/parallel/algorithms/detail/spin_sort.hpp has them
<hkaiser>
LiliumAtratum: only the next release is planned for c++20 compliance, we are not fully compliant yet
<LiliumAtratum>
ok, thx :)
<hkaiser>
LiliumAtratum: pls create a ticket, I'll fix it
<LiliumAtratum>
ok, I will create one. But I am sure, once you try compiling with C++20 you will hit the exact same error somewhere ;)
<LiliumAtratum>
I see you have a more general ticket `Adapt parallel algorithms to C++20 #4822`
<hkaiser>
LiliumAtratum: having a ticket will help in any case
<LiliumAtratum>
Created something small. #4971 is up.
<hkaiser>
and yes, actually compiling things before committing helps
LiliumAtratum has quit [Remote host closed the connection]
LiliumAtratum has joined #ste||ar
<LiliumAtratum>
Thank you :)
<LiliumAtratum>
Looking forward to 1.6.0
LiliumAtratum has left #ste||ar [#ste||ar]
<K-ballo>
it's gonna be a while
akheir has joined #ste||ar
<K-ballo>
I see a whole bunch of internal #include <hpx/modules/*.hpp>, are those intentional or just lazy?
<hkaiser>
K-ballo: what do you mean?
<K-ballo>
including an entire module for just one piece
<K-ballo>
is there some sort of design decision to only include entire modules?
<hkaiser>
K-ballo: we have talked about it but have not made a final decision
<hkaiser>
we don't have a clear rule for that :/
<hkaiser>
K-ballo: it's probably done to avoid constant changes while we were shuffling headers back and forth
<K-ballo>
there should be a fundamentals module with core functionality like invoke, always_void, void_guard, pack, range
<K-ballo>
HPX_NON_COPYABLE
<K-ballo>
the lambda stuff, although we shouldn't be using that anymore
<K-ballo>
it doesn't make sense to pull the entire functional module for the invoke macro, or the entire type support module for always_void, or the entire iterator support module for range begin/end
<hkaiser>
K-ballo: feel free ;-)
<hkaiser>
K-ballo: although, I think that just pulling the headers you need is fine