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/
<heller_>
pretty sure for the former, not sure about the latter
<heller_>
keep in mind that those packages don't exist for a very long time
<heller_>
and you will soon find yourself in a situation where you really want to use stuff from latest master
<grostig>
@heller_, so maybe I need to do a source compile?
<heller_>
that's be the easiest and most tested form to get HPX up and running
<grostig>
OK, I appreciate everyone's efforts. I'll try to do the compile and see how that goes. ;)
<grostig>
@diehlpk_mobile, @heller_ see above
<grostig>
@heller_, @K-ballo, @hkaiser, @diehlpk_mobile, HPX is so great it is worth the effort for me! Thanks everyone, you are making c++ catch up to "other languages" and we need that.
<K-ballo>
:) !!
<heller_>
a simple "pip install hpx" would have been appreciated ;)
<heller_>
but thanks!
<grostig>
@heller_, no not python, please..... I want hpx to do machine learning without python.
<heller_>
oh, you might want to look in phylanx ;)
<diehlpk_mobile>
thank you, i will try to improve the experience with the fedora packet manager
diehlpk_mobile has quit [Read error: Connection reset by peer]
<grostig>
To compile the hpx libs from source should I use master? or some other tag like 1.2.1.rc3? I need something that I can get help with as I learn hpx for applications programming.
<grostig>
heller_ seemed to imply I should use "latest master" even though I'm not developing the hpx libraries.
<heller_>
hpx master is pretty stable, usually.
<heller_>
the procedure doesn't really change whether you use master or a release
<grostig>
@heller_, ok so I'll just ask before I do a pull. Is now a good time?
<grostig>
I got the full git repository on my system, so I can start to compile the current stuff?
<hkaiser>
grostig: nod, go ahead
<grostig>
Clarification questions/issues on documentation should be made where? For example, I have g++ on fedora29, but cmake complains I need c++11 "std::atomic", well which one? There appear to be two packages on fedora: "atomic" and "atomic_ops" or do I need something else?
<diehlpk_mobile>
grostig, I now understand your issue with the hwloc package
<diehlpk_mobile>
it us again a fedora thing
<diehlpk_mobile>
hwloc contains only the executables of the hwloc package
<diehlpk_mobile>
hwloc-libs the libraries
<diehlpk_mobile>
hpx depends only on the hwloc-libs for hpx and hpx-examples
<diehlpk_mobile>
so there is no need to install these executables from the hwloc package
<diehlpk_mobile>
so no packages is missing, it is just a bad naming from Fedora
<grostig>
I can build a simple test with QtCreator with no problem.
<diehlpk_mobile>
Can you try dnf install libatomic?
<diehlpk_mobile>
this is a bug in fedora that gcc missed this lib
<grostig>
says it is already installed, and yes it is.
<grostig>
did try the command you asked for and above was the result.
<grostig>
I just updated the github issue with proof g++ can find it. Now cmake, apparently not....
<diehlpk_mobile>
Ok, can you use the 1.2.1 release candidate?
<diehlpk_mobile>
it compiles for me on Fedora 29
<diehlpk_mobile>
it is working on their build server
<grostig>
how do I make git give me that version, I'm on master now. I don't know how to do that in git.
<diehlpk_mobile>
download the tar file on github
<diehlpk_mobile>
we have a tab releases there
<diehlpk_mobile>
good luck, I have to leave. bye
diehlpk_mobile has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
<grostig>
Fix is to install libatomic and THEN clear out build directory and try again. Doesn't cmake do that? Guess not. I had just re-ran the cmake and it just kept failing. Can cmake properly restart without me having to know that I must remove the build dir contents manually? Also, documentation should reflect need for libatomic to be installed, since it is not by default when gcc-g++ is installed.
<grostig>
on fedora29
jbjnr has joined #ste||ar
<grostig>
@diehlpk_work: turn out this is how to get a tagged version from git: git checkout 1.2.1.rc3
<grostig>
@diehlpk_work: compile worked. thank you for your assistance.
<grostig>
@heller_: So I built from source master, with some problems, but got it. Then compiled, linked and dynamically liked cleanly, but still no output or error even with --hpx:debug-hpx-log. :( @diehlpk_work
<grostig>
@heller_: Could it be my c++17 or gnu++1z compile setting?
<grostig>
back tomorrow... bye
grostig has quit [Quit: Konversation terminated!]
jbjnr has quit [Ping timeout: 240 seconds]
jbjnr has joined #ste||ar
<simbergm>
trying to keep up with your conversation from yesterday... yeah, no more patch releases, just more frequent real releases ;)
david_pfander has joined #ste||ar
grostig has joined #ste||ar
<grostig>
.
<grostig>
@diehlpk_work: my own compile doesn't produce any output, but I tried a few examples in the cmake source built examples, including that "hello world" and it did get output.
<heller_>
grostig: I guess you somehow messed up compiling/linking
<heller_>
make VERBOSE=1 will show you the steps
<grostig>
heller_: yes, but how? I have already spent about 8 hours trying to get my "hello world" to work and have started to document other bugs (ie. cmake). The Stellar team has also spent hours helping me, thank you.the HPX's team members. I don't want to learn cmake, or
<grostig>
heller_: I need to be able to use simple make to compile HPX, and it has to be on fedora. The question is: does someone on the stellar team want to invest the time to figure that out and help me continue on this undocumented, not offically supported compile method.
<heller_>
grostig: as I mentioned yesterday, qmake supports pkg-config, use the pkg-config stuff
<grostig>
heller_: The method I meant to refer to was simple command line, or simple make.
<heller_>
use pkg-config
<grostig>
heller_: pkg-config sounds like another black magic box that I simply can't afford to learn at my age. The website for pkg-config, was severly out of date. I need quality documentation to even consider learning using a product.
<grostig>
heller_: Stellar does have very nice documentation, but the magic make stuff is "voodoo to me". I'm a programmer, not a system admin, or devops.
<grostig>
heller_: anyway, I need to think further about this. Thanks again for all your work, and perhaps I can figure something out now, or in the future.
<heller_>
grostig: well, you spent hours trying to get something to build. pkg-config isn't hard to learn, should take about an hour. It will give you 1) the proper command line for linking and compilng 2) ability to simply use a Makefile or the command line directly
<heller_>
another option would be to use hpxcc, if that's installed with fedora (this wraps the pkg-config magic you'd otherwise need to invoke yourself)
<heller_>
we all are programmers ;)
<grostig>
heller_: I'll take a look at it tomorrow, it is very late. if hpxcc is a wrapper, then I don't want it. I want unwrapped, basic no magic stuff. :)
<heller_>
cmake and pkg-config (or hpxcc) usually just work and are supported and automatically tested. At least for our official releases, aka not the fedora packages or any other linux distribution package
<heller_>
it's not magic, it's just computer programs
<heller_>
if you don't want to use that magic, I can't give you a guarantee that your stuff won't break in the future without an easy migration path
<grostig>
heller_: shell, make, vi and gcc will never go away (in my lifetime), and I with those build tools I don't need a migration path.
<heller_>
no, but building against HPX will evolve over time
<grostig>
heller_: I need sleeeeeep. bye :)
K-ballo has joined #ste||ar
<simbergm>
diehlpk_work:
<simbergm>
blah
<simbergm>
added 3593 and 3595 to release
<simbergm>
the two other gnuinstalldirs related prs didn't apply cleanly and have to run now
<simbergm>
continuing on monday...
<jbjnr_>
I'm grumpy
<K-ballo>
I guess I could be Bashful
<mdiers_>
Does a small example exist to make your own class serializable? I think I have a namespace problem with my attempts.
<K-ballo>
mdiers_: there are several different approaches to serialization, which one are you trying?
<jbjnr_>
mdiers_: tests/unit/serialization has several examples you might find helpful
<mdiers_>
K-ballo: the best and the closest to the standard is. my current is "friend void serialize( hpx::serialization::input_archive& ar, MyClass& data, unsigned int v ) {}" what is the third argument v for?
<mdiers_>
jbjnr_: Thanks, I'll take a look there.
<K-ballo>
there is no standard one
<K-ballo>
v is for versioning
<mdiers_>
K-ballo: ah, thanks
<K-ballo>
mdiers_: do you have an overload for output_archive too?
<mdiers_>
K-ballo: yes, .. after a recompile of the file it works. Which variant of the serialization should i use?
<K-ballo>
whichever fits your case best
<mdiers_>
K-ballo: versions handling is not needed, otherwise it can become also times more complex data structures.
<K-ballo>
ok
<mdiers_>
K-ballo: is there already a possibility to transfer for example a 3d volume compressed?
<K-ballo>
mdiers_: no, hpx knows nothing about compressed volumes, but there might be tools to transfer the underlying representatation (if it's an array, vector, etc... there's out of the box support for standard types and structs)
<K-ballo>
mdiers_: oh and in case "compressed" here stands for data compression, then there's a plugin that transparently compresses all outgoing serialized data
<mdiers_>
K-ballo: you mean the flags HPX_WITH_COMPRESSION_ at the hpx configuration? if one is set the compression is already active?
<K-ballo>
yes, those should be related. no, I don't know how the plugin is configured. docs should tell
hkaiser has joined #ste||ar
<mdiers_>
K-ballo: thank you very much. i'll continue reading the documentation.
daissgr has joined #ste||ar
<jbjnr_>
I'm grumpy
* zao
inserts cookies into jbjnr_
<jbjnr_>
how did you copy my grumpy statement and make it happen again?
<jbjnr_>
or did I accidentally hit a key and repost it
<jbjnr_>
FWIW I'm still grumpy
<hkaiser>
jbjnr_: FWIW, we love you
<jbjnr_>
lol
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
<heller_>
jbjnr_: what's up?
<jbjnr_>
My super cleaned up code is slower than the old dirty crap.
<jbjnr_>
But I'm adding a new soupy twist.
<heller_>
jbjnr_: I know that feeling!
<diehlpk_work>
simbergm, I talked to Harmut about the new patches
<diehlpk_work>
it is might too much for the point release
hkaiser has joined #ste||ar
<K-ballo>
how many patches did the point release end up having? do we really have that many showstopper issues?
<diehlpk_work>
K-ballo, I think 5
<diehlpk_work>
Currently a hardcoded path in our cmake files is the issue
<K-ballo>
:|
<diehlpk_work>
We assume that hpx is always installed to /usr/lib
<jbjnr_>
CMAKE_INSTALL_PREFIX should be used
<zao>
prefix/lib or actual /usr/lib?
<diehlpk_work>
On fedora it goes to /usr/lib64/ and cmake is broken
<zao>
(as opposed to prefix/lib64)
<diehlpk_work>
zao, it is hardcoded /usr/lib/cmake/HPX
<hkaiser>
diehlpk_work: as jbjnr suggested, CMAKE_INSTALL_PREFIX should help
<diehlpk_work>
zao set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "/usr/lib/cmake/HPX")
<zao>
ick
<diehlpk_work>
jbjnr_, hkaiser How would CMAKE_INSTALL_PREFIX update the hardcoded path?
<jbjnr_>
I didn't understan. It isn't supposed to be hardcoded. cmake should use that VAR. if it isn't then something needs fixing
<heller_>
it appears to be hard coded after it has been generated.
<hkaiser>
why is the directory wrong, then?
<heller_>
but it has been generated to have the location where to look for the cmake modules we need to include in order for projects to link against HPX
<heller_>
hkaiser: I have no idea
<heller_>
we know that it is broken for 1.2.0
<diehlpk_work>
heller_, yes, I run make -C ${mpi:-serial} tests.examples fir testing
<hkaiser>
ok, that explains it
<diehlpk_work>
But I do not test if we can compile a program using hpx
<heller_>
diehlpk_work: in which way does this test the installation?
<heller_>
that's bad
<heller_>
this should be something essential for a linux distribution packaging build system
<diehlpk_work>
We do not test the installation on the build system
<diehlpk_work>
I test the build on my local vm
<diehlpk_work>
I install hpx or updated and rum cmake there
<heller_>
that's nothing automated, and you obviously missed stuff
<diehlpk_work>
yes, I missed that it is not working on 64bit
<diehlpk_work>
We would need a new test for that
<heller_>
no, the fedora package needs that
<heller_>
this has nothing to do with our code
<diehlpk_work>
Yes, but I would need to have the code for doing this in the hpx.tar.gz
<heller_>
well, to some degree it does, but I am strongly oposed to add anything like testing distribution packages to our repository. This opens a pandoras box which I am not willing to maintain
<diehlpk_work>
I agree
nikunj97 has quit [Quit: Leaving]
<heller_>
we have a unit test that tests the build system in the installation directory
<heller_>
see, that's the reason we, as the group should not maintain those packages, suddenly it becomes our problem ;)
<diehlpk_work>
heller_, I can add the unit test for the installation directory
<heller_>
does this really test the actual package?
<heller_>
like missing dependencies etc?
<diehlpk_work>
The build system as far as I know does not install the package, it just uses the install dir to generate the packages
<heller_>
or a wrong split of tihngs in -devel/-whatever?
<heller_>
you should figure that out. I find it hard to believe that they accept packages without being actually tested
<diehlpk_work>
Running the examples is our test
<diehlpk_work>
Most other packages run their examples
<diehlpk_work>
heller_, if we do not maintain the package and one else would do it, he would report all these bugs
<diehlpk_work>
heller_, some people test their fedora packages, by downloading them to a vm and test them there
<grostig>
Good news: I got hpx source and examples built on fedora with recommened dependencies ( dependencies in the form of fedora packages for example boost etc.)
<grostig>
Good news: The example programs that are compiled by the big source build seem to work and do give some output. No errors on build, don't know it it runs at test suite or not.
bibek has joined #ste||ar
<grostig>
Good news: The simple helloworld program in the getting started when compiled manually from the command line using only g++ and linker does link and load and run.
<grostig>
Bad news: The simple helloworld program in the getting started, does not produce any output. This appears to be the same as before when I used the 1.2.0 fedora packages.
<heller_>
K-ballo: a chained continuation. A callable that is been invoked as a continuation, which is then triggering a remote continuation through the set_value_action remotely
<heller_>
grostig: the question: Did you try using hpxcc and/or pkg-config?
<hkaiser>
yah, doing three-way asyncs A->B->C and return whatever C returned
parsa_ is now known as parsa
hkaiser has quit [Quit: bye]
<grostig>
@heller_: No I have not. I searched for hpxcc and could not find any reference anywhere. Please provide I link.
<grostig>
@heller_: No I have also not decided to learn "pkg-config" to run a simple 10 line program.
<jbjnr>
do we have a hash function suitable for thread_id_type - or would it be ok to consider it a void*
<K-ballo>
should have an std::hash specialization already