<zao>
kale[m]: there’s been talk about this recently, try searching the logs
<kale[m]>
Okay so as for generating wheel I will be using hpx at the suggested commit but there will be a problem in generating wheels using CI since the docker isnt working as expected
hkaiser has joined #ste||ar
<gnikunj[m]>
hkaiser: CPOs does make code so much cleaner. Just saw your work on resiliency CPO.
<hkaiser>
:D
<gnikunj[m]>
btw, the async replay executor helper looks redundant
<gnikunj[m]>
it's exactly the same code as async_replay_helper
<gnikunj[m]>
but without the hpx::future part
<hkaiser>
yah, I thought about that
<hkaiser>
feel free to unify things
<gnikunj[m]>
alright. I'll try to first add actions to it today. And make the PR. I'll unify it in that PR then.
<gnikunj[m]>
hkaiser: what is the difference between hpx::async(action, hpx::find_here()) vs hpx::async(action, hpx::colocated(hpx::find_here))
<hkaiser>
gnikunj[m]: none
<hkaiser>
no difference
<gnikunj[m]>
aah, thought so
<gnikunj[m]>
why do we have the 2 separate?
<hkaiser>
colocated(id) is meant to run the action next to a component
<gnikunj[m]>
next to a component as in?
<gnikunj[m]>
it will run it on the id you provide
<hkaiser>
if teh component id is located on a locatity L, the colocated(id) will run on L
<gnikunj[m]>
you mean it will run on a thread that's near the component?
<gnikunj[m]>
but what if id is not L?
<hkaiser>
it will run a plain action on the locality where the component lives
<gnikunj[m]>
ohh so if you migrate objects, it will find the right id and run it on the migrated locality?
<hkaiser>
yes
<gnikunj[m]>
even if you provide the wrong one to begin with?
<hkaiser>
what wrong one?
<hkaiser>
'id' is the id of the component
<hkaiser>
it doesn't change, even if the component migrates
<gnikunj[m]>
I meant let's say the component is initiated on locality 1
<gnikunj[m]>
so you give the colocated(1)
<hkaiser>
no
<gnikunj[m]>
ohh, what is it then?
<hkaiser>
you instantiate a component on l1 that gives you the id, then colocated(id) will run on l1
<hkaiser>
id = new_<Component>(l1); then colocated(id) runs on l1
<gnikunj[m]>
aha, that's why all the execution policies return hpx::future<hpx::id_type>
<hkaiser>
right
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
<gnikunj[m]>
hkaiser: do we have a trait that identifies Action type?
<K-ballo>
is_action?
<gnikunj[m]>
so we do. Nice.
<K-ballo>
we should think of a more intuitive name :P
<gonidelis[m]>
Question: I am looking into the purpose of capture lists compared to the purpose of parameter lists in lambda functions. What I understand so far is that these capture lists mainly exist because we use lambda functions a lot in combination with stl algos and thus we can only have one (or to be more accurate, we can only have "certain") input from the algo but we may need some extra values (variables) in order to do the
<gonidelis[m]>
job we want to. Thus, a capture list enables us to wrap values along with the core functionality of the lambda, but still: that's significant when lambdas are used in combine with the stl algos.
<gonidelis[m]>
Is there any other specific reason (example), with a clear advantage for the existance of capture lists (on top of the parameter lists)
<gonidelis[m]>
?
<K-ballo>
that's an odd question.. the stl algos aren't special
<K-ballo>
parameters correspond to the interface the lambda has, whereas captures are internal implementation state
<K-ballo>
the parameters will be guided by the desired interface
<hkaiser>
gonidelis[m]: remember that a lambda is just syntactic sugar for a function object
<hkaiser>
i.e. [a, b, c](args) -> R {<body>} === struct <unnamed> { auto a, b, c; R operator()(args) { <body>}};
<gonidelis[m]>
hkaiser: yeah that's what I recall from that great lecture of yours. So it's like `args` is where we want to "apply" the function to and `a, b, c` are like for internal use (possibly for usage inside the body)
<gonidelis[m]>
hmmm... like maybe one could tell that the `args` are just `args` that we don't know what they trully are, until the user provides them to us and on the other hand we do know what the `captures` are and we do use them because we have defined them...
<gonidelis[m]>
sorry for describing in such a sloppy way
<kale[m]>
I'm using Phylanx version at commit:d48b611bbc5337bc14ba93e4bf3cb
<hkaiser>
kale[m]: uhh, I've never see this
<kale[m]>
hkaiser: It is able to find phylanx plugins that much I've checked in the debug log generated
<hkaiser>
kale[m]: be back in a bit
<hkaiser>
kale[m]: the code that fails tries to traverse the Python AST
<hkaiser>
we know it works on Pyhton 3.6/3.7
<hkaiser>
could it be that the AST format has changed and the _Constant node in the AST has been removed? (I believe _Constant is a type defined by the Python AST)
<kale[m]>
Yeah, I have a working wheel for 3.7 but trying to replicate the same steps with python 3.8 is throwing this error
<hkaiser>
the Python readme says: 'ast.NodeVisitor methods visit_Num(), visit_Str(), visit_Bytes(), visit_NameConstant() and visit_Ellipsis() are deprecated now and will not be called in future Python versions. Add the visit_Constant() method to handle all constant nodes.'
<hkaiser>
So something has changed and will require adaptation n our end
<hkaiser>
please create a ticket on the Phylanx git repository
<kale[m]>
hkaiser: Okay
nanmiao11 has quit [Remote host closed the connection]
<hkaiser>
kale[m]: feel free to fix it yourself, however
<hkaiser>
;-)
<gnikunj[m]>
:D
<gnikunj[m]>
hkaiser: yt?
<hkaiser>
here
<gnikunj[m]>
hkaiser: Do you have something other than std::vector in mind?
<hkaiser>
distribution policies?
<gnikunj[m]>
I thought of distribution policy but they essentially do a round robin anyway
<gnikunj[m]>
its essentially the same thing that I do in the implementation
<gnikunj[m]>
hkaiser: corrected the const& issue. About the tests, I simplified them to a greater extent. This will help us identify issues if the test fails.
<hkaiser>
gnikunj[m]: but removed the exception handling verification
Yorlik has joined #ste||ar
<gnikunj[m]>
aah right. I should get that in place.
<hkaiser>
please do
<gnikunj[m]>
else we'll have failing tests with correct codes
<gnikunj[m]>
do you want me to shift the distributed code to a new namespace?
<hkaiser>
gnikunj[m]: I think we can't have enough tests, and those have to be pretty as long as they verify things
<hkaiser>
I meant: thoase have _not_ to be pretty
<gnikunj[m]>
I can always get it back to the way they were :)
Yorlik has quit [Ping timeout: 265 seconds]
<hkaiser>
gnikunj[m]: just add your tests separately
<hkaiser>
no harm done ;-)
<gnikunj[m]>
hkaiser: right :D
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
<gnikunj[m]>
hkaiser: how does a CPO handle namespaces?