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/
jaafar has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
jaafar has joined #ste||ar
jaafar has quit [Ping timeout: 250 seconds]
K-ballo has quit [Quit: K-ballo]
EverYoung has quit [Ping timeout: 246 seconds]
taeguk has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 250 seconds]
pradeepisro49 has joined #ste||ar
david_pf_ has joined #ste||ar
david_pf_ has quit [Quit: david_pf_]
david_pf_ has joined #ste||ar
david_pf_ has quit [Client Quit]
pradeepisro49 has quit [Quit: Connection closed for inactivity]
<hkaiser>
why can't we hook our resources into github?
<hkaiser>
in the end it's just a git repo that runner needs
<heller>
I haven't found a tool that's capable of doing that with github yet
<heller>
and discussion: that's why I wrote the email in the first place
<hkaiser>
heller: I think that a) for political reasons, gitlab is inferior to github, and b) it's most confusing to people to have more than one 'main' user-facing repo
<heller>
I agree with b)
mcopik has joined #ste||ar
<hkaiser>
nobody cares about gitlab, it's a mostly academic thing
<hkaiser>
95% of all OSS happens on github
<hkaiser>
in terms of features they provide, github is mostly running after github
<hkaiser>
gitlab is running after github*
<heller>
from a first look, the service offered by gitlab is superior. If you ask me, there is nothing wrong with having a read only mirror on github, and something else where the development happens
<hkaiser>
no
<hkaiser>
github has to be th emain read-write repo
<hkaiser>
hide your gitlab repo somewhere as read-only for the CI, fine by me
<heller>
then this is a dead end.
<hkaiser>
what serives are superior? I don't see any
<hkaiser>
shrug
<hkaiser>
also why is that a dead end if mirroring is seamless as you said
<heller>
bryce said mirroring the repo, issues etc. is seamless
<heller>
I say, mirroring the code is seamless
<hkaiser>
ok, my point still holds
<hkaiser>
that's all you need
<hkaiser>
I don't care if the tickets are missored properly to a helper repo used for CI purposes only
<hkaiser>
mirrored*
<heller>
the gitlab UI integrates with the gitlab CI, if we stick with github as our main development, there is no much gain for using gitlab CI, as we loose the integrated reporting facilities (marking PRs as good etc)
<hkaiser>
heller: so please tell me - what is so superior
<heller>
hkaiser: well, if the CI interface they offer works well for our needs, than this would be one thing
<hkaiser>
what are 'our needs' we can't service with github?
<heller>
the UI in general offers a few nice features, like resolving conflicts for PRs, creating branches from issues
<hkaiser>
all of that can be done with github as well
<heller>
hkaiser: using all the resources we have available to test PRs and the master branch
<hkaiser>
heller: pls be more concrete - why can't we use 'all the resources we have available'?
<heller>
because there is no service that is able to trigger those
<hkaiser>
huh?
<hkaiser>
don't we do that already?
<heller>
where?
<hkaiser>
isn't buildbot being triggered ?
<heller>
only for master.
<heller>
is buildbot able to trigger the machines at CSCS or FAU?
<hkaiser>
shrug
<heller>
right
<heller>
gtg
<hkaiser>
show me the docs describing how to do that with gitlab
<hkaiser>
heller: be more concrete, pls - I'm not going to read all of this
<heller>
hkaiser: essentially, you have one yaml file describing the build (as we have for circle right now as well), and then we can register runners to execute those, that run on our machines
<hkaiser>
I don't see how this can be done without additional support specific to the resources to run on
<hkaiser>
so we have to write our own handlers for our resources
<hkaiser>
if that is true we could use the same energy/effort to write our own handlers to integrate with github
<diehlpk>
What about using Jenkins or something similar for our resources
<diehlpk>
I did it before and it was going very well
<K-ballo>
I seem to recall two distinct efforts to use Jenkins
<heller>
hkaiser: I am not saying it can't be done with github alone, just requires more effort to implement it
<heller>
hkaiser: that's what jbjnr and zao try to right now, writing their own handlers
<heller>
I'd like to test the gitlab runners nevertheless
<heller>
not sure if they'll work when PRs are submited via github though
<heller>
from a UI perspective, gitlab and github seem to be more or less equivalent. It's true that more users will look at github first
taeguk has quit [Ping timeout: 260 seconds]
<heller>
So yeah, delicate issue.
<heller>
If buildbot would only support ssh worker...
<hkaiser>
heller: in my book, gitlab looks decent for linux users only, github is much more polished and modern
<heller>
Ok ;)
<hkaiser>
;)
<heller>
I think it's not worth it to have gitlab just as our CI backend...
<hkaiser>
k
<heller>
And I'm not sure overall if those gitlab runners are a 100% for us
<heller>
+fit
<heller>
So looks like a dead end after all
jaafar has joined #ste||ar
<heller>
Regarding the gitlab vs. GitHub problematic. There are various big open source projects (llvm, kde, gcc, qt) which only have a read only mirror on GitHub
<K-ballo>
llvm and gcc are both still on svn
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
<heller>
K-ballo: the point I'm trying to make is that the popularity/usage of a oss project does not depend on where the code is hosted or where development is tracked and managed
<K-ballo>
I wouldn't expect it to affect popularity/usage, but it does increase the difficulty to contribute
K-ballo has quit [Read error: Connection reset by peer]
<zao>
No-one ever got fired for using Github :P
K-ballo has joined #ste||ar
<K-ballo>
thunderbird crashed...
<zao>
Sounds par for the course.
<K-ballo>
where the code is hosted and how development is tracked affects how people get involved with it
<heller>
Sure
<K-ballo>
kinda how people don't care for submitting issues to boost old track, but don't mind doing so on github
<heller>
You can log into gitlab with a github account
<K-ballo>
you don't even need to login to boost old track
<zao>
Assuming you can tolerate the criminally slow servers and figure out Trac syntax :)
<zao>
(my two öre, mirroring repos wherever for testing purposes, super cool)
<heller>
I'm not saying we should move away from github just like that. I'm just throwing out a possible solution on how to improve our testing
<heller>
If we need to write adapters etc to listen to PRs, we almost wrote our own service anyway
<zao>
I'm trying to figure out the state of PRs from a --mirror checkout alone... might have to use GH API for it.
<heller>
Yeah
<heller>
I mean, triggering builds and update the status for PRs should be relatively straight forward, I think. The hard part is what Jenkins and buildbot does. That is managing resources and matching builds to resources
<heller>
The downside of buildbot/Jenkins compared to circle/Travis/appveyor is that once our resources go down, we're stalled
<heller>
And none of those come with native slurm support
<heller>
My idea for a solution would be one master that dispatches to the worker via ssh, those just run the scripts in the background and report back. The easiest thing to report back would be the ctest xml output, I guess
<heller>
Or push that to cdash, and set the GitHub status with the URL to the cdash result page
mcopik has joined #ste||ar
<hkaiser>
heller: as I said, the linux guys believe gitlab is cutting edge
<heller>
*shrug*
<heller>
hkaiser: I think one argument for gitlab is to not put your information onto servers in the US
<hkaiser>
ROFL
<heller>
:P
<heller>
that's what I hear sometimes, at least
<hkaiser>
sure - I couldn't care less, frankly
<heller>
me neither
<heller>
the only argument for me would have been if our testing could be overall improved
<hkaiser>
nod
<heller>
and the general workflow
<hkaiser>
heller: I'd rather invest some money into circleci
<heller>
that'd be an option
<heller>
and frankly, I think that's the best shot
<heller>
"We can offer a 50% discount. And there is $20 free credits in your account."
diehlpk has quit [Remote host closed the connection]
<heller>
that was from october 22nd last year
diehlpk has joined #ste||ar
<heller>
that looks like a decent replacement for circle-ci at least, I think. with potentially more bang for the buck. I think circle-ci is rather expensive
diehlpk has quit [Ping timeout: 260 seconds]
jaafar has quit [Ping timeout: 268 seconds]
<github>
[hpx] sithhell created fix_action_move_semantics_regression (+1 new commit): https://git.io/vbYVX
<github>
hpx/fix_action_move_semantics_regression 9c661f7 Thomas Heller: Fixing local direction function execution and lambda actions perfect forwarding
<heller>
hkaiser: so, the local action improvement also broke the action decorations
<hkaiser>
heller: uhh, right - didn't think about those
<heller>
I am not sure how to fix that :/
<hkaiser>
do we have a test for this?
<heller>
yes
<heller>
one is action_invoke_no_more_than
<hkaiser>
ok, will have a look (if I find the time)
<heller>
I would have expected no change in runtime
<heller>
it's just the compile time logic for the tuple expansion, no?
<K-ballo>
heller: no, standard proposal, LEWG had certain opinions on it which I was trying to prove wrong
<K-ballo>
I did measure compile time improvements anyhow, there are some but tiny
<hkaiser>
heller: the placeholder resolution is not needed at runtime
<heller>
K-ballo: can you elaborate on what you tried to prove? a small text in the PR about that would be nice as well
<K-ballo>
now I'm sure there are more places where these could be used, since they don't need protection from users passing placeholders, bind expressions, etc
<heller>
hkaiser: exactly, and it was handled at compile before as well, in my book
<K-ballo>
any place where we used to have to avoid util::bind would be a candidate for bind_front/back
<heller>
if the placeholder is in the front or back, right?
<hkaiser>
no placeholders
<K-ballo>
heller: compelling use cases for bind_back, LEWG drop it because they couldn't think of any
<heller>
ahh
<heller>
fair enough
<K-ballo>
we have a good bunch, but not as many as I was expecting
<heller>
bind_front is closer to what other languages refer to as currying, if I am not mistaken
<hkaiser>
K-ballo: use cases anyways
<K-ballo>
I'll point Tomasz to them once they are merged, but LEWG already shipped the paper forward to LWG by now
<hkaiser>
not too late, still
<K-ballo>
I somehow missed the first revision of the paper :/ was one of the Konas
<hkaiser>
P0443R4 looks like to be ready for implementation now, at least it's closin gin
<hkaiser>
K-ballo: even if LWG decides not to have bind_back - us having it is a good thing
<K-ballo>
sure, we can keep it
<hkaiser>
nod
<K-ballo>
we do have the "compelling use cases" after all
<hkaiser>
right
<hkaiser>
our plan is to be conforming, that doesn't mean we can have more
<hkaiser>
can't*
<github>
[hpx] K-ballo force-pushed bind_front from d99219a to fdd4271: https://git.io/vFbxT
<github>
hpx/bind_front 4404762 Agustin K-ballo Berge: Add implementations of bind_front/back
<github>
hpx/bind_front fdd4271 Agustin K-ballo Berge: Replace some uses of bind by bind_front/back
<hkaiser>
K-ballo: I'll merge it after tests have cycled
<hkaiser>
heller: pls go ahead with merging #3007, I won't have the time to thoroughly investigate things right now
<heller>
hkaiser: ok, thanks
<hkaiser>
if it breaks something we'll fix it later
<heller>
k. shouldn't break anything (tm)
<hkaiser>
sure
<heller>
or rather: works for me
<heller>
hkaiser: what's missing for #2974?
<hkaiser>
heller: the comments have not been addressed