< Chris_Stewart_5> Has anyone had to deal with using bitcoind as a dependency with travis ci? Is there a way to get them to whitelist it's use in -regtest mode?
< sipa> ?
< sipa> why would it need a whitelist?
< Chris_Stewart_5> It looks like travis-ci bans people that use bitcoin as a dependency in .travis.yml
< Chris_Stewart_5> claiming I am mining
< sipa> ah, i see
< sipa> perhaps if you built bitcoind inside the VM?
< Chris_Stewart_5> and now I am a repeat offender :o. I emailed the travis ci people to hopefully get off of the list
< sipa> rather than using it as a dependency
< sipa> yeah, contact them to explain first
< Chris_Stewart_5> I asked if they could whitelist 'bitcoind -regtest'
< Chris_Stewart_5> We will see what the response is :/
< sipa> bitcoind doesn't even contain a miner anymore
< luke-jr> sipa: they banned us too
< luke-jr> had to get whitelisted :/
< Chris_Stewart_5> luke-jr: How long ago was that?
< luke-jr> not sure, a Looooooong time ago
< gmaxwell> great so even we're using a service that bans people for running our software. :(
< Chris_Stewart_5> yeah, I didn't even just get banned on that repo, it looks like I am banned on all repos :S
< bitcoin-git> [bitcoin] sipa opened pull request #10322: Use hardware timestamps in RNG seeding (master...rdtsc) https://github.com/bitcoin/bitcoin/pull/10322
< sipa> gmaxwell: std::random_device in libstdc++ from modern G++ uses rdrand when available, so we could just include that into the seeding
< sipa> and /dev/urandom otherwise
< sipa> ... however, the mingw-64 version just uses a mersenne twister with a constant(!) seed
< bitcoin-git> [bitcoin] sipa opened pull request #10323: Update to latest libsecp256k1 master (master...secp_up) https://github.com/bitcoin/bitcoin/pull/10323
< sipa> TIL: C++ template parameters can be (uninstantiated) templates themselves
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/75171f099e82...431a548faaf5
< bitcoin-git> bitcoin/master db994b2 Pieter Wuille: Simplify DisconnectBlock arguments/return value...
< bitcoin-git> bitcoin/master 431a548 Pieter Wuille: Merge #10297: Simplify DisconnectBlock arguments/return value...
< bitcoin-git> [bitcoin] sipa closed pull request #10297: Simplify DisconnectBlock arguments/return value (master...disconnect_enum) https://github.com/bitcoin/bitcoin/pull/10297
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/431a548faaf5...d4732f3232c3
< bitcoin-git> bitcoin/master bd1f138 Pieter Wuille: Add getchaintxstats RPC
< bitcoin-git> bitcoin/master d4732f3 Wladimir J. van der Laan: Merge #9733: Add getchaintxstats RPC...
< bitcoin-git> [bitcoin] laanwj closed pull request #9733: Add getchaintxstats RPC (master...chaintxstats) https://github.com/bitcoin/bitcoin/pull/9733
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4732f3232c3...83073de4bdd8
< bitcoin-git> bitcoin/master b8251f6 John Newbery: [tests] allow zmq test to be run in out-of-tree builds
< bitcoin-git> bitcoin/master 83073de Wladimir J. van der Laan: Merge #10307: [tests] allow zmq test to be run in out-of-tree builds...
< bitcoin-git> [bitcoin] laanwj closed pull request #10307: [tests] allow zmq test to be run in out-of-tree builds (master...fix_zmq_test_out_of_tree) https://github.com/bitcoin/bitcoin/pull/10307
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83073de4bdd8...d3dce0eb67e8
< bitcoin-git> bitcoin/master 185c7f0 Matt Corallo: Avoid reading the old hd master key during wallet encryption...
< bitcoin-git> bitcoin/master d3dce0e Wladimir J. van der Laan: Merge #10115: Avoid reading the old hd master key during wallet encryption...
< bitcoin-git> [bitcoin] laanwj closed pull request #10115: Avoid reading the old hd master key during wallet encryption (master...2017-03-cleanup-sethdmasterkey) https://github.com/bitcoin/bitcoin/pull/10115
< bitcoin-git> [bitcoin] spencerlievens opened pull request #10324: Add OSX keystroke to clear RPCConsole (master...patch-3) https://github.com/bitcoin/bitcoin/pull/10324
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d3dce0eb67e8...2a183de0ecb5
< bitcoin-git> bitcoin/master 91c91e1 John Newbery: Control mempool persistence using a command line parameter....
< bitcoin-git> bitcoin/master a750d77 John Newbery: Add tests for mempool persistence...
< bitcoin-git> bitcoin/master 2a183de Wladimir J. van der Laan: Merge #9966: Control mempool persistence using a command line parameter...
< bitcoin-git> [bitcoin] laanwj closed pull request #9966: Control mempool persistence using a command line parameter (master...mempoolpersistenceoption) https://github.com/bitcoin/bitcoin/pull/9966
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a183de0ecb5...0912620888e8
< bitcoin-git> bitcoin/master 56f09df Spencer Lievens: [Makefile] Alphabetically Reorder addrdb.cpp...
< bitcoin-git> bitcoin/master 0912620 Wladimir J. van der Laan: Merge #10302: [Makefile] Alphabetically Reorder addrdb.cpp...
< bitcoin-git> [bitcoin] laanwj closed pull request #10302: [Makefile] Alphabetically Reorder addrdb.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/10302
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0912620888e8...22d870016eb6
< bitcoin-git> bitcoin/master 1ff2bb4 BtcDrak: Remove unused args from GetFetchhFlags()
< bitcoin-git> bitcoin/master 22d8700 Wladimir J. van der Laan: Merge #10311: Remove unused args from GetFetchFlags()...
< bitcoin-git> [bitcoin] laanwj closed pull request #10311: Remove unused args from GetFetchFlags() (master...getflags) https://github.com/bitcoin/bitcoin/pull/10311
< bitcoin-git> [bitcoin] fanquake opened pull request #10325: 0.15.0 Depends Updates (master...depends-0-15-0) https://github.com/bitcoin/bitcoin/pull/10325
< jtimon> more begging for review on https://github.com/bitcoin/bitcoin/pull/9494
< jnewbery> wumpus did you see my comment on #10225? It's causing test runs to fail intermittently for me. Can we revert it until it's had some review?
< gribble> https://github.com/bitcoin/bitcoin/issues/10225 | [test] Add aborttrescan tests by kallewoof · Pull Request #10225 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: sure
< wumpus> just commenting out the test so it doesn't run automatically would be enough I guess
< jnewbery> yes, that would solve the immediate problem, but I'd also like to make sure that the test gets some review. I had a bunch of review comments for the PR which I didn't add because it wasn't even running reliably for me
< wumpus> no matter waht, comments must be addressed in a new PR
< wumpus> it's not possible to unmerge and reopen a PR
< jnewbery> can we do something like: new PR or commit to remove the test entirely, and then PR it again
< wumpus> I guess if no one fixes it, we can remove the test again at some point
< wumpus> I don't really see how that is better than just disabling the test (so it can still be run manually) then fixing its problems while it's not blocking travis, but okay...
< jnewbery> because the test is unreviewed and untested. I think we *should* have the test, I'd just like it to go through a review process before it gets merged :)
< bitcoin-git> [bitcoin] jnewbery opened pull request #10327: [tests] remove import-abort-rescan.py (master...remove_abort_rescan) https://github.com/bitcoin/bitcoin/pull/10327
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/22d870016eb6...35da2aeed7d4
< bitcoin-git> bitcoin/master 981e586 John Newbery: [tests] remove import-abort-rescan.py...
< bitcoin-git> bitcoin/master 35da2ae Wladimir J. van der Laan: Merge #10327: [tests] remove import-abort-rescan.py...
< bitcoin-git> [bitcoin] laanwj closed pull request #10327: [tests] remove import-abort-rescan.py (master...remove_abort_rescan) https://github.com/bitcoin/bitcoin/pull/10327
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10328: Update contrib/debian to latest Ubuntu PPA upload. (master...2017-05-update-debian) https://github.com/bitcoin/bitcoin/pull/10328
< BlueMatt> jonasschnelli: re: qt4: I think we need to just remove our tray icon anyway, at this point?
< BlueMatt> then the issues with qt4 should be resolved, I believe?
< jonasschnelli> BlueMatt: I think there is an option
< jonasschnelli> let me check
< jonasschnelli> setTrayIconVisible(optionsModel->getHideTrayIcon());
< BlueMatt> can someone close #10326 as "follow up with antpool, we are not antpool support there is nothing we can do"
< gribble> https://github.com/bitcoin/bitcoin/issues/10326 | block accepted in solo mining in Antpool and never rewards in the dashboard · Issue #10326 · bitcoin/bitcoin · GitHub
< BlueMatt> jonasschnelli: i believe there was previously discussion of just always not having tray icons
< jonasschnelli> Yes. Removing the tray makes sense... though, to prevent distraction, we shouldn't hurry. The option was a good start IMO
< jonasschnelli> I mean "removing the tray icon".
< jonasschnelli> OSX has already deprecated those "global menu icons" since years. Because it looks like that every new application wants to place a icon there and mostly the space is limited to just a handfull.
< jonasschnelli> I guess it's similar on Ubuntu/Windows.
< jonasschnelli> But all new application ignore these deprecations. :)
< jonasschnelli> Dropbox / Adobe / VMWare, etc.
< wumpus> ubuntu is going to drop unity anyhow
< wumpus> so the problem will go way
< jonasschnelli> wumpus: There are no such thing like Tray icons in GNOME?
< wumpus> but yes completely removing tray icon functionality would be a possible future thing too
< wumpus> jonasschnelli: there are, but that problem shouldn't exist there
< wumpus> it's a problem specific to how unity intercepts the tray menu
< wumpus> as I understand, at least
< jonasschnelli> Okay. Yes. I think as long as users like apps that inject tray icons, we should not hurry with removing the option.
< jonasschnelli> We could first set the option to false by default
< wumpus> right
< wumpus> but as I understand it this problem is specific to unity: it doesn't exist on GNOME, nor KDE
< wumpus> haven't tested, though.
< jonasschnelli> Yes. I think so.
< jonasschnelli> BlueMatt: the current PPA is built with Qt4? Right?
< BlueMatt> yes
< jonasschnelli> Hmm... what speaks against Qt5?
< BlueMatt> wumpus: luke-jr was also complaining about qt5 not working with kde4 folks (do people still use kde4...or kde?)
< jonasschnelli> Yes. But that orthogonal to the PPA.
< BlueMatt> true, but it is further reason why we need to support Qt4
< BlueMatt> (is there even a reason to migrate to qt5)
< BlueMatt> or, quickly migrate, that is
< wumpus> well, most software moved away from qt4 by now, so requiring qt4 for the ppa pulls that in, and makes the software look different from other things
< wumpus> this is a different decision than stopping qt4 support anyhow
< BlueMatt> how do other projects support qt5 on ubuntu? just no tray icons?
< wumpus> I think so, yes
< jonasschnelli> I expect much less maintenance on the qt4 branch. Things like HiDPI, etc. which nowadays is also common on Ubuntu is only possible with Qt5.
< wumpus> software on linux that adds tray icons is kind of rare
< BlueMatt> lol, why is all software terrible
< wumpus> the "correct way" to do tray functionality on ubuntu is to register beneath one of the existing (vendor-provided) tray icons in the tray menu. They have an API for this. Of course, given that it's going to disappear it's not worth spending time on that.
< wumpus> (if it ever was)
< wumpus> but e.g. some instant messenger and email clients etc do that
< BlueMatt> ah
< wumpus> (probably, ubuntu maintains their own patches for that)
< BlueMatt> <BlueMatt> lol, why is all software terrible
< wumpus> why is all terrible
< BlueMatt> fair point
< luke-jr> BlueMatt: Qt5 doesn't adapt to Qt4, *and vice versa*. KDE 4 is rapidly becoming Windows XP. I think we're okay to drop Qt4 entirely as soon as it becomes a burden, but changing builds to use Qt5 ASAP is a good idea.
< wumpus> the bitcoin.org builds have been using qt5 for considerable time, it's just the PPA using qt4
< luke-jr> Ubuntu is no longer Unity; I'm guessing we still support an older Unity-based version though?
< wumpus> there's no Ubuntu no-Unity release yet afaik? I just meant that starting from there we can switch it to qt5
< luke-jr> is there a way to make debs use a different version based on their target?
< luke-jr> (parazyd - the guy who opened that PR - 's target is Knots on Devuan FWIW)
< wumpus> "On 5 April 2017 Mark Shuttleworth announced that Canonical's work on Unity will end and that Ubuntu 18.04 LTS, a year away from release at the time, will abandon the Unity desktop and employ the GNOME 3 desktop instead"
< wumpus> yes he's using KDE5, which doesn't work with qt4 all too well, so I understand his concern
< BlueMatt> luke-jr: all debian builds have the release hardcoded
< BlueMatt> well, for uploads to ppa/debian builds/ubuntu builds
< BlueMatt> manual builds ignore that
< luke-jr> I thought for PPAs you upload once and it built for everything? :o
< BlueMatt> nope, it gets uploaded like 5 times
< luke-jr> ew
< luke-jr> BlueMatt: it would be nice if there was a gitian descriptor that produced the files to upload btw ;)
< BlueMatt> the files to upload is pretty much just the debian/ folder from contrib/debian and a copy of the git archive, all signed by my pgp key
< BlueMatt> not sure how useful it would be, then, unsigned :p
< luke-jr> there isn't something that requires a Debian-based OS to generate?
< BlueMatt> I dunno, I use the debian tools to upload, but used to use the debain tools on arch, even
< BlueMatt> now its in a vm
< sipa> i thought PPA was ubuntu-spdcific
< luke-jr> it is
< BlueMatt> PPAs are, but the tools to upload to them are debian-generic
< luke-jr> BlueMatt: well, it'd be nice to have that VM turned into a gitian descriptor simply for convenience IMO; gitian as an automating tool rather that determinism tool ;)O
< BlueMatt> luke-jr: yes, but there'd be no point in anyone but me using it?
< BlueMatt> so why bother?
< BlueMatt> its already dead-simple to do
< luke-jr> BlueMatt: well, you don't want to maintain a PPA for Knots I assume?
< BlueMatt> just copy contrib/debian into debian and run dpkg-buildpackage
< BlueMatt> iirc dpkg-buildpackage -S -sa -d && dput ppaname *.changes
< luke-jr> k, will try that
< BlueMatt> you need to add ppaname to some config file
< BlueMatt> but ofc thats the part that is me-specific
< BlueMatt> not gitian-able
< BlueMatt> also your pgp key name has to match the top entry in debian/changelog for dpkg-buildpackage to sign it right
< luke-jr> your daily and RC PPAs seem dead since 2011 btw
< BlueMatt> im aware
< BlueMatt> they need to be deleted, probably
< Lauda> Is 'walletpassphrase' supposed to return 'null' now on correct entry of pass?
< wumpus> it always did AFAIK
< wumpus> on failure it throws an error, on success it returns NullUniValue
< Lauda> It may just be me, but I haven't noticed 'null' up until today on 0.14.1
< Lauda> Thanks for clarifying though!
< BlueMatt> luke-jr: i cant add people to the "bitcoin" team on launchpad because adding people means they get instant upload rights....so adding people needs to be a public process of "this person is gonna get PPA upload rights"
< wumpus> Lauda: might be that the GUI now displays it differently?
< Lauda> wumpus IIRC the GUI never returned 'null', that's why it surprised me (it had an empty line or something). Again, might be me :l
< luke-jr> BlueMatt: hmm, no way to add me with just a second PPA for knots?
< BlueMatt> luke-jr: I dont believe so, but may be wrong
< luke-jr> weird
< wumpus> Lauda: ah I think I remember now, IIRC that was changed because an empty line was confusing people
< Lauda> maybe in 0.14.0 (just tested that one, as it also has null). Thanks :D
< luke-jr> BlueMatt: dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../bitcoin_0.11.0.orig.tar.{bz2,gz,lzma,xz}
< BlueMatt> luke-jr: you need to create a git archive with the listed name :p
< luke-jr> dpkg-source: info: local changes detected, the modified files are: bitcoin/source/clientversion.cpp
< BlueMatt> yes, and the source has to match the git archive exactly, so the git archive magic in clientversion.cpp needs to be updated accordingly
< BlueMatt> really you're supposed to just untar the release source (which for us is git archive)
< luke-jr> not the gitian-generated tarball?
< BlueMatt> i suppose it doesnt matter?
< BlueMatt> i mean you can upload any source you want, i use git archives
< luke-jr> the latter has clientversion correct and configure generated :D
< BlueMatt> ehh, I'll stick with autogen on launchpad, doesnt matter
< jtimon> mhmm, travis wasn't launched for #9494 on last rebase... wumpus can you or someone else make it happen or should I just push with a different commit id or something?
< gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] RHavar closed pull request #10100: Make ApproximateBestSubset optimize for amount of inputs (master...coinselection) https://github.com/bitcoin/bitcoin/pull/10100
< sipa> anyone know what could be happening here? https://travis-ci.org/bitcoin/bitcoin/jobs/228201960
< sipa> no output for 10 minutes while/after running bitcoin-util-test.py
< sipa> this is the second PR where I see this problem
< wumpus> no, no idea. This was after the revert of #10225?
< gribble> https://github.com/bitcoin/bitcoin/issues/10225 | [test] Add aborttrescan tests by kallewoof · Pull Request #10225 · bitcoin/bitcoin · GitHub
< sipa> let me rebase on top of that revert
< sipa> reindex-chainstate on my laptop with pertxoutcache: 1h27m to block 453354 (default assumevalid)
< sipa> (and infinite dbcache, which is larger now)
< sipa> i'll benchmark master as well
< luke-jr> BlueMatt: how to get db4.8 built? :p
< luke-jr> (maybe it should be a separate PPA that can just be used as a dep?)
< TD-Linux> which reminds me, a recent beautiful locking bug with latest glibc and libdb breaks rpm on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1394862
< TD-Linux> I don't think this affects db4.8 or wallet btw
< BlueMatt> sipa: context? what is non-per-utxo?
< BlueMatt> wait, what is pertxoutcache?
< sipa> BlueMatt: pertxoutcache = #10195
< gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
< sipa> sorry, i think in my own branch names rather than PRs
< BlueMatt> ah, k
< sipa> dbcache was 6.3G at that point though, and 2.7G on disk after flushing
< BlueMatt> sipa: still missing lots of context...how do those numbers compare to previously :p
< BlueMatt> (esp cache size)
< sipa> BlueMatt: yeah, i haven't done a rigorous benchmark on this system recently, so i can't tell
< sipa> i was just surprised by a reindex of 1.5h
< sipa> maybe that's due to improvements in master i'm not aware of, or maybe my memory is faulty :)
< BlueMatt> or assumevalid
< bitcoin-git> [bitcoin] jnewbery opened pull request #10330: fix zapwallettxes interaction with persistent mempool (master...zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10330
< jnewbery> sipa: I may be wrong, but I think that your travis issue is with the unit tests rather than bitcoin-util-test.py. Compare: https://travis-ci.org/bitcoin/bitcoin/jobs/228344728 . I think the final line in your output:
< jnewbery> make[4]: Entering directory `/home/travis/build/bitcoin/bitcoin/build/bitcoin-i686-w64-mingw32/src'
< jnewbery> indicates that bitcoin-util-test.py has returned and you're now running the unit tests
< sipa> jnewbery: sounds plausible
< sipa> any idea on how to find out which test is the cause?
< luke-jr> I'm not sure the UAWITNESS service bit in BIP 149 is sufficient. At the very least, relying on service bits is a bad idea.
< luke-jr> what happens if a malicious node sends 0.14.1 a segwit block when BIP9 didn't activate? will it permanently flag it as invalid and never reconsider a stripped version?
< abpa> Don't you have the same issue if SegWit 2 is proposed with BIP9 over again?
< luke-jr> abpa: possibly. changing the dummy byte may workaround this.
< jnewbery> how reproducible is this on travis? Perhaps you could update the travis/make config to run the unit tests with verbose output?
< sipa> jnewbery: i have 2 PRs which reproducibly failed in 1 or 2 builds, both windows builds
< sipa> how do i run the tests verbose?
< jnewbery> sipa: test_bitcoin --log_level=all if you're running them manually, but that produces a lot of output. I haven't looked at how you'd update makefiles/travis config to do this
< sipa> jnewbery: i cannot reproduce it locally
< sipa> ok
< bitcoin-git> [bitcoin] jnewbery opened pull request #10331: Share config between util and functional tests (master...shared_util_function_test_config) https://github.com/bitcoin/bitcoin/pull/10331
< luke-jr> FYI: release tarballs are missing contrib/debian entirely
< bitcoin-git> [bitcoin] parazyd closed pull request #10316: fix contrib/debian builds; prefer qt5 (master...debian-packaging) https://github.com/bitcoin/bitcoin/pull/10316
< bitcoin-git> [bitcoin] instagibbs opened pull request #10333: CreateTransction fee fixes: always create change, adjust value, and p… (master...fixfeefinal) https://github.com/bitcoin/bitcoin/pull/10333
< sipa> cfields: how do i go about having a #define available for the presence of clock_gettime?
< sipa> cfields: it seems configure.ac already tests for it, but there is no macro
< cfields> sipa: looks like we assume it's always there?
< sipa> cfields: the interwebs tell me that OSX doesn't have it
< cfields> sipa: ergh, I remember something about it changing in 10.12
< cfields> sipa: ah right, maybe it was added and we'll have to deal with it like getentropy
< cfields> checking
< cfields> sipa: wait. What do you need it for?
< sipa> cfields: #10322
< gribble> https://github.com/bitcoin/bitcoin/issues/10322 | Use hardware timestamps in RNG seeding by sipa · Pull Request #10322 · bitcoin/bitcoin · GitHub
< sipa> ARM does not have an rdtsc instruction, and clock_gettime has much higher precision than gettimeofday
< sipa> i guess it does not matter that much... because on OSX we'll always be on a platform that does have rdtsc
< cfields> sipa: opposed to using std::chrono::high_resolution_clock ?
< sipa> ah!
< cfields> (i assume it's just an abstraction around clock_gettime for *nix)
< sipa> checking how it is implemented; thanks for the suggestion
< cfields> np
< * sipa> is slightly scared about these things, after seeing how useless the std::random_device implementations can be...
< cfields> to answer your question, in case this doesn't work out, in the "AC_SEARCH_LIBS([clock_gettime]", just add a third argument. Do the AC_DEFINE there.
< cfields> libc++ uses: clock_gettime(CLOCK_REALTIME, &tp)
< cfields> but seems to round it to msecs :(
< sipa> "uses" ?
< sipa> for what?
< sipa> oh, for high_resolution_clock?
< sipa> rly?
< cfields> ah wait, that's only if there's no monotick source
< sipa> cfields: can you try compiling and running https://zerobin.net/?f8af7a8040549857#9JGDEBZvv+MQzzGCfLGyvIC5C8plMb7L/Jxg34DuCYM= ?
< gribble> https://github.com/bitcoin/bitcoin/issues/9 | Fix for GUI on Macs and latest wxWidgets by gavinandresen · Pull Request #9 · bitcoin/bitcoin · GitHub
< sipa> on linux it gives me nanosecond precision, in mingw-w64 + wine microsecond
< cfields> mmm, i'm about ready to take back that suggestion. probably not worth the risk.
< cfields> sec
< cfields> yea, I get nano
< sipa> cool
< sipa> i like c++:
< sipa> return std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::high_resolution_clock::now().time_since_epoch()).count();
< sipa> ...
< cfields> heh
< sipa> translates to a single instruction
< sipa> (a library call, to be clear... but no conversion anywhere)
< cfields> oh, nice :)
< cfields> sipa: static_assert(std::ratio_greater_equal<std::chrono::high_resolution_clock::period, std::nano>::value == true, "no nanosecond precision");
< cfields> zero instructions for that one :)
< sipa> cfields: that compiles fine on mingw, even though the result only has microsecond precision
< sipa> (it always returns numbers that are multiples of 1000)
< cfields> hmm
< sipa> what output do you get on osx from my snippet?
< cfields> nano
< cfields> 1033378907044228
< cfields> 1033378907124163
< cfields> ...
< cfields> oh sorry, got that static_assert backwards. That should be ratio_less_equal
< cfields> with that change, mingw fails to compile for me.
< sipa> still compiles fine here
< cfields> sipa: to avoid multiples of 1000 with microsecond precision, you can use: "auto value = std::chrono::duration_cast<std::chrono::high_resolution_clock::duration>(epoch);"
< cfields> (though it sounds like your mingw is lying to you about precision at compile-time, so that may not help)
< cfields> works here