💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336038391)
> How is the typedef used?
As in the diff I shared (https://github.com/stickies-v/bitcoin/commit/1880fba34c32ee4b9fe350f062dfbc27aa3db181), everything else stays the same:
- consumers use the typedef to define the size of enums, e.g. `enum class ChainType : btck_ChainType {`
- API only deals with the typedefs, e.g. `btck_ChainParameters* btck_chain_parameters_create(const btck_ChainType chain_type)`, so even though the user _can_ abuse the `Value` enum, they would be going against the int
...
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336038391)
> How is the typedef used?
As in the diff I shared (https://github.com/stickies-v/bitcoin/commit/1880fba34c32ee4b9fe350f062dfbc27aa3db181), everything else stays the same:
- consumers use the typedef to define the size of enums, e.g. `enum class ChainType : btck_ChainType {`
- API only deals with the typedefs, e.g. `btck_ChainParameters* btck_chain_parameters_create(const btck_ChainType chain_type)`, so even though the user _can_ abuse the `Value` enum, they would be going against the int
...
💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336084393)
Actually, anonymous enums would make more sense than named ones:
```cpp
typedef uint8_t btck_ChainType;
enum {
btck_ChainType_MAINNET = 0,
btck_ChainType_TESTNET = 1,
btck_ChainType_TESTNET_4 = 2,
btck_ChainType_SIGNET = 3,
btck_ChainType_REGTEST = 4
};
```
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336084393)
Actually, anonymous enums would make more sense than named ones:
```cpp
typedef uint8_t btck_ChainType;
enum {
btck_ChainType_MAINNET = 0,
btck_ChainType_TESTNET = 1,
btck_ChainType_TESTNET_4 = 2,
btck_ChainType_SIGNET = 3,
btck_ChainType_REGTEST = 4
};
```
💬 purpleKarrot commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336089748)
@stickies-v, this is how I currently implement the python bindings for flags: https://github.com/purpleKarrot/btck/blob/master/bindings/python/src/verification_flags.c
This is how they are combined: https://github.com/purpleKarrot/btck/blob/master/test/python/test_script.py#L18
How do you make sure that only binary operators can be used on flags when you bind them with ctypes/clang2py? If the answer is "not", then I would stay away from binding generators and stick to handwritten language
...
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336089748)
@stickies-v, this is how I currently implement the python bindings for flags: https://github.com/purpleKarrot/btck/blob/master/bindings/python/src/verification_flags.c
This is how they are combined: https://github.com/purpleKarrot/btck/blob/master/test/python/test_script.py#L18
How do you make sure that only binary operators can be used on flags when you bind them with ctypes/clang2py? If the answer is "not", then I would stay away from binding generators and stick to handwritten language
...
👍 vasild approved a pull request: "txgraph: use enum Level instead of bool main_only"
(https://github.com/bitcoin/bitcoin/pull/33354#pullrequestreview-3205037327)
ACK b9af83e72c60c1ee71251cf9f3dbae0ffccbe305
Passing enum values with meaningful names seems better and more readable than passing `true` / `false` or omitting the argument.
(https://github.com/bitcoin/bitcoin/pull/33354#pullrequestreview-3205037327)
ACK b9af83e72c60c1ee71251cf9f3dbae0ffccbe305
Passing enum values with meaningful names seems better and more readable than passing `true` / `false` or omitting the argument.
💬 vasild commented on pull request "txgraph: use enum Level instead of bool main_only":
(https://github.com/bitcoin/bitcoin/pull/33354#discussion_r2335974694)
Can be written as:
```cpp
for (auto level : { TxGraph::Level::TOP, TxGraph::Level::MAIN }) {
```
(https://github.com/bitcoin/bitcoin/pull/33354#discussion_r2335974694)
Can be written as:
```cpp
for (auto level : { TxGraph::Level::TOP, TxGraph::Level::MAIN }) {
```
💬 rkrux commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2336149483)
Didn't intend to suggest fixing it in this PR, instead highlighting an issue that could probably be fixed by the other PR if/when it's merged.
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2336149483)
Didn't intend to suggest fixing it in this PR, instead highlighting an issue that could probably be fixed by the other PR if/when it's merged.
💬 Eunovo commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2336183930)
https://github.com/bitcoin/bitcoin/pull/33336/commits/64ba2821b5a55aa6d51fbb7a16470d4f7c41c92e:
I believe you now need to add `GUARDED_BY(::cs_main)` here to use Clang's Thread Safety Analysis
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2336183930)
https://github.com/bitcoin/bitcoin/pull/33336/commits/64ba2821b5a55aa6d51fbb7a16470d4f7c41c92e:
I believe you now need to add `GUARDED_BY(::cs_main)` here to use Clang's Thread Safety Analysis
💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274322377)
@theuni fixed the approach.
Guix Build:
```bash
5141913f22cb29c0ca33940885558eb87c97cb59a427ede1862086276934bfc4 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/SHA256SUMS.part
05ea65e57ef36c7dc24c042001b297ff9a0ddf50e12da8d6f2b298cb8801725d guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-linux-gnu-debug.tar.gz
0f1a7b1fcd1719b916d3527b545eb959cd909692810be29a1ae20f5e4c4834c8 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-lin
...
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274322377)
@theuni fixed the approach.
Guix Build:
```bash
5141913f22cb29c0ca33940885558eb87c97cb59a427ede1862086276934bfc4 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/SHA256SUMS.part
05ea65e57ef36c7dc24c042001b297ff9a0ddf50e12da8d6f2b298cb8801725d guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-linux-gnu-debug.tar.gz
0f1a7b1fcd1719b916d3527b545eb959cd909692810be29a1ae20f5e4c4834c8 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-lin
...
💬 Raimo33 commented on pull request "node: optimize CBlockIndexWorkComparator":
(https://github.com/bitcoin/bitcoin/pull/33334#discussion_r2336380536)
https://godbolt.org/z/6TjP137z1
Looks like the current version wins both on x86 and arm, but I'm no assembly expert.
(https://github.com/bitcoin/bitcoin/pull/33334#discussion_r2336380536)
https://godbolt.org/z/6TjP137z1
Looks like the current version wins both on x86 and arm, but I'm no assembly expert.
👍 hebasto approved a pull request: "Avoid pathological QT text/markdown behavior..."
(https://github.com/bitcoin-core/gui/pull/886#pullrequestreview-3205692804)
ACK 6a371b70c87ad6b763c89384562fce8549f37434.
(https://github.com/bitcoin-core/gui/pull/886#pullrequestreview-3205692804)
ACK 6a371b70c87ad6b763c89384562fce8549f37434.
🚀 hebasto merged a pull request: "Avoid pathological QT text/markdown behavior..."
(https://github.com/bitcoin-core/gui/pull/886)
(https://github.com/bitcoin-core/gui/pull/886)
✅ hebasto closed an issue: "Copying output from console causes large mem usage/OOM"
(https://github.com/bitcoin-core/gui/issues/887)
(https://github.com/bitcoin-core/gui/issues/887)
💬 hebasto commented on pull request "Avoid pathological QT text/markdown behavior...":
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274536092)
@fanquake
Backport to 30.x?
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274536092)
@fanquake
Backport to 30.x?
💬 TheCharlatan commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336447807)
I'm a bit confused about this first commit. What exactly is it supposed to fix? FWIW the `-help` for `bitcoin-node` is still:
```
./build_dev_mode_clang/bin/bitcoin-node -help | head -n 12 PIPE|0 ✔ 13:28:55
Bitcoin Core daemon version v30.99.0-2c8a478db4b8
The Bitcoin Core daemon (bitcoind) is a headless program that connects to the Bitcoin network to validate and relay transactions and blocks, as well as rela
...
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336447807)
I'm a bit confused about this first commit. What exactly is it supposed to fix? FWIW the `-help` for `bitcoin-node` is still:
```
./build_dev_mode_clang/bin/bitcoin-node -help | head -n 12 PIPE|0 ✔ 13:28:55
Bitcoin Core daemon version v30.99.0-2c8a478db4b8
The Bitcoin Core daemon (bitcoind) is a headless program that connects to the Bitcoin network to validate and relay transactions and blocks, as well as rela
...
💬 willcl-ark commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274539118)
This appears to have been tagged 3 hours ago, so I think we can close this?
https://github.com/llvm/llvm-project/tags
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274539118)
This appears to have been tagged 3 hours ago, so I think we can close this?
https://github.com/llvm/llvm-project/tags
💬 fanquake commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274547337)
Yea tag exists, but the potential for it to be broken still the same for every new release.
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274547337)
Yea tag exists, but the potential for it to be broken still the same for every new release.
💬 willcl-ark commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274559080)
Because they have an apt packaged version for a while before a GH tag?
Is there anything else we can do about that, other than make sure we only run the latest (GH) tag, rather then the most bleeding-edge apt package?
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274559080)
Because they have an apt packaged version for a while before a GH tag?
Is there anything else we can do about that, other than make sure we only run the latest (GH) tag, rather then the most bleeding-edge apt package?
💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274577287)
Added dropping libatomic from `symbol-check.py`.
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274577287)
Added dropping libatomic from `symbol-check.py`.
📝 fanquake opened a pull request: "[30.0] rc2 backports"
(https://github.com/bitcoin/bitcoin/pull/33356)
Backports:
* https://github.com/bitcoin-core/gui/pull/886
(https://github.com/bitcoin/bitcoin/pull/33356)
Backports:
* https://github.com/bitcoin-core/gui/pull/886
💬 fanquake commented on pull request "Avoid pathological QT text/markdown behavior...":
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274585088)
Backported to 30.x in https://github.com/bitcoin/bitcoin/pull/33356.
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274585088)
Backported to 30.x in https://github.com/bitcoin/bitcoin/pull/33356.