<gonidelis[m]>
I `#include <hpx/parallel/algorithms/detail/distance.hpp>`
<gonidelis[m]>
and then I use it like `hpx::parallel::v1::detail::distance()` or `hpx::parallel::distance` ?
<zao>
I’d intuitively consider implementation detail of a module off limits and favor using the public interface, but that’s personal guesswork :)
<ms[m]>
gonidelis: the `v1` namespace is inline, so that one can be optionally left out, i.e. `hpx::parallel::detail::distance` would be valid, but not `hpx::parallel::distance`
<ms[m]>
I don't think we have a consistent rule on if we actually specify inline namespaces, but I'd leave it out where you use it
<ms[m]>
if the cpp file is a test file you don't need to worry about `detail` being internal
<ms[m]>
if this is indeed meant to be public then it shouldn't be in `detail` in the first place, but I'll leave that to K-ballo/hkaiser (I don
<ms[m]>
't know where this fits in the greater scheme of ranges)
<gonidelis[m]>
ms[m]: No it does not meant to be public... Just want to test if it works on a mini script instead of a whole algorithm :) It seems like `hpx::parallel::v1::detail::distance()` works after all! zao How could this be done? I mean how to access `distance` through "public interface"? Thank you all btw!!!
<gonidelis[m]>
What are the options in order to format a .cmake file in HPX?
<gonidelis[m]>
with `cmake-format` ^^
<gonidelis[m]>
I did `cmake-format -i cmake/HPX_PerformCxxFeatureTests.cmake ` and I think it messed it up :E
<ms[m]>
gonidelis: if it's just for testing there's no need for a "public interface"
<ms[m]>
that looks right for cmake-format... what happened?
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 256 seconds]
K-ballo1 is now known as K-ballo
<K-ballo>
gonidelis[m]: that command looks fine to me, what went wrong?
<ms[m]>
the modules.cpp file should be gone, it might require a clean cache though
<K-ballo>
ms[m]: with a clean cache it works
hkaiser has joined #ste||ar
<ms[m]>
ok, good
<ms[m]>
we still need to improve a bit with our cache variables...
<ms[m]>
gonidelis: do you still have a problem with your rebase? if you post the conflicting changes I might be able to tell you what to choose
<gonidelis[m]>
ms[m]: Seems like it was my mistake after all... I had a branch based on another branch which had not yet been merged to master. I am trying to fix it right now. auriene helps a lot !
<gonidelis[m]>
sorry
<ms[m]>
gonidelis: no worries at all, glad you're getting it sorted out
kale[m] has quit [Ping timeout: 246 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
<K-ballo>
our governance text has awkward line wraps
weilewei has joined #ste||ar
<hkaiser>
K-ballo: thanks
<weilewei>
hkaiser just got email that p3hpc becomes remote
<nikunj97>
fellow stellar people. After 2d of grueling grinding, I present you a 1d stencil that scales its kernel almost linearly (strong scaling)
karame_ has joined #ste||ar
<nikunj97>
I'll add the pr soon
<hkaiser>
nikunj97: nice!
<nikunj97>
10^9 stencil points for 100 iterations take 22s on 1 node and 8s on 4 nodes
<nikunj97>
don't have more nodes to test on, but I like the results xD
<hkaiser>
nikunj97: is this based on the 1d_stencil series?
<hkaiser>
nikunj97: more nodes: rostam
<nikunj97>
hkaiser, no
<nikunj97>
this is based on 2d stencil series from thomas
<nikunj97>
I used his communicator api to build a 1d stencil
<nikunj97>
I did scale 1d stencil series in examples, but the scaling results weren't very impressive. I couldn't explain why though
<tiagofg[m]>
hello everyone,
<tiagofg[m]>
I want to load dynamic libraries at run time and I think you guys can help me
<tiagofg[m]>
I have a c++ program that loads the libraries using dlopen and dlsym, I want to do the same but using hpx, to have hpx code inside these dynamic libraries
<tiagofg[m]>
first of all, is this possible?
<tiagofg[m]>
thanks
<hkaiser>
tiagofg[m]: I wouldn't know why this isn't possible
<hkaiser>
tiagofg[m]: you still would need to initialize HPX, but we have examples showing how to do that
<tiagofg[m]>
where can I find them? has anything to do with the hpx plugins?
<hkaiser>
tiagofg[m]: plugins are dynamically loaded HPX modules, I don't think that's what you're after, but please correct me if I misunderstood
<nikunj97>
tiagofg[m], what do you want to achieve by having hpx code inside such library?
<hkaiser>
we use a similar scheme to initialize HPX from a Python extension module, works without problems in production code
<tiagofg[m]>
what I intend to do is do the same things I did with dlopen and dlsym, but with hpx functions inside them
kale[m] has joined #ste||ar
<tiagofg[m]>
I already tried but I had the following error: what(): Attempting to register a thread outside the HPX runtime
<hkaiser>
tiagofg[m]: yah, the example will show you what to do
<tiagofg[m]>
yah I am looking
<tiagofg[m]>
I will try, thank you!
rtohid has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
<Yorlik>
Are futures also garbage collected? Or are they automatically removed when they go out of scope?
<K-ballo>
both?
<Yorlik>
Depending on the payload?
<K-ballo>
actually it depends on why you are asking
<K-ballo>
shared states are ref-counted
<Yorlik>
So - if the future returns a smart pointer as payload - would that keep alive the shared state? Or is the pointee not inside the shared state?
<Yorlik>
I'm asking, because I see low frequency memory fluctuations and was wondering if these reflect the GC.
<K-ballo>
the future returns a copy of the smart pointer
<gonidelis[m]>
whichi is like 34 commits (only 3 or 4 are mine)
<gonidelis[m]>
any ideas on how could I fix that?
<Yorlik>
would get_ptr like hpx::get_ptr<mytype>( hpx::launch::sync, id ) throw if id is a remote object?
<ms[m]>
gonidelis: did you at some point rebase on a branch that was not master? you most likely want to do an interactive rebase (`git rebase -i origin/master`) and "drop" the commits that are not yours
<gonidelis[m]>
yeah
<gonidelis[m]>
Actually I rebased on a previous PR of mine that i am waiting to be merged
<ms[m]>
I highly recommend you first create another temporary branch on the same commit as your actual branch if this is the first time you do that
<gonidelis[m]>
as my work was depending on that ;/
<ms[m]>
just so you can try again if you happen to lose some commits you didn't intend to drop
<ms[m]>
gonidelis: ok... I guess do the rebase, drop the unrelated commits, and check that everything still looks the way you expect in any case
<weilewei>
agreed hkaiser ms[m]
<weilewei>
std::size_t m_thread_data_2
<ms[m]>
if your local and remote branches are not on the same commit one of them is not up-to-date
<hkaiser>
weilewei: I think you should create a separate set of APIs handling the libcds data, leaving alone the existing thread_data
<ms[m]>
if it's the remote one is on the correct commit, reset or pull to that one first
<hkaiser>
weilewei: [get|set]_libcds_data()
<weilewei>
hkaiser oh... I see
<hkaiser>
wrap that inside a #if HPX_HAVE_LIBCDS/#endif
<weilewei>
but separate api calls doesn't mean separate files right?
<weilewei>
like hpx get[set]_thread_data show in thread_data.hpp, thread_data_stackful.hpp, thread.hpp, coroutine.hpp, etc... I just need to put [get|set]_libcds_data() in those files
<gonidelis[m]>
ms[m]: thank you so much. Don't know what went wrong I finally managed to make a clean PR. And even think that rori has been helping me the whole day....
bita_ has joined #ste||ar
<gonidelis[m]>
anyways. Today was a mini-git nightmare for me but I really love it when I have to deal with such complicated git "exercises".