01:28:13 <br-m> <jpk68:matrix.org> I could be wrong, but it seems adopting utf8proc would also allow us to replace some homegrown canonicalization functions
01:28:27 <br-m> <jpk68:matrix.org> For example, src/common/utf8.h. I think there are also some instances in epee
05:47:40 <br-m> <rbrunner7> @jpk68:matrix.org: Pretty sure that's correct, that's some ugly "handmade" code that we could replace later on.
07:24:37 <br-m> <thomasbuilds:matrix.org> is migrating off boost welcomed?
07:24:37 <br-m> <thomasbuilds:matrix.org> I'm thinking to boost::string_ref -> std::string_view
07:32:29 <br-m> <thomasbuilds:matrix.org> boost::optional → std::optional is probably the cleaner first step
07:35:15 <br-m> <ofrnxmr:xmr.mx> what is the gain?
07:52:28 <br-m> <thomasbuilds:matrix.org> Mostly modernization: std types, lighter includes, less version-bump churn... Real gain would be when a compiled boost lib is fully removed (chrono/thread/filesystem -> std) and drops off the link line
08:03:02 <moneromooo> Funny how it's all subjective. Your "real gain" is a "mostly pointless change" for me. The only gain I see in what you just said is lighter includes, assuming the "lighter" is significant enough performance wise.
08:04:39 <moneromooo> There is at least one thing where the use of boost instead of std is intended. I *think* it was a threading related type, and I *think* it was due to some bug in the STL shipping with GCC. Can't recall more than that.
08:05:28 <moneromooo> (though I don't know what you mean by "less version-bump churn", that might be a plus too)
08:05:57 <moneromooo> There have been new bugs introduced from "cleanup" patches before. It's not a theoretical danger.
08:23:43 <br-m> <thomasbuilds:matrix.org> On less version-bump churn I meant boost occasionally deprecates/removes APIs between releases, so bumping the pinned version sometimes needs guards
08:35:58 <br-m> <thomasbuilds:matrix.org> moneromooo: this? https://github.com/monero-project/monero/pull/1721
08:39:16 <moneromooo> Seems probable.
08:47:19 <sech1> So we keep using boost because some GCC version didn't work properly with threads on mingw 9 years ago? Do I get it right?
08:56:12 <moneromooo> For this type, yes.
08:59:10 <moneromooo> (coupled with if it ain't broke, don't fix it)
09:06:27 <Guest44> Hi
11:09:15 <sech1> selsta I've reviewed what looks to be the last of the pending review PRs for 0.18.5.1
11:09:45 <selsta> ty
11:13:31 <sech1> Hopefully we'll get it out soon because many P2Pool users just don't know how to update P2Pool separately from Monero-GUI
11:13:39 <tobtoht> .merges
11:13:39 <xmr-pr> 10597 10598 10646 10774 10790 10801
11:56:35 <selsta> sech1: could you check 10646 again?
12:19:56 <sech1> done
12:41:34 <br-m> <rbrunner7> I have a method in a class with a template parameter, like this:
12:41:35 <br-m> <rbrunner7> template<class str_type>
12:41:35 <br-m> <rbrunner7>     void data::encode(const language& lang, str_type& str) const
12:42:37 <br-m> <rbrunner7> I wanted to only have these 2 lines in the .h file, and move the implementation to the .cpp file. The .h and the .cpp file compile, but later the linker complains about a missing method.
12:43:10 <br-m> <rbrunner7> So that's not possible? I have to implement right in the .h file for the templating to work out right?
12:49:58 <sech1> You can put specializations of this template into the cpp file, but if any specialization is missing you will get linker errors.
12:50:14 <sech1> When the code is entirely in the header, compiler creates specializations automatically, and linker then finds them
12:50:49 <sech1> If you just put the generic template code in cpp file, it will not be specialized (apart from the explicit specializations in that single cpp file)
12:52:04 <sech1> so you'd have to do something like this in the cpp file: https://paste.debian.net/hidden/58f8e138
12:53:21 <sech1> exact syntax might be a bit different
12:54:04 <br-m> <rbrunner7> I see, thanks. Kind of defeats the whole purpose of templating somehow, if you have to give all the instantiations that you want to support yourself in the .cpp file ...
12:57:04 <sech1> It doesn't, use still have one copy of the code, you just declare each specialization (without copying the code)
12:57:11 <sech1> *you still have
15:03:14 <br-m> <vtnerd> And we alter the stack size with boost thread. This isn't possible with std thread. I forget the platform where this was needed > <sech1> So we keep using boost because some GCC version didn't work properly with threads on mingw 9 years ago? Do I get it right?
15:03:43 <br-m> <vtnerd> And asio isn't easily replaced, although there's a standalone version
15:10:19 <sech1> asio is another story, not so easy to replace indeed
22:48:47 <selsta> .merge+ 10798
22:48:47 <xmr-pr> Added