10:13 <jakub_golinowski> M-ms, yt?

12:07 <github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/vhXms

12:07 <github> hpx/gh-pages c8a6876 StellarBot: Updating docs

13:12 <M-ms> jakub_golinowski: here

13:12 <M-ms> How did it go with openmp?

13:15 <hkaiser> K-ballo: yt?

13:27 <github> [hpx] hkaiser pushed 1 new commit to master: https://git.io/vhXnR

13:27 <github> hpx/master e6c543d Hartmut Kaiser: Disambiguate std::pow for MSVC, add missing header

13:44 <M-ms> hkaiser: sorry and thanks for ^

13:44 <hkaiser> M-ms: no worries

13:44 <hkaiser> I should have tested it before approving

13:59 <K-ballo> hkaiser: here

14:01 <heller> what do we think of p1055?

14:02 <hkaiser> K-ballo: if you have the time, I'd like to talk about your comment you posted yesterday

14:02 <K-ballo> sure

14:03 <hkaiser> could you elaborate why you think adding the value to the future might not be a good idea?

14:03 <hkaiser> heller: I don't understand what they have in mind

14:03 <heller> hkaiser: IIUC, eric is trying to be able to easily adapt executors into his ranges stuff

14:04 <heller> I find the proposed syntax a bit confusing

14:04 <K-ballo> because future<T> is assumed to be small in size, cheap to move, etc

14:04 <hkaiser> K-ballo: nod, I understand that

14:05 <K-ballo> and it is guaranteed to be nothrow on move, so T's that throw on move are immediately disqualified from stashing

14:05 <hkaiser> K-ballo: the plan was to allow the stashing for no-throw-move types only

14:05 <heller> hkaiser: I am also not sure about the deferred/lazy stuff they are proposing

14:06 <hkaiser> heller: if you understand what they want, would you be able to explain in 2 sentences?

14:06 <K-ballo> I'd restrict it further to only trivially copyable things, and try to forget about the size bump

14:06 <K-ballo> else suddenly returning a future could try to grab a lock!

14:06 <hkaiser> K-ballo: why only trivially copyable things? nothing would be copied after all

14:07 <K-ballo> because that guarantees no user defined code is executed during those moves

14:07 <K-ballo> nor during the destruction

14:07 <hkaiser> what about future<vector<T>>?

14:07 <hkaiser> or similar

14:08 <K-ballo> I most definitively wouldn't stash it, not for an hpx::future that already has associated expectatoins

14:08 <heller> hkaiser: I think the main motivation is to move away from the huge interfaces presented in P0443, and somehow manage the combinatorial explosion coming from mixing different concepts together. To that end, they tried to come up with an extensible solution

14:08 <hkaiser> heller: that I do understand

14:09 <hkaiser> K-ballo: ok - that would make it less useful, though

14:09 <heller> hkaiser: however, it breaks with everything we had so far. That is traditional async + future::then etc.

14:10 <heller> and kind of looks overly complicated

14:10 <heller> one example is callin this_thread::get(f) multiple times

14:11 <hkaiser> yah, everybody wants to get away from the concurrency ts, no idea why

14:11 <heller> which is a shift from "getting the value of the operation" to "submit the task and wait until it has been executed"

14:13 <heller> well, one advantage of the solution presented, is that one can have really lightweight future/promise pairs, potentially ones that don't even require synchronization

14:14 <heller> and allow composition for things requiring different synchronization mechanisms, without having to go through a shared state. In addition, this avoids defining the shared state alltogether

15:12 <jbjnr> hkaiser: yt?

15:13 <jbjnr> I'm puzzled by this https://gist.github.com/biddisco/3ce41e2c59856acb0e5297133355b9b9

15:35 <diehlpk_work> heller, yt?

15:50 <diehlpk_work> heller,

15:52 <diehlpk_work> hkaiser, yet?

15:55 <hkaiser> jbjnr: see https://stackoverflow.com/questions/35367816/hpx-minimal-two-node-example-set-up

15:55 <hkaiser> diehlpk_work: here

15:57 <diehlpk_work> hkaiser, see pm

16:00 <jbjnr> hkaiser: the reason I ask is because, the answer I posted does not work any more

16:00 <jbjnr> to that same stack overflow question

16:02 <zao> Does node1 seem to listen properly according to `lsof -i`?

16:02 <hkaiser> jbjnr: your gist does things differently from what's described in that answer

16:03 <hkaiser> jbjnr: all the ip addresses in your example are the same, this is not how it works

16:04 <jbjnr> it used to work - both nodes are on the same locality

16:04 <jbjnr> same machine I mean

16:05 <hkaiser> jbjnr: sure

16:05 <hkaiser> it will still work if you do it right

16:05 <hkaiser> the so answer describes it in detail

16:06 <hkaiser> jbjnr: in short --hpx:agas should point to the same ip address for all localities, --hpx:hpx should point to distinct addresses for each of the localities

16:06 <hkaiser> for locality zero, both should be the same

16:08 <jbjnr> my point is that the answer I posted used to work, but does not any more

16:09 <hkaiser> jbjnr: not true

16:09 <hkaiser> jbjnr: the gist you posted does not correspond to your answer

16:09 <jbjnr> it's the same

16:09 <hkaiser> it's not

16:10 <hkaiser> all ip addresses are the same in the gist while in the answer the addresses passed to --hpx:hpx are distinct

16:11 <jbjnr> ok, so I can't use that syntax when I'm on the same node. fair enough. sorry

16:11 <hkaiser> jbjnr: sure you can

16:11 <hkaiser> jbjnr: just make the ip addresses distinct by using different ports

16:11 <jbjnr> then it doesn't work anyway

16:11 <hkaiser> try it

16:12 <jbjnr> {what}: assertion 'pp ? pp->here() == pp->agas_locality(cfg) : true' failed: HPX(assertion_failure)

16:12 <hkaiser> show me the commands you just used, pls

16:12 <jbjnr> ok. I'm wrong

16:12 <jbjnr> sorry for time wasting.

16:12 <hkaiser> np

16:13 <jbjnr> other stuff is broken though

16:13 <jbjnr> {what}: unknown command line option(s): -l2: HPX(bad_parameter)

16:13 <jbjnr> you can't use the shortcut command line params any more. not sure if we removed all of them or not

16:16 <hkaiser> jbjnr: you can't use them anymore for applications that use hpx_main.hpp

16:17 <zao> I approve of not hogging all the command line arguments :)

16:26 <jbjnr> hkaiser: ok thanks

16:57 <diehlpk_work> Yeah, 6 out of 7 students passed the first evaluation

17:23 <zao> Nice.

17:35 <jbjnr> so did ibcds guy fail. that's a real shame.

17:35 <jbjnr> libcds^

17:38 <diehlpk_work> Yeah, it is not optimal

17:44 <jbjnr> hkaiser: also these command line options no longer work -Ihpx.parcel.boot=tcp -Ihpx.parcel.libfabric.enable=1

17:56 <heller> jbjnr: he's all over the place, just not with us :(

17:57 <heller> The only thing he did in the last few weeks was to run the test suite finding out that not every test passes (in libcds)

17:57 <heller> Wishing to replace stuff without saying what stuff was or showing any code

17:59 <K-ballo> :/

18:03 <diehlpk_work> Since 2016 we lost at least one student

18:03 <diehlpk_work> per year

18:06 <hkaiser> jbjnr: they do work, just don't use short options

18:06 <hkaiser> use --hpx:ini instead

18:10 <github> [hpx] hkaiser deleted ready_future at 6b9f8dc: https://git.io/vhXHw

19:15 <jbjnr> heller: or hkaiser when running two localities on the same node - they have the same ip addr. I'm getting parcel destination does not match locality which received the parcel ({0000000100000000, 0000000000000000}), ({0000000200000000, 0000000000000000}:({0000000200000000, 0000000000000000} because a parcel is going back to the same locality instead of the other one

19:15 <jbjnr> what do we do in the tcp PP to get around this?

19:18 <jbjnr> (the LF PP does not see the correct port numbers AFAICT)

19:21 <heller> jbjnr: we use different ports, yes. The lf address, iiuc, only compares the ip address

19:26 <heller> You can do a bytewise compare, or reinterpret cast the void pointer to a sockaddr_in struct