<MichaelRaskin>
Was there one more change or something? I think my builder is not allowed to connect anymore
<MichaelRaskin>
(with the fresh next branch)
<MichaelRaskin>
gchristensen: and I do run Nix 2.0 on my builder!
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-borg
jtojnar has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 260 seconds]
<ekleog>
gchristensen: hmm… which one is coretemp's issue? I can't find it in either ofborg or nixpkgs repos. Anyway, if you end up wanting the `on a,b,c build d,e,f` feature, just tell me, I can at least help on the parser side :)
gleber_ has quit [Read error: Connection reset by peer]
gleber_ has joined #nixos-borg
orivej has joined #nixos-borg
jtojnar has joined #nixos-borg
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-borg
<MichaelRaskin>
gchristensen: so, what am I doing wrong with my builder?
<gchristensen>
hmm
<gchristensen>
what happens?
<MichaelRaskin>
reply_code: 403, reply_text: \"ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.\", class_id: 0, method_id: 0
<gchristensen>
hmmm
<LnL>
did you migrate to the new setup?
<gchristensen>
MichaelRaskin: try now?
<gchristensen>
it says invalid creds over here
<gchristensen>
oops
<MichaelRaskin>
Yes, just like on my side
<gchristensen>
fixed
<gchristensen>
I think ;)
<MichaelRaskin>
Yes, thanks
<MichaelRaskin>
Even got a build job!
<gchristensen>
nice!
<gchristensen>
seems I accidentally added a space to your password for a bit there.
<MichaelRaskin>
Actually, not nice because it means a huge overdue queue
<gchristensen>
it feels a bit "cheap" but what if thee nix-instantiate output was sent to the streaming log
<gchristensen>
I feel it would be better to split it out per attribute, but that is much trickier to do
<MichaelRaskin>
Hm, I now understand why aarch64 has 32 builders — because for better utilisation there are 32 Borg instances in case of single-threaded builds…
<MichaelRaskin>
I think just sending nix-instantiate output with --show-trace to the log should be good enough; of course build and instantiation should better be split…
<gchristensen>
OK, this is an "emergency" feature to add... I'm getting pinged a _lot_ on why things don't instantiate places
<MichaelRaskin>
Looks like the horrible build queue is now better…
<MichaelRaskin>
Ouch, a Firefox build. Why am I sure it will timeout?
<gchristensen>
fingers crossed ...
<gchristensen>
I wrote this function which does: Vec<Result(A,B)> -> (Vec<A>, Vec<B>)
<gchristensen>
and the code is horrendous and hard to read ... but the type so clearly explains it.
* gchristensen
swoons
<MichaelRaskin>
At that point I want to ask how you can make code for such a function horrendous.
<MichaelRaskin>
There are like not enough operations that can even be used in such genericity!
<MichaelRaskin>
Well, you could reverse one list and shuffle the other, of course…
<gchristensen>
ok now to clean stuff up a bit more...
<gchristensen>
I'm going to drop partial log support
<ekleog>
gchristensen: `let mut a = Vec::new(); let mut b = Vec::new(); for x in original_vec.into_iter() { match x { Ok(y) => a.push(y), Err(y) => b.push(y) } } (a, b)` ? (untested, but doesn't look that horrendous to me? apart from the fact it's not functional-style)
<gchristensen>
much nicer than mine
<ekleog>
(and so now I'm wondering about functional-style without making a copy... I guess it would be something like `let some_vec = original_vec.into_iter().map(Some).collect::<Vec<_>>(); let vec_a = some_vec.iter_mut().flat_map(|&mut x| let y = x.take(); if let Some(Ok(z)) = y { Some(z) } else { x = y; None }).collect(); let vec_b /* similar thing here but with Err */;`, but that's really ugly :/ then I guess
<ekleog>
it's a bit functional-style, zero-copy, nice-to-write, pick two)
<MichaelRaskin>
(I launched multiple builder instances to maximise core utilisation during the backlog time, then left two)
<gchristensen>
MichaelRaskin: yeah... sorry, I forgot to turn on the "build everything" option before I issued the first build.
<MichaelRaskin>
I think the list in question is a list of results per-built-attribute
<MichaelRaskin>
Which means, either it is short or we have more interesting sources of load
<MichaelRaskin>
Well, I didn't have any plans for running my own builds on the machine tonight anyway.
<gchristensen>
:o someone broke master, and then someone fixed master
<ekleog>
IIRC it's like 10 elements long, so not much indeed, that's just something free and that avoids that people looking at the code wonder what's going on, esp. as this into_iter().collect() is used only for casting the VecDeque to a Vec :)
<gchristensen>
ekleog: could you send a PR? I'm knee-deep in deployment stuff :)
<ekleog>
done :) (also, actually I've used .clone().into(), which is even cleaner from a readability standpoint and does some dark magic with the internals to try and make things faster, though it doesn't matter and it'd still likely allocate more than the .iter().map(clone).collect() :°)
<ekleog>
oh well, that was fast ^^
<MichaelRaskin>
gchristensen: actually, both godot copies on the same build machine is the best-case scenario: I build once, then NOP the second build
<MichaelRaskin>
Wait a minute, gcc5??
<MichaelRaskin>
I think ofBorg should be funded by a betting pool on especially absurd build jobs timing out or not.
<ekleog>
(or a way to abort jobs & blacklist them to be put up? 😇)
<ekleog>
(or better, fund this work with the betting pool)
<MichaelRaskin>
The answer: gcc5 build succeeds, godot fails because of a wrong patch.
<MichaelRaskin>
ekleog: then you ask for borg builder automatically fetching more single-threaded jobs if a single-threaded job comes, then there is optimal distribution of builds, then most of the ofborg code is approximate optimisation of an NP-complete problem
<ekleog>
oh yay :D
<MichaelRaskin>
OK, two updated builder instances started (on the same quadcore/octothread box)
<gchristensen>
nice
<MichaelRaskin>
Every program expands until it can read mail, every job juggler expands until most of its code is for approximating some NP-complete scheduling problem (they _all_ are NP-complete)
<ekleog>
then ofborg schedules my todo list
<ekleog>
next step is it building robots to actually check my todo list for me
<ekleog>
and then ROBOT INVASION BEWARE
<MichaelRaskin>
ekleog: don't worry, the robot scheduler will need task durations, and no task for a person who can write code has a duration that cna be known in advance.
<MichaelRaskin>
Robot uprising foiled by impossibility of programmer time estimates.
G6JB1MHarryS has joined #nixos-borg
G6JB1MHarryS has quit [Client Quit]
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]