<MacroFake>
Usually it is not possible request review from external users, only from users in a "team". GitHub usually checks for that and errors out of the API request. However, here it doesn't error out and just does something nonsensical.
<MacroFake>
[19:59] <jon_atack> MacroFake: what are the criteria for DrahtBot to request PR re-reviews? I see it happening for quite a few PRs, but not for other PRs.
<MacroFake>
The code is open source, but the logic should be: "If has_current_ack: re_request_stale_acks();"
vincenzo- has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
vincenzopalazzo has joined #bitcoin-core-dev
<vincenzopalazzo>
MacroFake, maybe because I did not review the last version after the rebase?
<MacroFake>
vincenzopalazzo: Right, but the GitHub bug is that it *un*-requests the review when the API call is for a *re*-request of a review
<vincenzopalazzo>
MacroFake, I see, probably
acl has joined #bitcoin-core-dev
vincenzopalazzo has quit [Remote host closed the connection]
vincenzopalazzo has joined #bitcoin-core-dev
acl has quit [Quit: Leaving...]
test_ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 258 seconds]
abubakarsadiq has joined #bitcoin-core-dev
Nekorand has joined #bitcoin-core-dev
preimage has joined #bitcoin-core-dev
michaelfolkson has quit [Server closed connection]
<cfields>
sipa: mmm. ok, I have some reading/catching up to do. But that seems quite naive for containers, especially here where we only ever write to this unordered_map after doing a full reserve:
<cfields>
My understanding is that that's accounting for malloc's slight over-allocations. But I would think that reserve() would prevent the over-allocation-per-node to some extent.
<sipa>
std::list has one malloc per element in the list, and each element is a node with an X, and pointers backward/forward
<sipa>
std::list also has no reserve()
<cfields>
*sigh*
<cfields>
nevermind
<cfields>
Yes, that last thing heh.
<cfields>
The reserve got stuck in my head. But obviously that's for the unordered_map in DisconnectedBlockTransactions, not the list.
<sipa>
Ah.
<cfields>
Ok, but I guess the question still stands. Because we do reserve on unordered_maps elsewhere.
<cfields>
And I guess it screws up the accounting. But if it's intended to be worst case that's fine.
Talkless has quit [Quit: Konversation terminated!]
<sipa>
i think the implemented code is correct besides (a) MallocUsage is outdated and (b) the exact memory layout of unordered_map data structures is ultimately guesswork as it depends on the stl
<sipa>
but ignoring those two points, an unordered_map consists of a single allocated hash table, plus one allocated object per entry in the map
<sipa>
the reserve only affects the size of the hash table, not the elements in iy
<sipa>
the first part is the allocations for the entries in the map
<sipa>
thr second part is for the hash table
<cfields>
ok, that all makes sense. And vector makes sense in that regard as well.
<cfields>
sipa: thanks very much for the help. I got myself good and confused :)
<sipa>
cfields: yw
<hebasto>
accounting allocators were able to handle most (all?) containers presicely
<hebasto>
*precisely
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
gfdhgf has quit [Quit: Leaving]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
ajonas has quit [Server closed connection]
ajonas has joined #bitcoin-core-dev
jnewbery has quit [Server closed connection]
jnewbery has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
benwestgate has joined #bitcoin-core-dev
lbia has quit [Ping timeout: 246 seconds]
preimage has quit [Quit: WeeChat 4.0.4]
benwestgate has quit [Ping timeout: 245 seconds]
vysn has quit [Remote host closed the connection]
rahl has quit [Server closed connection]
rahl has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
Evel-Knievel has quit [Ping timeout: 255 seconds]
Evel-Knievel has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
benwestgate has joined #bitcoin-core-dev
<PaperSword>
Is there method in CScript that will print the op codes in the same way bitcoin-cli decodescript does?
<PaperSword>
or do I have to just run ls
<PaperSword>
sorry *or do I have to just iterate over the script with GetOp and print the results as I iterate through?
<sipa>
PaperSword: i think you can figure out the answer for yourself, by looking at the implementation of decodescript
<sipa>
the answer is no, but obviously decodescript must be doing this conversion to human-readable form in some way, and you can probably invoke and/or reuse that code
Jackielove4u has quit [Quit: Connection closed for inactivity]
AaronvanW has joined #bitcoin-core-dev
<lightlike>
it's a really nice side-effect of migrating to GH actions that win/mac CI now run when pushing sth to my local repo, before opening a PR.