500 entries in 0.838s
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 ☟︎☟︎ 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.
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.
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.
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 ?
mircea_popescu: this is conceivably a useful tool, but imo not properly thought of as "
vtron".
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 )
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.
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.
☟︎ 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 ☝︎ diana_coman: re vtools fwiw I pressed it fine with traditional
vtron mircea_popescu: so that i gotta mandate every
vtron implements 500 hashers ?
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 ?
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: 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
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
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!
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
ben_vulpes: esthlos: where do you want input? comments on a-
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.
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
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.
lobbes: I did! Was simple as removing the robots.txt from .seals. btw I love the manual you included with yer
vtron 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 ?