<civodul>but that doesn't work to URIs like /*.narinfo
*davexunit grows concerned over the prevalence of propagated inputs
<davexunit>I worry that the benefit of different packages being able to use different versions of the same libraries will be made null by all the propagated inputs that dynamic languages require currently.
<rekado_>if the only problem with replacing the arguments to "require" is that dynamic dependency loading would fail would it not reduce the number of inputs that would need to be propagated?
<rekado_>for those modules where dependencies are not loaded with a string literal we still may have to propagate inputs or patch stuff, but I don't think that this is common enough to require us to always propagate inputs.
<davexunit>rekado_: I worry about the complications introduced by doing this aggressive patching
<Sleep_Walker>what an irony - I could use levenshtein algorithm on implementation of levenshtein algorithm implementation (it seems to be part of both sdcv and stardict packages)
<Sleep_Walker>why don't we have env in /bin, that would make life easier a bit
<taylanub>civodul: am I reading it right (in package.scm) that a generation N+1, left there after rolling back to N, can be clobbered at any time by a transaction, which will claim N+1 for the new generation it creates?
<mark_weaver>civodul: have you checked to make sure the file is actually a torrent file?
<taylanub>if so, that's surprising because I thought generations are never deleted implicitly, but maybe it's fine since a roll-back is always to a presumably "safe" generation (so one generally doesn't desire a "roll back of a roll back")?
<Sleep_Walker>taylanub: I deleted generations manually if you are commenting my bug report
<civodul>taylanub: if one rolls back from N to N-1, and then creates a new generation, that new generation will be N, thereby overwriting the previous N
<taylanub>Sleep_Walker: apparently if you do one more transaction, you will override your N+2. this gives some perspective on how the problem could be approached. (I was going to propose making the new generation always (apply max generations), with the assumption that they're not disposable; if they are disposable then perhaps they could just be disposed immediately on roll-back...)
<Sleep_Walker>I'm not even sure whether it is error or not but I was just a bit confused before I realized how it works
<Sleep_Walker>civodul today insisted that generation numbering is always monotonic so I'd rather reported that
<Sleep_Walker>I'm satisfied with the current state but I have some remnants of my previous (overly complicated) workflow
<Sleep_Walker>If I have some working version as part of profile for a while, it can be present in many of my profiles and I can't remove it until all the profiles with that will be wiped as well
<taylanub>Sleep_Walker: it's monotonic throughout one "path" of the generation tree, i.e. from the root to any node the number will increase at every step by some amount.
***Rastus_Vernon is now known as rvernon
***rvernon is now known as Rastus_Vernon
<rekado>I'm sometimes annoyed with how git merges stuff when rebasing.