<t​zadiko:matrix.org> 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:

<t​zadiko:matrix.org> 1: monero-project/monero #9831

<t​zadiko:matrix.org> 2: monero-project/monero #9852

<t​zadiko:matrix.org> 3: monero-project/monero #9838

<t​zadiko:matrix.org> 4: monero-project/monero #9842

<o​frnxmr:xmr.mx> Were cutting a new release and are way behind

.merges

Merge queue empty

<o​frnxmr:xmr.mx> The only pr relevant atm is monero-project/monero #9842

<o​frnxmr:xmr.mx> If this is reviewed and confirmed to be a correct bugfix, it maybe should go into the release

<o​frnxmr:xmr.mx> Tzadiko this needs to be squashed monero-project/monero #9831

the monero repo won't squash?

if it does, being able to see the commits as they logically happened can help a reviewer under the entire PR

it's up to the reviewer whether they look at the commits tab or the files tab (squash view)

+4 -3 22 commits

lol files tab

<o​frnxmr:xmr.mx> Person merging doesnt touch your code at all

<o​frnxmr:xmr.mx> The author squashed, period

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> Squashes*

if they're irrelevant, there's no reason to look at them

can go straight to the files tab

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 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

i can see the logic in that

for accountability purposes

<o​frnxmr:xmr.mx> Theres also the fact that cherrypicking this pr innvolves 22 commits, and rebasing onto it is a mess

<t​zadiko:matrix.org> 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).

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

<o​frnxmr:xmr.mx> For now, just need to squash 9831

<o​frnxmr:xmr.mx> Cherry-pick is not "just a rebase with less options" smh

<n​dorf:matrix.org> what's the minimum gcc version required these days (and/or how do i determine this for myself)?

<o​frnxmr:xmr.mx> Max* gcc version for depends builds :P

<o​frnxmr:xmr.mx> matrix.to/#/!ZdVDBBouJUyQVsewKn:mon…mx&via=matrix.org&via=monero.social

<t​obtoht:monero.social> ndorf: it's 8 for the master branch

<n​dorf:matrix.org> thanks. i guess that explains why we are still bothering with epee::span

<j​effro256:monero.social> We must still use `epee::span` since `std::span` was introduced in C++20 and our minimum supported standard version is C++17

<t​zadiko:matrix.org> 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.

<b​eimeiyizhilang:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/LXilFmRTJIcWohBsXmJahPJs

<b​eimeiyizhilang:matrix.org> How to download the latest version of the blockchain network

<t​zadiko:matrix.org> Run the daemon (Monerod.exe)

<b​eimeiyizhilang:matrix.org> 我没明白Tzadiko:

<o​frnxmr:xmr.mx> wallet gui will run the node for them

<b​eimeiyizhilang:matrix.org> image.png

<b​eimeiyizhilang:matrix.org> 我下载了这个 但是不能使用

<t​zadiko:matrix.org> 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

<o​frnxmr:xmr.mx> Delete

<t​zadiko:matrix.org> 把那个删掉吧 不是区块链

<o​frnxmr:xmr.mx> 狼只狼 Monero Support

<b​eimeiyizhilang:matrix.org> 好的

<b​eimeiyizhilang:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/XuwMrCeCmPAvBkjGjzuAydqI

<b​eimeiyizhilang:matrix.org> 是这个问题

<o​frnxmr:xmr.mx> Monero Support please

<t​zadiko:matrix.org> 有问题请用上面的渠道👆

<t​zadiko:matrix.org> 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<clipped message>

<t​zadiko:matrix.org> 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).

<t​zadiko:matrix.org> I've added an issue for it and I'll work on it: monero-project/monero #9866

<x​mrcookies:envs.net> It's just a Nostr event

<s​yntheticbird:monero.social> 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