Log PoW zero bits progress #8

Merged
cryptoquick merged 4 commits from PoW-improvements into master 2023-04-22 11:59:31 +12:00
cryptoquick commented 2023-04-02 02:18:47 +12:00 (Migrated from github.com)

This is helpful for if you have gossip started from CLI, at least. I'm not sure of a good way to stream updates, but that can be added later. For testing, see this branch:

https://github.com/cryptoquick/gossip/tree/PoW-improvements

I then installed it locally with this:

RUSTFLAGS="-Ctarget-cpu=native --cfg tokio_unstable" cargo install --path .

Screenshot:

Screenshot from 2023-04-01 08-18-14

This is helpful for if you have gossip started from CLI, at least. I'm not sure of a good way to stream updates, but that can be added later. For testing, see this branch: https://github.com/cryptoquick/gossip/tree/PoW-improvements I then installed it locally with this: `RUSTFLAGS="-Ctarget-cpu=native --cfg tokio_unstable" cargo install --path .` Screenshot: ![Screenshot from 2023-04-01 08-18-14](https://user-images.githubusercontent.com/285690/229294672-467f3286-fabd-4324-82db-c878da5f53e6.png)
cryptoquick commented 2023-04-02 02:20:54 +12:00 (Migrated from github.com)

It might be cool to have timestamps on this too somehow... But that might need to be added in the client itself.

It might be cool to have timestamps on this too somehow... But that might need to be added in the client itself.
mikedilger commented 2023-04-03 12:57:32 +12:00 (Migrated from github.com)

Interesting.

println!() isn't appropriate for a library. We could make new_with_pow() an async function and also pass back a mpsc channel were these messages are written as structs by the threads into the channel.

Interesting. println!() isn't appropriate for a library. We could make new_with_pow() an async function and also pass back a mpsc channel were these messages are written as structs by the threads into the channel.
cryptoquick commented 2023-04-03 14:45:35 +12:00 (Migrated from github.com)

Great point! Though, wouldn't you pass in an mpsc, not return one? Something like tracer can consume messages produced by this method, and others.

Great point! Though, wouldn't you pass in an mpsc, not return one? Something like tracer can consume messages produced by this method, and others.
mikedilger commented 2023-04-03 14:54:30 +12:00 (Migrated from github.com)

Yeah prob have to pass it in, since async has to return a future.

Yeah prob have to pass it in, since async has to return a future.
cryptoquick commented 2023-04-17 11:29:16 +12:00 (Migrated from github.com)

I just added an MPSC sender, does that look good to you? Just know, this would require blocking IO, I'm not sure if you wanted to use tokio's async channel types instead (a whole copy of the entire tokio runtime is not necessary to just have the type).

I just added an MPSC sender, does that look good to you? Just know, this would require blocking IO, I'm not sure if you wanted to use tokio's async channel types instead (a whole copy of the entire tokio runtime is not necessary to just have the type).
mikedilger commented 2023-04-20 09:15:39 +12:00 (Migrated from github.com)

std::sync::mpsc::Sender is fine since it will never block.

It should be optional.

std::sync::mpsc::Sender is fine since it will never block. It should be optional.
cryptoquick commented 2023-04-20 16:21:25 +12:00 (Migrated from github.com)

Okay, I've made the argument optional and renamed it to msg_sender, which might be more self-documenting.

Okay, I've made the argument optional and renamed it to `msg_sender`, which might be more self-documenting.
Sign in to join this conversation.
No description provided.