| 15 Oct 2023 |
|  meet changed their display name from meet to meetm. | 07:05:59 |
 woobilicious | In reply to @raitobezarius:matrix.org
Plus, as much I am a type theorist, Rust type system has IMHO the right level to focus on the matter at hand rather than building castles of abstraction (which would make sense for other stuff, but not things like Hydra IMHO) That's a surprising take since rust seems like it was designed to do more low level, manual management of memory safely. While we just want to interact with some high level stuff like S3 and github, website? you'd get a long way with Haskell web framework and a little abstraction, without having to think too much about it, especially since it' has a real runtime with garbage collection & green threads. I do agree however with the pragmatic stuff like C-FFI, code reuse and accessibility. | 09:24:06 |
| woobilicious | Rust's lack of uninitialised, heavy used of optional, careful type design, and borrow checker does solve like 99% of the issues I have with every other language. | 09:33:18 |
 vcunat | hydra-queue-runner is quite performance-critical and I don't think the task would be suitable for Haskell. | 11:51:20 |
| vcunat | (build-step graph with like a million nodes in memory, scheduling that, etc.) | 11:52:19 |
 K900 | Honestly | 11:52:24 |
| K900 | We probably don't need that graph in memory at all | 11:52:29 |
| vcunat | Yes, it sounds avoidable to me. (as you mentioned recently, in #infra:nixos.org probably) | 11:53:31 |
| K900 | We can just shove it all into Redis or something | 11:53:35 |
| K900 | And have a priority queue | 11:53:43 |
| K900 | We can also do fancy work stealing stuff that way | 11:55:28 |
| K900 | So we don't even need a central scheduler | 11:55:55 |
| K900 | Well, kinda | 11:56:12 |
| K900 | But we don't need it on the hot path | 11:56:17 |
 das_j | In reply to @k900:0upti.me
We can just shove it all into Redis or something But who will do that | 16:27:04 |
| K900 | Like, who will actually write the code? | 16:27:28 |
| K900 | Or what part of Hydra will do that thing | 16:27:35 |
| das_j | In reply to @k900:0upti.me
Like, who will actually write the code? Yes | 16:27:53 |
| K900 | Yeah that's kind of the problem with everything | 16:28:07 |
 Christian Theune | Apart from performance i would (ftom my perspective) focus rather on robustness. I am sure som current issues might just be craft issues. | 17:43:35 |
| Christian Theune | * Apart from performance i would (from my perspective) focus rather on robustness. I am sure some current issues might just be craft issues. | 17:43:59 |
| vcunat | In reply to @k900:0upti.me
Yeah that's kind of the problem with everything Especially with proposals like rewrite from scratch to make it better (ideally in a different language). | 17:48:55 |
 raitobezarius | In reply to @woobilicious:matrix.org
That's a surprising take since rust seems like it was designed to do more low level, manual management of memory safely. While we just want to interact with some high level stuff like S3 and github, website? you'd get a long way with Haskell web framework and a little abstraction, without having to think too much about it, especially since it' has a real runtime with garbage collection & green threads. I do agree however with the pragmatic stuff like C-FFI, code reuse and accessibility. What you are probably missing in the discussion is that we also need people to understand and read the code, so we use a Haskell web framework, who are the people who are committing to work on this and teach people on how to work on this? I don't believe it's a good strategy from a maintenance standpoint, we are trying to get out of Perl, I don't think going into Haskell will do any good | 23:41:58 |
| raitobezarius | And I+1 the discussion on who will do that | 23:42:39 |
| raitobezarius | And I think the key to "who will do that" is to not rewrite from scratch to make it better and reuse the existing stuff and rewrite it slowly while being compatible to make it easier to hack on, which is usually a task that people doesn't like to do but is unfortunately necessary | 23:43:06 |
| raitobezarius | Rust is probably a programming language that Nix community is close to, which can handle the web workload, has sane things in a lot of areas and we can interop with Nix quite easily with it given the current advances on the C FFI | 23:44:00 |
| raitobezarius | I also don't care if this is Python | 23:44:08 |
| 16 Oct 2023 |
 hacker1024 | Is there a way to increase build timeouts globally? Our build server emulates x86_64 on AArch64 and large packages like OpenCV with CUDA can take around two days to build. It'd be great if there was a way to tell Hydra to scale up timeouts by 3x. | 22:40:33 |
| hacker1024 | The first thing that comes to mind is something like this
pkgs.hydra_unstable.overrideAttrs ({ postPatch ? "", ... }: {
postPatch = postPatch + ''
substituteInPlace src/hydra-eval-jobs/hydra-eval-jobs.cc \
--replace 'queryMetaInt("timeout", 36000)' 'queryMetaInt("timeout", 108000)' \
--replace 'queryMetaInt("maxSilent", 7200)' 'queryMetaInt("maxSilent", 21600)'
'';
});
| 23:01:23 |
| hacker1024 | * The first thing that comes to mind is something like this
pkgs.hydra_unstable.overrideAttrs ({ postPatch ? "", ... }: {
postPatch = postPatch + ''
substituteInPlace src/hydra-eval-jobs/hydra-eval-jobs.cc \
--replace 'queryMetaInt("timeout", 36000)' 'queryMetaInt("timeout", 108000)' \
--replace 'queryMetaInt("maxSilent", 7200)' 'queryMetaInt("maxSilent", 21600)'
'';
});
| 23:01:32 |
