Hide Idle (>14 d.) Chans
← 2018-03-29 | 2018-03-31 → ↓
mircea_popescu: in other suicide notes : i had girl grind into fine dust a 100% chocolate bar while another ground into similarily fine dust semillas de maranon. i myself was dumping raisins into rum.
mircea_popescu: AND THEN i cooked the flour in the fat and bechamel'd it with the alcohol. the resulting sauce got poured over cut up bananas.
mircea_popescu: it is now in the freezer. i'm having the third serving. best 300 calorie spoonfulls i ever had.
mircea_popescu: in case this is the last you hear of me -- know i've had a good life.
mod6: :]
mod6: sounds awesome
mircea_popescu: douchebag btw, what happened to the drawer guy ?
ave1: mod6, I'm sorry I forgot the project name(http://btcbase.org/log/2018-03-30#1791071), this should do the trick: gprclean vdiff.gpr; gprbuild -v vdiff.gpr
a111: Logged on 2018-03-30 01:29 mod6: ave1: http://p.bvulpes.com/pastes/FQrCw/?raw=true
douchebag: he hasn't gotten back to me :/
mircea_popescu: i dunno wtf is it with sketchers, but they're the sketchiest bunch by far.
douchebag: They always bitch about not having money
douchebag: and then when you offer them work they're too lazy to do the work
douchebag: Basically they think they're artists because they smoke pot and draw shit
mircea_popescu: must be.
ave1: mod6, well your environment is sound and exactly the same as mine. Also you get the same error. Spyked patch should fix it (or open lib/xalloc.h and add static to all inline void functions that do not already have a static). It may be that phfs' enviroment is different (so far as I can see, spyked, hanbot, me and you all have the same problem).
ave1: btw I tried adding -flto/-fno-lto flags and optimization flags, but these did nothing for me.
mod6: Thanks ave1
douchebag: mircea_popescu: I have a girl but she is wondering if she's allowed to wear sunglasses
mircea_popescu: she isn't.
douchebag: Alright, told her that's a no - let's see how this goes
douchebag: mpex.biz is not loading ?
mircea_popescu: a did it crap out ?
mod6: down here too
mircea_popescu puts on list for tomorrow.
douchebag: I was wondering, how much would I earn from writing qntra articles?
douchebag: mircea_popescu: A woman is interested in the tits offer, but she's morbidly obese
ben_vulpes: and then once you write a qntra article, you'll wonder whether or not you should sell the shares you get for it on the spot or hold out for a better price
douchebag: ben_vulpes: How much are qntra shares worth at the moment?
ben_vulpes: douchebag: do you know where it's traded?
ben_vulpes: man i don't know anything about port but this is delicious
douchebag: I assumed mpex.biz but since that's down at the moment I wasn't able to verify
ben_vulpes: it's like two links deep off the homepage
douchebag: Anyway though, she wants to know if she'll still get paid even though shes a porker
ben_vulpes: why not let the girl speak for herself
douchebag: Sure
ben_vulpes: btw douchebag are you following the shared hosting php saga in #pizarro?
douchebag: No I'm not in there, can you give me a brief overview of what's going down?
douchebag: dagofbicks is here to show tits btw
ben_vulpes: douchebag: no, read the logs it's not that dense
mimisbrunnr: Logged on 2018-03-23 04:27 mircea_popescu: im starting to understand that "the opposite of talking is not listening, the opposite of talking is waiting for your turn" quip may have been adequate in the early postmodern stage ; but by now it's truly a case of "work efficiency is most work with least read." chucka wins in the end.
ave1: diana_coman: could the input parameter of rsa_oaep_encrypt be a character array? it is now an MPI this will discard any leading zero's of a message an exclude binary stream/file encryption. (same goes for decrypt)
ave1: an exclude -> and exclude
diana_coman: to answer your question directly though: 1. it certainly could - rsa_oaep_encrypt is just a wrapper so it's meant more as an example of using all the stuff together rather than a standard: I'd expect that there would be other/different wrappers, made to suit specific uses
mircea_popescu: aand in other morning glories, "i dreamed that i was in trouble, i don't know what, and i was walking back to where you were, shaking incontrollably from all joints. but then, voice-of-god you, that was in the air, said "don't worry about it, pet. go back to sleep". so i went back to sleep." "did i also look like the old king on the packaging of small chocolates ?" "no, you didn't look like anything, it was just the voice."
mircea_popescu: see what the whip does ? it makes gods of people!
ave1: diana_comon, Yes, I read the test and the code and your text (also played with the test a little). So I was a little suprised that rsa_oaep_encrypt used mpi code. I will write an alternative.
ave1: and another typo (i'm sorry) -> diana_coman
diana_coman: ave1, writing an alternative sounds great to me; (and no worries re typo; auto-complete is convenient though)
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-30#322461 << you get one share per word at the end of the month.
mimisbrunnr: Logged on 2018-03-30 06:14 douchebag: I was wondering, how much would I earn from writing qntra articles?
mircea_popescu: look for the editor in chief reports, they detail it.
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-30#322467 << sadly all proxies took a long walk off a short pier ; working on remedial.
mimisbrunnr: Logged on 2018-03-30 06:18 ben_vulpes: douchebag: do you know where it's traded?
mimisbrunnr: Logged on 2018-03-30 06:24 douchebag: Anyway though, she wants to know if she'll still get paid even though shes a porker
douchebag: alright, she's offline at the moment. I'll let her know whenever she decides to get on
mircea_popescu: no biggy.
mircea_popescu: don't stress out, the show's here all day.
deedbot: http://www.dianacoman.com/2018/03/30/my-first-2-years-as-cto-for-minigame/ << Ossasepia - My First 2 Years as CTO for Minigame
phf: http://btcbase.org/log/2018-03-30#1791228 << i'll publish the relevant patchsets on btcbase this saturday; i've read the relevant specs and the issue seems to be straightforward, what is annoying though is that for whatever reason it's not uniform across platforms.
a111: Logged on 2018-03-30 05:00 ave1: mod6, well your environment is sound and exactly the same as mine. Also you get the same error. Spyked patch should fix it (or open lib/xalloc.h and add static to all inline void functions that do not already have a static). It may be that phfs' enviroment is different (so far as I can see, spyked, hanbot, me and you all have the same problem).
mimisbrunnr: Logged on 2018-03-29 14:53 mircea_popescu: is this deliberate or oversight phf ?
phf: http://btcbase.org/log/2018-03-30#1791198 << there's already a generation of kids coming up for whom alt-right/feminism is what old people do; they want to be able to post fashwave pictures, while remaining mostly pantsuit. for them facebook/twitter is where they maintain public teacher/parents friendly identity, and mastodon/discord is where they can be themselves. it's basically just another wave of social networks.
a111: Logged on 2018-03-30 03:53 asciilifeform: douchebag: can you shed light on popularity of 'discord' item ?
douchebag: eh discord is used by a lot of autistic people
douchebag: gremlin is here to show tits bt
phf: mp picked up on your use of "autistic", which i didn't grok myself http://btcbase.org/log/2018-03-29#1791068
a111: Logged on 2018-03-29 23:39 mircea_popescu: i suspect by now "autistic" is the equivalent of the 1800s "friend". "one of ours" as opposed to "one of theirs"
douchebag: No, just a strange group of people
douchebag: oh shes back as grimm I guess
ben_vulpes: !!up grimm
deedbot: grimm voiced for 30 minutes.
grimm: im here to show tits
deedbot: E650469615F2EC9815C4589C8D806BAE3615D0E7 registered as grimm.
mircea_popescu: grimm did you ever do it before ?
grimm: nop
mircea_popescu: mk ; do a good job, will you. 5efeec1f
grimm: ye sure will sec
mircea_popescu: phf mp has the advantage of a full house. but anyway, yes, very much so, "twitter is the secret treefort mom knows about ; and then discord is the secret basement where https://www.reddit.com/r/stupidslutsclub/comments/87421g/do_you_know_where_your_daughters_are/ "
mircea_popescu: !!pay grimm 0.02
douchebag: grimm: it takes a moment
grimm: !!balance
mircea_popescu: (btw, vice is SO butthurt at "fashwave" it's something else. how fucktarded do these shriveled up, useless cunts who thought they can "become writers" need to be not to realise that the only thing they're doing is fanning teh fire ? aaanyways)
asciilifeform: what are the last 2 characters in the magicstring in that titpic ?
mircea_popescu: asciilifeform looks like tittycode for 1 and f
grimm: i just wrote what was given
grimm: !!balance
mircea_popescu: grimm you wrote the 1 backwards which is funny
grimm: lol sorry
grimm: !!withdraw 0.02 3FabNPwSNoaQEAfk9qCmb6Sj9BtJ7g8uGV
grimm: numbers from upside down are hard
mircea_popescu: we've been discovering\
deedbot: http://qntra.net/2018/03/gold-diggers-take-grace-mugabes-farm-as-precedent-of-uncompensated-land-seizure-turns-on-the-mugabes/ << Qntra - Gold Diggers Take Grace Mugabe's Farm As Precedent Of Uncompensated Land Seizure Turns on The Mugabes
grimm: !!v CF01914134E1A5C9419231F3CDA505B749906689AA6E0ABF88EF5EBE3D838393
grimm: thank you ill tell all my friends ahahaha
mircea_popescu: grimm please do.
BingoBoingo: <mircea_popescu> (btw, vice is SO butthurt at "fashwave" it's something else. how fucktarded do these shriveled up, useless cunts who thought they can "become writers" need to be not to realise that the only thing they're doing is fanning teh fire ? aaanyways) << It's like bull baiting, but with babushkas
trinque: BingoBoingo with the unmatched comedic timing
mircea_popescu: "qntra : under the deluge of tit bits, website-exchanges btc price keeps falling" lmao
mircea_popescu: trinque i k r!!1
mircea_popescu: i wonder which one of these identitties will pop up later doing anything worth the mention.
asciilifeform: any from prev years popped up so far ?
mircea_popescu: what's in a year. people who "become president" on stanford's list usually take 3-5 decades.
asciilifeform will be surprised, impressed, if it ever becomes known that one of these folx kept the 0.02 for decades
mircea_popescu: tis a distinct possibilitit.
asciilifeform: ( the more frequent ending seems to be the one pictured in http://trilema.com/2013/and-then-i-said-to-him-jimmy )
phf: http://btcbase.org/log/2018-03-30#1791280 << it's an oversight. i thought that the idea is that my vdiff/vpatch support programmatically whatever manifest format we come up with, but somebody demonstrates how it's supposed to work first. it's not hard to regrind existing tree, manually add a manifest, and then see how it looks on a graph. for some reason i thought that trinque has that experiment in his pipeline, since he also seems to have a clear ide
a111: Logged on 2018-03-30 17:43 mircea_popescu: phf http://logs.bvulpes.com/trilema?d=2018-3-29#321679
phf: a as to what format the manifest supposed to be. i didn't realize that the idea is that vtools tree was supposed to be the first one to experiment with it
mimisbrunnr: Logged on 2018-03-29 14:53 mircea_popescu: is this deliberate or oversight phf ?
mircea_popescu: nah, the idea was you hatch a format and include it.
mircea_popescu: so go ahead an' regrind.
trinque: not like I'd have been opposed; it's just easy to imagine what it'd look like. every patch has an antecedent of the history file, as well as whichever other files.
phf: trinque: can you produce a sample then? i don't want to implement your idea, having only vague understanding of how it's supposed to look. there's been many discussions in the log as to what the actual manifest contents should include
trinque: http://p.bvulpes.com/pastes/9g8Sl/?raw=true << sure, I think it's just the expected flow up to the current patch
trinque: can compare to the actual flow you got out of the patches and wtf loudly if they mismatch
phf: hmm
trinque: maybe selectively because experimental patches might avoid touching the history file until they graduate
mircea_popescu: phf that's the whole fucking point, implement his idea, having only "vague" understanding of how it's ~supposed~ to look. then he can comment on it.
mircea_popescu: it's not supposed to look like anything, nor is it supposed. it flows from a necessity, what.
phf: i don't understand his idea
mircea_popescu: so then say that!
mircea_popescu: reason i even did things in this manner is because it's not clear to me why it was contentious or whether the contention was resolved.
mircea_popescu: phf do you see the problem spyked's patch to your v tree encountered ?
mimisbrunnr: Logged on 2018-03-29 15:00 spyked: the way I understood it from reading v.pl, the edges in teh graph are established based on changes introduced by each hunk in the nodes (the patches). so since there are no patches changing the files in vdiff_lib_xalloc_static_xnmalloc.vpatch, it's a leaf (and this, if I understand correctly, is intrinsic to the current design of v).
phf: mircea_popescu: i've seen that problem before, but i haven't tried solving it myself yet, because i've not ran into it. i've not had a chance to attempt spyke's problem/solution yet
mircea_popescu: nono. i don't mean the direct, i mean the meta.
mircea_popescu: his patch is a loose leaf, because it doesn't touch any of the files ?
phf: i'm not sure if his analysis of the problem is correct without looking at it myself first
mircea_popescu: let me state it canonically then, to guide the looking :
mircea_popescu: you, phf, made genesis G, with files a, b, c. you then made patch 1, which changes file a.
mircea_popescu: should he spyked make a patch 2, which changes file b, is that patch 2 off G or off patch 1 ?
phf: (there's another problem in my tree specifically, of double presses. you have to have two separate patches for both trees)
phf: well, presumably that's for the reader.
phf: i'm saying that i understand the meta problem, because i've seen other people deal with it, and there's been a lot of competing proposals as to how to solve it, including trb's "makefile" approach.
phf: but spyked might also be running into a lateral issue, that's related to double presses. in any case ~i~ need to look at it first before i have understanding of it.
mircea_popescu: yes well.
mircea_popescu: go right ahead.
mircea_popescu: but "it's for the reader" is a very weak answer, because if patch 3 touching a and b is written so as to include patch 2, whereas patch 3` touching a alone is written so as not to include patch 2, "the reader" will have a most terrible time deciding which to use and why the fuck his build don't work.
phf: "it's for the reader" meaning that you clarification is for the log reader
mircea_popescu: a a. yeah ok
mircea_popescu: so then you understand trinque's problem and trinque's idea ; or just the problem but not the idea or what was it ?
phf: i don't understand the solution. i've spent significant amount of time writing various graph walking algorithms to feel like without an set of experimental patches it's hard to have a solution that actual address the underlying complexity. what i wanted to see from trinque or whoever's attempting to solve this problem, is an actual attempt to construct a press tree with a manifest file that does what they want, to ensure that the approach actual solves
phf: the problem.
phf: this doesn't require a new codebase, trb is there, can be reground
mircea_popescu: well, the vdiff new tree was originally the most promising point for such a sample. i did say something in the vein of "i'm not going to keep trinque mothballed forever if you don't do it" recently, but anyways.
mircea_popescu: terrible idea to do it on trb. no, you want to do it on something small and simple, speciifcallty because "it's not hard to regrind existing tree"
phf: mircea_popescu: right, around the time when you made that mothballed comment did i get cued into the idea that you wanted me to implement it.
mircea_popescu: um. no, i said as much months ago, dja want me to dig the log ?
phf: yes please
phf bb
mircea_popescu: http://logs.bvulpes.com/trilema?d=2017-12-6#253896 << earliest discussion of actually making replacement vdiff ; http://logs.bvulpes.com/trilema?d=2017-12-14#259177 << where you got called a week later ; here's the moneyshot :
mimisbrunnr: Logged on 2017-12-06 22:38 mircea_popescu: if we start fucking with vdiff, this is the first mover.
mircea_popescu: Dec 14 14:00:23 <asciilifeform> yea but mircea_popescu demanded sane namespace behaviour
mircea_popescu: Dec 14 14:06:42 <mircea_popescu> i'm letting him contribute, what. he understands what the problems are.
mircea_popescu: Dec 14 14:07:00 <mircea_popescu> maybe he bites the bullet and makes special files. or who the hell knows. i'm curious.
mircea_popescu: now, from the evaluation late march, it seems to me i was correct in thinking back mid dec that you understood what the problems are, but that you didn't bother to implement any solution for one of them ? or what am i missing ?
mircea_popescu: in any case those three lines unpack directly into http://logs.bvulpes.com/trilema?d=2018-3-30#322704 ; for they curious as to how the mp brain works.
mimisbrunnr: Logged on 2018-03-30 18:36 mircea_popescu: reason i even did things in this manner is because it's not clear to me why it was contentious or whether the contention was resolved.
phf: mircea_popescu: the conversation from which you quote the money shot happens in the context of file renames, the part where you call upon me quotes keccak specifically, elsewhere you re-enumerate the list of what looks like target items, http://btcbase.org/log/2017-12-14#1751799
a111: Logged on 2017-12-14 22:49 mircea_popescu: phf so basically this is cropping down nicely after all. proper vpatch (fixing mod6 's bane, the empty dir thing) + proper vdiff (hash-based preprocessing of rename/move + proper use of @@...@@ + keccak hashing).
phf: i'm not even through the list of target items yet, any one of them can be picked up as an example of "didn't bother to implement any solution for"
mircea_popescu: phf i'm not saying you're the badman, or that it was necessarily plainly communicated. but, for what it's worth, that's what it was there.
mod6: <+mircea_popescu> "qntra : under the deluge of tit bits, website-exchanges btc price keeps falling" lmao << :D
mircea_popescu: the reason the list of firm targets doesn't include the soft "well, i'm curious what he does about X" is precisely because... how hard am i gonna push it ? that's kinda the constraint, on one hand death by vagueness & ambiguity, on the other death by insufferable overbearingness.
phf: i grok that point; the things are simply not there. i've barely arrived to where i have a working replacement for what we already have on top of which further work can be built. i guess the only reason this one is contentious is because it would've worked better if done upfront.
mircea_popescu: i have no issue with it, can be added now without any serious loss. the only thing not clear to me is whether you don't want to add it, can't add it yet or haven't gotten around to adding it yet.
mircea_popescu: and none of the three is the "wrong" answer ; just, they lead down different paths and gotta pick something to talk about.
mod6: fwiw, I think minus other targets, such as the empty dir thing, it's probably going to be easier to regresion test without changes for those targets -- basically having a 1:1 mapping of the old to new.
mod6: *regression
mircea_popescu: there is that.
mod6: then the new vpatches to clobber the targets can be patched in, one at a time. making test cases for each, simpler, and probalby more effective.
phf: that's the thinking
mod6: *thumbsup*
phf: the retrospectively unpleasant part of this approach is patching vdiff's C, which, after writing a bunch of Ada, is torture. i believe diana_coman had similar experience
phf: but i don't think i could've implemented ~patch equivalent~ differ in reasonable time. vpatch already ballooned out because of an unfamiliar development environment, and it's much less heuristic based.
mircea_popescu: exactly how she ended up chained to a tree in the swamp, also.
a111: Logged on 2018-03-30 20:47 phf: the retrospectively unpleasant part of this approach is patching vdiff's C, which, after writing a bunch of Ada, is torture. i believe diana_coman had similar experience
mod6: I made a test vpatch set for v related development. Super helpful. Allows me to create test scenarios and automate them, ensuring that I'm not regressing from version to version.
mod6: Can do this if needed, didn't take long.
mod6: Became necessary when testing for things like multiple roots, mulitple leaves; and have automation to break the tree into parts so I can ensure of other things, like no pressing of descendants if all antecedents are present in the current tree.
mod6: bah
mod6: files are in the second link above if curious
mod6: Think I mis-typed the above too: *like no pressing of descendants if all antecedents are ~NOT~ present in the current tree*
phf: mod6: would you mind uploading that test tree somewhere? i want to throw it at btcbase. fwiw, vpatch/vdiff doesn't care about press tree, as long as the hashes work out in the end
mod6: http://www.mod6.net/sps2/ << here's the vpatches
mod6: I do have seals for these signed with my vpatch-testing key... but you can just sign them with your junk key if you wanna play around
mod6: (unless you really want my seals)
phf: though a manifest could be used as a kind of assert during press, as long as it doesn't rely on filenames. (i believe the idea of putting antecedent vpatch's hashes into manifest floated around)
mod6: i've been thinking about the manifest thing for a while... and I'm not sure about it... seems like it'd get hairy. and would require versioning in and of itself. however, if we had a sample to look at, might be easier for me to grok.
mod6: was thinking, that if we changed up the parameterization of v, could maybe resolve the multiple leaves thing. imagine http://www.mod6.net/sps2_dag.png without the 'j.vpathch', if one wanted to press both trees, maybe could tell v to : `./v.pl p v outputdir i.vpatch d.vpatch`
mod6: then would press both trees
mod6: and if not, then user just selects one leaf, as is today. i dunno, would need some thought. i may be missing the mark here too.
trinque: would have to name every patch that happened to end up a dangling leaf
mod6: you're saying if there are 69 leaves, and you want them all, then you have to list them all?
mod6: what if ole mod6 put in a special flag for that "gimme-all-leaves" instead of the listing of all?
mod6: i.e. : `./v.pl p v outputdir gimme-all-leaves`
phf: originally this was \supposed to be solved by curated wot, i.e. all in-wot-dangling leaves that can be applied to current press, by hash, would get pressed
trinque: hm. I'd have to ponder a while to see what's lost. it's unclear what the purpose of designating a press head would be in that scenario
trinque: the designated head matters along the walk of one path, but then you get all of adjacent ones?
phf: trinque: that was the behavior of v all along!
trinque: phf: it isn't.
mod6: it used to be in my V 99994 i would just blindly press all of the leaves, but that's was rejected as not the right thing. but with the good changes that 99993 brings in, could let the user choose at press time. just food for thought.
trinque: phf: can you elaborate a bit?
asciilifeform: in was in asciilifeform's original draft v. purely by way of bugginess.
phf: ^
trinque: lolk then
asciilifeform: and possibly also in an early mod6 vtron.
asciilifeform: but quite definitely The Wrong Thing
mod6: aha, and was changed.
phf: yeah, you guys "bugginess", this is the fundamental property of how v was described and how it was implemented
asciilifeform: phf fixed it immediately when he wrote his patchviewer vtron.
trinque: phf: where are you at on the practical problem of "trinque wants to redo portage in V" and I don't want people giving me patches that include unrelated ebuilds?
asciilifeform: phf: nothing fundamental or desirable or ever for that matter explicitly proclaimed, about pressing adjacent (sibling) patches that happen to get alphabet-sorted upward of $presshead
trinque will go ahead and try to delineate clearly
trinque: with present V behavior, some file has to always be present as an antecedent for any coherent line of history (there could be many)
trinque: if returning to "press everything, don't specify HEAD" I don't see that there can be multiple lines of history (branches)
trinque: are there others?
phf: trinque: there's no "returning to", original behavior is "press everything that falls from under this head"
trinque: why are you refusing to acknowledge this problem?
phf sighs
phf: trinque: didn't you accuse me of projecting before, ~where did i refuse to acknowledge this problem~
asciilifeform: http://btcbase.org/log/2018-03-30#1791427 << i proposed this at one point, and mircea_popescu (imho correctly) barfed, and one of the reasons was that it makes pressing irreversible (or at least reverse-walking becomes np-hard)
a111: Logged on 2018-03-30 22:09 mod6: was thinking, that if we changed up the parameterization of v, could maybe resolve the multiple leaves thing. imagine http://www.mod6.net/sps2_dag.png without the 'j.vpathch', if one wanted to press both trees, maybe could tell v to : `./v.pl p v outputdir i.vpatch d.vpatch`
trinque: then perhaps I'm wrong. I'm trying to present a problem to you by way of examples and it's not taking.
mod6: asciilifeform: ah, i figured we had probably been here before. cheers.
asciilifeform eats log, puzzles over $problem
trinque: phf: there are cases where two separate edits to separate files are both needed as antecedents to yet a 3rd patch, which edits possibly neither of them.
phf: trinque: i'm describing how things are right now, how things were, and what informs my and mod6 opinions on the subject. uncertainty about past behaviors in my opinion tends to influence uncertainty about future solutions
asciilifeform: i was somehow quite certain that trinque had a pseudocode-algo for his improved vtron
mod6: oh, and it just dawned on me how it would be np-hard to walk it backwards.
mod6: derp
mod6: too many paths
phf: mod6: there's that too :)
trinque: so what of that situation?
trinque: aside the two above, what's been done in trb is to include 1 and 2 in patch 3; the bulk of the patch is lifted into the thing
trinque: now 4 comes along and it edits nothing in 3
trinque: so 4 accretes 3
trinque: this can continue boundlessly
phf: like i said, i understand the problem, i'm not sure of the solution, because ~i~ have not attempted to tackle it. for example i suspect that the manifest might be problem specific, i.e. what you put there is informed by the shape of the tree you're trying to create.
trinque: I don't have a pet proposal to solve it, but it's definitely never getting solved without more eyes on that the problem exists
trinque: k, I understand.
asciilifeform: iirc mircea_popescu proposed once an algo where , for a patch to count as a Troo Patch, it must modify a chronicle.txt (along these lines)
mircea_popescu: was trinque's proposal, i just formalized it.
mod6: ok, so that would solve some of the 'hairyness'. a True Vpatch ~MUST~ edit chronicle.txt.
mircea_popescu: the trinque original (which im too lazy to dig out atm) was "concatenate your whole codebase, hash it, add the resut on a new line of manifest.txt" pretty much.
asciilifeform: original v left chronicling as a per-project convention, to the pleasure of the project operator, rather than part of vtron
mircea_popescu: i expanded on that to allow comments in the manifest, in the spirit of literate (
trinque: asciilifeform: sure, and it's nice that this ends up there in plaintext to be read, rather than blobs in a git black box
phf: ultimately it doesn't matter what's inside manifest, as long as its hash is unique, e.g. it's append only log that requires >1 byte of change in each vpatch
asciilifeform: ah yes iirc trinque proposed to remove the illusion created by classical gnupatch , that of file-independence
asciilifeform: 'hash everything' is tricky tho : do you also hash the manifest ?? (presumably up to the exact point where new hash gets inserted ?? )
mod6: more generally: is a manifest part of a code-base
mod6: ?
asciilifeform: i will also add, classic vpatches were verifiable with simple gnu tools 'by hand', and even creatable 'by hand' similarly. complex hash mechanism, not so much, and imho this is a downer
mircea_popescu: asciilifeform note that this hash is not opposable to anything. you can hash the system time for all the difference it makes.
phf: i suspect something like ebuild situation requires a non-trivial vpatch management: each port is its own genesis tree and portage system keeps track of head's. this way extending port's tree allows ongoing development, but trinque's role is to update portage's pointers periodically. this way a press from head must ignore lateral leaves, etc.
mircea_popescu: just grows the file.
trinque: yeah, the hash idea was bunk.
mircea_popescu: trinque seems the logical place this is going is "make comments file addition mandatory for each patch"
mircea_popescu: ie, "your patch must do two things to count : build off a valid tree state ; and explain itself in plaintext in the comments file for the project"
mircea_popescu: mod6 yes, absolutely.
trinque: http://p.bvulpes.com/pastes/8d93M/?raw=true << here's another HISTORY file, incomplete, that I've been putting together.
trinque: using it as an exercise to sign all the patches I haven't, too.
phf: if we're trying to nail down antecedents, why not put parent hash into vpatch prelude. i.e. "this vpatch can only happen after a vpatch with the given hash has been applied"
phf: e.g. the patch itself starts with mandatory parent: <hash>/false. this though completely eliminates the complicated graph transition machinery. all patches are hashed blobs, that you can point to by its hash
phf: hmm, manifest's hash though solves the same problem, we're essentially driving the graph by manifest hash chain, and the other files in patch are for additional culling
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-30#322858 << only in the sense of "original v promised the letter a will only be used 8805 times in code, because that;s how many times it happened to use it and i choose to take this strange view"
mimisbrunnr: Logged on 2018-03-30 22:13 phf: trinque: there's no "returning to", original behavior is "press everything that falls from under this head"
mircea_popescu: but in the general approach to the problem, 1. all specification will sort items into "always" "sometimes : as per conditions" "never" and categories ; and 2. all refinement of specification will move items, but ONLY from the left to the right and not the other way around.
mircea_popescu: so, the fact that an always is becoming a sometimes isn't a point of concern in the hard sense of http://logs.bvulpes.com/trilema?d=2018-3-30#322868 (which is otherwise broadly correct)
mimisbrunnr: Logged on 2018-03-30 22:15 phf: trinque: i'm describing how things are right now, how things were, and what informs my and mod6 opinions on the subject. uncertainty about past behaviors in my opinion tends to influence uncertainty about future solutions
mircea_popescu: anyway, the seemingly correct solution is for convention to be changed, so that 1. genesis author creates a comments.txt file or else it's not a proper genesis ; 2. all subsequent patches MUST include an edit to the comments.txt file of the codebase they are pressed upon, which 3. must consist of adding one line at the end consisting of whatever text the patch author deems useful to add and may not be null and 4. should ideal
mircea_popescu: ly not modify previous lines, but this is to be enforced by public arbiter, ie, sometimes it will make sense to.
mircea_popescu: with this mechanism no actual changes to v need to be made, it's a "soft fork" as it were.
phf: mircea_popescu: i don't agree that the "in the sense" is correct. trb patchset relied on pressing the lateral trees behavior up until recent nailing down of graph, which was a result of elaboration from clearer understanding. i think the understanding of v has evolved, and things of which there was much uncertainty and hand waving in the past are now much more obvious. i don't think it's the case that "the behavior was always that way" in an accidental
phf: sense.
mircea_popescu: phf how do you propose we could decide this ?
mircea_popescu: there's no dispute that understanding of v has evolved ; but i don't happen to see the uncertainity.
phf: well, cutting "makefiles" from trb and going up the graph demonstrates many places where full press wouldn't happen with current behavior, but will still happen with the "buggy" one. so either there was a shared understanding that has changed, or else people who claim that that was shared understanding haven't looked at the trb tree at the time to observe the buggy behavior themselves.
mircea_popescu: or possibly everyone regarded trb as a messy pile which isn't properly v-ified even today. like mpi, or like gentoo
mircea_popescu: in fact, the only legacy pantsuit item almost-v-ified would be wp, and that's STILL not done in spite of being two degrees of magnitude simpler, because of all sorts of "holy shit, svg"
mircea_popescu: otherwise, all v versions of anything were in fact rewrites.
mircea_popescu: for that matter, pre-solution to binary issue, even fg tree was sad.
mircea_popescu: can you turn around and say, "fg tree shows people didn't at the time understand v isn't married to the underlying format" or something ?
mircea_popescu: rather, there's a shared understanding that's applied by degrees. because the sty is so dirty you have to peel layers off, as the only possible approach.
asciilifeform: phf: can you give a concrete press head for current-trb that will barf if the lateral-walk is removed ?
asciilifeform: because i know of none
mircea_popescu: asciilifeform hewants to remove makefiles first.
phf: asciilifeform: i didn't say barf, but if you were to remove, say, makefiles, press to malleus_mikehearnificarum, you lose mod6_der_high_low_s
phf: asciilifeform: come to think of it, initially you were talking about using own wot to cull things, which makes no sense if you only have one tree.
asciilifeform: when i was actively trbing, i handled 'want p1 + p2 + ... p_n ' by hand-copy and producing p_n+1
asciilifeform: phf: correct
asciilifeform: phf: which is why i wrote the classical vtron the way i did -- wanted max flexibility of form. and yes this has cost.
asciilifeform: can make it narrower. but then you lose the multiverse aspect, aha.
asciilifeform: 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
mircea_popescu: the original "many keys" solution to that proved untenable.
asciilifeform: not sure that anybody got around to trying it
mircea_popescu: this imo is loud proof.
asciilifeform: just cuz the lorica is too heavy does not prove 'armour is Wrong Thing' , lol
mircea_popescu: it does, yes. the old french word for it is agincourt.
asciilifeform: by same logic 'v is a bother and let's all shithub', conceivably, neh ?
phf: asciilifeform: it very briefly worked with polarbeard's patches, but that was around active reground time, so the result wasn't particularly interesting. but you could press to experimental head with or without pb's additions, based on whether or not he was in your wot
asciilifeform: phf: in this sense -- correct, it was never automagically 'omit 1 d00d's key and still get otherwise wholly-valid set of same presses as before'
phf: problem that you run into is really granularity of files (of which we also had thread), and that perhaps having multi-file multi-anticedent vpatches is not the correct thing in genera
phf: l
phf: which we also had thread about
asciilifeform: problem is that most meaningful transforms are ~not~ attainable automatically, and the otherwise spiffy vtronics create unwarranted expectation of automatism
asciilifeform: heathens do not have this headache in their pigstys
phf: right, hence the conversations about sexp v
asciilifeform: (because they have properly low expectations)
mircea_popescu: this is actually very much the problem, huh.
phf: with manifest we're basically saying "there's going to be one file, which is going to establish the one true chain, and all these other files are just hanging by the side"
phf: problem can also be solved with having entire project in one file, or trinque's approach os tracking hash chains for the entire directory (i.e. treating the whole press as a single file)
phf: *of tracking
mircea_popescu: except first is practical nonsense, and second presumes thingd about directories, which is untenable.
mod6: one file, != fits in head
mod6: vpatches were meant to be digestable.
asciilifeform ftr biased in favour of pills that leave the orig vtron simple ( while potentially introducing a separate tool for testing conformance to chronology )
mircea_popescu: asciilifeform conformance is not mechanically tested.
asciilifeform: i did not say wholly automatic . simply 'tool' .
asciilifeform: could reduce even to naked eye.
phf: mod6: wait, what? from the way vpatch looks perspective there's literally no difference. you have one diff a/x b/x instead of many, but otherwise the thing looks identical.
asciilifeform: the way classical v can be , in times of need , reduced to naked eye.
asciilifeform: phf: how would this look , so that mass of patches stays similar to classical ?
mircea_popescu: phf i don't get it, why would we adapt the way we do things to what'd be convenient for the machines ?
mod6: <+phf> problem can also be solved with having entire project in one file, << to me, was trying to picture trb one giant vpatch, over and over, may have misunderstood
phf: no no
phf: yo, it's not a real solution, the only reason i was thinking about is because that's how knuth's literate programming is done. i mean the entirety of code is one file, you use project specific tooling to extract it.
mircea_popescu: yeah but i suspect that's a large part of why it went nowhere.
mod6: OH. i see what you're saying. so in stead of a & b per file, you're saying a & b for ~entire~ vpatch
asciilifeform: phf: i actually tried this, into a drawer, but gave up -- ugly and inbandistic
mod6: or am i still missing this?
phf: i.e. trb.vpatch -> trb.web -> foo.c, bar.c, qux.c
asciilifeform: ( observe, we are -- for foreseeable future -- stuck in unix world, where files exist, and at the very least Makefile, .ads, .adb, etc are forced to occupy separate ones )
phf: this is so trivial, and also inconsequential that i apologize for burning s/r on it
phf: mod6: think plaintext tar archive that you stick inside a vpatch. there's only ever ~one file~ in your tree. for simplicity it's one large trb.cpp that compiles to the result. no other dependencies.
asciilifeform: iirc i suggested this explicitly at one point, http://btcbase.org/log/2017-12-14#1751755
a111: Logged on 2017-12-14 21:34 asciilifeform: whereas if you want to be able to compactly represent ~arbitrary transforms of text and of dirs, you end up with something like sed on top of a... text representation of a tar ?
mod6: phf: oh
asciilifeform: but result was 'ugly inbandism', though it may be possible to do it without magic-symbols
mod6: it would also get nasty each time you remove or add a file in here.
mod6: anyway, ok moving on..
asciilifeform: mod6: not really, no. it becomes just another text transform. ditto renames and redirs.
mod6: alright, i'll have to take your word for it ; im imagining some huge diffs.
mod6: Eitherway, I've become to like how we have it now.
mod6: Maybe I'm a bit biased. heheh. there are still problems to tackle tho - and it's difficult to do so without adding further complexity.
asciilifeform: if the 'must artifically touch files to maintain clean-looking flow tree' is to be considered a problem ( and i do see this pov ) then 'only 1 file ever gets diffed, and it contains metacommands to create actually separate unix files out of its sections' is in fact 1 possible solution. and creates the 'every hash stands for whole project's state' thing.
mircea_popescu: phf see, it never stops. it's not something one can turn off at will, sadly.\
phf: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a regrind.
phf bb
mod6: cool, an example of this that we can use to examine would be hugely helpful.
mircea_popescu: ah check it out, trilema has the header with the head errant today.
hanbot: i think that's a head rampant.
mircea_popescu: rompant lol
asciilifeform: oook so asciilifeform dug out his old experiment, in case anyone can win from it :
asciilifeform: ^ and yes i classically-v-genesised it, given as there is not yet a new-v
asciilifeform: and yes there is a typo in readme, 't.xtal' should be 'test.xtal' .
asciilifeform: everything else is self-explanatory.
asciilifeform: mircea_popescu, phf , mod6 , trinque , et al ^^
asciilifeform: to see how this applies to $thread, take this , and then try gnudiffing the 'crystals' , then rename files, or move'em between dirs, and diff the resulting 'crystals' again, observe how only the 1 line that defined that 1 file's path, ends up changing
mod6: hey neat, i'll give this a closer look here tonight.
asciilifeform: don't burn too much time on this item, mod6 , it is strictly for vtronology.
mod6: thanks for the post asciilifeform
asciilifeform: all it does is the 'human readable tarball' trick.
asciilifeform: both to- and from- directions.
asciilifeform: quite possibly only trinque will find this tool interesting : it implements , i think, his favoured variant .
asciilifeform: ( or rather, just the whole-program representation therein -- it is not a vtron )
asciilifeform: anyways i've cluttered the l0gz enuff, that's all there is to this item currently.
asciilifeform: 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 .
asciilifeform back to wurk, bbl
asciilifeform: btw, ftr : ffa comes back from sabbatical next wk !
mod6: hey hey hey, lbj
← 2018-03-29 | 2018-03-31 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code