asciilifeform: this is what distinguishes us from the apes, we can do experiment, rather than argue over empty table.

asciilifeform: i promise to try it.

asciilifeform: hey trinque why dontcha write your variant vtron. then we'll talk about the output. rather than this headache.

asciilifeform: understand, trinque , asciilifeform does not suffer from an irrational hatred of people who start with letter 't' , and thereby balk at $algo. asciilifeform genuinely does not see how it results in anything other than a http://btcbase.org/log/2018-01-06#1765616 horror show. ☝︎

asciilifeform: ( btw does trinque have an existing variant-vtron that i can look at the output of ? )

asciilifeform: suppose this algo were in use. and it is time for trinque to write the 'makefiles' patch . how does the latter coalesce the strands ?

asciilifeform: trinque: let's consider the 2nd then

asciilifeform: but they aren't meaningless. they signify 'you will have ~this~ db.cpp and ~this~ db.h and ...'

asciilifeform: how does $scheme differ from the old practice of signing tars ?

asciilifeform: trinque: is the observation factual or not ?

asciilifeform: you can sign tarballs right now. i dun see why to even use a vtron then.

asciilifeform: if asciilifeform misread trinque's scheme somewhere -- will reread. but my current understanding is that it is exactly equivalent to signing tarballs. like in dark ages.

asciilifeform: and it is the correct way to coalesce strands.

asciilifeform: ben_vulpes: there is nothing mechanically 'speshulcase' about it, the vtron has no dedicated execution path for it. it'sa patch like any other.

asciilifeform: try it yourself.

asciilifeform: if every patch were forced to do it, you could not have a tree at all -- only radiating spokes.

asciilifeform: note that this is an item you have ~option~ of doing.

asciilifeform: trinque: it in fact put comments in unrelated file. just as i described must be done to tie up strands, when i released v

asciilifeform: lol

asciilifeform: name

asciilifeform: grr

asciilifeform: *nazme

asciilifeform does not recall who made each item unless said fact was preserved in nakme

asciilifeform: trinque: you did , hm, didntcha

asciilifeform: i'ma summarize the v thing : if you have a proposed new v algo ; and it would turn my 1kB patches into 1MB, and my readable 3 lines into 100kLoc of ?#@%$*(@%% , and my trivial machine-diff-verifiable changes into 'why dontcha sit for 5 years doing eyeball-powered diff' -- it is NOT an improvement. and i won't touch it. sign it. sign anything made on it. etc ☟︎☟︎

asciilifeform: i thought it was clear

asciilifeform: because U

asciilifeform: mod6's 'makefiles' was able to cleanly build on 'asciilifeform_maxint_locks_corrected' , without regrinding anything. i still fail to understand what would have been gained by forcing mod6 to ~manually~ regrind the entire history of entire fucking world in order to produce 'makefiles' ( and for the latter to consequently weigh a megabyte , instead of 10kb !!! )

asciilifeform: and at the risk of repeating , trinque can ~already~ do his style, in the existing v. whereas asciilifeform can't do worth shit in a trinque-style v.

asciilifeform: the patches are readable because they are minimal, and local changes stay local.

asciilifeform: it's a fact. it works.

asciilifeform: ( and moreover, if operators INSIST on committing war crimes, it makes cleanup trivial. called negrate. )

asciilifeform: and yes it relies on operators not to do blitheringly idiotic things. this is why v is possible in tmsr and not at microshit.

asciilifeform: and is SIMPLE .

asciilifeform: srsly i dunget why all of you lot so much want to break v. it WORKS. ☟︎

asciilifeform: that's what 'hash the codebase' equals. 1 file.

asciilifeform: but i'ma rewind upstack : trinque is entirely free to begin using this type of v right now ! by coalescing whole proggy into 1 file. then he can see what ends up happening to his tree.

asciilifeform: y'know how this ends,trinque, it ends with having to line yer house with rope ('eruv'), pay some d00d to dial a modem to turn yer stove on and off...

asciilifeform: superflous constraints, 'just in case', is how the talmudists ended up the way they are.

asciilifeform: it makes no superfluous constraints .

asciilifeform: trinque: the fact that the patch gets to be small, readable, and cleanly coalesceable . it correctly reflects the fact that it nonconflicts with items outside of db.cpp .

asciilifeform: if trb tree can continue to look EXACTLY like http://btcbase.org/patches ( with new leaves growing ) -- your vtron is usable. if not -- not.

asciilifeform: i will not tie OWN hands to possibly constrain some idiot somewhere.

asciilifeform: think, if EVERY patch requires global regrind of all of world history, you ain't using v, may as well throw out all of the unnecessary equipment -- you're passing a monolithic turd around ☟︎

asciilifeform: knife will cut artery as well as sausage. not knife's job,to know what it cuts.

asciilifeform: ben_vulpes: yes and this is coarse error in pilotage. THIS, not the fact that v permits you.

asciilifeform: if instead it demanded that your tree, to apply it, be bitwise-identical to asciilifeform's tree when he made it -- you could only build on this patch if you reground ALL of EVERYONE's work every single fucking time ☟︎

asciilifeform: take for example http://btcbase.org/patches/asciilifeform_maxint_locks_corrected . in properly working v, it ONLY depends on db.cpp being a particular hash . and does NOT lock you into anything else being anything else in particular. ☟︎

asciilifeform: want moar ? or get the idea

asciilifeform: and i'ma have nothing to do with any project that makes use of such a system.

asciilifeform: that it completely thermonukes the usefulness of v, to me personally.

asciilifeform: trinque: your tree ends up a spaghetti of radiating strands that can never recoalesce.

asciilifeform: patches that do not touch db.cpp , in any way shape or form, should not lock it into a state or depend on a particular state of it

asciilifeform: and imposes nonsensical constraint that would not otherwise be imposed.

asciilifeform: this TAKES AWAY detail that is currently preserved.

asciilifeform: this is not actually possible in a general way, it'd have to ~understand~ cpp, ada, cl, whatevers

asciilifeform: i think i grasp what trinque wants : for vtron to actually reflect the semantics of the code being juggled

asciilifeform: cutting items into named parts, is useful, ffs

asciilifeform: or ask writers of books to dispense with chapters

asciilifeform: but do not try to cripple MY programs into 'being 1 file'.

asciilifeform: this will then reflect the desired semantics.

asciilifeform: trinque: if you really hate files, you are welcome to make the whole proggy 1 file ☟︎

asciilifeform: i pointedly do NOT agree that 'having to use an external tool like cp command' is a problem. for fuckssake you have to use a non-vtron tool to edit the coad ! vtron dun replace emacs.

asciilifeform: i am so far failing to see the mega-problem

asciilifeform: there's no particular reason for anything extraneous to get draggedin

asciilifeform: trinque: if B needs A1 and A2, it naturally gets parented by both. if it needs instead modified A1' and A2' , then naturally each of those is parented by the respective A1 or A2

asciilifeform: ben_vulpes: think of it this way : EVERY time you edit ANYTHING, you created 'invalid' state, i.e. one that could never have been the result of a sequence of presses of previously-existing patches !

asciilifeform: can draw a hypothetical for asciilifeform's enlightenment plox ?

asciilifeform: trinque: why would anything end up 'dragged in'

asciilifeform: how you make a vdiff is yer own biznis, can make with magnetic needle for all anybody cares

asciilifeform: ben_vulpes: the only item required to be a hook on which a valid press hangs, is individual patch

asciilifeform: just like how, e.g., asciilifeform_and_now_we_have_eatblock coalesces mod6_fix_dumpblock_params and asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip

asciilifeform: bang, valid coalescing.

asciilifeform: by copying the db.cpp from asciilifeform's tree, the main.cpp from trinque's , and making sure they do not semantically conflict , then vdiffing.

asciilifeform: aite , if trinque gets it , i won't waste logspace

asciilifeform: look at the graph in http://btcbase.org/patches

asciilifeform: let's concretize

asciilifeform: ( 'this' being 'same parent ... end up same item' )

asciilifeform: trinque: consider how i solved this in trb.

asciilifeform: nope. same problem, in essence.

asciilifeform: i oughta be able to take a 1MB text file, cut it in the middle, and swap the halves, and the resulting diff to be a few lines.

asciilifeform: which is that ~moves~ are ugly and info-destroying

asciilifeform: it doesn't solve the fundamental problem

asciilifeform: into something to which i'd have , or not have, an objection

asciilifeform: ben_vulpes: i dun recall that this scheme was ever fleshed out

asciilifeform: walmartistan! 'filtration system, a marvel to behoooold...'(tm)(r)

asciilifeform: what is it

asciilifeform: no but this q has an answer

asciilifeform: i.e. when was the accusation ?

asciilifeform: or .... [accusing ... in the early 1990s] ?

asciilifeform: [accusing ....] [in the early 1990s] ?

asciilifeform: 'Tina Johnson, who first came to public notice for accusing Senate candidate Roy Moore of grabbing her in his office in the early 1990s' << how to parse this sentence ?

asciilifeform: ( yes there will be a mips32 etc )

asciilifeform: it gets replaced wholesale when porting to, e.g., a dedicated micro

asciilifeform: os.ads/adb is to corral all of the unix-specific uglies

asciilifeform: ( 'int' reflects that it gets used strictly in the c ffi , was orig idea )

asciilifeform: no good reason.

asciilifeform: now he can look at the 'official' answr in ch5.

asciilifeform: ben_vulpes is a winrar

asciilifeform: unsurprisingly, it worx