01:53:43 selsta: when release notes? 01:53:55 now 01:54:18 https://paste.debian.net/hidden/e47f8013/ 01:55:29 awesome 01:57:18 when gui™ 02:03:43 hmm I thought snipa did them 02:04:51 I'm looking at them rn. 02:05:03 And fixing my merge script to support -gui. 02:11:57 selsta - All caught up. The new build process looks shiny! 02:12:15 only mac has to be done manually now, but mac is easy to setup 02:12:24 Macs give me such a headache. 02:12:35 I've been mucking with iOS 14 builds for work for the last week or so. 02:12:52 do you have to deal with xcode? 02:12:55 Trying to get it to not freak out 24/7 trying to build makes me wonder if apple really wants people to build software for them. 02:12:55 Yes. 02:13:03 And cocoapods. 02:13:57 yea it’s quite bad lol, they probably don’t care because most profit is on iOS so devs will deal with it 02:14:43 Bleh. Once I unbury my desk downstairs, I need to move a bunch of computers, then rebuild a mac into a build box again. Such a pain. 02:28:36 * selsta wonders how many computers Snipa owns :D 02:28:53 Uh. A few. :) 02:29:17 I've got a couple of work machines (6-7 macs), a couple of internal servers (4-5) and my desktop. 11:40:40 Hi all, I'm trying to build the project locally but am running into this error "../src/libwalletqt/QRCodeImageProvider.cpp:29:10: fatal error: 'QrCode.hpp' file not found " -- any idea why we're referencing a non-existent file? 11:41:25 if this is GUI: please use cmake build system 11:41:58 see here for updated readme: https://github.com/monero-project/monero-gui/blob/c53668060067aa230e2f944fe7bba9487f1388ce/README.md 11:42:03 Any pointers for that? I followed the README and used the build.sh script to build 11:42:09 Ah, thanks 11:42:20 we will merge the readme changes in the next days 11:43:26 Awesome :) It's building away now 11:44:56 I have a JS frontend background looking to contribute to the project. Looks like I'll have to learn some Qt 11:46:31 QML should be easy if you know JS 11:47:21 backend is C++ but all the design stuff is in QML which is mostly JS syntax 11:48:57 Wonderful. Is there a contributors guide and/or an issue label that would be low-hanging fruit for first-time contributors? 11:52:16 There is a CONTRIBUTING.md file laying out basic things. A few issues in github laballed "hacktober fest" which are easy-ish for new contributors. That's for monero itself though, not the GUI., not sure which you're planning on hacking on. 11:53:06 Yea we don’t have that for the GUI currently. 11:53:35 A good way to start is to use the program and try and fix any bugs or annothing things you see. 11:53:46 Those things are typically small, though not always. 11:54:54 I just see you're saying "JS frontend". Then maybe adding, say, multisig to the GUI ? All the building blocks are there, it just needs a UI AFAIK. 11:56:54 Though multisig is probably a bit complicated as the first thing to work on :D 11:57:41 Well it'd just the the UI. 11:58:25 Haha yeah that sounds a little too ambitious. Let's start with changing a color or two first ;) 11:59:39 see https://www.figma.com/file/DplJ2DDQfIKiuRvolHX2hN/Monero-GUI for our design 12:00:46 Very nice that you had a designer's touch on the GUI 12:00:59 How much of those flows have been implemented? 12:06:16 Also, I'm a bit used to the instantaneous feedback loop of modern JS development. Is running `make` the only way to preview the UI as you develop or are there any tools/IDEs you recommend 12:42:24 danyim: You can use qtcreater afaik to mimic that behavior 12:43:03 dsc_ can probably tell you more :-P 12:45:38 danyim: `make -C build/release monero-wallet-gui` for a bit faster recompile 12:46:45 danyim: for complicated QML components I use https://github.com/monero-ecosystem/qml-xmr so you don't have to wait for lengthy compiles / application startups 12:46:57 its a near-live editor of QML 12:47:27 this was custom made because the waiting drove me insane 12:49:08 here was my work on the history page: https://twitter.com/xmrdsc/status/1102124558889435137 12:49:33 there is also #monero-gui btw 12:51:15 Oh nice. Just joined that 14:36:02 Hi guys. Is there anything that prevents wallet::store() from running on a separate thread periodically? 14:37:00 It seems that when the wallet is saving data from a new transfer, if store would be to run parallel, there would be nothing to prevent data races 14:37:01 am I right? 14:37:23 No, but it'd have to be locked, so preventing wallet refreshes. 14:38:03 Well, I guess you could keep two copies. Write to one on refresh. Copy the changes while locked to the second one. Save the second one unlocked... 14:38:15 Why though ? Does it take time to run ? 14:39:45 I get that. Refreshes aside though, say If store ran at the same time that a tx was made, could store end up storing corrupt data? 14:40:44 Is there anything preventing that right now? And the answer to your last question is that it can do for a gigantic enterprise wallet 14:41:01 I was just stress testing one 14:42:11 (a pretend one) 14:43:08 It would be nice to save periodically so that if the store() on shutdown failed, we wouldn't have to refresh the wallet from way back into the past 14:49:21 It can get corrupt data. Otherwise we would not need to lock. Crashes also. 14:55:53 AFAIK every time you run store() you have a chance of things corrupting. 14:56:11 This was our first impression at least, will have to look into it before making bold claims. 14:59:47 BTW, you may want to try again with 0.17. Serialization code changed (from boost to internal) and it might have gone slower or faster. Or not. 15:14:36 Right. Thanks. I did suspect so, however we tested (for days) and didn't notice any corruptions. 15:15:05 markUKP: the GUI saves periodically, it caused a crash during wallet restore once for me 15:15:26 You would think that a wallet performing a lot of tx with store running every 5 mins would store a corrupt version at some point 15:16:31 Crash in monero code, or GUI code ? 15:16:53 wallet2 code 15:17:11 Do you have a stack trace ? 15:22:10 xiphon do you remember what the issue is? ^ 15:23:23 wallet2 is not thread safe 15:24:15 thus we have a crash when we try to store the wallet while running refresh in another thread 15:24:57 cli wallet have its internal locks for the case 15:26:16 gui uses wallet2 api which auto-starts its internal refresh thread and have no locks 15:28:22 moneromooo: basically you'll corrupt wallet2::m_blockchain if you try to refresh and do something with the wallet in parallel 15:28:48 Cool, thanks. 15:30:19 We had a wallet RPC sending transactions none stop for 3 days and periodically saving the wallet on a thread( we coded it) every 5 mins 15:30:32 We didn't find any corruption, nor did we have crashes 15:30:51 But you're properly locking though, right ? 15:30:58 In principle, I agree with what you guys are saying. It just seems odd that we didn't witness anything like that 15:31:22 No extra locking MM 15:31:43 You said you have a massive test wallet. This could be the reason: a typical std::vector behaviour is to reallocate double current size if needed. 15:32:10 If you're already large, you won't realloc for a long while, just increase size. 15:33:14 Can you explain that a bit more in the context of data races 15:34:00 std::vector A. Size 2, allocated 3. 15:34:06 Why wouldnt storing during transfers corrupt data? 15:34:16 Thread A push_back -> size 3, allocated 3, no reallocation 15:34:51 Thread B starts reading, gets pointer to data(), gets preempted before actually dereferencing ptr[0] 15:35:05 Thread A push_back -> 3 is not enough for 4, realloc, data() pointer changes 15:35:17 Thread B now dereferences ptr[0], but the memory's moved. 15:35:35 So the first one works fine, the second one does not. 15:36:18 If you have a massive wallet, you might be at size 8437, allocated 16k. So you can read up to ~8k new outputs before a new realloc. 15:36:51 Anyway, lock properly and you're good. 15:37:19 Or if you want to speed things up, a locked copy and then unlocked save would also do. With extra memory conumption though. 15:37:36 I *assume* the copy will take less time, but that's not a given. Lots of std::vector. 15:38:29 Ideally this would all be mmapped from a LMDB database, so we would not have to worry about this at all... 15:39:56 I understand the form of corruption you described above 15:40:34 ie reading different pointer 15:42:05 But what about if in the large wallet store() goes to read say ptr[0] at the same time it's being written to 15:42:27 That is, it gets the right pointer, but only half of the data 15:42:35 Then it might get stale data. It doesn't really matter, you dont want that to happen either wau. 15:43:13 For a hash, it might be 4 bytes of junk and 4 legitimate bytes, for example? 15:43:31 if store() reads halfway through 15:43:53 That depends on so many things I'm not gonna say yes or no. 15:43:58 Ok 15:44:27 But in theory, this could happen. 15:45:28 I think you'd have to get your memory reused and written to in the meantime, and be preempted between at a 4 byte boundary read. 15:50:14 I did not know C++ could take care of things like that, ie know to come back for that piece of data once the write has finished 15:50:48 getting 'preempted' 15:52:21 Preemption is an OS thing. That's what lock are for. 15:52:56 yeah I thought so 15:52:57 Some languages might make this transparent I guess, at least low level stuff. 15:53:25 Well it seems that preemption IS a kind of locking? 15:53:49 if it takes care of these kind of read/write collisions? 15:53:54 What I call preemption is the OS saving the state of an executing thread and letting another resume. 15:55:36 and it could do that to prevent read/write collisions? 15:56:19 You use locks (for example) to prevent read/write collisions. 15:56:52 I know you do 15:57:26 I'm wondering why we aren't getting any corruption with this large and persistently active wallet, given that we didn't introduce extra locks 15:58:18 I thought you were saying that the OS could preemptively protect read/write collisions explaining that^ 15:58:50 No. I did not say that. 16:02:53 Then I'm struggling to see why we don't get any corruption 16:22:47 if the inconsistent state occurs only briefly and if there isn't a lot of preemption (not much other activity on other threads) then the collisions can be very rare 16:23:02 and it can be hardware dependent, compiler dependent, etc. too 17:33:24 single-word references can't get torn. on a 64bit CPU that means 64bit accesses are always safe. 17:33:40 you'll never get half of a pointer 17:35:22 in practice you can't tear accesses within a cacheline either, 64bytes. but you can certainly get stale data. 17:38:47 hyc thanks for that 17:53:48 hyc so are we only really locking in modern c++ to avoid stale 64 byte chunks? 17:59:17 only if the data you are interested in is a single chunk. if its multiple chunks that need to be consistent then you need to lock or be using a data structure that is designed to provide that without locking 18:11:37 @smo 18:11:54 smooth thanks that's what I was thinking 21:09:51 luigi1111w: can you set v0.17.0.0 as release and upload the binaries? 21:10:32 and then set https://paste.debian.net/hidden/1d974f9c/ as v0.17.0.1 pre-release