368 entries in 0.504s
<< 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☝︎
: my vtron
still won't press this, btw, even given all 3 patches.
: it is impossible to press this tree except by abusing a vtron
: ( i'd hope that new vtron
format will abolish all inbandism. )
: this has no effect on any extant vtron
( the resulting patches are correctly formatted ) .
: it matters , in particular in asciilifeform's vtron
: mircea_popescu: observe, phf is the only one with a trooly , properly strict vtron
, rejects non-uuencoded sigs.
: re vtools fwiw I pressed it fine with traditional vtron
: diana_coman: possibly i'm mistaken , will have to actually try the new vtool ( and whether it can be pressed with traditional vtron
: 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
: so that i gotta mandate every vtron
implements 500 hashers ?
: 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.
: 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 ;
: 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?
: is the task for esthlos here to produce a patch util that cares about hashes, or to build all patching functionality into the vtron
: looking again at his coad, seems like it simply calls out ( just like my vtron
did ) to patch util
: 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?
: 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)
: I agree, promisetronic without the vtron
getting angry at you over mismatched name
: mod6: what do you imagine needs to change in a vtron
to support the manifest?
: 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
: trinque: I added a manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron
, manifest) become declared "standard", if ever
: 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.
: whole process of talking with esthlos on the vtron
project has been a pleasure.
: esthlos here just cranked out a mighty fine vtron
without a fancy hat
: 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
: sure, but whether the same patch hunk ended up in two places is computable, interesting in a patch-viewer sense, not in a vtron
: phf: werentcha in the middle of a vtron
or do i misremember tho
: 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.
: 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)
: gotta hit the sack for now, vtron
: btw trinque, have made most of changes to vtron
, just have to add mkstemp for ccl (which I know thanks to phf is #_mkstemp)☟
: You've read the docs & use my vtron
enough to know this!
: ben_vulpes: a correctly-written adult vtron
should NEVER fail during press
: 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
: esthlos: where do you want input? comments on a-vtron
: so yes, a correctly implemented vtron
has no history file notion.
: as a side-note, my vtron
when doing operations and graphing checks *all* edges.
: 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' .
: 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: 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
: 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.
: mircea_popescu: thanks too for prodding me about Ada-vtron
. I'll poke at it as I can, for sure.
: (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.
: trinque: fwiw it was how my orig (unreleased) vtron
: ( it is apparently possible to write a vtron
, and not know what happens when you orphan a branch.. )
: esthlos: i recommend to take vtron
and experiment with it until you grasp how it works, it will click in your head quickly
: I did! Was simple as removing the robots.txt from .seals. btw I love the manual you included with yer vtron
: 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 ?
: 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 .
: ( or rather, just the whole-program representation therein -- it is not a vtron
ftr biased in favour of pills that leave the orig vtron
simple ( while potentially introducing a separate tool for testing conformance to chronology )
: 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
: phf: which is why i wrote the classical vtron
the way i did -- wanted max flexibility of form. and yes this has cost.
: original v left chronicling as a per-project convention, to the pleasure of the project operator, rather than part of vtron
: i was somehow quite certain that trinque had a pseudocode-algo for his improved vtron
: phf fixed it immediately when he wrote his patchviewer vtron
: 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.
: <+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.
: <+asciilifeform> hanbot: mod6's old vtron
did not support 'verbose' << pretty sure always did -- at least going back 2 years, aha.
: ooo ty asciilifeform, quite right. now how did i end up with old vtron
and new usermanual, lol
: hanbot: mod6's old vtron
did not support 'verbose'
: i do have the old mod6 vtron
, i'll look @ new, ty asciilifeform
: ( iirc mod6 introduced a check in a recent edition of his vtron
, but possible that hanbot has the old one ? )
: My vtron
also fails on this as well. I have a whole write up here. Stand by:
: 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.
: and phf's diff + ur vtron
passed a personal vtest 2gether as well
: I gotta get this mission critical stuff with vtron
out of the way. Then should be undertaking myself.
: The formal release version is planned of course. Thanks for paitence, and help to get this vtron
in proper working order.
: let the d00d write his vtron
. it's a homework, not a heroic quest . then -- beat with sticks. not before.
: before writing a vtron
, maybe spend sometime using one.
: 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
: but asciilifeform for one will read his vtron
. and ffa homework answers.
: 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.
: 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.
: meanwhile asciilifeform's vtron
on hold until i get python on server, nfs apparently eschews
: hanbot: see if you can achieve same barf with my vtron
: 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
: trinque: is there a changelog-eating vtron
: mircea_popescu: there is no way to weasel out of the fact that the info is available, but simply ignored by ineptly made vtron
: 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?