I am reading about randomX and wasm and it sounds like the main (only?) blocker is that WASM does not closely follow IEEE standards for fp operations. Has anybody produced a working example of a workaround to this?

You will DO what Monero tells you to do. You will JUMP when you are told to jump. And most importantly you will DISCONNECT whoever Scientology^H^H^H^H^H I mean Mnero tells you to disconnect. Otherwise you WILL end up like lh1008 here:

monerologs.net/monero-community/20210114#c181614 And you will do it all for FREE. Because Monero is open souce :D Just like Linux is there to pay for $700k watches that Torvalds wears.

Hi. Is it possible to open the monero-qui as a project in QT Creator?

yes

what is the file name then?

when I am opening main.qml the is opened as ordinary file but not QT project. It seems should exist *.pro file elsewhere?

enjo.hopto.org/pub/monero <-- the stats are steadily improving. Same as the compilation time:

Resulting from the changes "for the sake of changing something". The "something" is the compilation time, and "the change" is in this case: reduction.

Hopefully it won't also be new bugs.

I wouldn't touch it if there were no tests.

But true that. I will also focus on the test coverage some.

Does this graph show it's building about 10% faster with those changes ?

20% faster from the top.

But this is a full rebuild. A lot more could have been achieved for incremental compilations thanks to ccache.

This is because the changes in the code, that now is in .cpps doesn't force recompilations. This is the obvious part. Also cutting the header interdependencies short help in this.

*Could have been -> meaning that it was achieved most probably, but it's hard to measure it objectively without analysing the history of changes.

This is possible, but doesn't bring any benefit.

Also for the completeness sake, please note, that the lines of code metrics is steadily raising.

I think it's cool, that at the same time the compilation time is being reduced.

<mj-xmr "enjo.hopto.org/pub/monero"> good stuff! is there a particular way that the community could help bring more confidence to it? perhaps running a branch on testnet ... ?

CCosta[m], thanks. I don't understand how a branch on the testnet could help?

These are simply checks for master's code.

oh, I thought that was from the work you've been PR'ing

like 7679 and 7676, etc

It is not only my work, but the truth is, that I'm the only one who works on the compilation time.

let me see

(it we're talking about the same thing :) )

👍️ so yeah, I was just wondering if it's the case that you lack some confidence on the changes and keeping the compiled code running on testnet could help, would be happy to help :)

Yes CCosta[m] these branches influence the compilation time.

Ah I understand now.

You can do it if you like, but what these branches are missing the most is reviewing time. Many of these changes unfortunately require moving a lot of code from headers into .cpp files. There is always a risk, that there is a unintended modification of the implementation being moved.

Because you see one big chunk of a diff :(

mj-xmr: yeah, big diffs indeed 😬 i'm still getting used to the codebase, If I get some spare time this afternoon, will give it a look for sure

is there a particular one that I should prioritize?

I mean, that'd benefit the most

perhaps unblock other ones

7679 would be awesome. It brings measured -2.5% reduction overall

cool, sounds good 👍️

6934 brings another 2.5%

6934 seems huge, but the majority of the changes are only concerning header sections really.

While 7679 would unblock massive gains to be done further.

And since you dared to ask, 7416 is blocking me from writing more unit tests for epee.

:)

and is a very tiny one BTW.

So thanks in advance.

uuuh, 27 loc vs 1k+ haha

cool, gonna have some breakfast then take a look at 7416 this morning, might get to 7679 this afternoon then 👍️

These 27 changes are simply moving code around. Nothing new. Just made it available to a broader spectrum.

OK. Enjoy.

osineofine, you may wanna idle in #monero-pow

Hello all seems like monero will require to open a firewall tcp connections from some random gobal IPv4 in order to run in my xeon server with Linux ubtuntu?

no, you can run with firewalled ports jair . it just depends on what your trying to achieve.

but yes, monerod will try and make outgoing connections to other nodes

<mj-xmr "These 27 changes are simply movi"> github.com/mj-xmr/monero/blob/b4fe7…contrib/epee/src/CMakeLists.txt#L78 I noticed that this is newly added compared to before - compiles just fine without it, but I guess it'd fail at runtime otherwise?

CCosta[m], are you building static or shared libraries?

Because it's needed for shared libraries.

Word of guys running Monero community should be BELIEVED. Why would anyone that stole money and laughed at the losers that took the bait ever have a reason to lie to you? removeddit.com/r/Monero/comments/6d…ds_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?)

<mj-xmr "utxobr, are you building static "> oh damn, yeah, the build that worked was without DBUILD_SHARED_LIBS... nvm

static linkage is the easy part :) But costs time later on...

If there are any web developers in here that are interested in a one-time job on developing a new project I had in mind (sole-proprietor business that has some of the profits going to CCS Gen Dev Fund) Let me know... I'm trying to spread the good word of Monero (and BTC) to collectors of sports memorabilia and guitar/guitar pedal addicts :)

mainly that's all the stuff I have available for now that I'm willing to sell, but it's aiming to be a collectible haven for people to set up shop

<mj-xmr "utxobr, are you building static "> actually, just reran the builds here, and yeah, it actually compiles just fine

am I missing something? (very rarely do cpp work, rusty on it for sure)

It should compile fine. No surprises there.

CCosta[m], And this is what the CI (GitHub Actions) is supposed to check + tests.

yeah, was just a bit surprised that it didn't fail without `Boost_REGEX_LIBRARY` - pr lgtm though 👍️

Did it fail with Regex set to private and Shared=ON?

Because it should.

`rm -fr ./build; && cmake -DBUILD_SHARED_LIBS=1 -DSTATIC=0 -S . -B build && make -C build -j16` does it fail without regex lib or not ?

<wfaressuissia[m] "`rm -fr ./build; && cmake -DBUI"> succeeds

<mj-xmr "Did it fail with Regex set to pr"> hmmmm how would I set regex to private?

it hypothetical question in case if you placed `${Boost_REGEX_LIBRARIE}` lib few lines below, under `PRIVATE`

let me try

It doesn't matter since in your case it doesn't fail even without regex lib at all

run make with trace and check what libs are being used during linking

maybe it's included implicitly somehow

CCosta[m], did you try to run tests/unit_tests/unit_tests ?

`rm -fr ./build; && cmake -DBUILD_SHARED_LIBS=1 -DSTATIC=0 -S . -B build -GNinja && ninja --verbose -C build epee` paste log of compilation for all epee related objects

a-ha, with test it fails indeed

` cmake -DBUILD_TESTS=ON -DBUILD_SHARED_LIBS=1 -DSTATIC=0 -S ..`

`-DBUILD_TESTS=1` yeah, this option was set here too

also don't just build epee. Also build unit_tests and core_tests

and try to execute them of course

`-DBUILD_TESTS=0` but it fails during link stage with option, so it is unrelated

"a-ha, with test it fails indeed" It didn't fail since you've tried it on linux which allows undefined symbols during linking stage of shared library

"-Wl,--no-undefined" with this flag it will fail at link stage of epee

even on linux

cool. I didn't know that.

interesting, thx for sharing!

mj-xmr, What OS were you using during many years of c++ development ?

Was it Windows ?

wfaressuissia[m], Windows only during my studies, bc I had too small a HDD for a dual boot. Then Windows only for modding a closed source Windows project, but all private stuff under Linux.

The point is, that I was mostly focused on calculations, algorithms and such stuff.

So even though I was using Linux, I didn't focus on such details.

Well, TIL

thanks for the pointer gingeropolous, appreciate it

running on M1 Mac, seems to have no issues for the moment. syncing ok.

M1 uses 16KB pages, so the LMDB files are not directly usable on x86 linux

wonder if bitcoin has depends build for arm mac

(actually the LMDB files will work just fine, though perhaps not optimal for the underlying OS)

iinteresting - how's mining performance?

already posted xmrig benchmark results

i'll probably replace my work macbook pro soon, wondering if I should get m1 or another x86

> already posted xmrig benchmark results

cool! i'll take a look

apple x86 is a dead end, def would not buy one

interesting, I was expecting higher for the m1 looking at xmrig.com/benchmark/1

the reported results are on he low side because the CPU throttles partway thru the run

if I had a fan blowing over the chassis it prob would have kept going

syncing with --add-exclusive-node to my linux laptop keeps stopping, disconnecting and banning it

exit/restart, and it continues for a while

What error does it come up with ?

eh I didn't have any particular logging set

it just said monerod is disconnected from network

2021-04-24 19:37:03.347W monerod is now disconnected from the network

after a bunch of successful syncs

have loglevel 1 now

syncing with 1 node has been broken for a while

uh. that kinda sucks.

I remember we had the same discussion 2-3 releases ago :D

think this'll be fixed with that perfecting-p2p CCS?

that code is not touched yet

at some point yes :D

current fixes were regarding lower level network code

wfaressuissia[m]: is cryptonote_protocol_handler the relevant code here?

yes

moneromooo: paste.debian.net/1195036

lemme know if you need anything earlier than that. everything after that is just the same stuff over and over

or selsta or wfaressuissia[m] ^^

"fresh node can't be synced if it was launched with `--add-exclusive-node`" is it complete description of your environment ?

I have also set --prune-blockchain but I don't think that makes a difference

and also set --hide-my-port

There are some known errors that may lead to disconnection of legitimate peers. Single connection case may have higher probability to catch this error. It can't be fixed easily in isolated way.

It isn't critical for real world usage due to many peers with different IPs, but the same likely happens there too

When Tari finally comes out, will you dump your Monero to buy it? Will others?

unfortunate. one would think single-peer case is the easiest to get right.

I'll try to reproduce it locally and check whether it's fixable in isolated way, but it isn't the most important thing to fix now

Looks like the peer did not reply to the request. You'd need logs from the peer to know why.

I'd think the peer is pruned that that location, but it if restarts and syncs with the same peer it can't be that...

why Freenude have such cheap server

:/