i'll stay in stand by for new versions
Topic: [Round #5] Final Testing Release Before Armory v0.88 (Read 6442 times)
it doesnt start
i'll stay in stand by for new versions
i'll stay in stand by for new versions
btw. is it possible to get some data from armory via RPC/API?
I would like to check balances of my paper wallets without blockchain.info via such an API.
I would like to check balances of my paper wallets without blockchain.info via such an API.
I created "armoryd" which is included, but it's extremely minimal. I was waiting for some of the stability issues to go away before expanding it any more. But it will run for multiple days at a time before crashing, so it may still be useful for some low-importance activities
(the crashing is an artifact of the way it tracks the blk*.dat files, which is going away with the upcoming update).appreciated
thank you. I will check and repost on news 
btw. is it possible to get some data from armory via RPC/API?
I would like to check balances of my paper wallets without blockchain.info via such an API.
I would like to check balances of my paper wallets without blockchain.info via such an API.
I created "armoryd" which is included, but it's extremely minimal. I was waiting for some of the stability issues to go away before expanding it any more. But it will run for multiple days at a time before crashing, so it may still be useful for some low-importance activities
(the crashing is an artifact of the way it tracks the blk*.dat files, which is going away with the upcoming update).
btw. is it possible to get some data from armory via RPC/API?
I would like to check balances of my paper wallets without blockchain.info via such an API.
I would like to check balances of my paper wallets without blockchain.info via such an API.
Quote
the link doesn't work for me
I removed it because it's no longer a testing release! It's now available on the BitcoinArmory download page.
It doesn't work for everyone. But if it does work for you, it seems to be flawless. Otherwise it won't even start. Good luck!
Quote
the link doesn't work for me
EDIT: loaded from website
EDIT2: you were faster. thanks anyway
Hey, I think you should fix that!. Where I placed the red circle/ellipse thingy, I think the text should be fully centered (to allow seeing the decimals without wasting the space) instead of starting on the middle like it is currently. What do you think?
Yeh, I guess I could bring it in a little bit. The goal is to make sure the decimal place is lined up for all rows, so that 112.5 doesn't "look the same" as 1.125. For that, I need to reserve some space on the left side. But I agree, there's probably too much there.
Hey, I think you should fix that!. Where I placed the red circle/ellipse thingy, I think the text should be fully centered (to allow seeing the decimals without wasting the space) instead of starting on the middle like it is currently. What do you think?
Thanks for fixing the problem. However, why would you want to reduce the timeout from 0.01s to 0.001s? Would there be any noticeable difference?
That check happens in the main thread, which means it blocks until it's done. That means the GUI will be unresponsive for up to 0.01s on each call. If this function was called every 0.1 seconds, the interface would be jittery and laggy. It's not called that often, but in the future I might want to...
So, I want the value as low as possible unless I want to go through the hassle of somehow multithreading it. Since it's localhost, I figured 0.001s was more than enough time anyway. And I was right... for all systems except Windows Server 2008, apparently...
Oh well. I reverted it back to 0.01s, which isn't a problem when it's called at most once-per-second, and I'm sure it will have minimal impact. I just have to be careful if I want to increase that frequency.
Not sure if it is the problem of all Windows Server 2008 R2 or just my own problem. You may try, let say, reduce it to 0.005s and see if it works on my system
Thanks for fixing the problem. However, why would you want to reduce the timeout from 0.01s to 0.001s? Would there be any noticeable difference?
That check happens in the main thread, which means it blocks until it's done. That means the GUI will be unresponsive for up to 0.01s on each call. If this function was called every 0.1 seconds, the interface would be jittery and laggy. It's not called that often, but in the future I might want to...
So, I want the value as low as possible unless I want to go through the hassle of somehow multithreading it. Since it's localhost, I figured 0.001s was more than enough time anyway. And I was right... for all systems except Windows Server 2008, apparently...
Oh well. I reverted it back to 0.01s, which isn't a problem when it's called at most once-per-second, and I'm sure it will have minimal impact. I just have to be careful if I want to increase that frequency.
https://github.com/etotheipi/BitcoinArmory/commit/e0bcd9db6fe2e459c5d01290655e83e9632a36ab
Thanks for fixing the problem. However, why would you want to reduce the timeout from 0.01s to 0.001s? Would there be any noticeable difference?
Thanks for fixing the problem. However, why would you want to reduce the timeout from 0.01s to 0.001s? Would there be any noticeable difference?
Whoops! I accidentally changed the makefile, and the Linux installers didn't work on systems with python2.7. I have repackaged them and posted them to the top post.
A minor buglet:
The time estimate when loading the block chain is completely off. It takes 2-3 min to load, most of the time it estimates the remaining time to 18 min. This is undoubtedly because it only uses the number of block files read to make the estimate, but since I upgraded the Satoshi client from 0.7 to 0.8 I have three huge files, and around 15 small ones after that one.
The time estimate when loading the block chain is completely off. It takes 2-3 min to load, most of the time it estimates the remaining time to 18 min. This is undoubtedly because it only uses the number of block files read to make the estimate, but since I upgraded the Satoshi client from 0.7 to 0.8 I have three huge files, and around 15 small ones after that one.
Worse is full-blockchain-download estimator. Those things are tough to do right! I had to cap it at 8 hours to avoid it saying "187 years" when the download pauses. I have all these ideas to improve it, but I have also spent an unfortunate amount of time dealing with it already.
The 0.7 thing will go away over time, especially with forced upgrades to 0.8.1. I won't stress too much about it. Though I suppose it wouldn't be too hard to actually look at the size of those blockfiles...
But even that will become irrelevant when I get the persistent blockchain stuff (coming soon!)
A minor buglet:
The time estimate when loading the block chain is completely off. It takes 2-3 min to load, most of the time it estimates the remaining time to 18 min. This is undoubtedly because it only uses the number of block files read to make the estimate, but since I upgraded the Satoshi client from 0.7 to 0.8 I have three huge files, and around 15 small ones after that one.
The time estimate when loading the block chain is completely off. It takes 2-3 min to load, most of the time it estimates the remaining time to 18 min. This is undoubtedly because it only uses the number of block files read to make the estimate, but since I upgraded the Satoshi client from 0.7 to 0.8 I have three huge files, and around 15 small ones after that one.
Ack, I forgot to mention (and it will be at the top of the release notes):
Windows users must uninstall the previous version before installing this new one. If you've already installed the new version, reinstall/repair it.
Windows users must uninstall the previous version before installing this new one. If you've already installed the new version, reinstall/repair it.
Oh wow, that worked, had to fully remove and install. Nice to see someone so dedicated to create the best bitcoin wallet for power users.
PD: I was having problems with the 0.87.2 version, most times when I tried to do a transaction Armory gave a runtime error as soon as I entered the wallet password and hit enter. I tried reinstalling/ deleting mempool, with no improvement. Weird enough, the latest beta (this one) fixed my issue.
Ack, I forgot to mention (and it will be at the top of the release notes):
Windows users must uninstall the previous version before installing this new one. If you've already installed the new version, reinstall/repair it.
Windows users must uninstall the previous version before installing this new one. If you've already installed the new version, reinstall/repair it.
The latest release is still not working for me, and the log file is pretty much the same. What can I do?
Gah, I forgot about you. There should be more information in there this time. I added a bunch of good debugging output.
Can you remind me what is wrong? And send me the log file again, just in case it did catch something new. Thanks for being so patient. I'll figure it out!
Hey, for me it isn't working, as soon as I run it it closes, and if I click to see the details of the crash it points to msvcr90.dll , I have it installed and everything.
The latest release is still not working for me, and the log file is pretty much the same. What can I do?
Gah, I forgot about you. There should be more information in there this time. I added a bunch of good debugging output.
Can you remind me what is wrong? And send me the log file again, just in case it did catch something new. Thanks for being so patient. I'll figure it out!
The latest release is still not working for me, and the log file is pretty much the same. What can I do?
Non-US Users. Please help me test! Need unicode/non-en-us users to try it.
The new auto-bitcoind stuff came with a host of critical unicode issues. In the past, such issues were simply annoying, but didn't actually prevent users from using Armory. Now it did. I have upgraded the critical paths to handle unicode, and added warnings for everything else. One exception to unicode handling is that you cannot use unicode in your bitcoin.conf username or password, and only in Windows! (it works fine in Linux) Otherwise, I'm hoping this will go a lot better than before!
See the top post for details!
https://bitcointalksearch.org/topic/m.1655941
The new auto-bitcoind stuff came with a host of critical unicode issues. In the past, such issues were simply annoying, but didn't actually prevent users from using Armory. Now it did. I have upgraded the critical paths to handle unicode, and added warnings for everything else. One exception to unicode handling is that you cannot use unicode in your bitcoin.conf username or password, and only in Windows! (it works fine in Linux) Otherwise, I'm hoping this will go a lot better than before!
See the top post for details!
https://bitcointalksearch.org/topic/m.1655941
Jump to: