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
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has quit [Quit: Bye!]
diehlpk_work has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> ms[m]: I have a question wrt the docker env for our builders
<hkaiser> I created the PR that adds the zlibdev libraries here: https://github.com/STEllAR-GROUP/docker_build_env/pull/45
<hkaiser> but for some reason in fails, would you be able to ahve look to help?
<ms[m]> hkaiser: mmh, I think the config is just faulty... if you'd like I can try to push something there
<ms[m]> the hip step doesn't have access to the just built base image which doesn't get pushed on prs
<ms[m]> I think the steps could be merged into one and then it'd see the base image, but not entirely sure
<hkaiser> ms[m]: how did you handle that before?
<ms[m]> I think we didn't... it works correctly when you merge it to master, the check on the pr doesn't
<hkaiser> should I just merge the PR?
<ms[m]> I think I've just ignored it before
<hkaiser> ahh, ok - that's fine, then
<hkaiser> I merged it, let's see
pedro_barbosa[m] has joined #ste||ar
<ms[m]> yeah, fine-ish
<hkaiser> thanks
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
<hkaiser> satacker[m]: should it?
<satacker[m]> if the user formed overload is incorrect then it defaults to false right?
<hkaiser> satacker[m]: I think you're right
<hkaiser> excellent catch!
<hkaiser> not sure what I was thinking ;-)
<satacker[m]> I'll update it in my WIP PR, with some tests for it
<hkaiser> perfect, thanks!
<hkaiser> satacker[m]: btw, there is another implementation that was referenced in p2300r5, not sure if you've seen it
<satacker[m]> hkaiser: let me check, thanks
<satacker[m]> hkaiser: ohh, it's from microsoft : )
<satacker[m]> If this is going into STLs so quickly do we need to reimplement all of it?
<K-ballo> it's not from microsoft
<dkaratza[m]> hkaiser: can we change again tomorrow's meeting? I'm so sorry about that but my schedule is a complete mess again :/ can you do Thursday after 19:00 CET?
<hkaiser> dkaratza[m]: Thursdays afternoon are reasonable free for me
<hkaiser> satacker[m]: I think we should have our own implementation, several reasons: a) our implementation is C++17, b) it relies on our threading
<dkaratza[m]> hkaiser: oh great! can we maybe do 20:00 CET?
<hkaiser> c) it will take several years for the whole thing to be standardized, we can think of replacing our implementation then
<satacker[m]> got it, thanks
<hkaiser> dkaratza[m]: Thursday 3pm my time is fine
<hkaiser> dkaratza[m]: I sent the meeting update
<hkaiser> sorry, I meant 1pm my time
ruchipakhle has joined #ste||ar
<dkaratza[m]> hkaiser: The invitation I got is for 15:00 your time
<hkaiser> dkaratza[m]: I sent another one just now ;-)
<dkaratza[m]> Oh no, you sent another one
<hkaiser> sorry for the spam
<dkaratza[m]> No problem at all
<dkaratza[m]> My apologies for changing it again
<hkaiser> somehow my brain was saying that 20.00 your time is 3pm :/
<dkaratza[m]> Haha no worries
ruchipakhle has quit [Quit: Client closed]
diehlpk_work has quit [Ping timeout: 250 seconds]
diehlpk_work has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]
Yorlik has quit [Ping timeout: 250 seconds]