500 entries in 0.751s
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.
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
phf: (i don't really know how mod6's
vtron operates, only speaking of mine and asciilifeform's)
trinque: mrottenkolber: consider that as specified the total source code involved in a
vtron can *decrease* drastically from here.
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.
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
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
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
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
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.
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.
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'?
mod6: well, hopefully my
vtron works correctly.
ascii_butugychag: jurov: sure but now every
vtron would need to be rewritten to actually break down filenames
ascii_butugychag: PeterL: my original
vtron was controlled by manually selecting patch sets
ascii_butugychag: i thought mod6's
vtron actually verified each patch operation ?
adlai: phf: this web-facing thing is part of your CL
vtron?
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.
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.
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
mircea_popescu: asciilifeform: the other thing a
vtron needs to handle is orphans << heh.