00:09:08 <sethsimmons> WOW those are a lot higher than I expected
00:09:57 <volantaryism1[m]> sethsimmons: for reference, i believe bitcoin has around 100k nodes
00:11:24 <donkeydonkey> yeah a lot higher than i could find. i found bout 1520 nodes. nice work.
00:33:37 * Rishab[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/SOIpIGQjzEwocVyFoVofHuGT/message.txt >
00:33:52 <Rishab[m]>  * hi, I am struggling to get monero building on mac os. Has anyone on mac os run into this error:
00:33:52 <Rishab[m]> `Undefined symbols for architecture x86_64: "cryptonote::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&)", referenced from: hw::core::device_default::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&) in device_default.cpp.o ld: symbol(s) not found for architecture x86_64`
00:34:10 <Rishab[m]>  * hi, I am struggling to get monero building on mac os. Has anyone on mac os run into this error:
00:34:10 <Rishab[m]> Undefined symbols for architecture x86_64: "cryptonote::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&)", referenced from: hw::core::device_default::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&) in device_default.cpp.o ld: symbol(s) not found for architecture x86_64`
00:34:25 * Rishab[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/nnMdOSixXzagynEZpvZWVOFt/message.txt >
00:38:27 * Rishab[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/pyfmCeeFLrpCDUoTRmCenFyf/message.txt >
01:01:26 <selsta> Rishab[m]: yes, debug build is currently broken on Mac
01:10:17 <Rishab[m]> <selsta "Rishab: yes, debug build is curr"> I tried on release and i get the same error
01:10:53 <selsta> did you do a clean build?
01:11:29 <Rishab[m]> <selsta "did you do a clean build?"> nope, will try that
03:16:38 <dknsmoaeurgc> FUK has bееn intеnsеly hostilе to Monеro for ovеr 4 yеars. Making minеrs for Monеro, making a pool for Monеro, making codе that Monеro copiеd, not using bugs to stеal millions from еxchangеs. Wow. Such grеat hostility.
13:49:42 <moneromooo> Gah, the calculate pi stuff isn't easy to disable and it's breaking running tests -_-
13:50:08 <moneromooo> Plenty of lines to comment out and python always complains when it gets to running stuff...
14:14:15 <mj-xmr_> moneromooo, when is it breaking tests?
14:15:29 <mj-xmr_> Fire away, I'll have a look in about 3 hours from now.
14:16:20 <cfknhstqz> I can tell you why you can't stop the 'spam'. You are thinking in cult doctrine. If it was real spam, and I was selling Viagra for example - you could easily ban keywords and urls. Instead, stop being a sheep, think like a cult leader. Recoginse that this 'spam' is just some bullshit that you tell to the sheep.
14:16:20 <cfknhstqz> When you do that, solution will present itself. Observe. 'spam' -> 'FUK talks bad things about Monero on our IRC' (Don't say that out loud obviously, that will get you excommunicated) Solution? Get off-the-shelf sentiment analyser, detect anyone who 'talks bad things about Monero' and ban them.
14:17:03 <moneromooo> I was running ./tests/functional_tests/functional_tests_rpc.py /usr/bin/python tests/functional_tests/ build/Linux/crash/release/ mining
14:17:36 <moneromooo> It did not find the cpu-power-test binary. I assume because the makefile sets path correctly, but I did not look.
14:18:22 <mj-xmr_> ok, I'll try to reproduce it. Doesn't sound like rocket science from this point.
14:18:34 <moneromooo> In the end, https://paste.debian.net/hidden/3bbd3945/ fixed it.
14:19:49 <mj-xmr_> Yeah sorry about it.
14:19:59 <mj-xmr_> But I'll get it sorted.
15:43:56 <nvtleafeapfh_> “I thought, ‘I’m going to pump it and dump it,’ because I was interested and taking the ideas and implementing them in bitcoin. The bitcoin code base was far more interesting to me than monero, and I thought, ‘I’m not going to work on this codebase, it’s terrible,'” he recalls - fluffypony in an interview about Monero
17:06:13 <mj-xmr_> OK, I see how I can fix the mining test. Gimme half an hour.
17:06:24 <mj-xmr_> All the info is there.
17:09:46 <moneromooo> Thanks. No rush now.
17:10:16 <moneromooo> While you're there, the mining test is still printing all these debug traces.
17:10:22 <moneromooo> Timings etc.
17:11:35 <mj-xmr_> Not helpful?
17:12:18 <moneromooo> I meant it's still printing various lines like "It took N seconds" or whatever the message was.
17:12:19 <mj-xmr_> We thought with "iamamyth" that we could throttle this a bit, by reducing the timeouts.
17:12:45 <mj-xmr_> But for that we need to see what the actual readouts are from multiple runs.
17:12:45 <moneromooo> Also, if it takes 40 seconds to run a mining test, it's not really nice to take twice (once to measure, other to run). So making it optional would be great ^_^ as in, bypass if the env var NO_MEASURE_MINING is set maybe.
17:13:27 <moneromooo> Like, takes 40 seconds to init on my laptop, so that's 40 seconds spent waiting for the test to essentially do nothing.
17:13:49 <mj-xmr_> I agree. But on the CI I would like to keep it.
17:13:55 <moneromooo> Sure.
17:14:04 <mj-xmr_> Shall it all be in one PR?
17:14:13 * moneromooo does not mind either
17:14:35 <mj-xmr_> It would make it easier for everybody I think, but I'm not the reviewer.
17:27:17 <mj-xmr_> moneromooo, I got the path stuff mostly sorted. Just need to test on the CI. But I have a question re: NO_MEASURE_MINING. Wouldn't it be better to make a CACHE_MINING_MEASUREMENT, so that your first measurement is stored to a file and then reused?
17:28:03 <mj-xmr_> BC, I'm afraid that without these measurements you'd have to set the timeouts by hand, and this is kind of witchcraft.
17:29:38 <moneromooo> Sounds like more complexity to me, but I'm not going to argue against. After all I did a similar thing for performance tests to track progress so...
17:30:51 <selsta> I would also not add some caching there
17:32:03 <selsta> if someone disables measurement they will know how to set the timeouts
17:32:12 <mj-xmr_> Alright.
17:33:53 <moneromooo> Large timeouts by default seems fine.
17:34:10 <moneromooo> Most of the time, they won't trigger so will not get in the way.
17:34:31 <moneromooo> And if they trigger, you get to spend time debugging anyway.
17:34:56 <moneromooo> The measure once, cut once makes you pay every run.
17:57:43 <mj-xmr_> OK, I got your wishes coded. Should I also silence the RAM availability measurement?
17:57:49 <mj-xmr_> These are 2 lines in total.
17:58:40 <moneromooo> Do they have any point unless you're debugging this ?
18:00:12 <mj-xmr_> I'd say, if the mining fails, it could be because of lack of RAM as well, because RX needs a lot.
18:00:38 <mj-xmr_> So if on a CI I see a red flag, I'd check the RAM
18:00:47 <moneromooo> Then print it if it fails.
18:01:36 <moneromooo> Though ideally that'd in the logs in the first place.
18:01:37 <mj-xmr_> OK, I think I will have to do this sort of diagnostics separately. For now I'll just hide it as it's a corner case.
18:02:55 <mj-xmr_> So the following logic now applies:
18:03:12 <mj-xmr_> You can set mining and init timeouts via export=
18:03:21 <mj-xmr_> TIMEOUT_MINING_MINE
18:03:26 <mj-xmr_> TIMEOUT_MINING_INIT
18:03:54 <selsta> or just set a large default
18:04:09 <selsta> and one env var to disable the measurement
18:06:28 <mj-xmr_> Yeah ok
18:06:40 <mj-xmr_> At least a low power user will be able to measure it
18:07:07 <selsta> as mooo said, it does not matter if the timeout is too large as long as there are no issues (which should be the default case)
18:07:54 <mj-xmr_> This is exactly what we want to test with small timeouts - if there are any issues.
18:08:14 <mj-xmr_> But OK. As long as the default beh. is to measure, I'm fine.
18:08:35 <mj-xmr_> What do we do about the logs? Silent by default for now?
18:08:47 <selsta> silent unless failure seems to make most sense
18:09:35 <mj-xmr_> If there's a failure, I won't have access to the previous messages, unless I buffer them. Sounds like a plan?
18:12:00 <moneromooo> Messages about... available memory ?
18:13:25 <mj-xmr_> Yes and time
18:14:40 <moneromooo> I might be missing something, but you could call call the availalble memory code if it fails, rather than before, print a messge in a buffe, and then write the buffer if it fails.
18:15:48 <moneromooo> You know what. Leave those messages if it's going to be complicated. If they annoy me too much I'll take them out on my work branch (some more pointless conflict targets).
18:17:34 <mj-xmr_> moneromooo, it does get kind of complicated, because of not being able to really catch the error situation.
18:17:55 <mj-xmr_> What I propose is that you set a MINING_SILENT flag to silence them
18:18:03 <mj-xmr_> I mean an env var.
18:19:23 <moneromooo> Sure. And maybe a single var for the lot. Three vars seem... I dunno, part of me is thinking I'm painting the shed but it really *was* annoying...
18:19:58 <mj-xmr_> I realize this
18:20:26 <mj-xmr_> So then one var for NO_CALCULATION and timeouts large enough?
18:20:40 <moneromooo> Yes please :)
18:20:50 <mj-xmr_> Coming up
18:20:55 <moneromooo> Thanks
18:26:16 <mj-xmr_> Generally, whoever messes with these variables, knows what he's doing.
18:39:07 <mj-xmr_> It's on. https://github.com/monero-project/monero/pull/7686
18:39:29 <mj-xmr_> I'll write some description later. It also needs to pass the tests.
18:39:57 <moneromooo> ty
22:41:43 <nikg83[m]> Question: if someone modifies monero wallet to put in a extremely low fee, does the network reject it ? or stays there till it gets dropped, if miners decide not to include it a block due to low fee
22:45:20 <LyzaLittle> <nikg83[m]> I think this may answer your question https://www.reddit.com/r/Monero/comments/52ta35/decrease_minimum_fee_from_001kb_to_0002kb_by/d7n6l20/
22:46:15 <LyzaLittle> gingeropolous made the comment he may have more to say