--- Log opened Mon Feb 11 00:00:46 2019 02:30 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-tczrfdeeaqqvwlht] has joined #rust-bitcoin 04:16 -!- TamasBlummer1 [~Thunderbi@p200300DD672D1A4295EFE534E52DD1FC.dip0.t-ipconnect.de] has joined #rust-bitcoin 04:18 -!- TamasBlummer [~Thunderbi@p200300DD672D1A8039CADA0A94F5FDDC.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:18 -!- TamasBlummer1 is now known as TamasBlummer 07:27 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has joined #rust-bitcoin 07:47 -!- michaels_ [~michaelsd@38.126.31.226] has joined #rust-bitcoin 11:39 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds] 11:59 < dongcarl> gwillen: I shot myself in foot by merging a smaller PR first, which caused a merge conflict for my larger and more longer-standing PR, and now I have to rebase, and push, get invalidated, and beg for reviews all over again 11:59 < dongcarl> RIP me 12:24 < gwillen> :-( 12:32 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has joined #rust-bitcoin 12:49 < dongcarl> Okay TamasBlummer sgeisler I promise this is the last time. https://github.com/rust-bitcoin/rust-bitcoin/pull/183 12:49 < dongcarl> Had to rebase, and that invalidated everything :-/ 12:53 < sgeisler> The last time (TM) ^^ I'll have a look 12:53 < andytoshi> reviewing now 12:54 < dongcarl> <3 13:00 < gwillen> are people religious about re-reviewing after rebase? 13:00 < gwillen> I've noticed that on core people have started giving commit ids in their acks 13:00 < gwillen> this seems annoying 13:01 < andytoshi> gwillen: in this case i'm looking at the PR for the first time in like four months (but i'm also not reviewing very adversarily because of the other ACKs and lengthly design discussions i remember having, even though i don't remember my conclusions) 13:03 < andytoshi> but eg for libsecp code i have religious about it 13:03 < andytoshi> s/have/am/ 13:04 < dongcarl> You guys should all check out `git range-diff` 13:05 < andytoshi> i'm guessing that wolud shortcut all the time spent redoing rebases and then diffing the result against the PR? 13:06 < dongcarl> andytoshi: yup, see https://github.com/dongcarl/bitcoin/blob/2019-02-productivity-md/doc/productivity.md#diff-the-diffs-with-git-range-diff 13:06 < dongcarl> It's nicely colored too! 13:07 < dongcarl> ALL: just need one more review for https://github.com/rust-bitcoin/rust-bitcoin/pull/227, very small PR with 1 approval already. 13:09 < andytoshi> let's get 183 first pls ;) 13:09 < dongcarl> fo sho 13:17 < dongcarl> andytoshi: want to do the honors? 13:21 < andytoshi> sure 13:21 < andytoshi> done 13:22 < dongcarl> Yyeeeeeeaaaah 13:23 < andytoshi> utacked 227. looks sensible 13:24 < andytoshi> ok. now psbt needs rebase :P 13:24 * dongcarl becomes merge conflict incarnate 13:25 < andytoshi> toughen up. it's only been seven months ;) 13:26 < BlueMatt> oof, thats starting to sound like bitcoin core 13:27 < andytoshi> in fairness, this is maybe the most complex PR we've ever had (and is definitely the most complex PR if you include all the supporting refactorings it needed) 13:28 < andytoshi> in general rust-bitcoin is like 1/500th the size of core, so hopefully we can manage not to make a habit of this.. 13:29 < BlueMatt> yea, totally 13:29 < BlueMatt> I mentioned to dongcarl today, but ideally we could set github to only require 1 "current-commit" review, and then 1 additional review from someone instead of requiring two re-reviews 13:29 < BlueMatt> but...alas 13:29 < BlueMatt> i guess could email support@ and ask them to add it 13:58 < dongcarl> I was talking to sgeisler about this and he had some good ideas 13:59 < dongcarl> I think what I'll do is this: set up a time each week where I'll look through all the PRs 13:59 < dongcarl> Preferably a time that is convenient for people 13:59 < dongcarl> Participation is of course optional but I'll be online 14:00 < dongcarl> And we can perhaps have a faster loop 14:01 < dongcarl> On weeks where there are enough people, we might even be able to talk about priorities and rough timelines 14:05 < dongcarl> This has been through a good amount of review: https://github.com/rust-bitcoin/rust-bitcoin/pull/218 14:05 < andytoshi> for the next month i'm continuing to have a bit of a crazy travel schedule and will be AWOL. also working on signature stuff. 14:05 < andytoshi> but should be much more available after that 14:07 < dongcarl> Yeah, just having enough people available to get PRs through (3 people) would be wonderful. 14:33 < dongcarl> TamasBlummer: I'm not familiar with the rationale for https://github.com/rust-bitcoin/rust-bitcoin/pull/231, I remember you had problems with the concept? 14:33 < dongcarl> What's changed? 14:37 < dongcarl> Other reviewers, we should also get https://github.com/rust-bitcoin/rust-bitcoin/pull/233, it's been a couple of months and it's useful for PSBT as well. 14:37 < dongcarl> Thank you stevenroose for the good work 14:43 < stevenroose> dongcarl: about the DerivationPath thing: if I add the FromIterator and IntoIterator traits, can the From> and Into> be removed? 14:45 < stevenroose> I prefer to still be able to use .into(), just not sure if there are auto traits with the FromIterator stuff. I'll add a tiny unit test to make sure they are into()-able 14:56 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-tczrfdeeaqqvwlht] has quit [Quit: Connection closed for inactivity] 15:12 < stevenroose> sgeisler: re:bip32: would std::ops::Index be enough to do that? 15:12 < stevenroose> You also suggesting to add a `.child()` method? 15:17 -!- michaels_ [~michaelsd@38.126.31.226] has quit [Remote host closed the connection] 15:21 < sgeisler> stevenroose: you'd have to implement multiple versions of Index 15:21 < sgeisler> like here: https://github.com/rust-bitcoin/rust-bitcoin/blob/51aba8bb21cef3d6c7606d97711edda3f1112233/src/internal_macros.rs#L228 15:22 < sgeisler> at least one for range access and one for element access (if my code example should work how I intend it to work) 15:23 < sgeisler> I think a child method is quite natural when talking about bip32 key derivation 15:23 < sgeisler> I'm just unsure if it should consume self or borrow and clone the inner vector 15:23 < sgeisler> I think consume is more elegant 15:24 < sgeisler> since ChildNumber should be copy and so my code example would work without clones 15:46 -!- Netsplit *.net <-> *.split quits: valwal, scoobybejesus, neonknight, simian_za, dongcarl 16:59 -!- valwal [sid334773@gateway/web/irccloud.com/x-jnimdysrkinsctvt] has joined #rust-bitcoin 16:59 -!- simian_za [sid314183@gateway/web/irccloud.com/x-jjlfbeuliaretzrn] has joined #rust-bitcoin 16:59 -!- dongcarl [sid321684@gateway/web/irccloud.com/x-zetauabocrfhksce] has joined #rust-bitcoin 16:59 -!- neonknight [uid318979@gateway/web/irccloud.com/x-vnmchwbapkjjcljk] has joined #rust-bitcoin 17:00 -!- scoobybejesus [sid271506@gateway/web/irccloud.com/x-emfvqvaoiafpqavh] has joined #rust-bitcoin 22:22 -!- schmidty_ [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #rust-bitcoin 22:22 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds] 23:00 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] --- Log closed Tue Feb 12 00:00:47 2019