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/
<rachitt_shah[m]>
I would like to showcase some demos at our call, or perhaps build a page for HPX as proof of concept.
hkaiser has joined #ste||ar
<ms[m]>
rachitt_shah: all right, I'm open to hear your suggestions, but I think moving to another platform for the non-API docs is most likely overkill and may be focusing on the wrong parts
<ms[m]>
let's discuss in the meeting though!
<rachitt_shah[m]>
<ms[m] "rachitt_shah: all right, I'm ope"> Makes sense, perhaps I would need to direct my focus on APIs first. Let's take this up on the meeting.
<gonidelis[m]>
hkaiser: ms[m] gnikunj[m] Apologies, I won't be able to attend gsod meeting today. I am cought up in some schoolwork....
<ms[m]>
gonidelis[m]: no worries
<hkaiser>
sure, np
<hkaiser>
ms[m]: since you asked: for V1.7 I would like to get #5357 in
<hkaiser>
also, I would like to fix the c++17 github builder problems - btw, was that the reason for deciding not to move to c++17 yet?
<hkaiser>
(#4994)
<ms[m]>
hkaiser: yep, I only meant for rc1 at this point, we can definitely get that in 1.7.0
<hkaiser>
#5328 looks to be ready - almost as well
<ms[m]>
I don't know if I can give a useful review on that but I can definitely have a high level look if you'd like
<hkaiser>
ahh ok - cool
<hkaiser>
much appreciated
<ms[m]>
uhm, I think c++17 itself was fine but we tried adding some other flags as well which made everything terrible
<ms[m]>
don't remember the details, but I think there might be some links to logs in the discussion on the pr
<hkaiser>
ms[m]: for #5303, I'd rather move serializable_function into the serialization module, we've done this for serializable_any already
<ms[m]>
that makes sense
<hkaiser>
I plan to do that
<ms[m]>
we could do that and move the invoke stuff to a separate module as well
<hkaiser>
sure, but would that be necessary?
<ms[m]>
ok 👍️
<ms[m]>
not necessary, mostly just possible...
<hkaiser>
ms[m]: gnikunj[m] promised to finish #5353
<hkaiser>
#5362 would be nice to have as well - I could use that for one of our projects
<hkaiser>
btw
<hkaiser>
the future_sender you created (forgot the name), I think it needs a keep_alive as well
<ms[m]>
sure, anything marked 1.7.0 is still on track for 1.7.0 unless they get badly delayed