<ryantm>
I think there just isn't any merging logic going on with deps.
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 244 seconds]
saschagrunert has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
orivej has quit [Ping timeout: 256 seconds]
alp has joined #nixos-dev
_d0t has joined #nixos-dev
alp has quit [Ping timeout: 244 seconds]
Plien has joined #nixos-dev
alp has joined #nixos-dev
peti has joined #nixos-dev
evax has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
evax has joined #nixos-dev
peti has quit [Quit: lunch]
saschagrunert has quit [Quit: Leaving]
saschagrunert has joined #nixos-dev
saschagrunert has quit [Client Quit]
saschagrunert has joined #nixos-dev
saschagrunert has quit [Client Quit]
saschagrunert has joined #nixos-dev
orivej has joined #nixos-dev
Emantor has quit [Remote host closed the connection]
Emantor has joined #nixos-dev
Plien has quit [Quit: Connection closed for inactivity]
_d0t has quit [Quit: Konversation terminated!]
alp has quit [Ping timeout: 240 seconds]
spacekookie_ has joined #nixos-dev
tokudan_ has joined #nixos-dev
thoughtpolice_ has joined #nixos-dev
LnL- has joined #nixos-dev
LnL- has joined #nixos-dev
LnL- has quit [Changing host]
davidtwco_ has joined #nixos-dev
nh2_ has joined #nixos-dev
sdier_ has joined #nixos-dev
alunduil_ has joined #nixos-dev
infinisi1 has joined #nixos-dev
endocrimes_ has joined #nixos-dev
tom39291_ has joined #nixos-dev
jared-w_ has joined #nixos-dev
claudiii_ has joined #nixos-dev
claudiii has quit [Ping timeout: 272 seconds]
jared-w has quit [Ping timeout: 272 seconds]
nh2 has quit [Ping timeout: 272 seconds]
sdier has quit [Ping timeout: 272 seconds]
tokudan has quit [Ping timeout: 272 seconds]
DamienCassou has quit [Ping timeout: 272 seconds]
davidtwco has quit [Ping timeout: 272 seconds]
hl has quit [Ping timeout: 272 seconds]
tom39291 has quit [Ping timeout: 272 seconds]
infinisil has quit [Ping timeout: 272 seconds]
alexarice[m] has quit [Ping timeout: 272 seconds]
thoughtpolice has quit [Ping timeout: 272 seconds]
spacekookie has quit [Ping timeout: 272 seconds]
alunduil has quit [Ping timeout: 272 seconds]
endocrimes has quit [Ping timeout: 272 seconds]
samueldr has quit [Ping timeout: 272 seconds]
aterius has quit [Ping timeout: 272 seconds]
emilazy has quit [Ping timeout: 272 seconds]
ryantm has quit [Ping timeout: 272 seconds]
jared-w_ is now known as jared-w
claudiii_ is now known as claudiii
gchristensen has quit [Ping timeout: 272 seconds]
emilazy_ has joined #nixos-dev
sdier_ is now known as sdier
nh2_ is now known as nh2
davidtwco_ is now known as davidtwco
thoughtpolice_ is now known as thoughtpolice
emilazy_ is now known as emilazy
alunduil_ is now known as alunduil
gchristensen has joined #nixos-dev
immae_ has joined #nixos-dev
hl has joined #nixos-dev
hl has joined #nixos-dev
samueldr has joined #nixos-dev
DamienCassou has joined #nixos-dev
immae has quit [Ping timeout: 272 seconds]
ryantm has joined #nixos-dev
alexarice[m] has joined #nixos-dev
aterius has joined #nixos-dev
evax has quit [Ping timeout: 256 seconds]
evax has joined #nixos-dev
justanotheruser has joined #nixos-dev
alp has joined #nixos-dev
spacekookie_ is now known as spacekookie
teto has joined #nixos-dev
cole-h has joined #nixos-dev
teto has quit [Quit: WeeChat 2.9]
orivej has quit [Ping timeout: 260 seconds]
<gchristensen>
domenkozar[m]: got a reproducer for a patchelf bug! :D
Plien has joined #nixos-dev
ris has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
peelz has quit [Remote host closed the connection]
orivej has joined #nixos-dev
<ris>
fetchpatch-wise, what's the best way to deal with unmerged upstream PRs?
alp has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
__monty__ has joined #nixos-dev
<cole-h>
fetchpatch the `<commit-sha>.patch`
<cole-h>
The `<PR-number>.patch`'s contents will change as the PR gets pushed to, but the commit is static
alp has quit [Ping timeout: 272 seconds]
<domenkozar[m]>
gchristensen: yay :D
<ris>
cole-h: the problem is the commit will still be in the submitter's repo, and there's no guarantee they're not going to force-push and have github garbage collect it
<cole-h>
A fair argument, but I don't think I've ever seen GitHub garbage collect any commits (force-pushed away or not). Heck, one of my commits to my personal repo leaking an access token still exists (that was force-pushed away ~June 17).
<cole-h>
If you're worried about it, I'd say that's a prime candidate for copying the patch into nixpkgs.
<samueldr>
once it ends up being cached on cache.nixos.org we're blind to possible garbage collections
<samueldr>
this is both a good and a bad thing
<clever>
ris: i dont think github ever garbage collects after a force push
<clever>
ris: but the git protocol wont let you pull a commit not in a branch, so you can only fetch it via non-git means (github archive or commit patch)
<ris>
^ didn't know that
<ris>
but it makes sense of a lot of other things now you say it
<clever>
if you have push, you can also use the github UI to create a new branch pointing to an orphaned commit
<cole-h>
Also note that the patches can be fetched from the main repo (and not the fork) -- just click on the commit sha, append .patch, and Bob's your uncle.
<clever>
behind the scenes, github stores all forks on a single system
<cole-h>
Makes sense
<clever>
and at one time, there was a bug, where you could fork a private repo into an org you own
<clever>
then when you get your permissions revoked, the private fork doesnt get deleted
<clever>
and if you happen to know the commit sha1 of a new entry, you can fetch it from your fork
<clever>
despite having lost access
infinisi1 is now known as infinisil
lassulus is now known as l
l is now known as Guest53648
Guest53648 is now known as lassulus
<infinisil>
Idea: What if Nix switched to a Haskell-like representation for lists
<gchristensen>
linked lists?
<infinisil>
Yea
<infinisil>
Constant-time head and tail
<infinisil>
But linear index time
<infinisil>
Constant-time prepend as well
<samueldr>
does it change anything for consumers of Nix?
<gchristensen>
I feel like I've heard this discussed before
<infinisil>
Other than different performance, I don't think so, since Nix doesn't expose the fact that lists are arrays in the language
<samueldr>
right, that's what I assumed, implementation detail
<V>
Nobody implements lists as linked-lists unless they're optimising for maximum implementation simplicity
<V>
It absolutely destroys performance
<V>
Every iteration turns into pointer chasing and that's not something that CPUs are fast at
<V>
It also has a decent chance of not fitting into cache lines, etc
<V>
Just don't, please ^^
<infinisil>
It's a complexity tradeoff
<V>
You can implement arrays in terms of linked lists and vice versa, there's literally no benefit to either other than performance or simplicity
<V>
er, maybe not linked lists in terms of arrays. ignore that bit
<infinisil>
n list prepends in Nix currently have O(n^2) complexity, which is horrible if you have many
<V>
Are list prepends a common action in Nix?
<V>
I'd expect merging to be the main place this happens
<V>
(where that can be done as an append, I guess, anyway)
<infinisil>
Not on its own, but there's also tail which is O(n)
<infinisil>
Right now Nix has the disadvantage of not being able to implement many functional algorithms from Haskell efficiently due to its list representation
<V>
I wouldn't expect prepend to be a common operation
<infinisil>
But it also doesn't have the usual advantages of arrays, because you can't mutate them in Nix
<infinisil>
And a linked list representation can still be very fast with some optimizations (Haskell does list fusion)
<V>
you can also go more complicated and start doing n-trees
<V>
trees > linked lists, n-trees > trees
<V>
best of both worlds
<infinisil>
These are different structures though?
<V>
sure, but you can still view them as a list
<V>
just... one which has data locality due to stuff being stored in blocks
<infinisil>
Hm
<V>
and which can be split up and have stuff inserted in the middle without having to shift too much
<V>
it reduces the amount of stuff you'd have to shift in a really long vector to at most the size of your block
<V>
choose a suitably-sized block and you don't get lots of nesting either
<V>
you can store a looot of elements with just 32^32^32 elements
<V>
s/of elements/of data/
<infinisil>
I don't like the idea of having something so complicated, and haskell seems to be doing fine with its linked lists. But yeah maybe trees would be interesting too
<infinisil>
Oh, I'm just thinking, what if Nix could do some list operations in-place if it knows that there aren't any other references to it
<V>
what if persistent data structures? :)
<infinisil>
E.g. `builtins.sort ... [ 2 1 3 ]` doesn't have to allocate a new array, since the given one won't be used anymore
<infinisil>
This is kind of like linear types in idris
<infinisil>
That would be interesting, could work for all kinds of values
justanotheruser has quit [Ping timeout: 244 seconds]