log☇︎
1400+ entries in 0.143s
phf: relevant patch https://github.com/sbcl/sbcl/commit/6e02a5455aeef5a4642a2334348544c1f19775ad#diff-912df0bf4505a2db68a4b714e475e225R385
trinque: anyhow I wrote it; ben_vulpes added a patch.
phf: please do, it would be useful as a reference, but also for me specifically: btcbase.org/patch is written in common lisp, but it can only eat vpatches, not spit them out, so a mcilroy would be a solid addition
phf: what you have on top of original paper is unified diff format and the handling of multiple files in a single patch. (that's where you run into the bulk of extra code; things like sorting directory is simply unpleasant to do in C)
diana_coman: I've updated the reference shelf phf, maybe you are missing the previous patch? http://www.dianacoman.com/reference-code-shelf/
mircea_popescu: there is no difference between a patch unsigned and another patch unsigned, much like there's no difference between a nobody "gerald davis" and the exact same nobody "gerard david"
asciilifeform: phf: imho more correct pill would be to patch e.g. znc. or better still, the client, to warn of splits
asciilifeform: as for nodes at the 'tip', the path of chinesium through layers of prb is a lottery, and i suspect that attempting to measure the effect of a trb patch on said behaviour is doomed to astrologize over noise
a111: Logged on 2017-12-27 05:36 ben_vulpes: asciilifeform: let me know if your aggression patch was enough to stay at the tip of the chain, as it wasn't for my node.
asciilifeform: http://btcbase.org/log/2017-12-27#1759152 << not up to 'tip' yet. it did walk 3000+ blox in the night, however. which before patch sometimes took week+. ☝︎
ben_vulpes: asciilifeform: let me know if your aggression patch was enough to stay at the tip of the chain, as it wasn't for my node. ☟︎
trinque: can have a tool to edit it sure, but then that's the file that's being edited no matter what else is edited, and there's a coherent history based primarily upon a list denoting what's considered a thing at time of patch
ben_vulpes: oh you said "patch # and the codebase hash is..."
mircea_popescu envisaged the genesis.manifest as wholly mechanical item, just a patch-per-line count of patches, no space to adlib.
a111: Logged on 2017-12-27 02:03 asciilifeform: or, on other end of the possible, a vtron that somehow understands that a call of foo necessarily depends on the patch that birthed foo... and requires disambiguation only if >1 foo exists in the tree
trinque: manifest can be the patch header nearly as is
mircea_popescu: how about a convention whereby all new genesises must contain a manifest.genesis file, which file will be constantly patched on each patchj, no exceptions, by adding a line which reads : "This is patch #x and the codebase hash is blabla". ☟︎
mircea_popescu: anyway, and the proposed fix for this is to actually add a hash for the whole filebase in each patch ?
mircea_popescu: the ~only way to establish a lineage among these two so a3` is properly a4 is if the patch is spuriously modified to add a "hey v sucks" comment in Fj
mircea_popescu: so the idea is, you got up to a2, which consists of files F1... Fi ; now one patch call it a3 touches file Fj, and another patch call it a3` touches file Fk
mircea_popescu: if the patch tree goes a1->a2->a3/a3` your position is now to choose which of a3 or a3` counts, and which doesn't count. the discarded one may be scavenged for useful content, but it will never be a proper patch.
mircea_popescu: http://btcbase.org/log/2017-12-27#1758965 << this is exactly what's discussed in http://btcbase.org/log/2017-12-26#1758702 : only way to recover code in a heretic patch (ie, one you're not pressing upon) is to literally lift it and include it. ☝︎☝︎
mircea_popescu: trinque there's an ambiguity here i'm possibly responsible for though not intended : to "regrind", ie to take a pile of patches and make them into one single patch ; as opposed to re-genesis, which is what happened with eg mpi.
trinque: specifically what people have been doing when "regrinding" is adding comments to unrelated files and thus including their patch in the tree.
a111: Logged on 2017-12-27 03:43 mircea_popescu: let me put it this way, maybe resolves problem : v unpermits a specific kind of hack within the purview of this discussion, wherein one tries to design after the fact. correctly designed items will have the larger bits (by footprint) earlier in the patch tree ; and fray out correctly. github-style nonsensica commonly attempts to discover that "hey, this johnny come lately item should have been an evie-comes-early MODULE, let'
mircea_popescu: now, the v doctrine as it stands right now, both on logs and actual precedent, at least as far as i understand it (but this is vacuous both as a representation and as a history, as most important questions haven't yet been seriously tested) -- is that Z is right to simply sign a patch on B-genesis ;
trinque: current V requires that a file actually got edited to be an antecedent, but C editing B's work does not mean he's discarding A's, and A regrinding his patch means editing something edited in C to get in
trinque: takes what constitutes context for the patch and puts it in the hand of the operator
trinque: right, so if we could do this, name unchanged antecedents that are required, could merge A's log patch and B's db patch in C's subsequent patch without having to manually edit A's or B's
mircea_popescu: so for instance, "genesis a proper db ; then patch in three different branches for the three different types of node envisaged" doesn't seem on the face problematic.
mircea_popescu: let me put it this way, maybe resolves problem : v unpermits a specific kind of hack within the purview of this discussion, wherein one tries to design after the fact. correctly designed items will have the larger bits (by footprint) earlier in the patch tree ; and fray out correctly. github-style nonsensica commonly attempts to discover that "hey, this johnny come lately item should have been an evie-comes-early MODULE, let' ☟︎
asciilifeform: or, on other end of the possible, a vtron that somehow understands that a call of foo necessarily depends on the patch that birthed foo... and requires disambiguation only if >1 foo exists in the tree ☟︎
trinque: to my mind the hash is currently putting too narrow a constraint on the context within which the current patch is to be applied, where we could broaden the context at no detrimental, and possibly beneficial cost
asciilifeform: and yes every patch oughta stand as a leaf, pressable to .
trinque: should someone pressing think he has a coherent whole after pressing any patch? if not why?
asciilifeform: every time think of a possible change : think, does this take it in the direction of heathendom ? can it still make a patch like http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks , where it is hammer-in-your-face-obvious to the reader that every single fucking line does ?
a111: Logged on 2017-12-26 21:42 phf: we also at some point had a thread, where i believe ascii but also others were leaning towards the idea of a single file vpatches (i.e. that a vpatch should only ever contain hunks for a single file). i'm starting to think that multi-file solutions in general are a hack ("we can't fit the entire compilation in memory"), but then i've been looking at TeX on one hand, and the "millions of support files" in diff/patch on the other
asciilifeform: http://btcbase.org/log/2017-12-26#1758781 << this only oughta be done in 2 situations -- 'releases' , as discussed by mod6 et al ; and to avoid fuckuppy as seen in orig shiva patch, where there was a logical dependence , but not a vtronic one , b/w shiva-part1 and -part2 ☝︎
a111: Logged on 2017-12-26 21:42 ben_vulpes: phf: this exposes another problem: in ideal vtronics it is an illegal operation to press to multiple leaves at the same tree level, which is the only way to have a codebase against which to create a makefiles-type patch that ties multiple patches together
asciilifeform: http://btcbase.org/log/2017-12-26#1758789 << ben_vulpes if you look at phf's patch tree graphical viewer, you will realize how asciilifeform solved this problem ☝︎
a111: Logged on 2017-12-26 23:02 mircea_popescu: http://btcbase.org/log/2017-12-26#1758790 << especially in the light of 1. move/rename 2. edit double-patch method this seems more and more like the right thing ; but then again what to do of regrinds ? regrind should ideally be "one patch out of many"
asciilifeform: http://btcbase.org/log/2017-12-26#1758834 << it is not clear to me why the current scheme ( leaving aside the idiocies of unix diff/patch, in particular the file moves thing ) is not satisfactory. i dun subscribe to the 'force beauty through mechanism' school of thought. it is the job of the patch author to make it behave acceptably in the target vtree, ~before~ releasing. and failures are of the author, not of the mechanicals. ☝︎
a111: Logged on 2017-12-26 21:42 phf: we also at some point had a thread, where i believe ascii but also others were leaning towards the idea of a single file vpatches (i.e. that a vpatch should only ever contain hunks for a single file). i'm starting to think that multi-file solutions in general are a hack ("we can't fit the entire compilation in memory"), but then i've been looking at TeX on one hand, and the "millions of support files" in diff/patch on the other
mircea_popescu: http://btcbase.org/log/2017-12-26#1758790 << especially in the light of 1. move/rename 2. edit double-patch method this seems more and more like the right thing ; but then again what to do of regrinds ? regrind should ideally be "one patch out of many" ☝︎☟︎
phf: we also at some point had a thread, where i believe ascii but also others were leaning towards the idea of a single file vpatches (i.e. that a vpatch should only ever contain hunks for a single file). i'm starting to think that multi-file solutions in general are a hack ("we can't fit the entire compilation in memory"), but then i've been looking at TeX on one hand, and the "millions of support files" in diff/patch on the other ☟︎☟︎☟︎
ben_vulpes: phf: this exposes another problem: in ideal vtronics it is an illegal operation to press to multiple leaves at the same tree level, which is the only way to have a codebase against which to create a makefiles-type patch that ties multiple patches together ☟︎
trinque: "whole patch must be meaningful"
a111: Logged on 2017-12-26 17:52 ben_vulpes: http://btcbase.org/log/2017-12-26#1758614 << consider a genesis, a and b patchset where a and b don't touch the same files. if i press to b, write a c that descends from b, it will not have a as an antecedent. when you say "modify the filebase into the shape that you want it to be", do you mean include the changes of a in the c patch?
a111: Logged on 2017-12-26 17:52 ben_vulpes: http://btcbase.org/log/2017-12-26#1758614 << consider a genesis, a and b patchset where a and b don't touch the same files. if i press to b, write a c that descends from b, it will not have a as an antecedent. when you say "modify the filebase into the shape that you want it to be", do you mean include the changes of a in the c patch?
a111: Logged on 2017-12-26 01:06 mircea_popescu: http://btcbase.org/log/2017-12-25#1758589 << i don't get what the problem is. write a patch that modifies the filebase into the shape you want it to be. what's the problem ?
ben_vulpes: http://btcbase.org/log/2017-12-26#1758614 << consider a genesis, a and b patchset where a and b don't touch the same files. if i press to b, write a c that descends from b, it will not have a as an antecedent. when you say "modify the filebase into the shape that you want it to be", do you mean include the changes of a in the c patch? ☝︎☟︎☟︎
mircea_popescu: http://btcbase.org/log/2017-12-25#1758589 << i don't get what the problem is. write a patch that modifies the filebase into the shape you want it to be. what's the problem ? ☝︎☟︎
ben_vulpes: let's try again: i misnamed the seal for the truncation patch, must have "ben_vulpes" in the last period-delimited field of the seal name instead of "ben_vules"
a111: Logged on 2017-12-24 20:35 ben_vulpes: http://btc.yt/lxr/satoshi/source/src/db.cpp#0837 << any reason for this to not come out with the truncation patch?
ben_vulpes running truncation patch, will get back in the saddle after misc duties of parenting while impoverished
ben_vulpes: http://btc.yt/lxr/satoshi/source/src/db.cpp#0837 << any reason for this to not come out with the truncation patch? ☟︎
asciilifeform: ben_vulpes: consider making a patch ?
asciilifeform: oooh i think i see why. ben_vulpes's 'multiple-channels' patch mutilated it
mircea_popescu: asciilifeform let's model this. let "patch" be a bitfield ; let wot be comprised of l1...ln.
mircea_popescu: nobody can know WHO truly authored a patch. just what set of the signatories signed it that they're willing to share with him
mircea_popescu: in point of fact, the replacement-pistols will simply be a patch set.
asciilifeform: and speaking of this, can haz patch that logs ~from what kind of node~ each ACCEPTED block came ? ( or do i have to do errything meself..? )
shinohai: I fully intend to report on my results with patch after all this holiday nonsense is over.
asciilifeform: in other noose, 'aggression' patch is apparently ~the~ pill against what ailed zoolag; 482253 -> 484621 in ~12hr , previously that was 3-4 day's worth
a111: Logged on 2017-12-24 06:43 phf: asciilifeform: your blog renderer throws a space after < in -- Less-Than part (which is not in the patch)
phf: asciilifeform: your blog renderer throws a space after < in -- Less-Than part (which is not in the patch) ☟︎
ben_vulpes: will probably use asciilifeform's aggressive patch, as my logs are full of 70000-series nodes advertising sexily high tips
trinque: asciilifeform: sounds like a neato patch
asciilifeform: this is testable empirically; like-so: any N trb nodes built with 'aggression' patch above, and linked via 'wires', should never fall out of height-sync with one another by more than a coupla blox. at any point.
asciilifeform: !~later tell trinque where didja get the log-timestamps in your trb ? ( which patch pressed to ? )
asciilifeform: and speaking of hasty and untested , asciilifeform has a 'aggressive sync mode' trb patch, which will need a proper differential test
a111: Logged on 2017-12-22 01:59 esthlos: by selecting which keys are acceptable, we get a subsequence of acceptable diffs, which are then used to patch the source
a111: Logged on 2017-12-21 18:39 trinque: I will post an experimental patch soon, when fit for other hands
asciilifeform: so to expand : we take each 'out' , and follow it back as far as we can. ( when we meet a nil, we stop recursing, in that branch. ) when we meet a non-nil, recurse. when the recursion unwinds, the actual unixpatch (or phfian patch, for that matter) util invocations, happen.
asciilifeform: ... 1) to take the 'out' hashes of the ~one~, specific, patch being 'pressed to'
esthlos: by selecting which keys are acceptable, we get a subsequence of acceptable diffs, which are then used to patch the source ☟︎
asciilifeform: diana_coman: the v99 behaviour is the correct one : pressing 'siblings' automagically, is a mistake; if you want the contents of both 'siblings', you oughta have a 'unifier' patch that pulls both in.
trinque: I will post an experimental patch soon, when fit for other hands ☟︎
trinque: nah, mempool cut can be a separate patch
trinque: http://btcbase.org/log/2017-12-21#1756072 << I have already split the wallet from trb in a patch I'm testing. ☝︎
trinque: asciilifeform: I don't blame the patch, only "now I have an observation which suggests touch the knob"
asciilifeform: incidentally when i wrote the versionknob patch, i did not expect that everyone here will run with ~same~ , default ver
asciilifeform: another patch experiment whose time imho has come, is 'prod' rpc command : trigger the boot sync behaviour at arbitrary time.
asciilifeform: needs a patch.
asciilifeform: one useful item would be a 'from whom this came' log prefixer patch
a111: Logged on 2017-12-21 05:20 trinque: the version number appears to be a factor which ends up isolating trb nodes, hypothesis being that the version number being set high invites nodes to insult the malleus patch.
trinque: the version number appears to be a factor which ends up isolating trb nodes, hypothesis being that the version number being set high invites nodes to insult the malleus patch. ☟︎
a111: Logged on 2017-08-06 03:43 asciilifeform: my suspicion is that the bdb locks patch somehow has no effect when bdb built on netbsd
mircea_popescu: phf was your idea that "well maybe you just don't have a very clear picture of what x was in the first place, gotta press to it" ? ie, accumulating mental errors over the patch flow to GET TO x ?
mircea_popescu: how do you go from state to state other than through a diff/patch ?
mircea_popescu: but the idea is, getting an automated patch process going may throw a different light on this whole thing and turn out most informative.
mircea_popescu: guy could actually publish the item as a succession of patches, and speaking of this : hey trinque, could you be enticed to actually genesis that item, and patch it weekly ?
mircea_popescu: would you say graph as extant on wot.deedbot is not patch-ready ?
mircea_popescu: nobody will EVER find themselves in the situation of BOTH a) hurr durr, i am at leisure now let me make a patch and b) o noes, i am in distress now, can not run basic machinery.
mircea_popescu: anyway, this is the important, v-powered realisation here : there can NOT BE such a thing as bit-ambiguity in a source. if "this bit being either set or null has no effect" you have a problem, which must be addressed. because it sure as fuck isn't acceptabru to read diffs of style in a patch. patches are for substantive change.
asciilifeform: a patch either applies cleanly or something is Very Wrong
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
mircea_popescu: that said, a gmp version pushed out as a patch on mpi might not be entirely without merit.
mircea_popescu: esthlos i'd love for you to be able to jump straight into this ; however there's some groundwork to be laid. look into the V system, because ideally you'd be presenting the finished item as a patch on diana's eucrypt lib. and asciilifeform is working on and publishing a final FFA which is what we intend to use here.
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!