--- Log opened Wed Aug 17 00:00:53 2022
01:21 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
02:54 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
05:32 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
05:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:a1a2:5b69:396b:cec] has joined #bitcoin-core-pr-reviews
06:11 -!- hernanmarino [~hernanmar@186.153.60.185] has joined #bitcoin-core-pr-reviews
06:49 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
07:00 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has quit [Ping timeout: 256 seconds]
07:38 -!- pablomartin_ [~pablomart@185.199.100.247] has joined #bitcoin-core-pr-reviews
08:04 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:05 -!- forthrast [~forthrast@172.98.33.164] has joined #bitcoin-core-pr-reviews
08:08 -!- forthrast [~forthrast@172.98.33.164] has quit [Client Quit]
08:30 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:46 -!- baffler [~baffler@69-153-6-185.lightspeed.lsvlky.sbcglobal.net] has joined #bitcoin-core-pr-reviews
08:52 -!- Amirreza [~Amirreza7@2.177.87.147] has joined #bitcoin-core-pr-reviews
08:58 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
09:00 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:01 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
09:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:04 -!- bot_21 [~bot_21@212.129.78.240] has joined #bitcoin-core-pr-reviews
09:05 < bot_21> hi, how can i join?
09:05 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
09:07 < bot_21> #startmetting
09:09 < lightlike> bot_21:  you've joined the channel, but the meeting will only start in ~50 minutes (17:00 UTC)
09:10 < bot_21> lightlike oh ok, thanks !
09:33 -!- bot_21 [~bot_21@212.129.78.240] has quit [Quit: Connection closed]
09:35 -!- aryan_ [~aryan@cpe-67-250-75-104.nj.res.rr.com] has joined #bitcoin-core-pr-reviews
09:54 -!- forthrast [~forthrast@172.98.33.173] has joined #bitcoin-core-pr-reviews
09:59 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:00 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:00 < Lov3r_Of_Bitcoin> hello
10:00 < stickies-v> #startmeeting
10:00 < pablomartin_> hi all
10:00 < larryruane_> hi
10:00 < brunoerg> hi
10:00 < michaelfolkson> hi
10:00 < aryan_> 👋
10:01 < Amirreza> Hi
10:01 < stickies-v> welcome everyone! Today we're looking at #25665, authored by ryanofsky. The notes and questions are available on https://bitcoincore.reviews/25665
10:01 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:01 -!- bot_21 [~bot_21@212.129.76.217] has joined #bitcoin-core-pr-reviews
10:01 < schmidty_> hi
10:01 < juancama> Hey everyone
10:02 < stickies-v> anyone joining us for the first time today? even if you're just lurking, feel free to say hi!
10:02 < furszy> hi
10:02 < bot_21> hi
10:02 < hernanmarino> Hi !
10:02 < aryan_> First timer here.
10:02 -!- pablomartin_ is now known as pablomartin
10:02 < effexzi> Hi every1 
10:03 < stickies-v> whoo, welcome aryan_ ! glad to have you here. don't hold back on asking questions if anything's unclear!
10:05 < pablomartin> welcome aryan_!
10:05 < stickies-v> today's meeting is fairly technical and focuses on a couple of c++ libraries/techniques that aren't very often used in the codebase. as a quick disclaimer, i'm fairly new to c++ myself so don't take anything I say as gospel either haha. 
10:05 < stickies-v> who got the chance to review the PR or read the notes? (y/n)
10:05 < pablomartin> y
10:05 < hernanmarino> y
10:05 < aryan_> y
10:05 < Lov3r_Of_Bitcoin> y
10:05 < Amirreza> y
10:05 < michaelfolkson> y
10:05 < brunoerg> y
10:05 < juancama> y
10:06 < larryruane_> y
10:06 < bot_21> n
10:06 < stickies-v> what a y streak, oh my! and great to see some of you having commented on the PR already as well
10:06 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:06 < stickies-v> for those of you who were able to review, would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK?
10:06 < sipa> n
10:06 < aryan_> Approach ACK
10:06 < Amirreza> Tested Ack
10:06 < brunoerg> Concept ACK
10:07 < larryruane_> I have to say, though, this is the most confused I've ever been for a review club. This is well beyond my c++ understanding 
10:07 < pablomartin> Concept ACK and tested ACK
10:07 < hernanmarino> Tested ACK, but have some doubts on some technical details of the implementation
10:07 -!- forthrast [~forthrast@172.98.33.173] has quit [Quit: Connection closed]
10:07 < stickies-v> larryruane_: glad to hear I wasn't alone in that
10:07 -!- balogunofafrica [~balogunof@105.112.185.254] has joined #bitcoin-core-pr-reviews
10:08 < stickies-v> hernanmarino: care to share what they are? or will we cover them in the questions?
10:08 < brunoerg> larryruane_: +1
10:08 < aryan_> Ditto. This is the first C++ I've looked at in ~8 years though so I guess to be expected.
10:08 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:08 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:08 < michaelfolkson> Yeah Concept ACK, a little hazy on moving from BResult to this though
10:09 < hernanmarino> I just don know the answer for a couple of questions, let's talk later :)
10:09 < aryan_> If we're free to share doubts or uncertainties, is it typical to override the `bool` operator to allow for success checks in this way? Is it typical to override the bool operator to allow to check for success/failures in this way? https://github.com/bitcoin/bitcoin/pull/25665/files#diff-dd552c1ad61f5e2027fcef75f3a0ba027d69b5617931b3574e5d6ef2d3cbebe5R77
10:09 < stickies-v> quick note before diving into the questions: the PR has been updated slightly since these notes were released, so the current commit hashes are different but the actual changes are limited to comments. I'll keep linking to the "old" (590bc61) commits here.
10:09 < aryan_> Please feel free to answer later, just something that hung me up.
10:09 < larryruane_> what I desperately need to do is go through `result_tests.cpp` and really understand the test cases, simplest first, and maybe even write some test cases of my own (like when you're learning a new language), or try varying the existing test cases
10:10 < stickies-v> aryan_: iirc that's to keep parity with how std::optional is implemented, but would need to double check
10:11 < stickies-v> yep: "When an object of type optional<T> is contextually converted to bool, the conversion returns true if the object contains a value and false if it does not contain a value." (https://en.cppreference.com/w/cpp/utility/optional)
10:11 < stickies-v> (your link didn't actually point me to a diff so lmk if that's not an answer to your question)
10:11 < sipa> Is it a "operator bool()" or an "explicit operator bool()" ?
10:12 < aryan_> But this one here is true if `m_info` (or `m_info->failure) is empty. This means that it'll return false if there's a value but no `m_info`.
10:12 < stickies-v> larryruane_: yeah that's a good point, tests are very often a good starting point (besides docs) to understanding the use case/effects of a certain feature/change
10:13 < aryan_>     //! Success check.
10:13 < aryan_>     operator bool() const { return !m_info || !m_info->failure; }
10:13 < sipa> Before C++11, operator bool() existed for implicit conversion to bool, but it had lots of non-obvious ways to trigger it (e.g. you could write "obj + 3", and if obj had an operator bool, it'd evaluate to 3 or 4").
10:13 < sipa> Since C++11 you can use "explicit operator bool()" to avoid many such cases.
10:14 < pablomartin> thanks sipa
10:15 < stickies-v> aryan_: if returns true either there is no `ErrorInfo m_info`at all (i.e. success), or if there is an `ErrorInfo m_info` but it doesn't contain failure data. this is because the new `Result` implementation can also store warnings, which still mean the function returned successfully
10:15 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
10:16 < aryan_> Right, right. It seems to means of gauging success. Just feels odd to use the `bool` operator for that. Having a successful result with a value present return false is just something new, I guess.
10:16 < stickies-v> alright moving on to the first question: which use cases previously not handled well by `util::Result` does this PR target? Why did `util::Result` need an upgrade to be compatible with `LoadChainState()` and `VerifyLoadedChainState()`?
10:16 < sipa> operator bool() is generally a bad idea
10:16 < stickies-v> aryan_:  we'll actually cover why that parity with std::optional is important in the next question!
10:17 < Amirreza> I think having multiple errors and warnings.
10:17 < hernanmarino> Uses cases : allow a result to have both a value and an error message,to store multiple errors and for multiple results to be chained. 
10:17 < sipa> std::optional has "explicit operator bool()", not "operator bool()".
10:17 < aryan_> `Result` now allows a value AND an error message to be returned. It also allows for multiple errors/warnings. Lastly, `Result`s are now chainable (you can instantiate a `Result` with another `Result`)
10:18 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
10:18 < Amirreza> And also I think they support more types for Error value (not just string)
10:18 < hernanmarino> and LoadChainState() needed to return a value on Errors, not only on success, something not possible before this PR
10:18 < brunoerg> It also allows to return a value on failure, not just a value on success I guess
10:19 < brunoerg> hernanmarino: +1
10:19 < pablomartin> yeah, to have both value and error messages, store multiple of them, and buid them on top of them 
10:19 < stickies-v> Amirreza: hernanmarino aryan_ brunoerg pablomartin yes that pretty much covers it all! and nice one catching the chaining bit aryan_ , since that wasn't covered in the PR description
10:20 < michaelfolkson> Oh and with BResult you could only have one, ok
10:20 < larryruane_> pablomartin: but I think not storing multiple values... only multiple error and warnings
10:20 < larryruane_> (maybe that's what you meant)
10:20 < stickies-v> michaelfolkson: yep indeed, but for example LoadChainState() returns both a status code and an (optional) error string
10:20 < stickies-v> single value, multiple errors/warnings indeed! thanks larryruane_ 
10:20 < pablomartin> larryuane_ yeah, i meant multiple of the previous (values and error msgs)
10:21 < furszy> i'm a bit hesitant here, warnings are another specialization of the error field. Not sure if it's something that should be placed on the base ErrorInfo class.
10:21 -!- hodloevsky [~hodloevsk@c-73-251-219-241.hsd1.va.comcast.net] has joined #bitcoin-core-pr-reviews
10:22 < pablomartin> larryuane: got you, thanks!
10:22 < stickies-v> so bonus question... what if we have a function that needs to return multiple values on failure? should we extend `Result` to handle that?
10:22 -!- balogunofafrica [~balogunof@105.112.185.254] has quit [Quit: Connection closed]
10:22 < stickies-v> furszy: I think the distinction is meaningful because warnings don't change whether the function returned successfully?
10:23 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has joined #bitcoin-core-pr-reviews
10:24 -!- juancama6 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:24 < Amirreza> stickies-v: Currently by using the error-vectors we can do this, am I correct? But not return multiple value with different types.
10:24 -!- juancama6 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has left #bitcoin-core-pr-reviews []
10:24 < aryan_> I think warnings _DO_ change whether the function returned successfully (that bool I hate so much will end up returning false if there's a warning which means it failed).
10:24 < larryruane_> stickies-v: I would say no because the return value can be a `std::tuple`
10:24 < aryan_> +1 @larryuane_
10:24 < stickies-v> Amirreza: we only use vectors for error and warnings *messages*, not the failure *value*
10:24 -!- juancama11 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:25 < Amirreza> stickies-v: Yes, thanks.
10:25 < larryruane_> one could say that `tuple` is less convenient than if there was built-in support, but it's probably not very common, so best to keep it simple
10:25 < furszy> :stickies-v meaningful distinction to what exactly? not sure if I understood the question
10:26 < stickies-v> larryruane_: yeah exactly, std::tuple or the likes, or even a custom struct if we need something more complex
10:26 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has quit [Ping timeout: 248 seconds]
10:28 < pablomartin> but then has_value would mean that could have 1 or multiple...
10:28 < stickies-v> well a function could return successfully, but still provide feedback on some potentially dangerous operations/contexts through the warnings? but without distinguishing between errors and warnings, that would be difficult?
10:28 < furszy> not every function requires that.
10:29 < furszy> actually, most of the current util::Result usages don't requires it
10:29 < stickies-v> ah, no that's true
10:29 < aryan_> It should but with warnings being stored in `m_info`, it'll cause the bool to return false (unsuccessful) even if `m_info` has no errors. (sorry if it sounds like I'm harping on this bool)
10:30 -!- hodloevsky [~hodloevsk@c-73-251-219-241.hsd1.va.comcast.net] has quit [Quit: Connection closed]
10:30 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
10:31 < stickies-v> hmm no it wouldn't, aryan_ because `!m_info->failure` would be `true`
10:31 < stickies-v> (`operator bool() const { return !m_info || !m_info->failure; }`)
10:31 < aryan_> Ahhhh, yes, yes, yes. Sorry. I read bad.
10:32 < stickies-v> pablomartin: not sure what you mean with 1 or multiple?
10:32 < larryruane_> if a function accumulates some warnings... then encounters and error (or multiple errors), the warnings aren't reported too, correct?
10:32 < stickies-v> alright gonna move on to the next question already but feel free to keep discussing previous questions - we're async!
10:32 < stickies-v> https://github.com/bitcoin/bitcoin/pull/25721 states `BResult` had a less familiar interface than the well-known `std::optional`. Is that a good enough reason to change it? What other reason(s) do you see for this change?
10:33 < furszy> :larryruant I think that we should always have errors > warnings
10:33 < larryruane_> I would say it's a good enough reason, given that `BResult` is not already used by a lot of existing code (if it was, there would be an argument)
10:33 < larryruane_> furszy: yes i agree, just checking
10:33 < stickies-v> great question larryruane_ - to my understanding everything propagates, so I'd think warnings are kept?
10:34 < aryan_> +1 larry
10:35 < stickies-v> larryruane_: right, that's definitely an important argument - it would be harder case to make if we'd have to refactor tons of code. but do you see a "positive" argument as well, besides making it easier perhaps for developers because they already know the std::optional interface?
10:36 < larryruane_> stickies-v: "What other reason(s) do you see for this change?" ... PR 25721 says "The Result/Res/Obj naming was also not internally consistent." ... maybe that's another one?
10:36 < michaelfolkson> stickies-v: I would say....a less familiar interface on its own probably isn't a good enough reason to change it. But there are other stronger reasons (e.g. misleading BResult constructor, type compatibility from ##25721)
10:36 < larryruane_> (but I don't understand why those are not internally consistent)
10:37 < stickies-v> (I don't understand that internal inconsistency either haha)
10:37 < stickies-v> michaelfolkson: I mean there are definitely more arguments in favour of this PR! was just focusing on the std::optional interface here
10:38 < michaelfolkson> Ok sorry :)
10:39 < stickies-v> I think a good argument in favour of the std::optional interface that a lot of the functions (supposedly?) that could benefit from a util::Result instead currently return a std::optional. so by keeping the interface identical, there should be less code change when replaced
10:40 < larryruane_> i wonder if anyone considered https://github.com/TartanLlama/expected
10:41 < stickies-v> next one: what is a `union`? Why is `m_value` a `union` type when it holds just one member?
10:42 < larryruane_> `union` because the constructors / destructors don't automatically run
10:42 < Amirreza> I asked this question from the PR author, using union prevents calling the c-tor in the failure.
10:42 < larryruane_> have to admit i cheated on this one https://stackoverflow.com/questions/59066929/whats-the-purpose-of-using-a-union-with-only-one-member/59067394#59067394
10:42 < hernanmarino> a union is a structure for holding "one of many" value types.
10:42 < hernanmarino>  Using an union in this case avoids m_value getting constructor and destructor being called automatically, so that in case of failure m_value is never constructed.
10:43 < Amirreza> larryruane_, I cheated too :)
10:44 < stickies-v> larryruane_: Amirreza hernanmarino yeah exactly, feels like a sneaky workaround but does seem to do the trick!
10:44 -!- Ruben [~Ruben@cust-224-108-110-94.dyn.as47377.net] has joined #bitcoin-core-pr-reviews
10:44 < aryan_> > Using an union in this case avoids m_value getting constructor and destructor being called automatically, so that in case of failure m_value is never constructed.
10:44 < aryan_> This helps a lot in my understanding. Thank you!
10:44 -!- Ruben [~Ruben@cust-224-108-110-94.dyn.as47377.net] has quit [Client Quit]
10:44 < pablomartin> yeah, like @hernanmarino - it's also on a comment in the code: Uses anonymous union so success value is never
10:44 < pablomartin>  constructed in failure case.
10:44 < larryruane_> there's a difference between a simple `union` (which is what this is) and a `union class` right? 
10:45 < stickies-v> pablomartin: yeah well it used to not be a comment until Amirreza decided to front-run the review club haha. it's definitely something that should be in the code comments though!
10:45 < brunoerg> `m_value` is a union to hold only success value
10:46 < larryruane_> nevermind i guess it's always a class (I was thinking it was similar to enum versus enum class, those are different)
10:46 < stickies-v> larryruane_:  from what I understand a union is just a class type?
10:46 < brunoerg> so it wouldn't fit with another type
10:46 < larryruane_> stickies-v: +1
10:47 < stickies-v> brunoerg: yup, and because `Result` doesn't always hold an m_value (in failure case), we don't want to allocate memory to it if not necessary
10:47 < brunoerg> interesting
10:47 < furszy> well, in that case, why m_value is an union, while the error member don't?
10:48 < furszy> does a Result always holds an error?
10:50 < stickies-v> furszy: that's an excellent question, and I believe `ErrorInfo` achieves something similar by dynamically checking the type of F with `std::is_same<F, void>`?
10:50 < larryruane_> a `union` is similar to (but more basic than) a `std::variant` but the `variant` type keeps track of which variant an instance currently contains (whereas a `union` doesn't, that's up to you)
10:50 < stickies-v> hmm no that's not true
10:50 < sipa> std::is_same is a compile-time check, not a runtime one
10:50 < stickies-v> (my previous statement)
10:50 < stickies-v> yeah sorry
10:53 < stickies-v> second attempt: `m_info` is a std::unique_pointer and we allocate memory dynamically: https://github.com/bitcoin-core-review-club/bitcoin/blob/590bc615a3120a8f11712220546f9654058b82f0/src/util/result.h#L214-L215
10:54 < stickies-v> but we'd still allocate memory for the failure type even if the ErrorInfo only contained errors and warnings I think? which perhaps could be improved?
10:54 < stickies-v> furszy: do you think that makes sense?
10:55 < stickies-v> moving on to the next one already: in `template <typename T, typename F> class ResultBase`, what do `T` and `F` represent conceptually?
10:55 < michaelfolkson> stickies-v: Confused, errors are associated with failures?
10:55 < stickies-v> (link: https://github.com/bitcoin-core-review-club/bitcoin/blob/590bc615a3120a8f11712220546f9654058b82f0/src/util/result.h#L39-L40)
10:56 < furszy> > but we'd still allocate memory for the failure type even if the ErrorInfo only contained errors and warnings I think?
10:57 < larryruane_> `T` is the type of success return value, and `F` is the type for failure return values?
10:57 < furszy> hmm, we will always allocate memory for the error reason if it contains errors and warnings
10:57 < Amirreza> +1 larryruane_ 
10:59 < stickies-v> michaelfolkson: yeah, see the difference in constructors when Warning and Error is passed, Error triggers InitFailure, Warning doesn't: https://github.com/bitcoin-core-review-club/bitcoin/blob/590bc615a3120a8f11712220546f9654058b82f0/src/util/result.h#L162-L173
11:00 < hernanmarino> I agree with larryruane_ 
11:00 < stickies-v> yes you're correct larryruane_ ! and everyone agreeing with him whoo
11:01 < stickies-v> alright that's a wrap for today, thanks everyone for showing up and participating!
11:01 < stickies-v> #endmeeting
11:01 < juancama11> Have a great day
11:01 -!- juancama11 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has left #bitcoin-core-pr-reviews []
11:01 < Amirreza> stickies-v, Thanks for the meeting
11:01 < aryan_> Thank you stickies!
11:01 < larryruane_> thank you @stickies-v and everyone else!
11:01 < furszy> thanks
11:01 < brunoerg> thanks, stickies-v! 
11:01 < stickies-v> furszy: are you sure about that? InitFailure seems to indicate otherwise: https://github.com/bitcoin-core-review-club/bitcoin/blob/590bc615a3120a8f11712220546f9654058b82f0/src/util/result.h#L51-L55
11:02 < effexzi> Thanks every1 
11:02 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
11:02 < pablomartin> thanks stickies-v!
11:02 < hernanmarino> Thanks everybody 
11:03 < michaelfolkson> [18:54:35]  <stickies-v> but we'd still allocate memory for the failure type even if the ErrorInfo only contained errors and warnings I think?
11:03 -!- bot_21 [~bot_21@212.129.76.217] has quit [Quit: Connection closed]
11:03 < stickies-v> and thanks to ryanofsky for forcing all of us to up our C++ game haha
11:03 < michaelfolkson> You'd need to allocate memory for the failure type in the case of a warning?
11:03 < furszy> stickies-v: +1
11:04 < michaelfolkson> Anyway, thanks stickies-v (and ryanofsky)!
11:04 < aryan_> Stickies, agreed, this was a tough one coming from JS.
11:05 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
11:06 -!- Amirreza [~Amirreza7@2.177.87.147] has quit [Quit: Leaving]
11:07 < stickies-v> michaelfolkson: that's my understanding, yes. `ErrorInfo::failure` is a `std::optional` which does not use dynamic allocation
11:07 -!- aryan_ [~aryan@cpe-67-250-75-104.nj.res.rr.com] has quit [Quit: Leaving...]
11:07 < michaelfolkson> Ok thanks
11:08 -!- pablomartin [~pablomart@185.199.100.247] has quit [Quit: Leaving]
11:11 -!- forthrast [~forthrast@172.98.33.253] has joined #bitcoin-core-pr-reviews
11:13 -!- baffler [~baffler@69-153-6-185.lightspeed.lsvlky.sbcglobal.net] has quit [Quit: Connection closed]
11:27 -!- forthrast [~forthrast@172.98.33.253] has quit [Quit: Connection closed]
11:31 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has quit [Quit: Connection closed]
11:41 -!- mimmy [~mimmy@66-46-12-74.dedicated.allstream.net] has joined #bitcoin-core-pr-reviews
11:42 -!- evanlinj1 [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
11:42 -!- evanlinj1 [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
11:59 -!- mimmy [~mimmy@66-46-12-74.dedicated.allstream.net] has left #bitcoin-core-pr-reviews [WeeChat 3.6]
12:28 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]
14:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:a1a2:5b69:396b:cec] has quit []
14:46 -!- jesseposner [~jesse@user/jesseposner] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:09 -!- hernanmarino [~hernanmar@186.153.60.185] has quit [Remote host closed the connection]
15:09 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:09 -!- hernanmarino [~hernanmar@186.153.60.185] has joined #bitcoin-core-pr-reviews
15:12 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-pr-reviews
19:46 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
19:47 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:17 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:32 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:32 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:52 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
22:53 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:54 -!- evanlinj1 [~root@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 268 seconds]
22:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 268 seconds]
22:55 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
23:21 -!- greypw2546002 [~greypw254@grey.pw] has quit [Ping timeout: 240 seconds]
23:23 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Aug 18 00:00:53 2022