π¬ 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.
π¬ l0rinc commented on pull request "test: avoid stack overflow in `FindChallenges` via manual iteration":
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833428659)
Since CI is checking every commit, I have split out the introduction of the new algorithm, demonstrating that it results in the same output as the original.
I'm not sure how to do that in a single commit - unless I add it as a test, which didn't seem necessary here.
(https://github.com/bitcoin/bitcoin/pull/32351#issuecomment-2833428659)
Since CI is checking every commit, I have split out the introduction of the new algorithm, demonstrating that it results in the same output as the original.
I'm not sure how to do that in a single commit - unless I add it as a test, which didn't seem necessary here.
π ismaelsadeeq approved a pull request: "Bugfix: Miner: Don't reuse block_reserved_weight for "block is full enough to give up" weight delta"
(https://github.com/bitcoin/bitcoin/pull/32355#pullrequestreview-2797625801)
ACK 524f981bb87319fdd6ff2ab4a932c4b4e31a7398
Using the `m_options.block_reserved_weight` wonβt cause issues, but generally, I think itβs best to separate concerns and make this a `constexpr`.
This also makes the mining code cleaner.
(https://github.com/bitcoin/bitcoin/pull/32355#pullrequestreview-2797625801)
ACK 524f981bb87319fdd6ff2ab4a932c4b4e31a7398
Using the `m_options.block_reserved_weight` wonβt cause issues, but generally, I think itβs best to separate concerns and make this a `constexpr`.
This also makes the mining code cleaner.
π¬ jesterhodl commented on pull request "[29.x] qt: 29.1 translations update":
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833441349)
> The erroneous format specs still remain: [#32295 (comment)](https://github.com/bitcoin/bitcoin/issues/32295#issuecomment-2827238571)
Ok, for Polish there was one. I just corrected it.
I'm happy to correct other languages for this sort of issue, but I'm only granted access to Polish team in Transifex.
If someone grants me temporary access I can fix others and go back to being just Polish Team.
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833441349)
> The erroneous format specs still remain: [#32295 (comment)](https://github.com/bitcoin/bitcoin/issues/32295#issuecomment-2827238571)
Ok, for Polish there was one. I just corrected it.
I'm happy to correct other languages for this sort of issue, but I'm only granted access to Polish team in Transifex.
If someone grants me temporary access I can fix others and go back to being just Polish Team.
π€ romanz reviewed a pull request: "Replace libevent with our own HTTP and socket-handling implementation"
(https://github.com/bitcoin/bitcoin/pull/32061#pullrequestreview-2797634240)
LGTM, many thanks!
Added some comments/suggestions above :)
(https://github.com/bitcoin/bitcoin/pull/32061#pullrequestreview-2797634240)
LGTM, many thanks!
Added some comments/suggestions above :)
π¬ ismaelsadeeq commented on pull request "Fees: add Fee rate Forecaster Manager":
(https://github.com/bitcoin/bitcoin/pull/31664#discussion_r2062624207)
Done.
(https://github.com/bitcoin/bitcoin/pull/31664#discussion_r2062624207)
Done.