log☇︎
131800+ entries in 0.079s
mircea_popescu: so for instance, "genesis a proper db ; then patch in three different branches for the three different types of node envisaged" doesn't seem on the face problematic.
trinque: anyhow lemme run at it again. you can't modularize because you have to fake work in a disparate part of the tree to merge
asciilifeform: if it dun have a trb genesis, proving to proverbial martian that it really does have classical 0.5.3 pedigree, goes from trivial to monumentallypainful
mircea_popescu: ie, i don't expect the trb cut as described to have a trb genesis necessariyl, or even probably.
mircea_popescu: there's nothing wrong either in principle or in practice with making a correct item as the genesis and then patching in various parts of trb.
trinque: in that these are distinct items.
mircea_popescu: ie it takes a major regrind ?
mircea_popescu: well, i am kind of a fan of the whole "v doesn't permit you to lie to yourself about having supposedly designed what's utterly an ad-hoc item".
trinque: this is what I meant actually, by "can't modularize" within same walk of the v tree
mircea_popescu: now, is this enforcement a problem with v, is the proposition ? or is the aforegoing a misrepresentation of the discussion ?
mircea_popescu: v doesn't permit this backwards in time ; and if you run in this situation where johnny needs an experts' sex change to become evvie, it's high fucking time you hand-rewrote your whole steaming pile of crap.
mircea_popescu: s hack it backwards in time".
mircea_popescu: let me put it this way, maybe resolves problem : v unpermits a specific kind of hack within the purview of this discussion, wherein one tries to design after the fact. correctly designed items will have the larger bits (by footprint) earlier in the patch tree ; and fray out correctly. github-style nonsensica commonly attempts to discover that "hey, this johnny come lately item should have been an evie-comes-early MODULE, let' ☟︎
trinque: I'm actually writing right now on how the hypertext thing relates
trinque: cannot without the 'add comment to files you needed' ritual
trinque: means for example that db-interaction routines are in one file, network interactions in another.
a111: Logged on 2017-12-27 01:41 trinque: http://btcbase.org/log/2017-12-27#1758909 << if vtronic software is the same frayed rope, no one can ever modularize within the same v-tree. this may be a feature.
mircea_popescu: "hey, aren't you worried your shitcoin will get altcoin'd in the near future ?" "no, i am dog and i don't understand anything. vote me!"
mircea_popescu: lmao fucktard. a) the "pirate party" scam utterly fucking failed, how about addressing THAT ; b) kinda hard to have anyone ditch an empty ship, huh.
shinohai: From the twatter lulz mines: http://archive.is/vE3ud
asciilifeform much looks forward to reading
trinque will put some pen to paper this evening
a111: Logged on 2017-12-19 18:04 asciilifeform: we actually had the ast-diff thread, re phf's lisp diff lament.
asciilifeform: but this is reaching into the fantastic.
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 ☟︎
asciilifeform: picture a kind of 'multiverse ada', where you dun call foo(bar), but instead foo:somepatchid(bar:somepatchid) etc, explicitly conforming to 'multiversism'... ☟︎
asciilifeform: and especially this one, v that understands entity introductions / uses, semantic linkage aligned with v-flow ... i'd like to see it
asciilifeform: i'd like to encourage trinque to put some of his 'crackpot' algos 'to paper', as articles. the hypertext thing was interesting imho, for instance, and so was earlier trinque pill for 'mining is a bug', and possibly other occasions. dun be afraid to write down conjectures, trinque , gauss did ☟︎
asciilifeform: trinque: if you have concrete algo to align these -- i'm all ears
trinque: asciilifeform: is possible, but deserves to be in the logs
trinque: to my mind the hash is currently putting too narrow a constraint on the context within which the current patch is to be applied, where we could broaden the context at no detrimental, and possibly beneficial cost
asciilifeform: trinque: i'd go as far as to say that what you're observing is a defect in cpp, not v.
a111: Logged on 2017-12-26 21:22 trinque: http://btcbase.org/log/2017-12-26#1758679 << to my mind this suggests the hashes present in vpatch blocks are wrong. if they were rather the hash of the entire concatenation of the diffed item before and after applying that block, there'd be no need to pointlessly edit files to continue on the same branch.
asciilifeform: ( btw is there an engl. equiv of that term ? i'd like to learn it )
trinque: only way to make a 3rd improvement rely on two distinct improvements in past is to put cruft in both. ☟︎
asciilifeform: and yes every patch oughta stand as a leaf, pressable to .
asciilifeform: down to genesis.
trinque: should someone pressing think he has a coherent whole after pressing any patch? if not why?
trinque: what is the meaning of the hashes in a vpatch?
asciilifeform: that was a case when 'put in a comment to align vtronics and semantics' would have been The Right Thing
asciilifeform: asciilifeform introduced the schemetron 1st, and only 2nd the glue in trb, and they were not automagically v-linked
a111: Logged on 2017-12-21 17:38 mircea_popescu: anyway, continuing the trinque discussion, it seems entirely unavoidable that trb will become 3 things : a wallet node, optimized for pumping out local signed tx ; a block node, optimized for keeping the blockchain, getting blocks, no mempool nonsense ; and a spy node, optimized to keeping track of the lies and nonsense flowing through the relay network (mempool, timing nodes, what have you).
trinque notes that this comes up within days of the http://btcbase.org/log/2017-12-21#1756072 ☝︎
asciilifeform: shiva series was imho great example of 'coarse error in pilotage' re this thread
trinque: so then, when things get so modular that you have frayed rope, author makes clean separation, as V has told him he has distinct items.
asciilifeform: trinque: it is only a problem if people do it unthinkingly, without understanding when to, when not to, and why
asciilifeform: trinque: i actually put a good bit of thought into the vtronic shape of ffa, while rewriting it ( current-day ffa , observe, is a rewrite, largely by hand, of the previous )
trinque: in either case, what does asciilifeform think of the ritual of "add comment to unrelated file to merge paths", not symptomatic of a problem?
trinque: it again runs into the unix idiocy of "file", though, because file does sometimes mean module, sometimes means subcomponent of module.
a111: Logged on 2017-12-27 00:46 mircea_popescu: http://btcbase.org/log/2017-12-27#1758883 << sure. in the sense blockchain is frayed rope, this also.
trinque: http://btcbase.org/log/2017-12-27#1758909 << if vtronic software is the same frayed rope, no one can ever modularize within the same v-tree. this may be a feature. ☝︎☟︎
asciilifeform: ffa is, among other things, an experiment with minimizing theugly.
a111: Logged on 2017-12-27 00:49 mircea_popescu: http://btcbase.org/log/2017-12-27#1758901 << what's the problem with a "wasted" FZ anyway
asciilifeform: http://btcbase.org/log/2017-12-27#1758913 << it's not the wasted 8kbit or whatnot ( though on e.g. fpga, that's real waste that you can take to the bank...) but the ~ugliness~ ☝︎
BingoBoingo: Makes engineering physical things easier
BingoBoingo: Eh, give it 10 years and everything Republican will be inconel while the last USG trinkets come in Chinese potmetal
a111: Logged on 2017-12-27 00:45 mircea_popescu: http://btcbase.org/log/2017-12-27#1758864 << you engage in a category error. you don't know what's in the box BEFORE opening the box.
asciilifeform: http://btcbase.org/log/2017-12-27#1758907 << the reason engineering is even possible , is that it is not necessary to open ~every~ box. sometimes can form quite accurate picture without spending whole life opening boxes, eating every rotten egg top to bottom etc ☝︎
mircea_popescu: 20bux in the chinoshop
mircea_popescu: damned thing was the size of a god damned depth charge
BingoBoingo: Ah, I did the math the other way, Gracias
BingoBoingo: Will probably start upping the blog frequency to let some more vemon out
BingoBoingo: Anyways thinking on the noob roughing up earlier, could be a side effect of tranquility overdose. Gotta torture betas.
BingoBoingo: Hence the spankings and vacuum cleaner tube
mircea_popescu: a sense of confort, the common woman's mindeater.
a111: Logged on 2017-12-26 22:22 danielpbarron: wasn't indiancandy/sofiababy looking for a way to make bitcoin?
BingoBoingo: <mircea_popescu> http://btcbase.org/log/2017-12-26#1758819 << she kinda got sent off for NOT being looking dedicatedly enough ; then she got pissy because i imagine in her dumb head she had self-delusions as to self-importance as dear as they were baseless. << Ah, gets BTC once returns years later and has less sense and more ideas ☝︎
mircea_popescu: if you register a key you can self-voice don't have to keep doing this voicing thing
mircea_popescu: anyway, maybe the correct approach re the l0de thing would be something like a simulcast interview. you do interviews l0de ?
mircea_popescu: http://btcbase.org/log/2017-12-27#1758901 << what's the problem with a "wasted" FZ anyway ☝︎☟︎
a111: Logged on 2017-12-27 00:23 asciilifeform: http://btcbase.org/log/2017-12-26#1758779 << i see e.g. trb tree, as the frayed end of a rope. in long term, observe, the loose ends that dun get built on -- fade away, like orphan chains. btc is actually more or less same kind of system. but iirc we had this thread.
mircea_popescu: http://btcbase.org/log/2017-12-27#1758883 << sure. in the sense blockchain is frayed rope, this also. ☝︎☟︎
a111: Logged on 2017-12-27 00:06 asciilifeform: let's say every homo redditus alive -- suddenly interested. then WHAT? what's gained, other than a great mass of meat that now gotta be put somewhere far from the reactor rods
mircea_popescu: http://btcbase.org/log/2017-12-27#1758864 << you engage in a category error. you don't know what's in the box BEFORE opening the box. ☝︎☟︎
mircea_popescu: http://btcbase.org/log/2017-12-27#1758859 << gotta get SOME filtering process in place though ☝︎
asciilifeform: http://btcbase.org/log/2017-12-26#1758681 << if there existed anything like a market in (reasonably recent) miners -- they'd already be installed at the plant, in place of those gigantic resistors . ( and iirc there was a mircea_popescu thread, involving e.g. fish ponds ) ☝︎
asciilifeform: which is roughly 4x the typical ( thing's been floundering since late august ) rate.
asciilifeform: in other noose, zoolag with 'aggression' : walked from 484621 to 495973 in ~60 hrs.
asciilifeform: http://btcbase.org/log/2017-12-26#1758743 << this historically worked CONSIDERABLY better than 'let's throw the reddit toilet into reverse gear and see what crawls out of the pipe' ☝︎☟︎
a111: Logged on 2017-12-26 20:29 mircea_popescu just dumped a whole sack of coal on teh grill, teh girls happily cleanning up a grosse of pleurotus... if anyone needs me ima be at teh rancho bbqing.
asciilifeform: ben_vulpes: ( trinque ? ) what ~concrete~ operation on trb tree did v-as-it-nao-exists keep you from easily carrying out ? i'd like to see ?
asciilifeform: what is with this eagerness to pointlessly blunt the knife. i dunget it !
asciilifeform: i ~like~ that it is clear what parts of a whole were changed, and what -- left alone.
a111: Logged on 2017-12-26 21:22 trinque: http://btcbase.org/log/2017-12-26#1758679 << to my mind this suggests the hashes present in vpatch blocks are wrong. if they were rather the hash of the entire concatenation of the diffed item before and after applying that block, there'd be no need to pointlessly edit files to continue on the same branch.
asciilifeform: http://btcbase.org/log/2017-12-26#1758770 << this is not unlike poking out one of your eyes to save on eyeglasses cost. ☝︎
asciilifeform: ( i.e. it is already inescapably linear. asciilifeform half-expected that the kakoschism would produce a long-playing split of the trb universe, but neverhappened. not every possible thing, happens... )
asciilifeform: http://btcbase.org/log/2017-12-26#1758779 << i see e.g. trb tree, as the frayed end of a rope. in long term, observe, the loose ends that dun get built on -- fade away, like orphan chains. btc is actually more or less same kind of system. but iirc we had this thread. ☝︎☟︎
asciilifeform: and how big will be the vtron ? mine was <400 lines. imho this is worth something. and every feature added, comes at a cost.
asciilifeform: every time think of a possible change : think, does this take it in the direction of heathendom ? can it still make a patch like http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks , where it is hammer-in-your-face-obvious to the reader that every single fucking line does ?
asciilifeform: i would like everybody who is itching to change the way v fundamentally works, to sit down and think about why we ain't using 'git' etc.
asciilifeform: i should not need to look for a meta-document (with own sig, presumably) to know which group of patchons constitutes e.g. 'asciilifeform_dns_thermonyukyoolar_kleansing' .
a111: Logged on 2017-12-26 21:42 phf: we also at some point had a thread, where i believe ascii but also others were leaning towards the idea of a single file vpatches (i.e. that a vpatch should only ever contain hunks for a single file). i'm starting to think that multi-file solutions in general are a hack ("we can't fit the entire compilation in memory"), but then i've been looking at TeX on one hand, and the "millions of support files" in diff/patch on the other
asciilifeform: http://btcbase.org/log/2017-12-26#1758790 << this'd eat away substantially at the human-readability of the vpatch. which imho is a key property. ☝︎
a111: Logged on 2017-12-26 21:36 ben_vulpes: this still leaves me in the pickle of producing a vpatch from a press to a that won't actually descend linearly from a without touching a file, and adding "this line necessary to ensure this vpatch descends from a and not genesis"
asciilifeform: http://btcbase.org/log/2017-12-26#1758781 << this only oughta be done in 2 situations -- 'releases' , as discussed by mod6 et al ; and to avoid fuckuppy as seen in orig shiva patch, where there was a logical dependence , but not a vtronic one , b/w shiva-part1 and -part2 ☝︎
asciilifeform: a v user is expected to do ~almost all~ of his manipulations, via manual file management.
asciilifeform: which, in the whole picture, does not come close to topping the list of the hardest labours of a trb experimenter
asciilifeform: but you can replicate same effect by pressing by the press rules, and then copying by hand.
asciilifeform: ( it was , naturally, by having , at least in the early history, the tree from which each of the 'sibling' patches was produced, on account of having produced'em ) .
a111: Logged on 2017-12-26 21:42 ben_vulpes: phf: this exposes another problem: in ideal vtronics it is an illegal operation to press to multiple leaves at the same tree level, which is the only way to have a codebase against which to create a makefiles-type patch that ties multiple patches together