<gnikunj[m]>
the email doesn't have instructions to connect to the head node of loni
<gnikunj[m]>
thanks! it works now.
<gnikunj[m]>
I'm setting up my project on loni for now. I need to get some results before tomorrow's call and work on the benchmark as well.
<hkaiser>
nod
<hkaiser>
thanks
<gnikunj[m]>
we'll take care of the srun/mpirun issue on rostam later
<hkaiser>
gnikunj[m]: just run mpirun in your slurm allocation, that should take care of things as well
<gnikunj[m]>
hkaiser: I wish. Things aren't exactly working the way they should, it gets stuck at a few points.
<hkaiser>
ok
<gnikunj[m]>
I don't exactly know what's happening really. Its not just my example codes, its with all of them. I have most likely screwed up my rostam account with environment variables and stuff. Loni should be good start.
<hkaiser>
ms[m]: coverage reporting is down again, however, I'm not sure how to fix that
<ms[m]>
"hkaiser" (https://matrix.to/#/@freenode_hkaiser:matrix.org): uhh, thanks for the heads up
<ms[m]>
I hope it's just me who broke it again...
<ms[m]>
looks like the build just stopped halfway through... I've restarted it, let's see if does something more useful this time
<hkaiser>
ms[m]: thanks
<ms[m]>
btw, rori and jbjnr (hkaiser as well for that matter), if you don't yet have gitlab accounts it might be a good idea to get that and add you to the gitlab ci project so that I'm not the only one with access to it (besides harmen)
<ms[m]>
if you'd like to be added send me your gitlab usernames (on the gitlab.com gitlab instance)
<rori>
ms[m]: same as on github ;)
<ms[m]>
rori_[m]: thanks!
<hkaiser>
ms[m]: h.kaiser
<gnikunj[m]>
hkaiser: I'm glad to report that everything works perfectly fine on loni. For the rest of the month, I'll present all my results based on loni's nodes
<hkaiser>
gnikunj[m]: \o/
<gnikunj[m]>
the preliminary results on 20 nodes look amazing as well!
<gnikunj[m]>
I don't think I'll want to go anything above 20 nodes for the purpose of testing, but I'm tempted to test on 100 nodes ;-)
<hkaiser>
gnikunj[m]: lol
<gnikunj[m]>
hkaiser: which cmake flag enables C++17 build for hpx?
<hkaiser>
gnikunj[m]: standard CMAKE_CXX_STANDARD settings
<gnikunj[m]>
aah thanks!
<gnikunj[m]>
just to clarify, we do not depend on boost if we use c++17 right?
<hkaiser>
we do not dpend on linking with boost
<hkaiser>
we still need some header only libries
<gnikunj[m]>
ok
<tiagofg[m]>
hkaiser: Hi, have you looked at the inheritance example?
<hkaiser>
tiagofg[m]: I did look, but was not sure what your question was :/
<tiagofg[m]>
the action must return the member value, but return always 0
<hkaiser>
what action?
<tiagofg[m]>
regardless of the value of the member variable
<tiagofg[m]>
getIdp_action
<hkaiser>
ok, understood
<tiagofg[m]>
belongs to B class component
<hkaiser>
tiagofg[m]: does the code expose that problem?
<tiagofg[m]>
hkaiser: what you mean?
<tiagofg[m]>
ahh yes of course
<tiagofg[m]>
if you run that example the problem will happen
<hkaiser>
tiagofg[m]: ok
karame_ has joined #ste||ar
karame_ has quit [Remote host closed the connection]
bita has joined #ste||ar
<hkaiser>
tiagofg[m]: you will have to make getIdp() virtual
<tiagofg[m]>
humm, and define getIdp() on the derived function(c)?
<hkaiser>
no, just make it virtual
<hkaiser>
the problem is that an hpx id_type is esentially a glorified void* which will reinterpret_cast'ed to the component type
<tiagofg[m]>
I will do that later today, thank you!
<tiagofg[m]>
hummm
<hkaiser>
in derivation contexts this doesn't work well as for that the correct type needs to be known
<hkaiser>
also, the function bound to the action should be virtual as some compilers don't like that
<hkaiser>
the examples demonstrate how to work around this
<hkaiser>
you need two functions, one non-virtual that is bound to the action and which calls a virtual one
<hkaiser>
tiagofg[m]: I really think you should rather have one type representing the component and embedd the others as members
<hkaiser>
this would simplify your design and resolve the issues we're having
<hkaiser>
simply wrap the types you have in a new type that is the component
<tiagofg[m]>
okok, I already saw that examples.
<tiagofg[m]>
The problem is that I have to stay loyal to the API and the code format. But I will think that way
Yorlik has joined #ste||ar
akheir has joined #ste||ar
weilewei has joined #ste||ar
diehlpk_work has joined #ste||ar
shahrzad has joined #ste||ar
<hkaiser>
bita: do you still want to meet now?
RostamLog has joined #ste||ar
jaafar has quit [Quit: Konversation terminated!]
weilewei has quit [Ping timeout: 245 seconds]
nanmiao11 has quit [Ping timeout: 245 seconds]
hkaiser has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
weilewei has joined #ste||ar
nanmiao11 has joined #ste||ar
hkaiser has quit [Quit: bye]
nanmiao11 has quit [Remote host closed the connection]