02:15 <jaafar> hkaiser: so my goal is ideally to use the executor already passed into the algorithm (I'm looking at exclusive_scan again) and launch some of the tasks with lower priority than others

02:16 <hkaiser> ahh

02:16 <jaafar> In particular it would be good for the first stage tasks, which are created using async_execute, to be scheduled at a lower priority than the final stage tasks

02:16 <hkaiser> since you don't know what executor youve got you might not be able to do that

02:16 <jaafar> it seems that could happen either by 1) using continuation stealing on those first stage tasks or 2) making them lower priority than the final stage tasks somehow

02:17 <jaafar> so I knew that I could use "with" to change the chunk size an executor used. I thought maybe it could work for priorities as well

02:17 <hkaiser> ahh, that might actually work

02:17 <hkaiser> let me look

02:18 <hkaiser> we started to build new executors using the execuotr proposal interface, there you could do that

02:20 <hkaiser> so no, .with() doesn't support priorities or launch modes, currently

02:20 <jaafar> If I could async_execute with continuation stealing it might work just as well

02:21 <jaafar> since the goal is to rate-limit the creation of stage 1 tasks

02:21 <hkaiser> let me think about this a bit

02:23 <jaafar> OK thank you

02:51 <diehlpk_work> k-ballo[m], I have a strange C++ error which starts by using gcc 8

02:51 <diehlpk_work> https://pastebin.com/QBVEJj3x

02:51 <diehlpk_work> Would you mind to have a look if times permit

10:55 <gonidelis[m]> ms[m]: yt?

10:55 <ms[m]> gonidelis[m]: hey, here

10:55 <gonidelis[m]> https://github.com/STEllAR-GROUP/hpx/commit/8ad717f07df36fd461ff965bb76b0ecad5539e8d#diff-b9c6ef1d4a6ea5d7a6ee75822c263ed5e0a4b81428099e86a2ea010d890a3729L396-L399

10:56 <gonidelis[m]> Why do we make the `policy` change here?

11:02 <ms[m]> gonidelis[m]: could you link directly to the file please? github isn't very good at showing lines in diffs...

11:02 <ms[m]> but the answer is most likely that it was unused

11:02 <ms[m]> if you need it for your pr feel free to uncomment/unremove it

11:03 <ms[m]> ah, found the highlight... yes, unused

11:18 <gonidelis[m]> ms[m]: sorry for being late

11:18 <gonidelis[m]> what do you mean used?

11:19 <ms[m]> gonidelis[m]: the parameter was not being used in the function body

11:20 <gonidelis[m]> ohhhh ok!!

11:20 <gonidelis[m]> I ll make sure to keep it this way

11:20 <gonidelis[m]> don't worry

11:20 <gonidelis[m]> thanks!

11:21 <K-ballo> diehlpk_work_: sounds like a bad comparator, how does it look?

11:24 <ms[m]> gonidelis[m]: np, you won't get your pr won't pass ci unless you keep it that way ;)

11:35 <gonidelis[m]> ms[m]: that for sure is an offer I can't refuse ;p

13:08 <gonidelis[m]> ms[m]: did your CI tests passed on the change I sent you above? There is incompatibility between `in_in_out_resul` and `tuple` return types

13:11 <gonidelis[m]> ms[m]: forget it. I forgot that I hadn't push my PR yet... lol

13:11 <gonidelis[m]> I live in my own branch

13:54 <gonidelis[m]> We use `result::get()` with `future`s, right?

14:04 <diehlpk_work_> K-ballo, https://github.com/peridigm/peridigm/blob/2a5785b4662ca0750436e74053fac7d8718fef6d/src/core/Peridigm_Enums.cpp#L160

14:04 <diehlpk_work_> It happens at this line

14:04 <diehlpk_work_> and I found this porting hint

14:04 <diehlpk_work_> https://gcc.gnu.org/gcc-8/porting_to.html

14:05 <K-ballo> so it is indeed a bad comparator?

14:05 <K-ballo> what's the comparator?

14:06 <diehlpk_work_> Yes, I think it is the default std::less

14:06 <K-ballo> the default std::less won't be broken.............

14:06 <K-ballo> std::map<std::string,Tensor_Order,std::string >

14:06 <K-ballo> std::string is not a comparator

14:07 <K-ballo> shouldn't that be std::map<Tensor_Order,std::string > anyways?

14:07 <K-ballo> ah no, std::map<std::string, Tensor_Order>

14:08 <diehlpk_work_> Yes, but for this one the default comparator would be std::less or?

14:08 <K-ballo> the default comparator is irrelevant as std::string is given as a comparator

14:09 <K-ballo> (but yes, it would be std::less<key>)

14:09 <K-ballo> std::map<std::string,Tensor_Order,std::string >

14:09 <K-ballo> Key = std::string

14:09 <K-ballo> Value = Tensor_Order

14:09 <K-ballo> Comparator = std::string

14:14 <diehlpk_work_> Ok, but so the std::string default comparator would be fishy or?

14:15 <K-ballo> std::string default comparator is not involved

14:16 <K-ballo> the dev made a mistake and provided std::string *itself* as a comparator

14:16 <K-ballo> std::string is not a comparator

14:16 <K-ballo> remove the comparator argument (`,std::string`) to fix

14:18 <hkaiser> alternatively, write std::less<std::string>

14:19 <diehlpk_work_> Ok, I think that I will go with the first

14:52 <gonidelis[m]> Could anyone help me with this error?

14:53 <gonidelis[m]> https://gist.github.com/gonidelis/a87373c4704612428e8cec574d629f61

14:53 <gonidelis[m]> https://github.com/gonidelis/hpx/tree/adapt_transform

14:54 <gonidelis[m]> what's wrong with `std::forward<T_>(t)`?

15:10 <K-ballo> link to the code that causes the error

15:10 <K-ballo> gonidelis[m]: file and line

15:14 <gonidelis[m]> I think it comes from that call

15:14 <gonidelis[m]> https://github.com/gonidelis/hpx/blob/095731f9875ea23d8e4af28cdececb48ef82cf6e/libs/full/segmented_algorithms/include/hpx/parallel/segmented_algorithms/transform.hpp#L298

15:15 <K-ballo> no, I mean link to the context for the error message

15:16 <gonidelis[m]> this line is mentioned in this error message

15:16 <gonidelis[m]> but

15:16 <gonidelis[m]> the error essentialy comes from

15:17 <gonidelis[m]> https://github.com/gonidelis/hpx/blob/095731f9875ea23d8e4af28cdececb48ef82cf6e/libs/parallelism/algorithms/include/hpx/parallel/util/detail/algorithm_result.hpp#L36

15:17 <gonidelis[m]> here

15:17 <gonidelis[m]> Do you mean I should link the test call that causes the error?

15:21 <gonidelis[m]> K-ballo:

15:23 <K-ballo> are the different iterator types expected to be convertible? looks fishy

15:29 <gonidelis[m]> K-ballo: partionioned_vector.begin() and partionioned_vector.end() ?

15:30 <K-ballo> local_raw_vector_iterator and local_vector_iterator,

15:50 <gonidelis[m]> i don't even know what's the difference

15:51 <K-ballo> I'd guess you shouldn't be mixing them then

15:52 <gonidelis[m]> there's a possibility that they pre- exist from The Test cases

15:53 <K-ballo> if they pre-existed then they would have already been convertible

15:54 <K-ballo> in_in_result and friends all have the same converting constructors tuple has

15:55 <K-ballo> > note: candidate template ignored: requirement 'std::is_convertible<const hpx::local_raw_vector_iterator<int, std::vector<int, std::allocator<int> >, __gnu_cxx::__normal_iterator<int *, std::vector<int, std::allocator<int> > > > &, hpx::local_vector_iterator<int, std::vector<int, std::allocator<int> > > &>::value' was not satisfied

15:56 <K-ballo> is that an lvalue ref?

15:56 <K-ballo> from const& to non-const&, that's your bug

15:57 <K-ballo> still smells fishy.. are those iterators convertible hkaiser?

15:58 <hkaiser> K-ballo: what iterators?

15:58 <K-ballo> local_raw_vector_iterator and local_vector_iterator

16:05 <K-ballo> gonidelis[m]: your conversion operators are wrong https://eel.is/c++draft/algorithms.results

16:06 <K-ballo> and I guess that means those iterators actually are convertible, fishy

16:31 <gonidelis[m]> hkaiser: meet?

16:32 <hkaiser> yes, sec

16:32 <gonidelis[m]> np

16:32 <hkaiser> K-ballo: what's wrong with those?

16:35 <gonidelis[m]> K-ballo: what is wrong with the conersion ops?

16:39 <K-ballo> those (the ones from the standard) are fine

16:39 <K-ballo> the ones we have don't match those

16:40 <gonidelis[m]> do you mean that is `I1 const&` while we write `const I1&`

16:40 <gonidelis[m]> ?

16:41 <K-ballo> that wouldn't change anything

16:44 <zao> gonidelis[m]: Just those "east-const" and "west-const" are different spellings for the same type, so no difference semantically.