Topic: RAM-Reduction & Backup Center Testing (version 0.89.99.16) - page 12. (Read 41296 times)

Well just because it works on OSX, doesn't mean that the database/build/scan bugs are fixed.  I still have a lot of work to do on that front, but at least I have the tools now to debug it easier...

Unfortunately, one of the caveats of picobit's solution is the difficulty of passing command-line arguments.  I might "hack" something that will work from the menu:  Armory will check for a "rebuild.txt" or "rescan.txt" file at startup, if it finds it, it will delete it and then do the rebuild or rescan.  The menu option will simply write the file and then close the app.  This makes it fairly simple to force the rebuild or rescan, and also make it easy to induce it from within the app (I had problems before, trying to force this to happen after the app was already running). 

I'll make sure that's in the next version.  Unfortunately, we'll still need a real solution to the CLI-argument issue, since you can't set the --datadir this way. Though, for everything else, I suppose I could use an armory.conf file just like the bitcoin.conf file...

Yay picobit!

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/Armory.app.0.89.99.9-testing.tar.gz

That 40 MB tar.gz unpacks into a 136 MB Armory.app directory, which should be double-clickable to run Armory.  I successfully compiled it on my MacMini, after review the build-app.py script that picobit gave me, and then successfully running it.  There was a few hiccups in the build process, but it ultimately worked.  And kudos to picobit for not only giving me a script, but being diligent about creating and sorting log files for each command so I could easily figure out what went wrong.  

Please test it on your OSX system.  Especially on 10.9, and especially on any systems where the download from the webpage didn't work.  I want to find out if this .app works better than the one we originally got from higuys.  I'm hopeful based on els' statements that it worked on both 10.8 and 10.9, but I definitely need more empirical evidence.  

By the way, this is actually 0.89.99.9.  This has a feature merged in from CircusPeanut that fixes the broadcast issue people experience when using older versions of Armory on the offline computer.  The issue was that the core devs implemented a soft-rule requiring normalized signature padding, and older versions of Armory didn't do that.  Thus when you sign with the older version, the tx will be rejected if you are running Bitcoin-Qt/bitcoin 0.8.2 or newer.  This version works around that by exploiting the same transaction malleability that the core devs were trying to reduce!  It adjusts the signature padding of the already-signed transaction -- it changes the hash of the transaction but makes the transaction not only valid, but isStandard() so it will broadcast correctly.  

If you are experiencing that broadcast issue, you can:  (Linux) Pull the latest testing branch and use that (OSX) Use this .app (Windows) Wait for the next testing release.  

You want to checkout instead of clone for that part.

Thanks all of the instructions were exactly the same.  Armory is running now and I learned a couple new things.  Have a great day!

Disclaimer: I too am I Linux n00b, but here are the steps I used to compile (successfully) on Ubuntu:

Install dependencies:

Clone Armory Git:

Change to newly created directory of git repo:

Switch to the 'testing' branch:

Change to folder which is home to a file which needs editing:

Open the file which needs editing in a text editor:

// Comment out or delete line 18 (" #define strdup _strdup"), save and close c.cc

Switch back to the root directory:

Compile:

Run the program (you will have to run this command to open Armory each time you want to open it, make sure you have 'cd' into 'BitcoinArmory' directory first each time though!:


Notes:
gedit is a simple text editor which is installed by default in Ubuntu, if this is different in Debian you might have to change the step "gedit c.cc" but IDK.

Also, I guess some of the packages/dependencies required (first line of code) might differ in Debian, but I think Debian & Ubuntu are pretty similar in that way.

Hope this helps.

Linux n00b and dangerous so .....

I am trying to compile from source on  Debian.  When I do "git clone testing" Debian craps out
 bob@debian:~/BitcoinArmory$ git clone testing
Cloning into testing...
warning: You appear to have cloned an empty repository.

I had already ran the original git command as noted in "Building Armory from source"
Thanks in advance.

i've been doing testing in linux and windows, but as a mac user i am really excited to report that a pkg picobit was kind enough to share with me installed cleanly on both OS X 10.8 & 10.9.  on 10.9 i have a full blockchain so i can see the balance from a small test transaction in the wallet; no other testing as of yet.

i know there are issues to be worked out such as command line arguments not passing and needing to get a formal build process for this, but this is sweet even as it is.

thanks picobit!

If you have coins you can't access because of the Mac OS then just dual boot linux or run it in a virtual machine.

Mac is definitely a high priority right now.  I also should put in an informational channel to communicate with users like "Armory does not yet work with OSX 10.9.  If you upgrade you may temporarily lose access to your Armory wallet". 

Things like Windows XP and obscure (err... less-popular) flavors of Linux will be lower priority for now.   Luckily, goatpig has helped out tremendously with Windows in general, so I'm down to just a couple bugs left (though one is going to be a pain to fix), and then OSX support.  I'm going to make it my mission to try to get picobit's OSX solution working before the end of the weekend.   We'll see where it goes from there.

It sounds like goatpig might have a decent XP solution, but I will leave it to those who really want it to try to get it working.  Too many other things for me to worry about right now.

I have to agree, I think Alan is spread a little too thin, doing so much cool stuff, while trying to make it multi-OS usable. That will never work, I think Alan should be trying to get a good build process that will be able to output windows, linux and Mac binaries. Until then development has to be paused otherwise it will always be a rat race with new developments and OS binaries.

Agreed. It makes no sense to concentrate any effort into backwards compatibility when the trend is that the very PC's I'm referring to will eventually die in the heat of a desert somewhere, and this notional hard-up Bitcoin user ends up with a cast off Vista machine in replacement. If it can be done for the low cost of an experienced developer's pre-existing comprehensive knowledge of compatibility of compiling, as is the case with goatpig, then it's good to have.

To be clear, I have nothing against accommodating those OSes.  It's just a matter of priorities.  If we can support it, I'd be happy to, but I need to get some of the more critical usability issues out of the way, first.

Ok sorry about the folder. I'm in front of a XP machine right now and can't really find the folder. Not my machine though as I'm not home, so I'm not gonna install anything on it. I've given up on the xp toolset and will iron out a msvc9 toolset build as I get back home.

I have personally run msvc9 toolset built code on Win2k. From what I've seen of the Armory source, I think there's a 2/3rd chance it could run on Win2k. I'm 99% positive I can get the current Armory code to run on XP. Just a matter of testing the build first hand.

That increasingly shrinking proportion of XP users are increasingly going to be comprised of the people with (seemingly) no choice but XP; the poor (as well as those with poor opportunities to get hold of machines capable of running modern OS's, which are mostly still the economically poor). I know, I know, with a bit of work they could install a nice undemanding Linux distro that would be a much better all ways round, but that underestimates how protective the less computer savvy sort of individual would be over their only working PC. The extent to which such a machine, in a known working order, is valued by such a person perhaps cannot be overestimated; they might depend on it for a current system to receive foreign remittances, for instance.

I'd be very amused to hear of Nepalese or Zimbabwean Armory users making successful use of Armory on a 384 Mb 1Ghz XP machine! If they could even thrive with such a setup, then that would really be something. (has anyone ever tested it on Windows 2000?  )

thanks.  tried searching again, per above.  i do find a few, but attributable to other programs and not with current date.  i also am not finding the path Program Files/Visual Studio 9.0/ or anything like it, though i did reinstall the package to be sure there were no errors.  oh well.

You'll have to use XP's search feature ( select Start, then Search, then "All files and folders", and then type in the name of the file... )
you will probably find a few different files of that name in different places.

Check the date to make sure you grab the one you just installed.  You might not have much luck getting it to work,
like me, but let us know how you do.

Are you referring to this?  If not, I've missed another link somewhere.

> 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.

Yes, I installed the above.  Can't find an instance of the .dll from it though....

Judging by the time stamp displayed in the filemanager the msvcp90.dll I used was the one I installed just yesterday from that link you provided.

Looking forward to that new update you talk about above... I can wait til Monday. 

( Over the weekend I was going to install a version of linux in virtualbox and install armory in there... so maybe I can use that, for at least a temporary location for an offline wallet. I hope there are no security issues in doing something like that, as long as I don't allow networking. )

Thanks for your efforts.

It needs to be the msvcp90.dll from the package I linked. There are several versions of this DLL distributed by MS and py2exe only links against the one from that package. Regardless, I've concluded this path is too convoluted. I've found a simple way to build the entire project with msvc9/10 toolsets, that still support WinXP. I'll update the msvs projects once I'm back home, push them to my branch and have Alan build and distribute a test version with these. So this'll have to wait till Monday, sorry.