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/
hkaiser has quit [Quit: bye]
gentaco18 has joined #ste||ar
<gentaco18> Thanks! I've been thinking of watching the cscsch lecures on introduction to hpx and the C++ lectures on the stellar youtube channel. Can someone please confirm if those are good resources to begin with?
gentaco18 has quit [Quit: Connection closed]
<ms[m]> gonidelis[m]: they're the same mechanism, it's just that if you create a customization point based on tag_fallback, it'll first consider tag_invoke overloads, and only if there are no matching overloads will it consider tag_fallback_invoke overloads
<ms[m]> gentaco18: (if you're still around?) those are a good place to start! some of the content may be slightly outdated, but for the most part it's still accurate, and the high-level concepts haven't changed a bit
pedro_barbosa[m] has quit [*.net *.split]
tid_the_harveste has quit [*.net *.split]
klaus[m] has quit [*.net *.split]
jaafar has quit [*.net *.split]
<ms[m]> gonidelis[m]: note that hkaiser suggested the tag_invoke_fallback change as a straightforward change for srinivasyadav227 to try out, it might be nice to leave that for him/her
<ms[m]> not sure if your comment on the PR was before or after hkaiser suggested that...
<gonidelis[m]> ms[m]: oh I thought hkaiser suggested that srinivasyadav227 will get involved in the whole desegmentation process... my bad. ok i shall wait then ;)
<ms[m]> I might have misunderstood him as well :P but I think doing that before gsoc might be an unnecessarily big task...
<gonidelis[m]> yeah that sounds more sensible to me
pedro_barbosa[m] has joined #ste||ar
klaus[m] has joined #ste||ar
tid_the_harveste has joined #ste||ar
jaafar has joined #ste||ar
heller1 has quit [Ping timeout: 240 seconds]
mdiers[m] has quit [Ping timeout: 240 seconds]
vroni[m] has quit [Ping timeout: 240 seconds]
pedro_barbosa[m] has quit [Ping timeout: 258 seconds]
rori has quit [Ping timeout: 246 seconds]
srinivasyadav227 has quit [Ping timeout: 250 seconds]
tid_the_harveste has quit [Ping timeout: 258 seconds]
klaus[m] has quit [Ping timeout: 258 seconds]
gnikunj[m] has quit [Ping timeout: 268 seconds]
tiagofg[m] has quit [Ping timeout: 265 seconds]
k-ballo[m] has quit [Ping timeout: 265 seconds]
ms[m] has quit [Ping timeout: 265 seconds]
gonidelis[m] has quit [Ping timeout: 265 seconds]
tiagofg[m] has joined #ste||ar
rori has joined #ste||ar
klaus[m] has joined #ste||ar
srinivasyadav227 has joined #ste||ar
mdiers[m] has joined #ste||ar
ms[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
vroni[m] has joined #ste||ar
heller has joined #ste||ar
tid_the_harveste has joined #ste||ar
k-ballo[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
<gonidelis[m]> what happened?
wash[m] has quit [Remote host closed the connection]
wash[m] has joined #ste||ar
nanmiao111 has quit [Quit: Connection closed]
<gonidelis[m]> k-ballo: what's a borrowed iterator for?
<k-ballo[m]> for iterating
<k-ballo[m]> borrowed means it can survive the death of the range it comes from
<gonidelis[m]> in what cases is there the need for the iterator to survive the death of the range
<gonidelis[m]> k-ballo: ^^
<k-ballo[m]> i do not understand that question
<gonidelis[m]> why would one need for the iterators to survive the death of the range?
<gonidelis[m]> k-ballo: ^^
<k-ballo[m]> seems like the same question
<k-ballo[m]> it's not a matter of needing to, it just haooens
<k-ballo[m]> imagine you call find on a temporary string, the iterator returned will be dangling as the string owns its elements
<k-ballo[m]> calling find on a temporary string view, on the other hand, is safe because string view doesn't own the elements, it borrows them from elsewhere
nanmiao111 has joined #ste||ar
<k-ballo[m]> the idea is to reject the first unsafe call (st compile time) but allow the safe one
<k-ballo[m]> you could always just (unnecessarily) reject all find calls on temporaries, and then you wouldn't *need* to deal with borrowing ranges/iterators
<gonidelis[m]> the borrowed iters/ranges are used on the non-temporary calls, right?
<gonidelis[m]> k-ballo: ^^
<k-ballo[m]> what are the non-temporary calls?
hkaiser has joined #ste||ar
<gonidelis[m]> calls to non temporaries k-ballo
<k-ballo[m]> calls on non-temporary ranges?
<k-ballo[m]> borrowing is irrelevant there, as there won't be dangling
mdiers[m] has quit [Ping timeout: 240 seconds]
gnikunj[m] has quit [Ping timeout: 258 seconds]
gnikunj[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
<gonidelis[m]> srinivasyadav227: yt?
<gonidelis[m]> you there*
<gonidelis[m]> (abbreviations is part of the familiarization)
<gonidelis[m]> <k-ballo[m] "calling find on a temporary stri"> so the returned iterator in this case is borrowed from the beggining?
<gonidelis[m]> and that's why it's safe?
<gonidelis[m]> k-ballo:
<k-ballo[m]> the iterator isn't borrowed, the elements of the range are what's borrowed
<k-ballo[m]> string view doesn't own its chars, it borrows them
<k-ballo[m]> if string view dies, the chars will continue to exist
<k-ballo[m]> a "borrowed iterator" is an iterator over a borrowed range, one that doesn't own its elements
<k-ballo[m]> or "borrows" them
<k-ballo[m]> it uses stuff that belongs to someone else
gonidelis[m] has quit [Ping timeout: 244 seconds]
srinivasyadav227 has quit [Ping timeout: 244 seconds]
tid_the_harveste has quit [Ping timeout: 244 seconds]
gnikunj[m] has quit [Ping timeout: 244 seconds]
gonidelis[m] has joined #ste||ar
<gonidelis[m]> hkaiser: is this https://github.com/STEllAR-GROUP/hpx/blob/ab865a7781c24674581cf8c299b63f1bb3e9bdca/libs/parallelism/algorithms/include/hpx/parallel/algorithms/for_each.hpp#L637-L638 the same with `hpx::parallel::util::detail::algorithm_result<ExPolicy, void>::type`
<gonidelis[m]> ?
gnikunj[m] has joined #ste||ar
srinivasyadav227 has joined #ste||ar
<hkaiser> yes, the second argument defaults to void
<gonidelis[m]> but since this thing `hpx::parallel::v1::detail::for_each<FwdIter>().call(...)` returns an iterator
<gonidelis[m]> why don't we get `return-statement with a value, in function returning 'void'`?
<gonidelis[m]> hkaiser: i see
<hkaiser> unused_type can be constructed from any other type
<gonidelis[m]> ohhh.... wow
<hkaiser> algorithm_result<ExPolicy>::get(...) 'swallows' all values
<gonidelis[m]> so it's like you have overloads for every case
<hkaiser> yes
<gonidelis[m]> ok i get it... the only thing is: why did you create unused_type in the first place?
<gonidelis[m]> is it a wildcard or sth?
<hkaiser> yes
<gonidelis[m]> hm.... sounds like anarchy
<hkaiser> originally it was introduced for (remote) actions, we ran into trouble if those returned void, so we let them return unused_type instead
<hkaiser> later we discovered it's useful for many other things as well
<gonidelis[m]> interesting
tid_the_harveste has joined #ste||ar
<diehlpk_work> gnikunj[m], gonidelis[m] Can yoo please add your list to the wiki?
<gonidelis[m]> where?
<gonidelis[m]> exactly
<diehlpk_work> gonidelis[m], Give me as sec
<diehlpk_work> gonidelis[m], I would say above the requirement section
<hkaiser> I'd suggest to put it right before the project ideas section
<diehlpk_work> +1
<gonidelis[m]> diehlpk_work: how did you tag nikunj? he is not indicated online to me
<gonidelis[m]> i need his bullets
<gonidelis[m]> i only have mine
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
<diehlpk_work> gonidelis[m], He is only on my irc client, not sure what is going on with yours ;)
<gonidelis[m]> i am not suere either
<diehlpk_work> gonidelis[m], Add yours first
<gonidelis[m]> k
<diehlpk_work> gnikunj[m], Can add them later, anyways they will not start today to review the proposals
<gonidelis[m]> stop tagging him... i am jealus
<gonidelis[m]> jealous^^
<gnikunj[m]> gonidelis[m] diehlpk_work I went through the points mentioned. I don't think there's anything other than the point I mentioned.
<gonidelis[m]> gnikunj[m]: ok i have already added mine, feel free to put your in there too ;)
<gonidelis[m]> yours^^
<gnikunj[m]> Will do
<hkaiser> gonidelis[m]: thanks for adding the list to the wiki, sounds great!
<gonidelis[m]> hkaiser: i would appreciate better english on that
<gonidelis[m]> i don't know
<hkaiser> gonidelis[m]: working on it
<hkaiser> gonidelis[m]: please have a look, I made some changes - please complain if you don't like them
<gonidelis[m]> hkaiser: it's great
<gonidelis[m]> i would buy whatever is we are selling...
<gonidelis[m]> hkaiser: so do we just use `parallel::util::detail::algorithm_result<ExPolicy>::get()` when returning void?
<hkaiser> gonidelis[m]: yes, or future<void>
<gnikunj[m]> hkaiser: gonidelis[m] diehlpk_work I updated the page to have a stepwise approach and added 2 of my points to the list. Please go through it. Apologies for the delay.
<hkaiser> gnikunj[m]: thanks
<hkaiser> sounds great
<gonidelis[m]> gnikunj[m]: great ;)
<gnikunj[m]> :D
parsa has joined #ste||ar
hkaiser has quit [Quit: bye]
<diehlpk_work> gonidelis[m], gnikunj[m] Thanks, it reads good. Fingers crossed we get accepted again this year.
<gonidelis[m]> diehlpk_work: we will
hkaiser has joined #ste||ar