Os x is moving to an app model anyway
Sounds like Game Over. Apple are turning into the AOL of the operating system world (i.e. rich grandmas need only apply). It's sad stuff.
Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 13. (Read 35724 times)
Sounds like Game Over. Apple are turning into the AOL of the operating system world (i.e. rich grandmas need only apply). It's sad stuff.
Os x is moving to an app model anyway
So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3 
(it is the kind of tasks that any developer hates... Necessary to avoid "technological debt". But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).
(it is the kind of tasks that any developer hates... Necessary to avoid "technological debt". But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).
Heh. Believe me, I'm gung ho for upgrades.
I even did a rough pass at a Qt5 upgrade awhile back. Alas, for various reasons, it may be awhile before Py3/Qt5 (they would, in all likelihood, come paired together) are used in Armory. Anybody who feels strongly enough that we should upgrade ASAP should make some respectful noise. OS X users in particular should speak up. I believe 4.8.7 will be the final Qt4 release, meaning that any support for OSX 10.11 can't be guaranteed.Re: bolded
If it causes any other problems at all with development, I'd like to register my interest in removing support for OSX. It's a minority user group and it's expensive to develop for (both in maintaining the latest version of the development suite, and in the time spent wrestling with what sounds like a very badly supported GUI framework).
You guys have attracted several complaints and little praise for the OSX build up to now, in spite of spending significant resources on it. There's got to come a time when you start deciding whether or not this is at all valuable (and whether it doesn't actually damage the Armory brand more than if it were dropped, at least until OSX can be brought much closer to the usability of Linux & Windows builds). I feel like your time may be better spent concentrating on the builds that aren't so much of a (seemingly accumulating) struggle.
So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3
(it is the kind of tasks that any developer hates... Necessary to avoid "technological debt". But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).
(it is the kind of tasks that any developer hates... Necessary to avoid "technological debt". But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).
Heh. Believe me, I'm gung ho for upgrades.
I even did a rough pass at a Qt5 upgrade awhile back. Alas, for various reasons, it may be awhile before Py3/Qt5 (they would, in all likelihood, come paired together) are used in Armory. Anybody who feels strongly enough that we should upgrade ASAP should make some respectful noise. OS X users in particular should speak up. I believe 4.8.7 will be the final Qt4 release, meaning that any support for OSX 10.11 can't be guaranteed. 
The bad news is that paper backups do not work. When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive. Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up). I remember this being a problem once in the past too, but then the problem appeared to go away.
I can't fully reproduce this. I did see a bit of odd behavior and did see a Qt-related crash at one point. Still, I was able to print a paper backup.
Based off what I've seen here and elsewhere, I believe the problem has to do with how Qt handles modal windows. There's just something inherently broken in Qt4 for OSX that the team refuses to fix, and will never fix. (4.8.7 will supposedly be the last Qt4 release.) I had to port over some fixes from Qt5 awhile back just to make Armory reasonably stable. It seems these fixes aren't enough, unfortunately. For me, the fixes are pretty good. For others, they're not enough. Short of an upgrade to Qt5, I doubt there's much I can do, unfortunately. If anybody wants to take a crack and submit some pull requests, I'll be happy to take a look.
Otherwise, it is what it is.This sounds like a likely explanation. I guess at some point updating to Qt 5 will be inevitable.
So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3
(it is the kind of tasks that any developer hates... Necessary to avoid "technological debt". But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).
Can an Armory data dir/DB be shared between Windows and Ubuntu, e.g. in a VM or dual-boot setup? I tried to have Bitcoin and Armory share (via Shared Folders, Ubuntu is the guest) with Oracle VM VirtualBox and had issues with both.
This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)
And then when I tried to open it in Windows later, it was corrupt:
Currently doing a rebuild/rescan like it suggested.
This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)
And then when I tried to open it in Windows later, it was corrupt:
Currently doing a rebuild/rescan like it suggested.
LMDB detects its page size from the OS it is running under, not it's meta data. If the different OS have different page size, it will completely fail to align the meta pages (remember, it's a mapped DB, it does every thing by address and offsets) and corrupt them. Then your DB will go kebab.
That or it could be something entirely different. I'm not 100% familiar with LMDB's code base, more like 70%. And I've also never tried what you suggested. I remember remember doing it with our LevelDB database between Windows Host and Linux client however, and that worked fine. But I also remember that LevelDB will stick to the page size it finds in its meta data regardless of the supporting OS (for having played with the feature), so this is my prime suspect.
The bad news is that paper backups do not work. When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive. Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up). I remember this being a problem once in the past too, but then the problem appeared to go away.
I can't fully reproduce this. I did see a bit of odd behavior and did see a Qt-related crash at one point. Still, I was able to print a paper backup.
Based off what I've seen here and elsewhere, I believe the problem has to do with how Qt handles modal windows. There's just something inherently broken in Qt4 for OSX that the team refuses to fix, and will never fix. (4.8.7 will supposedly be the last Qt4 release.) I had to port over some fixes from Qt5 awhile back just to make Armory reasonably stable. It seems these fixes aren't enough, unfortunately. For me, the fixes are pretty good. For others, they're not enough. Short of an upgrade to Qt5, I doubt there's much I can do, unfortunately. If anybody wants to take a crack and submit some pull requests, I'll be happy to take a look.
Otherwise, it is what it is.
Can an Armory data dir/DB be shared between Windows and Ubuntu, e.g. in a VM or dual-boot setup? I tried to have Bitcoin and Armory share (via Shared Folders, Ubuntu is the guest) with Oracle VM VirtualBox and had issues with both.
This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)
And then when I tried to open it in Windows later, it was corrupt:
Currently doing a rebuild/rescan like it suggested.
This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)
And then when I tried to open it in Windows later, it was corrupt:
Currently doing a rebuild/rescan like it suggested.
1) (Supernode) "Import Lockbox" > "Done". The "Import Successful" window has the text "If the lockbox is not new and has been used before, Armory will not know about its history until you rescan the databases" which isn't true in supernode.
2) In Lockboxes, select a lockbox and then use the arrow keys up or down. The bitcoin address displayed will not update but when you go to click on almost everything you are actually using the new wallet. You need to click on the lockbox to update the displayed address.
3) "Lockbox" > Check "Simul" > "Merge Promissory Notes" doesn't provide any warning if you create a transaction and don't provide a fee.
2) In Lockboxes, select a lockbox and then use the arrow keys up or down. The bitcoin address displayed will not update but when you go to click on almost everything you are actually using the new wallet. You need to click on the lockbox to update the displayed address.
3) "Lockbox" > Check "Simul" > "Merge Promissory Notes" doesn't provide any warning if you create a transaction and don't provide a fee.
May I suggest a selected wallet filter
Should it be hidden, moved, or left where it is? Should it be totally user configurable.
Ideally, whatever it is can be non-intrusive enough to have visible all the time and not inconvenience users that have small transaction histories and/or don't need the fancy controls.
Ideally, whatever it is can be non-intrusive enough to have visible all the time and not inconvenience users that have small transaction histories and/or don't need the fancy controls.
I think this would be best achieved with the widget staying where it is, but make it very transparent, almost invisible. Then, when the user hovers the mouse in the vicinity (maybe 100 pixels) of the widget, it becomes opaque. Make that one setting, and then opaque all the time another. And maybe disabled completely a third. Just my 5 cents.
I suspect this is a OSX playing nasty with Qt kind of error which eventually trickled down into triggering that error message.
I just tried the newest version (Mac OS X version 10.9.5).
The good news is that building the first database was much faster than it used to be, and that starting up second time was lightning fast.
The bad news is that paper backups do not work. When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive. Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up). I remember this being a problem once in the past too, but then the problem appeared to go away.
EDIT: Then I tried to actually make a transaction. I got this strange error:
I get this every time I try to make a transaction
EDIT 2:
I could not export the log file (menu item greyed out). In fact, Armory was completely stuck, had to Force Quit it to get away from the send bitcoin window. Now it rescans the database, good thing that it takes minutes instead of an hour or two as in the previous version
I exported the log file while it did that, there is no hint of trouble there.
EDIT 3:
I cannot reproduce it. Once Armory had finished rescanning, I tried again, this time without problems.
I really wonder what kind of "quirk in the way Bitcoin transactions work" this pop-up is supposed to be triggered by...
The good news is that building the first database was much faster than it used to be, and that starting up second time was lightning fast.
The bad news is that paper backups do not work. When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive. Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up). I remember this being a problem once in the past too, but then the problem appeared to go away.
EDIT: Then I tried to actually make a transaction. I got this strange error:
Quote
There was an error constructing your transaction, due to a quirk in the way Bitcoin transactions work. If you see this error more than once, try sending your BTC in two or more separate transactions.
What can this possibly mean?I get this every time I try to make a transaction
EDIT 2:
I could not export the log file (menu item greyed out). In fact, Armory was completely stuck, had to Force Quit it to get away from the send bitcoin window. Now it rescans the database, good thing that it takes minutes instead of an hour or two as in the previous version
I exported the log file while it did that, there is no hint of trouble there.
EDIT 3:
I cannot reproduce it. Once Armory had finished rescanning, I tried again, this time without problems.
I really wonder what kind of "quirk in the way Bitcoin transactions work" this pop-up is supposed to be triggered by...
When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.
Can you provide more exact directions? I can't seem to reproduce this. That said, my suspicion is that, for whatever reasons, this is a Qt issue. I ran into something like this before with Qt 4.8.6. The upgrade to 4.8.7 helped me but doesn't seem to help other people. There's really not much that can be done for now, other than adding the button. You may want to try hitting the escape button. That helped me sometimes when I got stuck.
Also, please check your PMs. I sent one awhile back.
Is there any way to "sort" the wallet's in the main display? I know it's being trivial and anal on my part but I'd like to see the wallets presented in a certain order. For instance I'd like to see the wallets presented alphabetically by name or by type with "Watch-Only" wallets at the bottom of the wallet list. As I see it now wallets are displayed by ID so it's a toss-up as to where the wallet gets placed in the display after creation.
No such thing currently, we could consider adding a filter for wallet names on top of IDs.
When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.
I can't reproduce that, can you elaborate on the exact steps and the dialog displaying this behavior? Also this is possibly a OSX thing only.
When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.
Also regarding the little paging widget, instead of obstructing the transactions, I think it should be made into text boxes below transactions like before and a button to update the screen, maybe a Go To button or something like that
Also regarding the little paging widget, instead of obstructing the transactions, I think it should be made into text boxes below transactions like before and a button to update the screen, maybe a Go To button or something like that
Is there any way to "sort" the wallet's in the main display? I know it's being trivial and anal on my part but I'd like to see the wallets presented in a certain order. For instance I'd like to see the wallets presented alphabetically by name or by type with "Watch-Only" wallets at the bottom of the wallet list. As I see it now wallets are displayed by ID so it's a toss-up as to where the wallet gets placed in the display after creation.
1) In the paging control widget if you put a negative "-" in the block number and hit enter nothing happens and this is the log:
2) In the paging control widget if you put letters in the block number and hit enter nothing happens and this is the log:
3) In the paging control widget if you set the year to something old, such as 1750, you get the following error:
4) In the paging control widget if you click on the date and in the new window select the year, put a negative "-" in the year (such as -2014) and select a date:
5) In the paging control widget, if you are not already scrolled to the top, click on "#" > "Block" as if you were going to edit it and then click on "Top". The widget will end up horizontally spanning across all the transactions.
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'
2) In the paging control widget if you put letters in the block number and hit enter nothing happens and this is the log:
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'
3) In the paging control widget if you set the year to something old, such as 1750, you get the following error:
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
self.editDate()
File "/usr/lib/armory/armorymodels.py", line 780, in editDate
self.dateChanged()
File "/usr/lib/armory/armorymodels.py", line 794, in dateChanged
self.Date = int(time.mktime(ddate.timetuple()))
ValueError: year out of range
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
self.editDate()
File "/usr/lib/armory/armorymodels.py", line 780, in editDate
self.dateChanged()
File "/usr/lib/armory/armorymodels.py", line 794, in dateChanged
self.Date = int(time.mktime(ddate.timetuple()))
ValueError: year out of range
4) In the paging control widget if you click on the date and in the new window select the year, put a negative "-" in the year (such as -2014) and select a date:
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
self.editDate()
File "/usr/lib/armory/armorymodels.py", line 780, in editDate
self.dateChanged()
File "/usr/lib/armory/armorymodels.py", line 796, in dateChanged
self.Blk = TheBDM.bdv().getClosestBlockHeightForTime(self.Date)
File "/usr/lib/armory/CppBlockUtils.py", line 2012, in getClosestBlockHeightForTime
def getClosestBlockHeightForTime(self, *args): return _CppBlockUtils.BlockDataViewer_getClosestBlockHeightForTime(self, *args)
OverflowError: in method 'BlockDataViewer_getClosestBlockHeightForTime', argument 2 of type 'uint32_t'
Traceback (most recent call last):
File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
self.editDate()
File "/usr/lib/armory/armorymodels.py", line 780, in editDate
self.dateChanged()
File "/usr/lib/armory/armorymodels.py", line 796, in dateChanged
self.Blk = TheBDM.bdv().getClosestBlockHeightForTime(self.Date)
File "/usr/lib/armory/CppBlockUtils.py", line 2012, in getClosestBlockHeightForTime
def getClosestBlockHeightForTime(self, *args): return _CppBlockUtils.BlockDataViewer_getClosestBlockHeightForTime(self, *args)
OverflowError: in method 'BlockDataViewer_getClosestBlockHeightForTime', argument 2 of type 'uint32_t'
5) In the paging control widget, if you are not already scrolled to the top, click on "#" > "Block" as if you were going to edit it and then click on "Top". The widget will end up horizontally spanning across all the transactions.
Not a horrible problem but... I've been playing with .5 on Windows 7. If you try to restore a wallet from digital backup Armory prompts for the file name twice. Like I said not terrible. It works, but you have to answer the file name prompt twice.
Most likely related to some changes trying to improve the OSX file browser, we'll get it under control.
Gaaaaah, you're right, I forgot to clean something up when reverting the OS X fix. Will fix it right away.
1) Exporting transactions doesn't actually export the file until you've done it a second time. "File" > "Export Transactions" > "Export" will make a file that will be 0 bytes in size. Now do the same thing again but select a different wallet to output, the first file will now be filled in properly and the new file will be 0 bytes in size. This cycle continues with every new file that is created being 0 bytes until another export has been done. This also shows up in the error log:
2) Can't restore from fragmented backups. "Import or Restore Wallet" > "Fragmented Backup" > "Continue"
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/qtdialogs.py", line 9589, in accept
if self.createFile_CSV():
File "/usr/lib/armory/qtdialogs.py", line 9723, in createFile_CSV
combinedLedger = walletGroup.getHistoryPage(page)
File "/usr/lib/armory/CppBlockUtils.py", line 2046, in getHistoryPage
def getHistoryPage(self, *args): return _CppBlockUtils.WalletGroup_getHistoryPage(self, *args)
TypeError: WalletGroup_getHistoryPage() takes exactly 4 arguments (2 given)
Traceback (most recent call last):
File "/usr/lib/armory/qtdialogs.py", line 9589, in accept
if self.createFile_CSV():
File "/usr/lib/armory/qtdialogs.py", line 9723, in createFile_CSV
combinedLedger = walletGroup.getHistoryPage(page)
File "/usr/lib/armory/CppBlockUtils.py", line 2046, in getHistoryPage
def getHistoryPage(self, *args): return _CppBlockUtils.WalletGroup_getHistoryPage(self, *args)
2) Can't restore from fragmented backups. "Import or Restore Wallet" > "Fragmented Backup" > "Continue"
Code:
(ERROR) Traceback (most recent call last):
File "/usr/lib/armory/qtdialogs.py", line 12243, in clickedOkay
dlg = DlgRestoreFragged(self.parent, self.main, doTest)
File "/usr/lib/armory/qtdialogs.py", line 12921, in __init__
doItText = tr('Test Backup' if thisIsATest else tR('Restore from Fragments'))
NameError: global name 'tR' is not defined
Traceback (most recent call last):
File "/usr/lib/armory/qtdialogs.py", line 12243, in clickedOkay
dlg = DlgRestoreFragged(self.parent, self.main, doTest)
File "/usr/lib/armory/qtdialogs.py", line 12921, in __init__
doItText = tr('Test Backup' if thisIsATest else tR('Restore from Fragments'))
NameError: global name 'tR' is not defined
Jump to: