04:53:29 jberman On your CSS proposal, you said that you were going to look into #7999 about serialization/storage? I'm working on a PR which addresses the same issue as #7999. I just wanted to let you know that that is in the works and wanted to know if you have written any code regarding said problem 07:56:12 selsta: done 08:43:35 jeffro256: I haven't started digging into the PR at all yet. vtnerd has a clean looking alternative here that I also anticipated reviewing: https://github.com/monero-project/monero/compare/master...vtnerd:monero:replace_p2p_serialization 10:35:04 jeffro256[m]: what are you working on exactly? since we already have 2 rewrites a third one might not make sense 12:47:44 is the burnt amount provided or handled anywhere else besides the overall balance and on_money_received() notification? for example, can a monero-wallet-rpc client check for burnt funds in a tx, without receiving the native output notification? 13:03:08 Only the former AFAIK. 13:03:36 Though technically you could get incoming_transfers and sum/compare yourself, so you *can* get at the info in theory. 14:03:43 > jeffro256: I haven't started digging into the PR at all yet. vtnerd has a clean looking alternative here that I also anticipated reviewing: https://github.com/monero-project/monero/compare/master...vtnerd:monero:replace_p2p_serialization 14:03:43 Interesting, I didn't see that one, I'll definitely take a look. @vtnerd is it ready to be merged now (pending review)? 14:05:40 > jeffro256: what are you working on exactly? since we already have 2 rewrites a third one might not make sense 14:05:40 It solves the same problem as #7999 (faster (de)serialization with no DOM), while being a lot cleaner and being more extensible (similar to vtnerd's monero-lws wire module) since it takes a lot of inspiration from Rust's serde framework 14:07:06 I would need to look more into @vtnerd's PR but unless it does more than what I think it does, my PR does the same thing in about half the lines. I'm definitely going to benchmark it though 14:08:01 Also my PR wouldn't need to touch the `BEGIN_SERIALIZE_MAP()`, `KV_SERIALIZE()`, `END_KV_SERIALIZE` pattern 15:10:52 jeffro256[m]: 7999 has some benchmarks 15:21:45 afungible[m]: LMDB enforces uniqueness on keys. You cannot find two identical key images in LMDB because it would return an error when trying to store the 2nd one, and monerod would indicate a double-spend attempt 15:24:43 hyc: Thanks for the good explanation. 15:30:36 stagenet forks in 3 blocks 15:45:39 my patch has comments + boilerplate interface which blows up the line count a little 15:46:24 the interface allows you to chosoe between smaller binary size or de-virtualization with a slightly fatter binary 15:47:01 otherwise the number of lines actually doing stuff should be relatively small 15:47:13 the PR is basically ready for review, but perhaps could use more testing 15:47:35 unfortunately there's no framework (in either PR) that tests compatability with every command 16:33:23 "the interface allows you to..." <- Ooh choice between virtualization and devirtializion is cool 16:33:28 Is that what the MODE selector is ? 16:34:21 Also it seems like you’re trying to combine wire serialization interface with the boost serializatik interface 17:56:22 Heyo! 17:56:44 How can I help? 17:56:56 I don't know math or very good at programming though 17:57:36 go practice both and get good first ;) 18:02:27 oh, k 18:03:14 probably join #monero-community and help out there, anybody can jump right in 18:03:59 eternal[m]: you can also look through the issue tracker, maybe you'll find something that looks doable 18:08:39 selsta: on github? 18:08:56 yes 18:12:40 nope, realized all tests are writen in python but the blockchain is c++ 18:12:44 i only know python 18:12:49 lol 18:14:18 Tests are always good to have. 18:15:42 Or you could try contributing to the python monero lib, probably somewhere on github.com/monero-ecosystem. 18:19:48 moneromooo: oooh! 21:10:13 jeffro256[m]: yeah its a combo of a couple different serialization libraries really 21:11:26 selecting between virtualization and de-virtualized is a bit manual but there might be a way to improve it 21:12:09 theres a macro for header and cpp that can be changed - two for generic, and then two for each format type 21:13:02 the fields only have to be listed once because the macro forwards to a templated function ... if the concrete type is used the compiler definitely de-virtualizes all calls due to `final` keyword on class 21:13:32 the style is probably closest to epee, since its replacing that functionality iwthin boost 21:14:24 the downside of that de-virtualization is that each format type is a template expansion, which is a unique expansion in the object-file-binary 21:14:52 for p2p stuff you just mark everything as `epee` format since there is no other format being used 23:37:23 > the fields only have to be listed once because the macro forwards to a templated function ... if the concrete type is used the compiler definitely de-virtualizes all calls due to `final` keyword on class 23:37:23 I definitely copied this aspect from the wire module within my version. I always put `override final` on everything applicable and trust the compiler with the rest. SO it looks like OOP architecture wise but any dumb compiler can devirtualize 23:55:31 .merge+ 8465 8466 23:55:31 Added 23:55:34 .merges 23:55:34 -xmr-pr- 8299 8323 8352 8359 8379 8415 8419 8427 8428 8442 8444 8450 8451 8454 8465 8466 8483 23:55:40 luigi1112: ^^^