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/
<gonidelis[m]> hkaiser: any news about rostam?
<hkaiser> gonidelis[m]: still no news, sorry
<gonidelis[m]> no prob. i am just asking because my local machine has problem and i am scheduling on when to send it for repair
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
bita has quit [Ping timeout: 264 seconds]
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
<parsa> hkaiser: i checked and it looks like python 2 is removed from the hpx base image
<hkaiser> parsa: do we need it?
<hkaiser> and thanks for checking?
<hkaiser> !
<hkaiser> there are a lot of python related problems for other targets as well - not sure what happened - grrr
<parsa> i think we were using something that wasn't yet available in python 3. probably is resolved by now. will find out soon
<parsa> :s/something/ package
<hkaiser> parsa: yes
<hkaiser> parsa: and thanks for spending time on this
<parsa> some module's renamed?
<hkaiser> shrug
<parsa> sure, i don't want this stuff to break
<parsa> hkaiser: the python 2->3 errors fix is just using python3 explicitly instead python: https://app.circleci.com/pipelines/github/STEllAR-GROUP/phylanx/916/workflows/1972cfc0-1d4b-44f8-8715-5a2b65c07d49
<gonidelis[m]> hkaiser: should we wait for CI to approve ? we are almost there
<hkaiser> parsa: could you do that?
<hkaiser> gonidelis[m]: let's wait for the CI
<gonidelis[m]> cool
<parsa> sorry, do what? if you mean the 2->3 fix i'm waiting on this particular workflow to finish and then merge it into master
<parsa> if it goes well other branches will need to rebase on top of master
<parsa> i don't know what the test fails are caused by, yet
<hkaiser> parsa: ok, thanks
RostamLog has joined #ste||ar
<gonidelis[m]> :'))))) i am so moved... it's been 4 months. `transform` is finally there... \o/ \o/
<hkaiser> gonidelis[m]: well done!
<gonidelis[m]> hkaiser: thanks
<parsa> hkaiser: i don't understand what the other issue is. i think rod and steve together are better positioned to fix it
bita has joined #ste||ar
<gonidelis[m]> i cannot understand Stourdap
<gonidelis[m]> 's example
<gonidelis[m]> for `inline namespace`s here
<gonidelis[m]> what does `inline V99` do in this case?
<hkaiser> gonidelis[m]: it imports the names from inside V99 to the surrounding namespace without making them part of the namespace in terms of ADL etc.
<hkaiser> actually, scratch the non-ADL part
<hkaiser> gonidelis[m]: also, cooling has been fixed, expect rostam to be up soon
<gonidelis[m]> hkaiser: exactly...i can only see the usefulness as far as ADL is concerned. i suspect that there is something more though from my reading thus far. anyways that's great!! I will take my laptop to the repair shop tomorrow then.
<gonidelis[m]> so the reason why we use `inline constexpr` in our CPOs
<gonidelis[m]> is for the users to be able to write `hpx::transform()`
<gonidelis[m]> instead of `hpx::transform_t::transform()` ?
<gonidelis[m]> hkaiser: ^^
<hkaiser> no, that's a different thing
<hkaiser> the inline constexpr refers to the variable defined by the expression: inline constexpr struct foo {} foo_var;
<hkaiser> it's not an inline namespace
<gonidelis[m]> ahh yeah...