02:04 <weilewei> I tried to use spack to install hpx, and found the build error: /tmp/weile/spack-stage/cmake-3.15.1-ebvvojezhkv4n6hj3oyojwusf6fsvmpo/spack-src/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by

02:04 <weilewei> /tmp/weile/spack-stage/cmake-3.15.1-ebvvojezhkv4n6hj3oyojwusf6fsvmpo/spack-src/Bootstrap.cmk/cmake)/tmp/weile/spack-stage/cmake-3.15.1-ebvvojezhkv4n6hj3oyojwusf6fsvmpo/spack-src/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

02:04 <weilewei> /tmp/weile/spack-stage/cmake-3.15.1-ebvvojezhkv4n6hj3oyojwusf6fsvmpo/spack-src/Bootstrap.cmk/cmake)

02:05 <weilewei> I do not have sudo access to summit apparently :-) how can I add those missing GLIBCXX? or anyway to skip this error?

02:23 <weilewei> problem solved by adding module info in spack's compilers.yaml

03:30 <weilewei> hkaiser Dr. Kaiser, I somehow remembered you had a talk where shares about hpx in the triangle of performance, portability, productivity. where is it? Or maybe I remember wrongly

03:31 <hkaiser> weilewei: that wasn't me

03:31 <weilewei> oh, ok, never mind then

03:31 <weilewei> I need to write that abstract for https://p3hpcforum2020.alcf.anl.gov/

03:32 <weilewei> I will search around the internet and summarize it up

03:34 <hkaiser> ok, thanks

03:34 <weilewei> my pleasure : )

04:07 <zao> spack, heh, the other inferior software system :P

04:18 <weilewei> ==> Successfully installed hpx Fetch: 0.02s. Build: 1h 19m 27.65s. Total: 1h 19m 27.67s.

04:18 <weilewei> lol, it seems it is installed

04:18 <weilewei> zao why, people are saying it is good

04:19 <weilewei> Well, I guess it is relative

04:27 <zao> weilewei: Mostly friendly jabbing, we're using the Other One.

04:28 <zao> When I used their HPX script, it wasn't quite fit for purpose with newer versions.

04:30 <zao> But that was a few HPX versions ago.

04:30 <weilewei> @zao I think the hpx script in their master branch needs some fix... I can't install hpx from current commit directly

04:33 <weilewei> simbergm I saw you are one of the contributors for hpx script in spack github, are you maintaining it? Can I create PR to it if I want to fix something? Or does it has to go through you or any other people

07:43 <jbjnr> I like spack much more than easybuild

15:23 <jbjnr> hkaiser: fyi - Mauro is too busy to attend isocpp meetings and so I'll be taking over that role and I'll start looking more deeply at the executors proposal and potentially working on getting our stuff up to date

15:28 <K-ballo> jbjnr: will you be in Prague?

15:29 <jbjnr> I think so. (Not planned anything yet, but I will put in a travel request before this week is over)

15:30 <jbjnr> K-ballo: you going?

15:33 <hkaiser> jbjnr: nice!

15:33 <K-ballo> yep, I'll spend another couple months in europe

15:33 <jbjnr> months! wow

15:33 <jbjnr> hkaiser: abstract!

15:39 <hkaiser> K-ballo, heller: I'd like to ask you to have a look at the new channel_spsc implementation (https://github.com/STEllAR-GROUP/hpx/blob/master/libs/synchronization/include/hpx/synchronization/channel_spsc.hpp) to see if you can spot races or other undesired things

15:39 <hkaiser> thanks!

16:03 <K-ballo> I'll put it in the queue

16:04 <K-ballo> btw is there still time for more debug bloat reduction before the release?

16:18 <jbjnr> always time for bloat removal!

16:19 <jbjnr> not sure when simbergm is planning the release. soon, but when exactly I don't recall. I'd like my scheduler stuff to go in before it happens too...

16:22 <simbergm> what jbjnr said... we're way past when I initially planned the release, but christmas is an absolute deadline

16:23 <simbergm> the minimum I want to have still is the apex fixes, and once that's in I wouldn't want to wait much longer

16:24 <simbergm> everybody review jbjnr's pr! (or noone review it, not sure which is faster...)

16:29 <jbjnr> we must get the new apex fixes in too...

16:31 <jbjnr> simbergm: your comments are all correct, but doing the job 'properly' really needs all the other schedulers updated and I don't want to do that. if we can get this one in, prove it to be stable and reliable, then eventualy make it the default one, then fixing the other schedulers becomes less important.

16:31 <jbjnr> (I think)

16:31 <weilewei> simbergm it might be a silly question, shall spack have debug option for hpx?

16:36 <simbergm> jbjnr: I'm not asking to have the other schedulers updated, it would just be nice to have the interfaces (e.g. whether bound tasks is a priority or hint) because that's user facing

16:36 <simbergm> weilewei: can you try build_type=debug as a variant? I think all spack cmake packages support that implicitly

16:37 <jbjnr> I do agree - but for now it's an 'experimental' feature that needs to mature - and once we have more experience of adding features like this, we can build a better API for them (IMHO)

16:37 <jbjnr> we're going to have to redo all the excutor stuff anyway soon ...

16:38 <jbjnr> scheduler is broken on daint anyway so it barely matters. Why does this happen on every update?

16:38 <jbjnr> answer : because I tried to clean up the PR too much and broke it.

16:54 <simbergm> jbjnr: let's talk when the pr builds and passes tests

16:55 <simbergm> the apex commits should probably not be on that branch btw

17:04 <weilewei> simbergm I think it might need explicit expression in the script, I tried passing build_type=Debug to spack and it seems not working

17:04 <weilewei> like this: https://github.com/ipdemes/flecsi/blob/4b27b58f8f23e8331922add763a2157ba9440eac/spack-repo/packages/hpx/package.py#L43

17:07 <simbergm> weilewei: can you check if build_type shows up in the list of options when you do spack info hpx

18:13 <heller> hkaiser: from a cursory look, only the move assignment and move construction look fishy

18:14 <heller> I think you need to close the rhs before moving the content

18:20 <hkaiser> heller: good point

18:21 <heller> Or just make it non-movable and non-copyable

18:21 <hkaiser> heller: conceptually the channel is non-copyable, but I needed to define the move functions to work around the non-copyability of atomic as I wanted to be able to store channels in containers

18:21 <heller> Ah, right

18:22 <heller> The other option is to document moving as non thread safe...

18:22 <hkaiser> yah, right