1800+ entries in 0.254s
Reuel: When I am looking at the TRB site seals, I see more than one for each
patch, does that mean code has been reviewed?
pete_dushenski: my own recent efforts at coding are going less productively. trying to implement polarbeard's 'getpeerinfo'
patch and can't even get trb to show the option on the help menu nevermind implement the functionality
BingoBoingo: phf: Or a chance for pete to code and make a
patch from 0.7-ish
ben_vulpes: trinque: i don't have the appetite for the protocol-level
patch atm
ben_vulpes: so the
patch is currently sitting in logbot code
walter_: I'm afraid I cannot
patch a PHP website. I can only suggest that it gains the ability to respond Last-Modified, perhaps at the cost of removing the dynamic section (should be fine as a separate page)
mircea_popescu: i dunno. in truth the maintenance of mp-wp is a bit in the air right now ; but if you want to make a
patch by all means.
ben_vulpes: moreover there is no harm in bringing a
patch for discussion, and all of this durm and strang will discourage "patches alf doesn't like" even if just in the patcher's mind
trinque: the guy already said ok to shipping a txn maker with the
patch!!
trinque: it'd probably be better to be hollering at a
patch than all this
davout: asciilifeform: well for example, the "remove signmessage and verifymessage"
patch could very well be considered ready for production, it cuts something, not something anyone sane would actually depend on
trinque: I can't find davout saying he refused to provide such a thing in his
patch ben_vulpes: davout: why would you even consider releasing a
patch that leaves trb unable to cook and transmit transactions? keep it on your table where it's useful to you.
davout: getting a feel for the whole
patch authoring process without touching anything very sensitive
trinque: aside from rationale given in history.txt, an author is giving his
patch "without reservation"
trinque: and then when I shit, nobody seals my
patch, and eventually I'm known as a floor shitter, and nobody regards my seal
trinque: could always leave an expository comment in a file in your
patch, but I don't know that it holds that "found item" is less the v-author's fault
adlai: the bug is calling it a 'root', it's actually a leaf. the "root" of the relevant
patch tree is the node you're trying to press. the "second root" which makes less sense (but should still not eggog) is "press two nodes"
mircea_popescu: asciilifeform an item can exist in two copies : as its independent tree AND ALSO as a
patch imported in a project.
phf: also the sbcl os
patch, applies cleanly against sbcl_0_9_14, but is missing the forth bootstrap that nyef's talking about
a111: Logged on 2017-01-14 01:07 mircea_popescu: a
patch can only apply if ALL of its antecedents are present ; not if ANY of its antecedents are present
trinque: certainly in the case of both portage and bsd ports, "I got my
patch past one community organizer idiot" is no standard of merit
a111: Logged on 2017-01-14 01:07 mircea_popescu: a
patch can only apply if ALL of its antecedents are present ; not if ANY of its antecedents are present
mod6: <+mircea_popescu> a
patch can only apply if ALL of its antecedents are present ; not if ANY of its antecedents are present << this.
mircea_popescu: a
patch can only apply if ALL of its antecedents are present ; not if ANY of its antecedents are present
☟︎☟︎ mircea_popescu: theoretically the
patch you indicate only depends on zap_showmyip
phf: i feel like you talked about the
patch before, what does it do?
a111: Logged on 2017-01-08 07:59 ben_vulpes: so duh, vdiff does not guarantee patches will be sensible in a v tree, and it is incumbent upon a
patch-grinder to ensure their patches actually apply cleanly.
ben_vulpes: so duh, vdiff does not guarantee patches will be sensible in a v tree, and it is incumbent upon a
patch-grinder to ensure their patches actually apply cleanly.
☟︎ ben_vulpes: now, the patches apply cleanly if the
patch utility is not passed -p1, but this makes for much floppiness.
ben_vulpes: mircea_popescu:
patch says what antecedent file hashes it stemmed from, no?
adlai should probably provide an example instead of babbling, but: it's possible to produce distinct antecedents for the same
patch gabriel_laddel_p: adlai: ^ another thing you can do. The
patch to fix CL-FTP is in the logs.
trinque: ben_vulpes: so sounds like we should still consider doing the
patch for raw messages, such that we don't have to build this atop out-of-date logbot-service
ben_vulpes: let's say 2 btc, and that'll cover the
patch to record all protocol lines as well
ben_vulpes: trinque: any action on recording all message lines or is that a
patch i should cook?
mircea_popescu: in practice i come to understand now, after thousands of articles / years blogging, that in fact the frontend to a blog should really be as close to a... vdiff
patch! as practicable.
ben_vulpes: notion, iirc, was to make a "release" vpatch that added *something* to *every file in the tree* to neck the
patch graph down
mircea_popescu: but as to the other thing, i'm not sure i follow. your v inverted
patch flow ?
ben_vulpes: so i cracked everything open, and sure enough the
patch in question doesn't touch any files touched in the makefiles vpatch
mircea_popescu: you put them in the new file. they show up in the
patch ben_vulpes: i did not realize that the
patch could contain comments that do not affect its output, is that so?
mircea_popescu: ben_vulpes slowly moving towards literate code. here's a thought... why not put the comments straight into the
patch ?
a111: Logged on 2017-01-04 10:33 davout: i don't really see asciilifeform's issue with large 'formatting' patches, as long as it can be mechanically established that the changes a
patch brings do not change any of the code semantics there should be no problem with arbitrarily large patches
davout: i don't really see asciilifeform's issue with large 'formatting' patches, as long as it can be mechanically established that the changes a
patch brings do not change any of the code semantics there should be no problem with arbitrarily large patches
☟︎ mircea_popescu: asciilifeform i dunno, one huge insert
patch is still pretty dubious as far as paternity goes.
ben_vulpes: imma finish this phf-inspired
patch and fix the miner
a111: Logged on 2016-12-31 04:50 asciilifeform: 'The ability to limit concurrent coredumps allows dumping core to be safely enabled in these situations without affecting responsiveness of the system as a whole. I have several servers running with this
patch applied (actually backported to v2.6.26) and it has allowed me to deal successfully with the situation described above.'
a111: Logged on 2016-12-30 05:40 phf: so if you were to produce a
patch with a/old-veh.lisp and b/veh.lisp. existing vtrons will happily press it, though it's a total clusterfuck
ben_vulpes: one can
patch an empty directory with an arbitrary
patch and extract the filenames
patch wanted to hit
phf: ben_vulpes: you mean like ~parse~ the output of
patch?
ben_vulpes: wait phf hang on no i don't think i'm going to do the largest common, i think i'm just going to use the output of
patch to figure out what was actually patched
phf: i noticed that btcbase supports filenames with spaces in them: if you start a filename with " it will read until a closing ". i have no idea where i got this from, because gnu diff/
patch don't support spaces in names.
phf: huh, apparently plan 9's diff/
patch doesn't even implement unified diff format
a111: Logged on 2016-06-20 04:23 phf: which is handy if you're using something else to produce the
patch, or if you need to use a non-trivial diff command. for example i sometimes need to exclude files from diffing, so a command might look like diff -x foo -x bar -x qux -ruN a b | grep -v '^Binary files ' | vdiff > foo.vpatch
ben_vulpes: phf: i actually can't get
patch c/old.lisp and d/veh.lisp to apply derp.vpatch
phf: so if you were to produce a
patch with a/old-veh.lisp and b/veh.lisp. existing vtrons will happily press it, though it's a total clusterfuck
☟︎ phf:
patch/diff lets you have a
patch with --- foo +++ bar in which case it seems to ~check if foo exists, then try and press against foo, otherwise press against bar~
phf: but i'm starting to think it's an overkill anyway, because it doesn't accommodate for all possible insane
patch inputs.
phf: actually
patch seems to do ... something magical
trinque:
patch will ignore the number of levels you specified with -p
ben_vulpes: phf:
patch will apply something cleanly with mismatched depths, won't it?
ben_vulpes: the third approach is to apply each
patch to an empty directory and determine what files would have been patched, had it applied cleanly.
ben_vulpes: b) when working through the list of each
patch's children, search through the list of patched files until the patched filepath is a subsequence of the filename as recorded in the vpatch
ben_vulpes: a) capture output of `
patch' to determine which files were patched
mircea_popescu: phf i guess we will sooner or later have to actually formulate the
patch format yeah.
ben_vulpes: asciilifeform: pedantically, each
patch then produces semantically new program?
phf: fwiw
patch format is super promisetronic. it's something along the lines of "command that was used to produce the hunks\nhunks..."
a111: Logged on 2016-12-29 23:32 ben_vulpes:
http://btcbase.org/log/2016-12-28#1591573 << the diff line is distinct from the --- / +++ lines, does one ever see a
patch file where the files compared aren't prefixed with a/ or b/ ?