-
luigi1111
selsta: when release notes?
-
selsta
now
-
selsta
-
luigi1111
awesome
-
selsta
when gui™
-
luigi1111
hmm I thought snipa did them
-
Snipa
I'm looking at them rn.
-
Snipa
And fixing my merge script to support -gui.
-
Snipa
selsta - All caught up. The new build process looks shiny!
-
selsta
only mac has to be done manually now, but mac is easy to setup
-
Snipa
Macs give me such a headache.
-
Snipa
I've been mucking with iOS 14 builds for work for the last week or so.
-
selsta
do you have to deal with xcode?
-
Snipa
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.
-
Snipa
Yes.
-
Snipa
And cocoapods.
-
selsta
yea it’s quite bad lol, they probably don’t care because most profit is on iOS so devs will deal with it
-
Snipa
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.
-
» selsta wonders how many computers Snipa owns :D
-
Snipa
Uh. A few. :)
-
Snipa
I've got a couple of work machines (6-7 macs), a couple of internal servers (4-5) and my desktop.
-
danyim
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?
-
selsta
if this is GUI: please use cmake build system
-
selsta
-
danyim
Any pointers for that? I followed the README and used the build.sh script to build
-
danyim
Ah, thanks
-
selsta
we will merge the readme changes in the next days
-
danyim
Awesome :) It's building away now
-
danyim
I have a JS frontend background looking to contribute to the project. Looks like I'll have to learn some Qt
-
selsta
QML should be easy if you know JS
-
selsta
backend is C++ but all the design stuff is in QML which is mostly JS syntax
-
danyim
Wonderful. Is there a contributors guide and/or an issue label that would be low-hanging fruit for first-time contributors?
-
moneromooo
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.
-
selsta
Yea we don’t have that for the GUI currently.
-
moneromooo
A good way to start is to use the program and try and fix any bugs or annothing things you see.
-
moneromooo
Those things are typically small, though not always.
-
moneromooo
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.
-
selsta
Though multisig is probably a bit complicated as the first thing to work on :D
-
moneromooo
Well it'd just the the UI.
-
danyim
Haha yeah that sounds a little too ambitious. Let's start with changing a color or two first ;)
-
selsta
-
danyim
Very nice that you had a designer's touch on the GUI
-
danyim
How much of those flows have been implemented?
-
danyim
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
-
dEBRUYNE
danyim: You can use qtcreater afaik to mimic that behavior
-
dEBRUYNE
dsc_ can probably tell you more :-P
-
selsta
danyim: `make -C build/release monero-wallet-gui` for a bit faster recompile
-
dsc_
danyim: for complicated QML components I use
github.com/monero-ecosystem/qml-xmr so you don't have to wait for lengthy compiles / application startups
-
dsc_
its a near-live editor of QML
-
dsc_
this was custom made because the waiting drove me insane
-
dsc_
-
dsc_
there is also #monero-gui btw
-
danyim
Oh nice. Just joined that
-
markUKP
Hi guys. Is there anything that prevents wallet::store() from running on a separate thread periodically?
-
markUKP
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
-
markUKP
am I right?
-
moneromooo
No, but it'd have to be locked, so preventing wallet refreshes.
-
moneromooo
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...
-
moneromooo
Why though ? Does it take time to run ?
-
markUKP
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?
-
markUKP
Is there anything preventing that right now? And the answer to your last question is that it can do for a gigantic enterprise wallet
-
markUKP
I was just stress testing one
-
markUKP
(a pretend one)
-
markUKP
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
-
moneromooo
It can get corrupt data. Otherwise we would not need to lock. Crashes also.
-
dsc_
AFAIK every time you run store() you have a chance of things corrupting.
-
dsc_
This was our first impression at least, will have to look into it before making bold claims.
-
moneromooo
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.
-
markUKP
Right. Thanks. I did suspect so, however we tested (for days) and didn't notice any corruptions.
-
selsta
markUKP: the GUI saves periodically, it caused a crash during wallet restore once for me
-
markUKP
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
-
moneromooo
Crash in monero code, or GUI code ?
-
selsta
wallet2 code
-
moneromooo
Do you have a stack trace ?
-
selsta
xiphon do you remember what the issue is? ^
-
xiphon
wallet2 is not thread safe
-
xiphon
thus we have a crash when we try to store the wallet while running refresh in another thread
-
xiphon
cli wallet have its internal locks for the case
-
xiphon
gui uses wallet2 api which auto-starts its internal refresh thread and have no locks
-
xiphon
moneromooo: basically you'll corrupt wallet2::m_blockchain if you try to refresh and do something with the wallet in parallel
-
moneromooo
Cool, thanks.
-
markUKP
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
-
markUKP
We didn't find any corruption, nor did we have crashes
-
moneromooo
But you're properly locking though, right ?
-
markUKP
In principle, I agree with what you guys are saying. It just seems odd that we didn't witness anything like that
-
markUKP
No extra locking MM
-
moneromooo
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.
-
moneromooo
If you're already large, you won't realloc for a long while, just increase size.
-
markUKP
Can you explain that a bit more in the context of data races
-
moneromooo
std::vector A. Size 2, allocated 3.
-
markUKP
Why wouldnt storing during transfers corrupt data?
-
moneromooo
Thread A push_back -> size 3, allocated 3, no reallocation
-
moneromooo
Thread B starts reading, gets pointer to data(), gets preempted before actually dereferencing ptr[0]
-
moneromooo
Thread A push_back -> 3 is not enough for 4, realloc, data() pointer changes
-
moneromooo
Thread B now dereferences ptr[0], but the memory's moved.
-
moneromooo
So the first one works fine, the second one does not.
-
moneromooo
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.
-
moneromooo
Anyway, lock properly and you're good.
-
moneromooo
Or if you want to speed things up, a locked copy and then unlocked save would also do. With extra memory conumption though.
-
moneromooo
I *assume* the copy will take less time, but that's not a given. Lots of std::vector.
-
moneromooo
Ideally this would all be mmapped from a LMDB database, so we would not have to worry about this at all...
-
markUKP
I understand the form of corruption you described above
-
markUKP
ie reading different pointer
-
markUKP
But what about if in the large wallet store() goes to read say ptr[0] at the same time it's being written to
-
markUKP
That is, it gets the right pointer, but only half of the data
-
moneromooo
Then it might get stale data. It doesn't really matter, you dont want that to happen either wau.
-
markUKP
For a hash, it might be 4 bytes of junk and 4 legitimate bytes, for example?
-
markUKP
if store() reads halfway through
-
moneromooo
That depends on so many things I'm not gonna say yes or no.
-
markUKP
Ok
-
moneromooo
But in theory, this could happen.
-
moneromooo
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.
-
markUKP
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
-
markUKP
getting 'preempted'
-
moneromooo
Preemption is an OS thing. That's what lock are for.
-
markUKP
yeah I thought so
-
moneromooo
Some languages might make this transparent I guess, at least low level stuff.
-
markUKP
Well it seems that preemption IS a kind of locking?
-
markUKP
if it takes care of these kind of read/write collisions?
-
moneromooo
What I call preemption is the OS saving the state of an executing thread and letting another resume.
-
markUKP
and it could do that to prevent read/write collisions?
-
moneromooo
You use locks (for example) to prevent read/write collisions.
-
markUKP
I know you do
-
markUKP
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
-
markUKP
I thought you were saying that the OS could preemptively protect read/write collisions explaining that^
-
moneromooo
No. I did not say that.
-
markUKP
Then I'm struggling to see why we don't get any corruption
-
smooth
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
-
smooth
and it can be hardware dependent, compiler dependent, etc. too
-
hyc
single-word references can't get torn. on a 64bit CPU that means 64bit accesses are always safe.
-
hyc
you'll never get half of a pointer
-
hyc
in practice you can't tear accesses within a cacheline either, 64bytes. but you can certainly get stale data.
-
markUKP
hyc thanks for that
-
markUKP
hyc so are we only really locking in modern c++ to avoid stale 64 byte chunks?
-
smooth
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
-
markUKP
@smo
-
markUKP
smooth thanks that's what I was thinking
-
selsta
luigi1111w: can you set v0.17.0.0 as release and upload the binaries?
-
selsta
and then set
paste.debian.net/hidden/1d974f9c as v0.17.0.1 pre-release