checksubmit controls if a submitted order can be accepted by the broker by simulating execution and with it checking if the current cash reserves are enough. It actually pseudo-executes all pending orders, because an order could actually be 1st opening a short and increasing the pseudo-cash reserves.
But this is only pseudo-execution. When the actual execution takes place, the actual cash level is checked again and execution will be rejected if not possible.
@backtrader if you don't mind I would correct your summary slightly:
@ab_trader is looking to use the signals and position sizes provided by bt, and mirror them to broker account by hands. bt will keep position sizes, cash, value and commissions.
In that scenario there is no need to load the positions, cause they are mirrored by trader and are the same in bt and at broker account. In case of the discrepancies bt strategy can be easily adjusted.
The broker is being used for signal and position sizes providing as well as for tracking of the cash and value (no need to support the real broker).
I believe this summary reflects my proposals better. :)
A full exception trace would be a lot more useful than the selected final line, which only says that something hasn't got a length.
The full trace will give hints as to where the error was triggered and not where the error finally happened.
Choosing GPLv3 is a fully conscious decision. What other libraries may or may not do is not of much interest. Each author or organization willing to release open source code weights the pros and cons of different approaches and in this case the GPLv3 was chosen.
Having a license doesn't preclude being able to have a 2nd license for the platform. In most cases this pattern is filled with a direct negotiation between the parties (one interested in an acquisition with a different license, the other willing to re-license) Whether such a pattern fits your case is something which cannot be simply assumed.
There isn't enough information to even attempt anything. For example: the only provided output is from the modified source, without having the actual command line execution
As such one can only try to point the low hanging fruits. One would be:
Are you pointing to the right port? (usually 7496 for production and 7497 for paper trading)
The default port used by the sample and the IB ecosystem is 7496.
You quote above the following command:
./ibtest.py --data0 EUR.USD-CASH-IDEALPRO --resample --timeframe Minutes --compression 1
and this is theoretically working with the demo. But the demo also runs (default, can be of course be changed) on port 7497.
Cash Products like EUR.USD-CASH-IDEALPRO are allowed (afaik) to all IB customers (as long as your account is funded I think). Whether demo, paper trading or real account, that product is available for everyone. And the code (which relies on IBPy for interfacing to TWS) doesn't know what it is connecting to. The account type is controlled by the TWS (or IbGateway) instance you connect to.
The documentation/blog has several examples with multiple instruments, be it with resampling of the same data or with different datas. Some examples:
You simply have to tell the platform form which instrument to buy/sell.