log☇︎
67 entries in 0.422s
mircea_popescu: but in general, if you can't be arsed to read my blog, you're cordially invited to get the fuck lost and in no case pretend like you're using my patches.
asciilifeform: diana_coman: you in fact read & signed the patches of all items i touched that were put to use in smg. so per mp_en_viaje's philosophy, that makes you equal to the orig author. if the item you signed indeed was product of artful sabotage, you an' i are equally answerable .
Mocky: http://btcbase.org/log/2019-05-03#1911019 << I stated my assumption, for confirmation, that you can't press to both heads, and you answered with "why not?", and I followed up with 'what would that even look like?' I stated in two different ways that I'm talking about sibling patches with the same parent, not 1->2->3. did you even read what i wrote? ☝︎
asciilifeform: re config txt parsers, i dun grasp why it would need heapism, rather than simple http://btcbase.org/patches/ffa_ch18_subroutines.kv/tree/ffa/ffacalc/ffa_calc.adb#L99 -style offsets into the read-only text
mircea_popescu: cuz we don't have the manpower to write ~general purpose fs~. we don't even have the manpower to write fucking ~narrow purpose fs~, for lack of the manpower to fucking read patches before we mis-add numbers!
asciilifeform: bvt: didja get a chance to read my udp lib ? the structs thing is the reason for http://btcbase.org/patches/udp_errata_asciilifeform/tree/udp/libudp/unix_udp.c .
phf: right vpatch applies 'diff -ruN' style patches exactly. it also keeps track of both the hash of the patched file and the hash of the result state as it's reading/patching (there's no double read happening), and errors out if either fails to match the hashes in the header
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
trinque: spyked: so sounds like you're going to patch your items (in as many small, easy to read patches as possible) atop ircbot?
asciilifeform: he didn't seem to grasp the notion that the patches are meant to be read and understood.
mircea_popescu: the idea with it is that patches must be a) clearly assigned to a responsible key and b) well read. actually, not putatively a la ers's trillion dead fish eyes.
ben_vulpes: makes for a neat delineation between patches baked in an angry stew and those selfsame patches read in the cold light of morning and possibly even reground by others as "this works, and i propose it for inclusion in the trunk"
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.
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
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
pete_dushenski: asciilifeform: i agree. but user can 'read tin' on which there is a label, or just check 'patches' folder once built
ben_vulpes: ascii_rear: i recall reading in the log that your vtron's implicit pressing behavior is asciibetical up to indicated head, but i'm having trouble reconciling that with other reqs i once read: that vs press longest chain, and also that vs press all usable patches. would that accurately modify to 'longest chain up to indicated head'?
mircea_popescu: regrind, to be perfectly clear, is the act of making a tree out of patches instead of keeping them linear. this is a known efficiency-of-search trope, and i shouldn't have to explain how distributing the patches out saves work when i'm pressing 3 years later and want to read the whole string of patches from genesis.
asciilifeform: it needs to frag into a dozen patches with separation of concerns before i will bother to read it.
punkman: ben_vulpes: would ya read ninjashogun's patches?
asciilifeform: anybody at all can write patches. just like anyone could write a speech for obamitler to read. now to have him actually read it - is a different matter
mircea_popescu: (you have to understand - in principle, the extra maintenance is a mark of both fit in headness and "we really read these patches")
pete_dushenski: asciilifeform: i read the patches, though admittedly little code. i'm probably not even competent enough to need gas mask though, so no worries. amor fati.
ascii_butugychag: these, ideally, will NOT always be the same, i keep trying to encourage folks to read and sign MY patches (and that of others)
assbot: Logged on 08-09-2015 03:03:42; pete_dushenski: i also read that microshit will no longer be detailing what's in its patches. just trust ! (tm)
pete_dushenski: i also read that microshit will no longer be detailing what's in its patches. just trust ! (tm) ☟︎
assbot: Logged on 22-10-2014 18:52:16; mircea_popescu: <asciilifeform> how to do signed commits << the barbarian way. everyone who read a patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball. << i think this is exactly how it should go.
assbot: Logged on 31-08-2015 08:30:08; trinque: neat that when looking at the "flow" of patches you can tell who has read the logs of the project by the signatures.
trinque: neat that when looking at the "flow" of patches you can tell who has read the logs of the project by the signatures. ☟︎
asciilifeform: ;;later tell mod6 http://log.bitcoin-assets.com/?date=23-08-2015#1249381 << this is a potentially catastrophic misuse of the thing. if you glom the patches together, i can't sigverify'em, can't (easily) match them against earlier publications of same, and most of all - can't read it worth a damn ☝︎
ascii_field: can't read patches now ?
BingoBoingo: It is hard to say what anyone counts on. It is also hard to say how well I actually understand the cpp I attempt a performance of reading. And so Imma keep chopping at this for a while to get more familiar with the code. main.cpp is already ~1000 loc shorter than 0.7.2 release, perhaps more. I figure Derp on 0.7, read 0.5.x and patches and maybe at some point I will understand
trinque: could just read all the patches in that script you did
hanbot: mod6> hanbot: so, this might help you, it's worth a read through anyway -- it's a script that I created to pull down v0.5.3.1-RELEASE, and then add ascii's recent patches up through verifyall [ read the script for all that are applied ]: http://dpaste.com/23VKWD8.txt << neat deal on this & the latter scripts. my mission is to build based on the inferred instructions here tho': http://therealbitcoin.org/ml/btc-dev/2015-June/000102.html . is th
mod6: hanbot: so, this might help you, it's worth a read through anyway -- it's a script that I created to pull down v0.5.3.1-RELEASE, and then add ascii's recent patches up through verifyall [ read the script for all that are applied ]: http://dpaste.com/23VKWD8.txt
assbot: [BTC-dev] Recent Patches Read & Signed : WARNING! ... ( http://bit.ly/1COXfs4 )
assbot: Logged on 19-07-2015 11:37:45; punkman: fwiw, I've read the patches and it all seems good. I only have reservations about the 2 orphanage burning patches
punkman: fwiw, I've read the patches and it all seems good. I only have reservations about the 2 orphanage burning patches ☟︎
mod6: I still do need to sign that I've read the patches, might get to that tonight yet. Or tomorrow. We'll see how it goes.
mod6: I'll make an effort this week to sign the patches I've read and understand, even if still experimental at this time.
mod6: asciilifeform: testnet patch looks good at first read-through. i'll apply these to my sources bases (on top of stator + patches { dump/eat block }) and continue testing. i'll also add these to my build-with-patches guide.
mod6: <+ascii_field> mod6, ben_vulpes, mircea_popescu, et al: so far, no one has signed any of my patches... am i to conclude that nobody reads these things? << I've read them all (except the 2 you just posted, about to read here in a moment) but I don't sign patches until release is prepared.
asciilifeform: BingoBoingo: i normally post patches after i read five times or so, and test them (to the point where 150,000+ blocks are pulled)
assbot: Logged on 03-07-2015 19:44:53; phf: mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the n
phf: mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the next email ☟︎
mod6: ex: are you trying to patch v0.5.3 to get to v0.5.3.1? (You can just download the release tarball). Are you trying to patch v0.5.3.1-RELEASE with alf's patches? (must read emails to figure out the deps, OR you can just build the stator which includes all of alf's patches with exception of dumpblock & eatblock), those must be patched post extraction of the stator tarball -- of which im actually testing now.
mod6: So a bunch have patches have been submitted in the last month. A read through each of the emails is kindof required at this point because they all have specific instructions and dependantcies.
mod6: i've read the patches and ben's review on his blog. i'll be writing up a summary of my own in the SoBA at the end of the month.
assbot: Logged on 21-06-2015 01:43:37; asciilifeform: ben_vulpes, mod6, mircea_popescu, et al: you now have homework. it being, to read & actually grok the sequence of 4 'dns thermonuke' patches.
asciilifeform: ben_vulpes, mod6, mircea_popescu, et al: you now have homework. it being, to read & actually grok the sequence of 4 'dns thermonuke' patches. ☟︎
assbot: Logged on 18-06-2015 14:32:03; asciilifeform: incidentally, i've asked before and will ask again now - who has read my patches ?
asciilifeform: incidentally, i've asked before and will ask again now - who has read my patches ? ☟︎
asciilifeform: 'As evidence, consider that in version 5.5.4 of the AirMax firmware, the kernel was modified such that the MTD partitions would be read only, however this change cannot be found in the corresponding kernel patches or source.'
asciilifeform: nah he read the patches and upchucked
Chillum: It was recommended to me by two people here before I read the patches
Chillum: read the patches before running it
assbot: Logged on 12-03-2015 12:03:56; Adlai: sure, one of my big struggles lately is pushing myself to read slime source in the hope of contributing patches, rather than bemoaning that the bugs lurk in elisp and leaving it at that
Adlai: sure, one of my big struggles lately is pushing myself to read slime source in the hope of contributing patches, rather than bemoaning that the bugs lurk in elisp and leaving it at that ☟︎
nubbins`: if that doesn't encourage log readers to actually read and absorb the fuckin patches
decimation: Luke-Jr: the idea is that signed patches would be read by people, who would then sign
asciilifeform: anyone willing to review patches - read, ponder, sign. jurov can dump it all in turdatron later.
asciilifeform: ben_vulpes: not only read patches. judge.
ben_vulpes: asciilifeform: i do believe that someone in the wot must read patches, yes.
ben_vulpes: <asciilifeform> jurov: also at some point we ought to have people sign off on others' patches, once they read << would a new tarball with sig attached suffice?
asciilifeform: jurov: also at some point we ought to have people sign off on others' patches, once they read
mircea_popescu: <asciilifeform> how to do signed commits << the barbarian way. everyone who read a patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball. << i think this is exactly how it should go. ☟︎
asciilifeform: how to do signed commits << the barbarian way. everyone who read a patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball.