Building Armory and using Python Examples...

[tpofo]

First off, I think Armory is the best wallet. It is the only wallet I use.

Recently, I have been playing around with the python scripting in Armory.  I managed to successfully build Armory from source on windows using VS2013.  I ran Armory from python.  Everything works correctly.

I built Armory exactly with the versions of 32bit tools that were defined by the compiling in windows doc.  I used exact versions of everything.
I am using swigwin2.04 as well.  Compiling and post build process succeeded in 4 successful projects.

Now, when I try running some of the examples you included: 
Specifically testswig.py, examples in extras, and examples in pytest, I get some weird errors.
Some examples run perfectly, however, ones that I want to test like scanning the blockchain for a certain address/wallet fail.

I usually get:

Traceback (most recent call last):
  File "C:\API\Projects\BitcoinArmory\extras\sample_armory_code.py", line 29, in <module>
    cppWallet.addAddress_1_( hex_to_binary('11b366edfc0a8b66feebae5c2e25a7b6a5d1cf31') )  # hash160 (hex)
  File "..\CppBlockUtils.py", line 1690, in <lambda>
    __getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
  File "..\CppBlockUtils.py", line 53, in _swig_getattr
    raise AttributeError(name)
AttributeError: addAddress_1_

OR

(ERROR) Traceback (most recent call last):
  File "C:\API\Projects\BitcoinArmory\extras\sample_armory_code.py", line 83, in <module>
    cppWallet.addAddress_1_( hex_to_binary('0cdcd0f388a31b11ff11b1d8d7a9f978b37bc7af') )
NameError: name 'cppWallet' is not defined

Traceback (most recent call last):
  File "C:\API\Projects\BitcoinArmory\extras\sample_armory_code.py", line 83, in <module>
    cppWallet.addAddress_1_( hex_to_binary('0cdcd0f388a31b11ff11b1d8d7a9f978b37bc7af') )
NameError: name 'cppWallet' is not defined

Basically, I would like a simple working script for scanning blockchain quickly for an address in my local armory blockchain dir.

As an aside, is it possible to use your API without python?  I enjoy using C++ more directly.  But, no matter, I am comfortable just the way you have the python scripting working if it is too much trouble to explain.

Thanks in advance.

[goatpig]

Which branch did you pull? You should pull dev, it has up to date Python unit tests. Some of those in master have been neglected or totally replaced in dev.

Basically, I would like a simple working script for scanning blockchain quickly for an address in my local armory blockchain dir.

It isn't "that" simple. If you use Armory bare mode, you have to create a wallet, add the scrAddr, register the wallet and let Armory scan it (20~40min). If you want instant returns you need supernode, which is still being worked on in charles-refactor-blockchain. Careful as this branch gets some large code changes on a regular basis. It has also diverges a lot from other branches (overhauled back end and stuff), but it will eventually be merged into dev.

As an aside, is it possible to use your API without python?  I enjoy using C++ more directly.

Include the source directly in your project or build a static lib and include the headers in your own project. You can look at the C++ unit test for an example of a SWIG-less build.

[tpofo]

Thanks for the help.  I was using the master.  I tried the dev branch and same problem.
The testswig.py in cppforswig has some code that needed to be changed.

from btcarmoryengine import *
must be changed to:
from armoryengine.ALL import *

It runs, however, same swigwin problem:

Traceback (most recent call last):
  File "C:\API\Projects\BitcoinArmory-dev\cppForSwig\testswig.py", line 42, in <module>
    bdm.readBlkFile_FromScratch(blkfile)
  File "..\CppBlockUtils.py", line 1785, in <lambda>
    __getattr__ = lambda self, name: _swig_getattr(self, BlockDataManager_LevelDB, name)
  File "..\CppBlockUtils.py", line 53, in _swig_getattr
    raise AttributeError(name)
AttributeError: readBlkFile_FromScratch

I tried the other examples in "Extras" and some work some don't. 
sample_armory_code.py works, but when I turn on some features in the code(making them True).  I get same get_attr error.

I will give some of the other branches a try. 

[goatpig]

All of the calls from testswig.py that you've reported failing have been deprecated long ago. If you want up to date Python tests, look at the pytest folder in dev. You can look at the blockutils tests in the C++ unit tests for C++ examples on how to get the BDM started and querying data.

Don't expect testswig.py to get up to date until the new backend is merged in dev. CircusPeanut and Doug are away until some time after September 3rd. They've been maintaining the Python unit tests so you'll have to wait until they're back to ask them questions about those or report snafus. I've been spending 95% of my time on the new backend for the last couple months, so you can ask me about that instead.

[tpofo]

I was getting nowhere quick using python.  I decided to just use the C++ directly to access blockchain.  I got it working with a little playing around.
There is no in depth explanations to the API, but I kind of modeled my code after the cppblockutils tests.  I got it to compile and I am doing some wallet functions and blockchain searching which is pretty cool.

I am using ARMORY_DB_BARE  mode.  The SUPER one seems to crash in dev branch.  What is the mode that Armory's current version uses?
What do the different modes mean?

Thanks for the help so far.  I enjoy using the C++ backend. 

Do you know why the developer decided to interface python to a C++ backend?  Don't get me wrong, python is great, but why not just keep the app pure C++.  The Qt makes it cross platform GUI-wise anyway.  There is a big jumble of code conversion going on with python to C++. 
Again, I am not knocking the Armory development decision.  It is the best wallet out there.  I've been using it over a year and will not switch.

[goatpig]

The only DB mode available in current Armory releases is DB_BARE. For supernode, try it out in the charles_refactor_blockchain. It may not be stable just yet. I have to finish paging UTXOs and I'll give supernode its finishing touch.

Etotheipi started with Python for the following reasons:

1) He loves Python
2) Cheaper to develop the frontend with Python than with C++
3) SWIG is really easy to use
4) Can leverage a lot of existing Python libraries for alternate stuff that don't need to be in the backend (networking, system calls)
5) Ask him directly =P

[etotheipi]

Etotheipi started with Python for the following reasons:

1) He loves Python
2) Cheaper to develop the frontend with Python than with C++
3) SWIG is really easy to use
4) Can leverage a lot of existing Python libraries for alternate stuff that don't need to be in the backend (networking, system calls)
5) Ask him directly =P

I used python because of how extraordinarily flexible and easy it is to develop functionality, handle errors and corner cases, create flexible interfaces, testing, GUI development, and of course the cross-platformness of it (minus Qt4).  If I want to scan the blockchain for certain patterns, map difficulties, calculate balances, find special scripts, etc, it can be only a few lines of python in an isolated script (once everything is setup and you know how to use it).  

However, python is too slow for computational tasks, but SWIG makes it easy to do computation-heavy stuff (blockchain scanning) in C++ and use it as if it is native python code after running it through SWIG.   Being able to code stuff in either python (slow and flexible) and C++ (fast, optimizable and rigid) yet access all of it in python has been one of the features to which I attribute Armory's success.  In a way, python and C++ are opposites of one another, which means the combination of the two of them covers a lot of functionality space and is quite powerful.  My only complaint so far has been that I should've started with python3 and Qt5, both of which would've improved cross-compatibility and made internationalization easier (which is currently non-existent in Armory).

As mentioned by goatpig:  a lot of the scripts in the extras directory are out of date, and will be even further out of date once we merge in the Charles branch.  However, we plan to update those once the new wallets and supernode stuff is implemented, as the interfaces to wallets and blockchain data should become fairly static and stable after that.

[tpofo]

Hi Etotheipi,

I do commend you on the great product.  Thanks for taking the time to answer some questions.  I appreciate it. 
I totally see your point on choosing python/C++ to develop now. 

I was wondering if the Charles branch's scanning will be as fast as say the way they do it at blockchain.info?  It baffles me how fast a search for some statistic or info is on that engine.  Addresses come up instantaneously, etc... Will Armory have this quick blockchain searching?
Do you know possibly what DB technique they are using and how can this compare to what Armory might have in the near future?

[etotheipi]

Hi Etotheipi,

I do commend you on the great product.  Thanks for taking the time to answer some questions.  I appreciate it. 
I totally see your point on choosing python/C++ to develop now. 

I was wondering if the Charles branch's scanning will be as fast as say the way they do it at blockchain.info?  It baffles me how fast a search for some statistic or info is on that engine.  Addresses come up instantaneously, etc... Will Armory have this quick blockchain searching?
Do you know possibly what DB technique they are using and how can this compare to what Armory might have in the near future?

Their database has already collected all data for all addresses, and it simply fetched it for you. Armory's database only tracks the addresses in your wallets, so you can look those up instantly, but no others.  To look up others it had to rescan the entire blockchain history.

The Charles branch includes a "supernode" mode that tracks all addresses all the time, like blockchain.info.  it's not ready yet, but the goal is to create a tool that services can run locally that does the same thing, so they don't have to rely on third party services like blockchain.info.