2500+ entries in 0.253s
mircea_popescu: just, if you want to add a
patch, should be able to dump it as dpaste also.
☟︎ ben_vulpes: a full sync of each bitcoind produced by each
patch sent to the ml
ben_vulpes: i shut the jenkins down because full syncs of each
patch was prohibitively resource and time intensive and parallelized poorly
mod6: and... its maybe slightly different since the first
patch was inclued in the first release.
mod6: and i'll also have to "re-grind" my high/low S
patch mod6: <+pete_dushenski> ver 99999 is fine by me << yeah, this is fine. but the fact that it doesn't do what it should do isn't. i'll pull the
patch tomorrow.
ascii_rear: but, 1) there is a skull on the
patch for a reason 2) there is not actually an alternative to tinyscheme.
phf: i pressed it programmatically, without "
patch" utility, before leaving home, so didnt have time to test it
ben_vulpes: first: node.js. second: "naw, vpatches are for faggots". third: 2.5kloc
patch degendering reference implementation log statements.
shinohai: I know the
patch applied, because bitcoind -? shows it as an option
assbot: Logged on 21-01-2016 15:48:48; asciilifeform: mod6, shinohai: the version string
patch works. BUT you will always see the default version in the boot log!! because said printf ~precedes~ the setting of the custom string. this may explain shinohai's confusion.
pete_dushenski: mod6: i have a question about the version string
patch... i seem to have applied it correctly but i'm still seeing version "50400" even when trying the '-setvernum' command so i'm not sure what i'm doing wrong. this is a new instance that's in the process of syncing, not 'tevye', which properly shows '99999'. i used the original 99997k script and applied 'version-strings' and 'hearnificarum' manually and both are now
mod6: # Required Public Keys to add to your PGP Keyring. These are used to verify V, rotor, buildroot, and trinque's
patch:
mod6: # Required Public Keys to add to your PGP Keyring. This are used to verify V, rotor, buildroot, and trinque's
patch:
phf: having multiple hunks in a
patch modify several files at the same time creates a harder transition constraint then simple antecedent/descendent pairing, so i'm thinking it's probably safe to construct a graph in terms of transitions rather then purely a/d. the end result should be the same
phf: mircea_popescu: anyway, i was speaking of how things are right now in v.py/v.pl. a hunk touches a file, hunks are grouped thematically (i.e. by a single unit of meaning) in a
patch. a pairing of antecedent/descendent creates a graph and in combination with topo logical sort produces a press order
mircea_popescu: + # You need to have these keys in your gpg keyring to vertify V, trinque's special
patch, buildroot, and other stuff.
mod6: to verify V, trinque's special
patch, buildroot, and other stuff.
phf: i remember ascii suggesting that perhaps we should stick to one hunk per
patch, but that's not the case right with existing patches. if z thematically needs to touch two different files (a and b), then both modifications are inside a single
patch mircea_popescu: the best way forward, imo, is to restructure it as 1) one large
patch consisting of nothing but the return fixes and some smaller patches doing the rest of the stuff built on top of that.
mircea_popescu: polarbeard don't get this wrong, you did a lot of very useful work in that
patch.
mircea_popescu: note that the only way i got my apparently very controversial /s /t
patch to even be considered was showing how it could be machined.
ascii_butugychag: so i can ask the same question, line after line, for a whole
patch mircea_popescu: polarbeard yeah, you get the right idea, but seriously, making a single
patch consisting of JUST -return error +return error is the right way
mircea_popescu: but it's also immense and should all be one single
patch so we can see it more readily.
polarbeard: mircea_popescu: the
patch ended up being a bit verbose, yep, but it made sense to me fixing the messages as I was adding metadata, that's why I didn't add filtering, to not add actual logic to an already pretty big
patch mircea_popescu: there's a lot of stuff in there that will necessarily result in a huge
patch (the guy is stuck, willy-nilly, doing a lot of
punkman: mircea_popescu: so how would you split polarbeard's
patch?
ascii_butugychag: pete_dushenski: supposedly there is an x11
patch to make it go
mircea_popescu: so in full terms, i would say that again, including both in the same
patch is both premature optimization and a kludge.
phf: a way to indicate (a->a' b->b') would normally be to include them both in a single
patch. i think that's how it's done now
phf: so in the above example x y z are distinct patches, their effect is to take files through states, a, a', a". so if a
patch takes a->a', then it needs a in genesis. if a
patch takes a'->a" then it needs genesis and a->a'
patch. i was trying to indicate that y and z modify two separate files, i'm trying to see what is there that indicates that state (a' b') is desirable over (a' b)
punkman: phf, my "shortest path" algo is to recursively find all antecedents of the
patch I want to press. it's useful.
ascii_butugychag: so, e.g., mircea_popescu's retabbing, would be a five-line
patch mod6: as far as comments in the vpatch that are mearly just for archaeological or annotative purposes, i think something could be done here especially when we get our own diff/
patch.
mircea_popescu: now, one obvious solution (wasn't obvious to me at the time what it was a solution to) is to INCLUDE COMMENTS in the patches, like i did with my only signed
patch i didn't really intended as part of a final pressing
mircea_popescu: approach thematter from the other, practical side, maybe it's easier that way. so i made a
patch that did X, then i made a
patch that did X'. i consider X' to be > X.
ascii_butugychag: but i will note that introducing a new
patch that is binary-identical to an old one, is an error.
ascii_butugychag: so if i submit frobs-x.vpatch and also-frobs-x.vpatch and they both reference
patch frobbed-x-before.vpatch, then i can press to frob-x OR to also-frobs-x or to any other leaf.
assbot: Logged on 29-01-2016 10:29:19; jurov: I know that i should manage the repository myself, but imo a version field would be good to have so that I can easily spot if someone posts revised version of the same
patch.
assbot: Logged on 29-01-2016 10:02:07; punkman: so shiva
patch wholly includes the tinyscheme genesis instead of referencing it?
assbot: Logged on 29-01-2016 07:42:24; polarbeard: I've timestamped and categorized trb log lines, as well as improved the messages and removed (seeming never activated) destructive log rotation, here is the signed
patch:
https://gist.github.com/polarbeard/961aa315c69b89d2e613 in case somebody with a decent reputation wants to review it so I can submit it to the ml
ascii_butugychag: (as my instructions note, it is necessary to rename a directory after pressing tinyscheme-genesis to end up with the shiva subdir in shiva
patch)
assbot: Logged on 29-01-2016 10:02:07; punkman: so shiva
patch wholly includes the tinyscheme genesis instead of referencing it?
assbot: Logged on 29-01-2016 08:08:31; ben_vulpes: "this 2.6kloc
patch rewrites every log line in the reference implementation, in support of further work i'm doing on" etc etc
assbot: Logged on 29-01-2016 07:42:24; polarbeard: I've timestamped and categorized trb log lines, as well as improved the messages and removed (seeming never activated) destructive log rotation, here is the signed
patch:
https://gist.github.com/polarbeard/961aa315c69b89d2e613 in case somebody with a decent reputation wants to review it so I can submit it to the ml
punkman: I think it'd be best to name the 2nd
patch mempool_frobsv2.vpatch or something like that
jurov: and the version field as just advisory indication which is the more recent
patch polarbeard: ftr, I've updated the gist, will send the
patch to the ml later
jurov: I know that i should manage the repository myself, but imo a version field would be good to have so that I can easily spot if someone posts revised version of the same
patch.
☟︎ punkman: so shiva
patch wholly includes the tinyscheme genesis instead of referencing it?
☟︎☟︎ assbot: Logged on 29-01-2016 08:13:49; ben_vulpes: definitely split the actual muntzing out into its own
patch instead of complecting it with the rest of the work. i might be able to read and meditate on that
patch.
ben_vulpes: removing dead code is good, far better than rewriting the log lines. just split it out so that it can be reviewed seperately from the two thousand five hundred and ninety odd other lines of that
patch.
ben_vulpes: definitely split the actual muntzing out into its own
patch instead of complecting it with the rest of the work. i might be able to read and meditate on that
patch.
☟︎ ben_vulpes: "this 2.6kloc
patch rewrites every log line in the reference implementation, in support of further work i'm doing on" etc etc
☟︎ ben_vulpes: the problem with a
patch of this size is that my face wearies of reading myriad log lines changed for seemingly aesthetic reasons, and i fear that even a close read will miss an underhanded c contestant.
polarbeard: it truly is, as what value it has, it's just a step into better debugging capabilities, for this
patch I've not added new log lines on purpose but I plan doing it for the next
mod6: ok you should probably wait to run vdiff against the changes until i've got the release
patch out then, so you can start from there.
mod6: im thinking that i'm gonna tag the release, and publish the release
patch soon. just hoping that if any of it touches trb, that it'll be post-release
patch so there are no conflicts.
thestringpuller: once I'm up to sync, i'll
patch that in and restart the node
thestringpuller: is the version string
patch going into the newest release?
assbot: Logged on 27-01-2016 21:38:09; mats: i was just in a meeting where bosses decided to downgrade ~10k windows 10 users to TLS 1.0 (from 1.2) because of a bug from
patch tuesday
mats: i was just in a meeting where bosses decided to downgrade ~10k windows 10 users to TLS 1.0 (from 1.2) because of a bug from
patch tuesday
☟︎ jurov: no, from my own mempool
patch shinohai: node is now running mod6 's latest
patch, running beautifully \o/
assbot: Logged on 25-01-2016 01:30:26; *: asciilifeform observes that this thread has already taken up more space than the
patch.
mod6: alright, the DER
patch has been sent to the ML:
mod6: hmm. so then, I believe if i remove the tabs from my S-
patch and leave the spaces ~in~, then it'll look more like Mr. P.'s
patch he put together.
mircea_popescu: oh ok, my bad. so what i was thinking here is : a) finish the
patch ; b) do all the other stuff you were going to do in your own time ; c) when ready make a new version ; d) take a week off, during which everyone [who cares to] can write and run a script to / /
mod6: But it probably would have been the last thing to go into the tree before a release
patch.
mircea_popescu: i guess i unwittingly confused you, sorry about that. the S-
patch was not actually intended to mark a new release did it ?
mod6: Ok sounds good mircea_popescu. I'll stop my current work on the high/low
patch. I'll spend this week getting the changes [.wot in the pwd, and mechanical post-
patch hash checking] in V [v99996] released. Then I'll immediately begin work on a re-alignment of all the patches we currently are distributing.
ben_vulpes: perhaps fixing magic numbers is out of scope for a
patch to force s-values?