log
462 entries in 0.517s
asciilifeform: mircea_popescu: v.py was my orig vtron , as preserved in amber in http://trilema.com/2015/no-such-labs-releases-v-for-victory/
a111: Logged on 2018-12-03 19:31 asciilifeform: spyked: it's the 1st one most folx used, given as it was the first vtron
asciilifeform: spyked: it's the 1st one most folx used, given as it was the first vtron
spyked: http://btcbase.org/log/2018-12-03#1877949 <-- ftr, v.py was the first vtron that I read, and I think it's a great didactic implem (though nowadays esthlos v is imho a good competitor in that field) ☝︎
asciilifeform: lobbes: asciilifeform currently using diana_coman's vtron , worx a+++
asciilifeform: correct vtron duncare whether $string contains .
asciilifeform: and ftr naming convention ( carried on since asciilifeform's original vtron ) is simply that patch is $string.vpatch and sig is $string.vpatch.author.sig .
asciilifeform: mircea_popescu: vtron (including phf's , and in fact his esp. well) solves.
asciilifeform intended to release a thing somewhat like it with the orig 2015 vtron, but asciilifeform's wwwtronics was not equal to the task, never made a usable incarnation of item
a111: Logged on 2018-11-14 00:20 mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K.
mod6: ah yeah (0x05), it is a significant change from all previous releases of my vtron.
mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K. ☝︎
a111: Logged on 2018-11-13 21:36 asciilifeform: http://btcbase.org/log/2018-11-13#1872052 << i'ma hold off on posting http://btcbase.org/log/2018-11-13#1871779 item , then, so that i can link to diana_coman's vtron
asciilifeform: http://btcbase.org/log/2018-11-13#1872052 << i'ma hold off on posting http://btcbase.org/log/2018-11-13#1871779 item , then, so that i can link to diana_coman's vtron ☝︎☝︎
asciilifeform: vtron -- yes he did
asciilifeform: btw i confirmed that phf's v98 ( when patched to remove the subkey handler thing ) successfully presses ch1-11, with bitwise-correct results ( compared with classic vtron )
asciilifeform: once we have a One Troo scripting language ( possibly some variant of spyked's gc-less ada lisp.. ) i'd like to write a vtron in that ( supposing nobody else beats me to it )
asciilifeform: it defo should not be considered 'the' vtron.
asciilifeform: phf: right, my current understanding is that presently ~errybody has a kludged vtron, but no one yet posted a 'canonical' variant that's 1) properly genesis'd 2) worx errywhere
asciilifeform: mod6's vtron is my current all-time favourite
asciilifeform: seems like the closest thing to a working keccak-vtron currently is phf's v98 tho
asciilifeform: phf: i dun want to glom python-gnupg into vtron tho!
asciilifeform: and imho it is pretty sad that a vtron even sees ~anything~ 'systemwide'.
mircea_popescu: and i know no reason vtron must have "max line length picked in advance" either.
asciilifeform: and to write e.g. vtron, you gotta pick a max length in advance
asciilifeform: i'm a little surprised the vtron even swallowed it.
asciilifeform: i hate to bring back ancient thread re 'how many columns in terminal', but you ~must~ have a finite width, or cannot write even basic thing like vtron without idjit heapism. and i'm heavily biased to 'make'em 80' , that's how wide my terminal and printers are.
mircea_popescu: i guess so. there were some other items scattered about re what should go in the config file for vtron
asciilifeform: btw phf , i'm starting to think that esthlos-vtron could be turned into a proper replacement for asdf,quicklisp,all the heathen rubbish packagerisms
asciilifeform: so nomoar 'with what do i press vtron' , 'where is php', etc
asciilifeform: in orig vtron i relied on 'muscle power' to avoid this boojum, it proved insufficient; hence manifests.
ave1: yes, I know, but you asked about the senario; no published vtron permitted...
asciilifeform: ave1: no published vtron ever permitted 'more than one possible ancestor'
trinque: btw no insult meant to esthlos; we'll get an ebuild in there for his vtron as well, but he lacks a differ, and thus it's not a full v
asciilifeform: bvt: since you're already playing with a vtron, i suspect you know what the correct process is re patch
asciilifeform: i actually posted an experimental vtron that hashed the names
trinque: sure, vtron presses the ports tree, gprbuild builds
asciilifeform: imho gprbuild oughta stay separate item from vtron tho
asciilifeform: ( i.e. working vtron already present )
asciilifeform: but even if not changes, but minor refinements, e.g. the graph plotter -- n00bs will end up with old vtron, and then gotta press a newer
asciilifeform: diana_coman: as i understand q was 'how to give n00b his 1st vtron'
a111: Logged on 2018-10-01 11:51 esthlos: trinque: asdf is used to join the pieces together (keccak, gpg, etc.) for use by the vtron proper. I tried to build the vtron modularly, and my understanding is that asdf is the standard for handling modules in common lisp. is there a better way to do package management in cl?
asciilifeform: http://btcbase.org/log/2018-10-01#1856349 << right nao it's asdf, yes. but hopefully soon asdf can be replaced by your vtron-in-cl ! ☝︎
esthlos: trinque: asdf is used to join the pieces together (keccak, gpg, etc.) for use by the vtron proper. I tried to build the vtron modularly, and my understanding is that asdf is the standard for handling modules in common lisp. is there a better way to do package management in cl?
esthlos: trinque: wrt the keccak vtron, see http://p.bvulpes.com/pastes/YWfb5/?raw=true . I haven't managed to get asdf working with ccl, though the sbcl version builds and appears to work. Note that the thing will barf on non-keccak vpatches. Write-up will come in the next few days. I also have some log catch-up to do: will read the context and repond to your other question soon.
mod6: I want users to be able to get a vtron, as they do now, with v.pl, then build trb in very much the same way they are able to today.
mod6: <+mircea_popescu> the one useful thing here would be to get trb properly ground already. << I'm probably not going to do this until there is a vtron that supports keccak.
asciilifeform: ( asciilifeform plowed through the phf-vtronics thread when came back from voyage, and then second time when diana_coman requested keccak regrind, and both times failed to converge to correct answ re 'is there complete keccak vtron' )
a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...
mod6: yeah, this is the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.
asciilifeform: trinque: which vtron are you thinking of including in cuntoo beta ?
asciilifeform: phf: my orig vtron has been sad and unmaintained, and afaik unused by anybody by me, for long time
asciilifeform: phf: right . what i was looking for is variant of same that calls out to keccak instead of sha512 ( mod6's latest vtron actually checks hashes ) . but apparently still needs baking.
mod6: I had started on a ada vtron last year, but I got hung up with some of the string handling, and the fact that I had to use shell-outs for pgp. I'd like to get back to it at some point. I would love to dispense with the shell outs - and can probably do so, but not until 'peh' is finished.
a111: Logged on 2018-09-27 13:50 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: apparently diana_coman has been hand-cranking it, sorta like asciilifeform's 1st yr of trb pre-vtron
asciilifeform: and yes it is the picture i got from log. the gap in my head is where diana_coman switched to the new format; i then assumed there is a 100%-complete new vtron, and that 'hmm simply missed this, is in log somewhere' , turns out nope, notyet
lobbesbot: phf: Sent 14 hours and 6 minutes ago: <asciilifeform> 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)
lobbesbot: phf: Sent 14 hours and 10 minutes ago: <asciilifeform> 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: if phf's item came with a standalone keccak hasher , would then be quite simple to retool e.g. mod6's vtron, to follow the new format. but as it is loox like i'ma have to wait for esthlos , to get full working replacement for old vtrons
asciilifeform: so as i understand nobody has a 100% complete newtype vtron quite yet
a111: Logged on 2018-09-27 13:50 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: 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