--- Day changed Tue Nov 06 2018
02:27 < sgeisler_> Since our github organization doesn't have a logo yet I'd like to propose some: https://imgur.com/a/CCf1krL if you have other ideas please let me know. I personally would like a more abstract/vector version of the proposed logos better but I don't have the svg skills to do this. I think it would be nice to have some recognizable logo instead of the autogenerated pixel stuff.
02:27 < sgeisler_> (I can render these with transparent background too)
03:34 < BlueMatt> sgeisler_: sgtm, I dont really care, andytoshi ?
12:09 < andytoshi> hehe i like it
12:09 < andytoshi> the first one is more colorful
12:55 < andytoshi> fuckin a, we got https://github.com/bitcoin-core/secp256k1/pull/553 .. can start work on rust-secp 0.12 now
12:56 < andytoshi> BlueMatt: can you ack https://github.com/rust-bitcoin/rust-secp256k1/pull/77 (increase version to 0.11.4) and maybe https://github.com/rust-bitcoin/rust-bitcoin/pull/188 (rust-bitcoin version to 0.15)
12:57 < andytoshi> oh, also https://github.com/rust-bitcoin/rust-bitcoin/pull/179 which just adds a fuzztest and nothing else
15:26 < esotericnonsense> eh, forgot to include this in my autojoin
15:26 < esotericnonsense> anyway so i've rewritten the backend for my node monitor in rust; it uses handrolled libraries at the moment because it was a learning project, though I'd love to use/contribute to the ones in the rust-bitcoin repo as time permits
15:27 < esotericnonsense> i recommend using nasal pegs before opening the .rs files; https://gitlab.electronrelocation/esotericnonsense/bitcoin-top
15:27 < esotericnonsense> er.
15:27 < esotericnonsense> https://gitlab.electronrelocation.com/esotericnonsense/bitcoin-top
15:30 < esotericnonsense> it's not that well tested but the whole thing should "just work". automatically spawns containers with psql, bitcoind, nginx/varnish etc, you can stick it behind a reverse proxy and look at some graphs. i'd like to eventually make it in to a "web version" of bitcoind-ncurses/bitcoin-qt such that you could run a node and access it remotely (auth gated of course)
16:27 < stevenroose> andytoshi: like I commented, you can easily fix the versions in .toml.
16:28 < stevenroose> What I would like to see in Cargo is to also commit to some hash in .toml instead of just .lock. But well at least .lock has it.
16:28 < stevenroose> Issue is that commit hashes are very common, but the crates.io repo can't reuse them without including all history in every package tarball. So you'd have to introduce package tarball hashes as well, which I understand is not ideal.
16:34 < andytoshi> stevenroose: i can fix the versions of my immediate dependencies in .toml, but not the deps of my deps
16:35 < andytoshi> apparently there is _no_ way to control this in cargo
16:36 < stevenroose> andytoshi: hmm, deps of deps makes sense. No idea what happens if you add transient deps to your .toml file without explicitly using them.
16:36 < andytoshi> nothing.
16:37 < stevenroose> andytoshi: I think my background with dependency management is different, because I come from runtime languages where there can always be only one version of a package in the runtime.
16:37 < andytoshi> i removed the .lock from my commit. it's just a design bug in cargo that you cannot lock your deps in a library, there's no way around it
16:37 < andytoshi> this is definitely not true in rust
16:37 < stevenroose> So the scenario I described could perhaps work in rust because of static binding.
16:37 < andytoshi> exported types from different versions will be different types, which can lead to confusing errors if you try to mix them
16:38 < andytoshi> and libraries that do C compilation or other weird build.rs stuff (e.g. rust-secp) will cause link errors if you have multiple versions in play
16:38 < stevenroose> Yeah I thought of that in the middle of the conversation.. I could be wrong about the .lock interpretation thing. And I agree it should be possible to fix transient deps, fwiw.
16:38 < andytoshi> no, i asked on #rust, it sounds like you're right
16:39 < stevenroose> Go is having a huge pain with dependency management when I last used it.  Precisely of that constraint. So one old package that didn't update it's `.toml` can cause a ton of problems when other packages share a dep with that one on another version.
16:40 < andytoshi> rust is explicitly designed so that multiple major versions of libraries can be used together (and with the semver trick you can even make their types be compatible)
16:40 < andytoshi> the one big exception to this is crates like rust-secp which do C compilation
16:40 < andytoshi> which is why you're supposed to have -sys crates that basically never increase their versions
16:41 < andytoshi> it _should_ also work if you have multiple minor versions, but people don't generally put any effort into making that work (and it's actually hard for me to see how you would, in general..)
16:42 < andytoshi> so i can see why cargo makes the decisions that it does, regarding always trying to max out the minor versions of everything so that everything will use the same version
16:42 < andytoshi> but it's hard to avoid semver violations.. also almost nobody supports rust 1.14 anymore except by accident, so when people break this they don't consider it a semver violation
18:01 < stevenroose> "accept by accident"
21:01 < BlueMatt> andytoshi: wait, so what was up with the .lock file?
21:03 < andytoshi> BlueMatt: i wanted to commit Cargo.lock in the rust-secp repo so that the deps wouldn't change out from under me
21:03 < andytoshi> but stevenroose pointed out that cargo wouldn't actually enforce this except when building rust-secp as the top-level project. for downstream users it'd ignore my Cargo.lock
21:04 < andytoshi> and also, that this is likely to cause my downstream users to compile projects with multiple versions of dependencies, which can cause weird errors
21:05 < BlueMatt> ah
21:06 < andytoshi> ultimately i'm not too worried, rust-secp has barely any deps and none of them change very often
21:07 < andytoshi> if `cc` breaks us again then i'll just pin a specific version in Cargo.toml and forget about it
21:09 < BlueMatt> andytoshi: they apparently have some hack upstream in honggfuzz that fixed fuzzing, fyi
21:10 < BlueMatt> https://github.com/rust-fuzz/honggfuzz-rs/commit/0921e98d6dbc447de6bec1c0db9f10664caea289
21:10 < andytoshi> BlueMatt: oh, nice, i've got that as a shell command in rust-bitcoin and a couple other things
21:10 < andytoshi> RUSTFLAGS=-use-gold-linker or whatever
21:10 < andytoshi> but if it's done upstream maybe i can remove that
21:11 < BlueMatt> i believe so
22:17 < andytoshi> oh, i see, the "upgrade to 0.15" PR includes this ... lemme drop that and see if it still works
22:19 < dongcarl> andytoshi: sgeisler_ and I are reviewing bitcoin_hashes right now
22:19 < andytoshi> awesome, thanks
22:20 < andytoshi> i think you have an open invite to be a contributor
22:20 < andytoshi> and your acks might not count unless you accept it
22:20 < andytoshi> if you go to https://github.com/rust-bitcoin/bitcoin_hashes/invitations you should be able to accept
22:23 < dongcarl> Thank you!