500 entries in 0.719s
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.
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.
mod6: <+asciilifeform> hanbot: mod6's old
vtron did not support 'verbose' << pretty sure always did -- at least going back 2 years, aha.
hanbot: ooo ty asciilifeform, quite right. now how did i end up with old
vtron and new usermanual, lol
hanbot: i do have the old mod6
vtron, i'll look @ new, ty asciilifeform
mod6: My
vtron also fails on this as well. I have a whole write up here. Stand by:
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.
shinohai: and phf's diff + ur
vtron passed a personal vtest 2gether as well
mod6: I gotta get this mission critical stuff with
vtron out of the way. Then should be undertaking myself.
mod6: The formal release version is planned of course. Thanks for paitence, and help to get this
vtron in proper working order.
mod6: before writing a
vtron, maybe spend sometime using one.
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.
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.
hanbot: meanwhile asciilifeform's
vtron on hold until i get python on server, nfs apparently eschews
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?
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.
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.
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.
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.
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 )
mod6: anyway, i appreciate all the feedback. its obvious that there is passion to get this part of my
vtron right.
mod6: before i ever 'green light' that kinda use of my
vtron, i'd certainly like to test it myself etc. and ya, that dir would have to be unique.
mod6: my
vtron has been discussed very much over the last 2+ years. i remember many disucssions where rules popped out.
☟︎ mod6: <+asciilifeform> no good. first of all suppose there are 2 concurrent runs of the
vtron ( say this is a cuntoo pressing itself ) << yeah, concurrent runs of my
vtron are a no-go.
mod6: <+asciilifeform> mod6: an aborted run of
vtron should not be able to put a caltrop for subsequent run to die on. this is imho elementary.
mod6: otherwise, my
vtron handles the creation and deletion of that .gnupgtmp dir on its own.
mod6: <+ben_vulpes> mod6: while you're in there can you get your
vtron to cleanup its tmp gnupg directory when it catches a ctrl-c? << if you CTRL+C the thing, it really can't get rid of it. you're expected to clean this up on your own so the
vtron doesn't remove something it wasn't suppoesd to.
ben_vulpes: mod6: while you're in there can you get your
vtron to cleanup its tmp gnupg directory when it catches a ctrl-c?
a111: Logged on 2017-12-24 02:53 trinque: tangentially yet again, I'd really like a
vtron to put in this here cuntoo.
a111: Logged on 2017-12-27 02:03 asciilifeform: or, on other end of the possible, a
vtron that somehow understands that a call of foo necessarily depends on the patch that birthed foo... and requires disambiguation only if >1 foo exists in the tree
trinque: tangentially yet again, I'd really like a
vtron to put in this here cuntoo.
☟︎ a111: Logged on 2017-12-14 15:51 asciilifeform: phf: given example works with my
vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
mod6: your example will not work with my
vtron, for one simple reason: the new rules state that we do not do ANYTHING with vpatches that do not have a corresponding signature - we IGNORE WILD vpatches and drop them on the floor.
mod6: <+diana_coman> I can confirm this version presses with mod6's
vtron << thanks for checking this out too!
diana_coman: I can confirm this version presses with mod6's
vtron mircea_popescu: i suppose the third alternative is to actually implement a proper diff as part of
vtron mircea_popescu: on a long enough timeframe, there's going to exist a
vtron in ~any language anyway, i expect.
mircea_popescu: original mod6 perl
vtron was important prototype in the early life of v, made all sorts of latter things possible. exactly like original bitcoin. nobody said you have to marry it now though ; or divorce it for that matter.