--- Log opened Wed Jan 20 00:00:21 2021 00:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 00:40 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin 00:40 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds] 01:06 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-xxyfbhfpwravtvho] has quit [Ping timeout: 272 seconds] 01:07 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-cfpxvfoqzzaxcsfp] has joined #rust-bitcoin 03:18 -!- Alyce11Crooks [~Alyce11Cr@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 03:36 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 03:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 05:33 -!- belcher_ is now known as belcher 06:17 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 06:36 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin 06:36 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 06:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 06:50 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 09:10 -!- Alyce11Crooks [~Alyce11Cr@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection] 09:11 -!- Amanda86Davis [~Amanda86D@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 09:46 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Read error: Connection reset by peer] 09:46 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #rust-bitcoin 11:40 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #rust-bitcoin 12:43 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 12:45 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 15:51 -!- tibo [~tibo@2400:4050:2a83:7000:d0e6:4c3d:6457:95a1] has joined #rust-bitcoin 17:11 < jeremyrubin> We should add: #[cfg_attr(feature = "serde", derive(Deserialize, Serialize)] to all of the rust-bitcoin Error types 17:12 < andytoshi> sure 17:12 < Thomas[m]1> Why would you serialize the structure of an error? 17:12 < andytoshi> though don't a bunch of them have io::Error in them? 17:12 < andytoshi> also yeah, why would anyone need this 17:12 < jeremyrubin> Hmmm will have to check -- does io::Error not impl Serialize? 17:13 < andytoshi> lol no, io::Error does not impl basically anything 17:13 < jeremyrubin> If you want to return errors from a WASM plugin 17:13 < Thomas[m]1> I think `.to_string()` is what you are after (which will use the `Display` impl). 17:13 < jeremyrubin> Ok, but then how do I programatically handle different error cases? 17:14 < Thomas[m]1> Error codes perhaps? 17:14 < Thomas[m]1> Sounds cumbersome though 17:14 < jeremyrubin> If only there were a way to serialize errors ;) 17:14 < Thomas[m]1> I see where you are going :D 17:14 -!- Amanda86Davis [~Amanda86D@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 17:15 < Thomas[m]1> However, unless you want to restrict your WASM plugin to always be executed within a Rust-based runtime, it might be worthwhile to think about a more language-agnostic way of reporting errors anyway. 17:16 < jeremyrubin> serde_json! 17:16 < Thomas[m]1> Like, how would a JavaScript-based runtime deal with those errors? 17:16 < jeremyrubin> they are jsons 17:17 < jeremyrubin> Or,,, we could evenutally add a wasm_bindgen optional annotation for javascript users 17:17 < jeremyrubin> so then you could even get the bindings built automatically for the struct return types 17:17 -!- tibo_ [~tibo@2400:4050:2a83:7000:ae:8f0a:eb3c:3704] has joined #rust-bitcoin 17:17 < Thomas[m]1> I've worked with wasm-bindgen a bit in the last weeks and we ended up returning `Result` from our functions. 17:19 -!- tibo [~tibo@2400:4050:2a83:7000:d0e6:4c3d:6457:95a1] has quit [Ping timeout: 264 seconds] 17:20 < Thomas[m]1> See here: https://github.com/comit-network/waves/blob/b4a4dfa746784429f4711e72928f156bc191702d/waves/wallet/src/lib.rs#L41-L48 17:20 < Thomas[m]1> The `Err` `JsValue` is simply a string that contains the formatted error from `anyhow`. 17:20 < Thomas[m]1> Not machine readable though, but I think `wasm_bindgen` can generally not handle that very well. There is an open isse here: https://github.com/rustwasm/wasm-bindgen/issues/1742 17:20 < jeremyrubin> Yeah FWIW I'm handling rust <-> wasmized rust with a common error type that exists higher up, so for me having a serialize option would be good 17:21 < jeremyrubin> w.r.t. io::Error i can look into it more, I think it should be possible to stub out the io::Errors with something using serialize_with 17:24 < Thomas[m]1> I haven't read in detail into what WASM traps are capable of but I think it would be good to go towards a solution that would potentially work with any runtime. Numeric error codes sound like something very language should be able to deal with. 17:25 < Thomas[m]1> If both sides are Rust and you have a common error, you could even automate that away with a proc-macro that assigns a unique number to each variant so you can easily go from code to variant and back. 17:26 < Thomas[m]1> Not sure if you even want to pass richer information like stacktraces across such boundaries. Kind of breaks the encapsulation of WASM I feel. 17:34 < jeremyrubin> TBH don't care that much so long as it serializes/deserializes and can be handled programatically 17:35 < jeremyrubin> I think it'd be OK to erase std::io::error using Display or Debug or something into a custom type when serialized 17:35 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 17:35 < jeremyrubin> OR just don't allow serializing such a field? 17:35 < Thomas[m]1> How are you going to re-construct the instance though? 17:39 < Thomas[m]1> Errors in Rust are kind of one-way in that regard. I've also encountered a lot of libraries where all the constructors for the error variants are private :/ 17:42 < Thomas[m]1> You could just create your own error enum without "source" information and implement serialize/deserialize on that so you can map between them. In a way, it is the same problem when passing errors from a HTTP-server to its clients. The "right" way to do that is to use something like RFC7807 (application/problem+json). That will loose you information like stacktraces but at least you've got a clearly defined API 17:42 < Thomas[m]1> instead of an accidental one :) 17:43 < jeremyrubin> It doesn't change that we still want it to work with Serde 17:44 < Thomas[m]1> What it does change is that if you define your own error enum without any "source" errors, then you don't need `rust-bitcoin`'s error to implement Serialize 17:44 < Thomas[m]1> * What it does change is that if you define your own error enum without any "source" errors, then you don't need `rust-bitcoin`'s errors to implement Serialize 17:44 < jeremyrubin> not sure what you mean by a source error 17:44 < jeremyrubin> but it sounds pretty annoying to have to unwrap every error in such a manner 17:45 < Thomas[m]1> Carrying along the original error as a field in the variant. 17:45 < jeremyrubin> Especially in the use case I'm enabling, which is WASM plugins for rust/rust software 17:45 < jeremyrubin> this sounds super complicated; maybe you can flesh it out more thoroughly? 17:47 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 17:47 < Thomas[m]1> Can you give me an example of an error case in your WASM plugin that you'd like to report back? 17:47 < jeremyrubin> ParseAmountError 17:47 < jeremyrubin> MiniscriptError 17:51 * Thomas[m]1 sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/gToesUGpmJuDxcazzZDjmUUz/message.txt > 17:52 < Thomas[m]1> You can then also create a catch-all variants for all the remaining ones where you don't can/need to react programatically. 17:56 < jeremyrubin> I think you're underappreciating how many custom error variants we have 17:56 < jeremyrubin> this would make for tons of boilerplate code 17:56 < Thomas[m]1> You don't need to handle all of them at once 17:56 < Thomas[m]1> I would probably start with just the catch-only variant and simply carry over the result of `to_string` of the error and extend the list of errors as I run into situations where I need to handle them on the host. Like, "oh, here I want to know whether this failed because the amount was negative" -> go ahead and add that as an explicit variant 17:57 < Thomas[m]1> * I would probably start with just the catch-all variant and simply carry over the result of `to_string` of the error and extend the list of errors as I run into situations where I need to handle them on the host. Like, "oh, here I want to know whether this failed because the amount was negative" -> go ahead and add that as an explicit variant 17:58 < jeremyrubin> May as well use python 17:59 < jeremyrubin> I think it's far superior when we're dealing with rust that we preserve as much type information as possibler 17:59 < jeremyrubin> especially if it's not difficult to do 17:59 < Thomas[m]1> I completely agree but across serialization boundaries, that is actually difficult 18:00 < jeremyrubin> https://doc.rust-lang.org/std/io/struct.Error.html#method.new 18:00 < jeremyrubin> We can literally do: 18:01 < jeremyrubin> serialize_with = ... to_string ... deserialize_with = io::error::new(...string...) 18:01 < jeremyrubin> so just io errors get cast into strings 18:01 < jeremyrubin> then all the other types work fine 18:02 < jeremyrubin> so only the inner std::io::Error type gets erased, everything else stays as is 18:03 < jeremyrubin> which is relatively OK imo 18:05 < Thomas[m]1> What I am saying is, I would take the opportunity of a serialization boundary to define a set of errors that are actually relevant to the client (i.e. the host in this case). However, I don't know enough about your usecase to say that this makes sense for you. Conceptually though, a plugin usually presents some kind of abstraction layer which should hide some level of detail. Why would that not also apply to errors 18:05 < Thomas[m]1> where different source errors get mapped to a particular one that gets then returned to the host? 18:29 < jeremyrubin> Ok so there is a crate A and then a crate host and a crate plugin 18:30 < jeremyrubin> A has a trait T. plugin impl's T and binds it to the plugin interface. host knows it can call T's methods on the plugin 18:31 < jeremyrubin> The interface is defined elsewhere; preference is to be able to wrap a wasm plugin to behave identically to a native compiled in trait T 19:08 < Thomas[m]1> So in other words, you want it to be completely transparent that there is even a wasm plugin involved? 19:51 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds] 22:11 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #rust-bitcoin 22:24 < jeremyrubin> > [1/20/21 19:08] So in other words, you want it to be completely transparent that there is even a wasm plugin involved? 22:24 < jeremyrubin> yeah exactly 22:33 < Thomas[m]1> Very interesting, not sure if there is a general solution to it though. Maybe some unsafe trickery where you read the raw memory, serialize it and cast it back? That assumes the error doesn't contain any references etc 22:37 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds] --- Log closed Thu Jan 21 00:00:22 2021