hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Quit: Bye!]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 268 seconds]
K-ballo1 is now known as K-ballo
zao has quit [*.net *.split]
zao has joined #ste||ar
ms[m] has quit [*.net *.split]
ms[m] has joined #ste||ar
Yorlik has joined #ste||ar
Yorlik has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Ping timeout: 245 seconds]
K-ballo has joined #ste||ar
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 255 seconds]
hkaiser has joined #ste||ar
<gonidelis[m]> hkaiser: see pm please :)
hkaiser has quit [Ping timeout: 255 seconds]
hkaiser has joined #ste||ar
hkaiser_ has joined #ste||ar
hkaiser has quit [Ping timeout: 244 seconds]
<satacker[m]> section 10.8.1.1 does not define `get_completion_signatures` for `is_awaitable<S,P>` . It's not even in their implementation.
<satacker[m]> Ref: 4th point in above section
<satacker[m]> CC hkaiser
<hkaiser_> satacker[m]: could be an oversight
<satacker[m]> This is what's bugging me for a couple of days
<hkaiser_> otoh, get_completion_signatures is something that is exposed by senders
<hkaiser_> is is_awaitable<> a sender?
<satacker[m]> is_awaitable is not a sender
<hkaiser_> satacker[m]: why should it expose get_completion_signatures, then
<satacker[m]> sender is defined if it has valid completion signatures ig
<hkaiser_> yes
<hkaiser_> but if it's not a sender, then it shouldn't expose those
<satacker[m]> it shouldn't
<hkaiser_> right
<satacker[m]> but get completion signatures should consider is a sender is an awaitable even when it has a promise type that is explicitly needed for it to be satisfied as an awaitable
<satacker[m]> s/is/if/
<satacker[m]> for example `is_awaitable<S>` may not be an awaitable, but `is_awaitable<S,P>` could be one
<hkaiser_> satacker[m]: do you mean as_awaitable<>?
<satacker[m]> no, `is_awaitable`
<hkaiser_> so you're trying to implement the awaitable concept?
<hkaiser_> p2300 doesn't mention is_awaitable<>
<satacker[m]> No, it's just this line. When `is_awaitable<S>` is false but `is_awaitable<S,P>` is true
<satacker[m]> where P is promise type
<hkaiser_> satacker[m]: your is_awaitable corresponds to the __awaitable<> concept from the ref implementation
<satacker[m]> satacker[m]: sorry, by this I meant S may not be an awaitable but S,P could be
<hkaiser_> so in your case, is_awaitable is a trait, right?
<satacker[m]> is_awaitable<S> and is_awaitable<S,P> are just false or true types
<hkaiser_> a type-trait
<hkaiser_> yes
<hkaiser_> so why should they expose get_completion_signatures?
<hkaiser_> sorry, I'm still missing the point
<satacker[m]> I used wrong wording initially, let me rephrase the question
<satacker[m]> When `is_awaitable_v<S>` is true, this will work right?
<hkaiser_> what 'will work'?
<satacker[m]> But if `is_awaitable_v<S>` is false, does this necessarily mean it's not an awaitable? It could be within a coroutine context i.e. a promise type. Is this correct?
<hkaiser_> it says, that if _Sender is an awaitable, the completion signatures for _Sender should be generated as coded
<satacker[m]> hkaiser_: `get_completion_signatures` will return some completion signatures other than `no such completion signature`
<hkaiser_> yes, but that's the completion signatures for _Sender, not for is_awaitable<>
hkaiser has joined #ste||ar
<hkaiser> if get_completion_signatures are requested for a type that is an awaitable (i.e. not a sender), then they are generated on the fly based on the type returned when awaiting on it
<satacker[m]> `_Sender` may be an awaitable even if `is_awitable_v<_Sender>` is false
<hkaiser> is_sender<_Sender> will most likely be false for awaitables (is_awaitable<_Sender> == true)
hkaiser_ has quit [Ping timeout: 244 seconds]
<satacker[m]> yes, i am just saying that `is_awaitable<_Sender> ` maybe false even when _Sender is an awaitable
<hkaiser> this is done so you can write: (co_await some_expr) | some_receiver
<hkaiser> uhh, that doesn't sound right
<hkaiser> is_awaitable<_Sender> will be true if _Sender is awaitable, what would be the sense in it otherwise?
<hkaiser> or is there a 'special' is_awaitable<> that doesn't cover all things co_await could be used with?
<satacker[m]> hkaiser: Let me point out a case
<satacker[m]> `static_assert(is_awaitable_v<awaitable_2>);`
<satacker[m]> > this is done so you can write: (co_await some_expr) | some_receiver
<satacker[m]> some_expr can be evaluated by some_expr.await_transform by the compiler
<hkaiser> yes
<hkaiser> satacker[m]: I will need to have a closer look, I'd say go with your current understanding
<satacker[m]> Okay, are you available for meeting at our reg time tomorrow?
<hkaiser> satacker[m]: yes, absolutely
<hkaiser> I'll try to have a look this afternoon
<satacker[m]> Cool, thanks
<satacker[m]> Will let you know if I was wrong to save some trouble
<hkaiser> k
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
sivoais has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 268 seconds]
K-ballo1 is now known as K-ballo
diehlpk_work has joined #ste||ar
<diehlpk_work> gonidelis[m], Have you testes the parallel algorithms of HPX 1.8.0?
<gonidelis[m]> No
<gonidelis[m]> But didn’t change much
<diehlpk_work> OK, I am measuring performance and get really strange results for 1.8.0
<diehlpk_work> Neverming, the same strange behavior happens with HPX 1.7.1
diehlpk_work has quit [Remote host closed the connection]
ms[m] has quit [*.net *.split]
pansysk75[m] has quit [*.net *.split]
gdaiss[m] has quit [*.net *.split]
gdaiss[m] has joined #ste||ar
ms[m] has joined #ste||ar
pansysk75[m] has joined #ste||ar
<gonidelis[m]> Please let me know if your new results
<gonidelis[m]> of^^
<gonidelis[m]> diehlpk_work:
<gonidelis[m]> hkaiser: did your cppcon get accepted?
<hkaiser> gonidelis[m]: yes
<gonidelis[m]> Aurora here we go I guess ;p
<hkaiser> gonidelis[m]: yah
<hkaiser> now I have to think what I will talk about ;-)
<gonidelis[m]> lol
<gonidelis[m]> puttin a nice parallel ranges tutorial would be cool
<hkaiser> gonidelis[m]: could we do the rc2 tomorrow after the meeting with Shreyas?
<gonidelis[m]> yes, today was kinda of a busy day (still is0
<gonidelis[m]> )