05:11:02 <vtnerd> selsta : yeah next task
06:40:48 <grc001[m]> Hey folks, wen btc-xmr atomic swaps arrive it'd be really cool to see an xmr-trx atomic swap for usdt(trc20) transfers. erc20 too pricey... that is all. thank you.
07:00:53 <awhelpqjrcg> 'Oddly, no one who was directly involved with the SIR-C missions and currently still working the Lab, remembers the name Howard Chu, except for one who vaguely recalls Eugene Chu as having a brother names Howard'
07:00:53 <awhelpqjrcg> Ed Caro, NASA Chief Engineer. cryptogazette.com/wp-content/uploads/2019/12/1-768x1445.png
11:48:32 <juhgg> hello
11:51:56 <moneromooo> So close.
13:17:07 <xiewkixsmwkc> What kind of person steals from their own community? http://removeddit.com/r/Monero/comments/6d6okb/fluffypony_needs_to_give_up_his_commit_access_and/ (changed link to removeddit since /r/monero mod removed to try to cover it up - maybe fluffy himself?)
14:29:56 <selsta> mj-xmr_: btw, it seems the clion is more popular than codeblocks
14:31:02 <selsta> hmm ok ignore what I said, clion is a paid program
14:38:03 <bobbieweirder[m]> does someone know anything about DAPS? it claims to be a decentralized BTC layer using RingCT with staking and random ring sizes. i am not finding a lot of discussions yet so i wanted to see if anyone here has any thoughts
14:38:03 <bobbieweirder[m]> https://officialdapscoin.com/wp-content/uploads/2020/09/DAPS-WHITE-PAPER-2020.pdf
14:41:09 <moneromooo> This channel is about monero development.
14:48:59 <bobbieweirder[m]> but monero’s development doesn’t happen in a vacuum right? i just figured if another project is claiming to use our tech better it would invite discussions on whether we need to challenge our earlier assumptions so we can continue get better (if necessary). but i didn’t mean to speak out of turn. i can take the discussion elsewhere. sorry!
14:57:34 <moneromooo> If you can have better questions than that, they might well be on topic :)
14:58:17 <moneromooo> Just understanding how some altcoin works does not seem to be though.
15:00:31 <bobbieweirder[m]> i respect that. let me do some more digging and come back with something better
15:39:46 <mj-xmr_> selsta, we were using CLion at work, but as you noted. Also MS VS could be something to mention. Both use CMakeLists.txt natively. Same category, but VS is free. CodeBlocks belongs to the same category as Eclipse CDT, which would maybe be a better option than CB for many, yeah.
15:43:26 <mj-xmr_> and both are equally unstable :D
16:52:03 <CCosta[m]> so, I'm trying to figure out how to read the binary from `/get_txpool_backlog` from the daemon rpc - is there a piece of code that I could take a look at as reference?
16:52:47 <CCosta[m]> from https://github.com/monero-project/monero/commit/55bec1f03db039e03bfccec24c88ff08b15b6381 I can't really tell how that array is being serialized (so that I can deserialize in my code)
16:54:28 <CCosta[m]> (yes, I see  `KV_SERIALIZE_CONTAINER_POD_AS_BLOB(backlog)`, but, not sure how I deserialize it)
17:03:00 <moneromooo> I think vtnerd added some doc for serialization. find . -name \*.md
17:03:42 <moneromooo> But the AS_BLOB will be (I think) a varint for the size and a wholesale memcpy.
17:04:13 <moneromooo> That's the reason for the binary call, to avoid per field processing.
17:09:33 <floam412> can I buy the dev team a couple bottles of barolo?
17:09:41 <floam412> :)
17:10:05 <floam412> you guys have been working your asses off from what it looks like outside of the freenode IRC world
17:15:14 <mj-xmr_> Really? From here it looks like a dope party :)
17:38:44 <CCosta[m]> <moneromooo "That's the reason for the binary"> makes sense - I'll take a look at it - thanks!
19:57:52 <mj-xmr_> Reporting in: http://enjo.hopto.org/pub/monero/
19:58:33 <mj-xmr_> Crunched the numbers of last series of merges from yesterday.
19:59:10 <wfaressuissia[m]> ping next time if there is anything interesting in those automatically calculated numbers
20:00:16 <mj-xmr_> The interesting part is inside the reports. What they helped me already with was finding the bottlenecks of the core_tests.
20:01:15 <wfaressuissia[m]> Could it help to find bottlenecks of randomx miner ?
20:01:20 <mj-xmr_> But it does require some active detectivism.
20:01:57 <mj-xmr_> You could for sure use the Valgrind script to setup an appropriate experiment, yes.
20:02:15 <mj-xmr_> I could tutor you tomorrow, if you like.
20:02:29 <wfaressuissia[m]> I suppose the answer is it can't
20:02:38 <mj-xmr_> Why?
20:02:49 <mj-xmr_> Forgot to add: It doesn't make coffee.
20:03:55 <mj-xmr_> https://github.com/monero-project/monero/tree/master/utils/health#valgrind-checks
20:04:24 <mj-xmr_> Write a unit test for randomX, loop it, and filter out all other tests. Plug it in the config file. Done.
20:05:01 <wfaressuissia[m]> Let increase difficulty of the task: find the bottleneck and solution to speed up it
20:05:14 <mj-xmr_> A lot of things are possible. The question is: who has the time to review what you find out?
20:05:46 <mj-xmr_> For instance, I reduced the core test speed by 90%. Not merged yet. Got your answer?
20:06:28 <mj-xmr_> So I won't be spamming the devs with 10 branches of the same type. It only increases my maintenance burden.
20:07:01 <wfaressuissia[m]> It'll be interesting to see that core tests 90% speed up in details after submitted PR
20:07:38 <mj-xmr_> Be my guest: https://github.com/monero-project/monero/pull/7469
20:08:54 <mj-xmr_> It works fine, just by default it was decided to be switched off for valid reasons. But it's just a switch.
20:09:46 <selsta> I still don't fully get it. How do I know when to to regenerate the cache?
20:09:59 <wfaressuissia[m]> That's not speed up but reuse of old cache and requires manual approval since it isn't general purpose caching
20:10:50 <mj-xmr_> selsta, You know that you don't need to regenerate the cache when you know, that you haven't touched the part, that has to do with the data generation.
20:11:33 <moneromooo> but if you know you didn't, you don't need to run the tests again do you ?
20:11:59 <wfaressuissia[m]> yes, it's 100% speed up then :D
20:12:03 <moneromooo> I guess if you changed verification only. But that's fairly rare.
20:12:16 <moneromooo> Anyway, it seems very dangerous to me.
20:12:48 <mj-xmr_> These are high level tests, able to catch failures of many types.
20:13:26 <mj-xmr_> So I don't see why I would be happy with not running the tests if I modified a functionality that can affect the verdict.
20:13:51 <wfaressuissia[m]> "Anyway, it seems very dangerous to me." if someone don't know what is going on inside the code then 5 minutes blind test is better than nothing and and faster than 52 minutes test
20:14:08 <wfaressuissia[m]> but it's better to read the code instead
20:14:31 <mj-xmr_> better is to do both.
20:14:41 <mj-xmr_> We're not machines
20:14:54 <wfaressuissia[m]> We're better than machines
20:14:59 <mj-xmr_> And sometimes we're sleeeepy
20:15:48 <mj-xmr_> Which reminds me, that in our SCRUM teams, the POs/SMs blindly believe in the code review process to catch ALL the mistakes, that the CI didn't. A typical reason for failure of the projects.
20:16:53 <mj-xmr_> You wouldn't believe what shit goes to master at times after a formal review ...
20:17:30 <wfaressuissia[m]> your quote would be appropriate to some PR that adds more tests but not reusing old cache of existing ones
20:18:35 <mj-xmr_> Which quote now?
20:18:54 <mj-xmr_> And which old cache of existing ones?
20:19:10 <mj-xmr_> Each test has its own cache.
20:20:51 <wfaressuissia[m]> not quote but statement about some; cache of core tests
20:21:08 <mj-xmr_> In my SCRUM story I was referring more to blind faith in humans ability to catch mistakes.
20:21:18 <wfaressuissia[m]>  * not quote but statement about SCRUM teams; cache of core tests
20:23:39 <mj-xmr_> Tests can be added anytime. But if you know that adding another test will cost another 20 minutes every time you run it, do you think you and others will have motivation to run these tests frequently?
20:24:13 <selsta> don't write tests that take 20min :D
20:24:37 <mj-xmr_> selsta, you're right. We're already full of them. But then again, should I remove them? :)
20:25:13 <mj-xmr_> Because improving the test's speed at the core by modifying the implementation was rejected here Big Time.
20:25:29 <mj-xmr_> moneromooo knows the pain as well.
20:26:00 <mj-xmr_> So there's not much more that one can do to keep everybody happy :)
20:28:36 <wfaressuissia[m]> correct speed up isn't easy but possible, spend more time and will find good way to speed up it
20:29:21 <mj-xmr_> Alright I'll think about it when trying to fall asleep. G'night.