hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has joined #ste||ar
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
hkaiser has quit [Quit: Bye!]
tufei__ has joined #ste||ar
tufei_ has quit [Remote host closed the connection]
RostamLog has quit [Ping timeout: 268 seconds]
RostamLog has joined #ste||ar
<bhumit[m]>
hkaiser_ Is there a reason for non-standard algorithms like `reduce_by_key` and `sort_by_key` being in `hpx::parallel::v1` as opposed to just being in the top-level namespace?
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 264 seconds]
K-ballo1 is now known as K-ballo
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ste||ar
dkaratza[m] has quit [Quit: Bridge terminating on SIGTERM]
satacker[m] has quit [Quit: Bridge terminating on SIGTERM]
bhumit[m] has quit [Quit: Bridge terminating on SIGTERM]
ms[m] has quit [Quit: Bridge terminating on SIGTERM]
rtohid[m] has quit [Quit: Bridge terminating on SIGTERM]
gonidelis[m] has quit [Quit: Bridge terminating on SIGTERM]
gdaiss[m]1 has quit [Quit: Bridge terminating on SIGTERM]
john98zakaria[m] has quit [Quit: Bridge terminating on SIGTERM]
gnikunj[m] has quit [Quit: Bridge terminating on SIGTERM]
KordeJong[m] has quit [Quit: Bridge terminating on SIGTERM]
gdaiss[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
rtohid[m] has joined #ste||ar
bhumit[m] has joined #ste||ar
john98zakaria[m] has joined #ste||ar
satacker[m] has joined #ste||ar
pansysk75[m] has joined #ste||ar
dkaratza[m] has joined #ste||ar
KordeJong[m] has joined #ste||ar
ms[m] has joined #ste||ar
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ste||ar
<dkaratza[m]>
bhumit: which part of the public api are you doing currently? so that we dont have any conflicts
<bhumit[m]>
<dkaratza[m]> "bhumit: which part of the public..." <- Not doing any part, just adding missing links to public api. I doubt our work will conflict this week
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 264 seconds]
K-ballo1 is now known as K-ballo
ct-clmsn__ has joined #ste||ar
<ct-clmsn__>
I've been slowly replacing a std::thread implementation with hpx::thread and hit a segmentation fault issue
<ct-clmsn__>
hpx::threads::thread_data::get_scheduler_base(this=0x0000000000000000) const at thread_data.hpp:520:20
<ct-clmsn__>
Is getting tripped in lldb when trying to create the following: std::vector<hpx::thread>
<ct-clmsn__>
Happens when doing the following `thread_vector.emplace_back(hpx::thread(&fn, args));`
<ct-clmsn__>
To clarify, creating the std::vector<hpx::thread> is no problem, appending to the std::vector<hpx::thread> is the problem
<ct-clmsn__>
Build environment/tools are
<ct-clmsn__>
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
<ct-clmsn__>
Not sure why hpx::thread's constructor isn't initializing associated hpx::threads::thread_data
ct-clmsn__ has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 252 seconds]
K-ballo1 is now known as K-ballo
ct-clmsn has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
ct-clmsn has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
<ct-clmsn>
Figured it out
<ct-clmsn>
Didn't add HPX::wrap_main to the cmake link targets
<ct-clmsn>
The problem is that hpx_main was being included without that target so the initial thread data was null b/c `int main` wasn't being properly delegated to the hpx::thread system
ct-clmsn has quit [Quit: This computer has gone to sleep]