02:05:40 I have a couple of small open PRs with comments addressed; I want to know if I can get some eyes on them when people are free: 02:05:40 1: https://github.com/monero-project/monero/pull/9831 02:05:42 2: https://github.com/monero-project/monero/pull/9852 02:05:44 3: https://github.com/monero-project/monero/pull/9838 02:05:46 4: https://github.com/monero-project/monero/pull/9842 02:47:26 Were cutting a new release and are way behind 02:48:56 .merges 02:48:56 Merge queue empty 02:52:20 The only pr relevant atm is https://github.com/monero-project/monero/pull/9842 02:53:11 If this is reviewed and confirmed to be a correct bugfix, it maybe should go into the release 02:55:38 Tzadiko this needs to be squashed https://github.com/monero-project/monero/pull/9831 02:58:02 the monero repo won't squash? 02:59:23 if it does, being able to see the commits as they logically happened can help a reviewer under the entire PR 03:00:16 it's up to the reviewer whether they look at the commits tab or the files tab (squash view) 03:03:11 +4 -3 22 commits 03:04:53 lol files tab 03:05:18 Person merging doesnt touch your code at all 03:05:30 The author squashed, period 03:06:47 The +4 -3 was a much larger change, that but scope of pr changed from complicated to very simple. None of the complicated commits are relevant to the pr 03:06:54 Squashes* 03:08:03 if they're irrelevant, there's no reason to look at them 03:08:10 can go straight to the files tab 03:09:05 Could maintainer press "squash and merge"? Yes. Should they? Absolutely not. For the same reason they shouldnt modify your pr or commit directly to the repo. PRs are merged as-is, and are 1:1 with the commit history 03:12:21 and re "logically see commits as they happen" is fine. You still have to squash before it can be merged. The specific pr i mentioned has 1/22 relevant commits and is a very simple fix. It wont be "approved" until it is squashed, because it would (typically) need to be re-approved after squash to confirm nothing changed 03:14:31 i can see the logic in that 03:14:39 for accountability purposes 03:21:14 Theres also the fact that cherrypicking this pr innvolves 22 commits, and rebasing onto it is a mess 04:32:31 Okay, I thought squash happens after approval. I’ll squash. My only fear was other may want to comment on some of the unreviewed MRs, so I’d be squashing only to potentially push more commits prompted by comments. Will squash them all tomorrow (am away till then). 04:38:33 rebasing would only be an issue if there's interlaced conflicting changes. and a cherry-pick is just a rebase with less options. so not that likely to run into that issu e 05:56:30 For now, just need to squash 9831 05:57:49 Cherry-pick is not "just a rebase with less options" smh 15:45:46 what's the minimum gcc version required these days (and/or how do i determine this for myself)? 15:46:28 Max* gcc version for depends builds :P 15:47:12 https://matrix.to/#/!ZdVDBBouJUyQVsewKn:monero.social/$2BgQxBs7pnAVCpXLzD3vFTV6bTkPB58EDmLmYobIx70?via=xmr.mx&via=matrix.org&via=monero.social 16:04:52 ndorf: it's 8 for the master branch 16:23:14 thanks. i guess that explains why we are still bothering with epee::span 19:43:39 We must still use `epee::span` since `std::span` was introduced in C++20 and our minimum supported standard version is C++17 20:33:37 std::span is just a pointer and a length, and is non-owning, so if there is an API not present in epee::span that exists in std::span, it shouldn’t be too hard to add it. 20:47:15 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/LXilFmRTJIcWohBsXmJahPJs 20:47:42 How to download the latest version of the blockchain network 20:50:51 Run the daemon (Monerod.exe) 20:54:19 我没明白Tzadiko: 20:55:13 wallet gui will run the node for them 20:55:40 image.png 20:55:49 我下载了这个但是不能使用 20:55:50 Ya but that’s easier to understand tk a Chinese user than trying to explain tk him how to run a local node from the GUI 20:55:58 Delete 20:56:45 把那个删掉吧不是区块链 20:57:00 狼只狼 Monero Support 20:57:25 好的 20:57:38 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/XuwMrCeCmPAvBkjGjzuAydqI 20:57:40 是这个问题 20:57:49 Monero Support please 20:58:34 有问题请用上面的渠道👆 22:20:17 I noticed a pattern in the codebase where we have classes postfixed with Impl. I thought this means that they're looking to implement the PIMPL idiom (e.g. TransactionInfoImpl inerhits from TransactionInfo), but here Impl actually just refers to an implementation of the virtual interface (TransactionInfo is actually an interface). The use of inheritance here isn't needed. It incre 22:20:18 ases the size of any instance of the class (via the inclusion of the virtual table pointer). Furthermore, objects of type TransactionInfo are created with `new`, which is a heap allocation (is slow, and not needed in this context). 22:20:20 I've added an issue for it and I'll work on it: https://github.com/monero-project/monero/issues/9866 22:25:33 It's just a Nostr event 23:14:11 Reminder that IRC cannot see matrix reply, so you just said "It's just a Nostr event" out of nowhere. next time ping moneromooo by writing his name in your message