--- Log opened Fri Apr 05 00:00:36 2019
01:41 -!- TamasBlummer1 [~Thunderbi@p200300DD670F9D386506B7C4D522E0CB.dip0.t-ipconnect.de] has joined #rust-bitcoin
01:43 -!- TamasBlummer [~Thunderbi@p200300DD670F9D416506B7C4D522E0CB.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
01:43 -!- TamasBlummer1 is now known as TamasBlummer
02:53 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-hqsoryqzhlwmpgzx] has quit [Remote host closed the connection]
03:03 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-vedqvmmkxxympznl] has joined #rust-bitcoin
03:28 < stevenroose> How about we export bitcoin_hashes as bitcoin::hashes so users don't have to add it to Cargo? :)
07:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
07:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
07:10 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
07:15 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 245 seconds]
07:17 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
08:17 < stevenroose> andytoshi: I'm hitting a rust-jsonrpc error that David patched some months ago but wasn't released.
08:18 < stevenroose> Perhaps review the batching PR and release new version? :)
08:19 < andytoshi> heh kk
08:20 < andytoshi> oh, yeah, i'll re-review the batching PR
08:21 < andytoshi> man it is frustrating that json values can't be directly put into hashmaps
08:23 < andytoshi> stevenroose: have you tested this code?
08:23 < andytoshi> it looks correct
08:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
08:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
08:27 < stevenroose> tbh I haven't :/
08:27 < andytoshi> heh ok
08:27 < stevenroose> I have a PR depending on this in bitcoincore_rpc but I'm thinking about redoing it
08:28 < andytoshi> i'm going to add a newtype that lets you directly hash serde_json::Value types and PR that... gimme 15 minutes
08:28 < andytoshi> then ask you to rebase on that rather than using .to_string()
08:28 < stevenroose> I could do some unit tests with raw json from the spec page?
08:28 < andytoshi> that'd be awesome
08:28 < stevenroose> there weren't many, but one sec will append to this PR
08:28 < andytoshi> even one would be great
08:31 < andytoshi> do we not have arbitrary_precision on serde_json in this crate?
08:31 < andytoshi> how are we deserializing numbers?
08:31 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection]
08:33 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
08:36 < stevenroose> We don't. IDs are Value's IIRC so no need for numbers. Up to the user.
08:36 < stevenroose> I added a super basic parsing test. Can't really add much more IMO.
08:36 < andytoshi> if the user uses a number as an ID, it will get mangled when being turn into a Value
08:37 < andytoshi> this is why Value can't be Hash or Eq
08:38 < stevenroose> mangled?
08:38 < andytoshi> it will be parsed as a f64
08:39 < andytoshi> well, no, only if it can't be parsed as a i64
08:39 < stevenroose> Hmm, yeah I think it's like that. The Number type is an enum and I'd expect it to try from sane to insane :D
08:39 < stevenroose> so int first, then float then string probably.
08:39 < stevenroose> well "string" when it's arbitrary
08:40 < andytoshi> yes, it will only do string when arbitrary_precision is enabled
08:40 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection]
08:41 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
08:45 < stevenroose> andytoshi: we could also not sort responses
08:45 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 258 seconds]
08:45 < stevenroose> And document it as such.
08:45 < andytoshi> eek
08:45 < stevenroose> But since jsonrpc actually handles and assigns IDs with build_request, I don't think it's nice to make the user mess with them
08:46 < andytoshi> that'd cause _very_ mysterious errors and potentially security bugs
08:46 < stevenroose> also, in an HTTP context, what is "expensive" when it comes to memory allocation for stringing
08:47 < andytoshi> if you allocate a couple bytes then deallocate that, 2N times for N requests, that could easily bottleneck your client
08:47 < andytoshi> we had this kind of thing in our functionary logging code, a long time ago
08:47 < stevenroose> easiest would be to turn id into a u64
08:48 < andytoshi> and i went through and killed all the allocations in log lines (though some are back, which i'll fix with the structured logging changes..)
08:48 < andytoshi> second-easiest is to just newtype Value and add Hash
08:48 < stevenroose> I can PR that if you like. It's less according to the spec, but since we assign them ourselves, shouldn't take any functionality away
08:48 < andytoshi> and document "if you try to use floats here you might have a bad time"
08:50 < stevenroose> Hash only has guarantees about collision with other Hashes from the same type, right? so you can't just delegate to inner-type Hash I guess. Need to add some extra bits
08:50 < andytoshi> yeah, it's a bit of boilerplate, but not bad
08:50 < stevenroose> ah but that's not that hard
08:51 < stevenroose> what do you prefer?
08:51 < stevenroose> I want to move on with this :)
08:51 < andytoshi> i'm going to do the newtype
08:51 < andytoshi> gimme 15 more minutes :P
08:51 < stevenroose> ah, ok cool
08:54 < andytoshi> done. lemme add some unit tests tho
08:55 < andytoshi> https://github.com/apoelstra/rust-jsonrpc/tree/2019-04-value-hash is the newtype i'm thinking
08:56 < andytoshi> i'm going to force-push to that branch with a unit test
08:59 < stevenroose> andytoshi: are u64::hash and i64::hash guaranteed to be different?
08:59 < stevenroose> if they aren't then they could collide since you're both adding them to "number".hash
08:59 < andytoshi> no, i expect they'll be the same
08:59 < andytoshi> they'll "collide" on the same numbers
09:00 < stevenroose> hmm, good point, if they collide it'd probably be on positive i64s and then it'd be fine
09:00 < stevenroose> :D
09:00 < stevenroose> cool
09:00 < andytoshi> right :)
09:03 < stevenroose> you want to PR that util mod in and me to rebase on top?
09:04 < andytoshi> you can just cherry-pick it
09:04 < andytoshi> i'd prefer not to PR cuz it doesn't make sense on its own
09:05 < stevenroose> k tell me when you have the tests ready so I can PR
09:06 < andytoshi> done
09:06 < andytoshi> just pushed
09:06 < andytoshi> man json is shitty .. if you have maps with duplicate fields they'll hash to the same thing
09:06 < andytoshi> -0 and 0 hash to the same thing
09:07 < andytoshi> and 0.0 i think
09:07 < andytoshi> i mean, these basically just reflect json's inability to roundtrip.. but bleh
09:12 < stevenroose> hmm, the &'a Value thing is bugging my. I want to move the Responses into the HashMap, but the key needs to keep a reference to where the response is at
09:13 < andytoshi> hmm
09:13 < stevenroose> So I either have a HashMap over &Response, but then I can't create a new Vec<Response> to return
09:13 < andytoshi> let me try to adapt your code. that might be tricky
09:13 < andytoshi> right
09:14 < stevenroose> go ahead, probably better to clone the id twice instead of cloning the response once
09:14 < andytoshi> yeah, but maaybe we can avoid any clones at all
09:14 < andytoshi> in any case, cloning the id is not so bad .. that is a zero-allocation thing if the id is an integer
09:17 < stevenroose> you looking at it? otherwise I'll try like that
09:17 < andytoshi> i'm looking at it
09:17 < andytoshi> five minutes..
09:17 < andytoshi> man these lifetimes are annoying
09:17 < stevenroose> (also had to make the inner value public
09:17 < andytoshi> yeah, i noticed that. will fix in my branch
09:19 < andytoshi> heh, i think you should just clone the ID
09:19 < andytoshi> one sec, i'll fix the pub thing
09:20 < andytoshi> done
09:21 < andytoshi> oh, should i remove the &'a Value thing entirely
09:21 < andytoshi> and just use Value
09:23 < stevenroose> yeah that's what I would do with cloning
09:23 < stevenroose> I can do it
09:23 < andytoshi> sgtm
09:27 < stevenroose> aaaaarghh, that breaks the recursive thing for arrays and objects
09:28 < stevenroose> I think I'm just gonna clone the IDs into a vector first
09:32 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
09:32 < stevenroose> andytoshi: force pushed my PR
09:34 < andytoshi> cool, looking
09:34 < andytoshi> blehh, i wish we didn't need this Vec
09:34 < andytoshi> but it's fine i guess, it's just one allocation
09:36 < stevenroose> Yeah I can't think of a way not to need it. Because you have to scramble the resulting responses
09:36 < stevenroose> perhaps
09:36 < stevenroose> we can map id refs to indices
09:37 < stevenroose> then move the hashmap into the value vec
09:37 < andytoshi> oo hmm
09:37 < stevenroose> then sort
09:37 < andytoshi> i don't think we need to sort even
09:37 < stevenroose> (* then sort responses according to indices)
09:37 < stevenroose> yeah not sort indices I mean
09:37 < stevenroose> just  take responses by index
09:37 < stevenroose> worth it though? :D
09:37 < andytoshi> heh i think so :P
09:38 < andytoshi> can you spend a couple minutes trying it ? i think i still ran into lifetime issues without the Vec
09:38 < andytoshi> which didn't seem like "real" lifetime issues, in that there ought to be a solution
09:38 < andytoshi> but i couldn't figure it out
09:38 < andytoshi> so i guess .. if you can do this quickly we might as well
09:38 < andytoshi> but if it's gonna take more than a couple minutes *shrug* we'll just live with the Vec
09:38 < stevenroose> leme try
09:44 < stevenroose> hmm, can be O(n log n) I think, you can't take responses out of vecs without moving stuff around to fill the gaps so you'll have to go over them and find their index in the vec, then take out the index
09:45 < andytoshi> oh i see
09:45 < andytoshi> yeah, nvm then
09:45 < andytoshi> the existing code is O(n) :)
09:46 < andytoshi> if you fix my comment nit on the PR i'll merge this and publish a new version
09:50 < stevenroose> pushed
09:51 < stevenroose> I have to leave soon. Will check back in a bit.
10:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
10:13 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds]
10:17 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #rust-bitcoin
10:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
10:40 < andytoshi> https://github.com/apoelstra/rust-jsonrpc/pull/25 version bump
11:00 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection]
11:00 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
11:05 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 245 seconds]
12:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
13:38 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
13:42 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 246 seconds]
14:58 -!- neonknight0 [~neonknigh@195.159.29.126] has joined #rust-bitcoin
15:00 -!- CjS778 [~caylemeis@195.159.29.126] has joined #rust-bitcoin
15:01 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 255 seconds]
15:01 -!- CjS77 [~caylemeis@195.159.29.126] has quit [Ping timeout: 255 seconds]
15:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds]
15:01 -!- neonknight [~neonknigh@195.159.29.126] has quit [Ping timeout: 246 seconds]
15:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
15:01 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #rust-bitcoin
17:04 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
17:09 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 264 seconds]
21:06 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin
21:11 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 264 seconds]
23:11 -!- ccdle12 [~ccdle12@223.197.182.203] has joined #rust-bitcoin
23:46 -!- ccdle12_ [~ccdle12@223.197.182.203] has joined #rust-bitcoin
23:46 -!- ccdle12 [~ccdle12@223.197.182.203] has quit [Read error: Connection reset by peer]
--- Log closed Sat Apr 06 00:00:36 2019