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/
bita has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has quit [Ping timeout: 258 seconds]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 264 seconds]
K-ballo1 is now known as K-ballo
bita has joined #ste||ar
bita has quit [Read error: Connection reset by peer]
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
wash[m] has quit [Ping timeout: 265 seconds]
wash[m] has joined #ste||ar
<hkaiser>
ms[m]: how do you prepare the release? on a separate branch? or do you just use master for this?
<ms[m]>
hkaiser: release branch
<hkaiser>
can we start merging post release PRs?
<hkaiser>
or would you like to avoid this?
<ms[m]>
we can definitely if it helps you
<ms[m]>
I wanted to do rc2 with the prs currently marked as 1.6.0 but after that we can start merging other things
<ms[m]>
I can cherry pick if something else comes in later
<hkaiser>
ok, cool
<hkaiser>
thanks
<ms[m]>
do you have anything against merging the three remaining prs, or would you still like to have a look?
<hkaiser>
which ones?
<ms[m]>
it's the C++20 builder, annotations, and the cuda/hip flags
<ms[m]>
sec, I'll give you a link
<hkaiser>
the c++20 builder is fine, the annotations I need to look, the cuda/hip is your baby
<hkaiser>
gtg now, sorry
<ms[m]>
no worries, thanks!
hkaiser has quit [Quit: bye]
<gonidelis[m]>
why is `remove_copy_if` has the word `remove` in it since it does not remove anything?
<zao>
Great historical reasons, that one.
<zao>
The non-copy ones removes elements from a range by compacting the elements to keep, leaving a tail of objects that need to be erase:d away.
<zao>
That is, the typical use is `x.erase(std::remove_if(x.begin(), x.end(), pred), x.end());`
<gonidelis[m]>
What's x.erase ?
<zao>
remove_copy_if logically does the same "compact away the elements you don't want" operation, but happens to put them at a separate output iterator.
<gonidelis[m]>
The non-copy ones are the remove and remove_if
<zao>
Assuming x is a vector here, x.erase(from, to) removes the elements in that iterator range.
<zao>
After remove, you just have all the elements you want to keep bunched up at the front of the range, and the garbage towards the end. remove returns an iterator to where the new end should be.
<zao>
remove can't actually do anything about the container, as all it knows about is the iterator range, no container.
<gonidelis[m]>
zao: so it first copies and then removes the elements? so the result is sth like copy_all_elements_that_dont_specify_the_criteria?
<gonidelis[m]>
satisfy^^
<zao>
`remove[_if]` compacts the elements to keep of an iterator range towards the front of the range and returns the end of it.
<zao>
`remove_copy[_if]` puts copies of the desirable elements of an iterator range into an output iterator.
<zao>
Both result in having a range of desirable elements, the former in-place in the original place, and the latter as copies in another place.
<zao>
For the former, you typically want to cut the container down to size, for the latter you probably don't have to.
<gonidelis[m]>
οηηηη οκ
<gonidelis[m]>
ohhh ok ^^
<gonidelis[m]>
got it :)
<gonidelis[m]>
thanks!
hkaiser has joined #ste||ar
<gnikunj[m]>
what is the meaning of `constexpr auto const&` and how is it different to `constexpr auto&`?
<gnikunj[m]>
gonidelis[m]: I understood the idea behind 2-step process and I wrote a basic prototype based on it that works, but I don't get the use of constexpr auto const&
<gnikunj[m]>
the program compiles just fine without the `const&` part so what extra is it providing?
<hkaiser>
gnikunj[m]: yes, that was before he came up with CPOs as we use them today
<k-ballo[m]>
const ref vs deduced potentially mutable ref
<gnikunj[m]>
hkaiser: right, I was looking to the evolution of CPOs as we today and it was the first paper I could find.
<gnikunj[m]>
k-ballo[m]: so it is to avoid mutable types to be passed into T?
<k-ballo[m]>
what is T?
<gnikunj[m]>
the type passed to the function object later down the road
<k-ballo[m]>
`auto const&` is a const reference, `auto&` is either mutable or const depending on initializer
<gnikunj[m]>
aah, so we're guaranteeing it to be a const from the beginning.
<k-ballo[m]>
the constness of the referred object shouldn't affect arguments
<gnikunj[m]>
yeah, that'
<gnikunj[m]>
*yeah, that's what I was thinking myself
<gnikunj[m]>
could anyone provide me the link to the modern CPOs paper? the one we have in HPX