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/
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
EverYoun_ has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoung has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
<parsa[w]>
hkaiser: i have no clue why that inspect in that PR fails.
<parsa[w]>
where do find the log for each build?
<parsa[w]>
where do i*
<parsa[w]>
found it.
EverYoung has quit [Remote host closed the connection]
<heller_>
hkaiser: tests.unit.performance_counters.reinit_counters times out for me every now and then
<heller_>
any ideas?
<heller_>
and good morning
<hkaiser>
heller_: no idea, frankly
<hkaiser>
g'morning
<hkaiser>
btw, we have to avoid including iso646.h for msvc - those idiots '#define and &&' and similar there as the compiler does not understand 'and' as a keyword
<github>
hpx/master ff49251 Hartmut Kaiser: Don't #include ciso646 for MSVC as it contains '#define and &&' and similar
<heller_>
hkaiser: microsoft is the best
<github>
[hpx] sithhell force-pushed coroutine_cleanup from 6f3f08b to 9e1648c: https://git.io/vNyr8
<github>
hpx/coroutine_cleanup 9e1648c Thomas Heller: Cleaning up coroutine implementation...
<K-ballo>
what's wrong with including ciso646?
<K-ballo>
yeah, it should be empty, but `and` and `not` and friends are part of the core language
<K-ballo>
sounds like a symptom of a problem
<heller_>
hkaiser: also, any idea on when rostam will be back on track?
<heller_>
regarding buildbot
<simbergm>
heller_: current batch of jobs is not done, but so far it looks like it might be back to normal
<heller_>
simbergm: excellent
<heller_>
intel is marked as CXX14_CONSTEXPR capable, but fails to compile the thread_data stuff :/
<heller_>
thread_id_type stuff
<K-ballo>
adjust the feature test to match the usage
<K-ballo>
or drop the constexpr, is hardly worth it
<K-ballo>
btw the constexprs on the relational operators are never constant expressions since the pointers are not related
<hkaiser>
heller_: no idea - it's that papi problem
<heller_>
hkaiser: looks like it is back normal though
<K-ballo>
and we should flag constexpr (11) as required if we are going to use it unconstrained it
<heller_>
I thought it already was required
<hkaiser>
K-ballo: ciso646 is #defin'ing 'and' and friends which breaks other code
<hkaiser>
heller_: not sure about cuda (constexpr)
<K-ballo>
hkaiser: sounds like broken other code, adding ciso646 cannot break standard code, removing it can break it
<hkaiser>
K-ballo: it breaks boosts #include SOME_SYMBOL_EXPANDING_TO_FILENAME_INCLUDING_and
<K-ballo>
sounds like broken boost
<hkaiser>
sure, nothing we can do about that, can we?
<K-ballo>
or that we want to
<hkaiser>
wouldn't help with older versions anyways
<K-ballo>
that's fine, as long as we've determined the cause before treating the symptom
<heller_>
hmm, that usecase seems to compile fine on compiler explorer :/
<hkaiser>
yes, I know what's happening
<hkaiser>
heller_: happens when using clang-tidy only
<K-ballo>
heller_: a good check for the cxx14 constexpr feature test would be that a constexpr member function isn't implicitly const, perhaps by overloading on const vs non-const
<heller_>
"error #137: expression must be a modifiable lvalue"