* build complex and indirected types into AACI
* break up coerce and coerce_step
coerce_step handles the looping and accumulation logic, whereas coerce
just handles one term, and returns {ok, _} or {error, _}. This way
coerce can become recursive, and even without recursion becomes easier
to read, due to fewer nested tuples.
Pretty insignificant change, but it'll be nice to have something to diff
off of more cleanly.
* coerce some more types
Still haven't covered lists or tuples, but these were enough to cover a
real contract that I want to test properly, once I have a node to test
on.
* process types from all contracts in ACI
This includes the contract itself, which is added as an alias for
`contract`. This way the ACI can describe and use contract interfaces,
and `ct_*` contracts can be passed into vanillae.
* coerce lists and tuples
* Fix handle_down error message
It was printing a tuple with `~s`, and also tried to pretty print a fat
call stack more than a hundred columns into the first line, which put
together made for some confusing exception-during-error-handling
messages in the erlang console.
* Switch to unicode formatting in handle_down
Methodology:
- in Erlang, generate random DecodeData that are decentish (hard to generate
because of arbitrary depth recursive nature)
- in Erlang, check that DecodeData->rlp:encode->rlp:decode is an identity (it
is!)
- generate tons of encode/decode pairs for Python, make sure they all work
(they do!)
my current methodology for doing X
- find library that does X in Python with lots of stars on GitHub
- autogenerate test cases against Python library
- do X in Erlang to work out logic in easier setting
- make sure Erlang implementation works
- do X in TypeScript
- make sure TypeScript implementation works
It compiles but there's some NYI functions
This is going to have all the common functions that we need all over the place
- base64 encode/decode
- base58 encode/decode
- rlp encode/decode
- transaction types
- transaction formation
- reading stuff from the transaction
- safe type
- (maybe) AWCP
This commit contains a refactored version of my prior base64 implementation,
which is more imperativey and less "trying to fit Erlang into TS".
pharpend
Craig Everett