aserio 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/
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoun_ has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
EverYoung has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
diehlpk has joined #ste||ar
Smasher has quit [Remote host closed the connection]
katywilliams has joined #ste||ar
katywilliams has quit [Ping timeout: 264 seconds]
EverYoung has quit [Remote host closed the connection]
<thomasd>
(I'm aware the code is incomplete and will block at some point anyway, because nothing gets sent to those channels yet, but as far as I understand, it shouldn't block at that point ;-) )
<jbjnr>
if the row above hasn't put something into the channel yet - it will block
<jbjnr>
oh. it should return a future no block, is that what's wrong
<diehlpk_work>
simbergm, I will test the relase candidqate with BLAZE today
<jbjnr>
thomasd: it should return a future. looking at the channel code, I can't see anything wrong. Are you sure it's blocking there? Do you have a stack trace?
<thomasd>
no stack trace, I'm using "std::cout" print statements to see where it gets. I'm quite sure :)
<thomasd>
strange thing is, it does return a future the first time I hit that point, but blocks on the second iteration
<simbergm>
diehlpk_work: thanks!
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 245 seconds]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa has quit [Client Quit]
mcopik has quit [Ping timeout: 256 seconds]
katywilliams has quit [Ping timeout: 248 seconds]
hkaiser has joined #ste||ar
mcopik has joined #ste||ar
<jbjnr>
thomasd: ok, on the second iteration it will block. The channel will only let you have one at a time, it's not intended to be used like a cuda stream, where you can trigger multiple callbacks at the same time.
<jbjnr>
it could be made to work that way, but I don; think it supposed to give multiple futures, you have to use on, then get the next.
<jbjnr>
mind you, that might be a bad design. Being able to have multiple would be very useful and there's no real reason why not
<jbjnr>
hkaiser: yt? what's your view on it?
<zao>
`rc-run3.log:99% tests passed, 1 tests failed out of 561`
<zao>
Our good old friend `166 - tests.unit.components.distributed.tcp.migrate_component (Failed)`
<parsa[[w]]>
hkaiser: added reverse ranges
parsa[[w]] is now known as parsa[w]
<zao>
If it's modelled on Go channels, they have an optional buffer capacity for non-blocking. Default there is to block both reader and writer, so I guess we're diverging a bit already.
<thomasd>
Ah, ok, it didn't occur to me that it would block after the first get() by design.
aserio has joined #ste||ar
<zao>
The gist doesn't build on my checkout of the RC btw.
<zao>
Missing unwrapped.
mcopik has quit [Ping timeout: 256 seconds]
jakub_golinowski has joined #ste||ar
<thomasd>
zao: hmm sorry about that, maybe I edited the file since last test, let me check
<thomasd>
(it's a reduced/bastardized version of the code)
<zao>
Wait... where the heck did the commit I'm building go?
<zao>
You may have to disregard the above... I have no idea where I am.
EverYoung has joined #ste||ar
katywilliams has joined #ste||ar
<thomasd>
by the way, get()'ing multiple times from a channel without does immediately return the futures in a simpler example I have
<jbjnr>
thomasd: ok, if we are allowed multiple futures, then I'll need to build and test the example to help you, but I'm snowed under with things to do right now, so can't look at it for a bit. Perhaps one of the others might. zao seems like he's going to ive it a try...
<zao>
It doesn't exist in the tree at all.
<K-ballo>
simbergm: presumably it exists only in your index
<thomasd>
unfortunately I have to leave now... I'll try to further reduce my example and see where the problem comes from exactly. thanks for having a look!
thomasd has left #ste||ar ["ERC (IRC client for Emacs 25.3.1)"]
<zao>
jbjnr: Gods no.
<simbergm>
huh, my local tag is fee6ba2 and so is the one on github
<zao>
even with `git -C repos/hpx.git fetch --all --tags` there's no change.
<zao>
Seems like there's some variation in the past how the tag has been cut.
<zao>
In any way, it seems like I could refer to the annotated tag's object name and it resolved to the commit it was a tag for.
EverYoung has quit [Ping timeout: 276 seconds]
<zao>
Isn't git wonderful?
EverYoung has joined #ste||ar
<zao>
The core bug here was that my scripts used `git rev-parse` and not `git rev-list -1`.
<zao>
For unannotated tags and regular commits, they do the same thing.
<zao>
For annotated tags, the former yields the tag object, while the latter yields the actual commit object.
jakub_golinowski has quit [Quit: Ex-Chat]
david_pfander has quit [Ping timeout: 268 seconds]
mcopik has joined #ste||ar
Smasher has joined #ste||ar
<zao>
git rev-parse --verify '1.1.0-rc1^{commit}'
<zao>
Victory!
mcopik has quit [Ping timeout: 240 seconds]
<parsa[w]>
hkaiser: ping
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
jaafar has joined #ste||ar
Anushi1998 has quit [Quit: Leaving]
<katywilliams>
I'm currently rebuilding the latest version of phylanx and I get the following error:
<katywilliams>
[100%] Building CXX object python/src/CMakeFiles/phylanx_py.dir/phylanx.cpp.o
<katywilliams>
In file included from /home/kwilliams/software/phylanx/python/src/bindings/execution_tree.cpp:11:
<katywilliams>
In file included from /home/kwilliams/software/phylanx/python/src/bindings/type_casters.hpp:15:
<katywilliams>
/opt/mn/pybind11/2.2.0/include/pybind11/stl.h:162:20: error: non-const lvalue reference to type
<katywilliams>
'__bit_reference<...>' cannot bind to a temporary of type '__bit_reference<...>'
<katywilliams>
for (auto &value: src) {
aserio has joined #ste||ar
<katywilliams>
This then causes multiple errors "no matching function for call to 'cast'"
<katywilliams>
Any ideas what could be the issue?
<zao>
Has it previously built right with this toolchain, and what toolchain is this on?
<diehlpk_work>
simbergm, Could compile release candidate without any issues
<zao>
So could I, only test to fail over 17 full runs is tests.unit.components.distributed.tcp.migrate_component
<zao>
(same old, same old)
<hkaiser>
katywilliams: what version of pybind do you use?
<katywilliams>
pybind11/2.2.0, which is the version I used previously when it worked
aserio1 has joined #ste||ar
<hkaiser>
katywilliams: could you try using pybind top of master instead?
aserio has quit [Ping timeout: 245 seconds]
aserio1 is now known as aserio
<K-ballo>
sounds like a vector of bool
<zao>
ohgods
<zao>
Incompatible with range for, is it?
<K-ballo>
with `for (auto& value: src)`
<K-ballo>
because the type of value is reference to __bit_reference
EverYoung has quit [Ping timeout: 265 seconds]
<diehlpk_work>
Do we have filesytem issues on rostam? Copying and deleting files is very slow
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
mcopik has joined #ste||ar
EverYoung has joined #ste||ar
hkaiser has joined #ste||ar
daissgr has joined #ste||ar
<katywilliams>
Installing Phylanx worked on rostam with these dependencies (cmake/3.9.0, binutils/2.28, clang/5.0.0, boost/1.65.1-clang5.0.0-debug, pybind11/2.2.0, hwloc/1.11.3) back with HPX (479520e) and Phylanx (d386a2e) but now I am using HPX 8dace88 and Phylanx bab57d9 [with hwloc/2.0.0 instead of hwloc/1.11.3]
<hkaiser>
katywilliams: so it still doesn't compile for you?
<zao>
Note that hwloc/2 is still not supported properly in HPX, I believe.
<zao>
Unless someone actually fixed it while I looked away.
<katywilliams>
As of when I tried this morning, correct, gets to 100% but I get "error: non-const lvalue reference to type '__bit_reference<...>'"
<hkaiser>
katywilliams: strange, we're not seeing this anywhere else
<hkaiser>
simbergm: have you merged the hwloc/2 PR?
<K-ballo>
katywilliams: more context? could you link to the line with the range based for?
<hkaiser>
zao: seems the hwloc/2 fix has been merged
<zao>
Ooh.
<heller>
yeah, hwloc/2 should be good
<heller>
the unit tests are green
<katywilliams>
Here's more of the error, if it helps:
<katywilliams>
[100%] Building CXX object python/src/CMakeFiles/phylanx_py.dir/phylanx.cpp.o
<katywilliams>
In file included from /home/kwilliams/software/phylanx/python/src/bindings/execution_tree.cpp:11:
<katywilliams>
In file included from /home/kwilliams/software/phylanx/python/src/bindings/type_casters.hpp:15:
<katywilliams>
/opt/mn/pybind11/2.2.0/include/pybind11/stl.h:162:20: error: non-const lvalue reference to type '__bit_reference<...>'
<katywilliams>
cannot bind to a temporary of type '__bit_reference<...>'
<katywilliams>
for (auto &value: src) {
<katywilliams>
^ ~
<katywilliams>
/home/kwilliams/software/phylanx/python/src/bindings/type_casters.hpp:141:53: note: in instantiation of function