log☇︎
500 entries in 0.838s
asciilifeform: diana_coman: is there a version of mod6's vtron that uses the new vdiff / vpatch ? or what do you use in erryday work ?
diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron ☟︎☟︎
asciilifeform: call me an idjit, but i thought there were a new vtron... ☟︎
asciilifeform: diana_coman: do you normally use this with a hand-patched mod6 vtron ? or how ?
asciilifeform: and apparently this is not a full vtron, but only replaces 'diff' and 'patch' ....
a111: Logged on 2018-09-27 02:28 trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch
trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch ☟︎
mod6: I took your tarball, dumped in the latest version of my vtron, dropped in the .wot (phf) and seals from what I had in my sandbox previously.
asciilifeform: for this, need keccak vtron. presently i dun have one.
mod6: anyway, it's been a while, so I don't know for sure, but if memory serves, I believe his vtree is incompatible with my vtron, on the whole.
asciilifeform: !Q later tell phf nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
asciilifeform: !Q later tell phf are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick
asciilifeform: ideally i simply switch vtron to phf's and it's omnivorous.
asciilifeform: mod6: i've been using my orig vtron all this time. but recently diana_coman & mircea_popescu prodded, 'what's yer excuse for not moved to modern keccak-v' and i had no good counter, it's really time, so nao gotta actually uncrate phf's and make it go
mod6: <+diana_coman> asciilifeform, hm? I can't quite parse that q; if it helps: I'm using phf's vtools, yes << I'm a bit confused too. I'm still using my vtron.
a111: Logged on 2018-09-19 15:19 asciilifeform: if new vtron allows mechanical preservation of ~continuity~ , i.e. i can determine mechanically that a reground tree is in fact same as the old but-for-the-hashes, then all is ok. but if not, this'd be essentially same as throwing past 3rs of historicity away.
asciilifeform: mircea_popescu: i'd be entirely satisfied if it were a separate util, that came 'with' vtron, also.
mircea_popescu: why would i have baked into vtron something that a) is unlikely to ever be used again, past this year and b) works much better in bash anyway and is rather trivial to do
mircea_popescu: asciilifeform so you're saying this compare should be a flag in vtron, whereby it takes a sha and a keccak tree and spits out yes/no ?
asciilifeform: mircea_popescu: i long ago gave up trying to maintain 'the one and only vtron' lol
asciilifeform: a new operator ( no , i dun think we've seen the last of new sane folx, tho mircea_popescu may disagree ) oughta be in possession of the complete kit when he sets up his vtron.
mircea_popescu: this is conceivably a useful tool, but imo not properly thought of as "vtron".
asciilifeform: srsly, exactly same logic as in existing vtron, with the exception of 'when hashing, try keccak 1st, then sha, THEN compare equality, if found to be the latter, warn user, and if sha not enabled, eggog'
a111: Logged on 2018-09-19 15:32 asciilifeform: http://btcbase.org/log/2018-09-19#1851642 << btw mod6 , diana_coman , one possible cut of the knot would be if new vtron were to have algo where it tries keccak 1st, then if fails, tries sha512 and ~loudly warns~ ( can be off by default , and enabled on cmdline )
asciilifeform: mircea_popescu: canhaz link to 'hey folx, phf's vtron out of beta, let's regrind trb etc nao' ?
a111: Logged on 2018-09-19 15:19 asciilifeform: if new vtron allows mechanical preservation of ~continuity~ , i.e. i can determine mechanically that a reground tree is in fact same as the old but-for-the-hashes, then all is ok. but if not, this'd be essentially same as throwing past 3rs of historicity away.
a111: Logged on 2018-09-19 14:42 mod6: Before we embark on an entire regrind of the trb-vtree to use keccac, I think we just need a major release version of a "defacto" vtron that supports both SHA512 (for other legacy projects) and keccac. Sounds like phf's might fit the bill, but want to ensure that when the Foundation tackles this problem, it's on very stable footing.
asciilifeform: http://btcbase.org/log/2018-09-19#1851642 << btw mod6 , diana_coman , one possible cut of the knot would be if new vtron were to have algo where it tries keccak 1st, then if fails, tries sha512 and ~loudly warns~ ( can be off by default , and enabled on cmdline ) ☝︎☟︎
asciilifeform: if new vtron allows mechanical preservation of ~continuity~ , i.e. i can determine mechanically that a reground tree is in fact same as the old but-for-the-hashes, then all is ok. but if not, this'd be essentially same as throwing past 3rs of historicity away. ☟︎☟︎
mod6: Before we embark on an entire regrind of the trb-vtree to use keccac, I think we just need a major release version of a "defacto" vtron that supports both SHA512 (for other legacy projects) and keccac. Sounds like phf's might fit the bill, but want to ensure that when the Foundation tackles this problem, it's on very stable footing. ☟︎
mod6: http://btcbase.org/log/2018-09-19#1851602 << No, haven't done anything as of yet. Still using SHA512 and my vtron. ☝︎
asciilifeform: i'm not averse to regrinding things, vtron that understands 2 types of hash inside 1 tree is prolly too much to ask for; but at the very least i gotta be able to distinguish old form from new by file ext., for own workflow.
phf: http://btcbase.org/log/2018-08-05#1839743 << probably a multiroot situation. otherwise btcbase does sound alarm (e.g. the "deprecated" patchset has some examples). ftr btcbase is a visualizer of extant patches, it is to some extent more permissive by design than production vtron ☝︎
asciilifeform: my vtron still won't press this, btw, even given all 3 patches.
asciilifeform: it is impossible to press this tree except by abusing a vtron!
asciilifeform: ( i'd hope that new vtron format will abolish all inbandism. )
asciilifeform: this has no effect on any extant vtron ( the resulting patches are correctly formatted ) .
asciilifeform: it matters , in particular in asciilifeform's vtron
asciilifeform: mircea_popescu: observe, phf is the only one with a trooly , properly strict vtron, rejects non-uuencoded sigs.
diana_coman: re vtools fwiw I pressed it fine with traditional vtron
asciilifeform: diana_coman: possibly i'm mistaken , will have to actually try the new vtool ( and whether it can be pressed with traditional vtron ) .
asciilifeform: in the interest of proper log walks , 1) trinque whacks asciilifeform over the head with the headache of fileism, http://btcbase.org/log/2018-01-05#1765542 2) asciilifeform builds a trinqueian vtron frontend, http://btcbase.org/log/2018-04-02#1792071 ☝︎☝︎
esthlos: wrt http://btcbase.org/log/2018-07-07#1832726 and asciilifeform 's "sad mode", the idea of using the manifest was the confusing way the fuck back in http://btcbase.org/log/2018-03-07#1787163 , where I thought "oh, mp wants me to build a vtron using manifest to resolve tree, guess I need a manifest spec!" ☝︎☝︎
asciilifeform: aside from old-stuff-we're-doomed-to-regrind-for-new-vtron-anyway, largely in the keccak win of being able to emit arbitrarily long hash
mircea_popescu: so that i gotta mandate every vtron implements 500 hashers ?
asciilifeform: i still dun fully grasp why hasher gotta be hardwired into the vtron. what's the point of even having a shell if not for pluggable items like hash.
mircea_popescu: i'm not suggesting either ; i'm just saying that you have two ways you could proceed. either identify among the code you wish to reuse a tree to nestle among, and then your vtron would be an eucrypt downstream item, or a phf vtron item or whatever you pick ;
esthlos: so two things I see are: 1. what to do for hasher? somehow integrate phf's item into my vtron? 2. what do to for diff/patch? lisp McIlroy?
trinque: is the task for esthlos here to produce a patch util that cares about hashes, or to build all patching functionality into the vtron ?
asciilifeform: looking again at his coad, seems like it simply calls out ( just like my vtron did ) to patch util
esthlos: http://btcbase.org/log/2018-07-06#1832404 << my vtron doesn't include a vdiffer or a patch-applier. was this an oversight? ☝︎
phf: ah yes, i thought there was something else. does his vtron use keccak by the way, or it's still a shasum -a 512 call out?
trinque: yep, dood has a vtron
asciilifeform: arguably this kind of thing doesn't belong at all in a production vtron, it is uncomfortably close to the proverbial 'null cipher flag'(tm)(r)
trinque: I agree, promisetronic without the vtron getting angry at you over mismatched name
trinque: mod6: what do you imagine needs to change in a vtron to support the manifest?
trinque: take the example of esthlos recently, dood was being kinda hard to read, uncommunicative. I jabbed directly at forehead on that matter, and lovely vtron pops out the other side
esthlos: trinque: I added a manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron, manifest) become declared "standard", if ever
asciilifeform: nao, if phf can make his vtron handle 'arbitrary' (say, up to avail. ram) masses, and without losing anything, moar power to him. but in practice something is usually sacrificed, in the name of speed/efficiency, is the worrisome bit.
trinque: whole process of talking with esthlos on the vtron project has been a pleasure.
trinque: esthlos here just cranked out a mighty fine vtron without a fancy hat
esthlos: trinque: any time to look at the new vtron? the currently outstanding issues I'm aware of are 1. need to reintroduce a defpackage; 2. weirdness with ccl and building the gpg keychain
trinque: sure, but whether the same patch hunk ended up in two places is computable, interesting in a patch-viewer sense, not in a vtron-operation sense
asciilifeform: phf: werentcha in the middle of a vtron or do i misremember tho
esthlos: trinque phf et al: http://p.bvulpes.com/pastes/OYaGd/?raw=true << further steps on the vtron. currently it is freaking out when used with my ccl 1.11.5 . the make-temp-dir function phf provided throws an error on the first invocation, which prevents use as an executable, but oddly the function works if I return to the top level and then call it again.
a111: Logged on 2018-05-23 02:43 esthlos: btw trinque, have made most of changes to vtron, just have to add mkstemp for ccl (which I know thanks to phf is #_mkstemp)
esthlos: gotta hit the sack for now, vtron tomorrow
esthlos: btw trinque, have made most of changes to vtron, just have to add mkstemp for ccl (which I know thanks to phf is #_mkstemp) ☟︎
mod6: You've read the docs & use my vtron enough to know this!
asciilifeform: ben_vulpes: a correctly-written adult vtron should NEVER fail during press
esthlos: trinque asciilifeform phf etc: what's the best way to deal with sbcl's package lock error when redefining run-program? my naive approach was to define a new package for the vtron. But I'm pounding my head against use-package anyway
deedbot: http://blog.esthlos.com/a-vtron/ << esthlos - A Vtron
ben_vulpes: esthlos: where do you want input? comments on a-vtron ?
asciilifeform: trinque: the vtron ?
mircea_popescu: so yes, a correctly implemented vtron has no history file notion.
mod6: as a side-note, my vtron when doing operations and graphing checks *all* edges.
esthlos: trinque: you can find my writeup at http://blog.esthlos.com/a-vtron/ . I recall you wanted to have the thing return sane data from ops instead of format barfage
asciilifeform: mod6: the included illustration was to the effect of 'what if trb had been made using this type of vtron, from genesis to present day' .
mod6: I believe so, it does this: 1] It takes a press of v99. 2] Runs dir2txt.py on each dir, doing vdiffs of all the files. Stuffing output into monoblok. 3] Monoblok has 1 antecedent hash, 1 dependant hash, rest meta & source. 4] You load the monobloks (signed ofc) into a vtron, press them. They press into one giant file with metadata and source only. 5] one runs txt2dir.py on teh giant crystal to inflate univ
asciilifeform: mod6: note, even tho the proggy ~could~ be used as-is, i doubt that anybody would want to; it is really demo of a potential frontend to be built into vtron .
mircea_popescu: do the tx stuff ; ada vtron can wait.
mod6: One other thing about ada-vtron, at the time, I was using system commands to execute `gnupg'. Where as now, perhaps we can use ffa/peh.
mod6: mircea_popescu: thanks too for prodding me about Ada-vtron. I'll poke at it as I can, for sure.
mod6: (re: crystals) re-reading the email, it is jogging my memory that I didn't use the included trb files specifically. I recall screwing around and wiring in my vtron, as opposed to your vtron, then who knows. I probably did something dumb.
asciilifeform: trinque: fwiw it was how my orig (unreleased) vtron worked.
asciilifeform: ( it is apparently possible to write a vtron, and not know what happens when you orphan a branch.. )
asciilifeform: esthlos: i recommend to take vtron and experiment with it until you grasp how it works, it will click in your head quickly
lobbes: I did! Was simple as removing the robots.txt from .seals. btw I love the manual you included with yer vtron
mod6: my vtron pulls in 'vdiff_fixes_newline_gcc.vpatch' because it is an antecedent of 'vdiff_sha_static.vpatch' : http://www.mod6.net/2018/April/10/vtools_graph.html
mod6: http://p.bvulpes.com/pastes/AVFdI/?raw=true << ok that works. but my vtron chokes on this patch set -- mis-orders the press path, for some reason I still don't understand yet.
asciilifeform: then why does mod6's vtron barf
mircea_popescu: mod6 well, which way do you want to go ? i assumed that was kinda your plan, bake ada vtron, meanwhile maintain perl one functional but not really ugprade or anything. or ?
mod6: http://logs.bvulpes.com/trilema?d=2018-4-9#328866 << ok cool. sounds good. the ada part here is to phf right? or do you mean my not-yet-fully-baked ada vtron?
asciilifeform: hence i called 'trinquian vtron'
asciilifeform: prolly i oughta preemptively answer the q of 'where are the hashes'. answ: hashing belongs in vtron, and would be of entire shebang produced by ^above .
asciilifeform: ( or rather, just the whole-program representation therein -- it is not a vtron )
asciilifeform ftr biased in favour of pills that leave the orig vtron simple ( while potentially introducing a separate tool for testing conformance to chronology )
asciilifeform: i no longer try to actively persuade folx 'it oughta be Like So!' , at this point it is up to phf , mircea_popescu , diana_coman , et al, folx who very actively work on multi-author projects , to determine a Troo Vtron
asciilifeform: phf: which is why i wrote the classical vtron the way i did -- wanted max flexibility of form. and yes this has cost.
asciilifeform: original v left chronicling as a per-project convention, to the pleasure of the project operator, rather than part of vtron