phf: mircea_popescu: a111 doesn't read anything from bots, i can disable it but that will obviously create a mutually recursive loop of flood

phf: ben_vulpes: mimisbrunnr perhaps needs a list of fellow bots, so that it ignores links from bot quotes. i remember we had conversations about how to handle it long time ago, but i don't remember what the resolution was. a111 maintains a list of all bots, which is just manually updated

phf: i saw it on a colleagues table, started reading it, and it looks sensible and educational. first time i borrow a book from a coworker :o

phf: trinque: have you seen https://masteringpostgresql.com? it's by dimitri fontaine, who's a major postgresql contrib, but he also wrote pgloader, a proggy for etl into postgresql, which he wrote in common lisp; you get mentions of clos and naggum and such in his book.

phf: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a regrind. ☟︎

phf: mod6: think plaintext tar archive that you stick inside a vpatch. there's only ever ~one file~ in your tree. for simplicity it's one large trb.cpp that compiles to the result. no other dependencies.

phf: yo, it's not a real solution, the only reason i was thinking about is because that's how knuth's literate programming is done. i mean the entirety of code is one file, you use project specific tooling to extract it.

phf: mod6: wait, what? from the way vpatch looks perspective there's literally no difference. you have one diff a/x b/x instead of many, but otherwise the thing looks identical.

phf: problem can also be solved with having entire project in one file, or trinque's approach os tracking hash chains for the entire directory (i.e. treating the whole press as a single file)

phf: well, cutting "makefiles" from trb and going up the graph demonstrates many places where full press wouldn't happen with current behavior, but will still happen with the "buggy" one. so either there was a shared understanding that has changed, or else people who claim that that was shared understanding haven't looked at the trb tree at the time to observe the buggy behavior themselves.

phf: mircea_popescu: i don't agree that the "in the sense" is correct. trb patchset relied on pressing the lateral trees behavior up until recent nailing down of graph, which was a result of elaboration from clearer understanding. i think the understanding of v has evolved, and things of which there was much uncertainty and hand waving in the past are now much more obvious. i don't think it's the case that "the behavior was always that way" in an accidental

phf: if we're trying to nail down antecedents, why not put parent hash into vpatch prelude. i.e. "this vpatch can only happen after a vpatch with the given hash has been applied"

phf: i suspect something like ebuild situation requires a non-trivial vpatch management: each port is its own genesis tree and portage system keeps track of head's. this way extending port's tree allows ongoing development, but trinque's role is to update portage's pointers periodically. this way a press from head must ignore lateral leaves, etc.

phf: though a manifest could be used as a kind of assert during press, as long as it doesn't rely on filenames. (i believe the idea of putting antecedent vpatch's hashes into manifest floated around)

phf: the retrospectively unpleasant part of this approach is patching vdiff's C, which, after writing a bunch of Ada, is torture. i believe diana_coman had similar experience ☟︎

phf: i grok that point; the things are simply not there. i've barely arrived to where i have a working replacement for what we already have on top of which further work can be built. i guess the only reason this one is contentious is because it would've worked better if done upfront.

phf: this doesn't require a new codebase, trb is there, can be reground

phf: i don't understand the solution. i've spent significant amount of time writing various graph walking algorithms to feel like without an set of experimental patches it's hard to have a solution that actual address the underlying complexity. what i wanted to see from trinque or whoever's attempting to solve this problem, is an actual attempt to construct a press tree with a manifest file that does what they want, to ensure that the approach actual solves

phf: but spyked might also be running into a lateral issue, that's related to double presses. in any case ~i~ need to look at it first before i have understanding of it.

phf: i'm saying that i understand the meta problem, because i've seen other people deal with it, and there's been a lot of competing proposals as to how to solve it, including trb's "makefile" approach.

phf: mircea_popescu: i've seen that problem before, but i haven't tried solving it myself yet, because i've not ran into it. i've not had a chance to attempt spyke's problem/solution yet