log☇︎
500 entries in 0.719s
asciilifeform: i was somehow quite certain that trinque had a pseudocode-algo for his improved vtron
asciilifeform: phf fixed it immediately when he wrote his patchviewer vtron.
asciilifeform: and possibly also in an early mod6 vtron.
mod6: huh, well that's news to me -- I was prodded to use that in the latest version of my vtron. I'll have to look into that. Not that my thing is related to hanbot's problem.
mod6: <+hanbot> ooo ty asciilifeform, quite right. now how did i end up with old vtron and new usermanual, lol << oh, herp, didn't even see this.
mod6: <+asciilifeform> hanbot: mod6's old vtron did not support 'verbose' << pretty sure always did -- at least going back 2 years, aha.
hanbot: ooo ty asciilifeform, quite right. now how did i end up with old vtron and new usermanual, lol
asciilifeform: hanbot: mod6's old vtron did not support 'verbose'
hanbot: i do have the old mod6 vtron, i'll look @ new, ty asciilifeform
asciilifeform: ( iirc mod6 introduced a check in a recent edition of his vtron, but possible that hanbot has the old one ? )
esthlos: Hi all, I developed a vtron, writeup here: http://www.esthlos.com/posts/2018/03/17.html . I know I need a comments mechanism: next project is to get mp-wp working
mod6: My vtron also fails on this as well. I have a whole write up here. Stand by:
mod6: what my vtron does is this: as it iterates through the list of patches to be pressed, after each vpatch pressed, it checks that the output file sha matches the expected.
shinohai: and phf's diff + ur vtron passed a personal vtest 2gether as well
mod6: I gotta get this mission critical stuff with vtron out of the way. Then should be undertaking myself.
mod6: The formal release version is planned of course. Thanks for paitence, and help to get this vtron in proper working order.
mod6: Lords and Ladies of The Most Serene Republic, I present to you a pre-patched *EXPERIMENTAL* version of my vtron (99993), along with a patch to show changes from V (99994): http://therealbitcoin.org/ml/btc-dev/2018-January/000287.html
asciilifeform: let the d00d write his vtron. it's a homework, not a heroic quest . then -- beat with sticks. not before.
mod6: before writing a vtron, maybe spend sometime using one.
ben_vulpes: wutwutwut? a vtron webapp?
asciilifeform: douchebag: this is not miserable american school . shoot first; ask questions second. make a vtron. if its function diverges in some way from previous vtrons, you will a) notice b) find out why c ) then, ~maybe~ later ask others, if cannot determine solution on your own
asciilifeform: but asciilifeform for one will read his vtron. and ffa homework answers.
mod6: I'm gonna get this vtron stuff out of the way, then dive in. I should be able to make it through the first 3 chapters pretty easily. I even wrote my own unit tests for those parts.
mod6: Some of this is my fault, I've been trying to keep up here. Getting kinda swampped with a bunch of things at once. But! These are all good things. FFA, eucrypt, ada, vtron stuff, et. al.
hanbot: meanwhile asciilifeform's vtron on hold until i get python on server, nfs apparently eschews
asciilifeform: hanbot: see if you can achieve same barf with my vtron
mircea_popescu: hanbot selfbake vtron or ?
asciilifeform: hanbot: i'd like to know how you got '.orig'. afaik this only happens when merging is enabled. no vtron i know of , enables it
asciilifeform: trinque: is there a changelog-eating vtron somewhere ?
asciilifeform: mircea_popescu: there is no way to weasel out of the fact that the info is available, but simply ignored by ineptly made vtron.
asciilifeform: http://btcbase.org/log/2018-01-18#1772477 << in ideal vtron, the 'and i stole x from a, y from b...' is protocolic, rather than promisetronic. i.e. abolition of eyeball-powered diff. ☝︎
mod6: mircea_popescu: also, fwiw, we might need to adjust our "NO '--- ' or '+++ ' to begin a line in a vpatch to "NO '-- ' or '++ '". There was a vpatch in development where my vtron choked on a line being added into a source file that began with '++', and with the diff '+', became '+++'. My vtron correctly choked here. But maybe a bit of an adjustment to the rule?
asciilifeform: nope. phf afaik has the 1 and only mechanically-correct vtron. mod6 has a prototype of the 2nd.
asciilifeform: afaik the only correct vtron currently existing , in this respect, is phf's.
asciilifeform: apeloyee: trinqueian / mircea_popescuine vtron is arguably The Right Thing. my observation is that it may be a 50kg sword.
mod6: So I have an experimental patch here that applies right on top of release version 99994 of my vtron. ONLY use this in a testing capacity - the contents of the patch are subject to change at any time.
asciilifeform: it is every bit as much of a wholesome thingtodo as making own vtron, imho
mod6: <+mircea_popescu> your system can't have rf in it. << Catching up here... I'd like to change how my vtron handles this. I think this is the simplest / safest solution: http://p.bvulpes.com/pastes/PKYLq/?raw=true
mircea_popescu: man can make own vtron as man pleases and thassat.
mircea_popescu: note tho that i am NOT going to enforce any kind of responsibility for vtrons. the item says "MAKE YOUR OWN!!! vtron" for a fucking reason, and this is that reason -- if you use another man's parachute package better not be surprised by the fact he likes to keep girl undies there.
mod6: I try to keep docs up to date. And add protections where they are needed. Hopefully my vtron is, over time, getting better. Not worse.
asciilifeform: PeterL: why dontcha wait until trinque writes his modified vtron, and see what this looks like with own eyes. because for each line of this unproductive thread that we write, mircea_popescu will take an extra gulp of rum, and i suspect that it is not good for his digestion.
a111: Logged on 2018-01-05 19:06 mod6: my vtron has been discussed very much over the last 2+ years. i remember many disucssions where rules popped out.
a111: Logged on 2018-01-05 18:28 asciilifeform: no good. first of all suppose there are 2 concurrent runs of the vtron ( say this is a cuntoo pressing itself )
asciilifeform: hey trinque why dontcha write your variant vtron. then we'll talk about the output. rather than this headache.
asciilifeform: ( btw does trinque have an existing variant-vtron that i can look at the output of ? )
asciilifeform: you can sign tarballs right now. i dun see why to even use a vtron then.
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: 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 think i grasp what trinque wants : for vtron to actually reflect the semantics of the code being juggled
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.
mod6: anyway, i appreciate all the feedback. its obvious that there is passion to get this part of my vtron right.
asciilifeform: i don't want to see it. ever. if i'm seeing it, vtron is broken !
asciilifeform: for so long as vtron uses gpg shell-out, it's stuck with the tmp dir crapola
mod6: before i ever 'green light' that kinda use of my vtron, i'd certainly like to test it myself etc. and ya, that dir would have to be unique.
asciilifeform: mod6: the most serious bug is not even the failure to delete the tempdir, but that every run of the vtron uses ~same one~
mod6: my vtron has been discussed very much over the last 2+ years. i remember many disucssions where rules popped out. ☟︎
mod6: <+asciilifeform> no good. first of all suppose there are 2 concurrent runs of the vtron ( say this is a cuntoo pressing itself ) << yeah, concurrent runs of my vtron are a no-go.
asciilifeform: no good. first of all suppose there are 2 concurrent runs of the vtron ( say this is a cuntoo pressing itself ) ☟︎
mod6: <+asciilifeform> mod6: an aborted run of vtron should not be able to put a caltrop for subsequent run to die on. this is imho elementary.
asciilifeform: mod6: an aborted run of vtron should not be able to put a caltrop for subsequent run to die on. this is imho elementary.
mod6: otherwise, my vtron handles the creation and deletion of that .gnupgtmp dir on its own.
asciilifeform: mod6: the temp dir is primo example of an always-ok-to-kill item. i.e. one which the vtron run itself created and would never otherwise exist
mod6: <+ben_vulpes> mod6: while you're in there can you get your vtron to cleanup its tmp gnupg directory when it catches a ctrl-c? << if you CTRL+C the thing, it really can't get rid of it. you're expected to clean this up on your own so the vtron doesn't remove something it wasn't suppoesd to.
asciilifeform: ideally a vtron oughta unhappen, to the extent possible, everything it did to the world, if it gets a ctrl-c
ben_vulpes: mod6: while you're in there can you get your vtron to cleanup its tmp gnupg directory when it catches a ctrl-c?
asciilifeform: ty for making and maintaining this vtron, mod6 . it is a good thing.
asciilifeform: aaa this is the vtron
asciilifeform: mircea_popescu: nope. it was resolved in the correct way ('give the vtron the obvious hint , i.e. sanely named files , that turns the problem from o(n^2) into o(n)' )
a111: Logged on 2017-12-24 02:53 trinque: tangentially yet again, I'd really like a vtron to put in this here cuntoo.
a111: Logged on 2017-12-27 02:03 asciilifeform: or, on other end of the possible, a vtron that somehow understands that a call of foo necessarily depends on the patch that birthed foo... and requires disambiguation only if >1 foo exists in the tree
asciilifeform: or, on other end of the possible, a vtron that somehow understands that a call of foo necessarily depends on the patch that birthed foo... and requires disambiguation only if >1 foo exists in the tree ☟︎
asciilifeform: and how big will be the vtron ? mine was <400 lines. imho this is worth something. and every feature added, comes at a cost.
asciilifeform did not use it in vtron, because insufficiently illustrative
asciilifeform: i.e. vtron not married to a hasher.
asciilifeform: if vtron dun know about it, it's as good as gone
asciilifeform: a vtron ought to have programmable hash knob.
ben_vulpes: vtron != vdiff mircea_popescu
trinque: tangentially yet again, I'd really like a vtron to put in this here cuntoo. ☟︎
asciilifeform: the correct, Troo , algo, is the one used in phf's vtron.
asciilifeform: by not copying asciilifeform's orig. hasty, wartime vtron.
asciilifeform: the press algo i wrote was extremely lame , and mod6's vtron went astray by copying it, rather than the item in my head, lol
asciilifeform: i'm still waiting to hear how mircea_popescu would represent e.g. the fg schematic, in ideal vtron.
mircea_popescu: afaik no scheme vtron extant.
a111: Logged on 2017-12-16 21:37 asciilifeform: !~later tell mod6 plox to consider http://btcbase.org/log/2017-12-16#1752260 case , vtron really oughta barf informatively if a req'd unix util is notfound, imho
asciilifeform: !~later tell mod6 plox to consider http://btcbase.org/log/2017-12-16#1752260 case , vtron really oughta barf informatively if a req'd unix util is notfound, imho ☝︎☟︎
asciilifeform: fwiw i tested with his vtron, and mine, prior to releasing each ch 1-3
asciilifeform: PeterL: afaik current-day vtron, by mod6 , is the one at http://thebitcoin.foundation/index.html
a111: Logged on 2017-12-14 15:51 asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
mod6: your example will not work with my vtron, for one simple reason: the new rules state that we do not do ANYTHING with vpatches that do not have a corresponding signature - we IGNORE WILD vpatches and drop them on the floor.
asciilifeform: now let's come back to my much earlier pill, which i suggested in the mircea_popescu thread. which is imho even uglier. in that one, diana_coman would have to introduce the three mpi-ism vpatches comprising her working set, as ~files~ into eucrypt. and a sed script, and a vtron invocation, into her eucrypt makefile.
asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics. ☟︎
asciilifeform: you can press it in my vtron, by 1) recreating diana_coman's working set from last week 2) drop pseudo_eucrypt.vpatch into patches dir 3) ./v.py -wild --wot .wot --seals .seals patches p patches/pseudo_eucrypt.vpatch pseudoeucrypt
mod6: <+diana_coman> I can confirm this version presses with mod6's vtron << thanks for checking this out too!
diana_coman: I can confirm this version presses with mod6's vtron
asciilifeform: i get same result as with mod6's vtron
mircea_popescu: i suppose the third alternative is to actually implement a proper diff as part of vtron
asciilifeform: there was no mistake in asciilifeform's procedure for baking the item. second_cut is in fact a patch, not a genesis, asciilifeform spoke hastily. there is also no bug in mod6's vtron, or in asciilifeform's. diana_coman did not make a mistake.
mircea_popescu: on a long enough timeframe, there's going to exist a vtron in ~any language anyway, i expect.
mircea_popescu: original mod6 perl vtron was important prototype in the early life of v, made all sorts of latter things possible. exactly like original bitcoin. nobody said you have to marry it now though ; or divorce it for that matter.