--- Log opened Sat Oct 10 00:00:42 2020 01:49 -!- jonatack [~jon@213.152.162.15] has quit [Ping timeout: 240 seconds] 02:29 -!- jonatack [~jon@37.166.6.124] has joined #rust-bitcoin 02:51 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds] 02:54 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #rust-bitcoin 02:54 -!- jonatack [~jon@37.166.6.124] has quit [Ping timeout: 272 seconds] 02:56 -!- jonatack [~jon@213.152.161.170] has joined #rust-bitcoin 03:05 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 03:08 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 03:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 03:20 -!- Alphonso40Pfeffe [~Alphonso4@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 03:32 -!- jonatack [~jon@213.152.161.170] has quit [Quit: jonatack] 04:43 -!- reallll is now known as belcher 04:45 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin 04:45 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 04:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 05:07 -!- Alphonso40Pfeffe [~Alphonso4@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 05:53 -!- titanbiscuit [~tbisk@45.89.173.204] has quit [Ping timeout: 258 seconds] 07:08 -!- jonatack [~jon@185.206.225.51] has joined #rust-bitcoin 08:03 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 08:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 10:59 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 11:59 < stevenroose> elichai2: do you have a suggestion to deal with feature-gated error variants (in general)? I mean in my MessageSignature PR I can quite easily get rid of them 12:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 12:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 12:15 < jeremyrubin> you asked elichai2, but IMO it might be best to make the error variants non-conditional? 12:16 < jeremyrubin> stevenroose: and then you can make the innards of the error different 12:16 < jeremyrubin> https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=888cf86798257feede9955d52a342330 12:16 -!- belcher_ is now known as belcher 12:18 < elichai2> jeremyrubin: that will still break matching 12:18 < jeremyrubin> Nope :) 12:18 < jeremyrubin> Err there's a typo 12:18 < jeremyrubin> let me show you an example... 12:19 < elichai2> jeremyrubin: here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1d0dafb038cfe6d069e5e16ea16aecd8 12:20 < jeremyrubin> That's not matching 12:20 < jeremyrubin> That's what you do with the inner bit 12:20 < elichai2> this will either compile or fail to compile depending on if the feature is enabled 12:20 < elichai2> jeremyrubin: yeah, which is part of the type IMHO 12:20 < jeremyrubin> let me show you something... 12:21 < elichai2> changing `enum Test {A}` to `enum Test {A(i32)}` is a breaking change, right? 12:21 < elichai2> if so, then the feature changing breaks the API 12:21 < jeremyrubin> It depends what you're trying to accomplish IMO 12:22 < elichai2> jeremyrubin: you should strive for features being additive only 12:22 < jeremyrubin> https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=72fb01b3e63c5a39580ee9d3d95b0c79 12:22 < jeremyrubin> For example this works 12:22 < elichai2> never removing code and never breaking code, that way multiple dependencies in the tree can use different features without anything breaking 12:22 < jeremyrubin> And if you need to do something based on the value, you can feature gate the return type 12:22 < jeremyrubin> Othewise your code will correctly tell you you haven't handled it 12:22 < elichai2> but the user of our library shouldn't care about our features 12:22 < jeremyrubin> Adding an error variant is also a breaking change by that 12:23 < elichai2> unless he needs to enable a feature 12:23 < jeremyrubin> Because non-exhaustiveness will fail 12:23 < elichai2> correct 12:23 < jeremyrubin> The nice thing is what happens when ! stablizes 12:23 < jeremyrubin> then you can just make the other type Something(!) 12:23 < elichai2> how will that change anything here? 12:24 < elichai2> that will still be a breaking change to enable the feature 12:25 < elichai2> here: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=befa4be6919a36cf78e5eb5df46a0bc4 12:25 < jeremyrubin> If you zoom out it's actually a pretty decent compromise. Either the person writing the library doesn't care to support all features, in which case they pick a specific variant, or they do care but want to ignroe errors of this type 12:26 < elichai2> so in your example I wrote a binary, and I handle all your errors like you specified: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=02503df63a9c2d812bbbd9c5d18a5611 12:27 < elichai2> now some dependency also uses your library but he enables "some", which will now break my code 12:27 < jeremyrubin> How to enable feature flag in playground? 12:27 < elichai2> stevenroose: IMHO either marking the enum as `non_exhuastive`(which then adding new variants doesn't break anything) or adding `Box`(I really don't like that), or just using a different type 12:28 < elichai2> jeremyrubin: just uncomment+comment :) 12:31 < jeremyrubin> https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d7c279cccda48bb65ee7d7aaeed86af1 12:33 < elichai2> ok? you showed you can write code that will handle either, users won't write it like that,and I don't think they should 12:34 < jeremyrubin> I don't think users code should automatically support feature flags they aren't aware of via non-exhasutiveness removal 12:34 < jeremyrubin> i'd much prefer code which refuses to compile than code which is incorrect 12:40 < jeremyrubin> Maybe a non-exhaustive variant (not enum) works similarly to what I'm proposing 12:41 < jeremyrubin> I'm not sure how you'd write a correct handle trait though 12:41 < jeremyrubin> A downside of the approach I'm mentioning is it isn't flexible to adding new features in the future 12:53 < jrawsthorne> stevenroose: rebased 454 13:10 < jeremyrubin> Here's one option elichai2, we can make all of the errors normal enum types but for the cfg'd error types require that any external error type that might not be present has an implemention of From for InternalError 13:11 < jeremyrubin> This is still not perfect for future extensibility, but for a given version of the crate the error type will always be the same 13:22 < stevenroose> jrawsthorne: acked 454 13:24 < stevenroose> I made 2 of our network enums more exhaustive here: https://github.com/rust-bitcoin/rust-bitcoin/pull/496 13:25 < stevenroose> Sadly we don't have #[non_exhaustive] yet in 1.29 14:37 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 14:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 14:46 < stevenroose> Request for opinions. Does it seem worth it to make the bip39 crate no_std-capable? Currently it's entirely build around the `Mnemonic(String)` type, which would have to go. 14:47 < stevenroose> The alternative is `Mnemonic(Language, [u16; 24])` but that would complicate things like serde a lot. But it might be worth it. Only a few languages would work well without std, though because those non-latin-alphabet-based languages would need unicode normalization wich is not possible without std. 14:50 < stevenroose> Perhaps `Mnemonic([&'static str; MAX_NB_WORDS])` would be possible as well, without needing the language there. 14:59 < stevenroose> Eh just notice that the fact that we need to prefix "passphrase" to the pbkdf2 "key" is a PITA for no-std :/ 15:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 15:08 < jeremyrubin> stevenroose: maybe make a NoStdMnemonic type, and impl From on it? But also add some direct constructors for nostd environment? Also make most of the functions from a trait MnemonicTrait so that you can write generic library code? 15:10 < stevenroose> jeremyrubin: hmm that seems a bit too much.. `Mnemonic([&'static str; MAX_NB_WORDS])` actually works quite well for most parts, but without having support for pbkdf2 we can't do anything with it. That's needed to get the seed 15:13 < jeremyrubin> or From<&'a str> for Mnemonic Ah I see where the &'a static str is coming from now -- it's in the table, not strs you have to hold 15:16 < jeremyrubin> How do you deserialize a Mnemonic tho? Binary search? 15:18 < stevenroose> linear search 15:19 < stevenroose> lists are not ordered 15:19 < stevenroose> at least most are not 15:19 < stevenroose> they're ordered "lexicographically" which Rust doesn't know, the ordering of special characters isn't the same as the ordering of the underlying bytes 15:20 < stevenroose> but that's not the problem. searching we already do for validation etc 15:20 < stevenroose> I wonder how big of a deal no_std if for HWs.. 15:20 < ariard> BlueMatt: feel free to merge #738, it fixes test slowness as expected 15:21 < BlueMatt> done 15:22 < jeremyrubin> stevenroose: you could store a table of u16's to map them in byte order lol 15:22 < jeremyrubin> Tho I guess worst case it's MAX_NB_WORDS*WORDS 15:22 < jeremyrubin> That might not be too happy on some HWs 15:24 < jeremyrubin> 49152 comparisons worst case 15:26 < jeremyrubin> tangent; but is there a reason that the rust-bitcoin crates don't use cargo fmt? 15:46 < jrawsthorne> I've updated https://github.com/rust-bitcoin/rust-bitcoin/pull/449 which is BIP155 support to the latest BIP and added tests if anyone wants to take a look 15:50 < ariard> BlueMatt:thanks rebasing 653 on top 16:20 < ariard> jrawsthorne: did a quick parse, almost good to me 17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 21:54 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 240 seconds] 21:59 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #rust-bitcoin --- Log closed Sun Oct 11 00:00:43 2020