17:01:09 <m-relay> <r​brunner7:monero.social> Meeting in 1 hour
18:00:04 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1267
18:00:30 <m-relay> <s​yntheticbird:monero.social> Hello
18:00:40 <plowsof> 👋
18:00:41 <m-relay> <r​brunner7:monero.social> Wondering whether we will make it to meeting 1337 ...
18:01:27 <m-relay> <j​berman:monero.social> *waves*
18:01:29 <m-relay> <s​needlewoods_xmr:matrix.org> Hey
18:02:59 <m-relay> <r​brunner7:monero.social> Let's start with the reports from last week.
18:03:02 <m-relay> <r​brunner7:monero.social> I studied the issue jberman explained in our last meeting and came to an opinion about approach: https://github.com/seraphis-migration/monero/pull/81#issuecomment-3289567931
18:04:59 <m-relay> <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 https://github.com/monero-project/monero/pull/10083
18:05:12 <m-relay> <j​effro256:monero.social> Howdy
18:06:18 <m-relay> <j​effro256:monero.social> Me: worked on https://github.com/monero-project/monero/pull/10077, https://github.com/monero-project/monero/pull/10081, and reviewing https://github.com/seraphis-migration/monero/pull/81
18:06:23 <m-relay> <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
18:06:40 <m-relay> <r​brunner7:monero.social> That wallet bug is somehow surprising. Did that escape so long, or did people encountering the bug not report?
18:08:00 <m-relay> <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)
18:08:26 <m-relay> <j​berman:monero.social> Or for someone to submit a tx not via their wallet
18:08:33 <m-relay> <r​brunner7:monero.social> By the way, I think that reviewing the code of #81 proper is beyond my knowledge, unfortunately ..
18:08:47 <m-relay> <r​brunner7:monero.social> Ah, I see, pretty rare situations then
18:09:46 <m-relay> <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
18:11:02 <m-relay> <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.
18:11:11 <m-relay> <j​berman:monero.social> jeffro256: I think most interesting relevant concurrency change that will be necessary to make is the one from this PR: https://github.com/monero-project/monero/pull/9936
18:11:57 <m-relay> <j​berman:monero.social> I *think* that will be necessary because otherwise scanning tasks can get queued and begin execution before the network request
18:12:59 <m-relay> <j​berman:monero.social> But I'll test and spend some time on it. I do think the code will end up simpler
18:14:44 <m-relay> <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 ?
18:15:17 <m-relay> <j​effro256:monero.social> This is something that I have been thinking about too
18:15:29 <m-relay> <j​effro256:monero.social> The diff is getting pretty large, almost 50k lines of code
18:15:39 <m-relay> <r​brunner7:monero.social> Wow
18:15:43 <m-relay> <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
18:15:59 <m-relay> <j​effro256:monero.social> including tests, but still
18:16:18 <m-relay> <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
18:16:21 <m-relay> <j​effro256:monero.social> Do we want to start merging basic things now?
18:16:37 <m-relay> <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
18:17:21 <m-relay> <r​brunner7:monero.social> Are there substantial pieces that could get merged independently?
18:18:03 <m-relay> <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
18:18:09 <m-relay> <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
18:18:13 <m-relay> <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 :(
18:18:44 <m-relay> <j​berman:monero.social> This should knock out something like 5k-10k lines of code
18:19:30 <m-relay> <r​brunner7:monero.social> Sounds good, as far as I can judge, which is not very far
18:19:41 <m-relay> <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
18:20:12 <m-relay> <r​brunner7:monero.social> With review for the pieces already?
18:20:19 <m-relay> <j​berman:monero.social> Right
18:20:44 <m-relay> <r​brunner7:monero.social> At least we would know early if that approach runs into roadblocks - if nobody reviews ...
18:21:02 <m-relay> <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
18:21:13 <m-relay> <j​effro256:monero.social> Especially in regards to reorg handling
18:22:36 <m-relay> <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
18:22:46 <m-relay> <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
18:22:48 <m-relay> <j​effro256:monero.social> *We might lose
18:22:56 <m-relay> <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
18:23:57 <m-relay> <r​brunner7:monero.social> It would be quite hard to enter reviewing in the middle, right? Best to follow reviewing over time
18:24:47 <m-relay> <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
18:25:28 <m-relay> <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
18:25:29 <m-relay> <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
18:25:50 <m-relay> <j​berman:monero.social> I plan to write detailed documentation that would also help do that anyway^
18:26:13 <m-relay> <r​brunner7:monero.social> Nice. Hopefully that won't take weeks, surprisingly
18:26:42 <m-relay> <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
18:27:09 <m-relay> <r​brunner7:monero.social> So maybe it's less bad than feared. Still *a lot* of code.
18:27:26 <m-relay> <r​brunner7:monero.social> In any case, that will be quite some adventure, I am sure.
18:27:30 <m-relay> <j​effro256:monero.social> Most of `carrot_impl` is independent, except for a handful of transaction format and rule changes
18:28:43 <m-relay> <r​brunner7:monero.social> Ok, we will see. Do we have more things to discuss today?
18:29:56 <m-relay> <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 :)
18:30:41 <m-relay> <s​needlewoods_xmr:matrix.org> thanks everybody
18:35:24 <m-relay> <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
18:37:03 <m-relay> <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?
18:37:10 <m-relay> <j​berman:monero.social> I haven't tried recently
18:37:37 <m-relay> <r​brunner7:monero.social> I think Windows 11 rules out certain older CPUs in this way, as a side effect
18:37:44 <m-relay> <r​brunner7:monero.social> Beside other brain-dead requirements
18:39:00 <m-relay> <r​brunner7:monero.social> Stuff like that: https://www.reddit.com/r/Windows11/comments/1e6q46g/so_how_badly_really_do_windows_11_require_the/
18:45:03 <m-relay> <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)
18:46:09 <m-relay> <s​needlewoods_xmr:matrix.org> both have some linux distros, no windows, both amd x86-64
18:49:22 <m-relay> <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
19:29:08 <m-relay> <o​frnxmr:monero.social> "use depends"
19:30:22 <m-relay> <o​frnxmr:monero.social> Stage is based on master, so quite a bit is different, notably c++17 instead of 11
19:34:18 <m-relay> <o​frnxmr:monero.social> I think we should
19:34:19 <m-relay> <o​frnxmr:monero.social> 1. branch master as v0.19
19:34:21 <m-relay> <o​frnxmr:monero.social> 2. Send fcmp++ prs to master
19:37:35 <m-relay> <o​frnxmr:monero.social> Stage is based on master, so quite a bit is different, notably c++17 instead of 14*
20:17:30 <m-relay> <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