<r​brunner7:monero.social> Meeting in 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1267

<s​yntheticbird:monero.social> Hello

👋

<r​brunner7:monero.social> Wondering whether we will make it to meeting 1337 ...

<j​berman:monero.social> *waves*

<s​needlewoods_xmr:matrix.org> Hey

<r​brunner7:monero.social> Let's start with the reports from last week.

<r​brunner7:monero.social> I studied the issue jberman explained in our last meeting and came to an opinion about approach: seraphis-migration/monero #81#issuecomment-3289567931

<j​berman:monero.social> me: mostly worked on implementing comments from that PR above^ (it was ready for review but looks like will be working on further changes), also implemented monero-project/monero #10083

<j​effro256:monero.social> Howdy

<j​effro256:monero.social> Me: worked on monero-project/monero #10077, monero-project/monero #10081, and reviewing seraphis-migration/monero #81

<s​needlewoods_xmr:matrix.org> `grep "\<m_wallet\>" src/simplewallet/simplewallet.cpp -c` yields 148 results (that's <25% left), but some of them are a little more tricky, like all the transfer/sweep commands are still left to do

<r​brunner7:monero.social> That wallet bug is somehow surprising. Did that escape so long, or did people encountering the bug not report?

<j​berman:monero.social> I expect it's rare because it requires either a parallel wallet with same seed running, or for a tx to remain in the pool while a wallet is being restored (which probably takes longer than 2 mins usually)

<j​berman:monero.social> Or for someone to submit a tx not via their wallet

<r​brunner7:monero.social> By the way, I think that reviewing the code of #81 proper is beyond my knowledge, unfortunately ..

<r​brunner7:monero.social> Ah, I see, pretty rare situations then

<j​berman:monero.social> I think your point in #81 was ok. Especially in light of the latest round of changes, which added the caveat that m_blockchain can extend back further than the tree cache to handle granularized refresh and added more complexity to managing m_blockchain correctly

<r​brunner7:monero.social> I saw in the debugger that "short blockchain history" or how it's called merely gets 27 elements in the list. Peanuts.

<j​berman:monero.social> jeffro256: I think most interesting relevant concurrency change that will be necessary to make is the one from this PR: monero-project/monero #9936

<j​berman:monero.social> I *think* that will be necessary because otherwise scanning tasks can get queued and begin execution before the network request

<j​berman:monero.social> But I'll test and spend some time on it. I do think the code will end up simpler

<r​brunner7:monero.social> Thinking ahead I was asking myself recently how we will do it with reviewing when tons of code now in the staging repository will get into PR(s) to the main branch. Isn't that an almost impossible task for "outsiders" i.e. not jeffro256 and jberman ?

<j​effro256:monero.social> This is something that I have been thinking about too

<j​effro256:monero.social> The diff is getting pretty large, almost 50k lines of code

<r​brunner7:monero.social> Wow

<j​berman:monero.social> I was hoping to start discussing this soon too :) but these wallet issues may begin to take higher priority in the interim

<j​effro256:monero.social> including tests, but still

<j​berman:monero.social> In any case, I've been thinking about an approach for my side of FCMP++ integration stuff that would make the review process easier

<j​effro256:monero.social> Do we want to start merging basic things now?

<r​brunner7:monero.social> I am not sure a look back may help, when moneromooo also implemented a lot of code e.g. implementing RingCT and then (probably) made a monster PR

<r​brunner7:monero.social> Are there substantial pieces that could get merged independently?

<j​berman:monero.social> For curve trees related things, I was thinking of submitting smaller PR's in the following order: FFI first, then curve trees memory-based code (nothing plugged into consensus), then db curve trees code, then consensus changes

<j​effro256:monero.social> We also want want to start refactoring things which change the logical flow of the codebase to make future FCMP++ integration easier to review, so that we're not mixing refactoring + logical + FCMP changes all together like we have been

<r​brunner7:monero.social> Of course it would have been the same story, or even worse, with Seraphis, but we didn't get as far :(

<j​berman:monero.social> This should knock out something like 5k-10k lines of code

<r​brunner7:monero.social> Sounds good, as far as I can judge, which is not very far

<j​berman:monero.social> And I was thinking of proposing a new fcmp++-stage branch in the core Monero repo, and making the piecemeal PR's to that branch. Then once all the pieces are in, a large PR to master with everything

<r​brunner7:monero.social> With review for the pieces already?

<j​berman:monero.social> Right

<r​brunner7:monero.social> At least we would know early if that approach runs into roadblocks - if nobody reviews ...

<j​effro256:monero.social> The big downside with this approach is that if PRing and reviewing takes many weeks, a lot of merge conflicts may come up and certain pieces may have to be re-reviewed

<j​effro256:monero.social> Especially in regards to reorg handling

<j​effro256:monero.social> Psychologically, it may also reduce pressure to review if PR'ing to a non-master branch. We want might lose information on how to bisect potentia issues if PR'ing to a branch all at once

<r​brunner7:monero.social> This strikes me as something worth thinking about a bit, then rest, then thinking some more, then discussing, until things start to converge to a workable approach

<j​effro256:monero.social> *We might lose

<j​berman:monero.social> I *think* we can get many thousands of lines reviewed carefully this way before introducing the code that *would* conflict with master

<r​brunner7:monero.social> It would be quite hard to enter reviewing in the middle, right? Best to follow reviewing over time

<j​berman:monero.social> A lot of this code is like legos that don't rely on wider dependencies from across the repo. The curve trees handling part specifically. I think it would be beneficial to have that part reviewed separately. And then when a reviewer understands that lego, it becomes easier to review the whole

<r​brunner7:monero.social> I remember koe's epic code walkthrough for his Seraphis library. I think something like that would be necessary at least for the curve tree management stuff

<j​berman:monero.social> We could do a large PR and also provide some suggested instruction/guidance on how to review it piece by piece

<j​berman:monero.social> I plan to write detailed documentation that would also help do that anyway^

<r​brunner7:monero.social> Nice. Hopefully that won't take weeks, surprisingly

<j​effro256:monero.social> The `carrot_core` library is also basically completely independent besides the `cncrypto` library and the `ringct_basic` library, which aren't really expected to change much

<r​brunner7:monero.social> So maybe it's less bad than feared. Still *a lot* of code.

<r​brunner7:monero.social> In any case, that will be quite some adventure, I am sure.

<j​effro256:monero.social> Most of `carrot_impl` is independent, except for a handful of transaction format and rule changes

<r​brunner7:monero.social> Ok, we will see. Do we have more things to discuss today?

<r​brunner7:monero.social> Doesn't look like it. Thanks everybody for attending, read you again next week. With even more code produced that we will have to review :)

<s​needlewoods_xmr:matrix.org> thanks everybody

<s​needlewoods_xmr:matrix.org> one question, not for the meeting, has anyone tried a static build recently? I'm relatively certain I used `ARCH=generic make release-static` before on the `fcmp++-stage` branch to get a binary that I can run on an old laptop, but I can't get a working binary out of `release-v0.18` or `master` branch, always ending up getting `illegal instruction` error when I try to run it on the old lapt

<r​brunner7:monero.social> Hmm, maybe it's a CPU instruction problem? One that the code generator produces, but your old CPU does not support?

<j​berman:monero.social> I haven't tried recently

<r​brunner7:monero.social> I think Windows 11 rules out certain older CPUs in this way, as a side effect

<r​brunner7:monero.social> Beside other brain-dead requirements

<r​brunner7:monero.social> Stuff like that: reddit.com/r/Windows11/comments/1e6…ly_really_do_windows_11_require_the

<s​needlewoods_xmr:matrix.org> AFAIU there was a CPU problem, but after using `ARCH=generic` (I tried many things, but I think this solved the problem) I got a "fcmp++-monerod" that I can run on the old laptop, so I think the problem is either A) some libs changed on my "work laptop" that I used to compile B) something in CMake file changed between `release-v0.18` and `fcmp++-stage` branch C) skill issue (probably this)

<s​needlewoods_xmr:matrix.org> both have some linux distros, no windows, both amd x86-64

<s​needlewoods_xmr:matrix.org> okay after `rm -rf fcmp++-build-dir` and running the make command again I get the same error as for `release-v0.18` .. so it's probably a problem on my end

<o​frnxmr:monero.social> "use depends"

<o​frnxmr:monero.social> Stage is based on master, so quite a bit is different, notably c++17 instead of 11

<o​frnxmr:monero.social> I think we should

<o​frnxmr:monero.social> 1. branch master as v0.19

<o​frnxmr:monero.social> 2. Send fcmp++ prs to master

<o​frnxmr:monero.social> Stage is based on master, so quite a bit is different, notably c++17 instead of 14*

<s​needlewoods_xmr:matrix.org> little update, then enough offtopic: after some cleaning up, I could get the `fcmp++-stage` branch to work again and also monero-project `master` branch, still no luck with `release-v0.18` (even with "depends"). Will look into it later and report in dev channel if I find a problem