(trilema) mod6: anyway, i appreciate all the feedback. its obvious that there is passion to get this part of my vtron right.
(trilema) asciilifeform: i don't want to see it. ever. if i'm seeing it, vtron is broken !
(trilema) mod6: the good news is, hopefully, your pgptron will be built into any new vtrons
(trilema) asciilifeform: for so long as vtron uses gpg shell-out, it's stuck with the tmp dir crapola
(trilema) 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.
(trilema) asciilifeform: mod6: it makes, e.g., parallelly running vtrons on same box, impossible
(trilema) 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~
(trilema) mod6: my vtron has been discussed very much over the last 2+ years. i remember many disucssions where rules popped out.
(trilema) 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.
(trilema) asciilifeform: no good. first of all suppose there are 2 concurrent runs of the vtron ( say this is a cuntoo pressing itself )
(trilema) 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.
(trilema) 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.
(trilema) mod6: otherwise, my vtron handles the creation and deletion of that .gnupgtmp dir on its own.
(trilema) 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
(trilema) 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.
(trilema) asciilifeform: ideally a vtron oughta unhappen, to the extent possible, everything it did to the world, if it gets a ctrl-c
(trilema) 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?
(trilema) mod6: so goal is to fix this problem. then carry on and document all the rules the thing has in place. this way, others can try to build in those rules we've discussed in here to their vtrons without having to fish them all out of 2 years of logs.
(trilema) asciilifeform: ty for making and maintaining this vtron, mod6 . it is a good thing.
(trilema) asciilifeform: aaa this is the vtron
(trilema) 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)' )
(trilema) a111: Logged on 2017-12-24 02:53 trinque: tangentially yet again, I'd really like a vtron to put in this here cuntoo.
(trilema) asciilifeform: which is troo . and 'not bug, but feature' and in fact plays poorly with vtronics
(trilema) asciilifeform: i.e. a fully vtronic evaluator
(trilema) asciilifeform: if your universe is vtronic, you dun have 'dependencyproblems'. definitionally.
(trilema) 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
(trilema) a111: Logged on 2017-12-27 01:41 trinque: http://btcbase.org/log/2017-12-27#1758909 << if vtronic software is the same frayed rope, no one can ever modularize within the same v-tree. this may be a feature.
(trilema) 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
(trilema) asciilifeform: that was a case when 'put in a comment to align vtronics and semantics' would have been The Right Thing
(trilema) asciilifeform: trinque: i actually put a good bit of thought into the vtronic shape of ffa, while rewriting it ( current-day ffa , observe, is a rewrite, largely by hand, of the previous )
(trilema) trinque: http://btcbase.org/log/2017-12-27#1758909 << if vtronic software is the same frayed rope, no one can ever modularize within the same v-tree. this may be a feature.
(trilema) 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.
(trilema) asciilifeform: http://btcbase.org/log/2017-12-26#1758781 << this only oughta be done in 2 situations -- 'releases' , as discussed by mod6 et al ; and to avoid fuckuppy as seen in orig shiva patch, where there was a logical dependence , but not a vtronic one , b/w shiva-part1 and -part2
(trilema) a111: Logged on 2017-12-26 21:42 ben_vulpes: phf: this exposes another problem: in ideal vtronics it is an illegal operation to press to multiple leaves at the same tree level, which is the only way to have a codebase against which to create a makefiles-type patch that ties multiple patches together
(trilema) ben_vulpes: phf: this exposes another problem: in ideal vtronics it is an illegal operation to press to multiple leaves at the same tree level, which is the only way to have a codebase against which to create a makefiles-type patch that ties multiple patches together
(trilema) asciilifeform did not use it in vtron, because insufficiently illustrative
(trilema) asciilifeform: i.e. vtron not married to a hasher.
(trilema) asciilifeform: if vtron dun know about it, it's as good as gone
(trilema) asciilifeform: a vtron ought to have programmable hash knob.
(trilema) ben_vulpes: vtron != vdiff mircea_popescu
(trilema) trinque: tangentially yet again, I'd really like a vtron to put in this here cuntoo.
(trilema) asciilifeform: the correct, Troo , algo, is the one used in phf's vtron.
(trilema) asciilifeform: by not copying asciilifeform's orig. hasty, wartime vtron.
(trilema) 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
(trilema) asciilifeform: why wouldn't you vtronify the most parsimonious representation of an item that you have, though
(trilema) asciilifeform: i'm still waiting to hear how mircea_popescu would represent e.g. the fg schematic, in ideal vtron.
(trilema) asciilifeform: phf: there's no place for 'merge' as a concept in a vtronic system.
(trilema) mircea_popescu: afaik no scheme vtron extant.
(trilema) mircea_popescu: he;s preparing self for the new vtrons
(trilema) 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
(trilema) 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
(trilema) asciilifeform: fwiw i tested with his vtron, and mine, prior to releasing each ch 1-3
(trilema) asciilifeform: PeterL: afaik current-day vtron, by mod6 , is the one at http://thebitcoin.foundation/index.html
(trilema) asciilifeform: the tragicomic part is that i picked plain old diff for vtronics 'so that patches will be readable'
(trilema) phf: in my thinking vtroner is a larger beast, that's responsible for the management of the entire press chain. patch/diff are dealing with a specific problem of comparing two states, producing a difference of those two tays, and then taking a state into a next state according to differences
(trilema) mircea_popescu: and why would diff/patch be outside of vtroner is the larger design question
(trilema) 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.
(trilema) asciilifeform: this also makes the vtronic-linux a moar tenable, imho, proposition.
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) 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
(trilema) asciilifeform: ffa series is as much a course in vtronics, as in arithmetics.
(trilema) asciilifeform: naturally if yer simply gonna unzip and piss over the vtronic aspect where nobody has to hand-diff 300kB of liquishit -- then yes you dun have 2 genesis.
(trilema) asciilifeform: the important aspect is to avoid the mistake asciilifeform made early on in vtronic era, with 'tinyscheme' proggy
(trilema) asciilifeform: there are fundamentally 2 ways to go about using a vtronic item as a component in another. one is to subsume it into your own
(trilema) diana_coman: right; cleaned it again fully; put back in the readme file; made the structure a/mpi and b/mpi; can finally say that patch presses fine with both vtrons
(trilema) asciilifeform: this is a major 'nope', all extant vtrons i expect will choke on this alone.
(trilema) mod6: <+diana_coman> I can confirm this version presses with mod6's vtron << thanks for checking this out too!
(trilema) diana_coman: I can confirm this version presses with mod6's vtron
(trilema) asciilifeform: i get same result as with mod6's vtron
(trilema) mircea_popescu: i suppose the third alternative is to actually implement a proper diff as part of vtron
(trilema) 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.
(trilema) mircea_popescu: on a long enough timeframe, there's going to exist a vtron in ~any language anyway, i expect.
(trilema) 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.
(trilema) mircea_popescu: mod6 it's not a crime to have a perl vtron. however, if you plan as your own strategy to move away from perl and you're judging it more of a liability than anything, then by all means, eschew.
(trilema) asciilifeform: and i oughta properly read yer vtron, mod6 .
(trilema) asciilifeform: phf how the hell did this get eaten by your vtron
(trilema) mod6: <+mod6> <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut << my V pukes exactly when it can.
(trilema) mod6: <+mircea_popescu> mod6 wanna genesis your vtron ? << at this rate, doesn't look like it.
(trilema) mod6: <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut
(trilema) asciilifeform: diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron
(trilema) asciilifeform: ( a working vtron will immediately barf if encountering a file mismatching the claimed hash )
(trilema) asciilifeform: the issue is as fixed as it gets. i posted the grep item as example of how to verify, without even a vtron, that nothing has been slipped in from under the table.
(trilema) asciilifeform: i tested with my vtron, as pictured in diana_coman's tarball, and it worx.
(trilema) asciilifeform: i tried it with diana_coman's copy of asciilifeform's last vtron, and it has correct barfola
(trilema) mircea_popescu: mod6 wanna genesis your vtron ?
(trilema) mircea_popescu: aaanyway, suppose diana_coman wants to add a patch to mod6's vtron, to better error messages
(trilema) asciilifeform: phf's vtron apparently is clever, and able to eat both types.
(trilema) asciilifeform: ( they however were in there, in asciilifeform's ~original~ vtron . and vdiff . )
(trilema) asciilifeform: it doesn't press because vtron chokes on the timestamps.
(trilema) asciilifeform: vtron, patches, seals, all.
(trilema) asciilifeform: this happens only in mod6's vtron, the bug is replicated by asciilifeform just now ( however yet unexplained. )
(trilema) diana_coman: ftr I used mod6's vtron on ch1 of ffa and it worked perfectly fine
(trilema) asciilifeform: sounds like a bug in mod6's vtron, thus far
(trilema) asciilifeform: pretty strange, mine and phf's vtrons ate it up without complaint, e.g. http://btcbase.org/patches?patchset=mpi
(trilema) asciilifeform: diana_coman: are you using mod6's vtron ?
(trilema) asciilifeform: the other notion is that each shot oughta be a vpatch from previous . so also vtronics practice.
(trilema) asciilifeform: orig & update , both properly vtronic
(trilema) phf: (this is actually related to the code reuse thread we had, the extra-v code reuse machinery is fundamentally at odds with vtronic approach, the conclusion in that thread was "do more retyping it's good for you", which i agree with, but i believe asciilifeform was against it)
(trilema) phf: mircea_popescu: there's a bit of confusion there with logbot, because ircbot and logbot were both published by trinque by they are not vtronic connected, they rely on lisp machinery to load each other. multichannel equivalents of both were publshed by ben_vulpes
(trilema) asciilifeform: and itself vtronic
(trilema) asciilifeform: also gotta nitpick, this is not the first time vtronic crosspollination,
(trilema) mircea_popescu: how is vtron currently fed, via email list thing jurov made ?
(trilema) phf: well, that's fine by me, i think what happened is some other conversation got crossed over into what i was thinking. alf said you gotta publish, to which i responded with a very non committal "i'll think about it". but there were parts that i was thinking of publishing. specifically vpatch parser and presser both of which don't really on external tools, but accomplish the whole thing in memory. might be useful for further vtronics
(trilema) asciilifeform: from asciilifeform's pov this is what culture ~is~ -- when ben_vulpes writes own vtron, or mircea_popescu makes own jazz riff on asciilifeform's 'chumps' article, or the various other.
(trilema) asciilifeform: or ben_vulpes , he did pretty good commentary to orig. vtron
(trilema) asciilifeform: asciilifeform's mental picture of 'cuntoo' involves vtronic replacement of portage
(trilema) mod6: Another thing worth the mention is that my ada-vtron shells out to gpg - which adds some time as well. one thing I think that would help is if I could figure out how to capture the shell command output directly back into the application instead of having to write to a file, then read the file back into the program.
(trilema) mod6: To close the loop here a bit, the vtron stuff I've been doing in ada is a lot faster now than it was -- just needed to get some better loop control.
(trilema) asciilifeform: mircea_popescu: you just described our existing divtron aha
(trilema) mod6: ada vtron being built
(trilema) asciilifeform: systems are to be fixed - i.e. brought into conformance with vtronics -- or discarded.
(trilema) asciilifeform: i find it fascinating, the psychology of folx who voluntarily sign up for svtron.
(trilema) a111: Logged on 2017-08-06 20:05 mod6: http://btcbase.org/log/2017-08-06#1694494 << did you use your vtron here? My vtron does not support bsd at this time, when we have a working trb on bsd, then will support bsd.
(trilema) mod6: http://btcbase.org/log/2017-08-06#1694494 << did you use your vtron here? My vtron does not support bsd at this time, when we have a working trb on bsd, then will support bsd.
(trilema) asciilifeform: and the necessary bits -- reduce to a slightly generalized vtron.
(trilema) asciilifeform: one - proper one - suffices. and it is easier to produce from a generalized vtron, than to produce a vtron from, e.g., 'redo'.
(trilema) asciilifeform: current vtrons assume that all of the signed nodes exist on disk already.
(trilema) pete_dushenski: the vtron version question is a good one. how do i check again ?
(trilema) asciilifeform: pete_dushenski: and which vtron were you using ?
(trilema) a111: Logged on 2017-04-24 06:12 pete_dushenski: "WARNING: asciilifeform_blackhole_reads.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform_blackhole_reads.vpatch!" << anyone else seen this error ? my vtron is barfing this up even though my gpgtron says it's a good sig.
(trilema) a111: Logged on 2017-04-24 06:12 pete_dushenski: "WARNING: asciilifeform_blackhole_reads.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform_blackhole_reads.vpatch!" << anyone else seen this error ? my vtron is barfing this up even though my gpgtron says it's a good sig.
(trilema) pete_dushenski: "WARNING: asciilifeform_blackhole_reads.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform_blackhole_reads.vpatch!" << anyone else seen this error ? my vtron is barfing this up even though my gpgtron says it's a good sig.
(trilema) asciilifeform: kernel is not vtronic, naturally, but linus dun take patches from thin air, they all have names attached
(trilema) asciilifeform: it ~will~ exist, as a vtronic item.
(trilema) asciilifeform: trinque: my last attempt at 'vtronic portage' ran into the brick wall of 'there are nongenesisable items in the tarballss'
(trilema) asciilifeform: mircea_popescu: i was thinking of much more modest item -- replacement of ' asciilifeform's gentoo ' with something replicable on demand, for eternity (vtronic repo, vtronic 'portage')
(trilema) asciilifeform: phf: the 'make bsd with vtronic portagetron' thing looks slightly more appealing every day
(trilema) asciilifeform: you can hack it into existence vtron-style
(trilema) mod6: but having it set up as i just did in the above paste is unpressable in current vtronics.
(trilema) asciilifeform: mircea_popescu: looks like this worked. confirmed that mod6's vtron doesn't check for file-exists, appends. (i won't even blame him, as such, this is the default idiot behaviour of gnudiff !)
(trilema) asciilifeform: yeah but his vtron pressed to that dir once.
(trilema) asciilifeform: looks like this is what mod6's vtron does instead of overwriting files
(trilema) asciilifeform: mircea_popescu: you also might have other filed doubled up because mod6's vtron did append instead of create somewhere, it looks like
(trilema) mircea_popescu: which is of course bound to hit the situation where we have no proper treatment of file removal in vtron because old horrors.
(trilema) asciilifeform: in the meantime can try using asciilifeform's original vtron
(trilema) asciilifeform: mircea_popescu: this looks like a bug in mod6's vtron :
(trilema) phf: i actually need to fix btcbase to make sure file names state consistent with vtronics model..
(trilema) asciilifeform: ( you have a .wot, .seals, .patches, these can be named something else, but these are their conventional names; out of these, vtron 'presses' a particular tree that you want.)
(trilema) asciilifeform: i assumed (apparently wrongly) that mircea_popescu remembered basic vtronics .
(trilema) asciilifeform: http://btcbase.org/log/2017-02-25#1618203 << if the only gpg op in your thing is verification, you can lift code from any of the vtrons, verbatim
(trilema) asciilifeform: fwiw i still use my vtron and his interchangeably.
(trilema) asciilifeform: just recall vtron.
(trilema) asciilifeform: mircea_popescu: imho the smart thing to do with bad olde gpg is to use it as demonstrated in my original vtron -- sans keyring.
(trilema) asciilifeform reports a successful replication of mod6's recipe http://thebitcoin.foundation/trb-howto.html , 'offline' variant, using his vtron etc. took exactly 40 minutes from the instance of making an empty dir to do it in, to having <5MB finished binary in my hands.
(trilema) asciilifeform: i will however note that my original vtron ~was~ openly published.
(trilema) asciilifeform: mircea_popescu: he certainly spared asciilifeform from the chore of maintaining full vtron
(trilema) mircea_popescu: consider the fine case of mod6 's vtron since he said something. so he built a vtron, then later we decided didn't like how it works, he put the time in to understand the thing, fix it... all this happened because he made the first one ; and wouldn't have happened if we were just sitting 6months ago holding dicks and discussing it theoretically.
(trilema) asciilifeform: trinque: trb already exists in multiple branches, such is the nature of vtronics.
(trilema) davout: and just like vtrons, everyone should be able to write its own easily
(trilema) davout: mostly as an exercise in vtronics
(trilema) asciilifeform: as befits a literate d00d. write a vtron. or pick up an actual unsolved problem from the logz.
(trilema) asciilifeform: and so i remain skeptical of vtronic practices that obscure authorship, for whatever otherwise excellent reasons.
(trilema) mircea_popescu: vtron that presses a tree containing more than one genesis is, by that very fact, a broken implementation.
(trilema) mircea_popescu: vtron that presses a multi-root tree is, by that very fact, a broken implementation.
(trilema) mod6: ok. what should the vtron do with these extra roots? place them at the end of the flow as leafs?
(trilema) asciilifeform: cultivating a project with multiple roots may be bad form, but vtron ~must~ display properly
(trilema) asciilifeform: ( mircea_popescu's dictum of 'have 1 root' cannot be enforced mechanically, vtron has no business deciding arbitrarily which root is 'the' root)
(trilema) asciilifeform: mod6: if your vtron throws out a valid, signed-by-wot patch that has 0 antecedents, it is broken
(trilema) asciilifeform: btw mircea_popescu's criticism of shiva-genesis was 100% deserved, it ~does in fact~ logically depend on trb, but did not indicate said dependence vtronically
(trilema) asciilifeform: but they work fine in my vtron.
(trilema) asciilifeform: poor sad nonvtronic patch. go and try to find WHAT he patched.
(trilema) asciilifeform: i will confess, at one point i contemplated a 'vtronic bsd', but i have difficulty mustering any further enthusiasm for keeping unix on life support
(trilema) asciilifeform: alternatively-- vtronic portage.
(trilema) asciilifeform: mod6: afaik the 'edge case' here behaves 100% correctly in my vtron.
(trilema) asciilifeform: (thread was iirc originally about a vtronic gentoo cleanup, and i noted that nobody with half a brain would sign a gig of dubious rubbish code with their naked, unvectored lordly key)
(trilema) mircea_popescu: so that it's trb_mod6_doesgirlsonboats.vpatch vs vtron_phf_addsnamespaces.vpatch. no conflict possible.
(trilema) mircea_popescu: if we make the trb-i correct it should work like vtrons, multiple language implementations
(trilema) asciilifeform: didn't i post , right here, a well-formed-to-naked-eye-but-not-to-vtron vdiff ?
(trilema) asciilifeform: incidentally iirc phf's vtron internally converts diffs to something quite like this form
(trilema) asciilifeform: 'oh it's the same text except that i ran this-here perl turd on it and trust me that it works as i said on your perltron' is not vtronic.
(trilema) asciilifeform: http://btcbase.org/log/2017-01-04#1596264 << if it isn't apparent to naked eye in ~vtronic~ (e.g., phf's) viewer, it's a total loss of vtronicity.
(trilema) asciilifeform: the entire point in using a differ in vtron at all (as opposed to signing ENTIRE body of work) is to make the work of the reader tractable.
(trilema) a111: Logged on 2016-12-30 05:40 phf: so if you were to produce a patch with a/old-veh.lisp and b/veh.lisp. existing vtrons will happily press it, though it's a total clusterfuck
(trilema) asciilifeform: mircea_popescu: tbh i had a 'what the hell is all this' reaction to reading ben_vulpes and phf vtron problemz
(trilema) ben_vulpes: ^^ mircea_popescu asciilifeform mod6 trinque and any other vtronicists pls to opine
(trilema) phf: so if you were to produce a patch with a/old-veh.lisp and b/veh.lisp. existing vtrons will happily press it, though it's a total clusterfuck
(trilema) asciilifeform: trinque: mircea_popescu will probably barf if the 2 genesisen get displayed on same screen. it isn't an eggog in vtronics, but is in his head.
(trilema) phf: root is a compsci term for a the topmost element of a tree. genesis is a vtronic term for the origin. on imlementation level they are identical, and generally describe the same concept, but in general "root" being "genesis" is an implementation detail
(trilema) asciilifeform: it'd seem to me that if i throw in a seal that crashes gpg, ben_vulpes's vtron will say 'good signature' !
(trilema) mircea_popescu: ben_vulpes considering the only reason your lisp vtron even exists is because you're apparently fond of reimplementation,
(trilema) asciilifeform: neato -- 'write a vtron!'
(trilema) asciilifeform: sure we can. at least under my original vtron, this was a legal operation because it does not produce an eternal walk.
(trilema) asciilifeform: mod6's vtron, in this respect, worx.
(trilema) asciilifeform: it is legal in my vtron, because it 'returns to earth'
(trilema) mod6: <+asciilifeform> note that a correct vtron will not misbehave if you have this. << am trying this...
(trilema) asciilifeform: note that a correct vtron will not misbehave if you have this.
(trilema) asciilifeform: mircea_popescu: it is not illegal in my vtron because the toposort still provably terminates.
(trilema) asciilifeform: returns to genesis are topologically harmless and so were legal in my vtron (they cannot cause any kind of inconsistent behaviour.) note that a deedbotted vtron as discussed in today's thread, would still ban them.
(trilema) asciilifeform: notice, my vtron will not barf on it. because it does not cause a munchausening.
(trilema) asciilifeform: this also would give mircea_popescu the thing he asked for, which was a litmus that'd let him reject a cycle-creating patch immediately from his light cone, before it can get into his vtron and cause headache. and that is, 'no patch may have a descendant that is also an antecedent of itself or of an earlier-blocktimed patch.'
(trilema) asciilifeform: i posted this as a litmus test of sorts, for vtrons.
(trilema) asciilifeform: and btw i ~solved this~ in my first vtron
(trilema) asciilifeform: and it is trivial to make, if mircea_popescu really wants, i can post an example set , with a toy key, and he can hang his vtron.
(trilema) asciilifeform: if this weren't easily detectable, vtronics would be entirely impossible
(trilema) a111: Logged on 2016-12-23 02:19 mircea_popescu: mod6 i read through http://www.mod6.net/v-99994-trace.txt and indeed it seems right and proper vtronics. one q though : was there any patch not signed by asciilifeform interspersed in the flow ? because that's the only not tested case i think, if you have say a->b->c->d where a, c and d are signed by x. does it stop at a ?
(trilema) asciilifeform: it is the ~only~ must-die condition for a vtron.
(trilema) asciilifeform: there is only 1 case where a vtron ~must~ barf
(trilema) asciilifeform: i.e. your vtron doesn't see it in flow any more.
(trilema) asciilifeform: when you ask a vtron to press, it has to be for something that is in the flow
(trilema) asciilifeform: mod6: it isn't 'missing', your vtron should simply disregard everything that hung below it
(trilema) asciilifeform: a vtron that displays descendants for a patch that has an antecedent hash that corresponds to no patch, or does the same for any of its apparent children, is incorrect
(trilema) asciilifeform: somebody has buggy vtron.
(trilema) asciilifeform: look at how my vtron invoked 'patch'
(trilema) mircea_popescu: mod6 i read through http://www.mod6.net/v-99994-trace.txt and indeed it seems right and proper vtronics. one q though : was there any patch not signed by asciilifeform interspersed in the flow ? because that's the only not tested case i think, if you have say a->b->c->d where a, c and d are signed by x. does it stop at a ?
(trilema) asciilifeform: hypothetically we could live exactly the same way with NO published vtrons at all!
(trilema) asciilifeform: a hypothetical vtron with a correct forum-end and a disastrously broken harem-end can only hose ~the owner~
(trilema) asciilifeform: possibly my point re 'harem v' was ambiguous. what i wanted to say was that ~every~ vtron has a harem end and a forum end
(trilema) mircea_popescu: automated vtronics is like having cat "read" balzac for you.
(trilema) asciilifeform: all of the extant vtrons, i will point out, run on linux, which is a monstrous horror of the deep that no one in my wot has signed, ditto python, perl, etc.
(trilema) mircea_popescu: there;s no intention involved in or supported by vtronics
(trilema) mircea_popescu: nono, vtronic.
(trilema) asciilifeform: mircea_popescu: signed-but-non-vtronic snippets are vulnerable to context misplacement.
(trilema) ben_vulpes: mod6, asciilifeform, trinque, phf, mircea_popescu, and anyone else tracking vtronic gnashing: i dusted off and rewrote my cl V implementation. i'll follow up sometime tomorrow with more demo usage, and a more robust demonstration of wot-variant pressing. http://p.bvulpes.com/pastes/juTpM/?raw=true
(trilema) ben_vulpes: http://btcbase.org/log/2016-12-20#1586531 << i don't recall the proposed tests, actually. i mulled on this for a bit, am reluctant to try any sort of implementation until i finish the sqlator which a) is probably just sunk cost fallacy rearing its head, as i've done not much there but design the schema and prep a massive ingest job and b) has now been bumped down my todo list *again* in favor of vtronic
(trilema) asciilifeform: fwiw i deliberately did not polish my vtron, wajted to give folx a turn in the sun
(trilema) mircea_popescu: and on the other hand, i suppose it's entirely possible that if a years-made-wiser satoshi tried to release bitcoin, it'd have been done in the manner of how we did vtrons not in the manner of how he did bitcoin, ie, "here's what should happen - anyone who wants to participate make one"
(trilema) mircea_popescu: http://btcbase.org/log/2016-12-22#1587923 << i am fwiw satisfied that it's qutie mroe than this : vs aren't on btcbase because they don't fundamentally belong on btcbase, because unlike public trb "we all use this" they're private "my girl will dance the way ~i~ want her to dance and stfu". there's a much more limited set of rules re what vtrons should do ; than re what trbs should do.
(trilema) asciilifeform: the only time a vtron must hard-fail, is when it is impossible for it to operate in finite time, i.e. the case where it detects a graph cycle.
(trilema) asciilifeform: trinque: there were 2 separate cases where this happened. mod6's buggy vtron (which he fixed today), and mine when the self-appendectomy-time-turn-off-pain-receptor switch flipped.
(trilema) asciilifeform: in all extant vtrons, gpg keyring is nulled at boot
(trilema) asciilifeform: ben_vulpes had a quite complete exposition on my original vtron
(trilema) asciilifeform: ( the bug, as mircea_popescu iirc also pointed out, was in the direction of making his vtron ~stricter~, of forbidding entirely legit ops, so not catastrophic)
(trilema) asciilifeform: trinque: my original, unpublished vtron, only pressed (tracking the dependency flow), and user was expected to check the pgp sigs of the inputs, with bare hands, prior
(trilema) asciilifeform: mod6: relax a bit. recall, my original vtron didn't even check hashes post-patch
(trilema) asciilifeform: i'll point out that for so long as we have an agreed upon patch format, and can agree on a sigtron to use, with agreed pubkeys, 'each d00d has own vtron' worx fine
(trilema) asciilifeform: but now i gotta try other vtrons! ben_vulpes's , for instance
(trilema) asciilifeform: mircea_popescu: incidentally a vtron that has my 'origin' op, can check any tree for consistency simply by iterating over the files and running origin(hash_of_file)
(trilema) asciilifeform: it's what my original vtron did (when in normal operating mode)
(trilema) a111: Logged on 2016-12-21 21:35 mod6: which basically means to me, either no one understands "vtronics" or no one who did ever audited the thing. and i'm clearly not qualified and shouldn't have written the fucking thing int he first place.
(trilema) mod6: which basically means to me, either no one understands "vtronics" or no one who did ever audited the thing. and i'm clearly not qualified and shouldn't have written the fucking thing int he first place.
(trilema) asciilifeform finds this thread somewhat confusing, is probably doomed to actually read mod6's vtron and comment only after.
(trilema) asciilifeform: when trinque posts his fixed patch util, it will be safe to remove this 'hair' from vtron.
(trilema) asciilifeform: like jurov's lxr, but vtronic.
(trilema) asciilifeform: btw phf do you think we could get a src viewer in your vtron that makes this kind of thing apparent to naked eye?
(trilema) asciilifeform: see earlier mega-thread, re how signing a binaryball is a fundamentally un-vtronic act.
(trilema) asciilifeform: phf: thread was about hypothetical 'vtronic gentoo'
(trilema) asciilifeform: mircea_popescu: a vtronic 'gentoo' is trivially possible except that nobody's going to sign GB of crapola.
(trilema) asciilifeform: b) release vtronic pld source only -- and deedbot apparently doesn't eat vpatches yet -- AND then would have no schematics
(trilema) asciilifeform: a) deedbot hashes of binary garbage -- this is not vtronic!
(trilema) mircea_popescu: and which is why traditionalist societies guilty pleasure is genealogy, as in heraldics or vtronics ; whereas modernist societies guilty pleasure is "self improvement" as in miracle diets and college degrees. (no, the two aren't different, the notion that you will BECOME at the college is entirely like the notion that you'll go to heaven through not cursing.)
(trilema) asciilifeform: http://btcbase.org/log/2016-12-07#1578953 << theoretically v works exactly same with any diffing algo. but if you keep more than one type around, you gotta distinguish'em somehow, e.g., call your sexpr vtron's patches 'foo.lpatch' or similar
(trilema) asciilifeform: a signed rating is a correct use of the robot. in fact vtronics consists entirely of this type of thing
(trilema) asciilifeform: likewise 'my inner circle knows what the true J' is' is not solving same problem as 'everyone who knew Kpublic can reliably learn true J' ' which in the case of serious 'for the ages' signatures, e.g., vtronics, you actually ~do~ want
(trilema) mod6: The following have been updated: The Foundation's repository of vpatches & seals, the trb-howto.html, and the vpatch graph. You now are able to build the entire orchastra via integrated makefiles; offline (default) or online, operators choice. All through the use of vtroncis, of course.
(trilema) asciilifeform: trinque: a fully vtronic replacement for asdf and quicklisp would rock
(trilema) mod6: and im stuck between trying to making getting trb up and going for people, in a "one-trigger-pull", and an organic vtron garden.
(trilema) mod6: <+asciilifeform> http://btcbase.org/log/2016-09-15#1542102 << this would not be a good use of anyone's time, i have my own vtron << ok then. no.
(trilema) asciilifeform: http://btcbase.org/log/2016-09-15#1542102 << this would not be a good use of anyone's time, i have my own vtron