04:10:11 Hi! Is it possible to create a visual studio solution for monero-gui and compile it with MSVC? 07:04:24 sythaeryn_aerie[: you can try it, cmake allows you to create a visual studio solution 07:04:38 but there is no support for it if it doesn't work 07:07:05 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html 09:03:23 "sythaeryn_aerie: you can try it,..." <- thanks! I think I need some slightly more detailed steps how to make cmake generate a Visual Studio solution for the monero project. I am an experienced C++ programmer, but primarily with game development, so I spent my whole life in the windows ecosystem, where I only had to care about C++ in Visual Studio. I'd like to contribute to Monero, and I think I'd be able to quickly get 09:03:23 into most of the code, but I'd also like to keep using the tools I know best, being Visual Studio and all its related tools. are any of the monero devs using visual studio or is that something unusual? 09:04:09 none 09:04:51 everything is built with either gcc or clang toolchains 09:04:57 on Windows mingw64 is used 09:05:14 everything is built from bash shell 09:05:53 for main CLI build we don't even use mingw64 anymore, we just cross-compile from linux 09:07:27 I'm using Visual Studio 09:07:49 So p2pool supports VS. But yes, Monero tools don't support it 09:08:25 they might. cmake might work. but nobody has bothered to check, and nobody will care if it doesn't. 09:10:00 VS supports clang toolchain, so in theory it could work. But you'd need to find all dependencies too. 09:10:49 waste of time. Windows as a base OS is so much slower than Linux it kills productivity 09:12:57 hyc: I am never slowed down by my OS in any way, so I think that statement doesn't really make sense. there are obviously a huge amount of programmers who use windows every day. I'm not a Microsoft fan at all, but they know one thing, and that's how to make good tools for developers, because that's obviously what they need themselves. 09:13:09 I wouldn't say so. After a proper tuning, XMRig is faste on Windows for me. GUI differences are a matter of taste 09:13:51 yes, VS is very good for developers 09:14:01 no, I'm talking about basics like file I/O 09:14:12 NTFS is a shitty slow filesystem 09:14:28 the Windows memorry manager sucks, manages cache poorly 09:14:49 tools are whatever they are, but it's just lipstick on a pig 09:15:40 can't comment on file I/O, I don't run file servers :D 09:16:12 sythaeryn_aerie try cmake .. -G "Visual Studio 16 2019" -T ClangCL -A x64 09:16:15 most open source projects make it easy to get a visual studio .sln generated to make it easy for anyone to contribute who likes to simply use VS. I think it would be good if Monero would try to do the same. making it as easy as possible for people like me to help the project. I'm sure there's a lot of people like me who know C++ very well but are primarily working on the windows side of things and might not be familiar with the 09:16:15 toolchain Monero is setup around 09:16:21 it should create clang project for VS 09:18:03 actually I'll try it right now. Need to install C++ clang tools for VS first. 09:19:39 sech1: thanks! 09:22:44 you sound like a spoiled child. "your open source project that doesn't use any of the tools I'm familiar with should bend over backwards to add support for my tools" 09:23:47 yeah, cmake didn't work. It can't find dependencies, so it will take a while to even make it generate .sln 09:29:29 "you sound like a spoiled child...." <- I'm sure you'd agree that for an open source project it's quite ideal when the barrier to entry for any skilled programmer who wants to help is as low as possible and everyone can use their favorite tools for the job, because what matters is the code that's written and not what tools or OS someone uses for it. visual studio is very popular and there are a lot of C++ programmers who use 09:29:29 it every day for their work, so I am sure long-term it would bring many new contributors to the project if they could easily contribute using the tools they are used to. and that's something everyone would benefit from. 09:32:32 beside the point. the project is driven by volunteers. if nobody on the project uses then who has the responsibility to learn how to integrate your toolchain? 09:32:54 who has the time to do the work? who has the time to maintain it, when nobody uses it? 09:33:36 and it's more than just "the code" since there are subtle differences in header files and supported APIs between MSVC and gcc/clang 09:36:11 since Visual Studio seems to work fine with clang too, MSVC support might not be relevant, clang alone should be fine. as long as I could use the visual studio tools, I'd be happy. 09:36:26 great, make yourself happy. 09:36:33 it's nobody else's job to do things for you.\ 09:52:16 "great, make yourself happy." <- I'm not sure why you're so salty. I have come here because I'd like to contribute to Monero in my free time - I have not asked you to do anything for me. Visual Studio is the most popular development tool for C++, and I personally am sure it would benefit the Monero project a lot long-term to make it easy to use for Monero development. just my opinion. you are obviously free to disagree and 09:52:16 just ignore my thoughts on it. 09:53:48 ... you have asked "someone" on the project to add support for your tools, that nobody on the project uses 09:54:11 It's just how hyc is, straight to harsh :D It's a bit annoying but there's not going to be a change there. 09:54:24 a good open source developer understands that if you want something done, you do it. 09:54:46 My own opinion is that if you can make it work with minimal changes, why not. But it it's more than a few #defines, not worth the bother. 09:55:30 If you want to add a MSVC project file to the repo though, you'd have to maintain it, or it'll get removed. 09:55:44 (or find some other rube to maintain it :P) 09:58:09 if you think it'll be such a great boon to the project but you can't be bothered to do it yourself, then certainly no one else on the project will be motivated to do it 09:59:01 so you guys mostly use codeblocks atm? 09:59:04 Did they ask for someone else to do it ? 09:59:42 they keep saying it would be great to have it - but are they expecting it to magically appear? 09:59:51 no. for it to appear, someone has to do the legwork. 10:00:16 But they said they wanted to work on monero. Sounds like a "I could start with that" to me. 10:01:26 and again, "great, make yourself happy" 10:02:46 so what is the official "monero core team certified ide"? codeblocks, vim or emacs? 10:03:09 do you guys know if there's a way to extract the daily transactions on my wallet and create a daily report of all in/out 10:05:42 Yes, see src/wallet/*defs.h (or utils/python_rpc/framwework) 10:07:18 "But they said they wanted to..." <- I'd love to, but unfortunately that's not really something I could start with - the main work there seems to be "making cmake happy" and that's outside of my area of expertise 10:07:21 thank you moneromooo 10:08:13 the wallet rpc lets you constrain by block height. not by date. 10:08:39 so you'd need to keep a side record of the last height you checked before 10:12:37 I think there might be a new RPC to get a height from a date. 10:12:51 that's only an estimate 10:13:05 not sure how well it overlaps for consecutive dates 10:13:33 But in any case, if you get the txes, you get the timestamps anyway, so you can bin them then. 10:14:15 True, it's not actually monotonous... 10:15:47 sythaeryn_aerie your best shot is to try configure VS Code to use mingw64 toolchain because clang toolchain on Windows is also not supported 10:16:12 you then suggest to extract all txs which returns me an obj w/ containing the dates, then I can filter by day and sum all amounts 10:16:55 and I can do that via the RPC API calling into monerod 10:18:11 sythaeryn_aerie or just install msys2/mingw64 and follow the build instructions. I personally couldn't make Visual Studio Debugger work with it on Windows, and it's not the first time I tried 10:18:14 Either monerod (for all txes) or monero_wallet_rpc (for just that wallet's txes). 10:18:22 for text editor, VS Code will be just fine 10:19:10 I've never seen anything re: cross-compatible debug formats 10:19:19 can I query monerod to return all txs pertinent only to my wallet address? 10:19:22 so no, should not expect that to ever work 10:19:47 Yes, if you have the txids. 10:20:13 But you can't tell the daemon "get me txes to or from address 4xxx", that'd defeat hte point. 10:20:15 those need to be extracted from the wallet still 10:20:25 I understand thank you moneromooo 10:21:03 can the wallet be setup on a server in read-only? 10:21:22 yes, that's a view-only wallet 10:21:23 Yes. 10:21:52 thank you guys for the info 10:22:46 sech1: since I am a C++ programmer spending a lot of time using tools like the Visual Studio Debugger and Visual Studio Profiler usually, I don't think I'd enjoy working on a C++ project without having access to those tools... 10:32:31 "can I query monerod to return..." <- I think working with wallet_rpc or some other wallet related api is probably best. Here is how monero gui does it: https://github.com/monero-project/monero-gui/blob/edb0358916de455a72aa30eff63eb49aba6ee392/src/libwalletqt/TransactionHistory.cpp#L82 it imports from wallet2_api https://github.com/monero-project/monero/blob/master/src/wallet/api/wallet2_api.h 10:35:18 ^ that's one of the biggest problems with working with M$ tools. they don't support open standards (like DWARF debug info) and they don't publish specs of their PDB format to enable open source projects to support theirs. 10:35:29 sythaeryn_aerie I understand, I myself work mostly in VS (both at work and in my own projects). You can try to check out p2pool first, it supports VS. It's not so hard to work with Monero codebase once it's set up in msys2/mingw64 10:36:41 hyc while VS tools are excellent, I agree on this point. M$ tries to lock users to their ecosystem and are often successful 10:42:05 "hyc while VS tools are excellent..." <- but VS code is fine. it is open source. But visual studio is still closed source right? the naming is so confusing. It is so similar. 10:42:14 s/but// 10:43:54 VS code is just a text editor with tons of plugins 10:44:15 Maybe you can set it up to be comfortable, but 99% you won't be able to use VS debugger with the Monero codebase 10:45:12 "hyc while VS tools are excellent..." <- one good thing is that MSVC has become a lot more standard compliant in recent years 10:46:47 you can barely use any debugger with the monero codebase on windows. the object file format blows up from all the symbol data 10:46:50 thank you spirobel[m] 10:48:45 hyc: I don't quite understand why? what's the issue there? obviously big projects like Chromium can be debugged fine on Windows. Monero is not "bigger" I'd assume? 10:49:15 there's a limit of something like 32768 symbols per object file 10:49:48 my main work is with Unreal Engine 4 code. which is also a huge codebase. 10:50:05 and with the wild overuse of templates, boost, and other C++ syntactic garbage, many of the object files hit that limit\ 10:50:27 I recall the only thing that worked reliably was the PSDK debugger 10:54:31 hyc: is that some issue related to the toolchain used or something? as I said I don't have any experience with non-windows projects, but at least with VS and MSVC I've never, ever heard of there being any project running into something like a 32768 symbols limit for debugging or something similar 10:54:37 it may be this was only an issue on the 32bit builds. I don't remember now 10:55:06 and we ought to be phasing out 32bit builds soon anyway 10:56:05 yeah, this was an issue with gcc/gdb and COFF object files. Since MSVC uses PDB it probably didn't affect that 10:59:24 speaking of, PSDK debugger? I've been using debug printf so far :D it would be nice to have working debugger on Windows 10:59:44 well, it's asm-level only, but yeah. microsoft debugger 11:00:10 asm-level only works perfectly fine in VS too 11:00:18 just attach to the running process and open ASM view 11:00:24 https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools 11:00:26 WinDbg 11:00:31 "is that some issue related to..." <- maybe this can be an opportunity for you to learn about linux and the toolchains there. Using one ide too much can also become a crutch. 11:00:41 ah, WinDbg 11:02:17 spirobel true. Even at my work, where it's mostly VS and Windows, we use quite a bit of clang and linux toolchains for server-side tools 11:02:42 I find it hard to imagine how I could debug my own code without having access to the VS debugger, only having to reply on stuff like prints.... I'd think that would make everything take 10x longer and be way less fun. it's just deeply engrained in my workflow to use all the VS tools. I love to have access to the VS profiler and easily see how much time every individual line of code takes to run too. and having a quick and easy 11:02:42 right click -> go to disassembly to judge what exactly the compiler is doing and if I'm happy with that 11:03:41 spirobel[m]: problem is I'm really happy with the workflow I'm used to and I love writing C++ code but I don't love learning about toolchains and stuff, so it would be quite hard to motivate me to spend time with something like that... and I'm already busy with enough projects anyways 11:05:06 "to judge what exactly the compiler is doing" gcc toolchain can do that too, you can compile a single cpp file into .S asm file and check it out 11:05:37 also, if the code you write is self-contained, nothing prevents you from doing it in VS and then just plugging it into the Monero codebase 11:08:03 sech1: if there would be anything so self contained that would be useful, yeah 11:08:12 ^ good point there 11:08:15 if no one has ever been able to run the monero code through the VS profiler, I'd really love to be able to do that... I'm sure it would easily identify many potential optimizations 11:08:32 anyway, you can start with https://github.com/SChernykh/p2pool#windows-1 - p2pool is not part of Monero codebase, but it's tightly integrated. At least you could learn how to use RPC and ZMQ interfaces 11:10:24 Monero code was run through the profiler (not VS) before 11:10:40 some parts are optimized (like Supercop crypto library) 11:13:46 Something like bulletproofs might be easy-ish to extract to build with whatever tools you like, including that profiler. Speeding those up even more would be nice. 11:22:53 That's not a good starting point :D Any change in bulletproofs has a potential for infinite money glitch :D 11:25:35 There are tests and reviews. 11:29:21 true, but optimizing bulletproofs requires deep knowledge of the underlying math, and what the code in bulletproofs.cc does is just calling low-level crypto functions 11:30:21 I optimized it without knowning much of the math :P 11:30:24 it uses functions from monero\src\crypto\crypto-ops.c as far as I can see. Optimizing those would be nice 11:30:52 "Something like bulletproofs..." <- often the code that people know should be fast is already quite fast, and the most significant improvements can be had from code that people did not consider too relevant for the overall speed of the program before which is then only noticed by profiling 11:30:57 I'm talking about optimizations like this: https://github.com/monero-project/monero/commit/4ed60b626a368132fccad4449f1c4d50e312b60c#diff-52bc06cbdd63ac7e0d5300f4b17cc75da111f6dc24ac262ea1439352fb81c5b8 11:30:59 * moneromooo looks at several people rush to their editor with anguished looks 11:31:23 Those are already the optimized supercop code, no 11:31:24 ? 11:31:42 crypto-ops.c? 11:31:48 If not, then I agree, it'd be a very good target. 11:32:00 I'm still not sure where supercop is actually used 11:32:10 I think it's only for wallet scanning 11:32:19 Also, the person doing the profiling/sorting needs not be the one to do the speedups. 11:32:55 moneromooo: that's true, yeah 11:35:22 but often finding out what code needs to be optimized more is actually more work than doing the optimizations :P 11:36:03 unless stuff is already super optimized 13:09:53 sythaeryn_aerie[: maybe you can do a review of this PR? https://github.com/monero-project/monero/pull/8046 13:10:22 it's wallet optimization related 13:47:56 sythaeryn_aerie: Please join #monero-recruitment:monero.social 14:24:13 moneromooo: there are some new review comments here https://github.com/monero-project/monero/pull/7819 14:24:28 Thanks 18:15:18 -xmr-pr- woodser opened issue #8168: Don't require --rpc-login with --rpc-access-control-origins 18:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8168 18:48:28 sythaeryn_aerie[: if you want toolchain support improvement, you could create a bounty for it (a bit more motivating than 'please do this work for me for free') 21:11:23 would it be possible to add privacy-preserving scripting to monero using zk proofs? 21:12:19 maybe? lol 21:15:37 like, have all the utxo's pay to a hash of a script, and then when spending the uxto the spender would create a zk-proof that they a) have a script that matches the hash in the utxo they're consuming, and b) their transaction fulfills the conditions in the script 21:17:07 you may notice that this removes stealth addresses an subaddresses. I'll soon explain how to add them back in, if someone can confirm that my idea has any merit. 21:19:22 are they trustless setup? 21:20:46 I haven't actually implemented anything. this is purely my speculation >:D 21:21:38 is it theoretically, a trustless setup? 21:21:51 yes 21:21:56 i guess? 21:22:20 guess? isn't that kinda important? 21:22:44 it probably would be possible to create a zk-proof that does this and is trustless. 21:23:11 if not, we shouldn't implement this 21:24:26 you're the zk wizard, what do you think? 21:25:15 wizard? um all I know about is Monero ^.^ 21:32:44 the idea for reimplementing subadresses and stealth adresses goes like this. To create a subadress you take the main script hash and append to it a subadress index, and then hash them together. This is the subadress. To send to someone using a stealth adress you first create a shared secret with them, and then you append the shared secret to their 21:32:44 public adress (either a main or sub adress) and hash them together and publish the result to the blockchain as a "script public key". 21:37:29 Idk anything about zk scripting, so if you write up a doc explaining how it all works, that would be pretty helpful 21:39:40 lets say that you want to spend a utxo sent to a stealth-subadress. You create a zk proof that you input publicly the hash on the blockchain and the block height. You also input secretly the stealth shared secret, the subadress index, any hash preimages or other garbage the script checks and the actual script. the zk proof then proves to everybody 21:39:41 that 1) the script you used was the script being referenced and 2) the script indeed allows you to spend the utxo. 21:40:07 you lost me at "You create a zk proof" 21:40:21 how? 21:40:32 I can't write that right now because I have to go to sleep. sorry for my bad english