1200+ entries in 0.124s
mircea_popescu: nevertheless, you know aforehand, when you sit down to read through a
patch, that you're gonna spend so long with it, and you'll stop when you stop.
mod6: thanks for the update diana_coman. i've been running with that
patch too -- I've had some falling behind I believe not related to his vpatch, and instead related to ssd disk flakyness (as detailed in last month's SoBA).
diana_coman:
http://btcbase.org/log/2017-08-04#1694066 <-- experimental indecent (no ssd, no sata3) node has kept reliably at top for > 2 months after installing asciilifeform's aggressive pushget blocks
patch; conclusion so far: can be indecent IF only aggressive too!
☝︎ lobbes: been thinking through tickerbot design, and seems like the sane thing would be to have Process A (which is an instance of logbot-genesis with "logbot-multiple-channels-corrected"
patch) running that makes changes to a postgresql database.
mircea_popescu: anyway, as to the other one : v is the republican... well many things, but also works as a versioning system. here's a pretty picture to help the notion along :
http://btcbase.org/patches << you can select from the drop menu to the left, see vaqrious trees extant. you can click on any item to see the
patch it represents.
phf: and tbf it was rapidly replaced by quake1, once the engine was released in 99. i'm pretty msu had own port going, because the graybeards (i.e. 22 year old grad students) would sometimes
patch things overnight when we ran into bugs
a111: Logged on 2014-10-24 23:15 asciilifeform: kernel:
patch[28805]: segfault at 0 ip 0000000000403f35 sp 00007fffbc2fc8e0 error 4 in
patch[400000+26000]
phf: mod6: the graph is correct. you have a
patch chain A B C D E, you're trying to apply A B E. E is going to fail because you didn't apply C D
mod6: no! not even using vtronics at all. just a good ole fashion by hand
patch application.
mod6: Then I went ahead and tried to manually
patch these files together, first 'vtools_genesis.vpatch', then 'vtools_vdiff_sha.vpatch', then 'vdiff_sha_fixes_newline_gcc', and this is what I'm seeing:
mod6: Then I went ahead and tried to manually
patch these files together, first 'vtools_genesis.vpatch', then 'vtools_vdiff_sha.vpatch', then 'vdiff_sha_fixes_newline_gcc', and this is what I'm seeing:
mircea_popescu: no, what it should do is yell "alternate paths to press $vtools_fixes_static_tohex.vpatch requirement $x.alloc : $vtools+
patch and $vdiff_sha_fixes_newline_gcc."
mod6: oh, im specifically talking about the
patch set from your latest post.
a111: Logged on 2018-04-06 19:35 hanbot: latest in mp-wp saga: spyked's
patch on vtools let me gpr build the phf's patcher and vdiff, latter of which made a genesis, former of which dies on pressing wiff:
http://p.bvulpes.com/pastes/2IVPp/?raw=true mircea_popescu: i never saw such a
patch (then again i am not a major
patch reader>)
trinque uses ccl elsewhere, would glady sign that
patch phf: it looks like i'm going to wrap up the rest of the "replicate diff/
patch" this week, so that'll also be the time to start adding the clever features
mircea_popescu: yes, the idea was to make a "reorg"
patch separately if you're going to move files about.
mircea_popescu: this is where we admit that while the alternative solution presented passes on technical merits, nevertheless the thing it's an alternative to has much better political support. i ~want~ to require people to say a word about their
patch, for human eyes.
mircea_popescu: asciilifeform basically breaks every
patch up into single-file units ?
mircea_popescu: ah. so then get the whet back and see from there. maybe new vdiff is ready ; if not and you want to march you can apply spyked's
patch on the extant codebase as published by phf, if i understand correctly that should fix your problem. the diffs you produce with the thing thereby compiled will work with later restared vdiff too.
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
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
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
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"
mircea_popescu: trinque seems the logical place this is going is "make comments file addition mandatory for each
patch"
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
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.
trinque: would have to name every
patch that happened to end up a dangling leaf
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.
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.
mircea_popescu: should he spyked make a
patch 2, which changes file b, is that
patch 2 off G or off
patch 1 ?
mircea_popescu: you, phf, made genesis G, with files a, b, c. you then made
patch 1, which changes file a.
mircea_popescu: his
patch is a loose leaf, because it doesn't touch any of the files ?
mircea_popescu: phf do you see the problem spyked's
patch to your v tree encountered ?
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.
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).
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).
☟︎ trinque: douchebag: v-
patch worthy thing?
spyked: so the idea is to keep either vtools_genesis -> vtools_vdiff_sha -> vdiff_sha_fixes_newline_gcc or vtools_genesis -> vdiff_fixes_newline_gcc -> ... patches, but not both at the same time. because in this case v.pl will see that my
patch has two antecedents and will reject it.
trinque: my thinking on the thing is that it's as simple as each
patch introducing a new line in HISTORY that matches the
patch's name.
spyked: thanks mod6. I wonder if it's one of those cases that spawned the discussion which led to the idea of a manifest file. in any case, it looks like the
patch above (vdiff_lib_xalloc_static_xnmalloc) can have multiple children.
spyked: (also, I had to redo the
patch anyway, since I initially used the keccak vdiff; but I'm pretty sure this should be a child of vdiff_fixes_newline_gcc, since the hashes for vtools/lib/xalloc.h match)
a111: Logged on 2018-03-28 20:37 phf: mod6: pressing to different tails should produce alternative builds without any conflicts. but the issue has been discovered, and it requires a
patch. spyked originally found both the problem and the solution
phf: maintaining two separate builds in the same
patch tree is sort of experimental, and i'm happy that it seems to work out of the box
phf: mod6: pressing to different tails should produce alternative builds without any conflicts. but the issue has been discovered, and it requires a
patch. spyked originally found both the problem and the solution
☟︎ phf: yeah, that warning made me
patch and recompile libc 10 years ago, might've been one of the first excursions into pre-tmsr rage holes
phf: spyked: if you sign your
patch, i can include it in the vtools graph, a "collaborative" experience :)
phf: these kind of flags are set by ~xml~ files inside gnat's gprbuild support files, so there can be a general
patch on gnat to do the right thing
douchebag: Apache doesn't - that's why it's called A
patch e
a111: Logged on 2018-03-13 12:59 trinque: I believe it's more or less established by this point that the solution is to have a history file that's edited by patchers if they care that their
patch isn't abandoned.
trinque: I believe it's more or less established by this point that the solution is to have a history file that's edited by patchers if they care that their
patch isn't abandoned.
☟︎ a111: Logged on 2018-01-23 14:28 mircea_popescu: esthlos it is not standard procedure ; the emerging consensus is to have a dedicated philosophy file which a) all patches must touch (by protocol) ; b) contains comments as to the patcher's state of mind and c) contains one line per
patch uniquely identifying it, machine generated. the format's not fixed yet, but as phf is working on a new proper vdiff it's probably going to coalesce around a variant of whatever he uses.
ave1: Well, maybe not so easy, I will publish
patch (but probably next week)
diana_coman: phf, any bitrate above 1600 will correctly fail there since bitrate cannot be more than the total length of state (and that's 1600 unless you change the knobs); this being said, there IS an error too and it's one of those that show I need to sleep more: I got ToPos and FromPos flipped around and failed to notice it ...; so big thank you for testing this! correction,
patch & post coming later today
mod6: Thanks for digging that up phf! archive.is seems to have trouble pulling the
patch directly from shithub. I've grabbed it and posted it myself for the ages:
http://archive.is/1w3Kx phf: Subject: [
PATCH] Resolves issue #922 - "wallet passphrase timeout of several
phf: i have a btcbase based test harnes, but it of course also didn't catch the issue, because it doesn't know about `\ No newline ...' in band thing either. it treats that line as a textual prelude to the next hunk which is a valid
patch format
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: also, building further the (summary) testing infrastructure currently provided is imo a legitimate way to
patch upon the tree once complete ; and such work will prolly get sealed.
BingoBoingo: Well it appears to be a rebreak of an area that broke when I was younger. Had some bonded ceramic
patch and a chunk of that still seems attached.
BingoBoingo: Anyways
patch might be to introduce a bindip= param in the .config
ben_vulpes: asciilifeform: gonna ship another box with the timing
patch from aeons ago, sync to completion and then post
ben_vulpes: unrelatedly, one of the boxes flying with me has synced with my max aggression
patch atop asciilifeform's aggressive pushgetblocks has climbed to 308K in 4 days
mp_en_viaje: ave1, would you consider gutting that entire class as a
patch ? i have nfi why a "kses" bs is even needed. seems a case of giraffe's jugular.
mircea_popescu: obviously one could
patch the eucrypt to work on his box if for some reason he wants to (though i can't imagine who'd be running eulora client of ppc machine, but anyways).
phf: mircea_popescu: our current strategy with architecture support has been "it works on my machine, but if you want it to work on your machine submit a vpatch", and it's been pretty consistently applied (e.g. my openbsd
patch that's been floating independently, despite never getting vpatched).