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/
diehlpk_work has quit [Ping timeout: 264 seconds]
diehlpk_work has joined #ste||ar
hkaiser has quit [Quit: bye]
akheir has quit [Remote host closed the connection]
bita has quit [Ping timeout: 272 seconds]
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 264 seconds]
Vir has quit [Ping timeout: 258 seconds]
Vir has joined #ste||ar
<gonidelis[m]>
What's the difference between `std::end(vector)` and `iterator(std::end(vector))`
<gonidelis[m]>
when `typedef test::test_iterator<base_iterator, IteratorTag> iterator`
<gonidelis[m]>
?
<gonidelis[m]>
ms[m]: yt???
<zao>
Not sure about the call site you’re at but it has different abilities to use explicit copy-constructors for example.
<gonidelis[m]>
zao: hmm... I am just thinking of a way to test my sentinel use case here
<gonidelis[m]>
and I am searching for pre-existing sentinel tests
<ms[m]>
freenode_gonidelis[m]: that wrapper iterator type is just meant to help testing the algorithms with different iterator categories
<ms[m]>
actual user code would probably never use something like that
<gonidelis[m]>
ok cool
<gonidelis[m]>
ms[m]: actually I pinged you because you are involved in the algorithm adaptation
<gonidelis[m]>
and I wanted to ask whether you have created any tests that check the begin_iterator, sentinel case for the ranges
<gonidelis[m]>
just to get an idea
<ms[m]>
actually I don't think so, nothing where the sentinel would be a different type than the begin iterator
<ms[m]>
that's probably something we might need to add to many of the tests
<gonidelis[m]>
uhh ok... I was thinking of adding that in my current `transform` adaptation but since it does not exist anywhere else I will try to do it on my own
<gonidelis[m]>
ms[m]: or should I leave it to be done as an all-in-one pr?
<ms[m]>
please do at least add tests for the `hpx::range::transform` overloads with both begin and sent being the same type
<K-ballo>
testing an archetypical sentinel (or sized sentinel) ought to be enough for most tests, no need to repeat those tests for end iterators
<gonidelis[m]>
ms[m]: yeah of course I already have tests for that
<gonidelis[m]>
;)
<gonidelis[m]>
K-ballo: what do you mean?
<K-ballo>
what part?
hkaiser has joined #ste||ar
<gonidelis[m]>
K-ballo: ok got it
<gonidelis[m]>
you are just saying that in case we check the sentinel then the end iterator is already covered by these tests
patrick22 has joined #ste||ar
hkaiser has quit [Quit: bye]
<patrick22>
Hello. I have a question regarding serialization of futures. I found an issue on github where serialization of futures that are not ready is discussed: https://github.com/STEllAR-GROUP/hpx/issues/1164 The way i understand it is, that a future is only serialized when it is ready. If it is not ready, the system waits until it is ready. The issue is rather old, so I was wondering if this is still the way
<patrick22>
it is implemented at the moment. Does anyone know more about this?
<K-ballo>
what's the alternative to serializing it when ready?
<patrick22>
isn't it possible to wait on the receiving end instead of the sending end? One use-case from the github issue is that we can already work on parts of the remote computation that does not require the value of the future
<K-ballo>
the receiving end gets a future immediately
<K-ballo>
it can go on and do work on parts that don't require the value
<K-ballo>
I think I'm missing something, I don't recall that old issue at all despite being in there
<K-ballo>
ok, the issue seems to be only about deferred futures, now it makes some sense
<K-ballo>
patrick22: are you working with deferred futures? my advice would be to avoid them as much as possible, they don't quite fit
<zao>
Today in stuff I didn't expect to have to dive into - Boost.Asio doesn't play well with recent Intel compilers when it comes to the deduction machinery around their polymorphic executors. So off the deep end of C++ competence here for me :D
shahrzad has joined #ste||ar
<patrick22>
K-ballo: To my understanding I'm not working with deferred futures. The default launch policy is not deferred, right?
<patrick22>
To clarify: when passing a future as a parameter to a remote async invocation, the serialization is held off until the passed future becomes ready? At least this is the way I understand hkaiser's explanation: "The scheme we have currently waits for the future to become ready before sending the parcel and it recreates a (ready-) future from the transmitted value on the receiving end."
hkaiser has joined #ste||ar
<K-ballo>
patrick22: I see what you mean, yeah, I was only thinking in terms of returning futures from actions
<gonidelis[m]>
hkaiser: ping
<hkaiser>
hey gonidelis[m]
<gonidelis[m]>
i reckon that needs to be adapted along too, right?
<gonidelis[m]>
ahh I mean for the c++20 adaptation
<hkaiser>
for sentinels? yes
<gonidelis[m]>
yy
<gonidelis[m]>
ok
<gonidelis[m]>
Do you and ms[m] check the cases were `IterB` is different than `IterE` ?
<gonidelis[m]>
with tests?
<gonidelis[m]>
hkaiser: ^^
<hkaiser>
I don't think so, at least not systematically
<gonidelis[m]>
hkaiser: ok cool. I will just make it compile then. Well, I mean if it compiles it's very likely that it works too...
<hkaiser>
lol
<hkaiser>
right
<K-ballo>
hah
<gonidelis[m]>
K-ballo: hello :)
<gonidelis[m]>
sorry I didn't mean to say that publicly
<hkaiser>
good one
<gonidelis[m]>
is there any quick way to `clang-format` all my to-be-commited files?
<K-ballo>
for future reference, there's an extension that runs clang-format each time you save
<gonidelis[m]>
hmm ok thanks
akheir has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
bita has joined #ste||ar
<hkaiser>
shahrzad: which of the test did you run just now?
bita_ has joined #ste||ar
bita has quit [Ping timeout: 258 seconds]
<K-ballo>
I'm having trouble with iwyu "leaking" requirements in certain situations, for example the use of a `decay_unwrap` in the result type of some function