Forum logs for 30 Mar 2018

Monday, 16 March, Year 12 d.Tr. | Author:
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. [00:07]
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. [00:08]
mircea_popescu: it is now in the freezer. i'm having the third serving. best 300 calorie spoonfulls i ever had. [00:08]
mircea_popescu: in case this is the last you hear of me -- know i've had a good life. [00:08]
mod6: :] [00:11]
mod6: sounds awesome [00:11]
mircea_popescu: douchebag btw, what happened to the drawer guy ? [00:18]
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 [00:35]
a111: Logged on 2018-03-30 01:29 mod6: ave1: http://p.bvulpes.com/pastes/FQrCw/?raw=true [00:35]
douchebag: he hasn't gotten back to me :/ [00:38]
mircea_popescu: ah. k. [00:38]
mircea_popescu: i dunno wtf is it with sketchers, but they're the sketchiest bunch by far. [00:38]
douchebag: They always bitch about not having money [00:40]
douchebag: and then when you offer them work they're too lazy to do the work [00:40]
douchebag: Basically they think they're artists because they smoke pot and draw shit [00:41]
mircea_popescu: must be. [00:47]
mod6: ave1: http://p.bvulpes.com/pastes/vVcs9/?raw=true [00:51]
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). [01:00]
ave1: btw I tried adding -flto/-fno-lto flags and optimization flags, but these did nothing for me. [01:03]
mod6: Thanks ave1 [01:13]
douchebag: mircea_popescu: I have a girl but she is wondering if she's allowed to wear sunglasses [01:21]
mircea_popescu: she isn't. [01:21]
douchebag: Alright, told her that's a no - let's see how this goes [01:21]
douchebag: mpex.biz is not loading ? [02:07]
mircea_popescu: a did it crap out ? [02:11]
mod6: down here too [02:12]
* mircea_popescu puts on list for tomorrow. [02:12]
douchebag: I was wondering, how much would I earn from writing qntra articles? [02:22]
douchebag: mircea_popescu: A woman is interested in the tits offer, but she's morbidly obese [02:24]
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 [02:24]
douchebag: ben_vulpes: How much are qntra shares worth at the moment? [02:24]
ben_vulpes: douchebag: do you know where it's traded? [02:26]
ben_vulpes: man i don't know anything about port but this is delicious [02:28]
douchebag: I assumed mpex.biz but since that's down at the moment I wasn't able to verify [02:28]
ben_vulpes: it's like two links deep off the homepage [02:29]
ben_vulpes: http://qntra.net/2014/10/write-for-qntra-earn-equity-in-qntra/ [02:29]
douchebag: Anyway though, she wants to know if she'll still get paid even though shes a porker [02:33]
ben_vulpes: why not let the girl speak for herself [02:33]
douchebag: Sure [02:33]
ben_vulpes: btw douchebag are you following the shared hosting php saga in #pizarro? [02:34]
douchebag: No I'm not in there, can you give me a brief overview of what's going down? [02:42]
douchebag: dagofbicks is here to show tits btw [03:10]
ben_vulpes: douchebag: no, read the logs it's not that dense [03:13]
ben_vulpes: also http://logs.bvulpes.com/trilema?d=2018-3-23#317921 [03:13]
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. [03:13]
ben_vulpes: douchebag: http://logs.bvulpes.com/pizarro [03:13]
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) [09:12]
ave1: an exclude -> and exclude [09:13]
diana_coman: ave1, do you mean basically http://www.dianacoman.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-307.1-307.690 ? [10:37]
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 [10:44]
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." [11:06]
mircea_popescu: see what the whip does ? it makes gods of people! [11:06]
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. [11:08]
ave1: and another typo (i'm sorry) -> diana_coman [11:12]
diana_coman: ave1, writing an alternative sounds great to me (and no worries re typo auto-complete is convenient though) [11:13]
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-30#322461 << you get one share per word at the end of the month. [11:14]
mimisbrunnr: Logged on 2018-03-30 06:14 douchebag: I was wondering, how much would I earn from writing qntra articles? [11:14]
mircea_popescu: look for the editor in chief reports, they detail it. [11:14]
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. [11:14]
mimisbrunnr: Logged on 2018-03-30 06:18 ben_vulpes: douchebag: do you know where it's traded? [11:14]
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-30#322475 << yes. [11:15]
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 [11:15]
douchebag: alright, she's offline at the moment. I'll let her know whenever she decides to get on [11:25]
mircea_popescu: no biggy. [11:26]
mircea_popescu: don't stress out, the show's here all day. [11:26]
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 [13:36]
deedbot: http://trilema.com/2018/the-naked-city/ << Trilema - The Naked City [13:36]
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. [13:38]
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). [13:38]
mircea_popescu: phf http://logs.bvulpes.com/trilema?d=2018-3-29#321679 [13:43]
mimisbrunnr: Logged on 2018-03-29 14:53 mircea_popescu: is this deliberate or oversight phf ? [13:43]
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. [13:49]
a111: Logged on 2018-03-30 03:53 asciilifeform: douchebag: can you shed light on popularity of 'discord' item ? [13:49]
douchebag: eh discord is used by a lot of autistic people [13:50]
douchebag: gremlin is here to show tits bt [13:50]
douchebag: w [13:50]
douchebag: oh [13:51]
phf: mp picked up on your use of "autistic", which i didn't grok myself http://btcbase.org/log/2018-03-29#1791068 [13:51]
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" [13:51]
douchebag: No, just a strange group of people [13:51]
douchebag: oh shes back as grimm I guess [13:52]
ben_vulpes: !!up grimm [13:52]
deedbot: grimm voiced for 30 minutes. [13:52]
grimm: im here to show tits [13:52]
grimm: !!register http://p.bvulpes.com/pastes/iGDB6/?raw=true [13:53]
deedbot: E650469615F2EC9815C4589C8D806BAE3615D0E7 registered as grimm. [13:53]
mircea_popescu: grimm did you ever do it before ? [13:56]
grimm: nop [13:56]
mircea_popescu: mk do a good job, will you. 5efeec1f [13:56]
grimm: ye sure will sec [13:57]
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/ " [13:59]
grimm: https://i.imgur.com/5dDoHn2.jpg [14:01]
mircea_popescu: cheers. [14:01]
mircea_popescu: !!pay grimm 0.02 [14:01]
deedbot: Get your OTP: http://p.bvulpes.com/pastes/hHoCD/?raw=true [14:01]
douchebag: grimm: it takes a moment [14:03]
grimm: !!balance [14:07]
deedbot: http://p.bvulpes.com/pastes/FXQSM/?raw=true [14:07]
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) [14:09]
asciilifeform: what are the last 2 characters in the magicstring in that titpic ? [14:09]
mircea_popescu: asciilifeform looks like tittycode for 1 and f [14:10]
grimm: i just wrote what was given [14:11]
grimm: !!balance [14:11]
mircea_popescu: grimm you wrote the 1 backwards which is funny [14:11]
deedbot: http://p.bvulpes.com/pastes/xNd75/?raw=true [14:11]
grimm: lol sorry [14:13]
grimm: !!withdraw 0.02 3FabNPwSNoaQEAfk9qCmb6Sj9BtJ7g8uGV [14:13]
deedbot: Get your OTP: http://p.bvulpes.com/pastes/9rPCy/?raw=true [14:13]
grimm: numbers from upside down are hard [14:14]
mircea_popescu: we've been discovering\ [14:14]
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 [14:15]
grimm: !!v CF01914134E1A5C9419231F3CDA505B749906689AA6E0ABF88EF5EBE3D838393 [14:15]
deedbot: http://p.bvulpes.com/pastes/FlTEF/?raw=true [14:16]
mircea_popescu: lmao [14:17]
grimm: thank you ill tell all my friends ahahaha [14:17]
mircea_popescu: grimm please do. [14:17]
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 [14:18]
trinque: BingoBoingo with the unmatched comedic timing [14:18]
mircea_popescu: "qntra : under the deluge of tit bits, website-exchanges btc price keeps falling" lmao [14:18]
mircea_popescu: trinque i k r!!1 [14:18]
mircea_popescu: i wonder which one of these identitties will pop up later doing anything worth the mention. [14:19]
asciilifeform: any from prev years popped up so far ? [14:20]
mircea_popescu: what's in a year. people who "become president" on stanford's list usually take 3-5 decades. [14:20]
* asciilifeform will be surprised, impressed, if it ever becomes known that one of these folx kept the 0.02 for decades [14:23]
mircea_popescu: tis a distinct possibilitit. [14:23]
asciilifeform: ( the more frequent ending seems to be the one pictured in http://trilema.com/2013/and-then-i-said-to-him-jimmy ) [14:24]
mircea_popescu: yawell [14:24]
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 [14:30]
a111: Logged on 2018-03-30 17:43 mircea_popescu: phf http://logs.bvulpes.com/trilema?d=2018-3-29#321679 [14:30]
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 [14:30]
mimisbrunnr: Logged on 2018-03-29 14:53 mircea_popescu: is this deliberate or oversight phf ? [14:30]
mircea_popescu: nah, the idea was you hatch a format and include it. [14:30]
mircea_popescu: so go ahead an' regrind. [14:31]
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. [14:32]
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 [14:37]
trinque: http://p.bvulpes.com/pastes/9g8Sl/?raw=true << sure, I think it's just the expected flow up to the current patch [14:41]
trinque: can compare to the actual flow you got out of the patches and wtf loudly if they mismatch [14:42]
phf: hmm [14:42]
trinque: maybe selectively because experimental patches might avoid touching the history file until they graduate [14:43]
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. [14:43]
mircea_popescu: it's not supposed to look like anything, nor is it supposed. it flows from a necessity, what. [14:44]
phf: i don't understand his idea [14:44]
mircea_popescu: so then say that! [14:44]
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. [14:45]
mircea_popescu: phf do you see the problem spyked's patch to your v tree encountered ? [14:45]
mircea_popescu: http://logs.bvulpes.com/trilema?d=2018-3-29#321684 << specifically. [14:46]
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). [14:46]
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 [14:48]
mircea_popescu: nono. i don't mean the direct, i mean the meta. [14:48]
mircea_popescu: his patch is a loose leaf, because it doesn't touch any of the files ? [14:48]
phf: i'm not sure if his analysis of the problem is correct without looking at it myself first [14:49]
mircea_popescu: let me state it canonically then, to guide the looking : [14:49]
mircea_popescu: you, phf, made genesis G, with files a, b, c. you then made patch 1, which changes file a. [14:50]
mircea_popescu: should he spyked make a patch 2, which changes file b, is that patch 2 off G or off patch 1 ? [14:50]
phf: (there's another problem in my tree specifically, of double presses. you have to have two separate patches for both trees) [14:50]
phf: well, presumably that's for the reader. [14:52]
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. [14:52]
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. [14:53]
mircea_popescu: yes well. [14:53]
mircea_popescu: go right ahead. [14:53]
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. [14:55]
phf: "it's for the reader" meaning that you clarification is for the log reader [14:55]
mircea_popescu: a a. yeah ok [14:55]
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 ? [14:56]
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 [14:58]
phf: the problem. [14:58]
phf: this doesn't require a new codebase, trb is there, can be reground [14:59]
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. [14:59]
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" [15:00]
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. [15:03]
mircea_popescu: um. no, i said as much months ago, dja want me to dig the log ? [15:03]
phf: yes please [15:04]
* phf bb [15:14]
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 : [15:19]
mimisbrunnr: Logged on 2017-12-06 22:38 mircea_popescu: if we start fucking with vdiff, this is the first mover. [15:19]
mircea_popescu: Dec 14 14:00:23 <asciilifeform> yea but mircea_popescu demanded sane namespace behaviour [15:19]
mircea_popescu: Dec 14 14:06:42 <mircea_popescu> i'm letting him contribute, what. he understands what the problems are. [15:19]
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. [15:19]
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 ? [15:20]
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. [15:22]
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. [15:22]
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 [16:31]
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). [16:31]
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" [16:33]
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. [16:34]
mod6: <+mircea_popescu> "qntra : under the deluge of tit bits, website-exchanges btc price keeps falling" lmao << :D [16:38]
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. [16:39]
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. [16:42]
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. [16:43]
mircea_popescu: and none of the three is the "wrong" answer just, they lead down different paths and gotta pick something to talk about. [16:44]
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. [16:45]
mod6: *regression [16:45]
mircea_popescu: there is that. [16:45]
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. [16:46]
phf: that's the thinking [16:46]
mod6: *thumbsup* [16:46]
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 [16:47]
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. [16:48]
mircea_popescu: myeah. [16:48]
mircea_popescu: exactly how she ended up chained to a tree in the swamp, also. [16:49]
diana_coman: http://btcbase.org/log/2018-03-30#1791407 --> precisely, yes. [17:13]
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 [17:13]
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. [17:31]
mod6: Can do this if needed, didn't take long. [17:32]
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. [17:33]
mod6: http://www.mod6.net/sps_dag.png http://www.mod6.net/sps2/ [17:38]
mod6: bah [17:38]
mod6: here's the graph: http://www.mod6.net/sps2_dag.png [17:38]
mod6: files are in the second link above if curious [17:39]
mod6: Think I mis-typed the above too: *like no pressing of descendants if all antecedents are ~NOT~ present in the current tree* [17:47]
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 [18:03]
mod6: http://www.mod6.net/sps2/ << here's the vpatches [18:04]
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 [18:04]
mod6: (unless you really want my seals) [18:04]
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) [18:05]
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. [18:06]
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` [18:09]
mod6: then would press both trees [18:09]
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. [18:10]
trinque: would have to name every patch that happened to end up a dangling leaf [18:10]
mod6: you're saying if there are 69 leaves, and you want them all, then you have to list them all? [18:11]
mod6: what if ole mod6 put in a special flag for that "gimme-all-leaves" instead of the listing of all? [18:11]
mod6: i.e. : `./v.pl p v outputdir gimme-all-leaves` [18:13]
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 [18:13]
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 [18:14]
trinque: the designated head matters along the walk of one path, but then you get all of adjacent ones? [18:15]
phf: trinque: that was the behavior of v all along! [18:15]
mod6: in the case of: http://p.bvulpes.com/pastes/DcUdz/?raw=true [18:15]
trinque: phf: it isn't. [18:15]
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. [18:16]
trinque: phf: can you elaborate a bit? [18:16]
asciilifeform: in was in asciilifeform's original draft v. purely by way of bugginess. [18:16]
phf: ^ [18:17]
trinque: lolk then [18:17]
asciilifeform: and possibly also in an early mod6 vtron. [18:17]
asciilifeform: but quite definitely The Wrong Thing [18:17]
mod6: aha, and was changed. [18:17]
phf: yeah, you guys "bugginess", this is the fundamental property of how v was described and how it was implemented [18:17]
asciilifeform: phf fixed it immediately when he wrote his patchviewer vtron. [18:17]
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? [18:18]
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 [18:18]
* trinque will go ahead and try to delineate clearly [18:20]
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) [18:20]
trinque: if returning to "press everything, don't specify HEAD" I don't see that there can be multiple lines of history (branches) [18:20]
trinque: are there others? [18:20]
phf: trinque: there's no "returning to", original behavior is "press everything that falls from under this head" [18:21]
trinque: why are you refusing to acknowledge this problem? [18:21]
* phf sighs [18:21]
phf: trinque: didn't you accuse me of projecting before, ~where did i refuse to acknowledge this problem~ [18:22]
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) [18:22]
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` [18:22]
trinque: then perhaps I'm wrong. I'm trying to present a problem to you by way of examples and it's not taking. [18:22]
mod6: asciilifeform: ah, i figured we had probably been here before. cheers. [18:23]
* asciilifeform eats log, puzzles over $problem [18:23]
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. [18:23]
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 [18:23]
asciilifeform: i was somehow quite certain that trinque had a pseudocode-algo for his improved vtron [18:23]
mod6: oh, and it just dawned on me how it would be np-hard to walk it backwards. [18:23]
mod6: derp [18:23]
mod6: too many paths [18:24]
phf: mod6: there's that too :) [18:24]
trinque: so what of that situation? [18:24]
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 [18:25]
trinque: now 4 comes along and it edits nothing in 3 [18:25]
trinque: so 4 accretes 3 [18:25]
trinque: this can continue boundlessly [18:25]
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. [18:26]
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 [18:26]
trinque: k, I understand. [18:26]
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) [18:26]
mircea_popescu: was trinque's proposal, i just formalized it. [18:27]
asciilifeform: aa [18:27]
mod6: ok, so that would solve some of the 'hairyness'. a True Vpatch ~MUST~ edit chronicle.txt. [18:28]
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. [18:29]
asciilifeform: original v left chronicling as a per-project convention, to the pleasure of the project operator, rather than part of vtron [18:29]
mircea_popescu: i expanded on that to allow comments in the manifest, in the spirit of literate ( [18:29]
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 [18:30]
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 [18:30]
asciilifeform: ah yes iirc trinque proposed to remove the illusion created by classical gnupatch , that of file-independence [18:30]
asciilifeform: 'hash everything' is tricky tho : do you also hash the manifest ?? (presumably up to the exact point where new hash gets inserted ?? ) [18:31]
mod6: more generally: is a manifest part of a code-base [18:32]
mod6: ? [18:32]
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 [18:33]
mircea_popescu: asciilifeform note that this hash is not opposable to anything. you can hash the system time for all the difference it makes. [18:36]
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. [18:36]
mircea_popescu: just grows the file. [18:36]
trinque: yeah, the hash idea was bunk. [18:36]
mircea_popescu: trinque seems the logical place this is going is "make comments file addition mandatory for each patch" [18:37]
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" [18:38]
mircea_popescu: mod6 yes, absolutely. [18:38]
trinque: http://p.bvulpes.com/pastes/8d93M/?raw=true << here's another HISTORY file, incomplete, that I've been putting together. [18:42]
trinque: using it as an exercise to sign all the patches I haven't, too. [18:42]
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" [18:43]
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 [18:47]
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 [18:51]
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 thats how many times it happened to use it and i choose to take this strange view" [18:51]
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" [18:51]
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. [18:54]
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) [18:54]
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 [18:54]
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 [19:04]
mircea_popescu: ly not modify previous lines, but this is to be enforced by public arbiter, ie, sometimes it will make sense to. [19:04]
mircea_popescu: with this mechanism no actual changes to v need to be made, it's a "soft fork" as it were. [19:04]
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 [19:05]
phf: sense. [19:05]
mircea_popescu: phf how do you propose we could decide this ? [19:05]
mircea_popescu: there's no dispute that understanding of v has evolved but i don't happen to see the uncertainity. [19:06]
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. [19:10]
mircea_popescu: or possibly everyone regarded trb as a messy pile which isn't properly v-ified even today. like mpi, or like gentoo [19:11]
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" [19:12]
mircea_popescu: otherwise, all v versions of anything were in fact rewrites. [19:12]
mircea_popescu: for that matter, pre-solution to binary issue, even fg tree was sad. [19:13]
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 ? [19:13]
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. [19:16]
asciilifeform: phf: can you give a concrete press head for current-trb that will barf if the lateral-walk is removed ? [19:18]
asciilifeform: because i know of none [19:18]
mircea_popescu: asciilifeform hewants to remove makefiles first. [19:18]
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 [19:19]
asciilifeform: aa [19:22]
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. [19:23]
asciilifeform: when i was actively trbing, i handled 'want p1 + p2 + ... p_n ' by hand-copy and producing p_n+1 [19:23]
asciilifeform: phf: correct [19:23]
asciilifeform: phf: which is why i wrote the classical vtron the way i did -- wanted max flexibility of form. and yes this has cost. [19:23]
asciilifeform: can make it narrower. but then you lose the multiverse aspect, aha. [19:24]
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 [19:25]
mircea_popescu: the original "many keys" solution to that proved untenable. [19:25]
asciilifeform: not sure that anybody got around to trying it [19:25]
mircea_popescu: this imo is loud proof. [19:25]
asciilifeform: just cuz the lorica is too heavy does not prove 'armour is Wrong Thing' , lol [19:26]
mircea_popescu: it does, yes. the old french word for it is agincourt. [19:27]
asciilifeform: by same logic 'v is a bother and let's all shithub', conceivably, neh ? [19:27]
mircea_popescu: neh. [19:27]
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 [19:28]
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' [19:29]
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 [19:29]
phf: l [19:29]
phf: which we also had thread about [19:29]
asciilifeform: problem is that most meaningful transforms are ~not~ attainable automatically, and the otherwise spiffy vtronics create unwarranted expectation of automatism [19:29]
asciilifeform: heathens do not have this headache in their pigstys [19:29]
phf: right, hence the conversations about sexp v [19:29]
asciilifeform: (because they have properly low expectations) [19:30]
mircea_popescu: this is actually very much the problem, huh. [19:30]
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" [19:32]
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) [19:33]
phf: *of tracking [19:33]
mircea_popescu: except first is practical nonsense, and second presumes thingd about directories, which is untenable. [19:34]
mod6: one file, != fits in head [19:34]
mod6: vpatches were meant to be digestable. [19:34]
* asciilifeform ftr biased in favour of pills that leave the orig vtron simple ( while potentially introducing a separate tool for testing conformance to chronology ) [19:34]
asciilifeform: ^ [19:35]
mircea_popescu: asciilifeform conformance is not mechanically tested. [19:35]
asciilifeform: i did not say wholly automatic . simply 'tool' . [19:35]
asciilifeform: could reduce even to naked eye. [19:35]
mircea_popescu: a yes. [19:35]
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. [19:35]
asciilifeform: the way classical v can be , in times of need , reduced to naked eye. [19:35]
asciilifeform: phf: how would this look , so that mass of patches stays similar to classical ? [19:36]
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 ? [19:36]
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 [19:37]
phf: no no [19:37]
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. [19:38]
mircea_popescu: yeah but i suspect that's a large part of why it went nowhere. [19:38]
mod6: OH. i see what you're saying. so in stead of a & b per file, you're saying a & b for ~entire~ vpatch [19:38]
asciilifeform: phf: i actually tried this, into a drawer, but gave up -- ugly and inbandistic [19:39]
mod6: or am i still missing this? [19:39]
phf: i.e. trb.vpatch -> trb.web -> foo.c, bar.c, qux.c [19:39]
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 ) [19:40]
phf: this is so trivial, and also inconsequential that i apologize for burning s/r on it [19:40]
mircea_popescu: ty. [19:40]
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. [19:41]
asciilifeform: iirc i suggested this explicitly at one point, http://btcbase.org/log/2017-12-14#1751755 [19:42]
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 ? [19:42]
mod6: phf: oh [19:42]
asciilifeform: but result was 'ugly inbandism', though it may be possible to do it without magic-symbols [19:42]
mod6: it would also get nasty each time you remove or add a file in here. [19:43]
mod6: anyway, ok moving on.. [19:44]
asciilifeform: mod6: not really, no. it becomes just another text transform. ditto renames and redirs. [19:44]
mod6: alright, i'll have to take your word for it im imagining some huge diffs. [19:45]
mod6: Eitherway, I've become to like how we have it now. [19:45]
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. [19:45]
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. [19:47]
mircea_popescu: phf see, it never stops. it's not something one can turn off at will, sadly.\ [19:48]
phf: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a regrind. [19:52]
* phf bb [19:52]
mod6: cool, an example of this that we can use to examine would be hugely helpful. [19:52]
mircea_popescu: ah check it out, trilema has the header with the head errant today. [20:34]
hanbot: i think that's a head rampant. [20:35]
mircea_popescu: rompant lol [20:38]
asciilifeform: oook so asciilifeform dug out his old experiment, in case anyone can win from it : [21:49]
asciilifeform: ACHTUNG, PANZERS! : http://therealbitcoin.org/ml/btc-dev/2018-March/000293.html [21:50]
asciilifeform: ^ and yes i classically-v-genesised it, given as there is not yet a new-v [21:50]
asciilifeform: and yes there is a typo in readme, 't.xtal' should be 'test.xtal' . [21:51]
asciilifeform: everything else is self-explanatory. [21:51]
asciilifeform: mircea_popescu, phf , mod6 , trinque , et al ^^ [21:51]
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 [21:52]
mod6: hey neat, i'll give this a closer look here tonight. [21:53]
asciilifeform: don't burn too much time on this item, mod6 , it is strictly for vtronology. [21:53]
mod6: thanks for the post asciilifeform [21:53]
asciilifeform: all it does is the 'human readable tarball' trick. [21:54]
asciilifeform: both to- and from- directions. [21:54]
asciilifeform: quite possibly only trinque will find this tool interesting : it implements , i think, his favoured variant . [21:55]
asciilifeform: ( or rather, just the whole-program representation therein -- it is not a vtron ) [21:56]
asciilifeform: anyways i've cluttered the l0gz enuff, that's all there is to this item currently. [21:56]
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 . [22:01]
* asciilifeform back to wurk, bbl [22:08]
asciilifeform: btw, ftr : ffa comes back from sabbatical next wk ! [22:09]
mod6: hey hey hey, lbj [22:13]
Category: Logs
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.
Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.