--- Log opened Wed Sep 29 00:00:21 2021
00:08 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
00:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:22 -!- Murch[m] [~murchmatr@2001:470:69fc:105::2aa8] has quit [Quit: Bridge terminating on SIGTERM]
01:22 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has quit [Quit: Bridge terminating on SIGTERM]
01:22 -!- vasanth2[m] [~vasanth2m@2001:470:69fc:105::3548] has quit [Quit: Bridge terminating on SIGTERM]
01:22 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Quit: Bridge terminating on SIGTERM]
01:22 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has quit [Quit: Bridge terminating on SIGTERM]
01:25 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-pr-reviews
01:32 -!- vasanth2[m] [~vasanth2m@2001:470:69fc:105::3548] has joined #bitcoin-core-pr-reviews
01:32 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has joined #bitcoin-core-pr-reviews
01:32 -!- Murch[m] [~murchmatr@2001:470:69fc:105::2aa8] has joined #bitcoin-core-pr-reviews
01:32 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews
02:23 -!- hex17or_ [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 276 seconds]
02:24 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
04:19 < michaelfolkson> Wow amiti comics are back with a bang :)
04:19 < michaelfolkson> Impressive
05:52 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
06:17 < amiti> hahaha, thank you 
06:30 < dunxen_> just saw them now, wow! so good
06:33 -!- dunxen_ [~dunxen@gateway/tor-sasl/dunxen] has quit [Quit: Bye!]
06:33 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has joined #bitcoin-core-pr-reviews
07:13 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
07:13 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #bitcoin-core-pr-reviews
08:18 < pinheadmz> Does anyone have an opinion on git-bash / WSL / msys / powershell for developing on windows?
08:18 < sipa> my opinion would be to not develop on windows...
08:19 < pinheadmz> agreed let me clarify
08:19 < pinheadmz> i use linux and osx for primary dev work, but often need to check stuff on windows
08:19 < sipa> guix build + test in VM?
08:20 < sipa> (i don't actually know how easy it is to run modern windows in a VM, tbh)
08:20 < pinheadmz> ha sure. I actually have windows/ubuntu dual boot i dont really need to VM
08:20 < pinheadmz> just wanna be able to compile something i know will run on windows users computer
09:21 -!- CoinForensics [CoinForens@gateway/vpn/protonvpn/coinforensics] has joined #bitcoin-core-pr-reviews
09:41 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-pr-reviews
09:44 -!- zakinator123 [~zakinator@216.30.182.130] has joined #bitcoin-core-pr-reviews
09:51 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:53 < jnewbery> We'll get started in 7 minutes. I hope you all have your pimpl questions ready :)
09:54 -!- naiza77 [~naiza@180.188.251.235] has joined #bitcoin-core-pr-reviews
09:55 -!- naiza77 [~naiza@180.188.251.235] has quit [Client Quit]
09:55 -!- naiza [~naiza@180.188.251.235] has joined #bitcoin-core-pr-reviews
09:58 -!- shoryak [~shoryak@106.223.212.64] has joined #bitcoin-core-pr-reviews
09:58 -!- ziggie [~ziggie@user/ziggie] has joined #bitcoin-core-pr-reviews
09:59 -!- gene [~gene@gateway/tor-sasl/gene] has joined #bitcoin-core-pr-reviews
10:00 < jnewbery> #startmeeting
10:00 < jnewbery> Hi folks! Welcome to Bitcoin Core PR Review Club. Feel free to say hi to let everyone know you're here.
10:00 < CoinForensics> Hi (first PR Review Club, just lurking)
10:00 < ziggie> hi
10:00 < raj_> hi
10:00 < r-ush> hi
10:00 < naiza> Hi
10:00 < shoryak> hi
10:00 < zakinator123> Hello1
10:00 < lightlike> hi
10:00 < michaelfolkson> hi
10:00 < jnewbery> Welcome CoinForensics! Anyone else here for the first time?
10:00 < gene> hi
10:01 < amiti> welcome CoinForensics :) 
10:01 < r-ush> im here for the first time jnewbery
10:01 < zakinator123> Yes it's my first time as well!
10:01 < glozow> hi!
10:01 < jnewbery> This week's notes and questions (and diagrams!!) are here: https://bitcoincore.reviews/22950
10:01 < amiti> welcome r-ush & zakinator123 :) 
10:01 < jnewbery> welcome r-ush and zakinator123!
10:02 < glozow> it's my first time pimpling 👉👈
10:02 < jnewbery> There are a few tips about attending your first meeting here if things get confusing: https://bitcoincore.reviews/your-first-meeting
10:02 < larryruane> hi
10:02 < schmidty> hi
10:02 < jnewbery> Alright, I'll hand over to our host for this meeting, amiti!
10:03 < amiti> hi everyone! hope you're excited to get deep into this little corner of c++ :) 
10:03 -!- Azorcode [~Azorcode@201.211.37.206] has joined #bitcoin-core-pr-reviews
10:03 < sipa> ohai
10:03 < amiti> to start with, did you review the notes, PR, or make toy programs? we can do a format of y / n / n 
10:04 -!- ementar4729 [~ementar47@189.122.185.237] has joined #bitcoin-core-pr-reviews
10:04 < Azorcode> Hello everyone
10:04 < raj_> y/y/n
10:04 < michaelfolkson> y/y/n
10:04 < sipa> n / +- / n, and i suspect i'm missing out
10:04 < naiza> y/n/n
10:04 < shoryak> y/n/y
10:04 < CoinForensics> y/n/n
10:04 < gene> y / y / n
10:04 < larryruane> y / n / had trouble compiling the toys
10:04 < amiti> sipa: what are you missing out? 
10:04 < jnewbery> y / y / does Bitcoin Core count as a toy program?
10:04 < ziggie> y/n/n
10:05 < zakinator123> y/n/n
10:05 < amiti> larryruane: interesting, ok we can dig into the failures later. 
10:05 < sipa> amiti: the toys
10:05 < sipa> (and the rumours of comics)
10:05 < amiti> sipa: ah gotcha =P 
10:06 < amiti> ok, so let's dig in. why does changing implementation details of a class cause recompilation of all its callers?
10:06 < larryruane> because private stuff is in the header file
10:06 < gene> potential change in size of private members
10:06 < amiti> larryruane: that's true. why does it need to be there?
10:07 < gene> layout changes
10:07 < raj_> because each call site has to allocate space of the class, and it doesn't know what the space would be without recompiling the class again? 
10:07 < amiti> gene: yes! 
10:07 < larryruane> gene: +1
10:07 < michaelfolkson> Because in C++ when anything in a header file changes all users of that class must be recompiled
10:08 < amiti> yeah, so private member variables can change the size of the object 
10:08 < michaelfolkson> This seems to be a quirk to C++, I don't know if this the case with other object oriented languages
10:08 < amiti> what about private member functions, does anyone have ideas on that part? 
10:09 < sipa> michaelfolkson: more modern languages generally solve that problem by having different notions of compilation, and more explicit modules - fundamentally this problem always exists
10:09 < naiza> they are involved in overload resolution. 
10:09 -!- Blue_Moon [~Blue_Moon@189.130.130.132] has joined #bitcoin-core-pr-reviews
10:09 < amiti> nazia: yes! 
10:10 < larryruane> private member functions are also in the header file, so if they change (which users of the class shouldn't care about), recompilation is needed
10:10 < amiti> so the accessibility of what callers can access can be restricted, but the compiler gets to know about private members & functions at all times, including when it compiles the calling code. 
10:10 < amiti> does that distinction make sense? 
10:10 < sipa> also all the type arguments and many more things in the header determine the symbol name it is compiled to; if you change the type of an argument to a function, all callers need to update the symbol name they link to
10:11 < larryruane> sipa: "more explicit modules" I think I've read that c++20 will support modules
10:11 < lightlike> does the need for recompiling everything actually depend on what is changed (variable, function)? i.e. if you just change a comment in the header, wouldn't there be a lengthy recompile even then?
10:11 < sipa> lightlike: indeed, though ccache will catch that i think
10:11 < sipa> as the precompilation output would be the same
10:11 < sipa> *preprocessing
10:12 < amiti> larryruane: yes the c++20 spec has support for modules, most compilers haven't fully implemented it yet though
10:12 < sipa> is c++20 final already?
10:12 < sipa> it is! since december 2020
10:14 < gene> awesome! side question: would modules be accepted into Bitcoin?
10:14 < sipa> lightlike: but yes, in general, because c++ has no real modules, it has no idea when interfaces change, and has to assume that whenever headers change, everything needs to be rebuilt
10:14 < sipa> gene: irrelevant until we switch to c++20, and that won't happen until it's widely available
10:14 < sipa> amiti has keyboard problems she will be back soon
10:14 < gene> sipa: +1
10:15 < amiti> I'm back! 
10:15 < zakinator123> amiti: So even if the public interface is the same, but new private members/functions are added to a class, recompilation of users of that class is required?
10:15 < amiti> ok let's dig in to how we can build compilation firewalls with C++ 
10:15 < amiti> Describe how the pimpl pattern & a pure abstract class work to reduce compilation dependencies. What are advantages & disadvantages of each?
10:15 < ementar4729> Does Bitcoin Core use C++ 11 ? If so, is there a reason to not switch to C++ 17 ?
10:15 < sipa> ementar4729: we use C++17
10:15 < sipa> zakinator123: indeed
10:16 < larryruane> sometimes _just for testing_ (obviously), i'll run a command like `touch -d '2 weeks ago' file.h` after changing file.h to speed up compile (but also need to update the timestamp on file.cpp)
10:16 < amiti> zakinator123: yes, that's true. but because of this design, there's also the breakup of header & cpp files, so even other changes to that file can cause recompilation of callers 
10:16 < Azorcode> Amiti your description about this PR is excellent
10:16 < sipa> ementar4729: https://bitcoin.stackexchange.com/questions/100545/what-version-of-c-is-used-in-bitcoin-core
10:16 < ementar4729> Thanks sipa
10:17 < amiti> Azorcode: thank you 
10:17 < Azorcode> ;D 
10:17 < michaelfolkson> amiti: Pimpl handles resource management but an abstract class doesn't
10:17 < amiti> michaelfolkson: what do you mean? 
10:17 < amiti> ok maybe we can take it one at a time 
10:18 < larryruane> pimpl: https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering "We can solve any problem by introducing an extra level of indirection" 😄
10:18 < michaelfolkson> Pimpl handles resources internally but with an abstract class the user has to take care of proper resource management
10:18 < amiti> since the notes start with the pattern of a pure abstract class- can anyone describe what the pattern is & how it can be used to reduce compilation dependencies? 
10:19 < amiti> larryruane: lol
10:19 < larryruane> i think a pure abstract class defines only an interface -- functions -- and has no state within itself
10:20 < amiti> larryruane: yup, and then how can we utilize that?
10:20 < larryruane> i think it's like traits in Rust (but grain of salt, i don't know Rust well)
10:20 < sipa> or interfaces in Java, type classes in haskell, ...
10:20 < amiti> I know very little about Rust =P 
10:22 < amiti> so yeah, the header defines an interface using a pure abstract class 
10:22 < Azorcode> rust is better
10:23 < michaelfolkson> Ha let's leave that discussion for another time
10:23 < amiti> since its an abstract class, it can't be instantiated. so there is another class that inherits from the base class & adds any private functions / members to fulfill the interface
10:23 < amiti> in that pattern, how does a caller instantiate an object?
10:23 < larryruane> amiti: "how can we utilize that?" ... you can then define an "implementation" class that inherits from the abstract class, fills out those functions' implementations, but then you can write a function whose argument is the abstract type, but the caller can pass it an object of the derived type --- looks like a type mismatch but it's not! (sorry probably didn't explain that well)
10:24 < zakinator123> amiti: By calling a static method defined in the abstract class that returns a pointer to the implementation class.
10:24 < amiti> larryruane: yes! 
10:24 < amiti> zakinator123: yes! 
10:24 < amiti> does that make sense to people? does anyone have questions?
10:24 < sipa> a static method?
10:24 < sipa> i'm confused
10:24 < raj_> amiti, does the abstract class approach also solves for this cascading compilation?  
10:25 < ementar4729> I think ScriptPubKeyMan is other example of abstract class. LegacyScriptPubKeyMan and DescriptorScriptPubKeyMan are the implementation.
10:25 < gene> do functions in pimpl work through dynamic dispatch like virtual overrides?
10:25 < larryruane> what really helped me on this topic is chapter 4 of the book "A Tour of C++ second edition" ... kindle version is pretty cheap
10:25 < zakinator123> So since the private and public members of the abstract class remain unchanged since all changes to implementation will be happening in the impl class, recompilation of dependencies is not needed?
10:25 < sipa> BaseSignatureChecker is also an abstract class
10:25 < michaelfolkson> larryruane: Cool, thanks. I had a look at the books referred to on the PR
10:26 < amiti> sipa: right, the static function is to connect using an abstract class with achieving the aims of reducing compilation dependencies
10:26 < sipa> oh
10:26 < sipa> we're not pimpling yet
10:26 < amiti> I'm sure there are other ways to do it too, but this is the pattern that is currently used in peermanager & was one I came across in other places too
10:26 < larryruane> sipa: "a static method?" I think this just means a function that can't access the `this` pointer because there is no object (it can be called with the double-colon syntax)
10:27 < amiti> no, this is an alternative to the pimpl :) 
10:27 < amiti> zakinator123: exactly right 
10:27 < sipa> larryruane: yes indeed; i was just confused what we were talking about - /ignore me (not literally)
10:27 < amiti> ok, so hopefully that makes sense to people, feel free to speak up if you have more questions 
10:27 < amiti> but let's move on to how the pimpl works 
10:28 < amiti> ... anyone want to describe how the pimpl pattern works? :) 
10:28 < larryruane> so I guess pimpl is more recent than the abstract class idea?
10:28 < jnewbery> Here's the static method in PeerManager, which makes and returns an instance of PeerManagerImpl: https://github.com/bitcoin/bitcoin/blob/419afa93419e6840f78cb94b4a39d826eb10e139/src/net_processing.cpp#L1422-L1427
10:28 < grettke> amiti That sounds like Gang of Four Design pattern. Have you compared it to any of them?
10:28 < ementar4729> Singleton pattern ?
10:29 < larryruane> yep I think that's the convention (at least in bitcoin core), to call the instantiation method `make` ... i like that
10:29 < amiti> larryruane: I think they are just two ways to achieve the aim. the pimpl pattern seems to be more explicit / common in C++ literature. each one of these have lots of names for them.
10:29 < amiti> grettke: never heard of it 
10:29 < naiza> Pimpl moves the private data members to the separate class and then we access them with the help of the unique pointer. 
10:29 < jnewbery> amiti: it's not required to have that static method. For example, look at how PeerManager implements the NetEventsInterface interface class: class PeerManager : public CValidationInterface, public NetEventsInterface
10:29 < ementar4729> Does pimpl use singleton pattern ?
10:30 < amiti> jnewbery: agreed, not required :) 
10:30 < jnewbery> init.cpp creates an instance of a PeerManager, but then passes it to CConnman as a pointer to a NetEventsInterface
10:31 < jnewbery> sorry, I'll stop talking about abstract classes. We've moved on to pimpls now
10:31 < amiti> nazia: mostly right, I'm not sure what you mean by the last part of how we access
10:31 < sipa> ementar4729: no, pimpl is not a singleton, as you can create multiple AddrMan objects
10:31 < sipa> (and each has their own implementation object)
10:32 < amiti> so the pimpl is very similar, but has some key differences 
10:33 < sipa> i don't think pimpl really matches any of those common design patterns; it's more a workaround for a limitation in the language, than a design i'd say
10:34 < naiza> amiti: In the header file only, we create a forward declaration which points at the implementation class and is used to access it?
10:34 < jnewbery> gene: > "do functions in pimpl work through dynamic dispatch like virtual overrides?" No, the forwarding from the outer class to the inner impl class is defined explicitly, eg everything from here downwards: https://github.com/bitcoin/bitcoin/pull/22950/files#diff-49d1faa58beca1ee1509a247e0331bb91f8604e30a483a7b2dea813e6cea02e2R1118
10:34 < amiti> nazia: yes!
10:35 < zakinator123> What is a "forward declaration"
10:35 < sipa> class Blup;
10:35 < sipa> just stating that a class with a certain name exists, without defining it
10:35 < amiti> its saying "this is the name of a class that exists, you'll learn more about it later" 
10:35 < gene> jnewbery: thanks, I also found some stuff on the cppreference page: https://en.cppreference.com/w/cpp/language/pimpl#Runtime_overhead
10:36 < gene> your explanation makes sense, though. no lookup, just a pointer indirection
10:36 < jnewbery> gene: nice reference. Thank you!
10:36 < amiti> so, we've mentioned some of these, but to make it explicit- what are some of the tradeoffs of using each of these patterns? 
10:36 < gene> does bitcoin use LTO?
10:36 < sipa> gene: no, we've experimented with it, but last we tried it was not a win iirc
10:37 < sipa> maybe time to try again
10:37 < michaelfolkson> LTO = Link time optimization (thanks search engine)
10:37 < gene> the cppreference link mentions link time optimization as a way to overcome some runtime costs for pimpl
10:38 < gene> :) thanks michaelfolkson 
10:38 < amiti> gene: oh interesting
10:38 < jnewbery> gene: yes, pimpl involves one extra pointer indirection. I don't know exactly how compilers implement vtables and dynamic dispatch, but I guess that the overhead is roughly equivalent
10:38 < grettke> sipa Regarding the pattern versus language specific feature implementation topic, gotcha, I see.
10:38 < sipa> gene: for such statements it's always useful to wonder how much it actually matters; the cost of a predictable function call is in the order of nanoseconds; that may matter for some use cases, but nothing in addrman needs anything near that kind of performance
10:39 < amiti> jnewbery: that's a succinct answer to the main tradeoffs between the two :) 
10:39 < larryruane> I just thought of something, couldn't abstract classes (not sure about pimpl) be very useful for testing, for mocking? The test framework could create a derived class that does very different stuff from the production derived class, and you pass the abstract object to the production code and it doesn't know the difference
10:40 < grettke> amiti The Gang of Four (GoF) book captures the logic and general design behind common (to them) patterns of OO code.
10:40 < gene> sipa: definitely agree, might be interesting if a pimpl winds up in a hot path somewhere
10:40 < sipa> jnewbery: the overhead is way less, because the linker resolves the function call, so the binary code actually has the memory address that's invokved; with vtables you have an indirection to even find out what code to call
10:41 < grettke> gene Is "hot path" the same as Wiki's "hot spot"?
10:42 < gene> hot path = performance critical execution path
10:42 < amiti> sipa: oh interesting. I'm guessing that's why the pimpl pattern is more common? using the abstract class thing made sense in PeerManager because there was already the virtual table lookups present. 
10:42 < sipa> amiti: it's definitely an advantage of pimpl; i don't think it's relevant for addrman, though :)
10:43 < amiti> sipa: that makes sense 
10:43 < amiti> thanks!
10:43 < amiti> ok, so next topic- I wanted to talk about the toy programs
10:43 < amiti> LarryRuane: this could be a good time to share your compilation issues?
10:44 < amiti> did anyone who got the chance to tinker have any learnings to share? 
10:44 < amiti> or anyone read the annotated code and have questions?
10:45 < larryruane> https://www.irccloud.com/pastebin/yM517JJg/
10:45 < amiti> ah, what did you call the .h? 
10:45 < jnewbery> There was a little bit of discussion on pimpl vs abstract class for PeerManager here: https://github.com/bitcoin/bitcoin/pull/20758#discussion_r548321467
10:45 < larryruane> pimpl.h
10:45 < amiti> larryruane: that's a relic of when I named it differently 
10:46 < amiti> there are two files and you just have to make sure one imports the other =P 
10:46 < michaelfolkson> Why was Txrequest a good example for Pimpl and why was Peer Manager a good example for abstract class?
10:46 < michaelfolkson> Why not just take one and then compare what Pimpl looked like versus abstract class?
10:46 < sipa> pimpl is for when you're only (ever) going to have one implementation
10:47 < amiti> oh, in my notes? 
10:47 < amiti> kinda arbitrary, I was learning about the patterns & the code at the same time. 
10:47 < michaelfolkson> Ok cool, just wondered if there was a reason :)
10:48 < amiti> ok in the last few minutes here, we could talk about the actual PR a bit =P 
10:49 < amiti> what does PR 22950 enable for the code organization? what are some other factors to consider VS with isolated toy programs?
10:51 < michaelfolkson> Apparently addrman rework is coming!
10:51 < sipa> *drumrolls*
10:51 < michaelfolkson> https://github.com/bitcoin/bitcoin/pull/22950#issuecomment-925715583
10:51 < michaelfolkson> Ha
10:53 < amiti> ok, maybe a more leading question.. what is addrman_impl.h? 
10:54 < michaelfolkson> The header file for the implementation of addrman?
10:54 < jnewbery> it declares the AddrManImpl class
10:54 < amiti> jnewbery: exactly 
10:54 < amiti> why does it have to be in this second header file? 
10:55 < jnewbery> so it can be included by the unit tests
10:55 < gene> to put it in its own translation unit
10:56 < amiti> jnewbery: exactly
10:56 < amiti> also fuzz tests 
10:56 < michaelfolkson> Without the second header file it couldn't be included in the unit tests? I missed that
10:56 < amiti> gene: hmm, I thought translation units are the things that get compiled together 
10:57 < amiti> so header files get compiled into whichever translation units that import it 
10:57 < gene> amiti: errant thought, ignore me
10:57 < jnewbery> so even though the addrman.h header is only exposing a very limited interface to the rest of the code, the tests can still access test functions and members
10:57 < amiti> jnewbery: nicely put 
10:58 < lightlike> so we shouldn't start importing addrman_impl from random non-test locations.
10:58 < amiti> lightlike: +1 
10:58 < amiti> ok last couple minutes here, does anyone have outstanding questions?
10:59 < jnewbery> lightlike: I think addrman_impl should only be included by addrman.cpp and tests
10:59 < amiti> jnewbery: isn't that what lightlike is saying? 
11:00 < lightlike> yes, that's what i meant to say
11:00 < amiti> alright, that's time! thanks for coming everyone :) 
11:00 < gene> thanks for hosting amiti 
11:00 < jnewbery> sorry, yes I interpreted his sentence as a question and then just repeated what he said 😳
11:01 < raj_> thanks for hosting amiti , really educational discussion.. 
11:01 < jnewbery> thanks amiti! Great meeting!
11:01 < larryruane> thank you so much, amiti and everyone else! this was awesome!
11:01 < CoinForensics> Thank you amiti for explaining everything!
11:01 < naiza> Thanks a lot! Got to learn a lot. 
11:01 < jnewbery> #endmeeting
11:01 < ziggie> thanks !
11:01 < ementar4729> Thank you  amiti
11:01 < shoryak> thanks amiti 
11:01 < lightlike> thanks!
11:01 < grettke> Thank you amiti and everyone else. Great teachers and fun.
11:02 < michaelfolkson> Thanks amiti. How long does it take you to do those comics/graphics/diagrams? What do you use? :)
11:02 < Azorcode> Thanks amiti 
11:02 < larryruane> michaelfolkson: +1 I really love those graphics too
11:02 < amiti> I made these diagrams as I was learning the concepts. I use goodnotes on ipad (thanks to glozow for teaching me the way!)  
11:03 < Azorcode> nice
11:03 < glozow> amiti: <3
11:03 < schmidty> amiti: I also found the writeup (and diagrams) very helpful, thank you!
11:03 < michaelfolkson> Cool. You did the comics before glozow though right? Losing track of the chronology lol
11:04 < amiti> I don't know, doesn't seem important
11:04 < glozow> yeah amiti's been doing comics since before I started contributing to Bitcoin Core :)
11:04 < amiti> glozow: oh wow! hahahhaha
11:04 < naiza> glozow: <3 
11:04 < zakinator123> Thanks amiti!
11:05 < michaelfolkson> Before Gloria (BG)
11:05 < glozow> but I think other people were drawing diagrams since before any of us were born
11:05 < michaelfolkson> You may be right on that one
11:05 < larryruane> doesn't it seem like `explicit` should be the default? I would think implicit conversions would be confusing to readers
11:06 < larryruane> (does explicit only apply to constructors?)
11:11 -!- Azorcode [~Azorcode@201.211.37.206] has quit [Quit: Connection closed]
11:12 -!- naiza [~naiza@180.188.251.235] has quit [Quit: Connection closed]
11:22 -!- Blue_Moon [~Blue_Moon@189.130.130.132] has quit [Quit: Connection closed]
11:33 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
11:40 -!- shoryak [~shoryak@106.223.212.64] has quit [Quit: Connection closed]
12:08 -!- zakinator123 [~zakinator@216.30.182.130] has quit [Quit: Connection closed]
12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:16 -!- michaelfolkson [~michaelfo@138.68.143.20] has quit [Ping timeout: 252 seconds]
12:16 -!- michaelfolkson [~michaelfo@138.68.143.20] has joined #bitcoin-core-pr-reviews
12:21 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
12:39 -!- ementar4729 [~ementar47@189.122.185.237] has quit [Quit: Connection closed]
12:51 -!- CoinForensics [CoinForens@gateway/vpn/protonvpn/coinforensics] has quit []
12:57 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
12:58 -!- ziggie [~ziggie@user/ziggie] has quit [Quit: Client closed]
13:00 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has quit [Quit: ZNC - http://znc.in]
13:02 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews
13:11 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
15:56 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
16:20 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 265 seconds]
16:33 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
16:40 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 252 seconds]
16:46 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving]
17:11 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
18:54 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
18:55 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 268 seconds]
18:56 -!- lukedashjr is now known as luke-jr
18:56 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Client Quit]
18:57 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
18:58 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
19:00 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Remote host closed the connection]
19:01 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
19:03 -!- commmon [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews
19:06 -!- common [~common@096-033-221-075.res.spectrum.com] has quit [Ping timeout: 250 seconds]
19:29 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
20:42 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
20:42 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #bitcoin-core-pr-reviews
23:21 -!- commmon [~common@096-033-221-075.res.spectrum.com] has quit [Remote host closed the connection]
23:22 -!- commmon [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Sep 30 00:00:22 2021