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
<gonidelis[m]>
hkaiser: I was just wondering about your new executor
<K-ballo>
iterator_support depends on serialization?
<K-ballo>
ideally we'd be seen a level 0 config module (all the preprocessor flags and nothing else),
<K-ballo>
a level 1 support module (all the fundamental language only pieces we build on top of as well as some back-ported library features, internal use only)
<hkaiser_>
K-ballo: well, this is the status quo, now we can start re-ordering things, as needed
<K-ballo>
commits that rename files make me sad, but it may be a necessity
<K-ballo>
if there's a way to conditionally leverage modules it'd be a good time to give it a try
<K-ballo>
cmake doesn't seem to be up for it though, as far as I can see
<hkaiser_>
K-ballo: yes, I was waiting for cmake to support modules before looking into that
<K-ballo>
it should be a single effort
<K-ballo>
and by that I mean we shouldn't be turning the existing cmake modules into c++ modules
<hkaiser_>
combine our 'modules' into C++ modules?
<K-ballo>
if needed, figure out what our C++ modules should be
<K-ballo>
there'll likely be a lot of combining, it's not a problem for C++ modules to have lots of things
<hkaiser_>
sure
<K-ballo>
only truly independent pieces would benefit from a separate module, things like distributed probably
<K-ballo>
and maybe also optional things, like each parcelport
<K-ballo>
and some "extra" components
<hkaiser_>
K-ballo: we have two pieces today, that's a starting point
<K-ballo>
what are the two pieces?
<hkaiser_>
core and full (i.e. local and distributed)
jehelset has quit [Ping timeout: 260 seconds]
<gonidelis[m]>
what kinds of reordering are we want to make? hkaiser_ K-ballo ?
<gonidelis[m]>
kind of reorderings*
Yorlik_ has joined #ste||ar
hkaiser_ has quit [Quit: Bye!]
<gonidelis[m]>
ms: rori i downloaded the HPX docker environment and built hpx with DOCUMENTATION=ON ... now i have a banch of .doctree files within my container. How do I open it locally in a browser or sth? i mean 1. can firefox open .doctrees and 2. can firefox be used through the container?
<gonidelis[m]>
........ or just copy the files to host? (sounds sloppy) ://
<gonidelis[m]>
ahhh it's the htlmls under `/share`...my bad. tho the question remains. do i still need to copy the doctree files?
hkaiser has joined #ste||ar
diehlpk_work has joined #ste||ar
jehelset has joined #ste||ar
<rori[m]>
I was usually opening with `firefox <path/to>/index.html &`
<rori[m]>
and then browsing around with the links
<gonidelis[m]>
rori: but i need to mount firefox for that. no?
<gonidelis[m]>
"mount firefox"
<gonidelis[m]>
hkaiser: I was about to make those changes in the PR that we just merged ;p Should have told you to keep it open i am sorry. Regarding #5854 that is
<gonidelis[m]>
oh wait a sec....that's only about counter_type
<gonidelis[m]>
hmmm... i thought it was about the remaining perf_counter enums
<hkaiser>
gonidelis[m]: yes, you missed a couple of places
<gonidelis[m]>
i worked based on the tests.... should have `grep`ed
<gonidelis[m]>
will review after class
<hkaiser>
gonidelis[m]: indeed
<bhumit[m]>
<gonidelis[m]> "ms: rori i downloaded the..." <- I did this by using docker volumes. Look into that maybe?
<gonidelis[m]>
bhumit: ah thanks!
emmakoto[m] has joined #ste||ar
Yorlik_ is now known as Yorlik
Guest82 has joined #ste||ar
Guest82 has quit [Ping timeout: 250 seconds]
Guest82 has joined #ste||ar
jehelset has quit [Ping timeout: 240 seconds]
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
Guest82 has quit [Quit: Client closed]
EmmanouilKotoula has joined #ste||ar
<rori[m]>
<bhumit[m]> "I did this by using docker..." <- yes you should mount the build directory to have access locally, add the -v option to the docker run command `-v=<path/to/local/build/dir>:/hpx/build`
<gonidelis[m]>
yup! it worked thanks!
jehelset has joined #ste||ar
<gonidelis[m]>
hkaiser: what work does need to be done with the new dependency tool?
<hkaiser>
gonidelis[m]: we could integrate it into CircleCI so it can run for each commit to master
<gonidelis[m]>
and it just checks for circular dependencies?
<hkaiser>
not really
<hkaiser>
we already check for circular dependencies
<hkaiser>
the generated dependency report is more like documentation, I think
<hkaiser>
but I'm definitely open to suggestions
ahmed_ has joined #ste||ar
Yorlik has quit [Ping timeout: 260 seconds]
<K-ballo>
note the circular dependency between config and pp
<K-ballo>
it's definitely documentation, but it'd be nice if it could raise a warning when the numbers increase
<hkaiser>
gonidelis[m]: I wanted to see a more detailed dependency analysis, not sure how generally useful that will be
<hkaiser>
K-ballo: there shouldn't be any circular dependency
<gonidelis[m]>
hm..
<gonidelis[m]>
very nice!
<hkaiser>
K-ballo: no, there is no circular dependency - does the tool show something like that?
<hkaiser>
ahh darn, you're right, but that can be resolved - thanks for noticing
<K-ballo>
Level undetermined
<K-ballo>
core/config > core/preprocessor
<K-ballo>
core/preprocessor > core/config
<hkaiser>
one of the generated headers include hpx/config
<hkaiser>
I will fix that
<hkaiser>
preprocessor doesn't need to depend on config
<K-ballo>
no?
<K-ballo>
maybe it did before, when targeting earlier standards or older compilers
<K-ballo>
I would rather see core/config not depend on anything
<K-ballo>
probably some CAT?
<K-ballo>
cat and stringize
<K-ballo>
expand too :/
<hkaiser>
yah
<hkaiser>
preprocessor has its own config file for compiler compatibility