00:02:57 <philip_foss[m]> The source is building for the first time now and I'm sure I'll need to watch some educational videos for a while before I know what yall are talking about most of the time.
00:04:58 <philip_foss[m]> Well that built faster than most other projects I've worked on, very nice.
02:51:15 <MeowingCat> im implementing Base58 of Monero
02:52:24 <MeowingCat> i understand padding to 11 characters
02:53:07 <MeowingCat> what is happening to last 8 bytes???
02:59:35 <jeffro256[m]> @sech1 Do you know if the leak fixed in https://github.com/tevador/RandomX/pull/246 was actually happening in monero applications ?
05:27:52 <sech1> jeffro256[m] it's happening every time RandomX can't allocate memory using huge pages (which is all machines that didn't set up huge pages). But in case of Monero, it's a one time leak of the small size.
07:51:49 <MeowingCat> why are Monero integers big endian???
07:56:33 <sech1> Varint? They're not big endian, they're varint
07:58:18 <sech1> and they're kind of little endian
07:59:32 <sech1> if you found big endian somewhere in Monero's codebase, it's most likely network byte order (=big endian)
08:00:13 <MeowingCat> C#'s BigInteger is working with little endian on x86
08:00:35 <MeowingCat> when i parse private key from hex
08:00:35 <sech1> I don't see how it's connected to your previous question
08:01:05 <MeowingCat> and derive Monero keys
08:01:21 <MeowingCat> they are being wrong if i don't reverse the private key
08:04:00 <sech1> These are not numbers, they're ed25519 group elements
08:04:18 <MeowingCat> oh damn group elements
08:04:56 <sech1> of course the encoding could've been little endian, but the library Monero uses has big endian encoding for them
08:05:44 <MeowingCat> ge_p3_tobytes()?
08:14:21 <luigi1112> private keys are not group elements
08:14:26 <luigi1112> they are little endian integers
08:20:27 <sech1> how are they not group elements if they're used directly in all the Monero's cryptography?
08:24:49 <luigi1112> they are members of the group of integers 0-l
08:25:04 <luigi1112> but def not ed25519 group elements
09:04:09 <Guest1> hi
11:34:58 <jeffro256[m]> sech1 public keys are group elements because they're points (multiplied against the generator). Private keys are just the big random number that gets multiplied against the generator 
11:35:50 <jeffro256[m]> So you're right it wouldn't be encoded like a normal integer, but I don't think they're group elements 
11:36:32 <jeffro256[m]> But anyways, nice find on RandomX, cheers !
14:27:29 <spackle_xmr[m]> Can anyone point me to a code implementation of the compressed point decoding process from Zero to Monero section 2.4.2? I've written a version of it whose output always matches another decoding function, but I tweaked it in some weird ways and I'd like to check my work. Anything in python or c/c++ would be especially helpful.
14:30:43 <moneromooo> I think you want ge_frombytes_vartime
14:33:12 <wernervasquez[m]> https://github.com/FiloSottile/edwards25519/blob/17a0e597a690f30a548380f98a0424921c66e85d/scalar.go#L101 is what I use in my go implementation, if I understand you correctly
14:38:40 <luigi1111> jeffro256[m]: it is encoded like a normal integer, just backwards
14:38:51 <luigi1111> Bytewise
14:58:36 <UkoeHB> wernervasquez[m]: he’s looking for the opposite direction (decoding)
15:00:42 <spackle_xmr[m]> Thanks all, ge_frombytes_vartime looks like what I'm after. I'll poke around crypto-ops a bit and try to get familiar with things.
15:04:19 <wernervasquez[m]> UkoeHB spackle_xmr : I linked to the wrong thing entirely. Here is what I use for encode and decode of points https://github.com/FiloSottile/edwards25519/blob/17a0e597a690f30a548380f98a0424921c66e85d/edwards25519.go#L123
15:04:19 <wernervasquez[m]> https://github.com/FiloSottile/edwards25519/blob/17a0e597a690f30a548380f98a0424921c66e85d/edwards25519.go#L145
15:09:47 <spackle_xmr[m]> > <@wernervasquez:matrix.org> UkoeHB spackle_xmr : I linked to the wrong thing entirely. Here is what I use for encode and decode of points https://github.com/FiloSottile/edwards25519/blob/17a0e597a690f30a548380f98a0424921c66e85d/edwards25519.go#L123
15:09:47 <spackle_xmr[m]> > 
15:09:47 <spackle_xmr[m]> > https://github.com/FiloSottile/edwards25519/blob/17a0e597a690f30a548380f98a0424921c66e85d/edwards25519.go#L145
15:09:47 <spackle_xmr[m]> Thanks, I'll give that a look as well.
16:19:41 <spackle_xmr[m]> Hah, just saw that the code reference is marked in the page margin of ZtM. I'll remember to keep my eyes open in the future.
16:38:53 <ooo123ooo1234567> <sech1> "#7760 needs serious and thorough..." <- Did you try to run tests ?
16:40:04 <ooo123ooo1234567> <sech1> "see my comments there" <- "https://github.com/monero-project/monero/pull/7760#discussion_r88455935", subjective comment about naming
16:40:31 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884563318", this is structure for internal use, it isn't class; subjective comment about naming
16:41:00 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884563950" subjective comment about naming
16:42:08 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884568328" comment about performance drop due to location of static objects within functions; is it measurable drop ? old code doing the same, so it's at least not worse than before
16:42:28 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884573083" comment about unimportant performance drop, old code is doing the same
16:42:47 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884583691" did you try to read code ? it's thread safe
16:43:03 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884585709" subjective comment about not vs !
16:43:23 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884586499" subjective comment about not/and vs !/&&
16:43:45 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884588779" did you try to read code ? it's thread safe
16:44:01 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884590240" subjective comment about mixture of !/&& and not/and
16:44:11 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884590901" did you try to read code ? it's thread safe
16:44:26 <sech1> prove that it's only ever called from one thread at a time
16:45:31 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r884595212" in the worst case that std::random_device will fail to call rdseed/rdrand and will throw c++ exception, it's unimportant note about performance; old code is doing the same, any questions about this stupid addition to reviewers of this PR https://github.com/monero-project/monero/pull/5893
16:46:16 <sech1> Okay, I see you don't want to cooperate
16:46:28 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/7760#discussion_r885001542" all questions to reviewers of this https://github.com/monero-project/monero/pull/5893
16:46:34 <sech1> you missed this std::random_device issue even though you were rewriting the whole file
16:46:41 <sech1> so much for the "perfect" daemon
16:46:49 <sech1> I will not approve this PR until you fix it
16:47:08 <ooo123ooo1234567> sech1: Did you reply to all github comments or not yet ?
16:47:24 <ooo123ooo1234567> sry, Did I reply to all github comments or not yet ?
16:47:53 <sech1> don't reply, fix the code
16:47:59 <ooo123ooo1234567> sech1: confirm that I've replied to all comments and we can discuss deeper all issues, starting from the most important to less important
16:48:18 <sech1> I don't have time right now
16:48:52 <selsta> This random engine change was introduced as a security fix so there should be a separate discussion about removing it again.
16:48:57 <ooo123ooo1234567> sech1: yes, it's; every place you mentioned is called only from entry point with acquired state.lock
16:49:58 <sech1> I didn't do the full review yet. I literally spent less than an hour to just get familiar with the code
16:50:02 <ooo123ooo1234567> sech1: I want, but you're not right in everything; I didn't look into github yesterday, only opened it now
16:50:04 <sech1> so no, I didn't "try to read the code"
16:50:17 <ooo123ooo1234567> sech1: vtnerd did the same and failed in all cases
16:50:40 <ooo123ooo1234567> sech1: Do you want me to fix code style changes before you will look deeper or what ?
16:50:41 <sech1> if you call your PR "perfect" and at the same time leave unoptimal code that I found, you're lying
16:50:49 <sech1> fix it or I won't approve it
16:51:07 <sech1> I haven't started the full proper review yet
16:51:13 <sech1> because it will take many hours
16:51:14 <ooo123ooo1234567> sech1: Call at least 1 place where that code is worse than old one ?
16:51:22 <ooo123ooo1234567> Some places were not touched, since they are not important
16:51:28 <ooo123ooo1234567> but all important problems are solved there
16:52:01 <ooo123ooo1234567> sech1: It's easy to fix all code style changes, but will you look deeper or not ?
16:52:02 <sech1> github diff shows that everything was touched
16:52:23 <sech1> I said I don't have time right now
16:52:33 <sech1> I'll start this week
16:53:58 <ooo123ooo1234567> <sech1> "because this is unacceptable" <- It's unacceptable for reviewer to write shallow subjective comments about code style, without even reading code, running tests
16:54:55 <sech1> Instead of starting personal attacks, fix the code
16:55:17 <sech1> Code style is important
16:55:24 <sech1> I don't want to see the zoo in the code
16:55:41 <ooo123ooo1234567> sech1: any link to code style that you respect ?
16:55:46 <ooo123ooo1234567> I don't want to change code style at preference of every reviewer
16:55:59 <sech1> Change to what is similar to the existing Monero code
16:56:03 <sech1> Not what I respect or prefer!
16:56:26 <ooo123ooo1234567> especially incompetent that only write comments about code style
16:56:34 <sech1> As I said, if you're too stubborn to cooperate, I will not aprove it
16:56:55 <ooo123ooo1234567> sech1: Can you paste link to reference code style ?
16:56:58 <sech1> So you're calling me incompetent now?
16:57:00 <ooo123ooo1234567> https://google.github.io/styleguide/cppguide.html, this ok ?
16:57:08 <sech1> Then who missed this std::random_device glaring issue?
16:57:16 <ooo123ooo1234567> sech1: No, that's about previous reviews
16:57:19 <sech1> Which I found after quick look
16:57:20 <ooo123ooo1234567> not from you
16:57:42 <ooo123ooo1234567> sech1: I didn't miss, it. I even wrapped that random_device into separate random_delay function in order to remove it completely
16:58:16 <ooo123ooo1234567> "https://github.com/monero-project/monero/pull/8365" this PR is placebo, not needed
16:58:41 <ooo123ooo1234567> sech1: That's the problem: every reviewer pick something not important, but don't read code
16:58:56 <ooo123ooo1234567> Entry point is tests, there are at least 3 deep problems
16:59:06 <sech1> for the 100th time: I didn't start the review yet!
16:59:56 <sech1> I just looked at the code to see if it's worth to spend more time. Found one serious issue and two performance issue which you dismissed, yet called the code "perfect"
16:59:57 <ooo123ooo1234567> <sech1> "because this is unacceptable" <- you've written conclusion without reading code, how does it work ?
16:59:59 <ooo123ooo1234567> is it acceptable ?
17:00:19 <sech1> I read the code of random_delay function
17:00:23 <sech1> and called it unacceptable
17:00:24 <ooo123ooo1234567> sech1: "one serious issue" which one ?
17:00:40 <sech1> random_delay
17:00:50 <sech1> you saw it and didn't fix it
17:01:00 <sech1> while rewriting the whole code
17:01:05 <sech1> so fix it
17:01:16 <sech1> or we don't have anything to talk about
17:01:37 <sech1> I actually stopped looking at the code when I found it
17:01:47 <ooo123ooo1234567> sech1: I've leaved it as is, it's not worse than in old code; And this code fixes real correctness issues, unlike unimportant performance issues, you're talking here
17:01:50 <sech1> because I'm not sure in overall quality of your PR now
17:01:54 <ooo123ooo1234567> sech1: too early then
17:02:23 <ooo123ooo1234567> sech1: I'll change random_delay and performance issues, without code style changes, ok?
17:02:27 <ooo123ooo1234567> is it enough ?
17:03:22 <ooo123ooo1234567> I'm sure you will spend much more time on code reading, than this shallow comments
17:03:24 <sech1> enough for me to pull the code, compile it and run tests. And then run it under debugger to see how it works live
17:03:32 <ooo123ooo1234567> That's why it isn't important to do any polishing
17:03:56 <sech1> polishing is important
17:04:04 <sech1> or the next guy who looks at it will be confused
17:04:12 <sech1> and code style is important too
17:04:22 <sech1> have you ever worked in a big team?
17:04:36 <ooo123ooo1234567> sech1: That PR was written almost 1 year ago and nobody reviewed it, And now when jeffro256 added placebo PRs which introduced merge conflicts, someone is reviewing  it
17:05:14 <sech1> I'm reviewing it voluntarily
17:05:25 <OCREAT> ooo123ooo1234567: we're not talking about anything subjective. Have you ever learnt how to code and how to contribute to a project? 
17:05:28 <sech1> And I can just walk away and let it rot if you keep begin so stubborn
17:05:35 <sech1> *being
17:05:43 <ooo123ooo1234567> sech1: link to code style so that it isn't preference of every reviewer
17:06:05 <sech1> I can link you to my comment abount naming
17:06:28 <sech1> which is not my preference, rather what is used in other parts of Monero code
17:06:38 <ooo123ooo1234567> sech1: That's also a problem, there are many paid incompetent developers, but it's you who is reviewing it
17:06:59 <OCREAT> who ever writes && => and, || => or and then mix these two styles?!?! unbelievable. Sech1 has already suggested you how to fix your code. 
17:07:37 <ooo123ooo1234567> sech1: Monero code is written differently in different places, there is no code style; this code style is ok for you https://google.github.io/styleguide/cppguide.html ?
17:09:03 <sech1> So you're adding one more place where it's written in N+1-th code style. Awesome (not)
17:09:23 <sech1> find the most common code style that's already being used in most important files, and use it!
17:09:35 <sech1> there's no step-by-step guide I can link you to
17:10:02 <ooo123ooo1234567> sech1: I'm about non subjective doc rather than step-by-step guide
17:10:31 <OCREAT> ooo123ooo1234567: I'm trying to figure out your patch. Is it all by yourself? 
17:10:45 <ooo123ooo1234567> OCREAT: yes
17:10:59 <sech1> Google C++ Style Guide is not ok
17:11:06 <sech1> doesn't match what Monero code uses
17:11:47 <OCREAT> ooo123ooo1234567: okay, because it does not seem so. You can't even figure out what a writing style is, pretty useless to argument against Monero code style. 
17:11:49 <ooo123ooo1234567> <sech1> "And I can just walk away and let..." <- complaining about code style without running tests, is it being stubborn or not ?
17:12:04 <Siren[m]> sech1: I suggest documenting the monero code style
17:12:30 <ooo123ooo1234567> OCREAT: scammer, is it you ?
17:12:53 <moneromooo> There is no single monero code style. Please try to follow the style of whatever you're modifying. For new code, try something similar/sensible.
17:13:15 <OCREAT> pretty boring argument, c'mon you can do better ooo123ooo, but it's not the right place to talk over
17:13:53 <ooo123ooo1234567> Siren[m]: It's useless goal, it's better to pick new one and follow it during all new PRs
17:14:11 <sech1> no you don't
17:14:15 <sech1> use existing code style
17:14:20 <sech1> mooo gave a good suggestion
17:14:20 <Siren[m]> ooo123ooo1234567: If you're confused about it, perhaps there's use for it
17:14:34 <UkoeHB> I hope we can all strive to improve on the existing code style(s)/non-style...
17:14:57 <selsta> according to https://github.com/monero-project/monero/blob/master/docs/CONTRIBUTING.md there should be a documented code style, but not sure if this was overlooked
17:15:03 <ooo123ooo1234567> Siren[m]: Find at least 1 existing code style which is defined in all cases, link
17:15:12 <rbrunner> Well, that non-style has served pretty well for many years already
17:15:34 <ooo123ooo1234567> Siren[m]: You're arguing about the most shallow / unimportant thing, instead of reading code; facepalm
17:16:28 <rbrunner> What we discuss here right now is definitely not "unimportant" IMO
17:16:43 <rbrunner> And not facepalm-worthy
17:16:49 <plowsof[m]> he said he hasn't started reviewing it yet. would you rather hear the first impressions now or in a week? 
17:17:27 <moneromooo> I'm not looking forward to petty formatting bullshit. As long as people are sensible and fairly consistent, it should be enough. Strict submission to rigid rules is in noone's interest except those who get off on punctilliousness.
17:17:33 <Siren[m]> ooo123ooo1234567: You sound like you don't care about your code quality at all and you're trying to get your code merged just so it is merged
17:17:56 <UkoeHB> Siren[m]: ding ding we have a winner
17:18:09 <rbrunner> Winner in what regard?
17:18:23 <UkoeHB> Accuracy award?
17:18:30 <OCREAT> Siren[m]: wondering if he's included any 0day on their code
17:18:32 <rbrunner> :)
17:18:44 <ooo123ooo1234567> Siren[m]: The hardest part is write correct code and check it's correctness. Code style is easy to change, can be done even before merging.
17:18:52 <OCREAT> its*
17:19:04 <OCREAT> c'mon, you don't even speak english, whoever is this?
17:19:05 <ofrnxmr[m]> Siren[m]: I think ooo is willing to change the code style but doesnt want to waste time of style if there are other issues
17:19:08 <ooo123ooo1234567> It looks like I'm talking with linguists rather than programmers here
17:19:19 <ooo123ooo1234567> OCREAT: linguist ?
17:19:45 <UkoeHB> Seems like style adds a lot of delay (eg the serialization PR)
17:19:48 <ooo123ooo1234567> I'm intentionally write code in that style in to emphasize how incompetent people
17:19:54 <ooo123ooo1234567> vtnerd failed in all cases
17:19:57 <OCREAT> It LoOkS lIkE i'm TaLkInG wItH lInGuIsTs RaThEr ThAn PrOgRaMmErS hErE
17:20:03 <sech1> I can cope with different code style, for now, but you need to fix other issues (random_delay and host_count functions)
17:20:13 <ooo123ooo1234567> But I can change code style easily, others can change code style many times, but still write incorrect code
17:20:30 <sech1> you clearly didn't work in a team
17:20:37 <ofrnxmr[m]> OCREAT: Can you stop?? stay on topic
17:20:50 <sech1> correct code can be correct all the way you want, but if no one understands it or can read it, it's unmaintainable
17:20:56 <sech1> and it will be scrapped
17:21:01 <ooo123ooo1234567> OCREAT: mj-xmr, use your real account
17:21:07 <Siren[m]> ooo123ooo1234567: I'm not about the style alone (although imo not adopting a style standard makes the code harder to read),  reading this whole convo gives me that idea
17:21:14 <ooo123ooo1234567> sech1: I'm sure it isn't much different from your p2pool code
17:21:23 <sech1> not much
17:21:40 <mj-xmr[m]> > <@ooo123ooo1234567[m]:libera.chat> > <@OCREAT:libera.chat> It LoOkS lIkE i'm TaLkInG wItH lInGuIsTs RaThEr ThAn PrOgRaMmErS hErE
17:21:40 <mj-xmr[m]> > 
17:21:40 <mj-xmr[m]> > mj-xmr, use your real account
17:21:40 <mj-xmr[m]> Hello. Thanks for dragging me to another beef. 
17:21:50 <mj-xmr[m]> But I'm already fed up with your shit.
17:21:53 <sech1> but renaming std::string to string_t, why?
17:21:59 <sech1> just for the sake of renaming?
17:22:07 <sech1> like no other programmer knows what is std::string?
17:22:16 <rbrunner> That's a hell of an idea, yeah
17:22:17 <mj-xmr[m]> Please don't ping me ooo123ooo1234567[m] 
17:22:23 <mj-xmr[m]> I don't talk with idiots/
17:22:37 <OCREAT> mj-xmr[m]: you can /ignore people
17:23:12 <mj-xmr[m]> Oh how many times I already did this...
17:23:23 <mj-xmr[m]> This parasite goes around every blocks and bans
17:23:48 <mj-xmr[m]> He makes this whole space a dirty toilet so full of him.
17:23:50 <ooo123ooo1234567> sech1: I'm sure that anyone who spent time on verification of that code (not as linguist) wouldn't even complain about code style. It was easier to write with renames, just it.
17:24:09 <UkoeHB> mj-xmr[m]: pls just block and move on, we gotta stay at least kind of on topic
17:24:14 <ooo123ooo1234567> sech1: No, I don't care about code style. It's easy. Give me guide, i'll change whole code according to it.
17:24:34 <mj-xmr[m]> UkoeHB: Does it mean he won't ping me again? No.
17:24:43 <mj-xmr[m]> But here we go.
17:25:09 <ooo123ooo1234567> sech1: In current environment  I would say nobody understands even code written with some code style, check any code from vtnerd.
17:25:14 <sech1> I can't give you the guide. Use common sense if you have it. mooo told you already "Please try to follow the style of whatever you're modifying."
17:25:22 <OCREAT> https://github.com/monero-project/monero/pull/7999/files#diff-af8e6ea1b236e77edb1a1498dc9a47769a1bec777ce99b98b7ad98d11e4c4c5bR72 oh yeah, wtf is this?
17:25:24 <ofrnxmr[m]> ooo123ooo1234567: Traslation: no problem sech, I will.
17:25:47 <ooo123ooo1234567> <sech1> "I can cope with different code..." <- ok, will do these changes + merge conflicts
17:26:10 <mj-xmr[m]> > <@ofrnxmr[m]:libera.chat> > <@ooo123ooo1234567:matrix.org> No, I don't care about code style. It's easy. Give me guide, i'll change whole code according to it.
17:26:10 <mj-xmr[m]> > 
17:26:11 <mj-xmr[m]> > Traslation: no problem sech, I will.
17:26:11 <mj-xmr[m]> This is another sock puppet, just to let you know.
17:26:13 <mj-xmr[m]> also w is.
17:26:24 <OCREAT> perfect-daemon looks like "bad-coded daemon" :/ \: lol
17:26:27 <mj-xmr[m]> but I think you figured it out by now.
17:26:28 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> > <@ofrnxmr[m]:libera.chat> > <@ooo123ooo1234567:matrix.org> No, I don't care about code style. It's easy. Give me guide, i'll change whole code according to it.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ed66c14041d9be400b981e58bd99da3bb403a2fa)
17:26:32 <mj-xmr[m]> I meant `w`
17:26:42 <mj-xmr[m]> OCREAT: Oh yes.
17:26:43 <mj-xmr[m]> And very unprofessionally.
17:26:51 <mj-xmr[m]> not only "bad"
17:27:00 <OCREAT> "unprofessional daemon"
17:27:27 <mj-xmr[m]> I'm happy you said it, not me :)
17:27:29 <selsta> there was on topic patch discussion and people derailed it from the side.. nice
17:27:38 <mj-xmr[m]> Anyway, sorry for breaking your fun. Bye
17:27:41 <OCREAT> big shoutout to whoever will handle this situation 
17:27:56 <mj-xmr[m]> Don't ping me with bullshit.
17:28:05 <selsta> how about everyone who isn't involved in reviewing this patch keeps out of this discussion?
17:28:10 <mj-xmr[m]> OCREAT: sech1: will and I will help.
17:28:17 <ofrnxmr[m]> OCREAT: Seems handled to me.
17:28:19 <OCREAT> selsta: okay, sorry, we can move on
17:28:26 <mj-xmr[m]> selsta: I'm actually involved.
17:28:42 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> > <@selsta:libera.chat> how about everyone who isn't involved in reviewing this patch keeps out of this discussion?
17:28:42 <ooo123ooo1234567> > 
17:28:42 <ooo123ooo1234567> > I'm actually involved.
17:28:42 <ooo123ooo1234567> You can't even debug bash script; facepalm
17:28:43 <mj-xmr[m]> And I can tell you that this PR doesn't meet:
17:28:43 <mj-xmr[m]> - industry standards
17:28:44 <mj-xmr[m]> - Monero standards
17:28:50 <selsta> ...
17:29:04 <mj-xmr[m]> mj-xmr[m]: See here. 
17:29:26 <mj-xmr[m]> OK. Cya all.
17:31:26 <ooo123ooo1234567> <OCREAT> "Siren: wondering if he's..." <- That's task of reviewer to check.
17:31:40 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> And I can tell you that this PR doesn't meet:
17:31:40 <ooo123ooo1234567> > - industry standards
17:31:40 <ooo123ooo1234567> > - Monero standards
17:31:40 <ooo123ooo1234567> facepalm
17:33:12 <ooo123ooo1234567> <Siren[m]> "I'm not about the style alone (..." <- incompetent people that don't write complex code are caring about code style; code can be complex even with adoption of any "code style"; it's about dependencies, not about names.
17:33:39 <ooo123ooo1234567> And number of dependencies can be reduced even without "code style" changes.
17:36:35 <ooo123ooo1234567> <OCREAT> "perfect-daemon looks like "bad-..." <- Call at least 1 problem related to correctness introduced by that patch.
17:36:41 <rbrunner> Complex code needs caring about code style more than any other, but that's probably just me ...
17:37:05 <sech1> this ^
17:37:16 <OCREAT> What really matters for Monero is: 1) robustness of code 2) a minimum of readability 3) proof of working with unit tests
17:37:22 <rbrunner> And naming of course, naming
17:37:56 <sech1> "write your code like the next person maintaining it will be a psycho who knows where you live" (c)
17:38:05 <moneromooo> FWIW, I like ooo123's use of tests to show the fix. That's nice.
17:38:13 <sech1> that I agree with
17:39:23 <ooo123ooo1234567> <UkoeHB> "Siren: ding ding we have a..." <- facepalm
17:40:07 <w[m]> > <@mj-xmr[m]:libera.chat> > <@ofrnxmr[m]:libera.chat> > <@ooo123ooo1234567:matrix.org> No, I don't care about code style. It's easy. Give me guide, i'll change whole code according to it.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8fb92e7aabb7ffc4826c047f0381a76db0662265)
17:40:26 <mj-xmr[m]> moneromooo: They can be reused by a more professional developer. That's even nicer.
17:40:57 <mj-xmr[m]> > <@w[m]:libera.chat> > <@mj-xmr[m]:libera.chat> > <@ofrnxmr[m]:libera.chat> > <@ooo123ooo1234567:matrix.org> No, I don't care about code style. It's easy. Give me guide, i'll change whole code according to it.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5f7abe31c74e1e579e16cac7a26dcfbf2dba44df)
17:41:51 <mj-xmr[m]> I secured the unit tests on my local hard drive, in case imperfect-demon wants to threaten you with removal of them.
17:42:47 <ooo123ooo1234567> mj-xmr[m]: facepalm
17:43:26 <mj-xmr[m]> <rbrunner> "And naming of course, naming" <- Yes, and LoLcAt CaSe.
17:45:25 <rbrunner> Not sure what you, but anyway, I meant that seriously
17:45:29 <rbrunner> *you mean
17:45:38 <mj-xmr[m]> I thought you were joking.
17:46:05 <mj-xmr[m]> Sounded like it.
17:46:15 <ooo123ooo1234567> <Siren[m]> "I'm not about the style alone (..." <- Why are you supporting that scammer ?
17:46:29 <mj-xmr[m]> Obviously variables like `a` or `b` would not cut it.
17:47:27 <mj-xmr[m]> So my take on this is, that a professional programmer, be it sech1 or somebody of comparable experience, takes the conclusions learned from that PR, and breaks them into smaller pieces. Only small PRs are able to be reviewed and merged for many reasons, that I shouldn't have to tell you. I wrote it all in sech1 PR.
17:48:22 <mj-xmr[m]> Even if my funds are blocked, I will help in reviewing such managable PRs.
17:48:26 <ooo123ooo1234567> mj-xmr[m]: you don't know what you are talking about; facepalm
17:48:42 <ooo123ooo1234567> mj-xmr[m]: Aha, your funds are blocked; that's why you're talking so much
17:48:50 <rbrunner> " Only small PRs are able to be reviewed and merged" Don't agree for once, and that would be a grave problem for our code base if really true
17:48:52 <ooo123ooo1234567> I've not read yet msgs from monero-community
17:49:06 <mj-xmr[m]> It's not tolerable, that the original PR is left unmaintained for a year, exposing the vulnerabilities to bad actors for a year.
17:49:30 <rbrunner> With this problem, was it real, we could flat-out forget completely about introducing Seraphis
17:49:58 <mj-xmr[m]> rbrunner: That's how it works in practice. I've had many PRs open here and only small ones were even taken into account. Sorry, but that's how it is.
17:50:15 <mj-xmr[m]> rbrunner: For Seraphis, I think that nobody will argue, that we have to make an exception.
17:50:29 <ooo123ooo1234567> mj-xmr[m]: incompetent developer write bullshit, which is merged into repo, but this scammer blaims correct unreviewed code in problems; facepalm
17:50:58 <rbrunner> That happening to you escaped my attention. Somehow, at first impression, it sound improbable.
17:51:42 <mj-xmr[m]> mj-xmr[m]: So instead of riding the dead horse, please focus on progress and PLEASE invest time into stable and professional people. 
17:51:54 <mj-xmr[m]> Otherwise you're left hanging when that unstable one has a bad mood.
17:52:02 <mj-xmr[m]> And don't tell me it's "unrelated"
17:53:10 <mj-xmr[m]> rbrunner: I actually **keeps happening** to me, not just happened. But no problem. There are more important things and I also have to adapt to reality, not the other way around.
17:54:05 <moneromooo> Large PRs are possible if you have competent reviewers for this. Small PRs just increase the likelihood a PR will get reviewed properly.
17:54:51 <mj-xmr[m]> Yes. But even competent reviewers will get tired and demotivated after some point. Especially after having to deal with sock puppets. 
17:55:12 <moneromooo> That's the point :)
17:55:13 <mj-xmr[m]> And I'm not calling myself a competent reviewer. 
17:55:17 <rbrunner> Yes, that's why it's usually a good strategy to be somewhat careful if a good potential or actual reviewer comes around ...
17:55:25 <mj-xmr[m]> I'm only trying to save the project.
17:56:01 <moneromooo> We don't have them now. Except vtnerd and sech1 from time to time I think. But mostly we don't. Though I don't keep up with the PR list anymore so apologies if I'm missing someone ^_^
17:56:05 <mj-xmr[m]> rbrunner: A reviewer is GOLD.
17:56:31 <ooo123ooo1234567> mj-xmr[m]: hahahahahaha; scammer is saving the project
17:56:46 <mj-xmr[m]> moneromooo: everybody knows how long the PR list is.
17:56:48 <ooo123ooo1234567> mj-xmr[m]: the only thing that you cares about is your money, and nothing else.
17:56:53 <ooo123ooo1234567> s/cares/care/
17:58:21 <rbrunner> It seems jberman could have a good career ahead of him, also as a reviewer.
17:58:47 <mj-xmr[m]> Yes.
17:59:05 <moneromooo> Ah yes, I remember good comments on my recent patches.
18:02:02 <mj-xmr[m]> rbrunner: https://www.reddit.com/r/Monero/comments/umgew1/mjs_dev_report_aprmay_2022_23/i8332oy/?utm_source=reddit&utm_medium=web2x&context=3
18:03:14 <mj-xmr[m]> Here's an example where people ask me how many money they have to throw at me to fix Monero's issues, and instead I recommend them to fund the other devs, jberman[m] included. imperfect-demon excluded.
18:06:46 <ooo123ooo1234567> <moneromooo> "FWIW, I like ooo123's use of..." <- People learn only from challenges and these tests is good entry point for anyone to learn problem and check whether it was fixed. Any fiction literature in comments only help to simulate understanding via parroting of words from text in the worst case.
18:08:08 <mj-xmr[m]> Now were you able to calculate perhaps how much time exactly did you spend cumulatively on trying to merge 7760, instead of trying something better, like I proposed in 8365?
18:08:08 <mj-xmr[m]> https://github.com/monero-project/monero/pull/8365#pullrequestreview-989824458
18:09:04 <ooo123ooo1234567> <OCREAT> "https://github.com/monero-..." <- link to source with compile time strings for c++11 templates
18:12:01 <mj-xmr[m]> You also can't tell me that the reason it can't be merged is that "we can't find reviewers". We have a few of them but they can't be demotivated with:
18:12:01 <mj-xmr[m]> - too large PRs when they can be smaller (unlike Seraphis)
18:12:01 <mj-xmr[m]> - stubborn contributors (if, as a contributor you don't need a reviewer, then it means you need to start your own project)
18:12:01 <mj-xmr[m]> - sock puppets during every freaking meeting
18:13:18 <mj-xmr[m]> The train won't drive if you don't build tracks first.
18:14:14 <w[m]> > <@mj-xmr[m]:libera.chat> You also can't tell me that the reason it can't be merged is that "we can't find reviewers". We have a few of them but they can't be demotivated with:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/1e9c4994d1e8a15dcc68a3d7462ec1add6131feb)
18:14:48 <mj-xmr[m]> > <@w[m]:libera.chat> > <@mj-xmr[m]:libera.chat> You also can't tell me that the reason it can't be merged is that "we can't find reviewers". We have a few of them but they can't be demotivated with:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bc07036d552d3d72f2512c31da9ff18f227a61c0)
18:15:00 <mj-xmr[m]> What are your contributions?
18:15:17 <ooo123ooo1234567> > <@w:monero.social> mj thinks i am or that i know ooo
18:15:17 <ooo123ooo1234567> > 
18:15:17 <ooo123ooo1234567> > lol. why so tin foiled
18:15:17 <ooo123ooo1234567> that man is either scammer or pathological lier or certainly has bad opsecs so that deanonimized himself
18:15:38 <w[m]> > <@mj-xmr[m]:libera.chat> > <@w[m]:libera.chat> > <@mj-xmr[m]:libera.chat> You also can't tell me that the reason it can't be merged is that "we can't find reviewers". We have a few of them but they can't be demotivated with:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a80ce5f6e4f0a8e56ebda6bc8f5aad6a0b4b1d9e)
18:15:41 <w[m]> stay on topic
18:15:42 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> > <@w[m]:libera.chat> > <@mj-xmr[m]:libera.chat> You also can't tell me that the reason it can't be merged is that "we can't find reviewers". We have a few of them but they can't be demotivated with:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f812f218085c58f48975fbff5b9939f539d231b4)
18:16:19 <mj-xmr[m]> Was I referring to you in that message that you quoted ? Why so tin foiled?
18:16:31 <mj-xmr[m]> What's your GH account w[m]  and what are your contributions?
18:16:58 <w[m]> -dev
18:17:05 <w[m]> wrong chat
18:17:06 <mj-xmr[m]> dev what?
18:17:19 <mj-xmr[m]> Does anybody know w[m] ?
18:17:31 <mj-xmr[m]> Or is it safe for me to ignore him?
18:17:38 <w[m]> yes people know me
18:17:51 <mj-xmr[m]> I'm not asking you
18:18:05 * moneromooo wonders why it might be unsafe to /ignore someone
18:18:33 <mj-xmr[m]> Because he might know something useful.
18:18:35 <nioc> nobody is or has been ignored by me
18:18:43 <mj-xmr[m]> But I start to doubt it.
18:19:20 <w[m]> im going to stop now. guy who makes internet threats wants to know who i am
18:19:21 <w[m]> and again
18:19:21 <w[m]> this is -dev
18:19:21 <w[m]> ive got nothing to add so ill shutup now. but calling people sock puppeta and threatening to shoot people.. grow up
18:19:25 <mj-xmr[m]> nioc: Try to open a CCS Proposal and discover a whole New Realm of jealous sock puppets.
18:19:55 <mj-xmr[m]> > <@w[m]:libera.chat> im going to stop now. guy who makes internet threats wants to know who i am... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/66ac8ceaea9842d1ad542d015176ba727e40df90)
18:20:09 <mj-xmr[m]> And don't ping me.
18:20:44 <moneromooo> I'm wondering, is ooo still chatting here, or did you guys manage to continue the mudslinging without him ? :D
18:20:57 <mj-xmr[m]> The water is fine :)
18:21:27 <mj-xmr[m]> And I can't tell you if ooo is still chatting :)
18:21:41 <w[m]> ooo has yet to read mj's talk about shooting him in -community
18:21:59 <mj-xmr[m]> w[m]: What? What a paranoid fuck...
18:22:13 <mj-xmr[m]> Maybe I can buy him some medicine?
18:22:21 <mj-xmr[m]> Besides shut up. This is -dev
18:22:42 <w[m]> moneromooo: hahaha ooo is off to work on perfecting his code.. probably
18:23:06 <mj-xmr[m]> You can't make a Mercedes from a pile of shit. 
18:39:19 <sech1> ooo123ooo1234567 I've just read through https://github.com/monero-project/monero/pull/5893 and that whole std::random_device code appeared because "Coverity said so". I don't see why we need something better than rand() in a freaking delay function which is "Sleeping because QUEUE is FULL"
18:39:40 <sech1> it can probably be removed completely
18:39:47 <sech1> why random delay there at all
18:41:27 <sech1> I would prefer it to be removed entirely and have the delay of fixed value (250 ms)
18:41:33 <sech1> unless there are strong objections
18:42:18 <sech1> hyc you commented in that old PR, do you have any more context?
18:45:21 <mj-xmr[m]> Let's move on. 8365 has been approved by 3 reviewers, including me. 
18:45:46 <mj-xmr[m]> (independently of the above discussion)
18:45:52 <sech1> I doube 8365 is needed at all
18:46:00 <sech1> there's no need for randomness in that place
18:46:08 <mj-xmr[m]> aha
18:46:09 <sech1> unless I don't understand something about that code
18:46:26 <sech1> it's literally just a delay loop
18:46:32 <mj-xmr[m]> Try to remove it and run the core tests for a first impression?
18:46:34 <sech1> that waits until the send queue clears
18:46:42 <mj-xmr[m]> and then other tests?
18:46:58 <sech1> good idea
18:47:10 <mj-xmr[m]> With such code base, there may be many side effects that expect this behavior.
18:47:46 <mj-xmr[m]> It wasn't English, but YKWIM
18:48:59 <sech1> Delay will be random anyway, even if you supply fixed "250" value every time
18:49:14 <sech1> Because Windows, Linux, MacOS and many others are not real-time OS
18:50:02 <mj-xmr[m]> Yes, but maybe there's a statistical expectation, that say, for 1000 tries there's a result below 10.
18:50:11 <mj-xmr[m]> one result or 10.
18:50:17 <jeffro256[m]> Also 250 is wayyyyyy too high for polling if the queue is empty. 
18:50:51 <mj-xmr[m]> Ah, you're talking about 250ms.
18:50:58 <jeffro256[m]> We can still wait a variable length of time to prevent side channel attacks but it wastes an entire quarter of a second just to POLL if the queue is at the right level
18:51:09 <mj-xmr[m]> Well, it won't be SHORTER than 250, no?
18:51:31 <jeffro256[m]> no AFAIK
18:51:51 <mj-xmr[m]> OK, the way I approach such problems is I try to find which unit tests already cover this piece of code.
18:52:06 <mj-xmr[m]> I have a script for that for you guys, that's waiting to me reviewed and merged since 1.5 year.
18:52:08 <jeffro256[m]> We can wait a whole quarter of a second, but that should only be after we know we can send 
18:52:12 <mj-xmr[m]> rbrunner: ;)
18:52:17 <sech1> jeffro256[m] 7760 fixes this poll delay by doing async calls
18:52:45 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7806
18:53:06 <mj-xmr[m]> ^ It will be useful for anybody who wants to work methodically on the project.
18:53:15 <mj-xmr[m]> You can use it as it is, no need to merge it.
18:53:39 <jeffro256[m]> @sech1 I'll need to look at that specific part of the code, but unless he changed how the chunks are buffered/polled, just making it async won't help unfortunatelhy 
18:53:59 <sech1> making it async frees the current thread so it can do other things
18:54:08 <sech1> this is how networking code can work efficiently
18:55:14 <jeffro256[m]> Right, but it can still starve an indefinite amount of time if it comes back and its still not ready, comes back and still not ready, comes back and still not ready... Even if it's not hogging CPU time 
18:56:34 <mj-xmr[m]> It wouldn't take up CPU time, but I can confirm, that my valgrind tests many times, especially lately, run into a dead loop without any CPU usage. This COULD be this part but could be also another.
18:57:23 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/img/valgrind.png
18:57:42 <mj-xmr[m]> Every such jump in total run time was actually manually killed by me.
18:58:15 <mj-xmr[m]> So I confirm, that the problem exists at least.
18:58:23 <mj-xmr[m]> not necessarily here though.
18:59:08 <ooo123ooo1234567> mj-xmr[m]: why are you pasting your useless charts everywhere ? is it how competent people are doing at work ?
18:59:09 <sech1> I'm running "make release-test" without this random delay, we'll seen in a couple of hours
19:00:20 <sech1> ooo123ooo1234567 why useless charts? It shows that there is a problem somewhere when running with valgrind.
19:00:39 <jeffro256[m]> @sech1 The send buffer needs some sort of fairness mechanic 
19:00:39 <sech1> so it is useful, it gives information
19:00:42 <ooo123ooo1234567> <sech1> "it can probably be removed..." <- "I didn't miss, it. I even wrapped that random_device into separate random_delay function in order to remove it completely" yes
19:00:43 <mj-xmr[m]> useless for the brainless.
19:01:33 <mj-xmr[m]> Here's the relevant script, just for reference: https://github.com/monero-project/monero/blob/master/utils/health/valgrind-tests.sh
19:02:35 <ooo123ooo1234567> sech1: Call at least 1 problem which was fixed with the help of them.
19:03:20 <sech1> the problem with valgrind
19:03:24 <ooo123ooo1234567> sech1: or noise
19:03:25 <sech1> which will be fixed
19:05:16 <ooo123ooo1234567> <jeffro256[m]> "Right, but it can still starve..." <- Did you try to read code ? What's the purpose to talk about code without reading it ?
19:07:12 <jeffro256[m]> > > <@sech1:libera.chat> so it is useful, it gives information... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/53eb60ba1eace3e17632726d4778a5689e524078)
19:07:39 <jeffro256[m]> > > <@jeffro256:monero.social> Right, but it can still starve an indefinite amount of time if it comes back and its still not ready, comes back and still not ready, comes back and still not ready... Even if it's not hogging CPU time
19:07:39 <jeffro256[m]> > 
19:07:39 <jeffro256[m]> > Did you try to read code ? What's the purpose to talk about code without reading it ?
19:07:39 <jeffro256[m]> I specifically said I didn't read that part and that I was going to
19:08:36 <mj-xmr[m]> It sounds to me like you're wasting time on somebody.
19:08:39 <ooo123ooo1234567> > <@jeffro256:monero.social> > > <@sech1:libera.chat> so it is useful, it gives information... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bf250e1258cc8b76abb3c8aeb0c2c4eac4b605b6)
19:11:19 <mj-xmr[m]> ooo123: are you trying to hinder the progress of Monero as a whole? 
19:11:30 <mj-xmr[m]> Do you have a conflict of interest?
19:11:49 <mj-xmr[m]> Because it starts to appear so to me.
19:12:17 <mj-xmr[m]> It was a rhetorical question. I won't see your replies. Just that you know.
19:13:53 <ooo123ooo1234567> <sech1> "ooo123ooo1234567 I've just..." <- The right question: why previous reviewer allowed it ? And it isn't the only example of merged code without proper review
19:16:13 <mj-xmr[m]> <sech1> "the problem with valgrind" <- yes. If you fix a potential dead loop problem and multiple runs of this valgrind script runs without a hickup, you've pretty much quickly approximated the tedious work of finding the culprit. Leveraging the fact that the script can be automated (because it was written so)
19:17:05 <mj-xmr[m]> Again not pretty English, but YKWIM.
19:18:16 <jeffro256[m]> > > <@sech1:libera.chat> ooo123ooo1234567 I've just read through https://github.com/monero-project/monero/pull/5893 and that whole std::random_device code appeared because "Coverity said so". I don't see why we need something better than rand() in a freaking delay function which is "Sleeping because QUEUE is FULL"
19:18:16 <jeffro256[m]> > 
19:18:16 <jeffro256[m]> > The right question: why previous reviewer allowed it ? And it isn't the only example of merged code without proper review
19:18:16 <jeffro256[m]> I agree. This was probably merged with too little review and now we deal with it later. What's your GH handle?
19:18:46 <ooo123ooo1234567> > <@jeffro256:monero.social> > > <@sech1:libera.chat> ooo123ooo1234567 I've just read through https://github.com/monero-project/monero/pull/5893 and that whole std::random_device code appeared because "Coverity said so". I don't see why we need something better than rand() in a freaking delay function which... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8c33e1c3c9af6899a2df1573fdf15177cb8a33ec)
19:19:12 <ooo123ooo1234567>  * There are such example within last 2 months, it isn't fixed problem
19:20:32 <jeffro256[m]> What's your GH handle then? Throw a negative review at the problematic ones!
19:20:45 <ooo123ooo1234567> > <@jeffro256:monero.social> > > <@sech1:libera.chat> ooo123ooo1234567 I've just read through https://github.com/monero-project/monero/pull/5893 and that whole std::random_device code appeared because "Coverity said so". I don't see why we need something better than rand() in a freaking delay function which... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cbf80e461e84d285e3a3ff729e568ddf9cf4359e)
19:21:14 <mj-xmr[m]> jeffro256[m]: it's "SoCkPuPpEt"
19:21:24 <ooo123ooo1234567> jeffro256[m]: it doesn't matter; focus on problems/solutions
19:21:35 <mj-xmr[m]> APOLOGIES.
19:22:34 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> > <@sech1:libera.chat> the problem with valgrind
19:22:34 <ooo123ooo1234567> > 
19:22:34 <ooo123ooo1234567> > yes. If you fix a potential dead loop problem and multiple runs of this valgrind script runs without a hickup, you've pretty much quickly approximated the tedious work of finding the culprit. Leveraging the fact that the script can be automated (because it was written so)
19:22:34 <ooo123ooo1234567> if anyone would read code before approving PR or writing PR then there would be no such problems
19:22:59 <sech1> not true
19:23:17 <sech1> bugs exist even in the best reviewed software
19:23:31 <mj-xmr[m]> I agree.
19:23:59 <sech1> it's just inevitable once code complexity exceeds certain limit
19:24:46 <sech1> but bugs per 10k lines of code or other metrics certainly get better if reviews get done properly
19:24:55 <mj-xmr[m]> Reviews aren't a 100% safeguard of any software. That's why you have to rely on automated systems as well, which, unlike reviewers, don't get tired from having to deal with SoCkPupeTs.
19:25:43 <sech1> and once again about automated system and code style, why I ask to rename class members to use m_ prefix
19:25:50 <sech1> buggy code shouldn't even compile ideally
19:25:53 <mj-xmr[m]> I have ~12+ years of software dev career in teams that prove it. And it wasn't always all my failt!
19:26:07 <sech1> if you don't use prefixes, you can accidentally use local variable instead of class member in a complex code
19:26:10 <sech1> and it will compile
19:26:20 <sech1> just one typo and you use different variable
19:26:58 <sech1> compiler is your friend and you should help it by writing code that resists bugs by not compiling :)
19:27:05 <jeffro256[m]> @w are you on matrix or IRC?
19:27:14 <sech1> *by giving compile errors
19:28:13 <mj-xmr[m]> sech1: If you like adventures, you may always set a given clang warning to an error or define your own warning/error in clang, like the one you mentioned.
19:28:13 <mj-xmr[m]> I'm using the word "adventures" because this useless chart will show you (more or less) how much work you'll have fixing this:
19:28:18 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/img/tidyCXX.png
19:28:24 <jeffro256[m]> > at the same time you approved https://github.com/monero-project/monero/pull/8365 blindly; facepalm
19:28:24 <jeffro256[m]> I didn't "blindly" approve it. I looked at every single line and come to the conclusion that it's better than what we currently have 
19:28:25 <w[m]> jeffro256[m]: matrix
19:29:13 <jeffro256[m]> ooo123ooo1234567 You keep complaining about the review process, but refuse to participate in it
19:29:14 <sech1> mj-xmr[m] I always prefer -Wall -Werror where possible
19:29:18 <sech1> to keep compilation clean
19:29:26 <sech1> not in Monero codebase unfortunately
19:29:31 <ooo123ooo1234567> > <@jeffro256:monero.social> > at the same time you approved https://github.com/monero-project/monero/pull/8365 blindly; facepalm
19:29:31 <ooo123ooo1234567> > 
19:29:31 <ooo123ooo1234567> > I didn't "blindly" approve it. I looked at every single line and come to the conclusion that it's better than what we currently have
19:29:31 <ooo123ooo1234567> random delay isn't needed, but you approve PR that use random generator in a faster way; facepalm
19:29:31 <mj-xmr[m]> 8365 was actually perfectly prepared for a review and Reviewers as human beings. This is a non-verbal show of the contributor's respect to his reviewers.
19:29:53 <mj-xmr[m]> sech1: We'll get there, if we work as a team.
19:30:11 <ooo123ooo1234567> > <@jeffro256:monero.social> > at the same time you approved https://github.com/monero-project/monero/pull/8365 blindly; facepalm
19:30:11 <ooo123ooo1234567> > 
19:30:11 <ooo123ooo1234567> > I didn't "blindly" approve it. I looked at every single line and come to the conclusion that it's better than what we currently have
19:30:11 <ooo123ooo1234567> it's the same as approving unnecessary optimization
19:30:26 <ooo123ooo1234567>  * it's the same as approving unnecessary optimization with more code, wider scope (previously it's within 1 function, now it's within 1 class)
19:30:27 <mj-xmr[m]> Where even such a "useless charlatan" like me can add a bit here or there.
19:30:28 <mj-xmr[m]> But I don't have to either.
19:30:30 <sech1> 8365 is no unnecessary optimization
19:30:40 <sech1> it fixes a security issue (system entropy depletion)
19:30:57 <jeffro256[m]> Why don't I see any criticism on #8365 ? Let it be known if there's an issue!
19:31:02 <sech1> whether the randomness is needed there at all, is another topic
19:31:16 <jeffro256[m]> > compiler is your friend and you should help it by writing code that resists bugs by not compiling :)
19:31:16 <jeffro256[m]> Dang I must be writing some real bug-resistant code on accident :P
19:31:23 <mj-xmr[m]> If 8365 is an unnecessary optimization, than master MINUS 8365 is worse than that.
19:31:45 <jeffro256[m]> > mj-xmr I always prefer -Wall -Werror where possible
19:31:45 <jeffro256[m]> -Wall -Wextra -Weffc++ -Werror -pedantic is the way to go
19:31:53 <ooo123ooo1234567> sech1: No, std::random_device may use CSPRNG / /dev/urandom / RDSEED / RDRAND, but in the worst case it will be bottlenecked by CPU rdseed/rdrand instruction, which certainly has higher throughput than rate of accepting network connections
19:31:57 <sech1> -pedantic is an overkill
19:32:16 <jeffro256[m]> > > <@jeffro256:monero.social> > at the same time you approved https://github.com/monero-project/monero/pull/8365 blindly; facepalm... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/fa0059322620db0e782f5fb055c542f38bf3d7cc)
19:32:19 <sech1> ooo123ooo1234567 not all systems has rdseed/rdrand
19:32:29 <ooo123ooo1234567> sech1: it isn't security issue
19:32:33 <sech1> and entropy exhaustion is a real problem
19:32:40 <sech1> not a security issue?
19:32:53 <sech1> Imagine you run monerod that exhausts all entropy while syncing
19:32:55 <ooo123ooo1234567> sech1: proof ?
19:33:04 <sech1> then start monero-wallet-cli and create a new wallet with 0 entropy
19:33:11 <sech1> understand now?
19:33:13 <mj-xmr[m]> > <@jeffro256[m]:libera.chat> > mj-xmr I always prefer -Wall -Werror where possible
19:33:14 <mj-xmr[m]> > 
19:33:14 <mj-xmr[m]> > -Wall -Wextra -Weffc++ -Werror -pedantic is the way to go
19:33:14 <mj-xmr[m]> Unreal :)
19:33:31 <mj-xmr[m]> sech1: NO. CARE TO EXPLAIN AGAIN, SLOWLY?
19:33:39 <selsta> mj-xmr[m]: can you stop with it?
19:33:49 <moneromooo> Seconded
19:33:56 <UkoeHB> +1
19:33:57 <mj-xmr[m]> Can you say the same to ooo?
19:34:13 <mj-xmr[m]> let me know how he reacts.
19:34:17 <ooo123ooo1234567> sech1: if it's real problem, then OS is already compromised since user space code can make it vulnerable; 
19:34:26 <moneromooo> You're not ignored yet, that's why you get asked :)
19:34:28 <ooo123ooo1234567> sech1: proof please
19:34:39 <mj-xmr[m]> Why thank you :)
19:34:40 <sech1> it's a problem on uncompromised OS
19:34:53 <sech1> if your own code exhausts entropy, your new wallet will be predictable
19:35:00 <sech1> proof ^^^
19:35:05 <ooo123ooo1234567> sech1: can you find link to any successful demo with entropy depletion that way ?
19:35:13 <sech1> find yourself
19:35:20 <moneromooo> Anyway, if it even needs to be said... fixing entropy exhaustion is good. Please merge, etc etc.
19:35:22 <sech1> I give you ideas, find proofs please if you need it
19:35:33 <jeffro256[m]> ooo123ooo123[m] I agree that we should get rid of the random delay eventually, but we don't have to do it in one fell swoop. It's a relatively easy change to review and takes a step in the right direction. Also please, please, please, please put that stuff into the PR reviews. You have some really good insight so document that with a PR review
19:35:47 <sech1> moneromooo the next question is if it's needed at all (random delay in epee)
19:35:54 <sech1> so I'd wait with merging 8365
19:35:58 <jeffro256[m]> Not only for the author of the PR, but for others who review as well
19:36:01 <sech1> maybe complete removal of randomness is fine there
19:36:08 <moneromooo> Random maybe not, but busy wait is not good.
19:36:09 <ooo123ooo1234567> jeffro256[m]: 1 line changes in wrong direction are also easy to review, but are they needed ?
19:36:53 <moneromooo> Random could help with everything waking up at hte same time, but I'm not sure that can happen.
19:37:04 <sech1> delays are random already
19:37:11 <sech1> because OS can't guarantee exact delay
19:37:27 <jeffro256[m]> > Random maybe not, but busy wait is not good.
19:37:27 <jeffro256[m]> that's what I'm saying. It shoudn't be a horribly long wait just to check again to see if it needs to wait another horribly long period of time to check again to see if it ... 
19:37:37 <ooo123ooo1234567> jeffro256[m]: I don't enjoy talking with people that write shallow comments
19:38:10 <moneromooo> Much more precise than network delays though. A full queue would be due to (if not a bug) network congestion. That'll typically last somewhat longer than a timeslice (I want to say typical 10 ms ?)
19:38:23 <sech1> "It shoudn't be a horribly long wait just to check again" Maybe an exponential backoff would be better there. 1 ms, 2 ms, 4 ms and so on in the loop. And cap it at 250 ms.
19:38:29 <jeffro256[m]> > > <@jeffro256:monero.social> ooo123ooo123[m] I agree that we should get rid of the random delay eventually, but we don't have to do it in one fell swoop. It's a relatively easy change to review and takes a step in the right direction. Also please, please, please, please put that stuff into the PR reviews. You have some really good insight so document that with a PR review
19:38:29 <jeffro256[m]> > 
19:38:30 <jeffro256[m]> > 1 line changes in wrong direction are also easy to review, but are they needed ?
19:38:30 <jeffro256[m]> Do you think #8365 is a small step in the wrong direction?
19:38:31 <sech1> *256 ms
19:39:07 <moneromooo> If it's just one thread spamming lots of messages at once, it'll go through faster though, so small-ish delays are probably better, it'll check often but I assume the work is small, so it won't busy spam CPU.
19:39:17 <ooo123ooo1234567> sech1: sech1, that problem require much bigger changes in other parts; it will be just static delay for now; since code is async, it's ok; don't dive into small scope optimizations
19:39:30 <moneromooo> Sure, TCP like sounds good to me.
19:39:34 <ooo123ooo1234567> > <@jeffro256:monero.social> > > <@jeffro256:monero.social> ooo123ooo123[m] I agree that we should get rid of the random delay eventually, but we don't have to do it in one fell swoop. It's a relatively easy change to review and takes a step in the right direction. Also please, please, please, please put that... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8a3a6871728a7ce15119343ef272e6862386b6a8)
19:39:43 <sech1> yes, if it's async then 250 ms delay is not a problem
19:39:51 <Siren[m]> <ooo123ooo1234567> "Why are you supporting that..." <- What scammer?
19:39:56 <sech1> I was talking about the current loop that sleeps for 250 ms
19:40:01 <ooo123ooo1234567> sech1: talking with all you here I'm learning more about English, rather than C++
19:40:05 <ooo123ooo1234567> Siren[m]: mj-xmr
19:40:11 <selsta> Siren[m]: please move to #monero-community
19:40:29 <moneromooo> IIRC the only times I saw that queue filling was due to a bug though.
19:40:42 <Siren[m]> ooo123ooo1234567: Dunno what you're talking about
19:41:15 <moneromooo> Oh, and possibly at the end of the process. So keeping the max delay small enough helps a pause at the end. 250 ms sounds... low enough I guess.
19:41:59 <ooo123ooo1234567> moneromooo: This constant doesn't matter; small - problem, big - problem; you're talking about unimportant detail without reading code
19:42:02 <moneromooo> Assuming all the threads don't end up sleeping after each other, so 250 ms * 8 would not be nice. I don't know if they can bejave like that off the top of my head.
19:42:19 <moneromooo> so checking the stop flag before sleep is probably good.
19:42:26 <moneromooo> Like, right before. Might already do.
19:42:36 * moneromooo wanders back
19:42:41 <ooo123ooo1234567> moneromooo: in PR it's async code, what threads are you talking about ?
19:44:56 <w[m]> moneromooo: "in PR it's async code, what threads are you talking about ?"
19:44:56 <w[m]> from - ooo123ooo1234567: 
19:46:26 <ooo123ooo1234567> <sech1> "I give you ideas, find proofs..." <- ideas are easy to create, proof/implementation are not easy, any hint ?
19:47:05 <ooo123ooo1234567> <sech1> "if your own code exhausts..." <- I saw only hardware bug in AMD CPU for which rdseed will return 0x000000, but it's already compromised OS since hardware is broken
19:47:20 <sech1> https://lmgtfy.app/#gsc.tab=0&gsc.q=entropy%20exhaustion%20attack
19:48:40 <sech1> or rather https://letmegooglethat.com/?q=entropy+exhaustion+attack
19:50:56 <moneromooo> There are a few P2P threads IIRC. If it doesn't apply, great, nothing to do then.
19:51:44 <sech1> it's better to remove random delay
19:51:58 <sech1> too much hassle to get 1 random number between 0 and 49
19:52:07 <sech1> which doesn't even need to be random
19:52:36 <moneromooo> Sure, as long as low enough that a thread doesn't get stuck unnecessarily several times a row, works for me.
19:52:42 <sech1> core_tests passed without random delay (running tests now)
19:53:13 <sech1> but if you say that this code is barely executed at all, it doesn't really matter
19:54:11 <UkoeHB> spitballing: does random delay let it reorder with other jobs if potentially suck in a delay cycle?
19:55:02 <moneromooo> Well, I don't remember seeing this happen much in my case. I do remember this code yelling many years ago. Guess it could be the warnings got moved to a lesser log level too for all I know :)
20:02:11 <sech1> all tests passed without the random delay
20:03:04 <mj-xmr[m]> sech1: if you PR it, I will start running the valgrind tests already tonight.
20:03:36 <jeffro256[m]> Maybe you could put in a log statement in that while loop which prints if the queue is full and then fuzz test it to see if the code even ever triggers 
20:04:10 <sech1> most likely it doesn't
20:05:10 <ooo123ooo1234567> https://github.com/weaveworks/weave/issues/1037
20:05:11 <ooo123ooo1234567> https://www.2uo.de/myths-about-urandom/#re-seeding
20:05:15 <ooo123ooo1234567> https://eprint.iacr.org/2012/251.pdf
20:05:33 <ooo123ooo1234567> https://github.com/weaveworks/weave/issues/1037#issuecomment-118418860, "Based on that, the only thing we may need to be concerned about is blocking apps on the host that use /dev/random."
20:06:03 <ooo123ooo1234567> linux users are safe even in the worst case when timeout generation from that code will exhaust entropy pool at maximum speed
20:06:41 <sech1> good
20:06:59 <sech1> now maybe it's time to remove that code in your PR as there is no reason for it to be there
20:07:31 <sech1> and PR 8365 is redundant
20:08:22 <ooo123ooo1234567> sech1: look, doing unnecessary change: first reviewer point it and don't dive deeper, not doing unnecessary change: first reviewer point it and don't dive deeper
20:08:41 <ooo123ooo1234567> In both cases if reviewer don't want to spend time then there is no proper review
20:09:05 <ooo123ooo1234567> I'm not sure I will find my own PR for each case, I'm certainly sure there are examples in repo with PRs of others
20:09:46 <ooo123ooo1234567> Also not changing code style: bad, changing code style: why did you do that ?
20:10:13 <ooo123ooo1234567> But all of this doesn't matter, I'm personally will never complain about code style / text / naming / whatever in PRs of others. I will only check it's correct
20:10:59 <sech1> you only care about correct/incorrect and don't care about future maintainers who can make it incorrect because it has bad style and they don't fully understand it
20:11:02 <sech1> very short-sighted
20:11:08 <mj-xmr[m]> OK but this means, that if there's still a reason for a deadlock, it will still be there, but now it will look like a pure CPU hog. We won't be able to distinguish if it's intentional or not.
20:11:43 <sech1> what CUP hog? I'm only suggesting to change "250 + rng() % 50" to just "250"
20:11:53 <ooo123ooo1234567> sech1: No. This kind of challenge may force others to start care about something hard, instead of focusing on shallow things. But I'm not sure
20:12:04 <mj-xmr[m]> Ah sorry. Misunderstood.
20:12:31 <sech1> code style and readability is not shallow things
20:12:35 <ooo123ooo1234567> sech1: It's possible to look at the same thing with different focus / context / angle, and it will look differently. But correct code is working at least
20:12:36 <sech1> here we fundamentally disagree
20:12:56 <sech1> correct code can be working, but at the same time be a shit code
20:13:02 <sech1> from any maintainer's perspective
20:13:32 <sech1> you can write a single 1000-line function full of spaghetti that is correct and works and even bug free
20:13:38 <sech1> good like changing anything there
20:13:39 <ooo123ooo1234567> sech1: No, correct code is pretty hard to write
20:13:39 <mj-xmr[m]> sech1: Code is meant to be read by humans. Machines are happy with binary code.
20:13:39 <mj-xmr[m]> Also the humans who are meant to read it aren't only the original author. 
20:13:55 <sech1> *good luck
20:14:07 <sech1> define correct code then
20:14:21 <mj-xmr[m]> It can be the original author only that is meant to read it, but this doesn't belong to a team/community project.
20:14:27 <sech1> 1000-line spaghetti code function is correct? If it passes all tests and has no bugs?
20:17:49 <mj-xmr[m]> I just realized that we're selling years of professional experience to somebody who isn't worth it, entirely for free. Good night.
20:17:55 <ooo123ooo1234567> sech1: That's the problem: we are talking without defining common goal explicitly. And implicitly deduced one isn't equal probably
20:18:59 <ooo123ooo1234567> mj-xmr[m]: experience of writing fiction literature in form reports in your case; facepalm
20:20:09 <ooo123ooo1234567> <sech1> "1000-line spaghetti code..." <- I can treat your question as a challenge or blindly agree. I have no idea if there is some edge case where such code would be correct.
20:20:50 <ooo123ooo1234567> <sech1> "1000-line spaghetti code..." <- In most cases spaghetti code is written by people who add small scope short term fixes
20:21:02 <sech1> define correct
20:23:25 <ooo123ooo1234567> <sech1> "1000-line spaghetti code..." <- Some things with a lot of edge cases can't be implemented without if/else. There is probably even example in one of you rerpo
20:24:01 <ooo123ooo1234567> Things which are easy (within available time) to decompose can be implemented without spaghetti
20:30:17 <ooo123ooo1234567> > <@mj-xmr[m]:libera.chat> > <@sech1:libera.chat> code style and readability is not shallow things... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0921002276ea5c4e4a1299e1bd2d35e9808c7afc)
21:10:47 <ooo123ooo1234567> <mj-xmr[m]> "8365 was actually perfectly..." <- and all reviewers blindly approved; facepalm
21:12:08 <ooo123ooo1234567> <mj-xmr[m]> "8365 was actually perfectly..." <- scammers are very respectful and pleasant, until understand that they will not receive money
21:23:53 <ooo123ooo1234567> <UkoeHB> "spitballing: does random delay..." <- nobody writes async code that requires random delay in order to be correct; only incompetent developers adds random delay in some places in order to pass tests or hide deeper problem; and it was this case : firstly delay, then random delay, then proper usage of random number generator for random delay
21:28:02 <ooo123ooo1234567> <mj-xmr[m]> "Can you say the same to ooo?" <- are you trying to create alternative reality description for people that don't see all msgs ?
21:34:01 <luigi1112> mj-xmr[m] ooo123ooo1234567 please keep drama out of -dev to best of your ability. -community may be basically unmoderated (currently), but -dev isn't (supposed to be)
21:34:53 <ooo123ooo1234567> luigi1112: drama is about emotions, it isn't about emotions. There are real problems that are not solved.
21:35:36 <ooo123ooo1234567> luigi1112: And don't put me into the same row with this scammer;
21:35:56 <ooo123ooo1234567> These questions are relevant to anyone who will do the same
21:36:34 <luigi1112> the questions do not require inflammatory language
21:37:13 <ooo123ooo1234567> luigi1112: If there would be rules and no blind merges, then It would work
21:37:53 <luigi1112> let's improve it
21:38:19 <ooo123ooo1234567> luigi1112: I think I can defend every my word
21:39:56 <luigi1112> on a related note, improving things would be a good time to revisit finding a dedicated maintainer
21:40:19 <luigi1112> *esp for the monero repo
21:43:32 <ooo123ooo1234567> <mj-xmr[m]> "Reviews aren't a 100% safeguard..." <- I would completely opposite: the most important problems in monero can't be detected by incompetent people no matter what tool they are using; you're clear example;
21:46:00 <ooo123ooo1234567> <sech1> "bugs exist even in the best..." <- It's a comment about hardness to reach perfection, but in current environment I would say even lower boundary of qualification isn't reached yet
21:47:11 <ooo123ooo1234567> <jeffro256[m]> "What's your GH handle then..." <- if you're not anonymous then it doesn't mean that you must ask everyone what is their GH handle. Also GH isn't a measure of anything.
22:04:56 <mj-xmr[m]> <luigi1112> "the questions do not require..." <- I'll do my best. I just don't like being falsely accused of being a scammer.