09:55 <srinivasyadav227> any reasons why at some places std::pair or tuple is used and in some other places util::in_out_result is used for returing results in util/transform_loop.hpp?

10:16 <gonidelis[m]> freenode_srinivasyadav227[m]: we adapt std::pair to `in_out_result` and std::tuple to `in_in_out_result`

10:17 <gonidelis[m]> check the C++20 standard

10:17 <srinivasyadav227> so everything should be now in_out_result and in_in_out_result right?

10:52 <gonidelis[m]> srinivasyadav227: i don't know if all pairs have turned into in_out_results

10:53 <gonidelis[m]> you can check here for sure

10:53 <gonidelis[m]> http://eel.is/c++draft/

10:57 <srinivasyadav227> okay ;)

11:53 <gonidelis[m]> K-ballo:

11:54 <gonidelis[m]> Does that https://ericniebler.github.io/range-v3/#autotoc_md7 mean that I can use `views::filter | some_mutating_view` ?

11:55 <gonidelis[m]> actually, what does "invalidating iterators or sentinel" mean?

11:55 <gonidelis[m]> is it equivalent to "mutating the range"?

12:58 <K-ballo> gonidelis[m]: no, it's not equivalent, iterator invalidation is its own thing

12:58 <K-ballo> container give invalidation guarantees for all their operations

12:58 <K-ballo> you can only do those operations that will not invalidate the iterators (but may invalidate the elements themselves, or even references)

14:24 <gnikunj[m]> hkaiser: just realized I have induction session today in 5min. I'll join in the meeting once I get done with the induction.

14:25 <srinivasyadav227> hkaiser: can you explain this line https://github.com/STEllAR-GROUP/hpx/blob/fixing_datapar/libs/parallelism/algorithms/include/hpx/parallel/datapar/iterator_helpers.hpp#L218 ?

14:26 <hkaiser> gnikunj[m]: yes

14:26 <srinivasyadav227> and this one https://github.com/STEllAR-GROUP/hpx/blob/fixing_datapar/libs/parallelism/algorithms/include/hpx/parallel/datapar/iterator_helpers.hpp#L331, i am not clear whats actually happening here

14:32 <K-ballo> 218 is just `f(&tmp)`

14:32 <K-ballo> 331 too

14:33 <K-ballo> srinivasyadav227: the formal INVOKE definition is here https://en.cppreference.com/w/cpp/utility/functional/invoke, but you can just imagine it as a plain function call

14:33 <srinivasyadav227> tmp is a Vc::vector type, so is it like calling operator() on Vc::vector?

14:34 <K-ballo> no, on f

14:34 <K-ballo> `f(&tmp)`

14:34 <srinivasyadav227> ok, got it

14:37 <K-ballo> > Otherwise, INVOKE(f, t1, t2, ..., tN) is equivalent to f(t1, t2, ..., tN)

14:38 <srinivasyadav227> oh ok, its like plain function call, got it, but why are we passing &tmp instead of tmp

15:01 <mdiers[m]> hkaiser: Have you already looked at 5117? My last example also crashes on our older nodes from 2012. I just can't narrow it down any further.

15:01 <hkaiser> mdiers[m]: not yet, sorry

15:02 <hkaiser> srinivasyadav227: because 'f' expects a pointer?

15:03 <mdiers[m]> hkaiser: Too bad, but I can understand it. You have enough other things.

15:04 <srinivasyadav227> hkaiser: no f is this function object https://github.com/STEllAR-GROUP/hpx/blob/fixing_datapar/libs/parallelism/algorithms/tests/unit/algorithms/transform_tests.hpp#L22-L29

15:04 <hkaiser> mdiers[m]: I was away for two weeks and now I have to catch up with things

15:08 <mdiers[m]> hkaiser: No problem. I was also busy with other things in the last weeks ;-)

15:09 <hkaiser> srinivasyadav227: but things do compile, yes?

15:10 <srinivasyadav227> previously yes, with out transform_loop_ind

15:11 <hkaiser> well, _ind doesn't expect for 'f' to do the dereference, so this needs to be adapted

15:12 <srinivasyadav227> yes, so it should be changed in traits?

15:13 <hkaiser> well, whatever it takes

15:13 <srinivasyadav227> ok

15:14 <hkaiser> I don't know if the compiler optimization would affect the datapar parts in similar ways

15:18 <srinivasyadav227> yes, but existing datapar dont work now as f expects dereferenced value

15:50 <hkaiser> srinivasyadav227: it should be analogous to the non-datapar case, the difference is where the dereference happens

15:51 <srinivasyadav227> hkaiser: yes, i got it just now ;-)

17:39 <pedro_barbosa[m]> diehlpk_work: I was using the examples on the HXPCL repository to try out some stuff and while I was attempting to change the kernel from the /hpxcl-master/examples/cuda/example_kernel.cu, nothing was happening, so I decided to delete the file and the build_kernel_from_file program still works despite the kernel file missing, am I missing something here?

17:48 <diehlpk_work> pedro_barbosa[m], I am at the colloqium and I will double checl later

17:48 <pedro_barbosa[m]> Ok, thank you

19:54 <diehlpk_work> pedro_barbosa[m], In which folder are you executing the example?

20:12 <diehlpk_work> pedro_barbosa[m], There are few things:

20:13 <diehlpk_work> 1) if you change the file https://github.com/STEllAR-GROUP/hpxcl/tree/master/examples/cuda/example_kernel.cu and just run the example, it will not ce updated in

20:13 <diehlpk_work> in the build folder

20:14 <diehlpk_work> So you have to run cmake again or edit the example in the build folder as well

20:14 <diehlpk_work> So it might could have happend that you still compiled the old file

20:18 <diehlpk_work> 2) Be ware with the kernel names and the NVRTC compiler

20:19 <diehlpk_work> It can happen that there is still a kernel with the same name around.

20:20 <pedro_barbosa[m]> Oh I was only running the makefile, not building itagain

20:20 <diehlpk_work> I changed the name of the two kernels in the examples

20:20 <diehlpk_work> Ok, the cmake copies the example.cu from the src to the build folder

20:20 <pedro_barbosa[m]> Is there a way to run cmake only for the examples?

20:21 <diehlpk_work> I think the easiest would be if you just edit the cu file in the build folder

20:22 <pedro_barbosa[m]> and if I edit it there it should work?

20:24 <diehlpk_work> At least you would compile the correct file

20:24 <diehlpk_work> I experienced that you should rename the kernel, if you experience issues

20:25 <diehlpk_work> the kernel's name is sum and the nrvtc compiler keeps compiled files

20:26 <diehlpk_work> So if you compile again a kernel with the same name, but the body changed it is might not compiled again

20:32 <pedro_barbosa[m]> Ok got it, edited both kernel files from the /hpxcl-master/build/examples/cuda and /hpxcl-master/examples/cuda

20:32 <pedro_barbosa[m]> folders compiled and it worked

20:33 <diehlpk_work> Good

20:33 <pedro_barbosa[m]> also, I only had to change the kernels and run the program, didn't have to compile for it to work

20:39 <pedro_barbosa[m]> also, I have a doubt on the example itself (https://github.com/STEllAR-GROUP/hpxcl/blob/master/examples/cuda/build_kernel_from_file.cpp) on the line 78 shouldn't it be n[0]=SIZE; instead of result[0]=SIZE;?