--- Log opened Thu Dec 12 00:00:34 2019 00:54 -!- Kiminuo [~mix@141.98.103.126] has joined #rust-bitcoin 01:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 01:10 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [Ping timeout: 246 seconds] 01:12 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #rust-bitcoin 01:12 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 01:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 01:24 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 02:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 245 seconds] 02:43 -!- Kiminuo [~mix@141.98.103.126] has quit [Ping timeout: 250 seconds] 03:04 -!- Donavon55Ullrich [~Donavon55@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 03:48 < stevenroose> elichai2: about the hex thing, what's the position on LowerHex and UpperHex? It seems like a hex crate should do something with them. Like impl ToHex for fmt::LowerHex so that there is always a non-allocating version available. 03:49 < elichai2> what about non allocating? 03:50 < elichai2> we could PR that, even though `LowerHex` is pretty broken and nobody uses it 03:53 < stevenroose> yeah but it's better than introducing a new DisplayHex that has the exact same interface, right? 03:54 -!- jonatack [~jon@213.152.162.104] has joined #rust-bitcoin 03:55 < stevenroose> Heh so the ToHex definition there is a bit strange. IMO ideally we'd leverage fmt as much as we can like hashes::hex does. The allocating version is just a wrapper around the fmt one. 04:30 < elichai2> what allcoating thing? 05:05 < stevenroose> the ToHex(&self) -> String 05:12 < stevenroose> the problem with using lowerhex is that you can't implement it on foreign types 05:30 < elichai2> well the rust-hex crate generalized this to `fn to_hex>(&self) -> T;` 05:30 < elichai2> but you probably will still use String on the other side 05:30 < elichai2> anyhow. my problem is more with using `FromStr` for hex 05:30 < elichai2> not the other way around (LowerHex) 05:33 < stevenroose> My biggest concern is that the vast majority of the usage for hex serialization is when logging/printing 05:33 < stevenroose> So an efficient fmt:: compatible trait/function is key. They only have a ToHex that allocates a String 05:34 < stevenroose> I tried using fmt::LowerHex but then it's annoying you can't do it for AsRef<[u8]> 05:35 < elichai2> well even `LowerHex` in the end allocates to a String via the println/format macros 05:35 < stevenroose> So then I tried doing a DisplayHex that has the same interface as fmt:: traits but you really can't use those at all. All APIs with fmt use either write! or fmt::Arguments kinda thing. 05:36 < elichai2> so when you actually create the log you need to allocate 05:36 < stevenroose> elichai2: not if you use it inside a larger string, right? Then it won't double allocate. Or if you're serializing into a writer. 05:36 < stevenroose> Otherwise you allocate the String and then write it in your log message string. 05:37 < elichai2> hmm yeah it'll probably double allocate but the `format` bulitin is anyway pretty slow 05:38 < stevenroose> Yeah? Shouldn't that be one of the most optimized pieces of code? Since trace! would otherwise kill your app :D 05:38 < elichai2> I can't find the benchmark somehow hmmm 05:38 < stevenroose> So now I'm gonna try do a DisplayHex based on io::Write 05:39 < elichai2> stevenroose: https://github.com/rust-lang/rust-clippy/issues/2824#issuecomment-393578881 05:39 < stevenroose> Not ideal, though. But write! supports that. 05:39 < elichai2> still can't find the benchmark though 05:39 -!- Donavon55Ullrich [~Donavon55@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds] 05:40 < stevenroose> Yeah well using format! like that is silly. But format is useful when you're doing format!("Received tx: {}", txid), right? 05:41 < stevenroose> So you'd want some DisplayHex traint that you can one-line delegate from Display and Debug, like LowerHex 05:41 < elichai2> I'm not saying that format isn't usefull. it does something that isn't possible in any other way 05:41 < elichai2> which is why it's a builtin 05:41 < elichai2> just saying that performance isn't the biggest issue 05:48 -!- jonatack [~jon@213.152.162.104] has quit [Ping timeout: 240 seconds] 05:52 < stevenroose> So you're saying that doing this wouldn't matter much: impl fmt::Display for Hash { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.write_str(&self.to_hex()) } } 05:53 < elichai2> yeah. the only problem I see here is the usage of std inside of Display 05:53 < elichai2> which isn't really a problem. only my obsession with no-std hehe 06:01 < stevenroose> Yeah somehow fmt is non-std 06:01 < stevenroose> But why is it so impossible to create your own fmt-compatible trait? :S 06:01 < stevenroose> fmt::Write and fmt::Formatter are entirely closed 06:02 < stevenroose> Shouldn't we be able to define custom formattings? 06:05 -!- Kiminuo [~mix@141.98.103.126] has joined #rust-bitcoin 06:05 < stevenroose> I realize we won't be able to get a {:c} custom token, but at least let us write to a fmt::Formatter and let us create a string from a formatter ( elichai2 ) 06:08 < stevenroose> Or the Rust team could solve everything by implementing LowerHex on AsRef<[u8]>, period. :) 06:09 < stevenroose> I don't remember what their reasoning was for that. Because it overlaps with the recursive impl LowerHex for [T] I guess. 06:09 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin 06:09 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 06:09 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin 06:09 < stevenroose> Ah that one doesn't even exist. 06:14 < elichai2> you can write a `fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result` trait. but then what will you do with the `Formatter`? 06:14 < elichai2> stevenroose: see https://github.com/rust-lang/rust/pull/67021 for the recursive one 06:16 < elichai2> anyway. there's no real way to construct and/or read `fmt::Formatter` 06:19 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 06:38 -!- Kiminuo [~mix@141.98.103.126] has quit [Ping timeout: 268 seconds] 06:42 < stevenroose> elichai2: yeah, that's what I did. didn't the fmt:: interface change at some point? I remember that it used to be fmt::Write or something? Or am I confusing with something else? 06:43 < elichai2> I think you're confusing. `Formatter` also implements the Write trait 06:57 -!- jonatack [~jon@37.166.226.254] has joined #rust-bitcoin 07:00 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 07:18 < stevenroose> elichai2: I think I made it work with fmt::Write: https://gist.github.com/stevenroose/7165922a1122171e5809cedfedffbddb 07:18 < stevenroose> The only thing it doesn't do because it's not fmt is provide a {:x} formatter 07:19 < stevenroose> impl fmt::LowerHex for DisplayHex causes some trouble: upstream crates may add a new impl of trait `std::fmt::LowerHex` for type `std::vec::Vec` in future versions 07:19 < stevenroose> It's actually explicitly forbidden :/ 07:22 < elichai2> What's explicitly forbidden? 07:30 < stevenroose> implementing LowerHex on T: DisplayHex 07:31 < stevenroose> It gives this error: "upstream crates may add a new impl of trait `std::fmt::LowerHex` for type `std::vec::Vec` in future versions" 07:31 < stevenroose> It's basically _hashes::hex but with Hash and LowerHex stripped from it 07:32 < stevenroose> elichai2: DisplayHex could be part of the derive wrapper with display_from(DisplayHex), debug_from(DisplayHex) and lowerhex_from(DisplayHex) or something. 07:40 < elichai2> Heh 07:53 -!- jonatack [~jon@37.166.226.254] has quit [Read error: Connection reset by peer] 08:00 < stevenroose> elichai2: did you take a look at the lib? 08:03 < elichai2> Looks interesting 08:04 < elichai2> Isn't for [u8] and for Asref<[u8]> redundant? 08:16 < stevenroose> yeah I was confused by that not giving an error. 08:17 < stevenroose> but AsRef is not implemted for T 08:18 < stevenroose> but `impl AsRef<[T]> for [T]` is.. 08:36 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 09:09 < stevenroose> elichai2: fmt-hex crate? :p 10:31 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has joined #rust-bitcoin 11:08 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 276 seconds] 11:12 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 11:29 < ariard> hey what's the state of thread safety statical analysis on rust, like https://clang.llvm.org/docs/ThreadSafetyAnalysis.html for c++ ? 11:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds] 11:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 13:37 < BlueMatt> I think, sadly, there isn't much :( 13:38 < BlueMatt> the GUARDED_BY is somewhat uneccessary in the sense that mutexes in rust "own" their data, but things like ACQUIRED_BEFORE dont have any equivalent 14:57 -!- Kiminuo [~mix@141.98.103.126] has joined #rust-bitcoin 15:08 -!- Kiminuo [~mix@141.98.103.126] has quit [Ping timeout: 268 seconds] 15:09 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer] 15:10 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined #rust-bitcoin 16:17 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 17:11 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 246 seconds] 18:31 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 20:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 20:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 23:53 -!- Kiminuo [~mix@141.98.103.126] has joined #rust-bitcoin --- Log closed Fri Dec 13 00:00:35 2019