K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [*.net *.split]
hkaiser has quit [*.net *.split]
k-ballo[m] has quit [*.net *.split]
beauty2 has quit [*.net *.split]
bita has quit [*.net *.split]
diehlpk_work has quit [*.net *.split]
wash[m] has quit [*.net *.split]
zao has quit [*.net *.split]
jpinto[m] has quit [*.net *.split]
k-ballo[m] has joined #ste||ar
beauty2 has joined #ste||ar
bita has joined #ste||ar
wash[m] has joined #ste||ar
zao has joined #ste||ar
diehlpk_work has joined #ste||ar
jpinto[m] has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
jpinto[m] has quit [Ping timeout: 240 seconds]
ms[m] has quit [Ping timeout: 246 seconds]
teonnik has quit [Ping timeout: 258 seconds]
tiagofg[m] has quit [Ping timeout: 258 seconds]
klaus[m] has quit [Ping timeout: 246 seconds]
gnikunj[m] has quit [Ping timeout: 260 seconds]
rori has quit [Ping timeout: 268 seconds]
pedro_barbosa[m] has quit [Ping timeout: 268 seconds]
heller1 has quit [Ping timeout: 260 seconds]
k-ballo[m] has quit [Ping timeout: 264 seconds]
gonidelis[m] has quit [Ping timeout: 268 seconds]
jpinto[m] has joined #ste||ar
tiagofg[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
heller1 has joined #ste||ar
teonnik has joined #ste||ar
gnikunj[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
k-ballo[m] has quit [Ping timeout: 258 seconds]
tiagofg[m] has quit [Ping timeout: 240 seconds]
heller1 has quit [Ping timeout: 260 seconds]
teonnik has quit [Ping timeout: 260 seconds]
pedro_barbosa[m] has quit [Ping timeout: 260 seconds]
gnikunj[m] has quit [Ping timeout: 240 seconds]
jpinto[m] has quit [Ping timeout: 258 seconds]
gonidelis[m] has quit [Ping timeout: 260 seconds]
heller1 has joined #ste||ar
tiagofg[m] has joined #ste||ar
klaus[m] has joined #ste||ar
rori has joined #ste||ar
jpinto[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
ms[m] has joined #ste||ar
teonnik has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<diehlpk_work> ms[m], Is there any plan for the 1.6 release?
<diehlpk_work> Asking if it will get into the next fedora release or not
<hkaiser> diehlpk_work: what would be the deadline to get into the next fedora release?
<diehlpk_work> hkaiser, Having it end of Feb in the Federo repo would be easy
<diehlpk_work> After that it need to go through the review process
<ms[m]> diehlpk_work: asap, but some ci issues need to be fixed first
<hkaiser> diehlpk_work: end of Feb sounds realistic
<ms[m]> hkaiser: have you seen/heard from akheir lately? I'm waiting for some instructions from him before I go and mess everything up on rostam... (last time my emails apparently went to spam so he might need a poke)
<hkaiser> I'll poke him
<hkaiser> he was very busy with the cooling problems
<ms[m]> hkaiser: thanks!
<pedro_barbosa[m]> Hey guys, I've been trying to fix this example https://github.com/STEllAR-GROUP/tutorials/blob/master/examples/00_exercises/solution9.cpp but I've been having some trouble, can someone give me an hand with it?
<hkaiser> pedro_barbosa[m]: what's wrong with that example
<pedro_barbosa[m]> I believe it is outdated and doesn't compile, it still uses "hpx::compute::cuda" instead of "hpx::cuda::experimental" which I believe is the correct one
<hkaiser> do you think you can fix it?
<pedro_barbosa[m]> Not really, I'm still learning about HPX , I've given it a try for the past few days but wasn't able to make much progress
<hkaiser> ok
<hkaiser> diehlpk_work: yt?
<diehlpk_work> hkaiser, Meeting
<hkaiser> ok
<diehlpk_work> hkaiser, I am free
<hkaiser> diehlpk_work: see pm, pls
<diehlpk_work> hkaiser, please send it again
<weilewei> hkaiser meeting now for DCA
<gonidelis[m]> K-ballo:
<gonidelis[m]> hkaiser:
<gonidelis[m]> why don't we use here `range_sentinel` here /
<gonidelis[m]> ?
<gonidelis[m]> #L63 too
<hkaiser> excellent catch, I believe - this looks like a bug
<gonidelis[m]> hkaiser: so, this error would have kicked in, in case we used this particular trait in an `iterator - sentinel_value` type of `range` ? But since we are mainly testing just vectors (until now) for the ranges part, we have not encountered any issues yet?
<gonidelis[m]> Is that right?
<hkaiser> correct
<gonidelis[m]> hmm...
<gonidelis[m]> ok I will look into it just to verify that it is a bug indeed...
<hkaiser> try constructing a test that triggers this
<gonidelis[m]> ok. sounds cogent.
weilewei has quit [Quit: Connection closed]
<gonidelis[m]> hkaiser: yt?
<hkaiser> gonidelis[m]: here now
<gonidelis[m]> hkaiser: ok so here is the thing: i am trying to think of a workaround for the ranges test since the return value is not an iterator anymore but rather a "subrange"
<gonidelis[m]> first of all, is std::remove_if rendered useless in the ranges test case?
<gonidelis[m]> since it can only provide us with the past the end iterator (which i believe is the begin iterator of the subrange)
<hkaiser> gonidelis[m]: not sure what you mean
<gonidelis[m]> in this test that i linked, we were testing the validity of `hpx::remove_if` by utilizing `std::remove_if`
<gonidelis[m]> but since I want to check the validity of `hpx::ranges::remove_if` which has a completely different return type I don't have a `std` "ground truth" to compare
<gonidelis[m]> in other words there is not standard counterpart for `hpx::ranges::remove_if`, except if I can actually use `std::ranges::remove_if` but I can't, right?
<hkaiser> gonidelis[m]: the iterator returned from the std algorithm should be the same as the begin(r) return from the hpx algorithm, no?
<gonidelis[m]> hkaiser: yeah exactly! so that's just a boundary case which we can check. but what about the remaining part of the returned subrange?
gnikunj[m] has quit [Ping timeout: 246 seconds]
ms[m] has quit [Ping timeout: 246 seconds]
<hkaiser> gonidelis[m]: the remaining part is invalid anyways as the elements have been moved away
<hkaiser> not moved away and not invalid, but the remaining part will hold all those elements that have been 'removed'
<hkaiser> you could compare the length of the result sequences and make sure that the elements in the remaining part do not satisfy the removal criteria
<hkaiser> sorry - they have to satisfy the removal criteria
<gonidelis[m]> hkaiser: hmmm ok... yeah that sounds about right.
<gonidelis[m]> ok i will do that...
hkaiser has quit [Read error: Connection reset by peer]
<gonidelis[m]> K-ballo: can this be dereferenced ?
<k-ballo[m]> dereference a range..?
hkaiser has joined #ste||ar
gnikunj[m] has joined #ste||ar
<gonidelis[m]> i meant this k-ballo
<gonidelis[m]> sorry
<gonidelis[m]> i want to dereference the itarator of the range
<k-ballo[m]> the iterator can be dereferenced if it is dereferenceable..... what's the underlying question?
<gonidelis[m]> so it depends on what iterator i use to construct this range
<gonidelis[m]> what underlying question?
<gonidelis[m]> k-ballo: that thing is that `hpx::ranges::remove_if` returns an `iterator_range`
<gonidelis[m]> so I want to get the iterator of that returned range
<k-ballo[m]> i don't think you are making the right question, the question as it stands is meaningless
<hkaiser> gonidelis[m]: use b = begin(r) and e = end(r) and if b != e, then b is deferenceble
<k-ballo[m]> what would stop you from getting the iterator? and how is it related to dereferencing?
<gonidelis[m]> hkaiser: in the test?
<hkaiser> gonidelis[m]: everywhere
<gonidelis[m]> hkaiser: nod
ms[m] has joined #ste||ar
<gonidelis[m]> k-ballo: did you read our test conversation above? we just want to check whether the start of the resulting range from the hpx algo is the same as the resulting iterator of the std algo
<k-ballo[m]> i don't know how to get from there to dereferencing
<k-ballo[m]> you don't need to dereference iterators to compare them
<gonidelis[m]> k-ballo: i thought that comparing those two would require dereferencing
jaafar_ has joined #ste||ar
<gonidelis[m]> from what you are saying i guess it does not
<gonidelis[m]> cool
<gonidelis[m]> ok
<gonidelis[m]> i can't compare it to an iterator either, though ;p
rori has quit [Ping timeout: 268 seconds]
<k-ballo[m]> ... it *is* an iterator
<gonidelis[m]> (without the dereferencing part)
<k-ballo[m]> what does "dereferencing" mean to you?
<gonidelis[m]> k-ballo: with another iterator
<gonidelis[m]> k-ballo: getting the contents of the pointer
<k-ballo[m]> and how is that relevant to comparing iterators?
<gonidelis[m]> k-ballo: yeah it is not. I got that part. that was my mistake
<k-ballo[m]> you can't compare the values of the remove_if subrange, so you should never need dereferencing
<gonidelis[m]> k-ballo: what do i compare when we say "compare the begin iterator of the subrange to the resulting iterator of the std::remove"?
<k-ballo[m]> the begin iterator of the subrange, and the resu...
pedro_barbosa[m] has quit [Ping timeout: 260 seconds]
jaafar has quit [Ping timeout: 268 seconds]
<k-ballo[m]> comparing iterators is it1 == it2
<gonidelis[m]> ok... and with your impl in iterator_range, i just do result.begin() == std::remove_if ?
<k-ballo[m]> the iterator_range implementation is irrelevant
<gonidelis[m]> it's the return type of `hpx::ranges:remove_if`
<k-ballo[m]> i don't know about what you are actually trying to do with it, or what the existing tests already do
<k-ballo[m]> remove is a mutating algorithm, not sure how it's making comparisons across different containers
<gonidelis[m]> k-ballo: do you have a minute to straight this through a call or sth?
<k-ballo[m]> no
<gonidelis[m]> k-ballo: i am applying both `hpx::ranges::remove_if` and `std::remove_if` to the same container
<gonidelis[m]> (i make a copy first and then i pass it to `std::remove_if` actually)
<k-ballo[m]> you cant compare iterators from different containers
<gonidelis[m]> and thus i am comparing the begin iter of the first to the resulting iter of the latter
<k-ballo[m]> UB
<k-ballo[m]> besides, if it weren't UB it would always be false
<gonidelis[m]> hm...
<k-ballo[m]> i can't make sense of the scenario, and don't have the code to look at to try and decypher it
<gonidelis[m]> sec
<gonidelis[m]> just replace hpx::parallel::remove_if with the ranges impl which returns an iterator_range future
<gonidelis[m]> k-ballo: ^^
<k-ballo[m]> im on a phone, can't read code
<gonidelis[m]> k-ballo: oh ok... thanks anywyas
rori has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
<K-ballo> that's neither comparing iterators, nor dereferencing the returned subrange
<K-ballo> that's just comparing the non-removed elements from each container
<K-ballo> I don't see what the problem could be to adjust that to ranges
<K-ballo> gonidelis[m]: once you understand what the tests are actually testing, it should be trivial
<gonidelis[m]> K-ballo yeah but the ranges overloads return a subrange that includes all the removed elements
<gonidelis[m]> Which is different from the std overloads
<k-ballo[m]> it returns *more* information
<k-ballo[m]> because when using sentinels the end iterator isn't necessarily known by the caller
<gonidelis[m]> Hmm... so 1. I cannot check whether that extra info is correct
<k-ballo[m]> the extra info is trivial to check
<k-ballo[m]> it is the end iterator
<gonidelis[m]> Yup Hartmut already suggested a way
<gonidelis[m]> Just check whether they apply to the removed condition
<k-ballo[m]> mh?
<gonidelis[m]> And 2. How could I access with our `iterator_range` the non removed elements of a vector c
<gonidelis[m]> To the removal condition^^
<k-ballo[m]> there's nothing special about `iterator_range`
<gonidelis[m]> It's different from the original vector
<k-ballo[m]> it's the partition iterator the other overloads return, plus the end iterator
<gonidelis[m]> I have my start at the original vector and my end on iterator_range
<k-ballo[m]> and where's the problem?
<k-ballo[m]> iterator_range isnt a container
<gonidelis[m]> k-ballo it isn't ?
<k-ballo[m]> no, it's only a range