1500+ entries in 0.126s
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
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!
☟︎ 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: 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
phf: i'm not sure this is necessary,
patch already contains line count information in the @ ... @ part
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.
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: 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
phf: you can communicate that information through a
patch format, but that's not something ~diff~ can guess about
phf: diff/
patch allows for absolute paths, we don't them it though
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)
mircea_popescu: you're absolutely right.
patch process must be much looser than this.
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: 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: can you imagine any other context besides pressing this new diff/
patch would be used in ?
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: and why would diff/
patch be outside of vtroner is the larger design question
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: making your file comvertible to old style
patch through a truncation op.
a111: Logged on 2017-12-07 16:51 asciilifeform: mircea_popescu: you can: diff ~the
patch~
mircea_popescu: "farting and landing"
patch on "breaking and entering" ?
mircea_popescu: why the fuck exactly can't i move project/a to master/project/a through a
patch ?
mircea_popescu: diana_coman you'd make a new genesis, for eucrypt, and
patch it with mpi. this
patch will share no .sigs with the other mpi it is text-identical to
diana_coman: is there some documented process re how to create with V basically a new project that will contain as *internal* components derivations of existing projects? for example: eucrypt will have inside an mpi component; as seen earlier, I can
patch mpi directly, but then how do I include the result in a higher structure? can I even do it while preserving the links? (I guess it would mean that resulting project has effectively 2 roots: one the ge
diana_coman: right; cleaned it again fully; put back in the readme file; made the structure a/mpi and b/mpi; can finally say that
patch presses fine with both vtrons
diana_coman: ugh; now I have a situation in which mod6's v simply drops on the floor my
patch, while asciilifeform's v sees it correctly in the flow BUT when pressing it barfs saying that a readme file that the
patch deletes does not exist as a result of previous
patch WHILE pressing previous
patch actually creates that file;
mircea_popescu: if anyone seriously considers re-writing venerable diff/
patch into v-dp
mircea_popescu: asciilifeform you shouldn't put gpg clearsigned bits in a
patch in the first place.
phf: the problem is not diff or diff format, the problem is that vdiff does a naive grep for a prefix and breaks a perfectly valid traditional
patch a111: Logged on 2017-12-06 22:05 phf: if you just run a diff -uNr on the two readmes, the resultant
patch works. if you run a diff on the resulting
patch and the vpatch in the tar, then you can see that there's something wrong with the vpatch specifically
phf: if you just run a diff -uNr on the two readmes, the resultant
patch works. if you run a diff on the resulting
patch and the vpatch in the tar, then you can see that there's something wrong with the vpatch specifically
☟︎ trinque: who was? just trying a
patch with bsd stubble vs gnu moss-hair
trinque: a read of the manfile of linux
patch suggests *massive* fuckery to allow idjits to pull patches out of other text, email, newsgroups, etc
trinque: differently wrong on openbsd
patch mod6: s/
patch/patched file/
mod6: it can't check the expected sha of a
patch BEFORE its DONE patching.
mircea_popescu: aaanyway, suppose diana_coman wants to add a
patch to mod6's vtron, to better error messages
mircea_popescu: asciilifeform just as soon as someone puts a
patch on top of it, the trees will diverge and then phf can exclude the legacy one or w/e it is he does to them
phf: asciilifeform: i had issues specifically with an older, genesis-less version. my system doesn't require antecedents to be there, but for some reason when there's only one, antecedent-less
patch it gives me a 404. i've not actually investigated, since you produced a genesis since
diana_coman: mod6 or asciilifeform, can you help? I'm trying to press asciilifeform's second
patch for sane-mpi and V complains that it can't find the vpatch file although it is there (and I checked the sig too and it's all fine); I'm running your V, version thebitcoin.foundation/v/V-20170317.tar.gz.mod6 ; I have the following folder structure:
http://p.bvulpes.com/pastes/1ZwgW/?raw=true; Here's the error when I run v press verbose . mpi_second_cut.vpa
mircea_popescu: he has a good nose sniffing it out, but i don't believe your sicilian's "if thumbs hurt, cut arm at elbow to be sure" approach is warranted. next
patch put a warning in the comments an' let 'em be.
ben_vulpes: best part is that it only undoes the
patch, doesn't re-break macs with root passwords manually set.
phf: “MacOS Update Accidentally Undoes Apple's “root” Bug
Patch (wired.com)”
a111: Logged on 2017-09-14 17:24 asciilifeform: ^ which does mean that i'ma have to a) audit the binary when ffa built for use in the field b)
patch gcc/gnat not to emit DIV
BingoBoingo: Hey, if the Gods raid your playing god
patch with a bunch of voracious bunny rabbit mobs, then you've gardened delicious rabbit
diana_coman: mircea_popescu, let me see if I got this right re "
patch": simply apply serpent as it is and then at the next level up glue x keys together and send as "key", glue the corresponding x outputs together and use as "output"; basically lump together 16 serpents
mircea_popescu: anyway, whatever, diana_coman : the correct implementation approach to
patch the 256 bit serpent into 4096 bit rsa is to cut every rsa block into 16 fragments, cipher each independently with diff keys, then paste the 16 keys together make 4096 bit of key.
shinohai: spyked: I did
patch config.sub because it is horrendously old and has no idea what system I was using.
spyked: hm. shinohai, I remember patching config.sub and config.guess at least. posting a
patch in one minute.
spyked: the original w3m-js
patch adds a -ljs compilation/link-time flag. now, there's another issue: if your libjs is in a path that the run-time linker can't find (e.g. /usr/local/lib as opposed to /usr/lib), it will fail again at some point.
spyked: shinohai, I know why the
patch fails, though not sure why it fails without it... did you also compile and install libnjs? e.g. on line 1840 in config.log, "cannot find -ljs". hm. I am guessing you should have it installed if w3m-0.4 worked for you.
shinohai: I know I have builit it plenty of times, I'm trying to remember if there was some
patch for that, don't recall
spyked: (ftr, libgc is why I rebased the
patch on w3m-0.5.3 in the first place; for some reason the "mktable" executable generated by w3m was segfaulting in the gc library, while I knew 0.5.3 compiled on my system before, with libgc from debian sources)
shinohai: though it is available, I'm puzzled. (Your
patch did apply cleanly)
shinohai: Heya spyked, was looking at your
patch last night .... where did you get your w3m source code from if I may ask?
shinohai: !~later tell spyked got a question regarding the w3m
patch when you have a sec.
a111: Logged on 2016-12-23 14:55 mircea_popescu: suppose we had a rule stating that "all patches must include as a comment the
patch upon they are to be applied" ?
phf: shit my emacs greets me with iswitchb-mode is obsolete on boot, if i cared enough i'd
patch it out, but it's a daily meditation on the general level of fuck
phf: mircea_popescu: it's actually a broken
patch (i.e. it was published broken), i need to move it to deprecated, since *-corrected has been published since
trinque: nah don't think he had to
patch phf: but oftentimes when i post a
patch something comes up anyway. like the recent mpi release by asciilifeform is a vpatch, but it lacks a genesis, which breaks all kinds of assumptions (e.g. the tree visualizer wouldn't work at all)
phf: i resent the "sorta works" bit, i've been responsive with any feedback related to log and
patch visualizer. i've not read todays log so maybe i missed how /patches fits into greater scheme of things
phf: mircea_popescu: no, publish meaning put relevant parts into
patch visualizer, i otherwise haven't published anything. log/
patch visualizer is presented as a service, as far as log is concerned the philosophy has been "write your own" and there's not been much interest in the v part until now