--- Log opened Mon Dec 14 00:00:46 2020
00:16 -!- Netsplit *.net <-> *.split quits: dr-orlovsky, meshcollider, jonatack, darosior
00:22 -!- Netsplit over, joins: dr-orlovsky, jonatack, darosior, meshcollider
02:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
02:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript
03:01 < sanket1729> andytoshi: Any ideas on improving macro code? https://gist.github.com/sanket1729/9367a8df5aadfe5386ff23697bd99c87#file-descriptor_impl-rs-L95-L187
06:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
06:24 < andytoshi> is Raw the same as Bare?
06:25 < andytoshi> my thought was that the impls on the objects themselves could be repeated code ... it was only the enum dispatch stuff that'd be macro-ized
06:25 < andytoshi> though i wonder if we could use x-macros in Rust by clever use of modules, `type` and `include!` :P
06:32 < sanket1729> yes, raw is same as BAre
06:33 < sanket1729> I think it's okay if we repeated code that's just implementing the trait. It's probably better from documentation
06:34 < sanket1729> what do you mean enum dispatch stuff?
06:36 < sanket1729> But then we will have 10 implementations of DiscriptorTrait with ~60-70 loc each. 
06:37 < sanket1729> Seems boilerplate code, but it's not that bad
06:40 < sanket1729> I guess such macros are common with many parameters in rust-lang compiler, so we are not doing uncommon 
06:40 < sanket1729> https://github.com/rust-lang/rust/blob/ae5b641e9ef3fc5ed2b9944121f75902f639cb0a/src/libcore/num/mod.rs#L2446 
06:44 < andytoshi> heh yeah, i think i sorta copied that macro in rust-bitcoin for u256 and u128 and i regretted it
06:44 < andytoshi> esp as u128 got into the language itself, so i wound up having all this macro crap for literally only one type!
06:45 < andytoshi> sanket1729: so, regarding X macros in Rust, let me try to demonstrate what i mean..
06:45 < andytoshi> well, no, lemme just type it, cuz i don't have an easy way to upload multiple things (i should get my git server working again..
06:46 < andytoshi> my thinking is that in raw.rs you'd write something like 
06:46 < andytoshi> mod private { type Inner; include!("impl_inner.rs"); } pub use private::Inner as Raw;`
06:47 < andytoshi> and then impl_inner.rs would have a bunch of `impl Inner { fn max_satisfaction_weight(...) }` etc
06:47 < andytoshi> and if you can't do that, because the code is too different between the different impls ... then probably you shouldn't be using macros either
06:50 < sanket1729> The code for functions is same for a subset of items, but different of others. But there are other function which are same of a different set of items
06:50 < sanket1729> Basically, what we reduce with macros is basically the function signatures
06:51 < sanket1729> Those look big in size compared to the macro impl, because the implementations are one-liner or two-liner
06:51 < andytoshi> ah ok
06:51 < andytoshi> the function signatures i think we should just duplicate
06:51 < andytoshi> they serve as documentation and if they ever change the compiler will make us change all of them
06:51 < andytoshi> so they don't risk getting out of sync
06:52 < sanket1729> cool. I agree
06:52 < sanket1729> we can still have macros for debug, display, fromstr etc. 
06:53 < andytoshi> yeah that's ok, although I wonder if we could also do those with x-macros rather than macro_rules!
06:53 < andytoshi> maybe that's not really clearer
06:53 < andytoshi> or even with traits
06:53 < sanket1729> I have not used x-macros
06:53 < andytoshi> yeah, they're not very rustic at all
06:54 < andytoshi> they're actually a C idiom and if we use them in rust the compiler is not going to give readable error messages
06:54 < sanket1729> I think macro_rules! for debug, display, fromstr is neat and readable. What do you about having a deref to inner?
06:55 < andytoshi> i really really don't like Deref for non-pointers
06:55 < andytoshi> even for pointers Deref is confusing and magical and hard to predict
06:55 < sanket1729> yeah, it's basically you have to remember that it has deref. 
06:56 < andytoshi> yeah
07:13 < sanket1729> Since, we are doing a major breaking change. What is usually prefered in the rust-ecosystem w.r.t to position of argument for context parameters
07:13 < sanket1729> right now, we have that as the first parameter
07:36 < andytoshi> i don't know. i assume first is pretty universal
08:12 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript
10:45 -!- jonatack [~jon@134.19.179.139] has quit [Quit: jonatack]
10:52 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript
10:57 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 264 seconds]
10:58 -!- jonatack [~jon@134.19.179.195] has joined ##miniscript
12:03 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-cvgkhbesbqvoxvsu] has quit [Read error: Connection reset by peer]
12:03 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-cndlteukbokvnpjt] has quit [Ping timeout: 264 seconds]
12:03 -!- digi_james [sid281632@gateway/web/irccloud.com/x-vjrjbdfohnkqvcae] has quit [Read error: Connection reset by peer]
12:04 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ckjfcboybjfhlvon] has joined ##miniscript
12:04 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-lsbztgetyjllqsza] has joined ##miniscript
12:04 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-fpkuvfihnixtfrzh] has joined ##miniscript
12:31 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript
12:33 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript
14:07 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]
15:01 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
15:21 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript
17:53 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
18:04 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript
22:10 -!- jonatack [~jon@134.19.179.195] has quit [Read error: Connection reset by peer]
22:16 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript
--- Log closed Tue Dec 15 00:00:49 2020