Commit b869c264aa introdude `-v level`, which should be equivalent to
setting `LWT_LOG="* -> level`, but it inadvertently drop the support for
`LWT_LOG`. This commit reintroduces support for ` LWT_LOG` which allows
to setup distinct verbosity levels to distinct part of the node :
LWT_LOG="net -> debug ; rpc -> notice"
* SHA256 produces 256 bits pseudo-randomly uniformly, so you may
compare to a 256 bit target to get a proof of work
* If you pretend that the hash and targets are both integers between 0
and 2^256 - 1, then the target partitions the range into passing and
failing segments.
* In order to match the use of the `get_uint16` function from
`ocplib-endian`, the easiest way to encode `target` is as a `int list`
which works if not ideal
* This seems like the same thing bitcoin does; difficulty there is
actually not a primary notion but is calculated from a 256 bit target,
which is what gets adjusted over time
Tracing interpreter and type checker
Implements:
* a typechecker that optionally dumps the types of each instruction
* an interpreter that drops the stack at each execution step
Incidentally:
* adds some RPCs to pretty print the traces
* drops floats and imperative structures from the language
* fixes the typing of `FAIL`
Implement a minimal "completion" service.
The use of Base48 encoding allows to efficiently implement a "completion" mechanism for blocks, operations, public key and contract identifiers. For instance:
```
> ./tezos-client complete eeHfgnr9QeDN
eeHfgnr9QeDNvcMgSfATNeDeec4KG4CkHHkNNJt5B9xdVmsxhsHNR
```
This command returns all the identifiers matching the given prefix. Adding the option `-unique` let the command fails when there more than one possible completion.
This completion mechanism should probably never be used implicitly, but it might still be useful to display a small completion popup in a GUI, or during manual testing on the CLI.
See merge request !101
