10:36:33 <cerbere> greetings, where can I find information about what a daemon rpc error code 0 means ? I found all others in https://github.com/monero-project/monero/blob/8286f07b265d16a87b3fe3bb53e8d7bf37b5265a/src/rpc/core_rpc_server_error_codes.h but cannot spot the error 0, I get it when sending a flush_txpool if that helps.
10:43:06 <moneromooo> 0 would be no error.
10:47:36 <cerbere> interesting
10:52:11 <cerbere> is that intended ? I may obviously misunderstand something, but usually if there is no error I receive a json rpc answer with a result key, it's the only case I encounter where a success would yield a {'error': {'code': 0, 'message': ''}, 'id': 0, 'jsonrpc': '2.0'} rpc answer
10:55:11 <moneromooo> Then something might be failing to set an error code.
10:55:32 <moneromooo> File a bug with the JSON you're sending.
10:55:51 <cerbere> will do, thanks
11:57:44 <moneromooo> Longstanding confusion between error code and status error reporting. I'll PR a patch soon.
12:15:52 <kayront> https://www.visualsource.net/repo/github.com/monero-project/monero
12:15:55 <kayront> :mindblowngif:
12:36:50 <cerbere> that was quick @moneromoo ! thanks
15:09:23 <luigi1111w> .merges
15:09:23 -xmr-pr- 6877 6959 6986 7000 7185 7242 7252 7265 7270 7273 7275 7284 7288 7294 7308 7309 7311 7312 7313 7319 7325 7331 7332 7333 7339 7340 7341 7343 7349 7351 7352 7355 7361 7362 7371
15:35:33 <alphabettica> Guys if one of the structures inside the transaction class was was changed, say we added an extra data variable in one of them, do we need to update the database version? What other stuff would have to be done to make everything ok
15:35:53 <alphabettica> in a generic sense
15:36:31 <alphabettica> would the code go back and add space for that data variable to every previous database entry for that structure?
15:36:40 <moneromooo> In the general sense, no. The tx is stored as a bytestring.
15:37:31 <alphabettica> Ok. But we would if we modified the existing elements?
15:37:36 <moneromooo> You'd need to change serialization and presumably fork with updated validation rules. If this is for an altcoin, you would not need that though.
15:37:44 <alphabettica> say if we changed a uint64 to a 32
15:37:59 <alphabettica> so the db could still read the old values as 64
15:38:06 <moneromooo> The tx is stored as a bytestring.
15:38:50 <moneromooo> Now if you change something like height, you might want to alter the db to save space, but you would not *need* to.
15:39:25 <moneromooo> In fact, we use 64 bits for height everywehre, but there's a MAX_BLOCK_NUMBER or so define that fits on 32 bits. So we do waste a bit.
15:41:08 <alphabettica> But say if i've got a structure with a uint32 in there, and then change to 64. Wont reading the old values from the db read in the correct 32 and then 32 of junk?
19:07:11 <luigi1111w> 6877 conflicts moneromooo
19:08:29 <moneromooo> fixed
20:26:26 <pyu> on the recent CCS for 'perfect p2p protocol', wonder if can borrow some parts from libp2p (https://github.com/libp2p).
21:21:03 <cori> what's up
22:18:02 <fluffydonkey[m]> <pyu "on the recent CCS for 'perfect p"> the C++ - Go interop isn't all that good
23:48:54 <hank303> Does anyone here know why this
23:48:55 <hank303>     struct txin_to_key_public
23:48:56 <hank303>     {
23:48:56 <hank303>       uint64_t amount;
23:48:57 <hank303>       uint64_t relative_offset;
23:48:57 <hank303>       crypto::hash tx_hash;
23:48:58 <hank303>       BEGIN_SERIALIZE_OBJECT()
23:48:58 <hank303>         VARINT_FIELD(amount)
23:48:59 <hank303>         VARINT_FIELD(relative_offset)
23:48:59 <hank303>         FIELD(tx_hash)
23:49:00 <hank303>       END_SERIALIZE()
23:49:00 <hank303>     };
23:49:10 <hank303> would be padded ?
23:49:22 <hank303> It's a structure I made
23:49:47 <hank303> whereas   struct txin_to_key
23:49:47 <hank303>   {
23:49:48 <hank303>     uint64_t amount;
23:49:48 <hank303>     std::vector<uint64_t> key_offsets;
23:49:49 <hank303>     crypto::key_image k_image;      // double spending protection
23:49:49 <hank303> }
23:49:50 <hank303> is not padded
23:50:34 <hank303> I just have no idea what's going on... If I wrap it in a pragma pack (1) it works, but otherwise i have no luck
23:51:07 <hank303> it's triggering this return
23:51:08 <hank303> return !std::is_standard_layout<T>() || alignof(T) != 1;