March 14, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 14, 2019 [12:54:57] <Smithx10> papertigers: n1[12:56:52] <jlevon> no?[12:58:17] <Smithx10> nice one[12:58:27] <Smithx10> that flame graph tool :)[12:59:11] <jlevon> oh, I thought it was a short version of "no"[12:59:13] <jlevon> short*[13:58:25] <Smithx10> hahah the short version is the same length :P[17:28:21] <papertigers> nbaksalyar: are you around by any chance?[17:28:40] <nbaksalyar> papertigers: hi, sure :)[17:28:42] <papertigers> I need some help with futures and combinators[17:28:45] <papertigers> if you have a moment[17:30:29] <nbaksalyar> sure! what is the problem there?[17:32:09] <papertigers> I am trying to write a stream that wraps another stream. So in this case I want to take a Body stream from hyper and process the chunks in some way. I created this small example but I cant seem to get the combinators right to make rustc happy[17:32:33] <papertigers> https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=d3e3dc773902f60aace8f37bb0ede6cf[17:32:41] <papertigers> line 45[17:33:52] <papertigers> i've tried many things and swapping map for and_then etc ha but I can't seem to get it right. I feel like I am missing something that will make things click for me about how this should work[17:34:34] <nbaksalyar> seems like it's caused by .for_each() returning ()[17:35:12] <nbaksalyar> let me double-check it though[17:39:13] <papertigers> even if I stick a bogus value there like Ok(4) it complains about something else[17:58:08] <nbaksalyar> papertigers: getting back on this - `map` needs to be `and_then` in this case since `map` just converts the future result type while `and_then` can execute another future returned from the closure[17:58:54] <papertigers> I did try that but still wont compile for another reason I can't figure out[17:59:19] <papertigers> expected (), found struct `hyper::error::Error`[18:01:05] <nbaksalyar> yeah, type checking on futures can be a PITA :) I think some of the functions expect the future error type to be `hyper::Error`. give me a sec.[18:01:48] <papertigers> nbaksalyar: yeah that has been my biggest pain point so far. types + the combinators in futures[18:07:07] <nbaksalyar> papertigers: should work like this :) https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=80a1d00b55c84be1a757818540388164[18:08:23] <nbaksalyar> it's because `and_then()` expects the closure result to be `IntoFuture<Error = Self::Error>`, meaning it has to return the same error type (`hyper::Error` in this case)[18:09:18] <nbaksalyar> and since `.for_each()` returned just `IntoFuture<Error = ()>`, it failed. putting `map_err` _before_ `and_then` should do the trick[18:10:05] <papertigers> well I will be damned[18:10:10] <papertigers> hahha that works[18:10:29] <papertigers> that makes sense[18:10:37] <papertigers> let me try now with the real code[18:38:53] <papertigers> nbaksalyar: thanks again for explaining that[18:42:49] <nbaksalyar> no problem! :) actually, tooling for async/futures code is very important imo. While it's more-or-less manageable with compiler type errors, it quickly turns into hell if you start dealing with lower-level debugging[18:45:49] <nbaksalyar> and knowing how it's usually done with illumos/mdb/dtrace, it's something that the Rust community currently lacks - and can greatly benefit from[18:52:51] <papertigers> yeah I hope the debugging story gets better[18:53:26] <papertigers> mdb_v8.so is a work of art. Being able to debug node core files and being able to see the state everything was in is great[20:20:19] <jbk> well at least we'll have frame pointers on the illumos target :)