--- Log opened Wed Nov 06 00:00:58 2019
02:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
02:31 -!- jonatack [~jon@213.152.162.5] has joined #rust-bitcoin
03:30 < elichai2> BlueMatt: what do you think of that in relation to deserializing code? https://github.com/dtolnay/no-panic
03:30 < elichai2> (to make sure that deserialization can never panic/abort)
03:53 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in]
03:55 -!- real_or_random [~real_or_r@173.249.7.254] has joined #rust-bitcoin
04:41 < stevenroose> elichai2: the -sys PR broke your nightly test and I don't really understand why: https://travis-ci.org/rust-bitcoin/rust-secp256k1/jobs/608152345?utm_medium=notification&utm_source=github_status
04:41 < stevenroose> duplicate lang item found: `eh_personality`.  |||  first defined in crate `panic_unwind` (which `std` depends on).
04:42 < elichai2> yeah seems like std is somehow imported
04:43 < elichai2> secp256k1-sys has a default `std` function
04:43 < elichai2> and secp256k1 turns it on no matter what
04:43 < elichai2> you need to import it with `default-feature  = false` and then propagate the `std` feature if needed
04:44 < stevenroose> elichai2: I think I got it
04:44 < stevenroose> yeah I just noticed :)
04:44 < elichai2> stevenroose: a quick look at the commit dbbd89bfdfa74d4663f0ec91eb1d24d9da75417b there seem to be no need for std in secp256k1-sys
04:45 < stevenroose> elichai2: isn't there? the reimpl of the allocation methods do
04:46 < elichai2> I guess I missed that. anyway after that fix i'll try to review it throughly
04:46 < elichai2> (i'm still skeptic about the `rust-bitcoinconsensus` usacase :/ )
04:48 < stevenroose> elichai2: why is this needed on extern crate core: #[cfg(any(test, feature = "std"))]? Why the test?
04:48 < stevenroose> That's how it is in secp proper, but I don't have it in -sys.
04:49 < stevenroose> But now when running locally, I'm getting "maybe a missing crate `core`?"
04:49 < stevenroose> well adding the any(test, doesn't solve it. Let me see what Travis does.
04:50 < elichai2> when you have `#![no_std]` on rust automatically includes the core crate. but with std it doesn't. now because we use the `core` crate we need to include it even when std is on
04:50 < elichai2> about the tests. generally tests always include std even if the feature isn't on. so we need to explictly include core
04:51 < stevenroose> Yeah I understand the feature gating, not the test one.
04:51 < stevenroose> oh
04:51 < elichai2> this was technically solved in 2018, when core+std+alloc are always available
04:51 < stevenroose> k lol, that's why you have the no_std_test ?
04:51 < elichai2> yep :). this is the only way I could think of to *actually* test `no-std`
04:53 -!- vindard [~quassel@190.83.165.233] has joined #rust-bitcoin
04:53 < stevenroose> elichai2: hmm so when running that no_std_test, it says -sys is missing crate core. Because it doesn't have the std feature and is not in a test. So core should be available but isn't..
04:54 < stevenroose> Is my nightly too old perhaps?
04:54 < stevenroose> I think I updated it yesterday though
04:54 < stevenroose> cargo 1.40.0-nightly (5da4b4d47 2019-10-28)
05:02 < stevenroose> heh now I broke all builds with "unresolved import core".. Isn't core supposed to be available when building with `cargo build --no-default-features`?
05:07 < elichai2> it is
05:07 -!- jonatack [~jon@213.152.162.5] has quit [Ping timeout: 240 seconds]
05:07 < elichai2> what doesn't build for you exactly? -sys or secp itself or the no_std_tests?
05:08 < elichai2> (which they are proving themselves usefule ? andytoshi)
05:13 -!- vindard [~quassel@190.83.165.233] has quit [Remote host closed the connection]
05:13 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
05:15 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection]
05:17 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
05:30 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection]
05:30 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
05:46 < stevenroose> the no_std_test
05:46 < stevenroose> well actually now nothing builds
05:46 < stevenroose> just secp with --no-default-features
05:47 < stevenroose> https://travis-ci.org/rust-bitcoin/rust-secp256k1/builds/608171411
05:57 < elichai2> I don't know what to answer that guy anymore. https://github.com/rust-bitcoin/rust-secp256k1/issues/171 (like, he can easily split this into r,s and v+27, but I don't want to give such details, because people aren't supposed to do that :/)
06:19 < stevenroose> kay, the -sys pr is all green again and rebased: https://github.com/rust-bitcoin/rust-secp256k1/pull/169
06:29 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #rust-bitcoin
07:01 < elichai2> Feel free to comment and/or hate here https://github.com/rust-bitcoin/rust-bitcoin/issues/338 :)
08:40 -!- michaelfolkson [~textual@62.60.63.228] has joined #rust-bitcoin
09:20 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
10:08 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin
10:08 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
10:08 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
10:11 -!- michaelfolkson [~textual@62.60.63.228] has quit [Quit: Sleep mode]
10:30 -!- michaelfolkson [~textual@85.255.235.91] has joined #rust-bitcoin
11:15 < BlueMatt> ariard: at a high leve, the reason this wasnt done initially is I was worried about effeciency (especially requiring the user call into the lib twice because we got an err, plus pushing the Err into the events vec), but I'd also be somewhat surprised if there weren't cases where we have to process an Err inside a lock around that channel before returning
11:15 < BlueMatt> cause Errs may leave the channel in an inconsistent state, so you may need to ensure that it gets dropped before return, but also we should probably make sure thats clear in the code, too
11:19 < BlueMatt> elichai2: that looks like a cool testing tool....I assume we can, eg, find a way to add it to things such that travis checks it but we dont have to ship it in our crates
12:35 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer]
12:58 -!- michaelfolkson [~textual@85.255.235.91] has quit [Quit: Sleep mode]
13:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
13:46 -!- philbw4 [~znc-admin@157.245.253.12] has joined #rust-bitcoin
13:49 < philbw4> hi bitcoin rust people, I've been attempting to get a testnet server up and running for Tamas' defiads project https://github.com/defiads/defiads -- however, being new to Rust I seem to be running into a strange issue. The SPV node (based on the rust toolchain, hence why i'm posting here) seems to work fine when running on a personal laptop. However, on the server it seems to hang when trying to reach
13:49 < philbw4> out to peers. Wondering if this is an issue anyone else has encountered?
14:04 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin
14:04 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
14:04 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
15:53 -!- michaelfolkson [~textual@85.255.235.32] has joined #rust-bitcoin
15:56 -!- michaelfolkson [~textual@85.255.235.32] has quit [Client Quit]
16:15 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]
16:17 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin
16:50 -!- michaelfolkson [~textual@85.255.235.32] has joined #rust-bitcoin
18:25 -!- michaelfolkson [~textual@85.255.235.32] has quit [Quit: Sleep mode]
19:09 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 264 seconds]
19:11 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
--- Log closed Thu Nov 07 00:00:02 2019