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/
* parsa[w]
*pings* hkaiser
EverYoun_ has quit [Ping timeout: 255 seconds]
<hkaiser>
parsa[w]: here
<parsa[w]>
hkaiser: i forgot to ask you this: right now i have to do a "#define NOMINMAX" to get Blaze work with HPX on Windows
<parsa[w]>
does hpx include windows.h anywhere?
<hkaiser>
parsa[w]: yah, that's a blaze problem - alternatively include hpx/config.hpp first
<hkaiser>
parsa[w]: yes
<hkaiser>
or no, config.hpp might not help
<hkaiser>
just define NOMINMAX, then
<parsa[w]>
where is the right place to put it? i put in the project's property pages
<hkaiser>
add it to cmake
<parsa[w]>
something like if windows, add_definitions(-DNOMINMAX)?
<heller>
not completely at a stage where I ultimately want to end up in, but getting there...
<hkaiser>
thanks for pushing this
<hkaiser>
each of those tasks takes up one of the 4 instances we have, right?
<heller>
yes
<heller>
the only really long running ones are unit_tests and headers_tests
<hkaiser>
so if the slowest tasks runs longer than a quarter of the previous old time we loose
<heller>
all others run in less than 27 minutes
<hkaiser>
roughly speaking...
<heller>
tests.regressions runs in 21 minutes, this is including actually running the tests
<hkaiser>
but it looks nice
<hkaiser>
so we should split the long running tasks as well
<heller>
yeah, let me split the unit test one
<heller>
not sure how to split the headers tests
<hkaiser>
nod
<heller>
too bad I can't include other yaml files
<heller>
so the main file doesn't blow up...
<jbjnr>
heller: you can split the tests up arbitrarily by running ctest -R regex1 and ctest -R -E regex1
<heller>
yes, I know
<jbjnr>
(skip the second -R)
<heller>
the question is which regex to choose for the header tests
<heller>
ha! actually easy cheesy ;)
<jbjnr>
I've never run the header tests - what do they test?
<jbjnr>
I only test unit and regression
<jbjnr>
(and for the record hkaiser I'd like to see regression tests removed and just made part of unit testing)
david_pfander has joined #ste||ar
<K-ballo>
does that mean we only get one build at a time? won't builds in the queue work on their own steps while another build is busy with unit tests?
david_pfander1 has joined #ste||ar
mcopik has quit [Ping timeout: 240 seconds]
<jbjnr>
K-ballo: not sure if you're asking me, but partially yes. I only dislike regression tests cos they don't need tro be special, they should just be incorporated in nit tests where necessary
<jbjnr>
(building the tests can be split by using a mek rule for halk, and another for the other helf, same as ctest does)
<jbjnr>
^make rule for half. crumbs my typing
<K-ballo>
no, I was asking about circle 2.0, I imagined it to be pipeline-like
<jbjnr>
it seems driven by dependencies - so each branch of the pipeline can run when the parents are done
<K-ballo>
in my mind regression tests are special in that they are not curated, someone reported a bug and just dumped a test on us
<hkaiser>
K-ballo: if an instance is freed from on build (because its busy with just header tests for instance) it can work on another build - I hope
<K-ballo>
they certainly could be turned into proper unit tests, if someone had the time to do the work
<hkaiser>
K-ballo: yes, I agree
<hkaiser>
what's the point? just leave them as is
mcopik has joined #ste||ar
<hkaiser>
jbjnr: what would be the point of removing the regression tests?
<jbjnr>
no real point. I just said I don't like them - I guess because they';re not curated as K-ballo pointed out. they just hang around and accumulate and many are probably not valid any more
<hkaiser>
jakemp: why not valid?
<hkaiser>
jbjnr: ^^
<hkaiser>
they prevent us from reintroducing old problems
<jbjnr>
you find a bug, fix it, write a regression test, but then years go by and the code changes and the bug probably can't happen in quite the same way in some of thetests. so they are testing stuff that might be obsolete.
<hkaiser>
jbjnr: as long as they pass they can't be obsolete - I think
<jbjnr>
(not saying they are not useful, just if they were integrated into unit tests and maintained more it'd be better)
<hkaiser>
sure - pain in the butt to integrate them, though
<hkaiser>
K-ballo: I'd like to merge heller's PR first now as the solved problem causes endless failures in other spots
<hkaiser>
would it be ok to wait for another day with the async pack stuff?
<heller>
hkaiser: I think it is ready, this affinity failure is strange though
<jbjnr>
they should be run last then. They are less important than the actual unit tests etc. From the current build I see one task running and it's doing headers. almost 4 minutes in, when unit tests have not run
<heller>
or faster machines... there now is an option to get larger VMs ... but only for paid plans ...
hkaiser has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
<heller>
jbjnr: well, if at all, they should be run first ... since they are almost as annoying as the inspect tests
<heller>
K-ballo: cool, does this lead to faster builds?
<K-ballo>
yeah, like half or less, is only parsing and no codegen/linking
<jbjnr>
nice!
<K-ballo>
but there were caveats
<heller>
great
<K-ballo>
I no longer remember, that patch is old
<heller>
ok
<K-ballo>
is what I've been using for my header reports
<K-ballo>
I suspect something having to do with how all the compilation flags have to be replicated manually
<heller>
hmmm
<jbjnr>
I disagree that these tests should be run first. I want to see real failures first then cosmetic ones later (apart from inspect, because it is so annoying and every PR fails because of it first time).
<heller>
jbjnr: ok, changed
<jbjnr>
:)
<jbjnr>
thanks
<heller>
jbjnr: I'll wait until pushing, i want this to run first
<jbjnr>
why is only sub task running - are there other builds taking resources
<heller>
yes
<heller>
we'd need to pay to get more resources
<heller>
I asked if we get it for free though
<heller>
let's see what they'll answer
diehlpk has quit [Quit: Leaving]
<heller>
now we have two running!
<heller>
yay
<heller>
overall, I am pretty happy with this setup now
<heller>
at least, we are getting proper failures
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
<heller>
you reference the different steps here, and set requirements
<heller>
it's a small pain, step generators would help to avoid all the repetition
pree has quit [Ping timeout: 248 seconds]
<github>
[hpx] sithhell force-pushed channel_direct from 9b76d1d to 3c5fdf2: https://git.io/vdiJE
<github>
hpx/channel_direct 3c5fdf2 Thomas Heller: Changing channel actions to be direct
<K-ballo>
hkaiser: I'll look at #2904 and related again after the traversal stuff is merged, and I can start cleaning up the dataflow monstrous overload set
<github>
[hpx] sithhell force-pushed circle_2 from 758a522 to 39080e1: https://git.io/vdKfd
<github>
hpx/circle_2 39080e1 Thomas Heller: Switching to CircleCI 2.0
aserio has quit [Ping timeout: 248 seconds]
aserio has joined #ste||ar
<hkaiser>
K-ballo: much appreciated
<github>
[hpx] hkaiser created fixing_2137 (+1 new commit): https://git.io/vdiks
<github>
hpx/fixing_2137 d6c9502 Hartmut Kaiser: Adding explicit feature test for thread_local...
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
mcopik has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 246 seconds]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<github>
[hpx] hkaiser force-pushed fixing_2137 from d6c9502 to 615fe65: https://git.io/vdiCb
<github>
hpx/fixing_2137 615fe65 Hartmut Kaiser: Adding explicit feature test for thread_local...
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
aserio1 is now known as aserio
mcopik has quit [Ping timeout: 255 seconds]
<jbjnr>
the dashboard does not how the status of examples being built does it?