04:42 <weilewei> simbergm thanks, noted. I agreed with you that not to running tests before install. It is just giving module maintainer a hard time, and some tests occasionally fail

13:23 <tarzeau> simbergm: debian uses spellintian with this data https://sources.debian.org/src/lintian/2.45.0/data/spelling/, but i guess aspell -a < sometext will do as well

13:42 <simbergm> tarzeau: thanks for the link, I'll have a look at that

13:48 <jbjnr> well my new dataflow annotation works, but eh names come out as "@#$#$%^" and suchlike :(

14:02 <hkaiser> jbjnr: so it might not actually work ;-)

14:02 <jbjnr> correct

14:02 <hkaiser> jbjnr: btw, I know how to solve the mpi executor return type issue you mentioned the other day

14:02 <jbjnr> it works in the sense that annotations are being passed through dataflow, ut eh lifetime of the char * is probably suspect

14:02 <jbjnr> hkaiser: mpi ?? please go on

14:03 <jbjnr> use auto? or something more

14:03 <hkaiser> create functional wrappers for the mpi_xxx functions and specialize future_result_type for those

14:03 <hkaiser> or rewrite the executor infrastructure to use decltype(auto), that would work as well ;-)

14:04 <jbjnr> I don't want to write a wrapper for every mpi_xxx function, but a generic one that covers all, would be fine

14:04 <hkaiser> jbjnr: I feel you're overdoing with the annotations in dataflow, there has to be a simple solution

14:05 <hkaiser> works as well, but more involved, I guess

14:05 <hkaiser> why not create wrappers for all supported functions, it's just a handful...

14:05 <hkaiser> you don't want users to be able to use the synchronous mpi function with your async anyways

14:05 <jbjnr> my solution is simple, but it is just being a bit tricky. The char * is going out of scope it seems - my task names come from std::string that are generated o the fly

14:06 <hkaiser> well, yesterday you asked about is_callable - if that's what you're using it for I wouldn't call it 'simple'

14:06 <jbjnr> no, I gave up on that

14:06 <jbjnr> new method is simple

14:06 <hkaiser> good

14:07 <jbjnr> I create a dataflow_finalize type that is callable and specialize get_function_annotation for it

14:07 <hkaiser> k

14:08 <jbjnr> hkaiser: https://gist.github.com/biddisco/fb836bc5ce99cb8addc8d65a52e83372

14:08 <jbjnr> some strings are munged

14:09 <jbjnr> but I'm getting close. This version at leaset doesn't breakl al the fancy executors

14:09 <hkaiser> gtg, let's talk mpi later

15:31 <diehlpk_work> heller, Wer have a meeting with Rebecca tomorrow at 9 CST. Do you want to attend future meetings?

15:31 <diehlpk_work> So we could find a more suitable time for you

15:32 <heller> as you wish

15:38 <diehlpk_work> Yes, please attend the meeting, since you had some nice ideas

15:42 <diehlpk_work> heise online will announce uour release again in their weekly news letter

16:06 <heller> ok

16:06 <heller> I'll try to attend tomorrow

19:44 <diehlpk_work> jbjnr, Do you think you can get libfabric working again by January 24th?

19:44 <diehlpk_work> I intend to do the first runs for the SC20 by then?

22:48 <weilewei> hkaiser do you know why am I getting this error: https://gist.github.com/weilewei/b3e409d212f7609b0aed9ef5fbd6e733

22:48 <weilewei> nvcc fatal : Value 'c++17' is not defined for option 'std'

22:48 <weilewei> I am trying to build hpx tests with existing hpx

22:49 <hkaiser> well, you might to ask NVIdia why that is the case

22:49 <hkaiser> whether nvcc supports c++17 is outside of our control

22:49 <hkaiser> you might want to rebuild using c++14 as the target standard

22:50 <weilewei> ok let me try

22:53 <weilewei> ok, c++ error is gone after switching to hpx with c++14

22:53 <weilewei> [ 0%] Built target tests.unit.computeapi.host_[ 0%] Building NVCC (Device) object tests/unit/computeapi/cuda/CMakeFiles/for_loop_compute_test.dir/for_loop_compute_test_generated_for_loop_compute.cu.onvcc fatal : redefinition of argument 'default-stream'CMake Error at for_loop_compute_test_generated_for_loop_compute.cu.o.cmake:219 (message):