Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Yes, I use my super old mac mini and it works like a charm.
Topic: [ANN] The first Armory-for-OSX Release! (Testing) (Read 4621 times)
Yes, I use my super old mac mini and it works like a charm.
Would appreciate if somebody could check if offline/noblockchain access works or gives errors.
thanks
BeeCoin.
thanks
BeeCoin.
Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Never tried the offline in OSX, I use Ubuntu 10.04 for the offline version.
Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Just to let you know that I've been thoroughly testing Armory on OSX with flawless results up to know - I just have some display problems (coin control display its a bit screwed), but functionalities are 100% working and stable.
Using OS X 10.8.3 on a 2,53 GHz Intel Core 2 Duo with 8GB of RAM.
Using OS X 10.8.3 on a 2,53 GHz Intel Core 2 Duo with 8GB of RAM.
You might consider doing Red Emerald's brew formula if that's all you want access to. Obviously, it would be better to just have this work, but apparently the dependencies are still not totally standalone/bundled yet.
Thanks for your prompt response, Etotheipi.At this point, just for using the EC Calculator, I will simply run it on Windows within a VM.
In the long run, if OSX glitches have been worked out, I'd be interested in using Armory with more functions.
-BeeCoin.
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
Hi folks
I get the same error message (except the french part ;-) ) on Mac OSX Lion. Any solution for this?
At the moment, I want to use it only as EllipticCurve-Calculator in --noblockchain mode without any BitcoinClient installed.
best regards
-BeeCoin.
You might consider doing Red Emerald's brew formula if that's all you want access to. Obviously, it would be better to just have this work, but apparently the dependencies are still not totally standalone/bundled yet.
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
Hi folks
I get the same error message (except the french part ;-) ) on Mac OSX Lion. Any solution for this?
At the moment, I want to use it only as EllipticCurve-Calculator in --noblockchain mode without any BitcoinClient installed.
best regards
-BeeCoin.
Fwhew! The issues are slowly fading away...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
I can't wait! Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Fwhew! The issues are slowly fading away...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
I deleted the bitcoin directory, installed a fresh copy of bitcoin-qt 0.8.1 and downloaded the whole block chain.
I can cofirm that Armory is now working perfectly!
Thanks. I just sent via PM. I created a new wallet and repeated the same crash.
.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Can you try restart Armory and do it with a new wallet? Can you decrypt other wallets? I've seen an error like this when the wallet was corrupted. Perhaps it was corrupted immediately, somehow? It will fail on any operation that requires unlocking.
Also, please send me a log file. If the error is what I think it is, it'll have a "Stored public key does not match private key!" error (or something like that).
Thanks for the report.
.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
- Notifications are disabled completely. Apparently this solution does not play nicely with Growl. 0.5 BTC to anyone who figures out how to fix it!
I will add 0.5 BTC to this "bounty" to get growl working. I'm sure this would happen after all the bugs are worked out.
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
Thanks for your analysis. Actually, I had problems with my local block chain some weeks ago and already re-downloaded the whole thing. Then I again had problems and switched to Bitcoin-qt 0.7.2 – but there's probably still some faulty data on my computer. An I guess you're right that this is the reason for problems with Armory as well.
I will download the block chain again and I'm looking forward to the next release of Armory. It's simply the best app out there and I really appreciate you working on this!
FWIW the beta OSX client seems to be much faster than the one I compiled from the homebrew packages
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah!
People will use it to play Satoshi Dice anyway, so that is only fitting 
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
Jump to: