00:10 <heller> hmm, did something on rostam went awfully wrong?

00:15 <heller> all release builds seem to go horribly wrong

00:19 <K-ballo> hkaiser: making those sfinae do make the error go away.. so I guess the question is who is attempting to instantiate them

00:25 <K-ballo> was the optional PR reverted? or did it just not include replacement for uses of boost::optional?

00:29 <heller> it did not include any replacements

00:32 <github> [hpx] sithhell force-pushed fix_action_move_semantics_regression from 9c661f7 to 6ea1947: https://git.io/vbYHx

00:32 <github> hpx/fix_action_move_semantics_regression 6ea1947 Thomas Heller: Fixing local direction function execution and lambda actions perfect forwarding

00:35 <heller> for some reasons, the papi counters fail, but only in release mode and on rostam

00:41 <heller> all other plugins seem to work

00:51 <heller> the only difference to my local setup is that I have papi 5.5 and rostam 5.2

01:00 <heller> Ok, this problem seems to be around since a while...

01:31 <hkaiser> heller: papi counters are dynamically loaded

01:31 <hkaiser> nobody links against them

09:56 <fane_faiz> Hey guys i am new here.

09:56 <fane_faiz> wanted some assistance.

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

10:07 <github> hpx/gh-pages cb664f3 StellarBot: Updating docs

10:23 <github> [hpx] taeguk opened pull request #3040: Fix a mistake about exception handling in asynchronous execution of scan_partitioner. (master...tg_fix_scan_partitioner_async) https://git.io/vbOTk

10:23 <taeguk> Excuse me, I have a question about hpx::future::has_exception.

10:26 <taeguk> When the task is running so the result is not available from hpx::future and I call hpx::future::has_exception, it returns 'false'.

10:27 <taeguk> Is this intended behavior?

10:28 <taeguk> I assumed that hpx::future::has_exception may internally wait for the result to be available. But my assumption was incorrect.

11:08 <fane_faiz> Hello guys i wanna contribute so how should i get started?

11:20 <taeguk> fane_faiz: As I think, at first, investigate and determine what you will improve or implement.

11:21 <fane_faiz> can you please elaborate?

11:38 <github> [hpx] sithhell closed pull request #3038: Fixing local direction function execution and lambda actions perfect forwarding (master...fix_action_move_semantics_regression) https://git.io/vbYVQ

13:32 <zao> fane_faiz: We don't have much in the way of prepared tasks for newcomers. Skim through the SoC suggestions maybe, or look at the issue tracker for things to look at.

13:32 <zao> fane_faiz: Whatever you do, it's probably a good idea to download and build HPX, to get a feeling for how to work with it.

13:32 <zao> It all really depends on what kind of person you are and what you're capable of doing.

13:33 <zao> If you're unsure what HPX actually does, the presentations at conferences made by contributors may also be of interest, to get a feeling for what HPX actually is.

14:29 <jbjnr> hkaiser: heller pull request are now being built at cscs http://cdash.cscs.ch/index.php?project=HPX - so far I have only added one machine/configuration, but my simple pything based github query tools can spawn as many builds an any machines as we like.

14:29 <jbjnr> ps. ignore the older ones with all fails, I submitted a bunch of bad ones earlier ...

14:45 <hkaiser> jbjnr: nice!

14:45 <hkaiser> jbjnr: btw, #3039 is what you need for your executor work

15:07 <zao> jbjnr: Nifty!

15:24 <heller> jbjnr: cool! Is there also a github status report for the PRs?

15:38 <jbjnr> hkaiser: heller currently I have a very simple python script that polls github every N seconds (60 default) and if a PR has changed, it triggers the build on a machine at cscs. It is version1 and is fire and forget, so I am not getting feedback from the builds that I can use to update the PR status, but I will add that stuff if this proves useful. I need to add several other things first.

15:39 <jbjnr> it spawns builds using ssh and a script - currently we have a sngle config per machie and all is done via cmake and python. nothing else - it is very trivial, easy to extend and maointain and I have tried it on 3 machines - daint, greina and my laptop

15:39 <hkaiser> jbjnr: nice

15:40 <jbjnr> the ssh spawns a slurm job (generated by cmake), so it will run anywhere, but daint can't send http out from compute nodes, so we need something extra for that one. I will work on that

15:48 <heller> jbjnr: I think that's very useful

15:52 <jbjnr> if someone needs to update a PR, then please do it now - I want to see if a new build is triggered correctly. So far I tested it using a force option - so I have not seen it happen in the wild

15:52 <jbjnr> also I need to trigger the PR's to rebuild if master changes. That's easy too

15:53 <jbjnr> I can do many build per PR, so far just one release build with my default settings, but I will add more.

15:54 <hkaiser> jbjnr: do you build the plain PR or the PR merged to master?

15:54 <jbjnr> PR merged to master

15:54 <hkaiser> nice

15:54 <zao> Do you people know what the refs/pull/ID/merge thing means?

15:55 <jbjnr> but only if the github PR status is "mergeable"

15:55 <heller> No

15:55 <zao> refs/pull/ID/head is the PR head itself, is the merge what you'd get if merged into master or something?

15:55 <heller> jbjnr: instead of polling, you might want to consider the github web hooks

15:55 <heller> zao: I think it's the code as proposed

15:56 <jbjnr> that would be nice, but then I need to open ports at CSCS to let stuff in and write an http server. the pygithub code is a few lines and so easy ....

15:56 <jbjnr> I have called it "Pycicle"

15:57 <jbjnr> Python Continuous Integration Command Line Engine

15:57 <jbjnr> :)

15:57 <heller> Yeah, polling is good enough, I guess

15:57 <jbjnr> it sleeps the rest of the ime

15:57 <heller> Nice name

15:57 <hkaiser> yah polling once every minute is fine

15:57 <zao> Ah, 'merge' seems to be a suggested merge result of merging the PR head into the master commit it's based on.

15:57 <jbjnr> I will create a PR with pycicle and see if a build is triggered

15:57 <zao> That's useful I guess.

15:57 <hkaiser> popsicle ;)

16:28 <github> [hpx] biddisco opened pull request #3042: PyCicle - first attempt at a build toold for checking PR's (master...pycicle) https://git.io/vbOC4

16:33 <hkaiser> jbjnr: I know you will think I'm just annoying, but could you add license and copyright to the new files, please?

16:35 <jbjnr> ok

16:35 <jbjnr> build was triggered ok

16:35 <hkaiser> :D

16:35 <jbjnr> and you are correct. you are annoying :)

16:36 <hkaiser> that's what I'm here for ;)

17:13 <zao> jbjnr: For running the builds and tests on the clusters, do you limit your jobs to one per node to avoid the port collisions?

17:13 <zao> Or have you altered the test running thingie to jiggle the ports around to try to counteract that?

17:14 <zao> (I run my single-node tests inside of a network-insulated singularity container)

17:20 <jbjnr> zao: no, I use slurm to submit a job to the nodes - so far, this works - but some kid of limit of <N could be enforced. The script is very very simple so far, but we can add more features. I'll send an email to the list with my plans ...

17:21 <jbjnr> on greina - it seems like 8 jobs run at a time without problem, more than that get queued - which is fine

20:16 <jbjnr> grrr... I don't know how to get the branch name from the PR on github

20:16 <jbjnr> I'd like to use it in the dashboard display

20:20 <jbjnr> ooh. pr.head.label - give it to me - awesome!

20:23 <zao> Ah, indeed.

22:47 <jbjnr> zao: I misunderstood your question - yes one test at a time on a given node - but slurm will give me N nodes, so I can test N PR's at once. The port collision I didn't test, but I know from past experience that running two tests on the same node will fail, so no parallel testing

22:49 <zao> Ah, peace of mind restored.

22:49 <zao> Was worrying I'd imagined everything :)