phf: http://btcbase.org/log/2018-03-30#1791228 << i'll publish the relevant patchsets on btcbase this saturday; i've read the relevant specs and the issue seems to be straightforward, what is annoying though is that for whatever reason it's not uniform across platforms. ☝︎

phf: http://btcbase.org/log/2018-03-30#1791198 << there's already a generation of kids coming up for whom alt-right/feminism is what old people do; they want to be able to post fashwave pictures, while remaining mostly pantsuit. for them facebook/twitter is where they maintain public teacher/parents friendly identity, and mastodon/discord is where they can be themselves. it's basically just another wave of social networks. ☝︎

phf: mp picked up on your use of "autistic", which i didn't grok myself http://btcbase.org/log/2018-03-29#1791068 ☝︎

phf: http://btcbase.org/log/2018-03-30#1791280 << it's an oversight. i thought that the idea is that my vdiff/vpatch support programmatically whatever manifest format we come up with, but somebody demonstrates how it's supposed to work first. it's not hard to regrind existing tree, manually add a manifest, and then see how it looks on a graph. for some reason i thought that trinque has that experiment in his pipeline, since he also seems to have a clear ide ☝︎

phf: a as to what format the manifest supposed to be. i didn't realize that the idea is that vtools tree was supposed to be the first one to experiment with it

phf: trinque: can you produce a sample then? i don't want to implement your idea, having only vague understanding of how it's supposed to look. there's been many discussions in the log as to what the actual manifest contents should include

phf: hmm

phf: i don't understand his idea

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

phf: i'm not sure if his analysis of the problem is correct without looking at it myself first

phf: (there's another problem in my tree specifically, of double presses. you have to have two separate patches for both trees)

phf: well, presumably that's for the reader.

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: 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: "it's for the reader" meaning that you clarification is for the log reader

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: the problem.

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

phf: mircea_popescu: right, around the time when you made that mothballed comment did i get cued into the idea that you wanted me to implement it.

phf: yes please

phf bb

phf: mircea_popescu: the conversation from which you quote the money shot happens in the context of file renames, the part where you call upon me quotes keccak specifically, elsewhere you re-enumerate the list of what looks like target items, http://btcbase.org/log/2017-12-14#1751799 ☝︎

phf: i'm not even through the list of target items yet, any one of them can be picked up as an example of "didn't bother to implement any solution for"

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: that's the thinking

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: but i don't think i could've implemented ~patch equivalent~ differ in reasonable time. vpatch already ballooned out because of an unfamiliar development environment, and it's much less heuristic based.

phf: mod6: would you mind uploading that test tree somewhere? i want to throw it at btcbase. fwiw, vpatch/vdiff doesn't care about press tree, as long as the hashes work out in the end

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: originally this was \supposed to be solved by curated wot, i.e. all in-wot-dangling leaves that can be applied to current press, by hash, would get pressed

phf: trinque: that was the behavior of v all along!

phf: ^

phf: yeah, you guys "bugginess", this is the fundamental property of how v was described and how it was implemented

phf: trinque: there's no "returning to", original behavior is "press everything that falls from under this head"

phf sighs

phf: trinque: didn't you accuse me of projecting before, ~where did i refuse to acknowledge this problem~

phf: trinque: i'm describing how things are right now, how things were, and what informs my and mod6 opinions on the subject. uncertainty about past behaviors in my opinion tends to influence uncertainty about future solutions

phf: mod6: there's that too :)

phf: like i said, i understand the problem, i'm not sure of the solution, because ~i~ have not attempted to tackle it. for example i suspect that the manifest might be problem specific, i.e. what you put there is informed by the shape of the tree you're trying to create.

phf: ultimately it doesn't matter what's inside manifest, as long as its hash is unique, e.g. it's append only log that requires >1 byte of change in each vpatch

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: 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: e.g. the patch itself starts with mandatory parent: <hash>/false. this though completely eliminates the complicated graph transition machinery. all patches are hashed blobs, that you can point to by its hash

phf: hmm, manifest's hash though solves the same problem, we're essentially driving the graph by manifest hash chain, and the other files in patch are for additional culling

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: sense.

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: asciilifeform: i didn't say barf, but if you were to remove, say, makefiles, press to malleus_mikehearnificarum, you lose mod6_der_high_low_s

phf: asciilifeform: come to think of it, initially you were talking about using own wot to cull things, which makes no sense if you only have one tree.

phf: asciilifeform: it very briefly worked with polarbeard's patches, but that was around active reground time, so the result wasn't particularly interesting. but you could press to experimental head with or without pb's additions, based on whether or not he was in your wot

phf: problem that you run into is really granularity of files (of which we also had thread), and that perhaps having multi-file multi-anticedent vpatches is not the correct thing in genera

phf: l

phf: which we also had thread about

phf: right, hence the conversations about sexp v

phf: with manifest we're basically saying "there's going to be one file, which is going to establish the one true chain, and all these other files are just hanging by the side"

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: *of tracking

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: no no

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: i.e. trb.vpatch -> trb.web -> foo.c, bar.c, qux.c

phf: this is so trivial, and also inconsequential that i apologize for burning s/r on it

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: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a regrind. ☟︎

phf bb