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/
<gnikunj[m]>
nice! I'll try to create a calculator using Qi and Karma like in your talk. That should help me understand a bit about them. Then something like scheme.
<K-ballo>
no, it's not wrong, looks like command_line_handling.hpp gets included in the other 89 locations
<K-ballo>
some of those should be genuine, but not all 89 of them
<hkaiser>
K-ballo: I can't see the document, could you share it wiht my gmail account?
<K-ballo>
should be public now
<K-ballo>
it's possible other TUs have a direct #include too, but get the header via some indirect include first
<K-ballo>
detail/partitioner seems to be leaking it.. why would a detail/partitioner expose command line argument?
<hkaiser>
yah, that is somehow not right
<hkaiser>
the command line handling should be included by 2 or 3 files, max
<hkaiser>
directly, I mean
<K-ballo>
there's 81 direct includes
<hkaiser>
nod
<K-ballo>
out of the 91 inclusions of program options
<K-ballo>
no, I'm confusing things
<K-ballo>
there's 81 TUs including command line handling
<hkaiser>
it's really referred to from about 20 files or so, which makes perfect sense
<hkaiser>
most of the includes are in tests
<K-ballo>
that means it's just leaked everywhere then
<K-ballo>
why is the partitioner the one parsing the command line?
<zao>
Ho ho, you found that mess? :D
<zao>
I have vague memories of having to deal with it back on BSD OSes, is it because it's so early in startup that it can't get it from anything constructed already?