💬 hebasto commented on pull request "common: Close non-std fds before exec in RunCommandJSON":
(https://github.com/bitcoin/bitcoin/pull/32343#issuecomment-2832694789)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32343#issuecomment-2832694789)
Concept ACK.
💬 maflcko commented on pull request "[29.x] qt: 29.1 translations update":
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833289993)
The erroneous format specs still remain: https://github.com/bitcoin/bitcoin/issues/32295#issuecomment-2827238571
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833289993)
The erroneous format specs still remain: https://github.com/bitcoin/bitcoin/issues/32295#issuecomment-2827238571
💬 maflcko commented on pull request "common: Close non-std fds before exec in RunCommandJSON":
(https://github.com/bitcoin/bitcoin/pull/32343#issuecomment-2833334943)
The error seems to be intermittent, because now it looks like the centos task passed. (For reference, the failure three days ago was https://github.com/bitcoin/bitcoin/runs/41112451543)
(https://github.com/bitcoin/bitcoin/pull/32343#issuecomment-2833334943)
The error seems to be intermittent, because now it looks like the centos task passed. (For reference, the failure three days ago was https://github.com/bitcoin/bitcoin/runs/41112451543)
👍 hebasto approved a pull request: "test: avoid stack overflow in `FindChallenges` via manual iteration"
(https://github.com/bitcoin/bitcoin/pull/32351#pullrequestreview-2797575186)
ACK 2e533cf86a42b3416c1164d04089e80ffe622dd6, I have reviewed the code and it looks OK.
If we put refactoring aside, the changes in this PR could be much smaller and easier to review with `git diff --ignore-all-space`:
```diff
--- a/src/test/miniscript_tests.cpp
+++ b/src/test/miniscript_tests.cpp
@@ -297,9 +297,13 @@ using miniscript::operator""_mst;
using Node = miniscript::Node<CPubKey>;
/** Compute all challenges (pubkeys, hashes, timelocks) that occur in a given Miniscript. */
...
(https://github.com/bitcoin/bitcoin/pull/32351#pullrequestreview-2797575186)
ACK 2e533cf86a42b3416c1164d04089e80ffe622dd6, I have reviewed the code and it looks OK.
If we put refactoring aside, the changes in this PR could be much smaller and easier to review with `git diff --ignore-all-space`:
```diff
--- a/src/test/miniscript_tests.cpp
+++ b/src/test/miniscript_tests.cpp
@@ -297,9 +297,13 @@ using miniscript::operator""_mst;
using Node = miniscript::Node<CPubKey>;
/** Compute all challenges (pubkeys, hashes, timelocks) that occur in a given Miniscript. */
...
✅ hebasto closed a pull request: "test: Increase stack size for "Debug" builds with MSVC"
(https://github.com/bitcoin/bitcoin/pull/32349)
(https://github.com/bitcoin/bitcoin/pull/32349)
💬 hebasto commented on pull request "test: Increase stack size for "Debug" builds with MSVC":
(https://github.com/bitcoin/bitcoin/pull/32349#issuecomment-2833346711)
Closing in favour of https://github.com/bitcoin/bitcoin/pull/32351.
(https://github.com/bitcoin/bitcoin/pull/32349#issuecomment-2833346711)
Closing in favour of https://github.com/bitcoin/bitcoin/pull/32351.
💬 l0rinc commented on pull request "test: avoid stack overflow in `FindChallenges` via manual iteration":
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833349523)
> On master we do a depth-first gathering of challenges, the new stack based version does breadth-first, but result is put in a std::set so traversal order does not matter.
I've reworded the commit message to make this clearer.
The original method is pre-order depth-first, where the children are processed in the same order they appear (Left-to-right). The new method is still pre-order depth-first, but children are inserted in the reverse order (Right-to-left). But as you mention, it's in a s
...
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833349523)
> On master we do a depth-first gathering of challenges, the new stack based version does breadth-first, but result is put in a std::set so traversal order does not matter.
I've reworded the commit message to make this clearer.
The original method is pre-order depth-first, where the children are processed in the same order they appear (Left-to-right). The new method is still pre-order depth-first, but children are inserted in the reverse order (Right-to-left). But as you mention, it's in a s
...
💬 l0rinc commented on pull request "test: avoid stack overflow in `FindChallenges` via manual iteration":
(https://github.com/bitcoin/bitcoin/pull/32351#discussion_r2062574904)
This helped me debug the mentioned vector conversion, but it's not important anymore, so your suggestion also works.
(https://github.com/bitcoin/bitcoin/pull/32351#discussion_r2062574904)
This helped me debug the mentioned vector conversion, but it's not important anymore, so your suggestion also works.
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062566402)
nit: maybe it's better to return a `std::span` from `m_recv_buffer` to avoid a copy here.
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062566402)
nit: maybe it's better to return a `std::span` from `m_recv_buffer` to avoid a copy here.
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062570060)
Maybe use a list of buffers (instead a single FIFO buffer)?
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062570060)
Maybe use a list of buffers (instead a single FIFO buffer)?
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062572600)
nit: can be simplified using
```c++
void WriteReply(HTTPStatusCode status, std::string_view reply_body_view)
{
WriteReply(status, std::as_bytes(std::span{reply_body_view}));
}
```
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062572600)
nit: can be simplified using
```c++
void WriteReply(HTTPStatusCode status, std::string_view reply_body_view)
{
WriteReply(status, std::as_bytes(std::span{reply_body_view}));
}
```
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062569706)
Would it be possible to allow writing a reply composed of several `span<byte>`?
It should allow sending while serializing a response object.
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062569706)
Would it be possible to allow writing a reply composed of several `span<byte>`?
It should allow sending while serializing a response object.
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062573530)
Can be removed if we'll add `WriteReply(HTTPStatusCode status, std::string_view reply_body_view)` (see above).
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062573530)
Can be removed if we'll add `WriteReply(HTTPStatusCode status, std::string_view reply_body_view)` (see above).
💬 maflcko commented on pull request "doc: Fix fuzz test_runner.py path":
(https://github.com/bitcoin/bitcoin/pull/32353#issuecomment-2833354624)
lgtm ACK 61f238e84ac6d24d8f420c2eabcbb2980d7fcb1e
(https://github.com/bitcoin/bitcoin/pull/32353#issuecomment-2833354624)
lgtm ACK 61f238e84ac6d24d8f420c2eabcbb2980d7fcb1e
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578451)
nit:
```c++
std::string_view RequestMethodString(HTTPRequestMethod m)
```
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578451)
nit:
```c++
std::string_view RequestMethodString(HTTPRequestMethod m)
```
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578725)
nit: wouldn't it copy the substrings?
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578725)
nit: wouldn't it copy the substrings?
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578806)
nit:
```
std::pair<bool, std::string_view> HTTPRequest::GetHeader(const std::string& hdr) const
```
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2062578806)
nit:
```
std::pair<bool, std::string_view> HTTPRequest::GetHeader(const std::string& hdr) const
```
🤔 shahsb reviewed a pull request: "net: remove unnecessary check from AlreadyConnectedToAddress()"
(https://github.com/bitcoin/bitcoin/pull/32338#pullrequestreview-2797611994)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/32338#pullrequestreview-2797611994)
Concept ACK
💬 shahsb commented on pull request "net: remove unnecessary check from AlreadyConnectedToAddress()":
(https://github.com/bitcoin/bitcoin/pull/32338#issuecomment-2833412008)
Approach ACK
(https://github.com/bitcoin/bitcoin/pull/32338#issuecomment-2833412008)
Approach ACK
💬 hebasto commented on pull request "test: avoid stack overflow in `FindChallenges` via manual iteration":
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833427483)
> > the changes in this PR could be much smaller and easier to review
>
>
>
> You mean to avoid the use of the switch statement? If you feel strongly about it I can revert that, but the code seemed easy to review in either way.
I mean to squash all changes into a single commit with functionality changes only. Refactoring changes, such as introducing the `switch` statement, could be added in a separate commit.
But not a strong opinion, though.
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833427483)
> > the changes in this PR could be much smaller and easier to review
>
>
>
> You mean to avoid the use of the switch statement? If you feel strongly about it I can revert that, but the code seemed easy to review in either way.
I mean to squash all changes into a single commit with functionality changes only. Refactoring changes, such as introducing the `switch` statement, could be added in a separate commit.
But not a strong opinion, though.