AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
kraem has quit [Ping timeout: 265 seconds]
kraem has joined #nixos-dev
jess has quit []
jess has joined #nixos-dev
cole-h has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 252 seconds]
<rmcgibbo[m]>
hyperfekt: I've only used earlyoom rather than systemd-oomd (but my understanding is that they generally do the same thing). In my experience it's a pretty essential quality-of-life thing on a laptop or desktop with ~8GB of ram. I actually specifically purchased a lot more RAM for my next machine because of how frustrating the kernel OOM killer was. So yeah, assuming that systemd-oomd is working as advertised, I'm in
<rmcgibbo[m]>
favor.
<hyperfekt>
haha more RAM unfortunately isn't the way out
<hyperfekt>
i have 32GB
<rmcgibbo[m]>
I still have earlyoom running, and I have 64GB :P
<hyperfekt>
'working as advertised' is a good question. fedora has a release with systemd-oomd on by default so i expect any problems to get solved soon
<hyperfekt>
maybe for now making it a single config option that is off by default is the right way
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
orivej has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<domenkozar[m]>
sterni: the goal is to stop (some) bikeshedding discussions on PRs
orivej has quit [Ping timeout: 265 seconds]
<domenkozar[m]>
gchristensen: I'll prepare stuff and write down the plan, we can still back off if something comes up.
<sterni>
I'm sceptical regarding reformatting the tree because github doesn't support blame ignoreRevsFiles so the github blame feature is gonna be severly limited
<domenkozar[m]>
oh it doesn't come with trade-offs
<andi->
Yeah but mostly it means that you have to go one more step into the past.. Which isn't too bad
<domenkozar[m]>
without*
<gchristensen>
we should make sure that at the same time it lands contributing docs are updated, and a github actions check verifies
<domenkozar[m]>
yeah that's all ready in PRs
<gchristensen>
nice
<domenkozar[m]>
needs fleshing out, but it's there
<sterni>
I wonder if we should leave out lib/, the diff looks kind of pointless to me tbh
<domenkozar[m]>
the major risk right now is if we find last minute problems with formatting, so I'm asking if someone wants to take a look
<gchristensen>
I don't think we should leave anything out, it leaves really poor devex
<sterni>
fair
<samueldr>
won't it only move the bikeshedding into the "upstream" nixpkgs-format, which in turn will cause further reformats to be required?
<domenkozar[m]>
samueldr: that's the goal, but it's better to have them untied from the contributions
<sterni>
changing nixpkgs-fmt in a significant way in the future sounds like a huge nightmare though
<domenkozar[m]>
not if you have Nix to take care of determinism :)
<sterni>
?
<domenkozar[m]>
we just need to pin nixpkgs-fmt and bump it at appropriate times
<sterni>
oh yeah
<sterni>
I meant bikeshedding -> changing the rules
<domenkozar[m]>
so those changes happen like at each branch-off
<sterni>
I wouldn't like having treewide changes with purely cosmetic purpose
<sterni>
changing from no formatter to some formatter is something different than switching formatting I'd say
<domenkozar[m]>
it's a lot less painful then to have them per each PR enforced by different people
<domenkozar[m]>
than to*
<domenkozar[m]>
I'm not selling a silver bullet, only saving some time and suffering :)
<sterni>
yeah, I agree, what I meant is: the real benefit is having *some* consistent formatting
<gchristensen>
I don't care about nixpkgs-fmt having updates to improve something which has knock-on effects, it is the benefit of the formatter. I don't have to care
<gchristensen>
whatever nixpkgs-fmt says is right is right
<sterni>
not some specific nice formatting because prettier code is not really worth it necessarily to break the blame feature for
<sterni>
imo there wouldn't be much to be gained changing the formatting rules in the future in a way that would require are another tree reformat
<domenkozar[m]>
nothing here is really new, most languages follow this workflow nowadays, except that usually new format comes with each language release
<samueldr>
gchristensen: even when the changes are obviously wrong?
<gchristensen>
one click back per 6 months is pretty minor
<gchristensen>
samueldr: yeah, even then, it can be improved :P
<andi->
does nixpkgs-fmt have an escape hatch to exclude a file with say a somment in the first line (or before a statement)?
<andi->
But other than that I am very happy with *any* consistent formatter.
<gchristensen>
ooc, does gofmt have that?
<domenkozar[m]>
no, but we can add that and exclude files in a script until then
<samueldr>
been looking at expressions I maintain and it looks okay-ish, only grub has an issue which comes from what I'd call "it's been done wrong initially"
<andi->
I am thinking about those lib docs that graham wrote once upon a time. Even if those are fine now we might have more of those cases.
<domenkozar[m]>
samueldr: nice-ish! :D
<gchristensen>
an escape-hatch comment sounsd good
<gchristensen>
better than a whole file exclusion, which is a big hammer
<domenkozar[m]>
mhm
<gchristensen>
generally this looks really good
<gchristensen>
I've been using nixfmt but I will happily switch :)
* domenkozar[m]
dances in circles
<gchristensen>
it'd be cool if inherits alphasorted their names :)
<gchristensen>
I am a bit concerned about what's causing the rebuilds
<samueldr>
no
<samueldr>
that wouldn't be nice
<samueldr>
some bigger files really benefit from logically ordered blocks
<gchristensen>
good point
<samueldr>
I don't want to have to chase the definition alphabetically
<samueldr>
same for attrsets, since let blocks are basically fancy attrsets
<samueldr>
(or is it the reverse?)
<sterni>
alphasorting would be a nightmare I think
tokudan has quit [Remote host closed the connection]
mikroskeem has joined #nixos-dev
tokudan has joined #nixos-dev
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-dev
mikroskeem has quit [Quit: back in a few moments]
mikroskeem has joined #nixos-dev
<jonringer>
sterni: use of the formatter would also help a lot in the staging-next where there's often conflicts from master
<jonringer>
obviously a formatter wouldnt solve all edge cases. But it would eliminate a lot of "easy to get wrong" merges
<andi->
is rebuilds GCC from bootstrap tarballs :/
<gchristensen>
ow
<andi->
I guess that isn't the worst case as we could do one more staging run with the formatting but the formatter shouldn't change semantics.
<gchristensen>
+1
<sterni>
how does it even manage that? does it change indented strings?
<hyperfekt>
was there an RFC for formatting the tree? i'm not opposed but it does seem like something that should have one
pmy_ has quit [Read error: Connection reset by peer]
pmy_ has joined #nixos-dev
<hyperfekt>
probably would've been good to have one much earlier because at this point it would hold things up i guess
ashkitten has quit [Quit: WeeChat 3.1]
ashkitten has joined #nixos-dev
<gchristensen>
I think an RFC couldn't hurt, it'd be hard to get it through before 21.05 though
<hyperfekt>
if there's issues with our RFC process we should fix them instead of sidestepping it
<hyperfekt>
if the RFC process does what it's supposed to then sidestepping is arguably the wrong thing to do
<hyperfekt>
just in principle, i'm not saying anyone's intentionally or even unintentionally doing that. it may well be that this change isn't deserving of one, i haven't looked closely enough
<hyperfekt>
i just brought it up because i've seen RFCs for a bunch of things that seem less impactful, but on second thought that shouldn't be the only factor to whether there's an RFC. some things just don't have enough alternatives or details that are worth discussing
<gchristensen>
I agree
<ashkitten>
yeah, we need to fix our rfc process
<ashkitten>
what happened with flakes (what is currently happening with flakes, rather) shouldn't be repeated