hkaiser 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/ | GSoC2018: https://wp.me/p4pxJf-k1
<nikunj>
yes the error is of uninitialized hpx runtime as well
<nikunj>
ok, I'll add an entry in HPXConfig
<hkaiser>
nanashi55: could you add a config (cmake option) that enables your new code?
<hkaiser>
I'd like to make the migration to the new stuff a bit more smooth
<hkaiser>
nikunj: ^^
<nikunj>
how would you like me to make things happen?
<hkaiser>
HPX_WITH_DYNAMIC_HPX_MAIN or something
<hkaiser>
that should allow to inforce he old/new behavior at configuration time
<hkaiser>
I can try doing this as well
<hkaiser>
nikunj: let me do that, I know exactly what I would like to see
<nikunj>
hkaiser: understood
<hkaiser>
nikunj: this was on my list anyways - we try to introduce breaking changes in stages
<hkaiser>
one release have the new behavior in place but users need to explicitly enable it, second release, the new behavior is enabled by default, and third release we remove the old stuff
<nikunj>
ohk, sorry for the wrong information I shared
<hkaiser>
nikunj: no problem, I didn't communicate this to you
<hkaiser>
we might skip the first stage and have it enabled by default, but we need to have a means of enforcing the old behavor
<nikunj>
yes
<nikunj>
oh so are we adding a transition from the old behavior to the new?
<hkaiser>
nikunj: please feel free to comment on this, I hope I got it right
<nikunj>
hkaiser: LGTM
quaz0r has quit [Ping timeout: 260 seconds]
<hkaiser>
nikunj: what would happen if things are enabled at HPX built time but somebody disables the feature at application build time
<hkaiser>
all should be well because of the weak symbol, right?
<nikunj>
by built you mean while building hpx?
<nikunj>
thing will work like used to before if it's disabled at application build time
<hkaiser>
yes, that's what I meant
<hkaiser>
I pushed another commit explicitly allowing this
<nikunj>
if it's built using that option then the examples and tests will be built linking with my code
<hkaiser>
if an application #define HPX_HAVE_DYNAMIC_HPX_MAIN 0 before including hpx/hpx_main.hpp it will disable things
<nikunj>
yes
<nikunj>
and the code will move on to #define main method
<hkaiser>
right
<hkaiser>
could you test this PR with your environment, please
<nikunj>
also you have specifically mentioned for HPX_HAVE_DYNAMIC_HPX_MAIN in cmake check as well so that would not allow adding the flags as well
<nikunj>
ok, on it
<hkaiser>
thanks
<nikunj>
hkaiser: should I try building phylanx with hpx to test application built?
galabc has joined #ste||ar
<nikunj>
hkaiser: the branch builds and can run examples perfectly. Running tests on it now.
quaz0r has joined #ste||ar
<hkaiser>
nikunj: feel free to test phylanx as well, sure
<hkaiser>
nikunj: circleci for phylanx uses an older version of clang (hmm, so does circleci for hpx)
<hkaiser>
could it be that this causes the problems?
<nikunj>
I tested the code with clang 3.9, so I don't think it is the problem
<hkaiser>
then there is something else ...
<nikunj>
Most likely its with HPXConfig
<hkaiser>
could be
<hkaiser>
Phylanx relies on it
<nikunj>
we can now add HPX_WITH_DYNAMIC_HPX_MAIN to the config
<nikunj>
that should clear things
<hkaiser>
nikunj: pls note that the HPX_WITH_... is used for the cmake part, while HPX_HAVE_... is used as a pp constant at compile time
<nikunj>
ohk
<hkaiser>
also, the HPX_HAVE_.. is automatically propagated to dependent projects through the hpx/config.hpp
<nikunj>
hkaiser: the linker flags are not propagated through HPXConfig
<hkaiser>
right
<nikunj>
They are explicitly mentioned in HPX_SetupTarget though
<nikunj>
oh that explains it!
<nikunj>
phylanx doesn't depend on HPX_SetupTarget (as seen from the cmake source)
<nikunj>
so it wouldn't run
<nikunj>
linker flags are crucial for my code to run as expected
galabc has quit [Quit: Leaving]
<nikunj>
hkaiser: just checked out the cmake code for phylanx. It does not make use of hpx_setup_target (where I have added my flags). Therefore it does not work.
<hkaiser>
ok
<nikunj>
we need to add it along with the necessary flags required for HPX
<hkaiser>
nikunj: yes, we essentially copied things over from hpx (see phylanx_setup_target)
<hkaiser>
but we need it in hpxconfig anyways
<nikunj>
phylanx_setuptarget will not contain my flags as it is not propagated
<hkaiser>
right, we need to add it there, but only if HPX_WITH_DYNAMIC_HPX_MAIN is defined in HPXConfig
<nikunj>
yes! And HPX_WITH_DYNAMIC_HPX_MAIN will be propagated through cmake
<nikunj>
so we need to simply add the flags there and things should start to run as expected
<nikunj>
hkaiser: hpxconfig does not seem to contain any variable for link_flags or cxx_flags
<hkaiser>
nikunj: it needs to contain HPX_WITH_DYNAMIC_HPX_MAIN, though
<nikunj>
hkaiser: yes it should contain it
<nikunj>
also why don't we create flags similar to HPX_CUDA_CLANG_FLAGS for our variable?
<nikunj>
we can propagate it to all the projects
<nikunj>
we will then need to add the flag to the set of link flags and things should run pretty smoothly
<nikunj>
this way the user will not have to remember the linker flag I add in HPX_SetupTarget and can simply add it by the variable name
<hkaiser>
fine by me
<hkaiser>
nikunj: why is it failing if Phylanx does not force-link with your symbols
<hkaiser>
should it work anyways (falling back to the old behavior)?
<nikunj>
no, phylanx would still fail here still it is being run on inux
<nikunj>
so it will enter the #if defined(__linux).. portion
<nikunj>
leading to this error
<hkaiser>
: sure, but it should hit the weak symbol which defaults to false
<hkaiser>
can't we make this work anyways?
<hkaiser>
(I would like to change Phylanx as needed, but this is a possible source of errors which I'd like to prevent, if possible)
<nikunj>
yes it will hit false, but without the linker flags in place the actual linking will not work
<hkaiser>
is there a solution to this?
<nikunj>
if the linker flags are present then weak symbol should work.
<nikunj>
Yes there is, the one I used at first
<nikunj>
creating a separate static lib and using flag to link
<hkaiser>
in the end I'd like for the user not to have to do anything in order to have a functioning build, one way or another
<hkaiser>
can we at least detect at runtime that there is a problem?
<hkaiser>
to report a more meaningful error or somesuch?
<nikunj>
unfortunately not, without the addition of the linker flag my code would simply not work.
<K-ballo>
throw std::runtime_error("Not a valid format specifier");
<hkaiser>
ahh, ok - makes sense
<hkaiser>
I'll try that
<K-ballo>
whatever you put in the specifier is what you get as the `spec` parameter, totally user defined
<hkaiser>
ok
<hkaiser>
how does it behave if {%1%} is used?
<hkaiser>
just converts it to a string? of just uses operator<<()?
<hkaiser>
K-ballo: ^^
<hkaiser>
(or whatever the generic syntax is)
<K-ballo>
{1} is equivalent to {1:} which is equivalent to an empty spec
<K-ballo>
index and specifier are dealt with separately, custom formater only gets the spec
<K-ballo>
the empty spec has a special switch somewhere
<hkaiser>
{1} just uses operator<<() then?
<K-ballo>
no, it depends on the type
<hkaiser>
how is that customized?
<K-ballo>
{1} for an argument of type variant at that position would call custom formatter for variant, with an empty spec
<hkaiser>
ok
<hkaiser>
thanks
<K-ballo>
if the argument is a variant then the custom formatter function of variant always gets called
<hkaiser>
understood
<K-ballo>
if there is no custom formatter, the fallback is op <<, yes
<K-ballo>
I did not understand the question, but I hope I've answered nonetheless
<K-ballo>
I don't think I've been clear.. fundamental types don't use op<<, only user defined types do
<K-ballo>
ah! i figured it out
<K-ballo>
hkaiser: you actually want to dispatch to format(...), not format_value(...), since the later is only for user defined types
<hkaiser>
k
<hkaiser>
K-ballo: I think I have a solution to what I want, thanks
<K-ballo>
may I see it?
<hkaiser>
sure, once it's ready I'll show it to you
<hkaiser>
so I need to dispatch to format_to
<hkaiser>
K-ballo: another question
<hkaiser>
K-ballo: my argument is actually a vector<variant<>>, but I would like to treat the index in the vector as the positional index of the value to format
<hkaiser>
K-ballo: i.e. format("%d, %d", vector<>{1, 2});
<hkaiser>
K-ballo: i.e. format("%d, %d", vector<int>{1, 2});
<hkaiser>
would that be somehow possible?
<hkaiser>
I guess I could call detail::format with my argument vector
<K-ballo>
no, that doesn't sound possible
<K-ballo>
working directly with the implementation, I suppose it would be possible to transform the vector of arguments into a vector of argument descriptors