<gchristensen>
it'd be cool if github had a way to indicate a commit was deployed, and have it show for every PR since the previous deploy
<gchristensen>
ok Profpatsch you should be good now
<Profpatsch>
gchristensen: The authenticity of host 'aarch64.nixos.community (2604:1380:0:d600::7)' can't be established.
<Profpatsch>
ED25519 key fingerprint is SHA256:iPNPF+wdJezn9hz9tn02ONpwALemteTvq5Nz5xdsNa8.
<Profpatsch>
That’s not the one listed in the README, but it could just be a different format
<LnL>
you can use ssh-keyscan -t <type> to get a specific fingerprint
<gchristensen>
sounds like the docs need an update :)
<samueldr>
linking to a particular line is hard*er* since the log isn't loaded until well after the page is fully loaded
<samueldr>
this means the browser can't do its magic and scroll to an anchor
<samueldr>
though it should be possible to implement it ourselves right after load, as we anyway jump to the end
<Profpatsch>
samueldr: Is there no “jump to anchor” function? As you are saying, you are jumping anyway.
<Profpatsch>
And the browser will not jump if it can’t find the ID when it loads the page.
<samueldr>
unless I missed something glaringly obvious, there's no function in JS to jump to an anchor programatically, other than the dubious "create a link, click it artificially"
<samueldr>
the scrolling to the bottom is basically "set the scroll to the length of the element"
<samueldr>
it overshoots, but the browser clamps
<Profpatsch>
Is "#anchor" not a valid link?
<samueldr>
it is
<Profpatsch>
So granted you can parse the anchor from the current URL, that sounds totally fin.e
<Profpatsch>
(to me)
<Profpatsch>
gchristensen: thx btw, I have access to the aarch builder
<samueldr>
yeah, what you said and asked is 100% good and vaild, just need a little bit of code wrangling
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<ekleog>
ugh wow, so investigating the nixos test system led me to discover it does I don't know what with its `nixpkgs` argument and thenn just goes forward with `import ../..` which just re-imports it o.O
drakonis_ has joined #nixos-dev
<domenkozar>
yes, nbp spend quite some time implementing a test to make sure we never reimport nixpkgs, but iirc it never landed
<ekleog>
well, here it's even just *all* tests in `release.nix` will trigger a nixpkgs re-import :(
<ekleog>
… wait, does nixos-build-vms actually work? I can't get it to build its own manpage example
<nbp>
domenkozar: I do not recall implementing this test
<nbp>
domenkozar: However, I always wondered if our test suite ever run anywhere.
<nbp>
domenkozar: such as our lib test suite.
<domenkozar>
nbp: didn't you write a test that assures only one fixed point is used?
<Profpatsch>
Can’t we implement the “cheap” solution of evaluating nixpkgs and measuring memory usage? And then cap it at +20% of that?
<nbp>
domenkozar: I don't think I did.
<nbp>
domenkozar: I wrote some tooling to count the number of fix-point you were going through
<Profpatsch>
Then we immediately notice regressions when the test fails (e.g. because of a re-import)
<nbp>
domenkozar: but I could not land any such test case because it would have broken in most packages.
<Profpatsch>
ofborg also has some statistics of memory usage, which should notice jumps.
domenkozar has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen>
Profpatsch: % is tough, because we can go up 19.9% and then a new package pushes it to 20% and then oh noes :)
<Profpatsch>
gchristensen: Can you query the prometheus data about recent evaluation memory sizes, compare them against the current one and warn on the github PR when it’s a jump?
<gchristensen>
unfortunately we don't actually collect that data yet X)
<gchristensen>
but, we _could_ indeed! and probably should!
<manveru>
samueldr: you can jump to an element given the id, which is what anchors do
<Profpatsch>
I thought I remembered something, but I was thinking about evaluation time.
<Profpatsch>
Which is another such indicator that the PR does something wrong.
<yl[m]>
gchristensen: do you think it's possible for the bot to flag trailing whitespaces in PRs? I keep seeing new trailing whitespaces in the top-level/all-packages that I have to work around because my editor automatically trim them
<samueldr>
one personal addendum: big files like that one are not "the code you found", unless things were touched around the removed trailing space, I personally would argue towards not touching it :/ *looks at the bike shed*
<infinisil>
I mean, we have a .editorconfig file which is supposed to enforce this, editors apply it automatically
<samueldr>
if configured*
<infinisil>
Yeah
domenkozar has joined #nixos-dev
<infinisil>
But this is such a small change, I wouldn't mind these being applied by whoever has it configured
<infinisil>
Otherwise it will just annoy more people
<infinisil>
But yeah, an ofborg check for that would be nice
<infinisil>
I once ran editorconfig through all nixpkgs files to fix them up...
<infinisil>
It's amazing how many files don't conform to it
<samueldr>
yeah, I'm annoyed to no end by things like trailing spaces and such, but more in the camp of the most minimal changes possible :/
<domenkozar>
why would you waste someone's time for extra whitespace
<samueldr>
*rant that won't continue but should be in *-chat* the problem is programming languages are still an abstract representation of a thing that will become an AST, while the source files should probably be the AST and the editor present the document as desired by the author
<infinisil>
I mean yeah, it's not gonna cause any problems or so, but my OCD is troubled
<gchristensen>
omg haha what happened there
<samueldr>
gchristensen: 10$ on block selection copy from a terminal
<gchristensen>
:D
<yl[m]>
the problem only shows up when two PRs conflict due to whitespace issues
<infinisil>
yl[m]: Hmm that's a good point
<infinisil>
samueldr: Yes! I very much hope that's how it will be in the future
<samueldr>
(which is why I prefer the miminal change approach, reduces the risks of conflicts, but also hate whitespace issues)
<gchristensen>
autoformat both branches before the merge :)
<yl[m]>
what I think we really need is a nixfmt (ala gofmt style)
* yl[m]
duck & cover for mentioning Go :)
<yl[m]>
do we have an auto formatter?
<gchristensen>
no
<infinisil>
Didn't jD<blabla> start working on some nixfmt thing?
<samueldr>
some work, not sure if anything tangible, though did the hard work needed first: a parser!