01:28:51 > @sech1 jeffro256 for once I agree with ooo123, deprecated methods are not relevant for this PR review. As selsta commented there somewhere, boost 1.59 is still supported in Monero code, so we can use these methods. 01:28:51 We support Boost 1.58+, which means we should work to support newer versions as well, since most people's Boost build is going to be newer than 1.58. We already do this in practice with compatibility macros such as GET_IO_SERVICE, and since @ooo123ooo1234567 is completely rewriting all these connection methods, it should be done correctly THIS time 01:28:57 I know its annoying, and I know that how it was before this PR, but we don't want 2 giant rewrites: "connection: fix implementation" and "connection: fix implementation: fix implementation" :D 01:34:22 > "https://github.com/monero-project/monero/pull/7760#discussion_r889421565", "potentially infinite while loop" potentially shallow comment 01:34:22 This is not a shallow comment because infinite while loops will waste CI build time and slow down feedback. Not to mention if you're running the tests locally trying out somone's new PR who touches the server code down the line and it deadlocks and then you sit there and sit there and then kill it early and then lose debug informatation 01:36:41 Also I'm getting to the "Correctness" soon™, I was just pointing out the glaring surface issues I see 01:40:30 "I know its annoying, and I..." <- It would be better to want working code firstly, before anything else including "glaring surface issues". 01:41:04 jeffro256[m]: 100% you're underestimate hardness of this part, otherwise you wouldn't waste time. 01:41:08 s/underestimate/underestimating/ 01:43:13 "I know its annoying, and I..." <- There will not be even alternative implementation of fixes to added tests. Since my patch is correct and glaring issues are easy to fix, unlike correctness issues in PRs of others. 01:45:04 > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ? 01:45:04 With all due respect, I sense a double standard here in regards to PR #8365. PR #8365 passes all tests, solves a small, but well defined issue, and doesn't introduce any new problems. Of course, it is arguable if it is the BEST solution (I don't think it is). However you called the devs who approved "incompetent" and that they "blindly approved" of it. Yet when people scrutinize your PR, you become rather defensive. Please, it's a 01:45:04 large, complex PR, and I appreciate the work you're putting into it, but you have to be open to some review when the PR is so large 01:46:21 jeffro256[m]: we will close 8365 01:46:53 @selsta Cool 01:47:24 while it is correct, removing the RNG in the first place is even better 01:47:34 > <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/68cf17c8907d56c14267b94f9e51c00d0208e6a4) 01:47:56 > while it is correct, removing the RNG in the first place is even better 01:47:56 +1 01:48:41 All future PRs will be only bigger. 01:50:39 Even bigger than whole p2pool 01:50:41 hahahaha 01:51:59 "Switching away from libuv..." <- But what if I told you there was a Rust libuv with minimal testing and minimal real world usage... but in Rust 👀 01:52:13 /s. Let's not suggest replacing entire frameworks :p 01:52:19 > > <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c023a4be92d1bea0696a424c664f644cd6ec6c80) 01:52:24 all i know is that all current nodes run completely broken ssl code 01:52:34 and it results in bad user experience 01:53:24 Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized, as two infinite loops means you don't even know which triggered (assuming a lack of contextual logs) 01:53:29 > <@jeffro256:monero.social> > > <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/43769c69fe2850e3a27012dc0b7a38ff93abbf5b) 01:53:52 > all i know is that all current nodes run completely broken ssl code 01:53:52 Yeah, firefox will not accept any connections to our nodes over SSL 01:54:08 * If there is at least 1 subjective change not present in old code with side negative effect then write test to demonstrate it. 01:54:12 ooo123ooo1234567: i think with your code it's better but not fully solved yet 01:54:26 kayabanerve[m]: You're talking about code outside of context. You and jeffro256 didn't even try to run test. facepalm 01:54:50 ooo123ooo1234567: Yes. I'm solely commenting on the theory of infinite loops. 01:55:18 kayabanerve[m]: Don't do it. Code can't reviewed outside of context. Should i prove it ? 01:55:22 * prove it or it's already obvious ? 01:55:28 * Code can't be reviewed outside, * prove it or it's already obvious ? 01:55:38 Based on the comment "potential", it sounds like it should never be practically. I'l saying it should therefore have an explicit execution boundary in case: 01:55:38 1) Context of how it's used is changed, as this means we have a context-dependent infinite loop 01:55:38 2) A bug is introduced within itself 01:56:13 It's a harmless change in your case which massively improves development work flow in the worst case. 01:56:46 I'm advocating for more robust development practices. The end. 01:57:21 jeffro256[m]: our code is full of deprecated boost code. if something gets removed we will have to update the code anyway. i don't think adding a large amount of #if is a good idea currently 01:57:27 kayabanerve[m]: How did you make conclusion whether it's harmless or not outside of context ? 01:58:12 If your loop should never be infinite in practice, you should be able to define an execution boundary. Any value outside of that boundary would be harmless yet cover the case where it is infinite. 01:58:28 If you can't define a boundary, you can't say it shouldn't be infinite because you can't say it should be finite. 01:58:33 kayabanerve[m]: context free comment; facepalm 01:59:32 I'm not saying place the limit directly on the boundary. I do understand a practical n=100, yet due to RNG, n may be much higher, yet then set a limit of 1000. We shouldn't be able to flip a coin 10 times in a row and always get tails unless the code is truly that poorly written. 01:59:44 I didn't say there was even a side effect, just that there are a lot of lines which were changed largely for stylistic reasons and not for practical reasons, despite you being such a strong proponent of minimal diffs. In these cases it would not make sense to be defensive of "shallow" criticisms of such changes 02:00:21 jeffro256[m]: if there is no side effect then it's not related to correctness 02:00:22 * is no negative side effect 02:00:33 Context:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/422a6bb38124e69a8e5e1b7492fed6678f5cf977) 02:00:34 * Context:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5adccd1e978cb8fac16c012444686432595d98ef) 02:00:59 > > <@kayabanerve:matrix.org> Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized, as two infinite loops means you don't even know which triggered (assuming a lack of contextual logs) 02:00:59 > 02:00:59 > You're talking about code outside of context. You and jeffro256 didn't even try to run test. facepalm 02:00:59 I have tun the tests? I'm saying that it could very easily become a problem in the future. The entire point of a test is that you are challenging the code. You should NOT assume that it will pass by default 02:01:12 *run 02:01:17 > <@kayabanerve:matrix.org> Context:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/628b61beff385f7727cda1548d36fc335cfcd492) 02:01:18 If you can't propose bounds and successfully add a finite limiter to any theoretical infinite loop, I'll tell you right now it should be assumed infinite, and those aren't acceptable 02:01:30 jeffro256: Your replies are screwed up and it's horrible for everyone D: 02:02:01 > <@jeffro256:monero.social> > > <@kayabanerve:matrix.org> Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/693e4aa4b4d5f2cd5db2800dd5e5e5b06e5ee6ad) 02:02:08 Sorry :/ . What does it look like ? 02:02:21 ooo123ooo1234567: You cannot assume people using your code will know its quirks to the degree you do 02:02:38 You should be able to define code with well established boundaries and expectations and know how to program defensively for when they are exceeded 02:02:51 kayabanerve[m]: can you look into code you're talking about at least ? it's context free comment; facepalm 02:03:09 If this should never be infinite, there should be no issue with a finite limit, and we should be able to move on. If there is an issue with providing a finite limit, you cannot successfully argue it's a safe to deploy infinite loop. 02:03:37 Do you want to link it? It really doesn't matter for the comments I'm making. If it's a potentially infinite loop, I will always have this comment. 02:03:39 one of the large issues tackled in #7760 is *deadlocks* and *race conditions*. These become a problem when you wait on them in an infinite loop 02:04:08 You need a backup condition in cases like this. Multithreaded code is not deterministic 02:04:35 kayabanerve[m]: there is infinite loop; it's just comment from jeffro256 which have even tried to verify; facepalm 02:04:41 jeffro256[m]: It's not actually replying via Matrix yet copying the entire original message and adding > to it to quote it. IRC gets the original message repeated and I got tagged because you replied to a message replying to me, yet your quote re-included my message as well including my nick 02:04:41 * there is no infinite loop; 02:04:50 * there is no infinite loop; it's just comment from jeffro256 which you haven't even tried to verify; facepalm 02:04:52 It may be your client is bugged. If it is, just stop using replies though. 02:05:09 And I don't blame you for it :p Just trying to stop multi-line IRC spam and extraneous pings 02:05:24 ooo123ooo1234567: There isn't one. Great. Then my commentary is void 02:05:26 Using fractal right now, I think it's in beta 02:05:31 noted 02:05:43 You never said there wasn't one. Jeffro commented there was a potential one and I commented on that. 02:05:44 kayabanerve[m]: Are you kidding ? You wasted my time with debate without understanding the context; is it ok ? 02:06:07 You could've just said Jeffro was wrong, and that there wasn't an infinite loop, instead of debating my commentary on the potential infinite loop. 02:06:36 Yes there is: https://github.com/monero-project/monero/pull/7760#discussion_r889421565 02:06:39 Except I do want to hear jeffro256's comment still as I'm not convinced there isn't a potentially infinite loop. I think there isn't one with the context you've created, but... 02:06:40 kayabanerve[m]: It doesn't work with people. I tried 02:06:41 https://github.com/monero-project/monero/pull/7760#discussion_r889421733 02:07:16 jeffro256: That looks like a sleep statement 02:07:41 So I have two comments. 02:07:41 1) That is potentially infinite. 02:07:41 2) Use sleep statements instead of maxing out a CPU. 02:07:52 The "potentially" part comes from calling some logic, then expecting a value to converge on something in the future. And doing a hard wait with no exit condition 02:08:06 You're assuming the rest of the code will successfully trigger those events. If it doesn't, the code is wrong. Your test should say it's wrong, not infinitely loop in wait. 02:08:17 This is not ideal for unit tests and can be easily changed 02:08:24 I'd make it a for loop with an inner sleep. If at the end, that condition still isn't met, panic. 02:08:33 > You're assuming the rest of the code will successfully trigger those events. If it doesn't, the code is wrong. Your test should say it's wrong, not infinitely loop in wait. 02:08:33 +1 you understand 02:08:44 kayabanerve[m]: I really feel like this is the definitive statement which jeffro256 has been trying to communicate 02:08:51 Yeah, still bugged, get a different client :p 02:09:39 in practice i've run this code for 1 year now on multiple nodes, it has been bug free 02:09:56 kayabanerve[m]: infinite loop in case if code is broken, which is not desired state of things. Why does it matter to optimize something for this ? 02:10:07 are you expecting that code will be broken again and don't want to waste time in that test ? 02:10:22 > in practice i've run this code for 1 year now on multiple nodes, it has been bug free 02:10:22 That's good, but it might not stay that way with future PRs and you may just not have hit a snag 02:10:24 ooo123ooo1234567: > infinite loop in case if code is broken 02:10:24 I explicitly said your test should error if the code is broken 02:10:28 Maybe it's better to focus on how to make code correct instead of optimizing test case for future broken code; facepalm 02:10:33 Your have a poorly written test. 02:10:43 Okay I'm getting on a flight so I'll talk later 02:10:53 Also, this is waiting for a condition. If that condition is 50ms away, you'll hammer a CPU thread for 50ms. 02:11:03 If you instead sleep for 10ms, you only make 5 requests. 02:11:20 If that condition should already be met, so this shouldn't need to be a loop, then make it an if statement. If it's not the case, panic 02:11:28 kayabanerve[m]: code with patch will no trigger that test ever again, why does it matter ? 02:11:50 Tests are written on the assumption code is wrong to prove it's correct 02:11:52 you're suggesting polishing of test that reproduce deep problem instead of learning the problem and studying the code that fixes it; facepalm 02:11:59 You're arguing for a test written on the premise the code is correct 02:12:07 That is a fundamental disagreeance with why tests exist which invalidate them 02:12:30 You've spent longer debating this then it would take for you to make your code more robust while reducing CPU utilization 02:13:42 If that condition should already be true, `while (condition);` -> `if (!condition) { panic(); }` 02:13:42 If that condition should be true in the near future, `for (int i = 0; condition; i++) { if (i == n) { panic(); } sleep(x); } 02:13:44 * If that condition should already be true, `while (condition);` -> `if (!condition) { panic(); }` 02:13:44 If that condition should be true in the near future, \`for (int i = 0; condition; i++) { if (i == n) { panic(); } sleep(x); }` 02:13:50 * sleep(x); }` 02:14:57 It's a simple change which makes your test more robust as it now tests for additional error cases it would've previously not brought up, simplifies debugging by explicitly erroring, and reduces CPU utilization (in the second case). 02:15:11 just to summaries: you're debating about minor detail in reproduction for a deep problem that is already solved; you didn't participate in identifying it, didn't participate in fixing it; do you really thing that it's useful to talk about it ? 02:15:17 This should not be a lengthy debate, and you shouldn't have claimed this isn't an infinite loop. 02:15:28 where to start in monero source code? 02:15:33 I literally just sent you a proposed set of modifications as my way to help you fix it 02:15:50 I can't comment on what n/x values you want as I don't know the timing on this. 02:16:22 GnetDotcom[m]: Depends on what you want to do! The GitHub is https://github.com/monero-project/monero 02:16:25 s/thing/think/ 02:17:08 ooo123ooo1234567: So I do hear you saying this, which you briefly brought up in the past yet in a different way. 02:17:12 kayabanerve[m]: I want to understand the code 02:17:14 Will the test be deleted? 02:17:26 in general i think focus should be on getting current code reviewed on correctness, optimizations to existing tests can be done at a later date 02:17:58 selsta: Considering this is solely in the tests, I'm fine with it being merged. I'm more debating the theory around infinite loops. 02:18:12 if the whole code isn't approved yet focusing on minor test cases isn't going to bring us forward 02:18:19 kayabanerve[m]: it isn't infinite loop, read code or run it 02:18:22 it just ends in debate ans it is wrong focus 02:18:25 and* 02:18:31 it's more like synchronization barrier to trigger race condition 02:18:50 I'm willing to walk away from this. Thanks for refocusing selsta 02:18:59 GnetDotcom[m]: Right, yet the question remains, *why* 02:19:34 kayabanerve[m]: sorry, i just want these issues fixed :) and i think these loops aren't a good focus currently 02:19:34 Because it's a very large project and it'll take you a long time to understand every component. Is there a specific bug you want to fix, a specific feature you want to discuss, a specific part you want to work with... 02:19:50 kayabanerve[m]: it's called context free changes 02:20:05 s/changes/comments/ 02:20:08 s/changes/comment/ 02:20:17 selsta: No, no, nothing to be sorry about. It's a pointless conversation created by people who care more about arguing then solutions. Thanks for being the latter 02:21:06 kayabanerve[m]: you and jeffro256 are discussing unimportant test and avoiding to discuss solution; facepalm 02:21:21 s/to/checking/, s/discuss/actual/ 02:22:15 kayabanerve[m]: it would enough for the beginning to check actual code, you've joined jeffro256 without understanding what you're talking about 02:22:18 * it would be enough for 02:22:58 anyway sech1 said he would do a review with focus on code correctness so we should wait on that 02:23:02 selsta: might be good to cleanly document all the things people want to follow-up and fix 02:23:03 "in general i think focus..." <- this isn't even the case of optimization in test; there is no infinite loop 02:23:18 or improve* 02:23:51 UkoeHB: i think to know if this is even something to optimize it requires full code knowledge 02:25:06 that's why we have to wait for a full review 02:26:19 selsta: is it how public talk supposed to work ? everyone is telling without understanding and others blindly agree and shut up those disagree 02:26:31 * up those who disagree 02:27:04 selsta: the PR is never going to get updated unless there is a critical flaw, so you might as well start a list of all the code quality things to PR as follow-up 02:27:07 in the mean finding polite excuses to cover their incompetence 02:27:52 Where is located the PRNG in the source? 02:28:10 GnetDotcom[m]: The PRNG is one from keccak. I'll grab it now for you 02:28:37 src/crypto/random.c 02:29:04 UkoeHB: No. the only 1 important comment from vtnerd was included instantly, everything else will be included only after confirmed correctness, since it's optional and much easier changes 02:29:27 yes, ooo123ooo1234567 already offered to change code style later 02:30:04 UkoeHB: but sure, if anything remains that isn't a microoptimiization we can keep a list. 02:30:09 oh surprising 02:30:42 UkoeHB: there is no value in talking with people that can't firstly done the hardest part before leaving unimportant comments 02:32:05 "selsta: the PR is never going to..." <- with ability to exclude critical flaws it's possible to move very quickly in right direction, but with these unimportant comments even 1 such PR can't be merged 02:32:23 s/merged/verified properly/ 02:32:31 * with ability to exclude all critical flaws it's possible to move very quickly in right direction, but with these unimportant comments even 1 such PR can't be verified properly 02:38:53 "there is no value in talking..." <- You're perfect daemon I presume? 02:45:26 "it just ends in debate ans it is..." <- it's another time when someone is commenting on something without looking into it closely. it isn't wrong focus if others will stop commenting on something without looking into it closely. 02:45:42 > <@selsta:libera.chat> it just ends in debate ans it is wrong focus 02:45:42 * it's another time when someone is commenting on something without looking into it closely. it isn't wrong focus if others will stop writing context free comments. 02:49:23 "anyway sech1 said he would do..." <- there is no need to wait for anything after that 02:49:57 yes, but we have to wait until he gets to it 02:50:12 selsta: who are we ? 02:50:34 * we ? and wait for what ? 02:50:57 well everyone has to wait until there is one full code review (e.g. done by sech1) 02:56:53 "Your have a poorly written test...." <- define measure of poorness, It would be interesting to compare it across different tests 02:58:05 "https://github.com/monero-project/monero/pull/7760/files/925c0364d2d8823132cda8cdc84619828c8e4607#r889636515", what's the reason to add any sleeps if correct should run as fast as possible ? it will be redundant and will slow down test with arbitrary sleep constant 02:58:13 you clearly don't understand the context 02:58:33 ooo123ooo1234567: I appreciate the PR. This is a minor nitpick about the test which isn't important. While I maintain all my theoretical commentary on infinite loops, I don't feel a need to debate this further. 02:58:36 I have no questions to your comments in general, but in that particular context it isn't right 02:59:27 kayabanerve[m]: I don't have questions to your theoretical opinion about infinite loops, it may be even equal to mine. 02:59:29 I already said I was fine moving on, this shouldn't be considered a blocker, and the discussion serves more to argue due to our struggles communicating than to accomplish anything. Dragging me back in after I've made all these statements is pointless. 03:00:22 kayabanerve[m]: If it's fine to move on, then don't add into the last reply something like "I think opponent is completely wrong, but I will not continue". 03:00:37 I said people, not you. 03:00:46 I acknowledged my own faults. 03:00:57 But when you drag me back into this, then yes, it is you specifically 03:01:25 *I said people in my original message walking away from this when I deferred to selsta's accurate dismissal. 03:02:11 kayabanerve[m]: without some conclusion it isn't clear even who is right or wrong, maybe it's me who wrong. But since you added supposition into your last reply, I've replied that it isn't true. 03:02:47 The only thing I said in the message you replied to is that dragging me back in was pointless because we settled this 20 minutes ago. 03:03:26 I also tried sending you a message privately to give my opinion on your communication, as I have before, because it seems a lot of people believe your skills there are much lower than your skills as a developer. I tried to reach out, in a non public setting where we wouldn't spam monero, and further acknowledged your talents and that this nitpick shouldn't be a blocker. 03:04:15 You can do whatever you want in this channel (including pinging me on old conversations). I'm truly done here for tonight. Feel free to reach out privately, where we don't damage this channel with off topic discussion. 03:04:41 kayabanerve[m]: acknowledge through achieved objective goals is more than enough for me, I don't expect anything from others. It isn't even clear who is better without explicit competition. 03:24:58 where is the BIGINT library? 03:25:15 * BIGINT library located in source? 03:45:29 GnetDotcom[m]: in general you can use `git grep` to find things 03:45:40 in the codebase 04:36:15 is there a backup source of entropy other than "CryptAcquireContext()" in src/crypto/random.c ??? because it might get outdated any date (https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontexta) 04:38:33 s/outdated/removed/ 06:37:54 There almost certainly is. They'd be really dumb to remove access to entropy without a replacement. 06:49:34 "is there a backup source of..." <- This API is deprecated. New and existing software should start using Cryptography Next Generation APIs. Microsoft may remove this API in future releases. 06:52:51 Feel free to file a bug about this btw, so someone can add code to use the new one. 07:25:19 hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 07:35:44 "hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii..." <- hi 09:18:57 what is CheckLinkerFlag.cmake? 09:20:06 i have never seen a code like Monero 09:20:10 really interesting 09:22:10 i think things i have to link correctly are libsodium and boost with libwallet_merged.a 10:02:40 how should i use Monero source in my CMake configuration? 12:12:35 Hello! I had a very specific question, if monerod is running from an ssd, does that ssd need 256-bit AES hardware-based encryption as some ssds lack that? Or would you insist my SSD have that feature? SSD is running on linux. Are there any dependancies in the Monero protocol that rely on 256-bit AES hardware-based encryption or can I use an SSD 12:12:35 without that safely? 12:18:45 It is not needed. 12:19:10 It is recommended that you encrypt your filesystem, but how you do so is your own business. 12:19:24 Monero has no idea whether your filesystem is encrypted in the first place. 12:19:53 monerod does not encrypt the chain itself, but monero-wallet-cli will encrypt the wallet data. 12:20:26 If mining (or verifying PoW), you'll want a CPU that has hardware AES if possible. Maybe you confused the two ? 12:21:24 In general, I would not trust a disk's encryption myself, I'd use software encryption (ie, dm-crypt). 12:21:50 In any case, encrypting's one filesystem is recommended. 12:22:20 I see, thank you for answering that. No, I understand that some CPU's have hardware AES (mine does), and SSD's most do have hardware AES but are expensive. The SSD is was looking at, not for mining, but for running a full node via monerod only. I will look into dm-crypt. 12:23:14 Since hardware level encryption is not necessary for running a node, I will be able to use a relatively inexpensive ssd which is still quite fast. 12:23:55 As a follow up question, in this instance running monerod, are there any read/write bandwidth recommendations? 12:24:13 Yes, as much as you can get. 12:24:32 monerod does a LOT of random acccess reads and writes. 12:25:26 At least for the initial sync. After that you should not have any trouble keeping up, but still. 12:27:43 I understand, thank you for confirming that. I was essentially tageting a minimum random read speed of 240000 iops and random write of 500000 iops 12:29:18 Also for capacity and performance, the most expensive 250gb with decent read/writes are the same cost as a 500gb which outperforms it, making more sense 12:30:16 I have been looking at 250gb for running a full node, but am debating weather to switch to 500gb as standard simply for the performance gain (capacity increase being incidental) 12:30:41 Wonder what recommendations you would have about minimum capacity 12:31:45 Considering that TBW (terabytes written) is also a concern 12:32:23 as well as the increasing blockchain size, efficient as it is 12:32:39 The chain's something like 140 GB IIRC. Or 47 GB pruned. 12:32:58 I don't have a size increase rate to offer. 12:33:08 Yes, I am aware. I am also estimating a growth of 40GB per year in my calculations 12:33:37 Not sure how accurate that might be 12:34:48 In any case cost is still a concern, and with significant perfomance gains with negligeble incremental costs from 250GB to 500GB, my thinking a switch to 500gb might be justified 12:36:21 Anyway, you may want to continue in #monero. You're in #monero-dev, which is for monero development. 12:37:14 Oh right, sorry about that. Thank you for answering my questions 16:06:42 i think i found static libraries that i should link 16:08:17 libwallet_merged.a, libepee.a, libeasylogging.a, liblmd.a, libunbound.a, libboost_serialization.a, libboost_thread.a, libboost_system.a, libboost_date_time.a, libboost_filesystem.a, libboost_chrono.a, libboost_program_options.a, libboost_regex.a 16:12:14 Might also need openssl. 16:33:42 moneromooo, yesssssss 16:33:45 and zlib 17:00:17 g++ -std=c++14 src/monero_api.cpp $(find ../monero -regex ".+\.a" -printf "%p ") -o monero_api.exe 17:00:18 im doing this 17:00:51 i have to make it correct order but 17:01:09 im curious about libsodium 17:01:37 Yeah, take it with a grain of salt. 17:02:23 there is no anyting for libsodium in Monero build 17:02:37 is that included in Monero static objects? 17:03:58 * moneromooo goes git grep sodium 17:04:43 I found it. There is something for libsodium in Monero build. 17:05:14 you mean static objects??? 17:05:23 im looking for .a extension 17:05:40 If you need that and you don't have it, you'll need to build it. 17:05:54 kayabanerve[m]: there is also boost multiprecision for uint128 17:06:30 Doh. I was thinking "there's no bigint code in monero..." and I forgot this one -_- 17:06:49 Thanks for the heads up. I'm honestly not sure where that's used, unless it's the difficulty code. I was aiming to give an answer comparable to ethereum 17:07:05 Technically the block hash is considered an integer when checking difficulty 17:07:06 due to tail emission, the total supply can exceed 2^64 17:07:14 And scalars/field elements are just really big integers :D 17:07:16 moneromooo, okiiii 17:07:39 UkoeHB: Also true, yet not currently coded in monero 17:07:47 In fact, I'm pretty sure the node will panic before then 17:07:58 It explicitly has a max blockchain height iirc 17:08:09 kayabanerve[m]: moneromooo updated it a couple years ago so there's no overflow (the block reward part I think( 17:08:21 That's WAY in the future (the block height hitting max). 17:08:26 To think we coded in planned obsolescence and 2022 nodes won't work in 2200 :( 17:08:51 I'm reasonably sure it's more like tens of thousands of years at least. I looked long ago. 17:09:04 moneromooo: Idk, doesn't seem scalable. Will the gw basic rewrite make this a priority? 17:09:12 (less than tens of thousands of years ago) 17:09:33 I think we can easily justify an extra 10% in funding if so. It's our future! 17:09:47 But yeah, absolutely not a concern in practice :p 17:10:41 Also, while I updated the thing to handle large supply, I wouldn't bet my life there are no bugs. There's always one more bug. 17:31:14 g++ -std=c++14 src/monero_api.cpp ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/contrib/epee/src/libepee.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/easylogging++/libeasylogging.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/db_drivers/liblmdb/liblmdb.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external 17:31:14 /unbound/libunbound.a -lsodium -lboost_serialization-mt -lboost_thread-mt -lboost_system-mt -lboost_date_time-mt -lboost_filesystem-mt -lboost_chrono-mt -lboost_program_options-mt -lboost_regex-mt -o monero_api.exe 17:33:00 https://pastebin.com/hwcfKbNh 17:33:15 im getting these linker errors :(((((( 17:38:56 added more libraries 17:39:01 undefined reference to `randomx_dataset_item_count' 17:39:48 Jesus... git grep, or copy the link line as I said yesterday. Pull your weight. 17:40:59 moneromooo, :(( i don't understand what should i loook for in git grep? 17:41:16 g++ -std=c++14 -fstack-protector src/monero_api.cpp ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/contrib/epee/src/libepee.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/easylogging++/libeasylogging.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/db_drivers/liblmdb/liblmdb.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok 17:41:16 _/release/external/unbound/libunbound.a -lsodium -lboost_serialization-mt -lboost_thread-mt -lboost_system-mt -lboost_date_time-mt -lboost_filesystem-mt -lboost_chrono-mt -lboost_program_options-mt -lboost_regex-mt -lssl -lcrypto -lz -lwsock32 -lws2_32 -o monero_api.exe 17:42:32 undefined reference to `cryptonote::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&)' 17:42:42 i have cryptonote objects 17:43:02 In a loop, if you get an undefined symbol S, git grep "S". If it's not a monero one, search on the web for which lib it's from. Add lib. Repeat. 17:43:13 cryptonote_basic/libcryptonote_basic.a, cryptonote_basic/libcryptonote_format_utils_basic.a, cryptonote_core/libcryptonote_core.a, cryptonote_protocol/libcryptonote_protocol.a, 17:43:26 Or, as I said, look at what libs monero-wallet-rpc links against, and use that list. 17:43:54 And make sure it's in the right order (that is a pain in the ass). 17:44:10 randomx_dataset_item_count thing is coming from a library called as "librandomx" 17:44:22 Right, you're doing it good now. 17:44:49 im googling names found everything but librandomx looks like not a common thing 17:44:52 i need to build it 17:44:58 because there is no a MSYS2 package 17:45:04 It's in monero. git grep, again. It's in external, this one. 17:45:17 oh okii but 17:45:37 i need to do something to have its object file right? 17:45:45 Yeah. Build monero. 17:45:56 i already built 17:46:04 im looking at *.a files 17:46:13 but there is no anything like librandomx 17:46:27 ohh foound 17:47:41 undefined reference to `google::protobuf::internal::WireFormatLite::UInt32Size(google::protobuf::RepeatedField const&)' 17:47:44 google???????? 17:47:58 I'm *not* googling that for you. 17:48:26 Didn't know we used protobug though 17:48:33 lol, nice typo. 17:48:51 https://packages.msys2.org/package/mingw-w64-x86_64-gtest 17:48:56 Oh, that's probably trezor. You might want to configure without it. 17:49:00 https://packages.msys2.org/package/mingw-w64-x86_64-glog 17:49:02 protobuf?? 17:49:03 looking 17:49:31 installed 17:50:18 gooood libusb 17:52:01 hidapi 17:52:04 this thing 17:52:12 unbelievable 17:52:22 third party things are making me crazy 17:54:41 < moneromooo> Oh, that's probably trezor. You might want to configure without it. 17:55:19 (trezor is a hardware wallet, support is optional) 17:55:44 (unless you want it ofc) 18:08:26 i should find the correct order of cryptonote libraries 18:12:25 damnnn 18:12:36 tooo few undefined reference errors 18:12:43 undefined reference to `__imp_CertFreeCertificateContext' 18:14:58 undefined reference to `GetNetworkParams' 18:15:01 only this left 18:16:01 i can't believe 18:16:03 it is done 18:16:06 built 18:17:00 https://pastebin.com/QC4EqWmP 18:17:10 build command 18:19:54 this is unbelievable 18:20:00 damn static libraries 18:20:44 i think it would be easier with seeing build commands doing by build system 18:21:13 now it is time to codeeeeeeeeeee 18:26:22 VERBOSE=1. Did I not say that yesterday ? If not, I hould have :) 18:26:33 Otherwise, ^Z while it links, ps. 18:26:59 Monero::WalletManager::recoveryWalle() wants a "path" 18:27:02 what is that? 18:27:11 moneromooo, thank youuu 18:28:10 A path is a string of directories, separated by / 18:28:30 ohh damn a filesystem path? 18:28:32 So either the path to the wallet file, or to the directory the wallet's in. 18:28:34 for what? wallet data? 18:28:43 i don't want it 18:28:58 What else. recoveryWallet ain't about an jpeg file is it. 18:29:13 i have private seed 18:29:24 im using the same private seed for ETH and BTC 18:29:54 it is encrypted and stored in Godot's abstracted resource filesystem 18:30:10 i just need to recover wallet from seed 18:30:19 and build/sign a TX 18:30:30 If you do not want to store that wallet in a file, you can pass "" IIRC, and it'll keep it in memory. 18:30:44 I added that for tests mostly, but it works also outwith tests. 18:30:51 i will use libwallet for only TXs because i already implemented key derivations in C# i will use it 18:33:11 Monero::Wallet* w = wm->recoveryWallet("", "..."); 18:33:16 im doing this 18:33:38 butt std::string result = w->mainAddress(); is causing SIGSEGV :(((((((((((((((((((((( 18:34:47 I assume you were taught about checking for errors ? 18:35:11 Like, returning NULL... 18:35:20 ummmmmmm 18:35:21 you mean 18:35:27 w is NULL? 18:35:38 Oh, good point! It might be! 18:35:49 i didn't think thattt 18:35:54 Monero logs various things, if you ask for them. 18:36:00 i can't use my debugger for Windows 18:36:06 because it doesn't support Windows :((((((((((( 18:36:11 OK, maybe monero is a bit too advanced for you then. 18:36:12 i will use VSCode 18:36:24 here https://github.com/rohanrhu/gdb-frontend 18:36:30 (set MONERO_LOGS=2 and you'll get logs) 18:36:31 you can use it on Linux for Monero development 18:36:34 (an env var) 18:37:48 if you have specific feature requests for Monero debugging tell meeeeeee 18:38:34 Fixing the logged stack traces. They tend to stop being useful and output just addresses, not symbols. 18:39:00 That could do with being more dependable. 18:39:37 ummmmm wdym with logged stack traces??? 18:41:16 nvm 18:42:35 ohh you mean GDB shows only function addresses for stack traces? 18:43:58 my debugger has more features than usual things 18:45:21 i will do Windows support too buttttt i have to implement async mode for GDB on Windows 18:45:33