00:56 <parsa> K-ballo: how did people access an element in a shared_ptr<double[]>? https://wandbox.org/permlink/7nGopjMgdRAaxAVf works with recent GCCs but not 6.3>

00:57 <K-ballo> that's a 20 feature, isn't it?

00:58 <K-ballo> ptr.get()[i] I imagine, assuming that's good enough

01:03 <parsa> that doesn't work either: "invalid use of array with unspecified bounds"

01:05 <K-ballo> true, you'll have to go with double for element type

01:05 <K-ballo> sketchy

01:11 <hkaiser> parsa: use boost::shared_array<double>

01:11 <parsa> that worked. but it's deprecated

01:11 <parsa> boost::shared_array that is

01:13 <K-ballo> what is deprecated?

01:13 <K-ballo> ah, yeah, use boost::shared_ptr<double[]>, assuming

01:13 <K-ballo> ask glen on slack

15:04 <K-ballo> seeing 'hpx::iostreams::detail::release_ostream': inconsistent dll linkage warning on master

15:26 <hkaiser> K-ballo: ok, will take care of this, thanks

15:53 <hkaiser> K-ballo: how to reproduce this? compiling the core modules + hello_world does not expose this warning

15:54 <hkaiser> nvm, rebuilding helps ;-)

15:56 <hkaiser> ...fixed now

17:00 <jbjnr__> hkaiser: diehlpk_work daissgr - bad news rando lockups on startup on node counts of 256-512-1024 etc. Seems to be a boot time problem. No test code ever runs, never get any output. will look into bootup code this evening.

17:00 <jbjnr__> ^random

17:01 <jbjnr__> queue very full, hard to get nodes to test on :(

17:09 <hkaiser> jbjnr__: could be manifesting our hangs

17:21 <jbjnr__> hkaiser: what hangs are you referring to?

17:23 <hkaiser> jbjnr__: the hangs we see on CircleCI

17:23 <jbjnr__> these happen at start, I do not see any output from the main code. I will enable some debug logs in the bootstrapping and see if I can diagnose what's wrong - could it be the barrier? (Does BBB have one?)

17:23 <jbjnr__> do the circleci hangs happen on startup?

17:24 <hkaiser> I have the longstanding suspicion that the hangs we see happen during startup...

17:24 <jbjnr__> hmm

17:24 <jbjnr__> ^hmmmmm

17:24 <jbjnr__> :)

17:24 <hkaiser> :D

17:24 <jbjnr__> does any of th bootup code make use of the distributed barrier ?

17:25 <hkaiser> jbjnr__: startup uses a barrier, yes

17:25 <jbjnr__> I could swap it with my one ...

17:25 <hkaiser> didn't heller fix that?

17:25 <hkaiser> there was a PR yesterday

17:25 <jbjnr__> he cleaned up a memory leak but I'm not sure he changed the actual functionality

17:25 <hkaiser> he changed barrier

17:26 <hkaiser> keeping things alive longer...

17:26 <hkaiser> gtg

17:26 <jbjnr__> I'll try it out now

17:52 <nikunj> can anyone explain me this runtime error: hpx::init: exception caught: option '--hpx:console' does not take any arguments

17:53 <nikunj> I added a few commandline options and when I try to use them, HPX throws the above error

17:54 <nikunj> if I chose not to add explicit commandline value and let HPX chose the defaults I set, the output is as expected

17:55 <nikunj> https://pastebin.com/mYuPzhwz

18:03 <nikunj> found the issue, I wasn't writing commandline arguments correctly :/

18:10 <zao> :D

18:11 <jbjnr__> hkaiser: (just fyi merging the barrier fix does not seem to make any difference)

18:15 <hkaiser> jbjnr__: ok, good to know, thanks

21:10 <jbjnr__> heller: I am going to take a look at the barrier code tomorrow. if you see this, coould you please write a short explanation of what the steps it uses are so that I can go through it and see if there is a possibility of a hang. Thanks. I am a bit worried because I just had a quick look at barrier node and it is full of when_all's, vectors of futures, all sorts of other stuff and it's going to take me a bit of time to decipher

21:10 <jbjnr__> what's going on. No comments in the code to speak of.

21:10 <jbjnr__> goodnight all