00:05:37 linking 00:05:46 monero-wallet-rpc.exe 00:06:12 why GNU ld is very slow for this??? 00:07:34 use linux :D 00:08:29 it's a MinGW issue?? :( 00:08:39 i was a Linux cat in past 00:08:46 now im a Windows cat 00:09:40 why does monero-cpp need to build these things??? 00:09:50 monero-wallet-rpc.exe and more? 00:10:20 it does a full build 00:10:34 but i don't need them 00:10:46 compiling and linking take so long time :( 00:11:16 i really don't know what is GNU ld doing rn... 00:17:16 then only build the pieces you need 00:20:43 the issue 00:21:24 isn't monero-cpp a library to develop something with Monero features? 00:21:41 why is it building these? 00:22:53 you are doing a full build so it's also building everything 00:23:30 probably i will use monerod.exe right 00:23:32 butt 00:23:52 i could already have that 00:25:43 make sure to read through the full readme, you need the libwallet.a 00:27:59 is there pre-builds of that?? 00:32:20 [ 96%] Linking CXX executable ../../bin/monero-gen-trusted-multisig.exe 00:32:20 make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug' 00:32:20 [ 96%] Built target blockchain_prune 00:32:20 [ 97%] Linking CXX executable ../../bin/monero-wallet-rpc.exe 00:32:20 make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug' 00:32:21 [ 97%] Built target gen_multisig 00:32:23 make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug' 00:32:25 [ 97%] Built target wallet_rpc_server 00:32:27 make[2]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug' 00:32:29 make[1]: *** [Makefile:146: all] Error 2 00:32:32 make[1]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug' 00:32:34 make: *** [Makefile:84: debug-static-win64] Error 2 00:33:49 please use a paste website 00:34:08 sorry i thought it is short 00:34:31 it is short because you didn't post the error :D post the full log and use e.g. paste.debian.net 00:34:42 yesss doing that rn 00:35:20 http://paste.debian.net/hidden/89a2a215/ 00:36:02 did you sure that you checkout master branch? 00:36:06 which commit exactly? 00:36:10 i didn't 00:36:13 i tried master branch 00:36:18 there was an error 00:36:29 you have to apply https://github.com/monero-project/monero/commit/026dbc89bfff64ce0f89b780843a9ffc013600b9 00:36:31 i just casted a variable and fixed 00:36:48 monero was building but monero-cpp not 00:36:51 then i thought 00:37:05 i should checkout monero-cpp/v0.7.0 00:37:08 let's continue in #monero 00:37:17 it is v0.7.0 rn 00:37:25 okii 02:04:02 Height: 1382556/2632662 (52.5%) on mainnet, not mining, net hash 159.15 MH/s, v5, 12(out)+0(in) connections, uptime 0d 14h 51m 43s 02:04:18 can somebody just mail me the full node? lol 02:07:26 lousiF: do you have an SSD? and do you run the lastest release version? 02:07:36 yes and yes 02:08:56 my node was from an older backup, and I don't think I pruned it right. Decided to just re-download it with --prune-blockchain 02:10:52 running slow 02:12:39 which OS? 02:12:56 buntu jammy now 02:13:51 ok, sounds a bit slow for an internal ssd 02:14:11 it's the ISP 02:14:55 or something with peers. regardless it's gonna take days lol 02:17:00 2022-05-28 00:41:47.402 I [***.222.***.***:18180 OUT] Sync data returned a new top block candidate: 1382556 -> 2632999 [Your node is 1250443 blocks (4.8 years) behind] 02:17:00 2022-05-28 00:41:47.402 I SYNCHRONIZATION started 02:23:45 Received 22961838504 bytes (21.38 GB) in 4601667 packets in 15.2 hours, average 409.85 kB/s = 81.97% of the limit of 500.00 kB/s 02:23:45 Sent 68626586 bytes (65.45 MB) in 55980 packets in 15.2 hours, average 1.22 kB/s = 0.24% of the limit of 500.00 kB/s 02:24:16 have to cap it at 500kB/s or else no internet. 02:25:50 lousiF: Why? 02:26:17 I'm on a DSL connection on the edge of the North American continent. 02:28:07 and if I can't just hog all the bandwidth, it's about half-ish 02:28:14 -if 02:44:21 just an idea/request. I'm impatient, and just mailing it would be faster than downloading the entire thing. I think lots of other people could use the same assistance. 03:01:30 "just an idea/request. I'm..." <- Its not a peer problem if its using 80% of your 500kb/s limit. 03:01:31 Can always check sync_info to see if you have a queue of blocks waiting to sync. If so, the bottleneck is the computer. 03:01:31 Or you can add the flag --sync_pruned_blocks to download prepruned blocks (I imagine should speed up the sync, though I havent used it myself) 03:01:31 #monero:monero.social is a better place for this 03:02:10 I have the output here. don't want to flood 03:02:36 Dm 03:05:04 it's the ISP. it's slow as shit. lol. it is like tin cans and string out here 03:50:23 what is the C++ standard of monero source??? 03:51:09 MeowingCat: c++14 03:51:14 okii 03:53:01 https://pastebin.com/qT9Ge28f 03:53:04 im getting these errors 03:53:17 g++ -std=c++14 -I.\monero\monero-project\src\ -I.\monero\monero-project\contrib\epee\include\ -I.\monero\monero-project\external\easylogging++\ -I.\monero\monero-project\external -I C:/msys64/mingw64/include -o main main.cpp .\monero\libwallet_merged.a 03:53:26 my GCC command 09:29:13 Hello, I was wondering is there a reason that the Daemon/Wallet JSON-RPC API is not managed via OpenAPI / Swaggerhub? Would bring huge advantages like versioning, or am I overseeing something? Would gladly help to set up something like this 09:49:16 Same reason it doesn't use any lib it doesn't currently happen to use I guess. 09:50:39 The more invasive changes you want to do to rewrite something, the beter arguments you have to have for why it'll improve monero. 09:51:18 So, first tell us how invasive this'd be, roughly. And second, what the improvements will be (this includes new drawbacks). 09:51:50 If it turns out to be another "rewrite so I like it better that way", it'll be "thanks, but no thanks". 10:08:56 Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6021b31daeb0801fc60d69c98f3fb58f3f0c97bb) 10:09:42 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/402dbfef30c7f040dc1d6b38dc9e353f9a8f3c56) 10:09:56 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/53b61dfcb5138503ff7d48b04f712b7d7903845b) 10:11:21 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/93b962a6fc3138f320bbfcef8e5cb77c6ee8ea70) 10:11:31 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/719f98a58d30426920b3428f9ccfcad896e6cc3c) 10:13:07 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c4ae06ad41bf89ebe5e3448a8317745bfb35cb33) 10:16:10 Example can be seen here how something might look like: https://petstore.swagger.io/ 10:16:23 s/something/this/ 10:18:03 s/something/this/, s/petstore/editor/ 10:18:27 Note that past major versions of Monero are not compatible with the current network - so when a major version is rolled out, any breaking changes in the rpc api would be "mandatory" too, and the old version would be lost anyway 10:18:47 (Unless the majority of the network rejected the update, for whatever reason) 10:21:28 That is true, but it would still be nice to have this information anyway, you never know when you might use it 10:21:39 * Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/1dbf0b421b517e01bf6a214cb9925713b45ea8b4) 10:40:47 Would anyone be willing to look at https://github.com/monero-project/supercop/pull/9 ? It's a super quick warning fix 10:44:20 Can you please avoid spamming the same over and over ? That's what matrix does when you edit a line. 10:44:49 Also, your comments ends up cut off, and links to a site to see it. 10:45:03 Me ? 10:45:16 No, jonas1423[m] 10:45:21 More documentation is always good. 10:45:43 * moneromooo spins up vm to go read that link 10:47:28 jonas1423[m]: what is a swaggerhub instance ? It smells like needing some third party. 10:48:38 I mean, we all need third parties. Like GCC. But this looks like a third party which, if it goes, takes our stuff with it. Correct me if I'm wrong, it just reads like it (I never heard of "swaggerhub" before). 10:49:35 The RPC documentation has always lagged and often been incomplete. Fixing this would be nice, but does swaggerhub make it easier to update somehow ? If so, how ? 10:50:17 And I don't mean some automated process that sees I added "uint32_t x; KV_SERIALIZE(X);" and writes "x: 32 bit integer" in the doc, that's useless. 10:52:13 About code generation, do you mean auto generating bindings, like what's in utils/python-rpc/framework, without having to do it manually ? That'd be useful. 10:53:28 Does versioning mean "bumping a version number" or "keeping historical RPC versions" ? If that former, we already have that. If the latter, surely it cannot be automatic since the behaviour of the code that handles the RPC changes. What does it do to help here ? 10:53:35 > About code generation, do you mean auto generating bindings, like what's in utils/python-rpc/framework, without having to do it manually ? That'd be useful. 10:53:35 Yeah, I've never seen it before, but it looks like if you describe the JSON RPC interface it will automatically generate a client API for a bunch of different languages 11:03:10 "Can you please avoid spamming..." <- Sorry not used to matrix/element,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ce6a3ac6e4ecc5c5b020c3999c4fa30b1fa11690) 11:03:14 I think something like this would be very good. Maybe there is something like swagger that works well with cpp. the documentation of the wallet rpc is badly out of sync with the code. For example the signing with subaddresses is not mentioned in the docs, but it is actually possible: https://old.reddit.com/r/Monero/comments/uv01ip/how_monero_solves_all_the_privacy_problems_in_web3/i9ryrql/?context=3 11:04:34 spirobel[m]: Yes, thats exactly why something like a swagger-editor would be nice, the documentation on there would be the the single source of truth / the contract, if you change something there, you generate code that automatically (almost completely) adhere to that contract 11:06:07 jonas1423[m]: so the question to figure out: can we make swagger work with cpp? is there a plugin. And if that is not the case: is there an alternative that is similar to swagger that works with cpp. 11:06:23 s/./?/ 11:08:37 spirobel[m]: You can try it out on this site https://editor.swagger.io/ under Generate Client / Server -> cpprest and look at the generate models. I cannot tell you if that generated code is usable because I am not a cpp developer, but at least it is supported. 11:09:18 So... if still requires someone to write the doc. Just in some web browser instead of another editor. 11:09:49 Keeping old RPC versions could be interesting from time to time, but usually isn't. Most RPC stay backward compatible. 11:10:33 The code generation thing seems to be the one advantage I think. 11:12:16 moneromooo: as I understand it swagger is written as a comment with @swagger in the source code. So the source code and the comment right next to it is the single source of truth. From that the docs website is derived ( where you can autogenerate the api consumers etc) 11:12:48 Oh, like doxygen (which usually results in placating boilerplate) ? 11:13:49 I mean, if the issue is people (well, mainly me) not documenting things, adding this won't fix it, will it. 11:14:15 moneromooo: I dont know if I would call this placating boilerplate. It is helpful to have a way to automatically generate api consumers. 11:14:36 moneromooo: I have used doxygen like one or two times but I think that are completely different things 11:15:08 moneromooo: I mean it is just adding a comment above every api endpoint to state what variables it expects and what they mean. I dont think that is too much to ask. 11:15:42 It's not documentation it's specification, you write the api, generate code (the models, the single source of truth) and write your consumption / providing of this API 11:16:28 spirobel[m]: it is irrelevant. 11:16:57 This tool relies on the doc being written already, if I read the above correctly. 11:17:10 The doc is not written currently. Therefore adding the tool will not help. 11:17:10 moneromooo: yes 11:17:44 If you're going to say "if we add the tool, people will suddently start writing documentation", then... maybe, but why do they not without the tool ? 11:17:47 jonas1423[m]: I think you can go about it multiple ways, right? you can write the server code and add the comments there and then client code and specification of the website is generated from that. Or you write the specification in yaml and then generate client and server code from that. In our case server code is already written. So just adding the comments is probably the right approach. Just a guess. 11:18:28 Anyway, this is my opinion so far. If others want this, it'll go in. 11:18:45 spirobel[m]: I have only seen it in the one direction (spec -> server/client) and not the other way around, but if it works sure 11:19:22 I have used open api before to generate typesafe clients for a http service - it is very useful. However, IMO there should be a seperate project which maintains the open api definition, and perhaps generates clients for various languages as part of a ci action... 11:21:04 do you guys think there is maybe a slow way to move into this? maybe just add one of these comments for one api endpoint and see if it works? It does not need to be done all at once. Even one comment is a step forward. 11:21:54 moneromooo: If we go this further down this road, we are closing the doors for new developers that want to consume the daemon/wallet api and build monero applications, that is the real reason I am proposing this here. For example if someone wants to create a new Wallet-GUI on top of the daemon-rpc 11:21:55 at the moment in c# i have a very basic program which reads the rpc header files from github and generates the models - but i've seen projects which parse C++ code into an AST which you can then run a script over to grab the models, that way it's always in sync with the codebase 11:22:35 but instead of emitting c# code (which i have it do atm) you can generate the api definition 11:23:23 What we could try is the following:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7affb82b9ac6ef0332ba852944f82a45ccf9add6) 11:25:56 > <@jonas1423:matrix.org> What we could try is the following:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2c73ea1165a4905b0be2f1fa0761ce1fb06b1b5b) 11:26:28 spirobel[m]: I can try to transfer the code to the api-specification 11:26:54 I am not a cpp developer but I am bored and want to try :D 11:28:03 jonas1423[m]: but can you continously do that? because the code will change so your api-spec will be out of sync at some point. you dont need to be a cpp dev. You just need to add some comments to the code if you want to try this. 11:30:46 https://github.com/HennyH/monerobot/blob/main/src/MoneroBot.WalletRpcGenerator/RpcHeaderParser.cs 11:30:46 https://github.com/HennyH/monerobot/blob/main/src/MoneroBot.Xmr/Models/Generated/Models.cs 11:30:46 the monero source code for RPC is so well structured even primitive regex approach (like used here) can get the models out okay, something like (https://github.com/xoofx/CppAst.NET) would be more robust - from there just need to adapt to emit open api sepc 11:32:19 That's the problem, I can set it up initially, but then every time a dev adds a new piece of code to the public API, he should additionally add the open-api comments for that. OR we change the source of truth from code to spec at some point. What I want in the end is that everyone can build up new monero applications on top of the wallet/daemon rpcs easily 11:33:57 jonas1423[m]: I dont think the source of truth can change from code to spec. Probably best to add comments. or do the parsing thing by Henry Hollingworth 11:39:02 Yea, also writing the openapi-comments to public-api can be enforced by pipelines. As I said no matter the approach (source of truth code or openapi-spec) I can help set it up initially, as long as we have a feasible, correct documentation in the end. I will go off for a few hours, let me know if I can help with anything 11:48:13 Putting effort into making open api spec makes a lot more sense than everyone duplicating that effort to make a wrapper in each language which can easily fall out of sync etc.. vs write once and generate the really good tooling around it 11:53:03 jeffro256[m]: that s/64/85/ thing looks really odd. Why do you need this, if the extra isn't used ? 11:53:23 (it's not immediately obvious why after looking at the code) 11:54:21 I assume sc25519_window4 can use more in some cases, but never when called from that ? 11:55:45 (it doens't AFAICT, I just looked) 13:39:25 > <@jonas1423:matrix.org> Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: https://www.getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a0af73a26a1e21abd7bb0877f831ed1fffaf6536) 15:07:50 > jeffro256: that s/64/85/ thing looks really odd. Why do you need this, if the extra isn't used ? 15:07:50 Because GCC is strict about buffer overflows and will generate a warning message if size of a passed array isn't actually the full size as the array parameter. 15:11:04 I do not see why this applies here. The function takes 64, it's passed 64. 15:11:58 You're talking about b, presumably? 15:15:17 Yes, the applicable definition is in crypto_sign/ed25519/amd64-64-24k/sc25519.h line 59 15:16:16 I think the amd64-51-30k version only takes 64, but amd64.c.inc should just use the one that is greater 15:16:21 Oh. I see. 15:16:36 I looked that C file, which has 64 (and doens't seem to use above that). 15:18:34 I assume there's some cpp cleverness to redirect to another function that actually uses 85 ? 15:18:36 So should the definition be changed? 15:19:22 Well, I assume something uses up to 85 now that you pointed it out. 15:19:47 I just don't see what, but I don't really want to go through the cpp rabbit hole :D 15:20:23 At first glance, the prototype just looks wrong. But it's more probable I'm wrong. 15:21:58 git doens't even help, it's been 85 forever :/ 15:23:13 There's a window3 which takes 85. Looks like possibly a copy/paste error. 15:25:12 So I think it's a mistake in the prototype. Your chance to get a patch in supercop maybe :D 15:26:09 No yeah you're right, the definition only uses 64 and the author who used the function expected that it takes 64, so the odd one out is the prototype 15:26:57 That's true of both bodies of sc25519_window4 15:27:13 Assuming no cpp malarkey I saw this and that made me think it might redirect to others: #define sc25519_window4 CRYPTO_NAMESPACE(batch_sc25519_window4) 15:27:53 If you found all and they're all 64 (which seems likely), then just fix 85. 15:28:19 I think they did that so that the symbols of the functions don't conflict 15:28:51 Like the calling code looks the same but it's a different symbol underneath, which is pretty clever 15:29:07 I think that's basically how C++ namespaces work under the hood lol 15:29:24 (and it'd be nice if you could also PR upstream, also gets confirmation it's something more subtle/clever) 15:33:17 True, does SUPERCOP have a public git repo ? 15:33:41 I assume so, since we got it. Maybe ddg one of the commit hashes. 15:33:51 * moneromooo afk for a bit 17:43:14 Hello, Monero Dev community. 17:43:14 I’m new here and I really want to contribute to Monero. 17:43:14 What a college student currently studying JS/React/Node can do to contribute to Monero? 17:43:42 Should I pursue C++ instead? 17:44:34 Hi. 17:45:50 If by "pursue" you mean "get a course about", then that's up to you really. I *assume* your college is not led by morons, and that "JS/React/Node" is a tool for implementing stuff, rather than learning just those by rote. 17:46:15 If it's the former, you'll get the ideas and principles just fine, and getting C++ on top is just another layer you can add later. 17:46:41 If it's the latter, then you should probably change college. 17:47:19 Javascript is close enough to C++ (AFAIK) that if your teachers are more about the concepts rather than syntax, stuff will carry over well enough. 17:48:02 "close enough" only syntax wise 17:48:19 In any case, you likely won't be able to contribute meaningfully in the short term anyway, whether you switch or not. 17:48:43 OK, the idea of Javascript I have is from like 20 years ago :D 17:48:53 And it was really pretty similar. 17:49:09 Just a shitter version that runs in a browser. 17:49:14 OK. maybe not 20... 17:50:17 The reason I mention that is that I've seen people being taught "MS word" and not getting any of the concepts, just a rote "click here if you want to make text larger" and having no clue what to even do when using another word processor (can't recall which). 17:50:32 If you're learning the concepts, it's all good. 17:51:25 one of the big differences is that c++ is a strongly typed language whereas JS is weakly typed 17:51:28 I understand I’m too green to have an impact. But I want to start this long journey 17:51:35 Then again, you could also look at Haveno, a monero related project that uses JS. 17:51:45 Maybe you can help a bit earlier. 17:52:56 moneromooo: Could you point out where to start from? 17:53:04 plus C++ compiles to native code and has access to underlying hardware, and Javascript is interpreted and has things like 'eval'. So language conceptions are quite differents. 17:53:34 For monero ? I usually tell people to use it, then find some small thing that's broken or unwieldy, and focus on fixing just that part. 17:54:04 That's small enough, gives you an attainable goal, and you get to learn what's where. 17:54:11 moneromooo: For Haveno 17:54:27 Ah, then join #haveno-dev and ask. I never tried to even build it. 17:54:59 The user interface is here: https://github.com/haveno-dex/haveno-ui. The matrix room for development-related discussions is at #haveno-dev:haveno.network 🙂 17:55:10 edo.ca ^ 17:55:42 the user interface is in javascript, the core in Java, but we are also building a library in typescript: https://github/haveno-dex/haveno-ts 17:56:00 any help would be greatly appreciated 🙂 17:56:37 ErCiccione: Are you currently working in the Haveno project? 17:59:54 edo.ca: yes, i am part of the core team 18:15:13 Thank you guys for all the answers. Since Haveno uses JS, I might be more useful to that project. 18:15:13 I’ll join Haveno room and keep in touch with ErCiccione, but I still keep my eyes in this room too 18:15:31 ninja: error: '../external/monero-project/build/release/src/crypto/wallet/libwallet-crypto.a', needed by 'libmonero-cpp.dll', missing and no known rule to make it 18:17:30 Your makefile... or... ninjafile or whatever... seems borked. You get to fix it :) 18:17:48 Anyway, not a monero bug AFAICT. These files aren't monero's. 18:17:55 (except libwallet-crypto.a) 18:18:34 i didn't change them 18:18:41 just got from Github 18:19:51 Ah, if it's someone else's project, ask them. libmonero-cpp.dll isn't monero. Unless something got added when I wasn't looking ? 18:20:01 ummmm 18:20:03 it is monero-cpp 18:20:05 And we don't use ninja either. 18:20:14 https://github.com/monero-ecosystem/monero-cpp 18:20:24 i don't like Ninja, CMake and others 18:20:29 just love GNU Make 18:20:37 and using relative include paths 18:20:39 Well, check who wrote this. Maybe they're here, maybe not. 18:20:39 relativeeeeeeeeeeeeeeeeee 18:20:51 :( 18:20:53 sorry buttt 18:20:56 this thing made me crazy 18:21:00 because i don't understand people 18:21:05 Best is to file a bug in their repo, after searching issues to see wheter it's already reported. 18:21:15 people are crazy for include paths 18:22:19 a/b/c/meow.h butttt sometimes -I a/b/c and #include "meow.h" sometimes -I a/b and #include "c/meow.h" 18:22:36 i understand why someone are making frameworks and shits when i see these 18:22:48 That will not cause your problem above. 18:22:58 i really don't understand %90 of native softwares are not buildable 18:24:11 sometimes defining some preprocessor things in build scripts and pass to compiler and more more more 18:24:15 im about to crazy 18:24:24 Monero source is not portable :( 18:24:27 because of these reasons 18:25:11 OK, you're being very useful, thank you. We will give your feedback the attention it deserves. 18:25:17 looooks like this monero-cpp thing is used by monoero-java and monero-javascript bindings 18:25:42 Ah, that might be woodser then. 18:26:37 the issue 18:26:41 I assume you read the README or BUILDING files (or similar) ? 18:26:53 i need Windows, Linux, Android, iOS builds 18:27:05 im doing that what the README.md says 18:27:18 Well, good luck. Build systems tend to be a massive pita. 18:27:18 tried everything 18:27:46 That's why people make more. They love adding more pita. 18:27:53 :( 18:28:10 Godot's build system is very complicated too but it is used to be very cross-platform 18:28:21 it is tested on everywhere 18:28:29 "very complicated" <- you see ? pita 18:28:46 but i think nobody used monero-cpp before 18:28:51 except monero-java and monero-javascript 18:29:01 Anyway, either go to the issues page of that project, or ask the ninja people if you want to fix it yourself. 18:29:20 (I recommend the former) 18:29:46 Oh, one thing. 18:29:49 as i understand 18:30:11 A shot in the dark, but: I see ".dll". Windows has always been a fucking annoying different pita. 18:30:14 libwallet-crypto.a is a part of Monero's building 18:30:26 yesss im building it on MSYS2 18:30:44 One common issue is if you have a space (or other "uncommon" character) in a directory leading to that. If you do, try fixing that first. 18:30:52 im making a wallet app with Godot Engine 18:30:58 i wrote ETH and BTC parts in C# 18:31:10 i will use C++ for Monero part 18:31:32 Nice. I made one with the urho3d engine :D 18:31:39 oh what is that 18:31:43 * moneromooo tends to like niche stuff 18:32:03 It's another game engine. 18:32:08 looooking rn 18:33:52 its editor loooks good 18:34:40 UrhoSharp..... 18:34:45 is that .Net 6? 18:35:17 It's some port for... forget the name... Miguel de Icaza's .net compat thing for linux. It's unmaintained AFAIK. 18:35:44 interesting 18:35:55 Godot devs are working on .Net 6 for Godot 4 18:36:05 And even if it were, it should not be used. I suspect it's a now dead trojan horse for MS to fuck with linux again. 18:36:15 Unity is stucked in .Net Framework 4.7 shit 18:37:24 Godot's cross-platform abilities are great 18:37:31 its UI system is good too 18:37:41 Godot editor is a Godot game 18:38:35 is there a built .dll of monero-cpp? 18:38:58 Who knows. Maybe look on the project's github releases page. 18:39:06 there is a big code but can't build lol 18:39:18 ohhh my question 18:39:36 isn't libwallet-crypto.a a part of Monero? 18:39:39 It is. 18:39:43 i think it is 18:39:53 monero-cpp is using Monero 18:39:57 building it 18:40:01 Good choice. 18:40:06 and linking statically its things 18:40:29 butttt why not creating a libwallet-crypto.a? 18:40:30 maybe just build it on linux 18:40:38 or install wsl 18:40:46 buttt i need Windows build 18:40:49 MeowingCat: can you try building release-v0.17 branch? 18:40:51 Windows, Android and iOS 18:40:56 in the monero submodule 18:40:56 Dunno. Maybe you should check the project's github page. 18:41:13 @MeowingCat monero-cpp's makefile currently assumes a *nix environment. it's an open issue to support Windows, which means expecting *.dll instead of *.a build artifacts: https://github.com/monero-ecosystem/monero-cpp/issues/10 18:41:17 selsta, 0.17 of external/monero-project? 18:41:19 tryinggg 18:41:19 MeowingCat: maybe there is a way to cross compile it 18:41:26 if you're able to, I'd first confirm the build process in linux since you're targeting that platform too, and I'd like to support Windows with the necessary modifications to CMakeLists.txt 18:41:31 i just took a look for cross-compiling 18:41:45 buttt build scripts are designed for building Windows binaries on MSYS2 18:41:57 how could i cross-compile it?? 18:42:11 i tried linking statically libwallet.a thing 18:42:17 buttt epee lib is giving errors 18:42:19 i have no idea 18:42:51 what is libwallet.a? 18:42:54 and libwallet_merged.a? 18:43:08 g++ -std=c++14 -I.\monero\monero-project\src\ -I.\monero\monero-project\contrib\epee\include\ -I.\monero\monero-project\external\easylogging++\ -I.\monero\monero-project\external -I C:/msys64/mingw64/include -o main main.cpp .\monero\libwallet_merged.a; 18:43:10 i tried this 18:43:15 These are monero libs as well. 18:43:17 buttt epee library has errors 18:43:31 Ah, that one might be our problem :) 18:43:42 when i build Monero i got libwallet.a and libwallet_merged.a 18:43:56 those are static libraries built in monero-project which monero-cpp links to 18:44:10 i have them 18:44:15 but can't link 18:44:23 epee library has source in headers 18:44:47 https://pastebin.com/b19J5wyQ 18:44:55 these errors 18:45:09 it can be build with Monero's build scripts 18:45:14 must be a way 18:45:19 i have no idea 18:46:07 there are tons of thirdparty things, build systems and more and more :( 18:46:08 :((((((((((((((( 18:46:16 it should be built against the release-v0.17 branch if you aren't already 18:46:35 i hoooope 18:46:37 im gonna try 18:46:51 building this ruins my CPU 18:47:19 how can i clean build things? 18:47:27 removing build directories 18:47:40 monero-cpp/build and monero-project/build 18:47:46 is there another thing i should remove? 18:49:21 that should be it 18:51:05 looooks like 18:51:10 some submodule targets 18:51:23 are not existed in repo 18:51:33 or there is something else wrong 18:51:46 i did checkout to v0.17 18:51:54 you did `git submodule update --init --force` ? 18:52:24 yes that's the one who giving errors :( 18:53:01 post the error 18:53:09 fatal: uzak konum hatası: upload-pack: not our ref 4c700e09526a7d546394e85628c57e9490feefa0 18:53:09 fatal: 'external/miniupnp' altmodül yolunda getirme yapıldı; ancak 4c700e09526a7d546394e85628c57e9490feefa0 içermiyor. Bu işlemenin doğrudan getirilmesi başarısız oldu. 18:53:16 you ran this in the monero-project submodule, right? first thing is to get monero-project building before monero-cpp 18:53:26 yes 18:53:33 git submodule sync 18:54:06 ohh 18:54:08 okiii 18:54:50 doing "make release-static-win64" 18:55:01 my CPU is gonna cry now 18:59:35 error :( 19:00:21 https://pastebin.com/ERtnu0NX 19:08:49 woodser[m], selsta 19:08:59 can youuu looook??? 19:13:03 so previously you tried master and now release-0.17? 19:15:05 yes 19:15:25 idk if it was master 19:15:36 i tried master of monero-cpp 19:16:15 idk what is monero-project's submodule revision of monero-cpp/master 19:23:05 it's the release-v0.17 branch 19:24:46 Dalınız 'origin/release-v0.17' ile güncel. 19:24:53 im on release-v0.17 19:25:28 getting monero-project to build is the first step. that's completely separate from monero-cpp. I don't know what the cause of the errors are from your log, for example: keyvalue_serialization_overloads.h:388:193: error: incomplete type 19:34:06 okiii trying 20:16:38 hey, should i be unable to fork repos on repo.getmonero.org? right now the button is disabled and when i hover over it, it says i have reached maximum amount of projects, even though i don't have any 20:17:14 Gimme your login there, I'll fix it. 20:17:26 it is built 20:17:41 buttt 20:17:42 It's the defalt when you register from github, and I've not found how to change that default. 20:17:45 build directory is different 20:18:02 there is a MINGW64_NT-10.0-22000/release-v0.17/release 20:18:17 how should i build monero-cpp with this? 20:18:23 moneromooo: yeah i used github's sso 20:18:38 i'm MasFlam on there too 20:18:48