RAM-Reduction & Backup Center Testing (version 0.89.99.16)

[etotheipi]

Stupid question: are you using a manually edited bitcoin.conf?

Goatpig, you hero. It was indeed a faulty conf file. Top detective work and shame on me!

Awesome!  I will add that to the troubleshooting page.  At least a couple problems people have had, turned out to be bitcoin.conf issues, but not enough that I remember it as a common troubleshooting tip.

[goatpig]

Stupid question: are you using a manually edited bitcoin.conf?

Goatpig, you hero. It was indeed a faulty conf file. Top detective work and shame on me!

I'm actually relieved it was the .conf, I was running out of places to look at o.o

[Dabs]

Traceback (most recent call last):
  File "ArmoryQt.py", line 21, in <module>
  File "psutil\__init__.pyc", line 85, in <module>
  File "psutil\_psmswindows.pyc", line 15, in <module>
  File "_psutil_mswindows.pyc", line 12, in <module>
  File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.

Still not working for me. Sorry.

Just to be clear, my machines (I have 2 laptops) are both on Win XP SP3 updated with ms update to this month, with almost nothing else installed. (2 gig ram only.)

[etotheipi]

Traceback (most recent call last):
  File "ArmoryQt.py", line 21, in <module>
  File "psutil\__init__.pyc", line 85, in <module>
  File "psutil\_psmswindows.pyc", line 15, in <module>
  File "_psutil_mswindows.pyc", line 12, in <module>
  File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.

Still not working for me. Sorry.

Just to be clear, my machines (I have 2 laptops) are both on Win XP SP3 updated with ms update to this month, with almost nothing else installed. (2 gig ram only.)

Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset.   Unless goatpig has a recommendation for this, I'm not sure I see a way around it.   I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.

Ugh.

[Dabs]

Traceback (most recent call last):
  File "ArmoryQt.py", line 21, in <module>
  File "psutil\__init__.pyc", line 85, in <module>
  File "psutil\_psmswindows.pyc", line 15, in <module>
  File "_psutil_mswindows.pyc", line 12, in <module>
  File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.

Still not working for me. Sorry.

Just to be clear, my machines (I have 2 laptops) are both on Win XP SP3 updated with ms update to this month, with almost nothing else installed. (2 gig ram only.)

Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset.   Unless goatpig has a recommendation for this, I'm not sure I see a way around it.   I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.

Ugh.

Thanks for trying. I will eventually upgrade OS... I'm just one of those who like to stick it out for as long as I can. (The end of life support for XP is April 2014.)

[goatpig]

Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset.   Unless goatpig has a recommendation for this, I'm not sure I see a way around it.   I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.

Ugh.

I don't have anything on this. I have compiled simple code and successfully had it work on WinXP with this toolset before. I can't give you more info without looking at the behavior myself. I'll set up a WinXP guest at some point and give it a look.

[etotheipi]

Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset.   Unless goatpig has a recommendation for this, I'm not sure I see a way around it.   I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.

Ugh.

I don't have anything on this. I have compiled simple code and successfully had it work on WinXP with this toolset before. I can't give you more info without looking at the behavior myself. I'll set up a WinXP guest at some point and give it a look.

It might be possible to merge the .dlls from the old 0.88.1 release which was compatible with WinXP, with the new version with all the Armory code compiled using the XP toolset.  But that could be a mess and might not end up working.  I'm afraid that our move to MSVS 2012 may have shut out Windows XP users. 

[goatpig]

Give me a couple days and I'll investigate to code in a WinXP environment. Just don't pull the plug yet!

Last but not least, I can port the atomic types and operations to WinAPI calls. That would let you compile in MSVS 2008/10 and would entirely go around the whole issue. This is the only part of the code that isn't backwards compatible with earlier compilers.

[etotheipi]

Give me a couple days and I'll investigate to code in a WinXP environment. Just don't pull the plug yet!

Last but not least, I can port the atomic types and operations to WinAPI calls. That would let you compile in MSVS 2008/10 and would entirely go around the whole issue. This is the only part of the code that isn't backwards compatible with earlier compilers.

No offense to Dabs (sorry Dabs!), but I'm not convinced there's a reasonable cost-to-benefit ratio for this past a couple hours of work.  For every day that we spend on it, the number of potential XP users in the world shrinks by 2%...


EDIT:  To be clear, please take a shot at doing it.  I just don't want to spend a lot of resources working on it, because there's other priorities.   Well, assuming your priorities are aligned with mine

[goatpig]

assuming your priorities are aligned with mine

Try to take over the world? I think there's a quick fix to turn on LevelDB internal atomic ports

[goatpig]

I don't know if Alan got my email as gmail decided to stop working right when I figured out the trick. I'll update the projects and push it to the repo tomorrow. That one should get Armory working on WinXP.

[Dabs]

No offense to Dabs (sorry Dabs!)

None taken.

But you have to understand, a lot of corporate environments tend to stick to really really old ancient operating systems and other software. I'm not exactly there, since this is personal usage, but I understand enough to know that I can do almost anything on an older OS like XP while taking up less resources.

I do think, a bitcoin wallet should be able to work on something like XP. (well, QT still works on 32 bit XP, so I'm not complaining.)

[etotheipi]

Has anyone else had issues with Armory in the new Mavericks update for OS X?
Is there any update for it?
I'm currently running the latest version of armory and mine just does not run at all...I've got around 20 or so bitcoins stuck in there and I really do hope I haven't lost them all.
I did research seeing if OSX 10.9 wasn't compatible Armory though didn't find anything, until it happened to me.
anyone know what I can do?
I tried editing the info.plist's to change max versions and still didn't work no matter what I did :/

Yeah, so far everything has broken on 10.9.  Picobit gave me a script for building a more-standalone version of Armory on OSX, which should hopefully resolve this problem on most versions of OSX, and hopefully Mavericks, too.  And hopefully we'll get a new guy soon that will be better experienced with OSX in order to battle these OSX problems.

I just caught the "Marking Orphan Chain" bug in the debugger, which I've been hoping to do for days!  If I fix that bug, then I'll be under a lot less stress and can maybe take a shot at this.  Stay tuned and thanks for being patient!

[goatpig]

No offense to Dabs (sorry Dabs!)

None taken.

But you have to understand, a lot of corporate environments tend to stick to really really old ancient operating systems and other software. I'm not exactly there, since this is personal usage, but I understand enough to know that I can do almost anything on an older OS like XP while taking up less resources.

I do think, a bitcoin wallet should be able to work on something like XP. (well, QT still works on 32 bit XP, so I'm not complaining.)

Can you install this: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

Then try again to run the last win_xp build Alan gave you.

[els]

No offense to Dabs (sorry Dabs!)

None taken.

But you have to understand, a lot of corporate environments tend to stick to really really old ancient operating systems and other software. I'm not exactly there, since this is personal usage, but I understand enough to know that I can do almost anything on an older OS like XP while taking up less resources.

I do think, a bitcoin wallet should be able to work on something like XP. (well, QT still works on 32 bit XP, so I'm not complaining.)

Can you install this: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

Then try again to run the last win_xp build Alan gave you.

i tried this on XP Pro SP3 32-bit (with nothing else special installed), then installed the xp build from earlier in this thread.  still getting the same errors in logfile upon running:

Traceback (most recent call last):
  File "ArmoryQt.py", line 21, in <module>
  File "psutil\__init__.pyc", line 85, in <module>
  File "psutil\_psmswindows.pyc", line 15, in <module>
  File "_psutil_mswindows.pyc", line 12, in <module>
  File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.

did i miss another implied step somewhere in this?

[picobit]

Yeah, so far everything has broken on 10.9.  Picobit gave me a script for building a more-standalone version of Armory on OSX, which should hopefully resolve this problem on most versions of OSX, and hopefully Mavericks, too.  And hopefully we'll get a new guy soon that will be better experienced with OSX in order to battle these OSX problems.

I just caught the "Marking Orphan Chain" bug in the debugger, which I've been hoping to do for days!  If I fix that bug, then I'll be under a lot less stress and can maybe take a shot at this.  Stay tuned and thanks for being patient!

And I have been very passive recently due to being busy with other things.  I have an issue or two with my build script and the latest changes to Armory, but they are Makefile related and I will have a look at it in the weekend.  I will still be using Mountain Lion for a few weeks, but should then soon be able to test with Maverick too.

There is a vexing issue with OS X: If the database is messed up (and that happens too often), it is hard to call Armory with --rescan.  Passing command line arguments to OS X apps is possible (but not elegant), but the actual app is a script that calls Python, and that script does not pass through command line arguments.  If it did, Armory would refuse to start, since OS X per default sets some strange command line arguments (windows position, perhaps), and Armory cannot parse them.

[etotheipi]

Yeah, so far everything has broken on 10.9.  Picobit gave me a script for building a more-standalone version of Armory on OSX, which should hopefully resolve this problem on most versions of OSX, and hopefully Mavericks, too.  And hopefully we'll get a new guy soon that will be better experienced with OSX in order to battle these OSX problems.

I just caught the "Marking Orphan Chain" bug in the debugger, which I've been hoping to do for days!  If I fix that bug, then I'll be under a lot less stress and can maybe take a shot at this.  Stay tuned and thanks for being patient!

And I have been very passive recently due to being busy with other things.  I have an issue or two with my build script and the latest changes to Armory, but they are Makefile related and I will have a look at it in the weekend.  I will still be using Mountain Lion for a few weeks, but should then soon be able to test with Maverick too.

There is a vexing issue with OS X: If the database is messed up (and that happens too often), it is hard to call Armory with --rescan.  Passing command line arguments to OS X apps is possible (but not elegant), but the actual app is a script that calls Python, and that script does not pass through command line arguments.  If it did, Armory would refuse to start, since OS X per default sets some strange command line arguments (windows position, perhaps), and Armory cannot parse them.

At one point I added rescan and rebuild buttons, but they didn't behave properly.  I decided that they needed to occur before the app loaded.  With some luck, these upcoming bug fixes will require that a lot less frequently.  Or I'll find another mechanism to do it.

The makefile was updated by goatpig to do a more-intelligent search for the python dependencies.  It's very possible that you may need to just branch that whole section if compiling on OSX/Darwin.

[Mooshire]

Coming back to the good clients, what do you reccommend right now for a 64-bit win8 user with 8 GB of RAM?

[etotheipi]

Coming back to the good clients, what do you reccommend right now for a 64-bit win8 user with 8 GB of RAM?

Still 0.88.1 from the website.  Feel free to help test this version, but I'm fairly certain that the crashing bugs are bit too much for most people.  I finally caught the biggest one in the debugger, but it doesn't look like it's going to be easy to fix.  So it may still be a few days...

[e4xit]

Stupid question: are you using a manually edited bitcoin.conf?

Goatpig, you hero. It was indeed a faulty conf file. Top detective work and shame on me!

Awesome!  I will add that to the troubleshooting page.  At least a couple problems people have had, turned out to be bitcoin.conf issues, but not enough that I remember it as a common troubleshooting tip.

etotheipi,

If it helps your FAQ/troubleshooting page, my conf file (which didn't work) was the result of just downloading the 'bitcoind' package via the terminal

Code:

sudo apt-get install bitcoind

and then simply running

Code:

bitcoind

which presents you with an error saying that you must create a bitcoin.conf file with

Code:

server = 1
rpcuser = your_username
rpcpassword = your_unique_password

which I duely did...This seemed to be causing the errors (perhaps I wrote the .conf file wrong; it was written by hand but bitcoind seemed to run with no errors on its own from the terminal).

Then in response to goatpig's suggestion that it could be the .conf file causing the non-reported errors, I visited
https://en.bitcoin.it/wiki/Running_Bitcoin#Sample_Bitcoin.conf
and copy/pasted the "sample" .conf file, which I then uncommented only 'server', 'rpcuser' and 'rpcpassword' fields and set to '1', 'myusername' and 'mypassword' respectively.

Which got everything working again. Hope this help explain how/where I got stuck and how it was fixed.