--- Log opened Fri Jan 04 00:00:11 2019 00:00 < sgeisler> low friction is kinda essential for something like this, since you don't really get anything for publishing reviews :/ 00:00 < dpc> That's true. 00:01 < dpc> (though you could review stuff for money! I actually hope it will pick up eventually) 00:01 < sgeisler> It's nice to have and consume them, but publishing is just work, tragedy of the commons 00:01 < sgeisler> I hope so too, but I think that's still a hard sell 00:03 < dpc> I've created an issue for autmatic git publishing. 00:04 < dpc> I'm not sure if I want the full cycle. What if someone is not online etc... 00:04 < dpc> Though at very least I'd like it as switch or something. 00:05 < sgeisler> yeah, that sounds good, as long as review+commit works I'm happy, from there I can build my custom commands 00:11 < dpc> `reviewcrate() { cargo crev review $1 $2 && cargo crev git commit -a -m "add review for $1 v${2}" && cargo crev push; }` if you're using bash? 00:11 < dpc> Oh... it won't work for commit message if you haven't passed the version manually... 00:12 < dpc> Anyway, I will work on it. Got to go now. 00:13 < sgeisler> Thanks again, no pressure, crev is quite good as it is already :) I just want to see it as widely adopted as possible 01:44 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #rust-bitcoin 01:46 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 258 seconds] 02:38 -!- TamasBlummer1 [~Thunderbi@p200300DD67243B80852FECBBD058E88A.dip0.t-ipconnect.de] has joined #rust-bitcoin 02:40 -!- TamasBlummer [~Thunderbi@p200300DD67243B07CC57C785112B8FDA.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 02:40 -!- TamasBlummer1 is now known as TamasBlummer 03:01 -!- grubles [~grubles@unaffiliated/grubles] has joined #rust-bitcoin 03:03 -!- grubles_ [~grubles@unaffiliated/grubles] has quit [Ping timeout: 244 seconds] 08:55 -!- sgeisler [~quassel@x8d1ee20a.agdsn.tu-dresden.de] has quit [Quit: No Ping reply in 180 seconds.] 08:56 -!- sgeisler [~quassel@x8d1ee20a.agdsn.tu-dresden.de] has joined #rust-bitcoin 11:42 < gwillen> I'm very intrigued by crev 11:42 < gwillen> (I saw it hit HN today) 12:51 < BlueMatt> andytoshi: was your comment here a "I'm not sure if I like that" or a "sure, whatever"? https://github.com/rust-bitcoin/bitcoin_hashes/pull/21#issuecomment-450198521 12:51 < BlueMatt> if not I'll hit merge 12:52 < andytoshi> BlueMatt: "sure, whatever" 12:52 < andytoshi> go for it 12:52 < BlueMatt> k 12:52 < BlueMatt> we should move towards a rust-bitcoin bump with bitcoin_hashes at some point... 12:52 < BlueMatt> and preferably a secp bump in rust-bitcoin, too 12:52 < andytoshi> yeah, agreed. i had a small thing to do in liquid before i got on top of all this stuff again 12:52 < andytoshi> but then it turned out not to be small :) 12:53 < andytoshi> going forward, when we change deps like this i'd like to do a major version bump for each single change 12:53 < andytoshi> so if we update rust-secp, and bitcoin_hashes, and do real changes, maybe we wind up with several major versions within a day or two 12:54 < andytoshi> the idea being that migration will be easier downstream if they can use each version in turn, updating their own software in discrete chunks 12:54 < BlueMatt> i mean...ok? 12:54 < BlueMatt> fair enough 12:54 < andytoshi> previously with rust-bitcoin 0.13 to 0.14 there was a ton of stuff changing at once, so the commit that changed Cargo.toml from using 0.13 to 0.14 had to do like 10 unrelated things to keep each commit compiling 12:57 < BlueMatt> yea, fair 13:07 < BlueMatt> andytoshi: if you're ok with the perf on it, can you hit https://github.com/rust-bitcoin/bitcoin_hashes/pull/19 ? 13:20 < BlueMatt> well, actually, wait 13:32 < BlueMatt> andytoshi: so I played with it a bit more.... 13:32 < BlueMatt> if we're willing to assume the compiler cant learn anything about the structure of the inputs, then we could actually get ~= performance as a regular comparison 13:33 < BlueMatt> ie this version: https://godbolt.org/z/UXl1kI 13:33 < BlueMatt> technically the compiler can play any tricks it wants to calculate the final or-of-all-xors, but it still has to calculate it 13:34 < BlueMatt> in this case, the compiler will vectorize that calculation 13:34 < BlueMatt> gmaxwell: you may have thoughts ^ 13:34 < BlueMatt> this makes it pretty much as fast as the slow-path (ie equal) normal comparison 13:35 < BlueMatt> test cmp::benches::bench_64kb_constant_time_cmp_eq ... bench: 2,065 ns/iter (+/- 16) 13:35 < BlueMatt> test cmp::benches::bench_64kb_constant_time_cmp_ne ... bench: 2,066 ns/iter (+/- 20) 13:35 < BlueMatt> test cmp::benches::bench_64kb_slice_cmp_eq ... bench: 1,560 ns/iter (+/- 64) 13:35 < BlueMatt> test cmp::benches::bench_64kb_slice_cmp_ne ... bench: 2 ns/iter (+/- 0) 13:36 < BlueMatt> except for 32b comparisons, which end up slow-pathing on the vectorization and taking 10ns/iter, but thats still acceptable 14:01 < BlueMatt> I guess we cant really do that cause the compiler could do a if t == 0xff { replace reading the inputs with a bunch of 0xff writes } 14:02 < BlueMatt> anyway, I guess we should take as-is 14:02 < BlueMatt> we can manually unroll a little bit if we want at some point 14:24 < andytoshi> BlueMatt: if you're comfortable i'm happy to merge this 14:25 < BlueMatt> yea, just take it as-is, I think 14:25 < BlueMatt> if anyone ever complains we can revisit optimizing more 14:25 < andytoshi> kk 14:25 < BlueMatt> at least as-is its pretty well guaranteed to not get optimized by the compiler, though hardware is always a crapshoot 14:25 < BlueMatt> at least x86's crazy memory consistency helps there 14:26 < andytoshi> heh yeah 14:27 -!- icota [~igor@141-136-153-168.dsl.iskon.hr] has joined #rust-bitcoin 15:05 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 18:35 -!- icota_ [~igor@141-136-181-157.dsl.iskon.hr] has joined #rust-bitcoin 18:39 -!- icota [~igor@141-136-153-168.dsl.iskon.hr] has quit [Ping timeout: 258 seconds] 21:43 < dpc> sgeisler: Changes you've requested have just been landed. If possible, I would appreciate someone actually testing them for a while. :) 21:43 < dpc> sgeisler: https://github.com/dpc/crev/commit/c33589c645edc1fdd3265c900a3bcab33c33b858 21:44 < sgeisler> Thx :) I just started compiling the new version 21:48 < dpc> I think I'm going to pass on auto-pushing for a while. If you have any other good ideas about the UX, please let me know. I agree that any way we can make it more efortless is higher chance of people doing it. 21:52 < sgeisler> I just noticed again that the shell.nix definition doesn't work out of the box for me, does it for you or are you using something else? 21:52 < sgeisler> I had to add + export OPENSSL_DIR="${pkgs.openssl.dev}" and + export OPENSSL_LIB_DIR="${pkgs.openssl.out}/lib" 21:52 < sgeisler> to make it work 21:53 < sgeisler> Maybe the currently included version isn't completely up to date? I guess it should either work or not otherwise, that's the whole point of nix, isn't it? :D 21:56 < dpc> I haven't used it for a while. Let me try. 21:57 < dpc> Please submit a PR anyway. It might work on my system due to something I did to it. 21:58 < dpc> I do some questionable things just to make my life easier in Nix. 22:02 < sgeisler> For me it was just a quick fix "change it till it compiles", that's why I didn't PR yet. I want to figure out the exact set of deps I need first :D 22:37 < dpc> Oh, OK. :) --- Log closed Sat Jan 05 00:00:12 2019