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
aacirino has quit [Remote host closed the connection]
<srinivasyadav227>
hkaiser: yt ?
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 240 seconds]
diehlpk_work_ has quit [Ping timeout: 240 seconds]
<satacker[m]>
<hkaiser> "satacker: I'm locking forward to..." <- Did some background research: Starting from why senders receivers schedulers made sense to how other libraries have used it for coroutine integration
<satacker[m]>
CC gonidelis
<satacker[m]>
Question: So when you said we lacked co_await integration you meant that the `libs/core/execution_base/include/hpx/coroutines/` are based on boost.context and we need to add a co_await integration i.e. details to check if it follows all the rules an Awaitable should follow, and likewise for the rest of the design guidelines within sender/receivers and then use this to create a task/generator API for eager/lazy evaluation. Is that so?
<satacker[m]>
If I am proceeding in the right direction I could use some help in making a proposal for this. Thank you
aacirino has joined #ste||ar
<gonidelis[m]>
satacker: first of all thank you very much for looking into this project. it is really valuable for us. secondly, I am not as familiar as I should be in order to address your question so I would suggest that you email Hartmut with your concerns (and cc me please) given that he will be able to answer you precisely and provide you with the corresponding material. You will not find him in irc for the next couple of days that's why I am
<gonidelis[m]>
The only thing I could verify from what you said is that we indeed want to provide our own awaitables integration instead of relying to external `co_await`s (say C++20, or other libraries). I think this path points to a pseudo-coroutine infrastructure but does not provide separated standalone functionality.
<gonidelis[m]>
suggesting the email.
<gonidelis[m]>
I very much think you are approaching this from the right direction though. Please keep digging, come up with a rough draft (even provide a dummy implementation maybe?) and share it with us so we can discuss on concrete ideas. hkaiser will be back next week so we can discuss in detail. Thanks!
<gonidelis[m]>
satacker: did you just share a proposal?
<gonidelis[m]>
ah yes u did
<satacker[m]>
I shared a document which I will turn it into proposal later
<satacker[m]>
I shall keep digging in as you have suggested and also try to implement what I think.
<gonidelis[m]>
thanks for sharing
diehlpk_work_ has joined #ste||ar
aacirino has quit [Quit: Leaving.]
<gonidelis[m]>
K-ballo: I read about template vs interface polymorphism and it says that a drawback of using template polymorphis is that: "If the concrete type is known, the method can explicitly specify the concrete type, non-polymorphically. Otherwise, the caller must also be a template, to pass along the template type"
<gonidelis[m]>
i do understand the otherwise part
<gonidelis[m]>
but what does it mean "the method can explicitly specify the concrete type" ?
<gonidelis[m]>
non-polymorphically
<gonidelis[m]>
like when I use an `int`, what's the catch?