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/ | GSoC: https://github.com/STEllAR-GROUP/hpx/wiki/Google-Summer-of-Code-%28GSoC%29-2020
<hkaiser> weilewei: ok
<hkaiser> that's not surprising, we've had all kind of MPI related issues before
<gonidelis[m]> hkaiser: yt?
<hkaiser> here
<hkaiser> gonidelis[m]: it's late for you ;-)
<gonidelis[m]> hkaiser: haha ... I happen to be on the country by the sea so it's good time for coding. Why did you use `get_second_element` on your copy CPO adaptation?
<hkaiser> because the implementation returns an in_out_result, but the algorithm API returns the 'out' part only (the second element)
<gonidelis[m]> hkaiser: is this defined in the standard? i mean the API return?
<hkaiser> yes, look at the spec
<hkaiser> what algorithm do you look at?
<gonidelis[m]> yeah... this one
<hkaiser> it returns just OutputIterator
<gonidelis[m]> Is this the return that you mean?
<gonidelis[m]> ahhhh....
<gonidelis[m]> ok!
<gonidelis[m]> So, I copy your get_second_element impl for transform and use it likewise?
<hkaiser> if you need the same code, move it to result_type.hpp
<gonidelis[m]> Well I have an OutputIterator return type too
<gonidelis[m]> So it's exactly the same case... I think.
<hkaiser> ok
<hkaiser> then please move the get_second_element functions to result_type.hpp and adapt the copy code accordingly
<gonidelis[m]> ok... That means that I put them under `util` namespace, right?
<hkaiser> yes
<gonidelis[m]> great! thanks a lot!
<gonidelis[m]> hkaiser: Should the CPO dispatch on the transform API function or on the `transform_` one?
<gonidelis[m]> the `transform_` function is used as a midpoint for the segmented part
<gonidelis[m]> so I should just forward to the non-segmented transform_ I think
<hkaiser> the cpo should forward to transform_
<gonidelis[m]> ok great
weilewei has quit [Ping timeout: 245 seconds]
hkaiser has quit [Ping timeout: 244 seconds]
kale[m] has quit [Ping timeout: 264 seconds]
Yorlik has quit [Ping timeout: 240 seconds]
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
nanmiao11 has quit [Remote host closed the connection]
akheir has quit [Quit: Leaving]
ben[m]2 has left #ste||ar ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
vroni[m] has quit [Quit: Idle for 30+ days]
<rori> I'm updating the docs with more recent versions, does anyone know which generator (version of visual studio) to use for cmake on windows like ` cmake -G "Visual Studio 9 2008"` but 2008 seems to be a bit outdated
<rori> ?*
<zao> rori: For current VS, it'd be something like: `-G "Visual Studio 16 2019" -A x64`
<rori> thanks :)
Yorlik has joined #ste||ar
<rori> is someone still trying the releases on xeon phi?
Yorlik has quit [Ping timeout: 246 seconds]
<K-ballo> x64 is the default for the 2019 vs generator
hkaiser has joined #ste||ar
Yorlik has joined #ste||ar
<rori> yes I just added the -G ;)
weilewei has joined #ste||ar
bita_ has joined #ste||ar
diehlpk has joined #ste||ar
diehlpk has quit [Changing host]
diehlpk has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
nanmiao11 has joined #ste||ar
akheir has joined #ste||ar
diehlpk has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
<kale[m]> I am getting this error while building HPX with tcmalloc on Releasr type build. I am using centos 5 docker with gcc 9.3.1. And boost 1.66. https://gist.github.com/git-kale/37d5072617621331a70a1b1e7501a355
nanmiao11 has quit [Remote host closed the connection]
nanmiao11 has joined #ste||ar
<K-ballo> that's odd.. while the code looks off, I don't think it should be rejected
<K-ballo> can't reproduce either.. must be something else
<kale[m]> K-ballo: Shall I try building on an older commit
<K-ballo> no, there haven't been changes to trim since it was introduced
<K-ballo> unless you mean to side-step the issue
<K-ballo> you are not using the old libstdc++ abi, are you?
<K-ballo> it looks from the error message as if you were using the 98 string implementation
<K-ballo> the code requires C++11 to work
<K-ballo> HPX further requires C++14 these days
<K-ballo> yeap, that reproduced it https://wandbox.org/permlink/KnsQv4BTV56uv2wG
<kale[m]> Oh I'm on manylinux docker and it doesnt allow compiling anything with new ABIs. CXXABI_1.3.7 and GLIBCXX_3.4.19 are maximum supported versions on the sustem
<K-ballo> the code _could_ be made to work with C++98's std::string, at least in this instance, but I doubt such a thing is worth it
nanmiao11 has quit [Remote host closed the connection]
nanmiao11 has joined #ste||ar
weilewei has quit [Remote host closed the connection]
kale[m] has quit [Ping timeout: 256 seconds]
nanmiao11 has quit [Remote host closed the connection]
kale[m] has joined #ste||ar
mcopik has joined #ste||ar
nanmiao11 has joined #ste||ar
weilewei has joined #ste||ar
mcopik has quit [Remote host closed the connection]
mcopik has joined #ste||ar
mcopik has quit [Read error: Connection reset by peer]
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
<gnikunj[m]> has anyone tried building hpx on rostam recently? I'm getting the following error log: https://gist.github.com/NK-Nikunj/16e9eb1598d554cba656920156284eaf
<gnikunj[m]> the error looks to be related to hwloc linking
<gnikunj[m]> its the first time I'm seeing this error. It builds fine on my machine btw.
<K-ballo> "The old string is old, and is not going to be maintained to track the current C++ standard."
<K-ballo> kale[m]: that's the bug you are hitting ^
<kale[m]> K-ballo: Thanks! I'm not going for the manylinux approach, since no one is going to use Phylanx on an ancient machine. And we have a wheel that works on any recent linux system :)
<weilewei> hkaiser @patrick The arm machine is onsite in stony brook Unit now, in theory, access will be sent around next two weeks.
<hkaiser> weilewei: nice! thanks for asking
<weilewei> hkaiser yea, sure, my pleasure.
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
<gnikunj[m]> weilewei: what processors do the machine have?
<weilewei> gnikunj[m] the fukaku-like machines
bita_ has quit [Ping timeout: 260 seconds]
<gnikunj[m]> a64fx?
<weilewei> yes
<gnikunj[m]> nice!
<akheir> gnikunj[m]:yt?
<gnikunj[m]> akheir here
<akheir> which problem again? the file system or sudo?
<gnikunj[m]> File system
<gnikunj[m]> Sudo works fine
<akheir> I'll look into it.
<gnikunj[m]> Thanks! Also could you try building hpx? There seems to be a weird error that I can't reproduce on my local machine
<akheir> let me look
<gnikunj[m]> Thanks a lot!
<akheir> how do you build HPX on rpi? which compiler and flag you use?
<gnikunj[m]> Not on rpi. Hpx is not building on x86
<gnikunj[m]> I tried on head node and medusa
<akheir> again which compiler and which flags?
<gnikunj[m]> I have the standard set of modules included and use:
<gnikunj[m]> mkdir build && cd build && cmake .. && make -j $(nproc)
<akheir> which modules did you load?
<gnikunj[m]> I use gcc 9.3
<gnikunj[m]> Gcc 9.3, boost 1.73 release, hwloc 2.2 are the most important ones I believe
<gnikunj[m]> Let me share the exact config wait.
<nanmiao11> gnikunj[m] I have built hpx 5 days before
<gnikunj[m]> nanmiao11: did you face issue similar to this: https://gist.github.com/NK-Nikunj/16e9eb1598d554cba656920156284eaf
<gnikunj[m]> akheir: also, I'm using hpx master right now
<nanmiao11> gnikunj[m] No. I built successfully. The difference module I used is clang/10.0.0
<nanmiao11> Is hpx master a stable one?
<gnikunj[m]> nanmiao11: I see. I'll try with clang/10.0.0 then
<gnikunj[m]> yes and no. At least it is supposed to be ;-)
<nanmiao11> git clone https://github.com/STEllAR-GROUP/hpx.gitcd hpxgit checkout tags/stablemkdir build && cd buildThese are steps Bita shared to me
<nanmiao11> use "git checkout tags/stable"
<gnikunj[m]> yes, stable is the stable tag
<nanmiao11> Then, I am not sure what is the problem...
<gnikunj[m]> they issue seems orthogonal to stable vs master in my opinion. But I'll give it a shot wait
<gnikunj[m]> nanmiao11: yup stable doesn't help in building either
<gnikunj[m]> I'll try with clang. It may help
<akheir> gnikunj[m]: Fixed the Pis. Something stupid goes on Ubuntu server. Whenever this happened just do `sudo reboot`
<gnikunj[m]> akheir: alright thank! Also, I think ik why hpx is not installing. I have a stupid export that adds hwloc path
<gnikunj[m]> and even though the path is appended to LD_LIBRARY_PATH, it seems to be confused between selecting one
<akheir> hmm, could be.
<gnikunj[m]> I'm trying to rebuild now. If it doesn't build I'll let you know
<gnikunj[m]> akheir: it works now. I don't know why it would confuse when there's a clear order to it :/
weilewei has quit [Remote host closed the connection]
<akheir> many times cmake has its own ideas. This is not the first time we ran into this issue. That's why we try to minimize system installed libraries and exclusively use modules
<gnikunj[m]> Makes sense
weilewei has joined #ste||ar
<weilewei> hkaiser I plan to run experiment/benchmark these days, and plan to use 1.5.0-rc1 for now. Any suggestions?
<hkaiser> weilewei: yes, that's fine
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar