Kk

.merge+ 9243 9244

Added

<j​z1111:matrix.org> is there an example on how to create the binary request body for `/get_blocks.bin`?

<j​effro256:monero.social> You can look to wallet2 for reference: github.com/monero-project/monero/bl…/src/wallet/wallet2.cpp#L3037-L3057

<j​effro256:monero.social> You don't need the lock if not multi-threading and `m_http_client` is just an instance of `net::http::client`

<j​effro256:monero.social> There's other types of pool retrieval like incremental: github.com/monero-project/monero/bl…/src/wallet/wallet2.cpp#L3591-L3601

<j​z1111:matrix.org> is there a way to do this outside c++?

<j​z1111:matrix.org> is there a bash way to do this? we're using curl to send the `/getblocks.bin` request

<j​effro256:monero.social> Not easily

<j​effro256:monero.social> If you know the epee binary format and on-chain serialization format, you can hand-craft the messages yourself

<j​effro256:monero.social> There might be libraries in the monero ecosystem that do this IDK. Try asking in #monero-community-dev:monero.social

<j​effro256:monero.social> Why not just use the `get_block` JSONRPC method?

<n​eo_00:matrix.org> Hello everyone, I'd like to clarify one point. Is there a way to ensure that when sending a transfer, the remaining part of the input is not locked? Thanks.

No.

<p​cre:matrix.org> C++ has come under a bit of fire lately. Recently, even the White House has fired shots against C++!

<p​cre:matrix.org> Templates were intended as a replacement for the C preprocessor, and are now ... programmable. Template metaprogramming! No, not a joke. Seriously!

<p​cre:matrix.org> Tick to C guys

<p​cre:matrix.org> Stick to C

<p​cre:matrix.org> std::vector was intended as a replacement for C arrays, but operator[] does not do range checking. This makes it worse than C arrays because it looks safer but is not.

<p​cre:matrix.org> std::span was intended as a replacement for pointer arithmetic, and the Microsoft reference implementation that introduced it to the standard committee had mandatory range checking. The standard committee saw this and removed it. As a result, std::span is now worse than pointer arithmetic because it looks safer but is not.

<p​cre:matrix.org> Iterators were intended as a replacement for pointer arithmetic, but not only do they not have range checking, they don't realise when you throw away the container and then do memory corruption. This makes them worse than pointer arithmetic in C, because they look safer but are not.

<p​cre:matrix.org> Why am I telling you all this? Because the C++ community is slowly realising that they have wrapped the car around the tree. The rescue attempts are becoming downright humorous. Bjarne Stroustrup gave a downright grotesque talk on C++ Safety at Cppcon. In comparison, Biden seems fresh and up to the challenge. Stroustrup is still trying to minimise the problem and define it away.

#languagerant is that way ->

lol

but yeah, I agree, stick to C. still more readable and easier to debug than template-ridden code

<p​cre:matrix.org> sorry.

TLDR has Rust been mentioned?

<g​fdshygti53:monero.social> Yes, rust has been mentioned

<g​fdshygti53:monero.social> I personally have some issue with it.

<g​fdshygti53:monero.social> It might be memory safe, but the risk of easy to do supply chain attack is way higher. Yet, not at the level of node-js and python but I assume it will go up with usage.

<g​fdshygti53:monero.social> I think it might be still ok if you audit every crate and every time one get updated

<g​fdshygti53:monero.social> If only that could mitigated it would be great because it's one of the rare language that actually perform really good (afaik it sit between C and C++)

audit every crate - sure, no sweat...

<s​gp_:monero.social> jberman (or others): do you know if the daemon RPC /get-info is still expensive?

<g​fdshygti53:monero.social> Look expensive compared to most other calls

<g​fdshygti53:monero.social> Only get_transactions and get_blocks are more expensive than get_info, look like

<s​gp_:monero.social> So `/get_height` is expected to be significantly less expensive?

yes, it's much faster

XMRig uses it for solo mining (when ZMQ is not enabled)

<s​gp_:monero.social> If I'm understanding correctly, the response `untrusted: false` means that the node is reporting fully synchronized?

untrusted means the data was retrieved from (proxied to) a separate daemon.

Or that the daemon ran in that mode after last startup.

<s​gp_:monero.social> I'm trying to implement the most sensible health checker method. Is there a more efficient zmq endpoint for this? Or is /get_height the best option

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/SzyrEiMMICxOGlsnoJqytFCv

<g​fdshygti53:monero.social> get_info

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/euRmShuxOQUXXIdsvKbVBmZh

<g​fdshygti53:monero.social> get_height

<g​fdshygti53:monero.social> a **lot** faster yeh

<s​gp_:monero.social> Wow

ZMQ lets you know about all new blocks/transactions the moment they are received

and it's almost free for the node (except traffic)

<s​gp_:monero.social> RavFX: what dashboard are you using for that?

<g​fdshygti53:monero.social> github.com/lalanza808/docker-monero-node

.merges

selsta

luigi1111w: merge these two and tag in an hour or two?

ok

luigi1111w: you can tag

and ping me once done so that i can also bump the gui submodule

selsta done

ty

luigi1111w: can you restart this CI run? github.com/monero-project/monero/actions/runs/8254793978

seems network error

cancel it?

can you cancel and start again?

or not sure what options there are, usually it can be run again

looks like they have to have failed or be canceled

mac one restarted now

Cancel first, then you will have an option to restart

failed again.... network error or appears so, but this time somewhere else

hmm

can you cancel start it again pls if it fails again i'll get the binaries from somewhere else

done

looks good now it went to the build step

paste.debian.net/plain/1310513 v0.18.3.3