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
Guest87652 has quit [Ping timeout: 276 seconds]
<nikunj97>
zao: I fixed the -std=c++14 error
<zao>
Ooh?
<nikunj97>
I'm committing my changes, could you please check if things are working
<nikunj97>
zao: I forgot to add target_compile_options :/
<nikunj97>
that's why it was the only file not getting the flag
<hkaiser>
nikunj97: is this a separate cmake project?
<hkaiser>
or just another target?
<nikunj97>
hkaiser: it's just another target
<hkaiser>
then this does not sound right
<hkaiser>
on windows you can't use -std=... options, for instance
<hkaiser>
is this a static library?
<nikunj97>
hkaiser: yes
<hkaiser>
use use hpx_setup_target on your target
<nikunj97>
hkaiser: are you sure? I added the parameters according to libhpx.so and libhpx_init.a are building
<hkaiser>
ok
<hkaiser>
well, let's leave it as you have it, we can always fix things
<zao>
int return_value = actual_main(argc, argv, __envp);`
<zao>
(boooo)
<nikunj97>
zao: yes it's unused. It's an expected behavior
<zao>
It causes a warning.
<nikunj97>
It is because the return value of C main (which is 0) is stored in it. It is not used for any other reason, thus unused.
<zao>
Also, does this mean that you're discarding the return code of the program?
<zao>
If it's unused, either don't name it or mitigate the unused variable warning.
<zao>
If I want to "return 13;" from a program using your HPX runtime stuff, does that work?
<nikunj97>
zao: ok I'll take off the variable from there
<nikunj97>
zao: it will work
<nikunj97>
hold on it might not
<nikunj97>
I'm not calling exit(return_value)
<nikunj97>
I'll change the code a bit
<nikunj97>
I should make my code's return value as return_value
<nikunj97>
that will handle things
<zao>
Seems to be building otherwise.
<nikunj97>
zao: good to hear. could you try running any example with hpx_main (hello_world for an instance)
<nikunj97>
or try running any tests like tests.unit.actions
<zao>
Still building, but I'll try to get to it.
<nikunj97>
zao: you can't return 13 on this implementation. It will only return 0 (due to the fact that hpx::finalize always returns 0)
<zao>
The return code is an important aspect of a normal program, communicating success/failure.
<zao>
Is it impossible to route out from a hpx-wrapped program, or something that doesn't make sense in such a program?
<nikunj97>
zao: I don't think so
<zao>
If the intent is to take an arbitrary normal program and turn its main into a HPX-enabled thing, it'd be a bit surprising that the normal semantics of return code doesn't carry through.
<zao>
I don't know the scope of your project, so it might be a fine tradeoff.
<nikunj97>
My implementation is similar to main -> hpx_main system. It's just that I change the entry point to my function and set entry point to main so it looks like initialize_main -> hpx_entry -> main
<nikunj97>
what main returns is stored in the return_value, I can surely pass by storing it's value in a global variable and then returning the same from initialize_main
<nikunj97>
it will work exactly the same way as a return code would work on main
<nikunj97>
zao: did it work?
<zao>
bin/hello_world launches at least.
<nikunj97>
good to hear :)
<nikunj97>
zao: could you try to run tests?
<zao>
On it already.
<zao>
`tests.unit.components.launch_process` has wedged for 15 minutes now, and doesn't seem to be honoring any timeouts.
<zao>
This is of course not necessarily your stuff hecking up.
<nikunj97>
launch_process uses hpx_init.
<nikunj97>
so it does not relate to my implementation, but it's weird to see that it's happening. I'll look into it
<nikunj97>
zao: does other tests passes?
<zao>
The tests up to that point pass, but no idea about anything after it.
<nikunj97>
you could try running other tests (omitting the launch_process)
<zao>
99% tests passed, 1 tests failed out of 573
<zao>
(had to manually kill the launch_process one)
<nikunj97>
which one?
<nikunj97>
so it would mean that everything is fine other than launch_process
<zao>
For this run, yes :)
<nikunj97>
My implementation is working it seems :)
<nikunj97>
time to doze off to sleep then (it's 8am in the morning here now)
<hkaiser>
nikunj97: you can pass the required return value to finalize()
K-ballo has quit [Quit: K-ballo]
<nikunj97>
hkaiser: ok
<nikunj97>
hkaiser: done
hkaiser has quit [Quit: bye]
quaz0r has quit [Ping timeout: 256 seconds]
nanashi55 has quit [Ping timeout: 264 seconds]
nanashi55 has joined #ste||ar
quaz0r has joined #ste||ar
anushi has quit [Ping timeout: 276 seconds]
anushi has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
quaz0r has quit [Ping timeout: 260 seconds]
quaz0r has joined #ste||ar
anushi has quit [Ping timeout: 255 seconds]
anushi has joined #ste||ar
FjordPrefect has quit [Ping timeout: 260 seconds]
itachi_uchiha_ has quit [Ping timeout: 260 seconds]
M-ms has quit [Ping timeout: 245 seconds]
mcopik has joined #ste||ar
quaz0r has quit [Ping timeout: 264 seconds]
itachi_uchiha_ has joined #ste||ar
FjordPrefect has joined #ste||ar
M-ms has joined #ste||ar
david_pfander1 has joined #ste||ar
david_pfander1 has quit [Ping timeout: 264 seconds]
jakub_golinowski has quit [Ping timeout: 245 seconds]
quaz0r has joined #ste||ar
jakub_golinowski has joined #ste||ar
jakub_golinowski has quit [Quit: Ex-Chat]
quaz0r has quit [Ping timeout: 256 seconds]
jaafar has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
quaz0r has joined #ste||ar
quaz0r has quit [Client Quit]
quaz0r has joined #ste||ar
diehlpk has quit [Ping timeout: 256 seconds]
<nikunj97>
hkaiser: yt?
<hkaiser>
here
<nikunj97>
hkaiser, how should I integrate my implementation with pkg-config?
<nikunj97>
there are a few flags that I want to add with my implementation that will make it work
<hkaiser>
nikunj97: in a perfect world all what is needed to pull in your code would be to #include hpx_main.hpp
<hkaiser>
do you think that would be possible?
<nikunj97>
there are 2 things that I need to do. First is to link against my static library and second is to provide a compiler flag
<nikunj97>
I'm not sure if that can be done by including just the header
<nikunj97>
hkaiser, any ideas as to how I should do it?
<hkaiser>
including the header could define pp constants and enable some code that refers to symbols in a static library
<nikunj97>
The easiest way I see it is to create another lib to attach to (instead of hpx_application)
<hkaiser>
the static library (hpx_init) would always be linked, but the symbols would be pulled only if needed
<nikunj97>
I can certainly try something like this. Just to assure I'm understanding correctly, you want me to always link with hpx_wrap but define it's behavior depending upon the header (if included/not included) using pp?
<hkaiser>
nikunj97: wouldn't that be the easiest for the user?
<nikunj97>
it will be
<hkaiser>
nod
<nikunj97>
hkaiser: ok I'll try implementing it
<hkaiser>
thanks :)
<github>
[hpx] K-ballo force-pushed logging from 0032f70 to e865bab: https://git.io/vx6Yc
<zao>
Also, is this some sort of external file system?
<zao>
Not sure if anything in the build is wildcard globbing, but there seems to be a ton of hidden files in those directories that are not C++ source files.
<zao>
HPX build relies heavily on *.cpp, and your filesystem driver or macOS puts hidden files with that extension that are not source files on the filesystem.
<nikunj97>
yes, that line includes every .cpp file there is
<nikunj97>
I think I have a method to implement what you want. I can allow every executable to link with static library and change the pattern depending upon an integer defined in hpx_main.hpp. I can check for it's value, if it matches then proceed with current implementation. Else switch back to previous implementation. Should I proceed with this method?
nikunj97 has quit [Quit: Leaving]
nikunj has joined #ste||ar
<hkaiser>
nikunj: yes, that sounds like what we want
<nikunj>
hkaiser: ok then I'll configure pkg-config in that way
<hkaiser>
nikunj: you might not have to do anything for pkg-config in this case
<nikunj>
I need to pkg-config to add libhpx_wrap.a