--- Log opened Sun Oct 11 00:00:43 2020 00:43 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 02:01 -!- jonatack [~jon@185.206.225.51] has quit [Ping timeout: 260 seconds] 02:31 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin 02:31 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 02:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 02:50 -!- jonatack [~jon@37.166.231.206] has joined #rust-bitcoin 02:56 -!- jonatack [~jon@37.166.231.206] has quit [Read error: Connection reset by peer] 02:57 -!- jonatack [~jon@185.206.225.51] has joined #rust-bitcoin 03:00 -!- jonatack [~jon@185.206.225.51] has quit [Read error: Connection reset by peer] 03:03 -!- jonatack [~jon@37.166.231.206] has joined #rust-bitcoin 03:20 -!- Ryley45Raynor [~Ryley45Ra@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 04:42 -!- jonatack [~jon@37.166.231.206] has quit [Ping timeout: 258 seconds] 06:32 -!- jonatack [~jon@109.232.227.138] has joined #rust-bitcoin 07:37 -!- Netsplit *.net <-> *.split quits: icota[m] 07:37 -!- Netsplit over, joins: icota[m] 07:38 -!- Netsplit *.net <-> *.split quits: moneyball__, jamesob, midnight 07:39 -!- Netsplit over, joins: midnight, moneyball__, jamesob 07:40 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-oeomhefeyifncioi] has quit [Ping timeout: 244 seconds] 07:53 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-lwpewzcfbdxukyql] has joined #rust-bitcoin 09:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 11:53 -!- otoburb [~otoburb@unaffiliated/otoburb] has joined #rust-bitcoin 12:40 -!- jonatack [~jon@109.232.227.138] has quit [Ping timeout: 260 seconds] 12:42 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 12:42 -!- jonatack [~jon@134.19.179.147] has joined #rust-bitcoin 13:24 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #rust-bitcoin 13:27 < cloudhead> jeremyrubin: from what I know, some folks think it would introduce too much churn 13:27 < cloudhead> especially if rustfmt output isn't stable 13:28 < cloudhead> this hasn't been my experience, but it has been the experience of some here 13:28 < cloudhead> I always have to disable it when doing a contribution, because it'll reformat the entire file ^_^' 13:30 -!- Ryley45Raynor [~Ryley45Ra@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 14:00 < gwillen> we've been starting to consider the use of cargo fmt internally (Blockstream), and one of the arguments I've heard in favor of doing it now is that the Rust team has promised it will stop changing at this point. 14:00 < gwillen> I think I heard that from apoelstra; I'm surprised he seems to be missing from this channel currently. 14:02 < gwillen> I reviewed the output of running it over our code as a demo, and I was generally pretty happy with the results. One of the points of contention was the rule that, unless all parameters to a call are on the same line, they shall all be on different lines (you can't break in the middle.) 14:03 < gwillen> I'm used to that rule from Google style, but it takes up a lot of vertical space that some people find objectionable. 14:12 < cloudhead> Good to hear 14:13 < cloudhead> the function header formatting can be annoying indeed - it's not so bad with a 100 column width though, but understandable 14:32 < andytoshi> gwillen: my name is andytoshi here :P 14:32 < andytoshi> although i do highlight on apoelstra 14:33 < andytoshi> also fyi i never used the word "promise" 15:32 < gwillen> haha sorry andytoshi, I forgot your nick is different here. And okay, I forget what word you used, but you did have the impression that they aren't planning to keep changing it after this, right? 15:33 < gwillen> yeah I think probably given the wrapping rules, using it with the widest possible column setting will be the least disruptive, even 120 maybe 15:59 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 16:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin 16:05 -!- tibo [~tibo@2400:4050:2a83:7000:d10d:f490:81c5:99ef] has joined #rust-bitcoin 17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 17:47 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection] 18:00 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin 18:57 < andytoshi> i would find that very disruptive 18:58 < andytoshi> it defaults to 100, that is more than wide enough 19:28 < jeremyrubin> How in love are we with the serialization pattern for util/amount? It seems like it might make more sense to make it an enum of some sort 19:29 < jeremyrubin> It's a bit bizzare because let's say I make some type X which can be serialized but contains an Amount, there's no way for it to generically support either a Bitcoin or a Sats amount 19:30 < jeremyrubin> I guess what sucks is it isn't safe to assume anywhere that an inbound value is of sats or btc type, but the current pattern sort of does make the user of Amount assume what the inbound type is, which might not be known 19:33 < jeremyrubin> I'm thinking I may just make a new type (oh compatibility) which makes more sense for I/O and can coerce to Amount 19:41 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 19:45 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin 23:31 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 23:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin --- Log closed Mon Oct 12 00:00:44 2020