profile
viewpoint
Andrew Cann canndrew Perth, Australia

canndrew/error_def 17

Rust syntax extension for generating error-handling boilerplate code.

canndrew/future-utils 8

Extensions to Rust's Future and Stream traits.

canndrew/crust 3

Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects

canndrew/crust-futures 3

Port of crust to futures/tokio

canndrew/c_linked_list 2

Rust library for handling C linked lists

canndrew/emoji-quickpick 2

Emoji picking app for Linux

canndrew/atomic-arc 1

Atomically reference-counted atomic pointers for Rust

canndrew/abstractsocket 0

abstract unix sockets support for net.createConnection

canndrew/agda 0

Agda is a dependently typed programming language / interactive theorem prover.

canndrew/beaker-plugin-safe-authenticator 0

SAFE Authenticator plugin for SAFE Browser

issue closeddtolnay/quote

Support nested usages of quote

I'm writing a proc macro for use in proc macros. I'd like to write some code that looks like this:

let foo = ... ;
quote! {
    let bar = ... ;
    quote! {
        (#foo, ##bar)
    }
}

ie. where foo gets expanded when my proc macro runs and bar gets expanded when the proc macro that uses my proc macro runs. This doesn't seem possible though. Maybe I've just incorrectly guessed the syntax, but I couldn't find anything when searching the docs and the issue tracker for "nesting".

closed time in 23 days

canndrew

issue commentdtolnay/quote

Support nested usages of quote

Thanks, and thanks for the quick response :)

##bar means # followed by #bar.

Right. I can see my syntax can't be made to work.

If you want # followed by bar you could write:

Thanks. I'll do that.

canndrew

comment created time in 23 days

fork canndrew/quote

Rust quasi-quoting

fork in 24 days

issue openeddtolnay/quote

Support nested usages of quote

I'm writing a proc macro for use in proc macros. I'd like to write some code that looks like this:

let foo = ... ;
quote! {
    let bar = ... ;
    quote! {
        (#foo, ##bar)
    }
}

ie. where foo gets expanded when my proc macro runs and bar gets expanded when the proc macro that uses my proc macro runs. This doesn't seem possible though. Maybe I've just incorrectly guessed the syntax, but I couldn't find anything when searching the docs and the issue tracker for "nesting".

created time in 24 days

Pull request review commentrust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

 macro_rules! serde_struct_impl {                         formatter.write_str("a struct")                     } +                    fn visit_seq<V>(self, mut seq: V) -> Result<Self::Value, V::Error>+                    where+                        V: $crate::serde::de::SeqAccess<'de>,+                    {+                        use $crate::serde::de::Error;++                        let length = 0;+                        $(+                            let $fe = seq.next_element()?.ok_or_else(|| {+                                Error::invalid_length(length, &self)+                            })?;+                            #[allow(unused_variables)]+                            let length = length + 1;+                        )*

Do we really need to worry about compiler bugs producing incorrect code?

I tried changing it anyway, since it's not worth arguing about, but then you can't add the #[allow(unused_assignment)] attribute to the line because rust complains that "attributes on expressions are experimental", and without that you get compiler warnings about the last incrementation of length being unused.

canndrew

comment created time in 2 months

pull request commentrust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

Btw, what's the rationale for not wanting to introduce new dependencies for tests? I understand dependencies are a security concern (which is obviously pretty important for this crate) but surely that doesn't apply for tests, right?

canndrew

comment created time in 2 months

pull request commentrust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

I've updated the PR to remove bincode as a dependency and from serde_round_trip!. Is it possible to get this merged as-is, given that it fixes a bug and I know that the new code at least works for my own code?

canndrew

comment created time in 2 months

push eventcanndrew/rust-bitcoin

Dr Maxim Orlovsky

commit sha ec92a056827a39a4d9f01a8936959524d71a7e39

New HashTypes defined according to #284 (WIP), Txid is completed

view details

Dr Maxim Orlovsky

commit sha 5ef39e34fab0e0f405243343a9b51ad08c11eae9

Implementing (W)Pubkey/ScriptHash and BlockHash

view details

Dr Maxim Orlovsky

commit sha 5f4f629bb192a63adc07b15d4864e422d77dd92a

Replaced all hash160, sha256 and sha256d with the new hash types throughout the code Embedding Txid's in the doc exaples

view details

Dr Maxim Orlovsky

commit sha d20ab1dbc414634ace785bb8a3660ef6819840ea

Switching to XpubIdentifier

view details

Dr Maxim Orlovsky

commit sha 4746ccb88ed662d1dc610b4917310c1da34a9671

Final work on Txid and other hashes Fixing issue with external dependency and hash_newtype macro implementation Reverting back to the bitcoin_hashes crate after new version release

view details

Dr Maxim Orlovsky

commit sha f5a8087105828c5add858f8363d4fd0f8ba0a431

New hash types: MerkleRoot/Branch, WitnessCommit, SigHash, FilterHash

view details

Dr Maxim Orlovsky

commit sha 0abe15b1f6010991e33acacdb69fcb1935234bc3

Moving from BitcoinHash to Wtxid for Transactions

view details

Dr Maxim Orlovsky

commit sha 5fc24dea33ac8524e5e404fb8acd893d871cdfbd

Multiple fixes for hash types and their computing Unit test for wtxid and SegWit transactions

view details

Andrew Poelstra

commit sha 50f3a60712013d204dab138410ce2982d32266c6

Merge pull request #349 from pandoracore/hashtypes Hash new types as specified in #284

view details

Andrew Cann

commit sha d156c65778aa38a9bcdaf7c7d77e59bae55187f9

Fix serde struct macros deserialization impls The Deserialize impls generated by serde_struct_impl and serde_struct_human_string_impl need to be able to handle serialization formats which serialize structs as sequences (such as bincode). This commit adds visit_seq methods to the Visitor types defined by these macros, in addition to the existing visit_map methods. The implementation is taken directly from the serde docs: https://serde.rs/deserialize-struct.html

view details

push time in 2 months

pull request commentrust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

@dr-orlovsky I've extended the serde_round_trip! macro to use to do a round trip with bincode as well as json. Is that sufficient?

canndrew

comment created time in 2 months

push eventcanndrew/rust-bitcoin

Andrew Cann

commit sha 6095212467a07fefb6013393901e6402b9e19896

Fix serde struct macros deserialization impls The Deserialize impls generated by serde_struct_impl and serde_struct_human_string_impl need to be able to handle serialization formats which serialize structs as sequences (such as bincode). This commit adds visit_seq methods to the Visitor types defined by these macros, in addition to the existing visit_map methods. The implementation is taken directly from the serde docs: https://serde.rs/deserialize-struct.html

view details

push time in 2 months

Pull request review commentrust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

 macro_rules! serde_struct_impl {                         formatter.write_str("a struct")                     } +                    fn visit_seq<V>(self, mut seq: V) -> Result<Self::Value, V::Error>+                    where+                        V: $crate::serde::de::SeqAccess<'de>,+                    {+                        use $crate::serde::de::Error;++                        let length = 0;+                        $(+                            let $fe = seq.next_element()?.ok_or_else(|| {+                                Error::invalid_length(length, &self)+                            })?;+                            #[allow(unused_variables)]+                            let length = length + 1;+                        )*

This works fine the way it is. It's the way I usually write these sorts of macros. I can change it if you want though.

canndrew

comment created time in 2 months

issue commentrust-bitcoin/rust-bitcoin

Serializing then deserializing an OutPoint fails

I've PR'ed a fix for this: #375

canndrew

comment created time in 2 months

PR opened rust-bitcoin/rust-bitcoin

Fix serde struct macros deserialization impls

Fixes #374

The Deserialize impls generated by serde_struct_impl and serde_struct_human_string_impl need to be able to handle serialization formats which serialize structs as sequences (such as bincode).

This PR adds visit_seq methods to the Visitor types defined by these macros, in addition to the existing visit_map methods. The implementation is taken directly from the serde docs: https://serde.rs/deserialize-struct.html

+44 -0

0 comment

1 changed file

pr created time in 2 months

create barnchcanndrew/rust-bitcoin

branch : fix-serde-struct-macros

created branch time in 2 months

fork canndrew/rust-bitcoin

Rust Bitcoin library

fork in 2 months

issue openedrust-bitcoin/rust-bitcoin

Serializing then deserializing an OutPoint fails

This is easy to reproduce:

use bitcoin::hashes::{sha256d, Hash};
use bitcoin::OutPoint;

fn main() {
    let out_point = OutPoint {
        txid: sha256d::Hash::hash(&"foobar"[..]),
        vout: 0,
    };
    let serialized = bincode::serialize(&out_point).unwrap();

    // This line panics.
    let _deserialized: OutPoint = bincode::deserialize(&serialized).unwrap();
}

The error message is "invalid type: sequence, expected a struct"

created time in 2 months

issue commentrust-bitcoin/rust-bitcoin

Building with serde feature fails

Thanks y'all. I figured out I had to use use-serde instead of serde. This should probably be mentioned in the crate-level docs though, so I'm leaving this open for now.

canndrew

comment created time in 2 months

issue openedrust-bitcoin/rust-bitcoin

Building with serde feature fails

Both 0.21.0 (the latest published version) and master fail to build when features = ["serde"] is specified. On master, the error is:

error[E0463]: can't find crate for `hex`
  --> src/lib.rs:59:38
   |
59 | #[cfg(any(test, feature = "serde"))] extern crate hex;
   |                                      ^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `bitcoin`.

To learn more, run the command again with --verbose.

created time in 2 months

issue commenttokio-rs/tokio

Dropping an mpsc::Receiver deadlocks

Hi, sorry for the silence. My codebase is large and I wasn't able to trim it down to something that reproduces the issue. But it looks like you've fixed it anyway, so thanks for that :). I'll try to test it out in the next couple of days and report back.

canndrew

comment created time in 2 months

issue commentrust-lang/rfcs

Allow omission of unsatisfiable members in trait impls

This is also a dupe of https://github.com/rust-lang/rust/issues/20021

There's also this semi-related RFC: https://github.com/rust-lang/rfcs/pull/1699

alercah

comment created time in 2 months

issue openedtokio-rs/tokio

Dropping an mpsc::Receiver deadlocks

Version

tokio-0.2.2

Platform

Linux 5.0.0-36-generic #39~18.04.1-Ubuntu SMP x86_64 GNU/Linux

Description

I have a #[tokio::test] test which is failing to exit cleanly. The test spawns a bunch of tasks, does some work, then runs to completion, but when tokio tries to shut down it blocks forever. According to gdb this is happening because mpsc::Receiver::drop is calling mpsc::chan::Rx::drop which calls mpsc::chan::Tx::drop which tries to acquire a mutex and then deadlocks. Here's the full stack trace:

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff77b4023 in __GI___pthread_mutex_lock (mutex=0x7ffff0002690) at ../nptl/pthread_mutex_lock.c:78
#2  0x0000555555d687e5 in std::sys::unix::mutex::Mutex::lock (self=0x7ffff0002690) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/sys/unix/mutex.rs:55
#3  0x0000555555d68671 in std::sys_common::mutex::Mutex::raw_lock (self=0x7ffff0002690) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/sys_common/mutex.rs:36
#4  0x0000555555d79b05 in std::sync::mutex::Mutex<T>::lock (self=0x7ffff0002718) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/sync/mutex.rs:220
#5  0x0000555555d7ba08 in <tokio::runtime::basic_scheduler::SchedulerPriv as tokio::task::Schedule>::schedule (self=0x7ffff00026f0, task=...)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/runtime/basic_scheduler.rs:319
#6  0x00005555558bc075 in tokio::task::harness::Harness<T,S>::wake_by_ref (self=0x7ffff6df9db0) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:315
#7  0x00005555558bdddd in tokio::task::harness::Harness<T,S>::wake_by_val (self=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:299
#8  0x00005555557f3ed2 in tokio::task::waker::wake_by_val (ptr=0x7ffff0013290) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/waker.rs:84
#9  0x0000555555d86222 in core::task::wake::Waker::wake (self=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/task/wake.rs:252
#10 0x0000555555dc9aba in tokio::sync::task::atomic_waker::AtomicWaker::wake (self=0x7ffff00141d8) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/task/atomic_waker.rs:243
#11 0x000055555589b650 in <tokio::sync::mpsc::chan::Tx<T,S> as core::ops::drop::Drop>::drop (self=0x7ffff002e6f0)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/mpsc/chan.rs:236
#12 0x00005555557a4bb1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#13 0x00005555557b0d91 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#14 0x000055555579f9e1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#15 0x000055555579aae1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#16 0x000055555579d34f in core::ptr::real_drop_in_place () at src/ln/peer/msg_channel.rs:227
#17 0x00005555557ad641 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#18 0x00005555557a7cb4 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#19 0x000055555578c911 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#20 0x0000555555791e40 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#21 0x0000555555799465 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#22 0x000055555579ec88 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#23 0x00005555557b2188 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#24 0x000055555589a33f in <tokio::sync::mpsc::chan::Rx<T,S> as core::ops::drop::Drop>::drop::{{closure}} (rx_fields_ptr=0x7ffff0019018)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/mpsc/chan.rs:323
#25 0x0000555555729384 in tokio::loom::std::causal_cell::CausalCell<T>::with_mut (self=0x7ffff0019018, f=...)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/loom/std/causal_cell.rs:41
#26 0x000055555589896f in <tokio::sync::mpsc::chan::Rx<T,S> as core::ops::drop::Drop>::drop (self=0x7ffff0016a60)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/mpsc/chan.rs:320
#27 0x00005555557aa201 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#28 0x000055555579fbee in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#29 0x00005555557aebc5 in core::ptr::real_drop_in_place () at src/ln/peer/msg_channel_manager.rs:548
#30 0x00005555557a3171 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#31 0x00005555557b4257 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#32 0x00005555557a35e1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#33 0x00005555557a3ff1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#34 0x00005555557b42b4 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#35 0x000055555579c6f1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#36 0x00005555557b498e in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#37 0x000055555579e342 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#38 0x00005555556b97ca in tokio::task::core::Core<T>::transition_to_consumed (self=0x7ffff0017420) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/core.rs:106
#39 0x00005555558f0e84 in tokio::task::harness::Harness<T,S>::do_cancel::{{closure}}::{{closure}} () at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:363
#40 0x000055555578b933 in core::ops::function::FnOnce::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ops/function.rs:223
#41 0x0000555555673cd3 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=()) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:316
#42 0x0000555555778ad9 in std::panicking::try::do_call (data=0x7ffff6dfedc8 "") at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:287
#43 0x0000555555e2e30a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:81
#44 0x00005555557765fb in std::panicking::try (f=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:265
#45 0x0000555555674933 in std::panic::catch_unwind (f=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:395
#46 0x00005555558f029c in tokio::task::harness::Harness<T,S>::do_cancel::{{closure}} () at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:361
#47 0x000055555571fd48 in tokio::loom::std::causal_cell::CausalCell<T>::with_mut (self=0x7ffff0017420, f=...)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/loom/std/causal_cell.rs:41
#48 0x00005555558eda30 in tokio::task::harness::Harness<T,S>::do_cancel (self=..., res=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:359
#49 0x00005555558de852 in tokio::task::harness::Harness<T,S>::cancel (self=..., from_queue=true) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:342
#50 0x000055555594f5f2 in tokio::task::raw::cancel (ptr=0x7ffff00173f0, from_queue=true) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/raw.rs:196
#51 0x0000555555d491c7 in tokio::task::raw::RawTask::cancel_from_queue (self=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/raw.rs:145
#52 0x0000555555dba0a1 in tokio::task::Task<S>::shutdown (self=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/mod.rs:384
#53 0x0000555555d7ba9f in <tokio::runtime::basic_scheduler::SchedulerPriv as tokio::task::Schedule>::schedule (self=0x7ffff00026f0, task=...)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/runtime/basic_scheduler.rs:324
#54 0x00005555558bbf85 in tokio::task::harness::Harness<T,S>::wake_by_ref (self=0x7ffff6dff130) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:315
#55 0x00005555558bdcfd in tokio::task::harness::Harness<T,S>::wake_by_val (self=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:299
#56 0x00005555557f3f92 in tokio::task::waker::wake_by_val (ptr=0x7ffff00173f0) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/waker.rs:84
#57 0x0000555555d86222 in core::task::wake::Waker::wake (self=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/task/wake.rs:252
#58 0x0000555555dc9aba in tokio::sync::task::atomic_waker::AtomicWaker::wake (self=0x7ffff00168f8) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/task/atomic_waker.rs:243
#59 0x000055555589aa20 in <tokio::sync::mpsc::chan::Tx<T,S> as core::ops::drop::Drop>::drop (self=0x7ffff0017510)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/sync/mpsc/chan.rs:236
#60 0x0000555555793d31 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#61 0x000055555578c451 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#62 0x00005555557b47f1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#63 0x00005555557b07c1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#64 0x00005555557c7502 in core::ptr::drop_in_place (to_drop=0x7ffff0017510) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:171
#65 alloc::sync::Arc<T>::drop_slow (self=0x7ffff00197e8) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/sync.rs:706
#66 0x00005555557ce086 in <alloc::sync::Arc<T> as core::ops::drop::Drop>::drop (self=0x7ffff00197e8) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/sync.rs:1234
#67 0x00005555557ab10e in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#68 0x00005555557a86f6 in core::ptr::real_drop_in_place () at src/ln/peer/manager.rs:110
#69 0x0000555555796ba1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#70 0x00005555557b1c37 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#71 0x00005555557a1751 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#72 0x00005555557a2171 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#73 0x00005555557a4fe4 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#74 0x000055555578c8f1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#75 0x000055555579a84e in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#76 0x00005555557aa402 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#77 0x00005555556b98ca in tokio::task::core::Core<T>::transition_to_consumed (self=0x7ffff00149e0) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/core.rs:106
#78 0x00005555558f0f04 in tokio::task::harness::Harness<T,S>::do_cancel::{{closure}}::{{closure}} () at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:363
#79 0x0000555555789393 in core::ops::function::FnOnce::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ops/function.rs:223
#80 0x0000555555673de3 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=()) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:316
#81 0x0000555555778f19 in std::panicking::try::do_call (data=0x7ffff6dff578 "\260\366\337\366\377\177") at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:287
#82 0x0000555555e2e30a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:81
#83 0x000055555577628b in std::panicking::try (f=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:265
#84 0x0000555555674543 in std::panic::catch_unwind (f=...) at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:395
#85 0x00005555558f01ac in tokio::task::harness::Harness<T,S>::do_cancel::{{closure}} () at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:361
#86 0x0000555555729988 in tokio::loom::std::causal_cell::CausalCell<T>::with_mut (self=0x7ffff00149e0, f=...)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/loom/std/causal_cell.rs:41
#87 0x00005555558ee8d0 in tokio::task::harness::Harness<T,S>::do_cancel (self=..., res=...) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:359
#88 0x00005555558df4b2 in tokio::task::harness::Harness<T,S>::cancel (self=..., from_queue=false) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/harness.rs:342
#89 0x000055555594f5b2 in tokio::task::raw::cancel (ptr=0x7ffff00149b0, from_queue=false) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/raw.rs:196
#90 0x0000555555dc022b in tokio::task::list::OwnedList<T>::shutdown (self=0x7ffff00026f0) at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/task/list.rs:68
#91 0x0000555555d7be53 in <tokio::runtime::basic_scheduler::BasicScheduler<P> as core::ops::drop::Drop>::drop (self=0x7ffff6dff970)
    at /home/shum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.2/src/runtime/basic_scheduler.rs:359
#92 0x0000555555791935 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#93 0x000055555578c977 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#94 0x0000555555796fc1 in core::ptr::real_drop_in_place () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ptr/mod.rs:181
#95 0x00005555557f651a in geelightning::ln::peer::manager::test::connect_two_peer_managers () at src/ln/peer/manager.rs:176
#96 0x00005555559429fa in geelightning::ln::peer::manager::test::connect_two_peer_managers::{{closure}} () at src/ln/peer/manager.rs:176
#97 0x0000555555788fee in core::ops::function::FnOnce::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ops/function.rs:223
#98 0x00005555559c5e2f in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/boxed.rs:942
#99 0x0000555555e2e30a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:81
#100 0x00005555559e180a in std::panicking::try () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:265
#101 std::panic::catch_unwind () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:395
#102 test::run_test_in_process () at src/libtest/lib.rs:570
#103 test::run_test::run_test_inner::{{closure}} () at src/libtest/lib.rs:473
#104 0x00005555559ba696 in std::sys_common::backtrace::__rust_begin_short_backtrace () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/sys_common/backtrace.rs:136
#105 0x00005555559beae6 in std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}} () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/thread/mod.rs:469
#106 <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:316
#107 std::panicking::try::do_call () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:287
#108 0x0000555555e2e30a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:81
#109 0x00005555559bf476 in std::panicking::try () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panicking.rs:265
#110 std::panic::catch_unwind () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/panic.rs:395
#111 std::thread::Builder::spawn_unchecked::{{closure}} () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libstd/thread/mod.rs:468
#112 core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/ops/function.rs:223
#113 0x0000555555e192ef in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/boxed.rs:942
#114 0x0000555555e2d7e0 in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once () at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/boxed.rs:942
#115 std::sys_common::thread::start_thread () at src/libstd/sys_common/thread.rs:13
#116 std::sys::unix::thread::Thread::new::thread_start () at src/libstd/sys/unix/thread.rs:79
#117 0x00007ffff77b16db in start_thread (arg=0x7ffff6e02700) at pthread_create.c:463
#118 0x00007ffff72c288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

My code was working fine with tokio-0.2.0-alpha.5. I've only hit this problem with trying to upgrade to tokio-0.2.2. Interestingly, I had previously been using futures::channel::mpsc channels but swapped them out for tokio channels in attempt to fix this bug, only to find that tokio's channels are deadlocking in the exact same way (Receiver::drop() -> Sender::drop() -> deadlock). I also had what seems like a similar problem in my own channel-like type that I had written where a lock was being shared between a sender and a receiver, and after upgrading to tokio-0.2.2 their destructors would call each other via wake and deadlock. I was able to fix that in my own code by releasing the lock before calling wake. Based on the stack trace it looks like something similar could be happening here.

created time in 3 months

PR opened servo/smallbitvec

Add insert method

Add a method to insert bits at arbitrary indexes.

+154 -0

0 comment

2 changed files

pr created time in 3 months

create barnchcanndrew/smallbitvec

branch : insert

created branch time in 3 months

PR opened servo/smallbitvec

Add count_ones, count_zeros methods

Pretty self-explanatory. Add methods for counting the number of ones/zeros in a SmallBitVec.

+79 -0

0 comment

2 changed files

pr created time in 3 months

create barnchcanndrew/smallbitvec

branch : count_ones_zeros

created branch time in 3 months

fork canndrew/smallbitvec

A growable bit-vector for Rust, optimized for size

fork in 3 months

issue commentrust-lang/rfcs

Test timeouts

I'd expect anything here to mostly happen in custom test frameworks.

The default test framework that ships with rust should support this though. It's a small but necessary feature.

I think the timeout should be passed to the #[test] attribute as an argument. eg.

#[test(timeout = "200ms")]
fn my_cool_test() {}

or

#[test(timeout = Duration::new(1, 0))]
fn my_cool_test() {}
clarfon

comment created time in 3 months

issue commentrust-lang-nursery/futures-rs

Add Mutex::poll_lock method

Presumably this would have to return some kind of token and be paired with a Mutex::{abandon/deregister/bikeshed} call in Drop::drop to allow you to deregister interest in the Mutex if your future is canceled.

Not really. You could just accept that the task the future was running on would get a spurious wakeup.

You would also need to store the MutexGuard somewhere if do some stuff isn't entirely synchronous calls.

Yeah, if you want to do something async in do some stuff then you're back at square one.

canndrew

comment created time in 3 months

issue openedrust-lang-nursery/futures-rs

Add Mutex::poll_lock method

I just had a bug in some code that looks like this:

use futures::lock::Mutex;

struct MySender {
    inner: Arc<Mutex<Inner>>,
}

struct MyReceiver {
    inner: Arc<Mutex<Inner>>,
}

impl Future for MyReceiver {
    fn poll(self: Pin<&mut Self>, cx: &mut Context) -> Poll<()> {
        if let Poll::Ready(inner) = Pin::new(&mut self.get_mut().inner.lock()).poll(cx) {
            // do some stuff
            return Poll::Ready(());
        }
        Poll::Pending
    }
}

The bug is that the MutexLockFuture returned by Mutex::lock deregisters itself when it gets dropped. So if I poll MyReceiver and the lock is held the task won't get woken up again when the lock is released. AFAICT my options for fixing this are:

  1. Store the MutexLockFuture inside MyReceiver. This is inconvenient and inefficient since MutexLockFuture borrows the Mutex and so I'd need to use rental and an extra layer of boxing.
  2. Implement MyReceiver with an async block/function instead of implementing Future directly. Again this means an extra layer of boxing. Also I'm trying to implement a low-level primitive here and I'd rather just implement Future directly.
  3. Use a std non-async Mutex. This is obviously less than ideal, though I know in my case the lock won't get held for very long.

At the moment I've gone for option (2) since it's the laziest option, but it would be nice if there was a simple way to do this properly.

Could we add a poll_lock method to Mutex which allows me to use the Mutex in the buggy way I attempted above?

created time in 3 months

issue commentservo/smallbitvec

Add shrink_to_fit method

Actually, while I'm at it, it would be nice to have count_ones/count_zeros methods. It's easy to write .iter().filter(|&b| b).count() but a simple method would be clearer. These methods already exist on Rust's built-in int types so there's precedent for it.

I could also make use of impls for Bit{And,Or,Xor}Assign.

canndrew

comment created time in 4 months

issue openedservo/smallbitvec

Add shrink_to_fit method

Similar to Vec::shrink_to_fit.

Should I just make a PR for this or is there a reason it doesn't exist already?

created time in 4 months

issue commentrust-lang/rfcs

Add impl TryFrom<T> for E where E is a C-like #[repr(T)] enum

If I make a PR for this is it likely to get merged?

canndrew

comment created time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.40.0

However I disagree with dumping all the responsibility on a maintainer who dared violate a rule they probably didn’t know about.

I think it's "technically" their responsibility but that the Rust team should be extremely patient with crate authors who are violating rules while giving them time to bring things in line (particularly if it's a crate with a lot of users). Three years is really stretching patience though, except that apparently the author had no idea about the problem which says more about all of us involved in the ongoing conversation around this then it does about them.

Centril

comment created time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.40.0

Users of objc had no idea this was going on.

If you use a broken crate, you get broken code. Relying on compiler behaviour which is subject to change - in unsafe code no less - is always a bug, even if it wasn't previously rearing its head. It's not the Rust team's responsibility to avoid triggering latent bugs in people's code with new releases. We should take effort to avoid it out of common decency, but this change has been blocked on this for three years now. If the maintainer of objc hasn't fixed his code and yanked the effected versions then he is the one who his users should complain to when his bug breaks their code.

Centril

comment created time in 4 months

issue openedrust-lang/rfcs

Add impl TryFrom<T> for E where E is a C-like #[repr(T)] enum

This is a problem that has come up a lot. The most recent discussion I could find about it is the internals thread here, but that thread has been locked and I figured this should probably have an "official" issue somewhere.

There's currently no (good) way to convert from an enum integer discriminant value to the enum itself. Enums should support deriving TryFrom for the purpose. eg.

#[repr(u32)]
#[derive(TryFrom)]
enum MyCoolEnum {
    Foo = 1,
    Bar = 2,
}

let x: u32 = ... ;
let my_cool_enum = MyCoolEnum::try_from(x).expect("invalid discriminant!");

created time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.40.0

Sorry to reiterate a point that's been made, but I first tried to push through this change in 2016 (!) and if nothing has been done to help the objc users who are hit by this issue in the time since then I can't imagine that anything ever will. In the mean time, every day/year that we delay this change is more time for people to write broken code that depends on the old fallback behaviour. This is a rare corner case and it only happens in unsafe code relying on inference behaviour which the language spec explictly tells people they're not allowed to rely on. People shouldn't rely on behaviour they've been told they're not allowed to rely on. Particularly in unsafe code. At what point are we allowed to say "fuck it" and push this through? What's the point of carving out a clause in the stability guarantees that says we're allowed to change this if we're not willing to change it?

Centril

comment created time in 4 months

issue openedagda/agda

cannot declare data types in Setω

On agda master branch this code no longer compiles:

open import Agda.Primitive

data Foo : Setω where

created time in 5 months

issue commentrust-lang/rfcs

Arrays should impl the bitwise operations

Or to put it another way: the bitwise operations aren't really mathematical operations. They're operations on collections of bools of the shape.

canndrew

comment created time in 5 months

issue commentrust-lang/rfcs

Arrays should impl the bitwise operations

Yeah, I wouldn't advocate for + or * to be implemented on arrays - would it work element-wise? Would the results overflow to the next element (treating the whole array as one giant int)? Would multiplication be a dot product? Would it return a matrix of results? There's no single, obvious semantics here.

For bitwise operations though there is a single obvious semantics. Bitwise operations already work element-wise (which is why they're implemented for types like HashSet and BTreeSet). I can't imagine anyone getting confused by the semantics of this or expecting a different semantics.

canndrew

comment created time in 5 months

issue openedrust-lang/rfcs

Arrays should impl the bitwise operations

I have a couple [u8; 8]s that I'd like to xor with each other. Unfortunately this doesn't work:

let x = [0u8; 8];
let y = [1u8; 8];
let z = x ^ y;

I think it should, since this has pretty clear semantics. More generally I think it would make sense to have an impl:

impl<const N: usize, A, B> BitXor<[B; N]> for [A; N]
where
    A: BitXor<B>,
{
    type Output = [<A as BitXor<B>>::Output; N];

    fn bitxor(self, rhs: [B; N]) -> Self::Output {
        ...
    }
}

And similar for BitAnd and BitOr.

created time in 5 months

issue commentagda/agda

Add a pragma for telling agda that a definition is injective

@nad is it supposed to work with functions, like I've done in my code (declaring Ctx as injective)?

canndrew

comment created time in 5 months

issue commentagda/agda

Add a pragma for telling agda that a definition is injective

It's totally unsound though without the proof. Is it sound with the proof?

Also it doesn't appear to be working for me 😞. Here's my code:

module core where

open import Agda.Primitive

data Lev : Set where
    lev-zero : Lev
    lev-succ : Lev -> Lev

interp : Lev -> Level
interp lev-zero = lzero
interp (lev-succ lev) = lsuc (interp lev)

Ctx :
    (l : Lev) ->
    Set (lsuc (interp l))

Type :
    {ctx-l : Lev} ->
    (type-l : Lev) ->
    Ctx ctx-l ->
    Set ((interp ctx-l) ⊔ (lsuc (interp type-l)))

Ctx l = Set (interp l)
Type {ctx-l} type-l ctx = ctx -> Set (interp type-l)

{-# INJECTIVE interp #-}
{-# INJECTIVE Ctx #-}

data $cons
    {ctx-l}
    {type-l} :
    (ctx : Ctx ctx-l) ->
    (type : Type {- UNSOLVED META HERE -} type-l ctx) ->
    Set where

If you try to compile this it says there's an unsolved meta in the definition of $cons where I've written UNSOLVED META HERE. This should work if Ctx is injective - ctx has type Ctx ctx-l, so the {ctx-l} argument to Type must be ctx-l.

canndrew

comment created time in 5 months

issue commentagda/agda

Add a pragma for telling agda that a definition is injective

Oh cool! I'm curious why it doesn't require a proof of injectivity though? It wouldn't be any more restrictive since you could just postulate the proof if need be.

canndrew

comment created time in 5 months

issue openedagda/agda

Add a pragma for telling agda that a definition is injective

Agda has REWRITE rules for turning a propositional equality into a definitional equality. Could we have something similar for injectivity? That is, agda's unifier can often use foo x ≡ foo y to infer x ≡ y, but this only works when it can see that foo is injective from the definition of foo. I'm in a situation where I can prove that foo is injective propositionally and I'd like to make use of the same inference behavior. It would be nice if it was possible to do this using something like:

foo-injective : {x y} -> (foo x ≡ foo y) -> x ≡ y
foo-injective = ...

{-# INJECTIVE foo foo-injective #-}

(Note: I'm an Agda noob so maybe this already possible in some way that I'm not familiar with, but it didn't seem that way based on my conversations on irc)

created time in 5 months

pull request commentivy-lang/ivy-bitcoin

Provide a command-line compiler (as its own npm package)

@danrobinson Would it be possible to publish ivy-compiler as it's own npm package?

knocte

comment created time in 5 months

issue openedrust-lang/rfcs

Add a location! macro for creating a std::panic::Location

The standard library already has file!, line! and column! macros which return values expressing the location in the code where the macro was called. If I need to pass these values around I usually just want to wrap them into some kind of struct which holds all three values. The standard library already has a struct which does just this - std::panic::Location - but there's no way to construct one (other than by panicking).

Could we just add another macro, next to file!/line!/column!, which creates a Location directly?

created time in 5 months

issue commentrust-lang-nursery/futures-rs

Syntax sugar for select! when using futures that return () or !

You can currently already write_ = unit_future()

I don't think that's a good idea since it's not clear that you're throwing away a (). Also unit_future might get changed in the future to return something else in which case this code will start silently throwing away something other than () when it would be preferable to make this line of code fail type-checking instead.

Really though I'm more interested in syntax sugar for !-futures. Having to write () = is not a big deal.

canndrew

comment created time in 5 months

issue openedmimblewimble/grin-wallet

fatal error: 'stdbool.h' file not found

I'm having trouble building grin wallet on Ubuntu. The dependency croaring-sys is failing to build with the error:

CRoaring/roaring.h:37:10: fatal error: 'stdbool.h' file not found

Is there a native dependency missing? I have the build-essential and libclang-dev packages installed.

created time in 5 months

more