✅ hebasto closed an issue: "Copying output from console causes large mem usage/OOM"
(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?

💬 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
...

💬 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

💬 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.

💬 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?

💬 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`.

📝 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

💬 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.

💬 ryanofsky commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336488629)
> I'm a bit confused about this first commit. What exactly is it supposed to fix?

Just to clarify here (I can also update the commit message) this first commit adds the binary name to `-version` output (`-help` output may be different) as a way of giving the functional test an easy way to detect whether correct binary was called.

💬 fanquake commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274603532)
I think just using the a (recent) tag is fine, and avoids this issue entirely, rather than trying to match the `libcxx` build to whichever point release of Clang is being installed via apt.

💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336501679)
[C23 compiler support](https://en.cppreference.com/w/c/compiler_support/23.html) is still early and limited, but [typed enums](https://open-std.org/JTC1/SC22/WG14/www/docs/n3030.htm) would offer increased type safety to users that want it?

```C
/* C23-aware enum definitions */
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L && !defined(__cplusplus)
/**
* For C23 and later, use a strongly-typed enum. This creates a distinct type
* which is not implicitly convert
...

💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336505385)
> How do you make sure that only binary operators can be used on flags when you bind them with ctypes/clang2py?

I haven't implemented that yet, but that seems like an orthogonal concern - and at first thought I don't see why that wouldn't be possible with ctypes?

💬 Sjors commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336519638)
This seems useful enough even outside the test suite. E.g. when a user files a bug report it's good to know whether we ran `bitcoind` or `bitcoin-node`, and instructing them to do `bitcoin -version` is a lot easier than to look at process names.

I would be fine with also adding it to `-help`, but there it's less relevant.

💬 sipa commented on pull request "txgraph: use enum Level instead of bool main_only":
(https://github.com/bitcoin/bitcoin/pull/33354#discussion_r2336531027)
Indeed, done!

💬 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_r2336547527)
Right, I think I missed the context, because the changed lines also run when processing the help command. Should we fix the output?
```diff
diff --git a/src/bitcoind.cpp b/src/bitcoind.cpp
index a4373dafdf..e046be19aa 100644
--- a/src/bitcoind.cpp
+++ b/src/bitcoind.cpp
@@ -140 +140,3 @@ static bool ProcessInitCommands(interfaces::Init& init, ArgsManager& args)
- if (const char* exe_name{init.exeName()}) {
+ const char* exe_name_ptr = init.exeName();
+ std::string e
...

👍 vasild approved a pull request: "txgraph: use enum Level instead of bool main_only"
(https://github.com/bitcoin/bitcoin/pull/33354#pullrequestreview-3205867427)
ACK d45f3717d2c65d1a6012a4bc2f47ff75004fd171

💬 instagibbs commented on pull request "txgraph: use enum Level instead of bool main_only":
(https://github.com/bitcoin/bitcoin/pull/33354#issuecomment-3274757427)
concept ACK, having the two values was never confusing, it just took mental load to figure out what the implied argument meant in each context (and lead to bugs too)

💬 Raimo33 commented on issue "Higher **reported** memory usage of Bitcoin Core after version 29":
(https://github.com/bitcoin/bitcoin/issues/33351#issuecomment-3274820688)
looks like a `top` issue to me.

💬 sipa commented on issue "Higher **reported** memory usage of Bitcoin Core after version 29":
(https://github.com/bitcoin/bitcoin/issues/33351#issuecomment-3274837345)
Yeah, it's just a reporting issue.

The behavior is largely unchanged: the OS will cache disk content in memory regardless if there is a spare physical memory. The difference is that with (more) mmap'ed content, that memory usage will be accounted for by the process itself as shared memory, while otherwise it'll be accounted for as kernel disk cache memory.