Wine doesnt always work. I've gotten it to work some some older games, but I've also had it bug out on me plenty. In short, you can't trust it to work 100% of the time.

And I'm not even going to respond to jl.

IIRC, games don't run that great in a virtualized windows installation?

http://www.glari.ch:2750/block/a6c907c0f9a2b30208f725a5dbdb7d00047ea3339e7bfa831604f5f738023e72

Thank you Unthinkingbit

Actualy is the dvc shop function working too, a dummy product for testing is now online.
Had a hard time to figure out a symbol for devcoin, i finaly came to the conclusion to use the sign phi Φ since Dev..coin can sound very similar to Deph..coin



Any objections?

That's an interesting observation on its own.  I'm not sure why HDD stress would cause networking hiccups.  Does it also cause Armory to crash (eventually)? 

However, I'm not convinced that is the source of the crashing problem.  I'm fairly confident that there is something else (i.e. a inf loop bug or something) causing readBlkFileUpdate() to take longer than 10s.  It just doesn't seem possible, even with a ridiculously slow HDD, that it would take more than 10s to read a few kB from disk.

Sorry, don't mean to discount your observation -- I do need to fix stupid networking problems like that.  But my gut tells me there's another, subtler issue...

It also has my address And it also managed to grab my signature I now noted.

https://blockchain.info/address/13373CuvtwQGgDWYv28pm3mTxy2bGS5U4D

http://www.diigo.com/item/image/1r0qz/0i1c?size=o

I'm not sure how that's possible... if it's in the blockchain there's no way to not detect it on a restart.  Unless Bitcoin-Qt isn't fully synchronized.

To be clear, mempool.bin holds only zero-conf tx.  The zero-conf tx is deleted when the same tx is included in the blockchain.  If you delete mempool.bin before it makes it into the blockchain, then the tx won't show up at all, until it has 1+ confirmation.   So if it doesn't show up at all, then... are you sure it made it into a block?  Do you have access to the txid in order to look for it on blockchain.info.  I'd be very surprised if the tx is in the blockchain, is relevant to any your wallets, Bitcoin-Qt is sync'd, AND it doesn't show up. 

I guess an alternative explanation would be something to do with your wallet not recognizing that the tx is relevant to it:  perhaps if somehow your keypool wasn't big enough... did you generate 100s of empty addresses before this one?  However, expert mode now lets you extend the keypool manually.  I doubt that's your problem (especially because the tx showed up before, but it's worth trying if all else fails).



Hmm, I've never seen it happen in linux.  I guess my HDD just doesn't get overwhelmed like that.  However, the disconnect-reconnect fluctuations are a symptom of the problem, not the cause.  Perhaps I should add a mechanism to disable the flickering if there's too much...

The real problem is why it's taking longer than 10s to do something that normally takes 0.2 ms.  My guess is it isn't a "legitimate" failure (HDD taking 2500 times longer than normal), it could be an infinite loop in the readBlkFileUpdate method, or it's somehow inducing a rescan when it's only supposed to be doing a quick update.  The debug output should tell me the last line that was run in readBlkFileUpdate, and also tell me the state of a bunch of different variables at that time.

prezbo,

Are you compiling from source?  I just put the BlockUtils.cpp with debugging calls in my dropbox folder, and it can be copied right into the cppForSwig directory and recompiled.  It's a P.I.T.A. to debug this stuff, because I can't compile in MSVS in debug mode (because I get crazy linker errors for things like not having python_debug.dll, I haven't figured it out, yet), and I can debug in Linux, but the error doesn't seem to happen there.  

So, the best I can do at the moment, is have it spit output to the console every other line, to find out where the problem is (and the state of some variables when it happened).  I might be able to figure it out just from the output... at the very least I can do more intelligent debugging when I figure out the location.  I am putting it out there right now, because I just ran it on my Win7 VM for 36 hours and it hasn't crashed yet...

---

I found and fixed the bug causing double-display in new wallets.  That's a particularly important bug to fix with the recent influx of new users.  That along with coin control is worth a full release, even without this once-per-24hours-crash bug fixed.   I am in process right now, of compiling and signing the installers.  I will also see if I can get git installed on the offline computer and sign the "v0.86-beta" tag, too (after I create it).

I also figured out why so many users were having trouble with the installers in Windows -- I have been trying to push people onto the 32-bit version, and I think when it installs it skips files it thinks are already there -- including things like python.dll which is 64-bit but then replacing everything else with the 32-bit version.  This is also why a repair/reinstall always fixes it.  I'll see if I can figure out how to force the installer to replace everything.

More than four days have passed without an objection so the bounty is in force. It has been awarded to K1773R for the GUI server/client part of his windows bundle:
https://bitcointalk.org/index.php?topic=34586.msg1367909#msg1367909

He'll get the devcoins is round 18:
https://github.com/Unthinkingbit/charity/blob/master/bounty_18.csv

To prove this thread's worth, allow me to distract you with pictures of kittens.

Stupid thread is stupid.

I was toying with the idea of using fractal backgrounds, for their scalability and as an allusion to Bitcoin's mathematical nature.



The design isn't finished, but if you like it I can work on it some more and produce a few templates of different sizes. Resolution isn't a problem but I'm wondering what else I can put on it and whether to add some fine print.

And here's a variation with a prominent mathematician:



Although it would be pretty hard to relate Khayyam to Bitcoin, I like how this illustration worked with the rest of the design. If there is interest, we might even commission an artist to draw us a Gavin that watches over the QR-code.

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map<a,b>, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

Merged block submittal result: True

Merged block submittal for pool <POOLURL> result: True

what exactly is this (booo) thing ?
is the shares accepted or ...?

I havent checked your download again yet, can you note if you already updated the devcoin qt for the icon/name? Also what are the chances you would be able to create a similar to bitcoind patched with devcoind patched so that we can start tweaking it to create sites that automate payouts similar to the bitcoin sites?

http://darkgamex.ch:2751/tx/0421151b4287b274d0150f723f9f0a9fa0c342b7d25ae0354008b129919eace9#o1

I was successfully able to track a transaction that I processed on the windows version of the devcoin qt.

GRC? Hmm. Usually we have been using GRP to represent GRouPcoin.

Would you use BBQ, BBC, or BQC for barbeque coin if you had to fit it into three letters?

-MarkM-