hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 240 seconds]
FunMiles has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
FunMiles has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
srinivasyadav227 has quit [Ping timeout: 250 seconds]
jedi18[m] has quit [Ping timeout: 245 seconds]
srinivasyadav227 has joined #ste||ar
ms[m] has quit [Ping timeout: 245 seconds]
jedi18[m] has joined #ste||ar
ms[m] has joined #ste||ar
sestro[m] has quit [Quit: You have been kicked for being idle]
hkaiser has joined #ste||ar
KordeJong[m] has joined #ste||ar
<hkaiser>
ms[m]: I think I know what happens to the slurm job (clang-newest) for the scoped execution PR
<ms[m]>
hkaiser: nice
<ms[m]>
I just got this from a debug build: `{what}: Assertion 'magic == debug_magic' failed: HPX(assertion_failure)`
<ms[m]>
tests.regressions.modules.actions.function_argument is the first test to time out
<hkaiser>
the changes cause many tests to hang *sigh* which makes the slurm job time out and being killed
<ms[m]>
yes
<hkaiser>
I'm glad the PR is still draft, so it's not as embarrassing ;-)
<ms[m]>
tests.regressions.modules.actions.function_serialization_728 also times out right after it
<ms[m]>
right, we'd have hung you otherwise!
<hkaiser>
but seriously, seems I don't fully understand the consequences of scoped execution yet at it tends to create deadlock situations
<hkaiser>
ms[m]: that assertion, no idea where that's being triggered
K-ballo has joined #ste||ar
<ms[m]>
hkaiser: right, I can give you the stacktrace etc. but I was more wondering if you can reproduce the hangs with those two tests
<ms[m]>
hangs/assertions failing
<hkaiser>
ms[m]: I will try doing that today
<ms[m]>
👍️
<ms[m]>
just let me know if I can fish out some more information from the linux builds
<hkaiser>
the gcc9 builds on rostam fail similarily, there I can access the logs - but thanks!
<ms[m]>
hkaiser: regarding #5536, it sounds like msvc is checking that an iterator is destructed before whatever it's pointing to gone, but are we actually dereferencing those iterators?
<ms[m]>
did I misunderstand what the check is or is msvc just being very eager?
<hkaiser>
yes
<hkaiser>
it checks whether an iterator is still valid at the point of its destruction
<hkaiser>
even if its not dereferenced
<ms[m]>
hkaiser: so was there an actual bug there as well?
<hkaiser>
yes, that's a flyby
<hkaiser>
but that one didn't cause issues with the tests
<hkaiser>
first = last works only if last is an iterator, I changed it to use advance_to_sentinel
<hkaiser>
but that's unrelated
<hkaiser>
to answer your question: there was no actual bug
<ms[m]>
thanks, gotcha
<jedi18[m]>
Btw the clang-format on the PRs and Visual Studio are inconsistent in how they deal with a space between two paranthesized expressions (#5536 has it too so it's not specific to my VS). Any idea how to fix that?
<hkaiser>
arghhh
<hkaiser>
I'll go back and fix this - clang-format versions again
<hkaiser>
jedi18[m]: I usually fix this manually
<jedi18[m]>
hkaiser: Okk, I'll try finding another fix
<rori[m]>
There is already `SpaceAfterCStyleCast: true` in the .clang-format file so maybe it's just that the circleci step doesn't use the custom configuration for clang-format, you might want to add -style=file to the cicleci clang_format step in the `.circleci/config.yml` file
<ms[m]>
jedi18, hkaiser are you able to explicitly install clang-format-11?
<jedi18[m]>
ms: I don't see a setting for the clang-format version, but there is a "use custom clang-format.exe file". Could that be used?
<ms[m]>
most likely...
<hkaiser>
rori[m]: it's just that newer clang-format versions use the SpaceAfterCStykeCast setting for the (max)() construct as well, which is questionable in the first place
<K-ballo>
wut? that's not a c-style cast
<hkaiser>
exactly
<ms[m]>
is it actually using that setting or are you guessing it's related?
<hkaiser>
pure conjecture
<ms[m]>
easy enough to test ;)
<hkaiser>
well, if I set the setting to false it doesn't do that