(trilema) mircea_popescu: and i know no reason vtron must have "max line length picked in advance" either.
(trilema) asciilifeform: and to write e.g. vtron, you gotta pick a max length in advance
(trilema) asciilifeform: i'm a little surprised the vtron even swallowed it.
(trilema) 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.
(trilema) mircea_popescu: i guess so. there were some other items scattered about re what should go in the config file for vtron
(trilema) 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
(trilema) diana_coman: an shelf page updated with ave1's divtronic crc32; thank you ave1!; phf please snarf updated .vpatch and sigs when convenient: http://ossasepia.com/reference-code-shelf/#selection-429.0-443.46
(trilema) asciilifeform: so nomoar 'with what do i press vtron' , 'where is php', etc
(trilema) ave1: I was still on the "automagic" way to choose either the lookup or the divtronic CRC32. Whis will never be automagic, authors just have to work on 2 different threes if they want and let the longest one survive.
(trilema) asciilifeform: in current day vtrons you gotta explicitly bake pressable leaves if you want alternatives.
(trilema) asciilifeform: in orig vtron i relied on 'muscle power' to avoid this boojum, it proved insufficient; hence manifests.
(trilema) ave1: yes, I know, but you asked about the senario; no published vtron permitted...
(trilema) asciilifeform: ave1: no published vtron ever permitted 'more than one possible ancestor'
(trilema) asciilifeform: that's where we differ, i think. my whole notion in inventing vtronics was to preserve all history that can be practically preserved.
(trilema) ave1: as for an alternative branch; http://ave1.org/code/eucrypt/eucrypt_crc32_divtronic.vpatch.ave1.sig and http://ave1.org/code/eucrypt/eucrypt_crc32_divtronic.vpatch.
(trilema) asciilifeform: concretely : ave1 releases crc32 as standalone staticable lib, like my udp. it comes with 2 pressable leaves, 'tabletronic' and 'divtronic'. you can press either and use in e.g. euloratron when building.
(trilema) 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
(trilema) deedbot: asciilifeform rated bvt 1 << n00b, ada/vtronics experiments
(trilema) asciilifeform: !!rate bvt 1 n00b, ada/vtronics experiments
(trilema) asciilifeform: bvt: since you're already playing with a vtron, i suspect you know what the correct process is re patch
(trilema) asciilifeform: i actually posted an experimental vtron that hashed the names
(trilema) trinque: sure, vtron presses the ports tree, gprbuild builds
(trilema) asciilifeform: imho gprbuild oughta stay separate item from vtron tho
(trilema) asciilifeform: 1st thing is to freeze the old tars, then slowly can vtronicize.
(trilema) asciilifeform: trinque: was contemplating vtronic mechanism here, rather than 'cute' rename of the old emerge
(trilema) asciilifeform: ( i.e. working vtron already present )
(trilema) 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
(trilema) asciilifeform: diana_coman: as i understand q was 'how to give n00b his 1st vtron'
(trilema) asciilifeform: maintaining hard-continuity of history is nearly whole point, as i see it , of vtronics.
(trilema) asciilifeform: diana_coman: right, pretty much all of the early vtronics work happened on tbf ml
(trilema) 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?
(trilema) 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 !
(trilema) 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?
(trilema) trinque: hory shit, it's raining vtrons.
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) asciilifeform: mircea_popescu: it not only made for very picturesque output in old buggy vtrons, but pretty terrible for blood pressure, as turned out that the supposed 'disable fuzzy' flags dun actually do anyffin in gnupatch
(trilema) a111: Logged on 2018-09-27 17:54 asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
(trilema) 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' )
(trilema) a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...
(trilema) asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
(trilema) mod6: yeah, this is the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.
(trilema) asciilifeform: trinque: which vtron are you thinking of including in cuntoo beta ?
(trilema) asciilifeform: phf: my orig vtron has been sad and unmaintained, and afaik unused by anybody by me, for long time
(trilema) 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.
(trilema) 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.
(trilema) asciilifeform: i'd also like to see a continuing existence of multiple working vtrons, so eventually would like to rework mod6's to use newtype format ( unless mod6 would prefer to do it himself )
(trilema) 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
(trilema) asciilifeform: ( recall, i introduced the patches thing considerably prior to ~vtronic~ patches )
(trilema) asciilifeform: apparently diana_coman has been hand-cranking it, sorta like asciilifeform's 1st yr of trb pre-vtron
(trilema) 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
(trilema) 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)
(trilema) 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
(trilema) 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
(trilema) asciilifeform: so as i understand nobody has a 100% complete newtype vtron quite yet
(trilema) 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
(trilema) 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 ?
(trilema) 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
(trilema) asciilifeform: call me an idjit, but i thought there were a new vtron...
(trilema) asciilifeform: diana_coman: do you normally use this with a hand-patched mod6 vtron ? or how ?
(trilema) asciilifeform: and apparently this is not a full vtron, but only replaces 'diff' and 'patch' ....
(trilema) 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
(trilema) trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch
(trilema) 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.
(trilema) asciilifeform: for this, need keccak vtron. presently i dun have one.
(trilema) 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.
(trilema) 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)
(trilema) 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
(trilema) asciilifeform: ideally i simply switch vtron to phf's and it's omnivorous.
(trilema) 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
(trilema) 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.
(trilema) asciilifeform: at least in the old vtrons ( i have not yet read the new one fully )
(trilema) 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.
(trilema) asciilifeform: mircea_popescu: i'd be entirely satisfied if it were a separate util, that came 'with' vtron, also.
(trilema) 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
(trilema) 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 ?
(trilema) asciilifeform: mircea_popescu: i long ago gave up trying to maintain 'the one and only vtron' lol
(trilema) 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.
(trilema) mircea_popescu: this is conceivably a useful tool, but imo not properly thought of as "vtron".
(trilema) 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'
(trilema) 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 )
(trilema) asciilifeform: mircea_popescu: canhaz link to 'hey folx, phf's vtron out of beta, let's regrind trb etc nao' ?
(trilema) 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.
(trilema) 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 )
(trilema) 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.
(trilema) 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.
(trilema) asciilifeform: but will note, the situation where i gotta keep multiple vtrons around, one for this-here, one for that-there, ( ftr i've been using my orig since aug '15 ) is imho suboptimal.
(trilema) 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.
(trilema) mod6: http://btcbase.org/log/2018-09-19#1851602 << No, haven't done anything as of yet. Still using SHA512 and my vtron.
(trilema) 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.
(trilema) asciilifeform: diana_coman: and if there was a moment in the l0gz where mircea_popescu proclaimed 'hey this is out of beta, errybody plox to retire the classical vtrons' -- i missed it? plox to link.
(trilema) asciilifeform: entirely. this is one of the 9000 ways in which vtronics wins.
(trilema) asciilifeform: imho the preferred method of branching is -- vtronic
(trilema) trinque: rationale behind bothering with the repository system is to let the legacy gentoo ebuild repository coexist with the vtronic repository, in exactly the same way as "overlays" do now with the gentoo repo
(trilema) trinque: no, that's way too ambitious for first release. first release is just a vtronic ebuild tree
(trilema) asciilifeform: sorta the polar opposite of vtronic development : 'this is c++, this always was'
(trilema) lobbesbot: ave1: Sent 16 hours and 3 minutes ago: <asciilifeform> http://ave1.org/code/zfp/v/patches/zfp_2_noc.vpatch is an invalid vpatch, it breaks fundamental rule of vtronics , by referencing files not given in the genesis !
(trilema) 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
(trilema) asciilifeform: my vtron still won't press this, btw, even given all 3 patches.
(trilema) asciilifeform: it is impossible to press this tree except by abusing a vtron!
(trilema) asciilifeform: !Q later tell ave1 http://ave1.org/code/zfp/v/patches/zfp_2_noc.vpatch is an invalid vpatch, it breaks fundamental rule of vtronics , by referencing files not given in the genesis !
(trilema) asciilifeform: ( i'd hope that new vtron format will abolish all inbandism. )
(trilema) asciilifeform: this has no effect on any extant vtron ( the resulting patches are correctly formatted ) .
(trilema) asciilifeform: it matters , in particular in asciilifeform's vtron
(trilema) asciilifeform: ( all of the older vtrons, mine, mod6's , pass the .sig straight to gpg, which doesn't care whether uuencoded )
(trilema) asciilifeform: mircea_popescu: observe, phf is the only one with a trooly , properly strict vtron, rejects non-uuencoded sigs.
(trilema) asciilifeform: http://btcbase.org/log/2018-07-20#1836681 << was rereading this vintage thread; funnily enough , early pre-vtronics discussion
(trilema) asciilifeform: http://btcbase.org/log/2018-07-18#1835675 << what part of the 'rms problem' does vtronics per se not cure ?
(trilema) a111: Logged on 2018-07-17 13:35 asciilifeform: diana_coman: asciilifeform's pov re the retardation of 'open sores' , rms et al, is that they are tards not because they throw open the coad to allcomers but because they have no concept of wot , therefore were unable to conceptualize vtronics .
(trilema) asciilifeform: diana_coman: asciilifeform's pov re the retardation of 'open sores' , rms et al, is that they are tards not because they throw open the coad to allcomers but because they have no concept of wot , therefore were unable to conceptualize vtronics .
(trilema) asciilifeform: mod6: can you think of a fraudulent scenario that isn't handled by simple vtronics and actually requires seekrit coad ?
(trilema) trinque: /cuntoo dir is what I continue to work on. vtronic portage will sit in there. when released, diana_coman can replace the whole /cuntoo dir with the final item
(trilema) diana_coman: re vtools fwiw I pressed it fine with traditional vtron
(trilema) asciilifeform: diana_coman: possibly i'm mistaken , will have to actually try the new vtool ( and whether it can be pressed with traditional vtron ) .
(trilema) a111: Logged on 2018-06-21 15:33 asciilifeform: Mocky: to function as a troo vtronicist, gotta grasp the concept, described by e.g. dijkstra, that a line of code you have written is not an asset, but an expense. (specifically, an expense against the time budget of other thinking people, who must read and grasp what you have written. )
(trilema) a111: Logged on 2018-04-02 22:04 asciilifeform: trinque, phf , other vtronicists : http://therealbitcoin.org/ml/btc-dev/2018-April/000296.html
(trilema) asciilifeform: in the interest of proper log walks , 1) trinque whacks asciilifeform over the head with the headache of fileism, http://btcbase.org/log/2018-01-05#1765542 2) asciilifeform builds a trinqueian vtron frontend, http://btcbase.org/log/2018-04-02#1792071
(trilema) esthlos: wrt http://btcbase.org/log/2018-07-07#1832726 and asciilifeform 's "sad mode", the idea of using the manifest was the confusing way the fuck back in http://btcbase.org/log/2018-03-07#1787163 , where I thought "oh, mp wants me to build a vtron using manifest to resolve tree, guess I need a manifest spec!"
(trilema) asciilifeform: aside from old-stuff-we're-doomed-to-regrind-for-new-vtron-anyway, largely in the keccak win of being able to emit arbitrarily long hash
(trilema) mircea_popescu: so that i gotta mandate every vtron implements 500 hashers ?
(trilema) asciilifeform: i still dun fully grasp why hasher gotta be hardwired into the vtron. what's the point of even having a shell if not for pluggable items like hash.
(trilema) 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 ;
(trilema) 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?
(trilema) 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 ?
(trilema) asciilifeform: looking again at his coad, seems like it simply calls out ( just like my vtron did ) to patch util
(trilema) esthlos: http://btcbase.org/log/2018-07-06#1832404 << my vtron doesn't include a vdiffer or a patch-applier. was this an oversight?
(trilema) 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?
(trilema) trinque: yep, dood has a vtron
(trilema) asciilifeform: arguably this kind of thing doesn't belong at all in a production vtron, it is uncomfortably close to the proverbial 'null cipher flag'(tm)(r)
(trilema) trinque: I agree, promisetronic without the vtron getting angry at you over mismatched name
(trilema) trinque: mod6: what do you imagine needs to change in a vtron to support the manifest?
(trilema) a111: Logged on 2018-06-21 15:33 asciilifeform: Mocky: to function as a troo vtronicist, gotta grasp the concept, described by e.g. dijkstra, that a line of code you have written is not an asset, but an expense. (specifically, an expense against the time budget of other thinking people, who must read and grasp what you have written. )
(trilema) a111: Logged on 2018-06-21 15:33 asciilifeform: Mocky: to function as a troo vtronicist, gotta grasp the concept, described by e.g. dijkstra, that a line of code you have written is not an asset, but an expense. (specifically, an expense against the time budget of other thinking people, who must read and grasp what you have written. )
(trilema) asciilifeform: Mocky: imho the best intro text re vtronics is still ben_vulpes's , http://cascadianhacker.com/07_v-tronics-101-a-gentle-introduction-to-the-most-serene-republic-of-bitcoins-cryptographically-backed-version-control-system
(trilema) asciilifeform: Mocky: to function as a troo vtronicist, gotta grasp the concept, described by e.g. dijkstra, that a line of code you have written is not an asset, but an expense. (specifically, an expense against the time budget of other thinking people, who must read and grasp what you have written. )
(trilema) asciilifeform: Mocky: as you are prolly already beginning to understand from the l0gz, vtronics grew from trb work, which demanded 'measure not 7, but 7777 times, before cutting once', in the style of http://btcbase.org/log/2014-11-15#922644
(trilema) trinque: if you choose to use the build without the vtronic portage, it will be feasible to transition the system once that is born.
(trilema) 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
(trilema) asciilifeform: e.g. vtrons.
(trilema) 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
(trilema) asciilifeform: nao, if phf can make his vtron handle 'arbitrary' (say, up to avail. ram) masses, and without losing anything, moar power to him. but in practice something is usually sacrificed, in the name of speed/efficiency, is the worrisome bit.
(trilema) trinque: whole process of talking with esthlos on the vtron project has been a pleasure.
(trilema) trinque: esthlos here just cranked out a mighty fine vtron without a fancy hat
(trilema) 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
(trilema) 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
(trilema) asciilifeform: phf: werentcha in the middle of a vtron or do i misremember tho
(trilema) 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.
(trilema) 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)
(trilema) esthlos: gotta hit the sack for now, vtron tomorrow
(trilema) 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)
(trilema) mod6: You've read the docs & use my vtron enough to know this!
(trilema) asciilifeform: ben_vulpes: a correctly-written adult vtron should NEVER fail during press
(trilema) 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
(trilema) ben_vulpes: esthlos: where do you want input? comments on a-vtron ?
(trilema) asciilifeform: trinque: the vtron ?
(trilema) deedbot: trinque rated esthlos 1 << lisp vtronicist
(trilema) trinque: (think, when this is done, we have a basis for a vtronic lisp repository, aside a vtronic portage, and all the rest)
(trilema) mircea_popescu: so yes, a correctly implemented vtron has no history file notion.
(trilema) mod6: as a side-note, my vtron when doing operations and graphing checks *all* edges.
(trilema) esthlos: trinque: you can find my writeup at http://blog.esthlos.com/a-vtron/ . I recall you wanted to have the thing return sane data from ops instead of format barfage
(trilema) asciilifeform: mod6: the included illustration was to the effect of 'what if trb had been made using this type of vtron, from genesis to present day' .
(trilema) 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
(trilema) asciilifeform: mod6: note, even tho the proggy ~could~ be used as-is, i doubt that anybody would want to; it is really demo of a potential frontend to be built into vtron .
(trilema) mircea_popescu: do the tx stuff ; ada vtron can wait.
(trilema) 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.
(trilema) mod6: mircea_popescu: thanks too for prodding me about Ada-vtron. I'll poke at it as I can, for sure.
(trilema) 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.
(trilema) asciilifeform: trinque: fwiw it was how my orig (unreleased) vtron worked.
(trilema) a111: Logged on 2018-04-02 22:04 asciilifeform: trinque, phf , other vtronicists : http://therealbitcoin.org/ml/btc-dev/2018-April/000296.html
(trilema) asciilifeform: ( it is apparently possible to write a vtron, and not know what happens when you orphan a branch.. )
(trilema) asciilifeform: esthlos: i recommend to take vtron and experiment with it until you grasp how it works, it will click in your head quickly
(trilema) lobbes: I did! Was simple as removing the robots.txt from .seals. btw I love the manual you included with yer vtron
(trilema) mircea_popescu: http://btcbase.org/log/2018-04-12#1797814 << this'd be the one extra item vtronics might eventually get, if this ever comes to exist in a proper sense.
(trilema) mod6: my vtron pulls in 'vdiff_fixes_newline_gcc.vpatch' because it is an antecedent of 'vdiff_sha_static.vpatch' : http://www.mod6.net/2018/April/10/vtools_graph.html
(trilema) mod6: http://p.bvulpes.com/pastes/AVFdI/?raw=true << ok that works. but my vtron chokes on this patch set -- mis-orders the press path, for some reason I still don't understand yet.
(trilema) asciilifeform: then why does mod6's vtron barf
(trilema) mod6: no! not even using vtronics at all. just a good ole fashion by hand patch application.
(trilema) 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 ?
(trilema) mod6: http://logs.bvulpes.com/trilema?d=2018-4-9#328866 << ok cool. sounds good. the ada part here is to phf right? or do you mean my not-yet-fully-baked ada vtron?
(trilema) trinque: wont be the vtronic portage just yet, but yeah, I can install an entirely usable gentoo for ya.
(trilema) asciilifeform: ultimately ideal would be fully vtronic replacement for portage.
(trilema) asciilifeform: hence i called 'trinquian vtron'
(trilema) asciilifeform: trinque, phf , other vtronicists : http://therealbitcoin.org/ml/btc-dev/2018-April/000296.html
(trilema) asciilifeform: prolly i oughta preemptively answer the q of 'where are the hashes'. answ: hashing belongs in vtron, and would be of entire shebang produced by ^above .
(trilema) asciilifeform: ( or rather, just the whole-program representation therein -- it is not a vtron )
(trilema) asciilifeform: don't burn too much time on this item, mod6 , it is strictly for vtronology.
(trilema) asciilifeform ftr biased in favour of pills that leave the orig vtron simple ( while potentially introducing a separate tool for testing conformance to chronology )
(trilema) asciilifeform: problem is that most meaningful transforms are ~not~ attainable automatically, and the otherwise spiffy vtronics create unwarranted expectation of automatism
(trilema) asciilifeform: i no longer try to actively persuade folx 'it oughta be Like So!' , at this point it is up to phf , mircea_popescu , diana_coman , et al, folx who very actively work on multi-author projects , to determine a Troo Vtron
(trilema) asciilifeform: phf: which is why i wrote the classical vtron the way i did -- wanted max flexibility of form. and yes this has cost.
(trilema) asciilifeform: original v left chronicling as a per-project convention, to the pleasure of the project operator, rather than part of vtron
(trilema) asciilifeform: i was somehow quite certain that trinque had a pseudocode-algo for his improved vtron
(trilema) asciilifeform: phf fixed it immediately when he wrote his patchviewer vtron.
(trilema) asciilifeform: and possibly also in an early mod6 vtron.
(trilema) 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.
(trilema) 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.
(trilema) mod6: <+asciilifeform> hanbot: mod6's old vtron did not support 'verbose' << pretty sure always did -- at least going back 2 years, aha.
(trilema) hanbot: ooo ty asciilifeform, quite right. now how did i end up with old vtron and new usermanual, lol
(trilema) asciilifeform: hanbot: mod6's old vtron did not support 'verbose'
(trilema) hanbot: i do have the old mod6 vtron, i'll look @ new, ty asciilifeform
(trilema) asciilifeform: ( iirc mod6 introduced a check in a recent edition of his vtron, but possible that hanbot has the old one ? )
(trilema) 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
(trilema) mod6: My vtron also fails on this as well. I have a whole write up here. Stand by:
(trilema) 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.
(trilema) shinohai: and phf's diff + ur vtron passed a personal vtest 2gether as well
(trilema) mod6: I gotta get this mission critical stuff with vtron out of the way. Then should be undertaking myself.
(trilema) mod6: The formal release version is planned of course. Thanks for paitence, and help to get this vtron in proper working order.
(trilema) 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
(trilema) asciilifeform: let the d00d write his vtron. it's a homework, not a heroic quest . then -- beat with sticks. not before.
(trilema) mod6: before writing a vtron, maybe spend sometime using one.
(trilema) ben_vulpes: wutwutwut? a vtron webapp?
(trilema) 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
(trilema) asciilifeform: but asciilifeform for one will read his vtron. and ffa homework answers.
(trilema) 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.
(trilema) 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.
(trilema) hanbot: meanwhile asciilifeform's vtron on hold until i get python on server, nfs apparently eschews
(trilema) asciilifeform: hanbot: see if you can achieve same barf with my vtron
(trilema) mircea_popescu: hanbot selfbake vtron or ?
(trilema) 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
(trilema) asciilifeform: hey hanbot , wanna write the Troo Vtronic Likbez ?
(trilema) deedbot: asciilifeform updated rating of trinque from 2 to 4 << texas lisper; author and operator of deedbot ; experimental vtronics work
(trilema) asciilifeform: !!rate trinque 4 texas lisper; author and operator of deedbot ; experimental vtronics work
(trilema) esthlos: hello all, vtronics question
(trilema) a111: Logged on 2018-01-21 02:36 trinque: literature seems exactly the right item to define line of project history, both in the obvious and vtronic sense
(trilema) trinque: literature seems exactly the right item to define line of project history, both in the obvious and vtronic sense
(trilema) asciilifeform: trinque: is there a changelog-eating vtron somewhere ?
(trilema) 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.
(trilema) 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.
(trilema) 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?
(trilema) asciilifeform: nope. phf afaik has the 1 and only mechanically-correct vtron. mod6 has a prototype of the 2nd.
(trilema) asciilifeform: afaik the only correct vtron currently existing , in this respect, is phf's.
(trilema) asciilifeform: apeloyee: trinqueian / mircea_popescuine vtron is arguably The Right Thing. my observation is that it may be a 50kg sword.
(trilema) 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.
(trilema) asciilifeform: it is every bit as much of a wholesome thingtodo as making own vtron, imho
(trilema) 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
(trilema) mircea_popescu: man can make own vtron as man pleases and thassat.
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) 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 )
(trilema) asciilifeform: hey trinque why dontcha write your variant vtron. then we'll talk about the output. rather than this headache.
(trilema) asciilifeform: ( btw does trinque have an existing variant-vtron that i can look at the output of ? )
(trilema) asciilifeform: you can sign tarballs right now. i dun see why to even use a vtron then.
(trilema) 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.
(trilema) 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.
(trilema) asciilifeform: i think i grasp what trinque wants : for vtron to actually reflect the semantics of the code being juggled
(trilema) 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.