--- Log opened Tue Jul 24 23:21:59 2018
23:28 < BlueMatt> dongcarl: probably the easiest way to do is just do what savil said, there, just run travis-fuzz
23:28 < BlueMatt> though if you want instructions for like afl or cluster setup I can share the scripts I use
23:30 < BlueMatt> andytoshi: heh, I mean I guess pinning a dep for hex is ok, though given its use in like only one place (and only serialize!) in non-test, you could really make it a test-only dep and add the written out hex encoder in the one place its used
23:30 < BlueMatt> (which would only be a -1 line +4 lines diff
23:33 < BlueMatt> oh, except for one place thats used in a serde deserializer, but we can make that optional on the basis of wehether you're building with serde support or not (which I think we said we agreed should be optional)
23:34 < savil> BlueMatt: serde feels like a pretty core operation, when interacting with the network. When would it make sense to make it be optional?  obviously, i'm missing lots of context since i'm new to this
23:35 < BlueMatt> if you're interacting with the network you should use the ConsensusEncode/Decode things
23:35 < BlueMatt> there is a paralell encode/decode in rust-bitcoin due to consensus
23:35 < BlueMatt> so the non-consensus parts seem pretty redundant for most people
23:35 < savil> oh interesting. And which scenario(s) would need serde?
23:36 < BlueMatt> there may be a few types that are non-consensus? Also its more of a local-storage thing I guess? I dunno, I just figure pretty much every use is just consensus-encode/decode
23:36 < savil> got it
23:38 < BlueMatt> if you're including a rust-bitcoin type in some kind of local storage where you're already using serde, it probably makes sense to just let serde auto-derive the inner types
23:38 < BlueMatt> otherwise you'll have to bend over backwards to use it
23:38 < BlueMatt> but if you're not using any rust-bitcoin types inside of a serde-serialize/deserialized struct, it probably makes sense to not have it
23:40 < savil> (y)