* Adjusting version
* Initiating some edoc stuff
* Doc check
* Fixing docs
* Do a hard type check when entering nodes
* Two fixes:
- Module call change from enacl to ecu_eddsa
- Fix the v3 call endpoint for top block
* Fix top_block typespec and make top_height great again
* Fix typo
* Coerce in both directions
This is what I have been using in the voting app, via decode_bytearray.
Some smaller fixes are included too, such as exposing the `state` type
of a contract, and wrapping/unwrapping the `{tuple, {...}}` wrapper
produced by aeser.
Add Contract.state to the AACI typedefs
dry_run_result and tx_result
Coerce now has the ability to convert BACK from the format aebytecode
understands, which allows dry_run_result and tx_result to decode the
cb_... stuff and turn it into the kinds of erlang object that could be
passed right back into vanillae, for example. More than anything,
though, these functions just give you the data in the form that you want
it for pattern matching and getting actual work done.
expose decode_bytearray instead of tx_result
wrap/unwrap tuple atom correctly
* better coerce error accumulation
Now coerce errors all have the same format: [{error(), [path_steps()]}]
* 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".
Craig Everett
pharpend