log☇︎
500 entries in 0.727s
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.
asciilifeform: and i oughta properly read yer vtron, mod6 .
asciilifeform: phf how the hell did this get eaten by your vtron
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.
mod6: <+mircea_popescu> mod6 wanna genesis your vtron ? << at this rate, doesn't look like it.
mod6: <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut
asciilifeform: diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron
asciilifeform: ( a working vtron will immediately barf if encountering a file mismatching the claimed hash )
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.
asciilifeform: i tested with my vtron, as pictured in diana_coman's tarball, and it worx.
asciilifeform: i tried it with diana_coman's copy of asciilifeform's last vtron, and it has correct barfola
mircea_popescu: mod6 wanna genesis your vtron ?
mircea_popescu: aaanyway, suppose diana_coman wants to add a patch to mod6's vtron, to better error messages
asciilifeform: phf's vtron apparently is clever, and able to eat both types.
asciilifeform: ( they however were in there, in asciilifeform's ~original~ vtron . and vdiff . )
asciilifeform: it doesn't press because vtron chokes on the timestamps.
asciilifeform: vtron, patches, seals, all.
asciilifeform: this happens only in mod6's vtron, the bug is replicated by asciilifeform just now ( however yet unexplained. )
diana_coman: ftr I used mod6's vtron on ch1 of ffa and it worked perfectly fine
asciilifeform: sounds like a bug in mod6's vtron, thus far
asciilifeform: diana_coman: are you using mod6's vtron ?
mircea_popescu: how is vtron currently fed, via email list thing jurov made ?
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.
asciilifeform: or ben_vulpes , he did pretty good commentary to orig. vtron
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.
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.
mod6: ada vtron being built
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.
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. ☝︎☟︎
asciilifeform: and the necessary bits -- reduce to a slightly generalized vtron.
asciilifeform: one - proper one - suffices. and it is easier to produce from a generalized vtron, than to produce a vtron from, e.g., 'redo'.
pete_dushenski: the vtron version question is a good one. how do i check again ?
asciilifeform: pete_dushenski: and which vtron were you using ?
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.
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.
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. ☟︎☟︎
asciilifeform: you can hack it into existence vtron-style
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 !)
asciilifeform: yeah but his vtron pressed to that dir once.
asciilifeform: looks like this is what mod6's vtron does instead of overwriting files
asciilifeform: mircea_popescu: you also might have other filed doubled up because mod6's vtron did append instead of create somewhere, it looks like
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.
asciilifeform: in the meantime can try using asciilifeform's original vtron
asciilifeform: mircea_popescu: this looks like a bug in mod6's vtron :
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.)
asciilifeform: fwiw i still use my vtron and his interchangeably.
asciilifeform: just recall vtron.
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.
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.
asciilifeform: i will however note that my original vtron ~was~ openly published.
asciilifeform: mircea_popescu: he certainly spared asciilifeform from the chore of maintaining full vtron
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.
asciilifeform: as befits a literate d00d. write a vtron. or pick up an actual unsolved problem from the logz.
mircea_popescu: vtron that presses a tree containing more than one genesis is, by that very fact, a broken implementation.
mircea_popescu: vtron that presses a multi-root tree is, by that very fact, a broken implementation.
asciilifeform: cultivating a project with multiple roots may be bad form, but vtron ~must~ display properly
mod6: ok. what should the vtron do with these extra roots? place them at the end of the flow as leafs?
asciilifeform: ( mircea_popescu's dictum of 'have 1 root' cannot be enforced mechanically, vtron has no business deciding arbitrarily which root is 'the' root)
asciilifeform: mod6: if your vtron throws out a valid, signed-by-wot patch that has 0 antecedents, it is broken
asciilifeform: but they work fine in my vtron.
asciilifeform: mod6: afaik the 'edge case' here behaves 100% correctly in my vtron.
mircea_popescu: so that it's trb_mod6_doesgirlsonboats.vpatch vs vtron_phf_addsnamespaces.vpatch. no conflict possible.
asciilifeform: didn't i post , right here, a well-formed-to-naked-eye-but-not-to-vtron vdiff ?
asciilifeform: incidentally iirc phf's vtron internally converts diffs to something quite like this form
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.
asciilifeform: mircea_popescu: tbh i had a 'what the hell is all this' reaction to reading ben_vulpes and phf vtron problemz
asciilifeform: it'd seem to me that if i throw in a seal that crashes gpg, ben_vulpes's vtron will say 'good signature' !
mircea_popescu: ben_vulpes considering the only reason your lisp vtron even exists is because you're apparently fond of reimplementation,
asciilifeform: neato -- 'write a vtron!'
asciilifeform: sure we can. at least under my original vtron, this was a legal operation because it does not produce an eternal walk.
asciilifeform: mod6's vtron, in this respect, worx.
asciilifeform: it is legal in my vtron, because it 'returns to earth'
mod6: <+asciilifeform> note that a correct vtron will not misbehave if you have this. << am trying this...
asciilifeform: note that a correct vtron will not misbehave if you have this.
asciilifeform: mircea_popescu: it is not illegal in my vtron because the toposort still provably terminates.
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.
asciilifeform: notice, my vtron will not barf on it. because it does not cause a munchausening.
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.'
asciilifeform: and btw i ~solved this~ in my first vtron
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.
asciilifeform: it is the ~only~ must-die condition for a vtron.
asciilifeform: there is only 1 case where a vtron ~must~ barf
asciilifeform: i.e. your vtron doesn't see it in flow any more.
asciilifeform: when you ask a vtron to press, it has to be for something that is in the flow
asciilifeform: mod6: it isn't 'missing', your vtron should simply disregard everything that hung below it
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
asciilifeform: somebody has buggy vtron.
asciilifeform: look at how my vtron invoked 'patch'
asciilifeform: a hypothetical vtron with a correct forum-end and a disastrously broken harem-end can only hose ~the owner~
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
asciilifeform: fwiw i deliberately did not polish my vtron, wajted to give folx a turn in the sun
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.
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.
asciilifeform: ben_vulpes had a quite complete exposition on my original vtron
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)
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
asciilifeform: mod6: relax a bit. recall, my original vtron didn't even check hashes post-patch
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
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)
asciilifeform: it's what my original vtron did (when in normal operating mode)