log☇︎
500 entries in 0.787s
asciilifeform finds this thread somewhat confusing, is probably doomed to actually read mod6's vtron and comment only after.
asciilifeform: when trinque posts his fixed patch util, it will be safe to remove this 'hair' from vtron.
asciilifeform: btw phf do you think we could get a src viewer in your vtron that makes this kind of thing apparent to naked eye?
asciilifeform: http://btcbase.org/log/2016-12-07#1578953 << theoretically v works exactly same with any diffing algo. but if you keep more than one type around, you gotta distinguish'em somehow, e.g., call your sexpr vtron's patches 'foo.lpatch' or similar ☝︎
mod6: and im stuck between trying to making getting trb up and going for people, in a "one-trigger-pull", and an organic vtron garden.
mod6: <+asciilifeform> http://btcbase.org/log/2016-09-15#1542102 << this would not be a good use of anyone's time, i have my own vtron << ok then. no. ☝︎
asciilifeform: http://btcbase.org/log/2016-09-15#1542102 << this would not be a good use of anyone's time, i have my own vtron ☝︎
asciilifeform: !~later tell mod6 i sat down to play with trinque's bots for kicks, and with your vtron, and noticed that the latter does not like to be 'init'-ed twice for 2 separate projects in one local dir. is this intentional ? and i still have problem grasping why we have the 'init' thing...
asciilifeform: that was not in my vtron.
asciilifeform: (he wrote a cl vtron and possibly other items)
asciilifeform: phf: it is how my vtron worked.
asciilifeform: e.g., mod6's vtron does not depend on trb in any way shape or form
asciilifeform: yeah but this is not done in any extant vtron.
asciilifeform: pop yer favourite text editor, and pick favourite vtron (i recommend mod6's) and play.
asciilifeform: srsly read the code, of ANYBODY's vtron
a111: Logged on 2016-02-08 20:09 ascii_butugychag: i will half-seriously suggest that we refer to the ~set of patches, seals, keys~ that a particular vtron is aware of at his particular point in spacetime, as... his lightcone
asciilifeform: realize, v was something that i was specifically only able to conceive of because i am working with cultured folks who can be relied upon to not shit in the kitchen. operating vtron will always require a good measure of intelligence, wisdom, restraint...
asciilifeform: my vtron was very much a battlefield wunderwaffen, adequate strictly for pressing a well-gardened trb tree that consisted 95% of asciilifeform
asciilifeform: well recall , my vtron was incomplete in the aspect where it assumed that any leaf was pressable per se
phf: (i don't really know how mod6's vtron operates, only speaking of mine and asciilifeform's)
asciilifeform: well phf was , i think, speaking of the basic vtron conceptually
trinque: mrottenkolber: consider that as specified the total source code involved in a vtron can *decrease* drastically from here.
asciilifeform: mod6: correct vtron will exponentiate inside itself.
asciilifeform: mod6: a proper vtron won't call out to shell
mod6: speaking of which... if we were still going to use scheme, long-term, i'd probably re-write my vtron in scheme -- if for no other reason, to learn it.
mod6: phf: well, other than saying "interesting" and "cool", i couldn't figure out how to do that either. unless we create a vtron signature style in 'g' or is it 'p'? i cant recall.. cause how will someones vtron be able to pull the bit string out to know how to categorize someones seal?
mod6: and you sign your vtron keys with your one regular key? i dunno.
asciilifeform: i.e. of a vtron being confused by an enemy digging up ancient signed material.
jurov: vtron would just say to you that the antisig from your wot exists
jurov: for poor vtron to be able to distinguish signatures and antisignatures
asciilifeform: when we get a turingcomplete vtron, i will regrind all of my works
asciilifeform: the inevitable thing is that vtron users' expectations must re-adjust.
jurov: maybe we'll end up with vtron that actually allow to implement source code parser inside vpatches so that it computes checksums for every function
asciilifeform: all i ask for is that vtron be able to specify arbitrary transformations, e.g., 'replace every letter a with b', rather than the +++/--- imbecility.
asciilifeform: any future folks who might think they are being clever with, e.g., nonterminating vtron program.
punkman: asciilifeform: afaik we don't presently have a vtron that is capable of digesting everything incl. the old crud. << my vtron digests conflicting patches
asciilifeform: iirc he was mainly bleeding to get his vtron up to par ?
asciilifeform: but this is unfortunately not a vtronic operation, because we have idiot diff and not a turing-complete vtron.
asciilifeform: afaik we don't presently have a vtron that is capable of digesting everything incl. the old crud.
asciilifeform: phf: you don't need vtron for this, go use bare hands
punkman: phf, seems so. my initial suggestion was releases as patch sequence files, but I don't think anyone liked this idea. My vtron does .seq files with "foo.vpatch \t sha512(foo.vpatch) \n" inside, which works for my blobby vtronized things.
mod6: i even had a thought, and im not even sure its feasible technically or just logically, but; we could perhaps create a wrapper for gnu patch where we strip out lines that are surrounded with "%%" or something similar to how it does with "@@", this would ultimately be needed in vtron as well to avoid issues. But the thought is, then we could put comments directly in the vpatch (surrounded by '%%') and
asciilifeform: is anyone still unclear why i did not and still do not want curl in vtron ?!!!!
assbot: Successfully updated the rating for mod6 from 3 to 5 with note: met alive; expert gardener of therealbitcoin.org; implementer of the first fully-functional battlefield-grade vtron.
asciilifeform: !rate mod6 5 met alive; expert gardener of therealbitcoin.org; implementer of the first fully-functional battlefield-grade vtron.
punkman: asciilifeform: .. << turing-complete vtron or bust << I'll get there eventually. Though, I think the standard unified-diff representation is useful even if patchons consisting of script are available.
asciilifeform: http://log.bitcoin-assets.com/?date=11-02-2016#1402714 << turing-complete vtron or bust ☝︎
asciilifeform: i will also note that all of this was part of my original concept for vtron
asciilifeform: if not barfs, then broken vtron.
ascii_butugychag: i will half-seriously suggest that we refer to the ~set of patches, seals, keys~ that a particular vtron is aware of at his particular point in spacetime, as... his lightcone ☟︎
ben_vulpes: http://log.bitcoin-assets.com/?date=03-02-2016#1395703 << so here's what my (unreleased, v2) vtron does: it grabs all patches and all sigs, merges them into an alphabetically sorted list, and then munches through that list attaching sigs whose name matches the previous patch to that patch. is this a blindingly stupid thing to do? i realize that it depends implicitly on the naming convention, but would like to hear about other unrealized ☝︎
ben_vulpes: ascii_rear: i recall reading in the log that your vtron's implicit pressing behavior is asciibetical up to indicated head, but i'm having trouble reconciling that with other reqs i once read: that vs press longest chain, and also that vs press all usable patches. would that accurately modify to 'longest chain up to indicated head'?
ascii_butugychag: (and this oughta be checked for by a vtron)
mod6: well, hopefully my vtron works correctly.
ascii_butugychag: supposing that your vtron works correctly
ascii_butugychag: jurov: sure but now every vtron would need to be rewritten to actually break down filenames
asciilifeform: anything that can sit down into a vtron, is pressable.
ascii_butugychag: my vtron had it
ascii_butugychag: PeterL: my original vtron was controlled by manually selecting patch sets
ascii_butugychag: jurov: a correctly-designed vtron - absolutely will
ascii_butugychag: (my own vtron verified nothing at all, i must point out.)
ascii_butugychag: i thought mod6's vtron actually verified each patch operation ?
asciilifeform: btw this is the kind of question a working vtron oughta answer in <1sec
adlai: phf: this web-facing thing is part of your CL vtron?
asciilifeform: phf: see my original vtron.
asciilifeform: vtron, in primary mode of operation, is to climb the tree, as high as it can on each branch, operating using the current wotset
asciilifeform: does anyone recall how my original vtron only showed linear flow ?
assbot: Logged on 31-01-2016 07:35:23; ben_vulpes: is everyone who hacks on this thing to write and use their own vtronic cockpit controls? or is the production of /a/ vtron usable in other contexts a goal?
ben_vulpes: is everyone who hacks on this thing to write and use their own vtronic cockpit controls? or is the production of /a/ vtron usable in other contexts a goal? ☟︎
ascii_butugychag: mircea_popescu: what i want is not a gutted corpse of gnudiff, but a turing-complete vtron
ascii_butugychag: i confess that i've been using my ancient vtron. but will prolly switch to mod6's industrial-strength one very soon
mircea_popescu: <ascii_butugychag> ideally a vtron ought to be able to apply ANY well-defined operation << quite this, tho we might have to get there in steps.
ascii_butugychag: turing-complete vtron
mod6: <+ascii_butugychag> ideally a vtron ought to be able to apply ANY well-defined operation << ok sure, this could be a separate feature of V i guess... have to think on this.
ascii_butugychag: ideally a vtron ought to be able to apply ANY well-defined operation
mircea_popescu: ascii_butugychag mod6 if you wish to consider a general problem : what is the ~correct~ thing to do for vtron when it encounters two validly signed patches doing the same thing ?
ascii_butugychag: i broke my head on this for a while, and settled on '~/.wot by default, user-specified wot whenever you want' when i did vtron.
mod6: <+ascii_butugychag> i still don't get why a vtron should use the net at all << I'm open to well defined explicit ideas here.
ascii_butugychag: i still don't get why a vtron should use the net at all
mod6: <+ascii_butugychag> mod6: should i re-grind the ts genesis? or can your vtron eat this without choking. << i can throw it in my patches dir tonight and see what it does with it.
ascii_butugychag: mod6: should i re-grind the ts genesis? or can your vtron eat this without choking.
mod6: <+asciilifeform> mod6: does your vtron implement 'origin' ? << no
asciilifeform: mod6: does your vtron implement 'origin' ?
asciilifeform: http://log.bitcoin-assets.com/?date=21-01-2016#1379583 << incidentally, ~this~ is what the 'origin' command in my vtron did ☝︎
mircea_popescu: linton_s_dawson http://trilema.com/2016/the-v-manual-genesis/ << there's an attempt at a manual. you could also search for vtron and v-tron, alf tens to use it a lot. the mailing list is also a good source.
ascii_butugychag: which was really the original stone age vtron.
asciilifeform: (which, of course, would mean that a correct vtron does not presently exist...)
asciilifeform: http://log.bitcoin-assets.com/?date=16-01-2016#1373434 << while this is a correct description, i would also like to add that a ~correct~ vtron is also defined as being SPECIFICALLY NOT THIS : http://log.bitcoin-assets.com/?date=14-01-2016#1370325 ☝︎☝︎
asciilifeform: http://log.bitcoin-assets.com/?date=16-01-2016#1373494 << i've actually thought about writing, for lulz, a vtron in... gnumake ☝︎
asciilifeform: to see what i mean, break all vpatches apart on file-hash tuple boundaries, and then feed into mod6's vtron set to wild mode, and generate the plot
asciilifeform: must understand that 'patch' is simply one possible operation for a vtron
asciilifeform: http://therealbitcoin.org/ml/btc-dev/2015-November/000179.html << mod6's far spiffier vtron
asciilifeform: http://log.bitcoin-assets.com/?date=21-12-2015#1349614 << using whose vtron ? ☝︎
mircea_popescu: asciilifeform: the other thing a vtron needs to handle is orphans << heh.
asciilifeform: it is handy for testing a vtron
asciilifeform: also if you set your vtron to 'wild' mode you can trivially test various combos
asciilifeform: if the toposort is correctly written, mod6's vtron ought to do it
asciilifeform: the other thing a vtron needs to handle is orphans
asciilifeform: mod6: ideally a vtron would follow along as the patches are applied and actually verify the hashes, yes
asciilifeform: the only item that requires manual handling in a correct vtron is keys.