01:01:34 <selsta> was asleep during the meeting, sorry lol
01:02:24 <selsta> 19:20 <UkoeHB> Is selsta around to give us an update/overview of the dev cycle for next hardfork? Or anyone else who knows about it? <-- I'm currently trying to get everything reviewed and merged, starting with 7169
01:07:02 <selsta> 19:34 <UkoeHB> sech1: is there anyone involved in release planning actually here? <-- so yes I'm working on it and have an overview
01:30:48 <selsta> .merge+ 8001 8005
01:30:48 <xmr-pr> Added
04:02:31 <xmrscott[m]> Re: flatpak it might be worth including ARM BigmenPixel . I could very well be doing something wrong, but my Pinephone doesn't seem able to find the monero flatpak desptie adding the flatpak package and flathub source
04:02:56 <xmrscott[m]> I'm curious as to how adaptive -gui is for a phone screen slightly below 1080p
04:06:04 <selsta> 19:39 <rbrunner> Ah, ok, so many small ones, not a big bang? <-- one big PR would be impossible to review, even at current sizes it's already difficult
04:13:15 <luigi1111w> .merges
04:13:15 -xmr-pr- 7798 7799 7804 7808 7859 7861 7867 7868 7869 7870 7876 7971 7993 7994 8001 8005
04:22:38 <BigmenPixel[m]> <xmrscott[m]> "Re: flatpak it might be worth..." <- I tried once to build with aarch64 but it didn’t work, maybe it’s worth waiting for the official aarch64 build? But I will try again.
04:31:19 <xmrscott[m]> Ok, thanks
05:01:43 <selsta> the monero repo now supports C++14 :)
05:12:24 <BigmenPixel[m]> <xmrscott[m]> "Ok, thanks" <- This time the build was successful ...
05:13:39 <xmrscott[m]> Good to know. Ping me if ARM support gets added to Flathub and I'll try to install on Pinephone again
05:14:25 <BigmenPixel[m]> xmrscott[m]: It remains to wait only for the post-install scripts, you can test it [here](https://flathub.org/builds/#/builders/32/builds/64003) (the link for download will appear)
05:27:02 <BigmenPixel[m]> done
05:27:03 <BigmenPixel[m]> ```
05:27:03 <BigmenPixel[m]> flatpak install https://dl.flathub.org/build-repo/61842/org.getmonero.Monero.flatpakref
05:27:03 <BigmenPixel[m]> ```
05:55:53 <selsta> vtnerd: is your BP+ PR review complete?
07:34:06 <BigmenPixel[m]> > <@bigmenpixel:matrix.org> done... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/68f8ccb1522e1cbb75e14334c1e0430727efa428)
09:37:21 <selsta> moneromooo: https://github.com/monero-project/monero/runs/3923219873 gamma unit test failed here, is that the one that occasionally fails?
09:38:03 <selsta> or does the unit test also need an update now that the output selection has been tweaked?
09:41:12 <moneromooo> It is inherently random since it checks stats on gamma picks.
09:41:46 <moneromooo> But if you modify the distribution, it will skew the stats. If the change is intended, then you should update the expected median.
09:42:09 <selsta> jberman[m]: ^
09:42:11 <moneromooo> Now, I'm not the one to make a judgement call on whether the expected median should be changed.
09:42:52 <moneromooo> IIRC that value is also taken from Miller et al.
09:43:35 <moneromooo> So if we consciously differ from that source, it makes sense to update the expected median to what we expect that new median to be.
13:53:57 <Rucknium[m]> selsta: Could you post the link to the source code of the test that failed?
13:57:33 <selsta> Rucknium[m]: tests/unit_tests/output_selection.cpp:112
14:04:31 <Rucknium[m]> It looks like the test doesn't set a random seed. Does it set a random seed?
14:06:19 <moneromooo> If you mean making it deterministic, then it'd make the test pointless since it's supposed to test distribution properties.
14:07:55 <Rucknium[m]> I disagree. Raise the sample size substantially and set a seed. Otherwise it will fail stochastically. I am not a software developer, however.
14:08:47 <Rucknium[m]> You're missing implicit failures by having a lower sample size and no seed set.
14:08:52 <moneromooo> That's the point. If you set a seed, then whatever series it generates will always match the test, by construction.
14:09:16 <moneromooo> Raising the sample size will slow it down, IIRC it's already several seconds.
14:09:35 <moneromooo> But if it's not, raising's fine.
14:09:58 <selsta> >586 ms total
14:10:00 <Rucknium[m]> As it is now, with no seed, there is always a non-zero chance of the test failing, from what I understand.
14:10:01 <selsta> on my machine
14:10:14 <moneromooo> Oh that's not too bad then.
14:17:07 <Rucknium[m]> moneromooo: You should ask Syksy about this issue. He's written R statistical packages with tests. I did a quick search and it looks like at least one of his packages has a test that sets a seed. It might not be appropriate for what Monero is doing here, but it's worth looking into I think.
14:19:29 <moneromooo> I did not generalize my statement above to all uses of seeds in tests.
14:20:21 <moneromooo> Now, I do not care enough to argue the point further, I just gave my opinion.
14:20:44 <moneromooo> When I think about these things, I like to take an extreme example and see if it seems obviously wrong:
14:22:23 <moneromooo> Here, if we were to test a dice rolling program, which can roll 1-6, and check each number appears ~17% of the time, if you'd run it once with some seed and found it did about right, setting this seed in the test would prevent you seeing that it does break if, I dunno, the CPU's out of cheese or something.
14:23:00 <moneromooo> That is my point here: hardcoding the seed locks the test to a working data set, which makes the test more or less pointless.
14:23:23 <moneromooo> It'll catch cases of bugs when changing the gamma pick, but not existing bugs. 
14:23:54 <moneromooo> It locks in the "I got lucky" factor when you decided on the seed.
14:24:55 <hyc> if the point is reducing the test's dependence on luck, then you can only do that by running with a wide range of seeds, no?
14:25:09 <moneromooo> Yes.
14:25:26 <moneromooo> I concede random failures is annoying though.
14:25:52 <hyc> non-reproducible failures are annoying, yes
14:26:14 <Rucknium[m]> I agree with your point, overall. That's why I suggested raising the sample size. What's happening now is that you are relying on running the build process many times to catch bugs. That seems like not a good practice.
14:26:19 <hyc> in LMDB source we have a randtest program that uses randomly generated test cases, but we print the randseed at the start of each iteration
14:26:30 <moneromooo> I agree with raising the sample size.
14:26:37 <Rucknium[m]> hyc: The better way to do it is to raise the sample size.
14:27:07 <hyc> you obviously need to do both. if you don't know what the random seed was that triggered a failure, you can't verify a fix later.
14:28:03 <hyc> tests must always be repeatable/reproducible
14:28:05 <Syksy> context of the simulations does matter a lot; for scientifically reproducible results, a seed is pretty much obligatory so others can reproduce your results
14:28:11 <Rucknium[m]> Again, I have not looked into the issue very closely, but I think raising the sample size (i.e. doing the test many more times) would be a much higher priority than setting a seed. So I think we may be in agreement that sample size should be raised.
14:28:51 <Syksy> For applications you'd want to run over multiple seeds ideally, but ideally it shouldn't matter - I did run Rucknium's monte carlo simulations with one additional seed and the results seemed consistent with the previous seed
14:29:07 <Rucknium[m]> hyc: I agree that printing the seed would help a lot with the goals of the test/build process.
14:29:31 <Syksy> Of course with simulations the first question is always is the simulation schema correct for the desired application; for Monero use cases it's hard to tell because the truth is not known :)
14:30:10 <Syksy> But I could say based on running a second seed that the second simulations produced consistent results with the original simulations
14:30:42 <Rucknium[m]> Yes, with large enough sample size and a sound pseudo-random number generator, the seed shouldn't really matter.
14:31:47 <hyc> on a tangent: at this point we could take a large chunk of Bitcoin history and duplicate it on a monero testnet. I.e., duplicate transactions, number if unique addresses, etc.
14:32:28 <hyc> in that way we'd know something of the truth behind the simulation
14:34:27 <Rucknium[m]> Maybe someone could explain to Syksy what the purpose of this test is, and he can offer a view on seeds and sample sizes:
14:34:27 <Rucknium[m]> https://github.com/monero-project/monero/blob/753dc901a11c5597fe0a7f8a8ba039762117d54c/tests/unit_tests/output_selection.cpp#L112-L134
14:35:10 <moneromooo>   ASSERT_GE(median, 1.3 * 86400);
14:35:10 <moneromooo>   ASSERT_LE(median, 1.6 * 86400);
14:35:26 <moneromooo> It looks to me it checks the median age.
14:38:02 <moneromooo> In fact, if you rewrite the fake out selection, this test becomes moot, so you'd write whatever other tests make sense for your new algorithm.
14:39:10 <Rucknium[m]> Yes I agree that new tests will probably need to be written.
14:40:52 <Rucknium[m]> <moneromooo> "It looks to me it checks the..." <- To be more clear, is it the case that it constructs N rings and ensures that none of the rings have output ages with a median greater than some Z?
14:41:23 <moneromooo> No. It picks N outputs and checks the median.
14:41:54 <moneromooo> Against the expected value from Miller et al IIRC.
14:42:40 <moneromooo> I remember chatting with... sarang I believe, at the time, for what tests would be useful. So the value might not come from Miller et al...
14:47:02 <Rucknium[m]> So it is checking gamma_picker itself, but not the ring member constructor, I think. From my understanding, gamma_picker is used as part of the ring member constructor, but there are more parts to it.
14:49:16 <Rucknium[m]> I would agree that checking a median is a useful sanity check. I don't think that checking the median is an explicit recommendation of Moser et al (2018). (That's not to say that I would recommend blindly relying on their recommendation ;) )
14:57:14 <selsta> I can make a PR to double the sample size.
14:58:42 <moneromooo> Rucknium[m], jberman[m]: you may want to think about whether the "if (o >= n_outs) continue;" should be removed too. 
14:59:01 <moneromooo> It looks similar to what you changed recently.
15:01:43 <Rucknium[m]> selsta: I will put "examine sample size and random seed matters in Monero's unit tests" on the upcoming MRL agenda.
15:30:11 <xmrscott[m]> BigmenPixel: I'll test it again the next 12 hours or so when I can
16:46:15 <jberman[m]> gonna play around with this test locally, I think more can be done with it, and I think it would be fine to 10x the ages vector. rolling is pretty quick
16:48:41 <jberman[m]> I'm not sure how to get to an expected median between 1.3 and 1.4 though. Plug in shape=19.28, rate=1.61 and P(X<x)=0.5, and you get x=11.76876. e^x = 129,153.9 / 86,400 = 1.49
16:48:59 <jberman[m]> https://homepage.divms.uiowa.edu/~mbognar/applets/gamma.html
16:49:11 <jberman[m]> Can also repro expected median with this code: https://paste.debian.net/1215890/
16:49:56 <jberman[m]> Above being said, the recent change should actually cause the gamma picker to pick more recent outputs than it was picking before, so it seems it's probably moving even further younger. The recent changes should be getting it closer to the paper's rec though, not moving further away. going to take a closer look at the test locally
21:26:55 <Guest38> hi there, have python skills, familiar with django, want to learn monero basics and create exchange web app, should i know some basic and if that to which?)
21:28:08 <Guest38> hi there, have python skills, familiar with django, want to learn monero basics and create exchange web app, should i know some basic and if that then which?)
21:31:05 <Guest38> ok, I think I should start on clone repo)
21:32:08 <Guest38> but if some one gives me a little help of pre requirements, it would be great
21:44:18 <BusyBoredom[m]> I'd recommend reading "zero to monero" if you'd like to understand the inner workings of monero. 
21:45:01 <helgibergmann[m]> thanks
21:45:38 <BusyBoredom[m]> No problem