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 | Everybody: please respond to the documentation survey: https://forms.gle/aCpNkhjSfW55isXGA
RostamLog has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
diehlpk_work_ has quit [Remote host closed the connection]
tufei has quit [Remote host closed the connection]
tufei has joined #ste||ar
nanmiao has quit [Quit: Client closed]
parsa[fn] has quit [Quit: Vazeyti]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> ms[m]: yt?
<ms[m]> hkaiser: here
<hkaiser> hey
<hkaiser> did we update cmake-format in the circle base image?
<ms[m]> uhm, yeah, I think so, although implicitly
<hkaiser> what version is that now, I need to update my local version ...
<ms[m]> circleci says 0.6.1
<ms[m]> 0.6.13
<ms[m]> the latter
<hkaiser> ok, I still have 0.6.10, that explains things
<hkaiser> thanks
<ms[m]> yep
<ms[m]> I think I also merged some wrongly formatted stuff to master, but that should be fixed now
<ms[m]> if circleci is complaining a rebase may be enough
<hkaiser> ok, thanks
<ms[m]> hkaiser: feel free to go ahead with #5489
<ms[m]> any news about rostam btw?
<hkaiser> ms[m]: I will talk to Alireza later today, things seem to take longer than anticipated
<hkaiser> ms[m]: merged... that will allow me to use bind for the executor_scheduler
<ms[m]> hkaiser: no worries and thanks
<K-ballo> beware of using bind internally when the arguments are user provided, things blown up with nested bind evaluation, extraneous placeholders, etc
<hkaiser> nod, true
<hkaiser> K-ballo: will bind_front/back have the same issues?
<K-ballo> no, none of them
<hkaiser> ok
<gnikunj[m]> hkaiser: hey! Is there a way to provide HPX configuration to hpx::init (like running hpx_main on all localities) without actually having to have a program_option object?
<hkaiser> gnikunj[m]: yes
<gnikunj[m]> any test/example that does it? Seems like Nan's code is having trouble building it.
<hkaiser> you can pass any command line option in the cfg array of the init_params
<hkaiser> init_params p; p.cfg = {"--hpx:run-hpx-main" }; hpx::init(argc, argv, p);
<gnikunj[m]> hkaiser: sure, but what if the commandline option has a different structure? (the parser complains about `-kernel` as an unrecognized command)
<gnikunj[m]> we want to make sure that any hpx related commandline options are passed (i.e. the one's related to --<some options> and any option defined using program_options) while also having other non-hpx related commandline options handled too (like `-type <some_type>`
<gnikunj[m]> * we want to make sure that any hpx related commandline options are passed (i.e. the one's related to --<some options> and any option defined using program_options) while also having other non-hpx related commandline options handled too (like `-type <some_type>`)
<hkaiser> add a "--hpx:ini=hpx.commandline.allow_unknown!=1" to the list of options
<gnikunj[m]> perfect, I was looking for this!
<hkaiser> you might also want to add "--hpx:init=hpx.commandline.aliasing!=0" which disables HPX's short options
<hkaiser> hpx:ini= that is
<hkaiser> these to will also remove the hpx options from argc/argv before calling hpx_main, so that hpx_main will have only the application specific options
<gnikunj[m]> splendid! It worked. Thanks!
diehlpk_work has joined #ste||ar
hkaiser has quit [Quit: Bye!]