WOW those are a lot higher than I expected

sethsimmons: for reference, i believe bitcoin has around 100k nodes

yeah a lot higher than i could find. i found bout 1520 nodes. nice work.

* hi, I am struggling to get monero building on mac os. Has anyone on mac os run into this error:

`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`

* hi, I am struggling to get monero building on mac os. Has anyone on mac os run into this error:

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`

Rishab[m]: yes, debug build is currently broken on Mac

<selsta "Rishab: yes, debug build is curr"> I tried on release and i get the same error

did you do a clean build?

<selsta "did you do a clean build?"> nope, will try that

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.

Gah, the calculate pi stuff isn't easy to disable and it's breaking running tests -_-

Plenty of lines to comment out and python always complains when it gets to running stuff...

moneromooo, when is it breaking tests?

Fire away, I'll have a look in about 3 hours from now.

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.

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.

I was running ./tests/functional_tests/functional_tests_rpc.py /usr/bin/python tests/functional_tests/ build/Linux/crash/release/ mining

It did not find the cpu-power-test binary. I assume because the makefile sets path correctly, but I did not look.

ok, I'll try to reproduce it. Doesn't sound like rocket science from this point.

In the end, paste.debian.net/hidden/3bbd3945 fixed it.

Yeah sorry about it.

But I'll get it sorted.

“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

OK, I see how I can fix the mining test. Gimme half an hour.

All the info is there.

Thanks. No rush now.

While you're there, the mining test is still printing all these debug traces.

Timings etc.

Not helpful?

I meant it's still printing various lines like "It took N seconds" or whatever the message was.

We thought with "iamamyth" that we could throttle this a bit, by reducing the timeouts.

But for that we need to see what the actual readouts are from multiple runs.

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.

Like, takes 40 seconds to init on my laptop, so that's 40 seconds spent waiting for the test to essentially do nothing.

I agree. But on the CI I would like to keep it.

Sure.

Shall it all be in one PR?

It would make it easier for everybody I think, but I'm not the reviewer.

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?

BC, I'm afraid that without these measurements you'd have to set the timeouts by hand, and this is kind of witchcraft.

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...

I would also not add some caching there

if someone disables measurement they will know how to set the timeouts

Alright.

Large timeouts by default seems fine.

Most of the time, they won't trigger so will not get in the way.

And if they trigger, you get to spend time debugging anyway.

The measure once, cut once makes you pay every run.

OK, I got your wishes coded. Should I also silence the RAM availability measurement?

These are 2 lines in total.

Do they have any point unless you're debugging this ?

I'd say, if the mining fails, it could be because of lack of RAM as well, because RX needs a lot.

So if on a CI I see a red flag, I'd check the RAM

Then print it if it fails.

Though ideally that'd in the logs in the first place.

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.

So the following logic now applies:

You can set mining and init timeouts via export=

TIMEOUT_MINING_MINE

TIMEOUT_MINING_INIT

or just set a large default

and one env var to disable the measurement

Yeah ok

At least a low power user will be able to measure it

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)

This is exactly what we want to test with small timeouts - if there are any issues.

But OK. As long as the default beh. is to measure, I'm fine.

What do we do about the logs? Silent by default for now?

silent unless failure seems to make most sense

If there's a failure, I won't have access to the previous messages, unless I buffer them. Sounds like a plan?

Messages about... available memory ?

Yes and time

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.

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).

moneromooo, it does get kind of complicated, because of not being able to really catch the error situation.

What I propose is that you set a MINING_SILENT flag to silence them

I mean an env var.

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...

I realize this

So then one var for NO_CALCULATION and timeouts large enough?

Yes please :)

Coming up

Thanks

Generally, whoever messes with these variables, knows what he's doing.

It's on. monero-project/monero #7686

I'll write some description later. It also needs to pass the tests.

ty

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

<nikg83[m]> I think this may answer your question reddit.com/r/Monero/comments/52ta35…fee_from_001kb_to_0002kb_by/d7n6l20

gingeropolous made the comment he may have more to say