Hide Idle (>14 d.) Chans
← 2017-12-13 | 2017-12-15 → ↓
ben_vulpes: canvassing the low bandwidth radio space
ben_vulpes: concretely, trying to figure out what it would take to prototype a tuneable phase locked loop channel
diana_coman: asciilifeform, would you please elaborate on http://btcbase.org/log/2017-12-07#1748150 ? apparently it's still not straightforward enough for me in practice
a111: Logged on 2017-12-07 16:51 asciilifeform: mircea_popescu: you can: diff ~the patch~
BingoBoingo: !~ticker --market all
jhvh1: BingoBoingo: Bitstamp BTCUSD last: 16651.45, vol: 14908.84943855 | Bitfinex BTCUSD last: 16600.0, vol: 59781.18472423 | Kraken BTCUSD last: 16550.0, vol: 3279.47747035 | Volume-weighted last average: 16607.7349007
shinohai: Is this UBI thing a meme now? http://archive.is/q3fXn
BingoBoingo: No, memes are funny
BingoBoingo: And they stick
BingoBoingo: It's an unfunny forced meme
shinohai: But the concept of a UBI is hilarious period.
BingoBoingo: But it would piss of walmart customers: "Whaddya mean the help is taking home more money because they work AND get muh welfares!
asciilifeform: !~later tell diana_coman plox to describe, very very specifically, what you need done. then i'll show how.
jhvh1: asciilifeform: The operation succeeded.
diana_coman: asciilifeform, I need to create a vpatch that performs the change of dir structure from a/mpi to b/eucrypt/mpi where the contents of the mpi folder in both cases are identical; or more specifically for the task at hand: I want to create a vpatch that has as antecedent my previous sane_mpi_eucrypt.vpatch (whose output is an mpi folder with all sorts) and results in eucrypt/mpi where this new mpi folder has precisely same contents
diana_coman: fwiw I managed to do this to some extent, but I don't like this "to some extent"
asciilifeform: diana_coman: i gotta ask , what did this 'to some extent' look like.
diana_coman: asciilifeform, it does the move BUT it requires post-cleaning (i.e. leaves some stuff behind) + works only with mod6's v; so something is wrong somewhere and hopefully it's just on my side i.e. I can correct it quickly following your explanation of how it should be done
asciilifeform: let's see it
diana_coman: mind telling me how you see it done? it's hopefully faster than debugging a wrong approach; once I have it working I'll write up the failure too if that's the thing
asciilifeform: i'm making an example, brb
diana_coman: k, thanks
phf: diana_coman: it's not going to be pretty. it'll be twice the amount of text: once to delete the old file with - - - - and once to create a new file with + + + +
asciilifeform: phf: this is the basic insanity of gnupatch. a proper vpatch ought to see that the hashes are the same incoming and outgoing , and Do The Right Thing without the idiot spew
asciilifeform: *vpatcher
asciilifeform: the 1 thing i still don't fully understand is why diana_coman's subdir gotta move
asciilifeform: it isn't required for the linker, nor for maintaining v-lineage ( the latter works just as well if diana_coman were to simply add a comment to 1 or more items in mpi dir , that 'this is nao part of eucrypt' )
asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi'
asciilifeform: then you dun need any gnupatch shenanigans.
asciilifeform: i'ma demonstrate, brb
phf: presumably she doesn't want to compromise the resultant press because of poor tooling
phf: well, the project is called eucrypt, presses into eucrypt directory, inside it has support infrastructure like mpi
phf: if she decides to replace bignum backing, presumably mpi will get nuked and replaced with something else
asciilifeform: 1s, almost done with example
asciilifeform: it's not eucrypt, of course, but the helloworld i originally included in mpi . but shows what i meant above.
asciilifeform: you can press it in my vtron, by 1) recreating diana_coman's working set from last week 2) drop pseudo_eucrypt.vpatch into patches dir 3) ./v.py -wild --wot .wot --seals .seals patches p patches/pseudo_eucrypt.vpatch pseudoeucrypt
BingoBoingo: !~bcstats
jhvh1: BingoBoingo: Current Blocks: None | Current Difficulty: 1.590896927258E12 | Next Difficulty At Block: 499967 | Next Difficulty In: None blocks | Next Difficulty In About: 3 days, 17 hours, 55 minutes, and 40 seconds | Next Difficulty Estimate: None | Estimated Percent Change: None
asciilifeform: BingoBoingo: do you mind?
asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
asciilifeform: now let's come back to my much earlier pill, which i suggested in the mircea_popescu thread. which is imho even uglier. in that one, diana_coman would have to introduce the three mpi-ism vpatches comprising her working set, as ~files~ into eucrypt. and a sed script, and a vtron invocation, into her eucrypt makefile.
asciilifeform: if phf , or anyone else, can think of a 3rd ( that is, one that actually preserves the v-genealogy , rather than idiot-cut-and-pastism ) i'm all ears.
mod6: your example will not work with my vtron, for one simple reason: the new rules state that we do not do ANYTHING with vpatches that do not have a corresponding signature - we IGNORE WILD vpatches and drop them on the floor.
asciilifeform: imho the item i posted just nao, illustrates the cleaner method. but it has down-side in that one has to give up on 'i get to decide exactly what the unix dir structure will look like, notwithstanding the fact that gnumake was dropped as a baby and has nfi what file moving is'
asciilifeform: mod6: if you dun have a testmode, you gotta sign it yerself to run it, what can i say
mod6: That is fine; if it has a valid corresponding signature.
asciilifeform: mod6: i dun like to uncase the launch codes 10,000,000 times per day every time test press. but others are moar than welcome to.
mod6: I understand that sentiment. We discussed this at length. Which is why I actually have a test-vpatch pgp key for that purpose only.
asciilifeform: or can sign it with the mahmood khadir key, or 1 of the others we broke, lol
mod6: haha, fair enough
asciilifeform: at any rate it oughta be obvious what the illustration does simply from naked eye reading.
asciilifeform: you dun actually need to press it, unless specifically want to.
mod6: sure, thanks for posting the sample for diana_coman
asciilifeform: now here's a 3rd pill :
asciilifeform: eh nm no 3rd. can't think of one.
phf: i didn't necessarily need the illustration, because i understood what you were saying, my point was merely that it's sad state of things
asciilifeform: i'ma leave it for diana_coman , mod6 , phf , mircea_popescu , et al, to consider which pill is less barfatronic, and possibly conceive of another.
asciilifeform: phf: sad indeed, and afaik unfixable without sending gnupatch/gnudiff to where they belong -- into the oven.
asciilifeform: though i'll admit that i personally dun get the fixation with moving mpi to being a subdir of $newproj.
asciilifeform: the vdiffing worx exactly correctly, as does the linkage, without this.
asciilifeform: ( both demonstrated in the example. )
phf: well, the nature of v is that you're pressing into a global namespace. in fact that was a property of the original idea to a great extent (hence mp and his insistence on there being only one genesis). we compromised that already by having multiple projects, but you still run into the same issue when you're trying to combine multiple projects together. you're basically saying that the press namespace doesn't matter as long as there's no collision. ~othe
phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
asciilifeform: i happen to see the entire unix directory scheme as idiocy
phf: sure, but you can't avoid namespacing issue. you're pressing files by name.
asciilifeform: but, observe, phf's scheme could easily work, and require afaik no regrinds
asciilifeform: take for instance trb , as seen in http://btcbase.org/patches/genesis/file
asciilifeform: dir is 'bitcoin'
asciilifeform: take mpi . dir is 'mpi'.
asciilifeform: iirc all of the v-releases, to date, are already dir-siblings in phf's hypothetical tmsr-rootdir.
phf: nah
phf: actually, i think fg is the only exception
phf: but yeah in that model your press is / and you have /mpi and /eucrypt, so if you want to link against /mpi you do ../mpi/... in your makefile
asciilifeform: aha, as shown
phf: no what's shown is eucrypt ~inside~ mpi
asciilifeform: and yes fg genesis apparently lacks subdirization.
asciilifeform: phf: how inside ? they're sibling dirs
phf: ah yeah you're right
phf: well, then we're on the same page
asciilifeform: i like phf's unification idea. even if it means that at some point i gotta regrind fg-genesis.
asciilifeform: common dir root for errything.
asciilifeform: it very much seems to me, to be The Right Thing.
asciilifeform: also oughta satisfy mircea_popescu's 'there was 1 genesis' item. because under phf's unification, there in fact ~was~ , created an empty universe with a 'bitcoin' dir.
asciilifeform: this also makes the vtronic-linux a moar tenable, imho, proposition.
asciilifeform: picture, all v-released items live in /v/ ; seals in /seals/; wot in '/wot/; /v/ gets pressed on install, and on request whenever later...
asciilifeform: common root lets you vdiffate whatever change you made to anything, even if it takes in > 1 subsystem.
asciilifeform: all binaries on the box must trace their descent to contents of /v/...
phf: right
phf: it is to some extent a bsd model (that slackless os also follows it), where you have baseline system, where the source is owned by a cabal of maintainers/developers
asciilifeform: suckless ?
phf: err, yes, i was going to say slackware, but they are sloppier than bsd
asciilifeform: http://btcbase.org/log/2017-12-14#1751421 << ben_vulpes wtf is 'low bandwidth radio space' ??! how does this differ from 'low thickness physical space' ? how do i parse yer sentence ?
a111: Logged on 2017-12-14 05:08 ben_vulpes: canvassing the low bandwidth radio space
asciilifeform: http://btcbase.org/log/2017-12-14#1751422 << where does one find a ~non~-tunable pll , ben_vulpes ?
a111: Logged on 2017-12-14 05:14 ben_vulpes: concretely, trying to figure out what it would take to prototype a tuneable phase locked loop channel
asciilifeform: what's even is it.
asciilifeform: possibly i can guess what ben_vulpes wanted... answr is, there is 0 ionospheric propagation at any of the spectrum the cheapo rtl dongle is able to pick up.
asciilifeform: it's good for what comes from before your horizon, and that's it.
ben_vulpes: too parsimonious!
asciilifeform: it also doesn't transmit. if you wanna transmit, you need an actual sdr, e.g. 'hackrf' , 'gnuradio', or something made with own hands.
ben_vulpes: hardware for broadcasting and receiving data over low bandwidth radio links
asciilifeform: rtldongle dun transmit.
ben_vulpes: yeah, this i know.
ben_vulpes: vga card doesn't receive, right?
asciilifeform: vga card + pirate hf amp -- transmit.
asciilifeform: ( connection left as exercise for the reader. )
asciilifeform: rtl dun receive ~anything at <=30Mhz .
asciilifeform: ( and the supposed converter boxes, dun work worth a shit. ) but iirc i already mentioned this.
ben_vulpes bbl, teaching human 101, will return later
asciilifeform: try 'hackrf' or 1 of the other inexpensive 0-2Ghz or whatever, 'swiss army knives'
asciilifeform also bbl
mod6: mornin'
ben_vulpes: apparently mike_c's new gig has now banned messages to girls from users they haven't "liked" yet
ben_vulpes: they show up on the sender's "profile" instead
ben_vulpes: so it's a shitty bumble now.
ben_vulpes: which is kind of impressive because bumble was already a shitty tinder, providing a cover for short-term coy behavior in online dating.
BingoBoingo: ben_vulpes: Well, maybe it's part of mircea_popescu's vast conspiracy to push people into more crowded spaces?
ben_vulpes: mike_c, the republic's mole in IAC
ben_vulpes: buenos dias, BingoBoingo
BingoBoingo: ben_vulpes: Aqui es "Buen dia" en la manana. Otra veces "Buenas" (tardes o noche not specified)
ben_vulpes: buen dia!
BingoBoingo first 3 days heard it as "Bom dia" though they adopted portuguese greeting from Brasil.
mircea_popescu: http://btcbase.org/log/2017-12-14#1751431 << nah. there's a straight relationship between humour and hope : anything thats hopeable is not humorous and vice-versa.
a111: Logged on 2017-12-14 13:49 shinohai: But the concept of a UBI is hilarious period.
mircea_popescu: (humor necessarily feeds of contradiction of expectations ; hope is always and no matter how disguised continuation of expectation. the contradiction between the two is absolute and a matter of definition.)
mircea_popescu: that's also why poor people, stupid people (but i repeat myself) and socialists, "democrats", pantsuits etc are so fucking unfunny. too hope-y, or rather, their intellects are too dysfunctional to handle contradiction, of whatever kind.
mircea_popescu: http://btcbase.org/log/2017-12-14#1751446 << VERY late in the game to "not understand" this.
a111: Logged on 2017-12-14 15:38 asciilifeform: the 1 thing i still don't fully understand is why diana_coman's subdir gotta move
mircea_popescu: the correct time to not understand it was LAST fuycking week, when http://btcbase.org/log/2017-12-07#1748152
a111: Logged on 2017-12-07 16:52 mircea_popescu: so then why can't she simply move the mpi/ dir into eucrypt/mpi/ and proceed ?
ben_vulpes: always entertaining to watch "just wanted"s rack their nuts on the handrail of reality
mircea_popescu: there is that.
BingoBoingo will have to add that to hosting menu. How many nuts per RU?
mircea_popescu: http://btcbase.org/log/2017-12-14#1751448 << because it's not a fucking sibling to fucking mpi
a111: Logged on 2017-12-14 15:39 asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi'
ben_vulpes: none, cab should be threaded :D
mircea_popescu: mpi is a SUB. and if it can't act the sub part it's getting cut out with hot irons and the ground where it stood salted.
mircea_popescu: exactly like ANY OTHER piece of fucking useless heathenry
mircea_popescu: http://btcbase.org/log/2017-12-14#1751463 << it does exactly one fucking job. this one : diana_coman please don't talk to asciilifeform or take any further advice from him. total timewaste.
a111: Logged on 2017-12-14 15:51 asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
a111: Logged on 2017-12-05 15:11 asciilifeform: and in general i dun expect any of it to be paid for, there is no tradition of any such thing. but i do have the possibly naive expectation of the work not to be shat on.
mircea_popescu: this isn't work, what you're doing. this is anti-work.
mircea_popescu: and it's not the first time ; it's the fucking third. every time she tried to get some sort of support from you, you acted the retarded usarmy desk flier, cost her 10x the time it'd have taken if she were camping in the desert.
mircea_popescu: this is me opting out. now go read thefucking logs ; copy BY HAND on a notebook what you did wrong, in fucking gothic longhand, a dozen times, and get it in your thick skull.
mircea_popescu: the world's not some sort of wide open grazing range where we can just randomly produce useless nonsense.
asciilifeform: not as if asciilifeform hypnotized diana_coman into repeatedly requestion (unpaid!) support for her (commercial) proj from him.
asciilifeform: *requesting
mircea_popescu: so now that problem is solved ; go do something else, there shall be no more of this.
asciilifeform returns to somethingelse
BingoBoingo: !~ticker --market all --currency gbp
jhvh1: BingoBoingo: Kraken BTCGBP last: 8031.0, vol: 0.03649989 | Volume-weighted last average: 8031.0
BingoBoingo: !~ticker --market all
jhvh1: BingoBoingo: Bitstamp BTCUSD last: 16349.16, vol: 13907.27801175 | Bitfinex BTCUSD last: 16382.0, vol: 51961.20651967 | CampBX BTCUSD last: 13350.0, vol: 0 | Kraken BTCUSD last: 16395.0, vol: 3078.69426607 | Volume-weighted last average: 16375.9563592
BingoBoingo: Incredilag
mircea_popescu: lag is always credible.
mircea_popescu: http://btcbase.org/log/2017-12-14#1751486 << i considered this. it's not evidently broken, but i think it subtly is broken, and the principal cause of the failure of the unix actually -- a failure to correctly handle namespaces.
a111: Logged on 2017-12-14 16:13 phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
mircea_popescu: yes we don't have a gns yet, but this doesn't excuse us from... doing the same computations by hand as if we had it! it's not suddenly allowable to go "well since i have no running water i therefore do not wash". no bitch -- since you have no running water, you walk fifty miles uphil each way to GET water in a bucket. still wash.
asciilifeform: that'd mean tmsr-diff
mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
mircea_popescu: like how oral culture worked, the concept of a trope, as found in folk tales, is really simply equivalent to "and this is how mpi goes, and this is how bubblesort goes..." and so on.
mircea_popescu: over time it'll actually get systematized, as in the aaerne-thompson system for folk takes, or as in the tmsr-diff here. but that day is far into teh future.
asciilifeform: if mircea_popescu decides to have the eulora programmers not only copy the thing verbatim, as if v never existed, but to retype it, and whack'em with a stick for each mistyped letter, who am i to object . it's his proggy.
mircea_popescu: contrary to naive intuition, there is no damage in re-reading old code as if it were new.
asciilifeform: fwiw i do it ~all day, ~every day.
mircea_popescu: in fact, i expect it will be the MAJORITY of work for humans in the future.
asciilifeform: it's what i do for a living.
asciilifeform: mechanical tools can make the job slightly smaller, or - when they're rubbish - slightly larger. but it remains.
asciilifeform: incidentally if mircea_popescu wanted to go 'whole hog' re http://btcbase.org/log/2017-12-14#1751589 , could even throw out asciilifeform's mpi and make new one from the source material. see if it ends up same, possibly find new cuts.
a111: Logged on 2017-12-14 19:22 mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
asciilifeform promises not to cry , is old enuff
mircea_popescu: that's ok, minigame delayed enough as it is.
mircea_popescu: phf are you amenable to re-writing diff btw ? http://btcbase.org/log/2017-12-06#1747792 is going to happen later this year, and v-immutability is a pita.
a111: Logged on 2017-12-06 22:51 mircea_popescu: once we have keccak.
asciilifeform: iirc ben_vulpes had a prototype .
ben_vulpes: mnope did not
asciilifeform: mircea_popescu: consider making a spec for the One Troo Diff ?
asciilifeform promises to read
mircea_popescu: kinda open matter yet ; but procedurally one takes the diff source code, genesises it, patches the differences and produces a drop-in diff replacement.
asciilifeform: yea but mircea_popescu demanded sane namespace behaviour
mircea_popescu: i'm letting him contribute, what. he understands what the problems are.
mircea_popescu: maybe he bites the bullet and makes special files. or who the hell knows. i'm curious.
mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
mircea_popescu: can EVEN KEEP the +++ --- style separators, but in the DATA segment
mircea_popescu: making your file comvertible to old style patch through a truncation op.
a111: Logged on 2017-01-03 21:14 mircea_popescu: v is really only as powerful as the underlying differ is.
a111: Logged on 2017-01-05 00:49 mircea_popescu: i do not wish to live in a world where people can make patches consisting of 512kb lines of a
a111: Logged on 2017-01-05 00:24 mircea_popescu: lines are good!
mircea_popescu: !!up nocko
deedbot: nocko voiced for 30 minutes.
mircea_popescu: you new here ?
a111: Logged on 2017-12-10 21:23 nocko: I was linked to FFA guide, started looking around and am now here. I cannot say that I yet have half an idea what's going on... but hello.
asciilifeform: !!key nocko
deedbot: Not registered.
asciilifeform: maybeshakespeare, maybeanothermanbysamename
asciilifeform bbl, meat maneuvers.
phf: http://btcbase.org/log/2017-12-14#1751602 << i have some ideas of the first steps, that is i can make backwards compatible vpatched diff/patch
a111: Logged on 2017-12-14 19:42 mircea_popescu: phf are you amenable to re-writing diff btw ? http://btcbase.org/log/2017-12-06#1747792 is going to happen later this year, and v-immutability is a pita.
phf: take existing stuff, strip it down to just what we already have -ruN functionality. i think that the actual tools should be vdiff and vpatch, that is they do shasuming themselves and produce proper vpatches/apply proper vpatches, but without chain or signature validation.
mircea_popescu: why without ?
phf: well, signature validation is done by gnupg, i don't see any reason to bring that whole thing in, and there's very little reason to system("gnupg ...")
phf: chain validation needs to only go as far as "does the hash on the file that i'm about to patch corresponds to what i expect"
mircea_popescu: the whole idea is to eg import keccak from eucrypt
mircea_popescu: and why would diff/patch be outside of vtroner is the larger design question
phf: mpi is a fraction of what gnupg is, are we then moving away from pgp keys and signatures?
mircea_popescu: idea is to use tmsr-rsa anyway
phf: hmm
phf: this then is entirely unscoped
mircea_popescu: it is. open discussion.
mircea_popescu: in principle we could do incremental builds ; but only if they can be cleanly upgraded later, that's a major point.
phf: in my thinking vtroner is a larger beast, that's responsible for the management of the entire press chain. patch/diff are dealing with a specific problem of comparing two states, producing a difference of those two tays, and then taking a state into a next state according to differences
mircea_popescu: so basically keep them modular ?
mircea_popescu: can you imagine any other context besides pressing this new diff/patch would be used in ?
phf: from that perspective both vdiff and vpatch ~could~ also produce a corresponding sig, in which case the protocol is that patch/diff produce an always valid vpatch (i.e. vpatch/sig combination)
mircea_popescu: how can they sig for you
phf: i thought that's what you were talking about?
mircea_popescu: ~check~ signatures.
phf: or the thinking that vdiff doesn't sig, but then vpatch expects a sig never the less?
mircea_popescu: not produce them
mircea_popescu: and yes.
mircea_popescu: sign in your sign room, mofo.
phf: i don't think that's a good idea, but i can't articulate an objection. vpatch now needs to know about your wot and wot management, or else the process of patching now becomes explicitly providing a pub key, a corresponding sig and a vpatch itself.
mircea_popescu: it doesn't have to be decided now.
mircea_popescu: isn't the latter actually ideal, protocol wise ?
phf: well, this goes back to the threads about whether or not it makes sense to patch sigs on your workbench. i use patch in my workflow frequently outside of pressing a tree to bring things from one state into another. i might have a dozen of unsigned patches, that i'm working with that won't see the light of day
phf: in this case the value of proper vpatch/vdiff is that they never produce fuzzy patches and always validate the shasum for you, but they don't do the v-tronic management
mircea_popescu: you're absolutely right. patch process must be much looser than this.
phf: actually phf-shiva-swank is still broken in the experimental patchset, because it was produced by vdiff/patch combination (vdiff made some claims of shasums, which patch didn't verify. the fact that i should've verified the press is a different question)
phf: btw one of the reasons for dodgy delete function in the diff is that patches theoretically a reversible, -'ing all the lines of file can conversely be +'d back
phf: but anyway, i'm not convinced that file management is a proper concern for diff. we could add it to a diff format, by placing some instructions in the prelude (which is normally ignored by unix patchers). rm src/foo.c, mv src/foo.c src/bar.c which can be used as instructions for reader with non compliant patchers, or parsed by the vpatcher to be executed. this is all incredibly inband, but conforms to the medium
mircea_popescu: the fact that unix diff is directory blind is an idiocy larger than commonly encountered in that thing's misdesign
mircea_popescu: a file is not "its contents and AN ARBITRARY TRUNCATION OF ITS NAME"
mircea_popescu: and a file's fucking name is its absolute path, not the last bit thereof.
mircea_popescu: but whatever, in 1970 people couldn't afford disks with actual directory structure in them
phf: diff/patch allows for absolute paths, we don't them it though
mircea_popescu: i don't know how it allows if i can't move a god damned file.
phf: well, moving of the file is a filesystem operation, what does it have to do with ~diffing~?
mircea_popescu: that the name of the file is the file.
mircea_popescu: the FILE has changed.
phf: sure, but diff's way of indicating change is to show what happened to a file, that is all the lines of the file got deleted
mircea_popescu: if i edit glib.c and replace line 50 with "fuck you stallman", and then try to compile glib.c, i get an error. if i edit glib.c and MOVE glib.c to /fuck/you/stallman/glib.c, and try to compile glib.c, i get an error
mircea_popescu: ergo, BOTH these operations have been edits of the file.
mircea_popescu: phf and in that diff is designed by turkeys.
phf: diff has two things that it can signal: an addition of a line, and a deletion of a line, which is in line with what it claims to diff, i.e. diffing of lines
phf: *claims to do
trinque: problem stemming from that unix uses file path as a matter of identity, and allows this to be mutable (!)
trinque: can't be both
mircea_popescu: trinque's statement is perfectly acceptable.
phf: but then the question is what is the responsibility of diff
mircea_popescu: phf sure, and subsistence hunting has two things that it can do, throw rock or jab spear. this is in line with it being an occupation of idiots invented by idiotws.
phf: fwiw diff can't even know that a file has been moved
mircea_popescu: but it can know that it's not in the same directory.
phf: no, it can't
mircea_popescu: "the difference between a/fuckyoustallman.c and b/fuckyoustallman.c is 1) that one's in a and the other in b ; 2) no further"
mircea_popescu: why can't it ?
phf: if you do mkdir a; touch foo; touch a/foo; mv foo a/foo;
phf: there's no way of knowing without having a complete history of states whether or not foo was moved or removed
mircea_popescu: but you can know that one foo is in a and the other not
mircea_popescu: diff compares two items, not an item to itself
mircea_popescu: when i say diff a/foo b/foo, diff fails to output "one is in a, the other in b" as the first fucking item on its list of differences. this is because the (idiots) that made diff thought they gain something by eliding "the trivial case".
mircea_popescu: this turns out to not have been so
mircea_popescu: "of course the user knows they're not in the same dir duh" is no design logic.
phf: wut
phf: it's precisely first item it outputs
mircea_popescu: then WHY!!!! can't i use it to move files!!11
phf: diff can't know if the newly appeared item that's identical to an item that exists elsewhere in previous state has been moved there from the elsewhere or created in situ
phf: you can communicate that information through a patch format, but that's not something ~diff~ can guess about
mircea_popescu: i dun get what the problem is.
mircea_popescu: if you have a : a/b a/c and b : b/b b/d/c it is thereby evident upon diffing a and b that c was moved from a/ to b/d/ if a/c contents === b/d/c contents.
phf: say you have /a/foo and you have /a/bar/foo where both foo are identical. you're running diff -ruN a b, what is the expected behavior?
mircea_popescu: what's to guess ?
phf: by your previous question you're saying that diff is supposed to say that foo was moved
mircea_popescu: this'd require all file movements to be a separate patch, as you can't both move and edit in the same go. which imo is bonus the right thing
mircea_popescu: phf yeah ?
phf: what if you have /a/foo and /b/bar/foo, /b/qux/foo where all foo are identical?
mircea_popescu: then the first one was moved and the other created.
mircea_popescu: also, if it dies a flaming death in this case that'd be very acceptable, and fuck you for keeping duplicates like that.
phf: so basically hash sums trump namespacing always
mircea_popescu: it's why we have them
mircea_popescu: "file's identity" as per trinque
phf: in that case we should probably forbid hash identical files to be in different paths
mircea_popescu: kinda what i said above
mircea_popescu: we have long ago de facto forbidden hash-identical files ~from being~. anything, at all.
phf: (that was by the way how btcbase patcher worked for a long time, until i had to modify it because there are placeholder items in bitcoin source code that are at different filepaths)
mircea_popescu: hence the keccak instead of curent whatever it is.
mircea_popescu: phf because it's the logical way for it to work
mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
phf: not restricted to moves by the way, there's also copy. there's a certain symmetry lost though. if you say make a genesis with 3 empty files a b c, then they are fresh line patches. but the patch against that that creates another 3 empty files puts cp a x; cp a y; cp a z; in the prelude instead
mircea_popescu: anywya, this system'd be purrfect : if hash unchanged, "this is THE SAME file by a different name (or path, same thing" ; if hash changed "this is DIFFERENT FILE by same name"
asciilifeform: http://btcbase.org/log/2017-12-14#1751721 << ftr my orig v eggogs, 'cyclic graph!' if any new-hash is == to any old-hash
a111: Logged on 2017-12-14 21:14 mircea_popescu: we have long ago de facto forbidden hash-identical files ~from being~. anything, at all.
mircea_popescu: phf no such thing as empty lines. put a fucking comment in there.
mircea_popescu: empty files* i mean
phf: mircea_popescu: well, empty file does have a shasum
mircea_popescu: if you put empty files in your project i will personally chase you down in the afterlife.
phf: but in this model you can have only one
mircea_popescu: tbh i don't even understand why the machine permits such insanity. an empty file is very much a http://btcbase.org/log/2017-11-14#1738478 trigger
a111: Logged on 2017-11-14 22:08 asciilifeform must invoke herr babbage, 'i cannot rightfully apprehend the confusion of ideas...'
asciilifeform: mircea_popescu: it's a cmachineism -- 'hey this register CAN haz a 0 in it, ergo lengths of 0 are permissible'. observe that i banished this idiocy from ffa planet
a111: Logged on 2017-12-14 20:59 trinque: problem stemming from that unix uses file path as a matter of identity, and allows this to be mutable (!)
asciilifeform: ( where length of FZ 0 is ~not~ permitted, because wtf )
mircea_popescu: we evidently also ~could~ add filename to the hash. but i dun wanna.
asciilifeform: you could in phf's unified-namespace thing, but i dun see how else otherwise
phf: (fwiw so far i've been using patches prelude to stuff metainformation there. one interesting property of patching an already pressed lisp system, is that you don't want a clean press. instead you want to find what state your system is, and then press it further down the chain. but because you don't want to restart the system likewise, you want some additional actions performed as you're moving down the press chain. so i've been using prelude as a place
phf: to put lisp commands that need to be run after the source has been pressed to the current patche's state.)
shinohai: "We're excited to announce that your Blockchain wallet is now offering full support for Bitcoin Cash! "
shinohai: Why even bother with Bitcoin
asciilifeform: phf: consider posting example ?
mircea_popescu: phf interesting
asciilifeform: http://btcbase.org/log/2017-12-14#1751725 << the retardation of unixdiff is unfortunately not limited to file moves. it also has no ability to represent , e.g., sections of a file moving ( iirc this came up during the original genesis thread )
a111: Logged on 2017-12-14 21:16 mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
asciilifeform: it's a pathetically dumb state machine.
asciilifeform: the tragicomic part is that i picked plain old diff for vtronics 'so that patches will be readable'
asciilifeform: ( and 'everyone already has it, and it works' etc )
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 ?
a111: Logged on 2017-01-05 00:29 asciilifeform: so, one possible diff might be : \4\i'm \+15\quite certainly \80\not fucking learning an aminoacid matrix to be able to use diff i tell you that
asciilifeform: incidentally mircea_popescu , phf , consider a particular cut : suppose that ( otherwise unchanged ) diff format did not mention paths at all, only hashes. and there is a separate section, 'manifest', that is table of hashes to paths. during press, the latter is eaten and traditional unix dir appears.
mircea_popescu: too many knobs
asciilifeform: it's 1 knob.
asciilifeform: and does away with the horror chamber of 'i moved a file, where did the 10 MB of crud come from'
asciilifeform: i dunno that the addition of a knob to divorce from the idiocy of unixpathism , is really escapable
asciilifeform: it'll have to be solved , in some way, with at least 1 knob.
ben_vulpes: if i recall correctly, the empty files are necessary to hold the output of trbs compilation process
asciilifeform: ben_vulpes: only because unix diff , again , is retarded
asciilifeform: and pretends that empty dirs don't matter, but somehow a dir that is empty BUT for 1 emptyfile -- is nonempty.
asciilifeform: it's rubbish.
asciilifeform: observe that in e.g. ffa , used nonempty placeholders.
asciilifeform: ( trb-genesis, for better or worse, was a plain cut of the original material. ended up preserving the idiocy of empty file. )
mircea_popescu: asciilifeform you don't specifically need a manifest, as per discussion (have you been reading the discussion ?) ; can just follow the hashes.
asciilifeform: aha caught up
asciilifeform: imho this is the troo cut
asciilifeform: make paths non-special
asciilifeform: and just text, and subject to diffing like any other text.
asciilifeform bbl,meat
mod6: ben_vulpes: also, patch will not even create those output directories for the build process if the dir doesn't contain at least 1 file. it simply ignores them.
mod6: it's idiotic.
a111: Logged on 2017-12-14 19:55 mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
phf: i'm not sure this is necessary, patch already contains line count information in the @ ... @ part
phf: +++ --- is there not for content parsing, but for allowing an arbitrary prelude (that is for including patches in email)
phf: the reason why we have issues with +++ and --- is because vdiff specifically ignores the @ ... @ bits when postprocessing a patch. a complete vdiff-er wouldn't have to do that kind of post processing and can produce a valid patch always
mircea_popescu: but this would remove the inband-ness
phf: i'm not sure where inband-ness even comes from. patch format has a header of a format 'command used to produce this diff\nsource file\ndestination file\n@@ specific numbers of lines to follow @@\nlines"
phf: so you're proposing to move @@ ... @@ to before "command used" part
mircea_popescu: well, because specific headers used to adnotate (@, +, -) can also appear in the text adnotated
phf: yes, and they won't make a difference!
mircea_popescu: i am in a word proposing to put all the @@ type adnotations in the begining ; and all data at the end
mircea_popescu: but i suppose you're right, a correct v-differ would just follow the extant protocol properly and not have the problem
mircea_popescu: in other news, anyone wanna do a 20bux paypal for me ?
mircea_popescu: danielpbarron ?
phf: our inband problems stem purely from not utilizing @@ ... @@ information
danielpbarron: mircea_popescu, sure
lobbesbot: Logged on 2017-12-14 22:44:09: <danielpbarron> this is a real testement to quality of S.NSA and its products
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).
mircea_popescu: by the looks of it, sometime in january. that works ?
phf: should be doable
phf: hmm, there's a bit of complexity there as far as producing files/directories shuffle, which might take longer, but i'll start with paring things down. i haven't yet seen diff/patch sources closely!
mircea_popescu: kinda why im giving you a two week lead here.
mircea_popescu: danielpbarron pm
mircea_popescu: that came out a lot dumber than intended. how about "plenty of time yet"
deedbot: http://www.dianacoman.com/2017/12/14/eucrypt-chapter-2-a-source-of-randomness/ << Ossasepia - EuCrypt Chapter 2: A Source of Randomness
diana_coman: to round up the previous thread: previous patch on mpi remains in place but linked to standalone mpi project; EuCrypt got is own genesis patch that creates *the whole currently known structure*; each chapter comes with its own patch adding content
mircea_popescu: onwards&upwards
phf: верной дорогой идете, товарищи
phf: diana_coman: since you basically split from mpi, i put you into a separate project http://btcbase.org/patches?patchset=eucrypt
mircea_popescu: diana_coman one that I actually bought link to http://www.dianacoman.com/2017/10/02/some-costs-of-importing-randomness/ neh ? mightaswell...
phf: asciilifeform: http://downloads.cornall.co/ibm-capsense-usb/ is that what you used for your model f?
phf: ah found relevant bits in logs http://btcbase.org/log/2016-09-12#1540407
a111: Logged on 2016-09-12 17:26 phf: asciilifeform: are you using breadboarded/soldered version, or you ended up printing the pcb too for the keyboard controller?
asciilifeform: aha phf, it
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).
asciilifeform: http://btcbase.org/log/2017-12-14#1751797 << lolneato. congrats on success of FG dealership, danielpbarron
a111: Logged on 2017-12-14 22:48 mircea_popescu: in other crossposts, http://logs.minigame.bz/2017-12-14.log.html#t22:44:09
asciilifeform: http://btcbase.org/log/2017-12-14#1751803 << at one time i linked to 'diff' src here, when hunting for ordering nonuniformity that turned out to be a uniturdism . it made koch's war crime, look clean.
a111: Logged on 2017-12-14 22:51 phf: hmm, there's a bit of complexity there as far as producing files/directories shuffle, which might take longer, but i'll start with paring things down. i haven't yet seen diff/patch sources closely!
a111: Logged on 2015-08-21 01:22 asciilifeform: mircea_popescu: try this on for size:
asciilifeform: http://btcbase.org/log/2017-12-14#1751807 << the fg link goes to my www , naked , which imho is not obviously relevant : i recommend https://archive.is/CGQkR instead
a111: Logged on 2017-12-14 22:55 deedbot: http://www.dianacoman.com/2017/12/14/eucrypt-chapter-2-a-source-of-randomness/ << Ossasepia - EuCrypt Chapter 2: A Source of Randomness
← 2017-12-13 | 2017-12-15 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code