diff --git a/docs/.gitignore b/docs/.gitignore index aa1eab1d8a315422b42682d26710a6a729ee0341..76dcd20616a3552c1e2b3513dbbdf90983201875 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -18,3 +18,5 @@ tezos-client.html /user/node-config.json /CHANGES-dev.rst /developer/metrics.csv + +/linkcheck diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 81ca3a22f2a7406e54174f50a5ab69ee2a1029bd..76c0e565f5c8db9f2956d8d272a3d9fe06982c35 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -124,6 +124,8 @@ Client cast invalid ballots (unexpected voting period, missing voting rights, ...) +.. _changes_13_0_rc1_baker: + Baker ----- diff --git a/docs/Makefile b/docs/Makefile index 9bf4677f1900a263367bcf4d87c0ebaca2fc3ed7..93cc799e650c950c3feba5a7a6fb525afa9f944d 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -83,8 +83,11 @@ odoc-lite: main docexes @mkdir -p _build/api @cp -r $(TMPDOCDIR)/_build/default/_doc _build/api/odoc +.PHONY: linkcheck linkcheck: html - @$(SPHINXBUILD) -b linkcheck "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) + @echo "Running linkcheck, outputs messages to $(BUILDDIR)/output.txt" + @$(SPHINXBUILD) -b linkcheck "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) >$@;\ + RESULT=$$?; cat $(BUILDDIR)/output.txt; exit $$RESULT .PHONY: redirectcheck redirectcheck: html @@ -192,6 +195,6 @@ pycodestyle: lint: pylint pycodestyle lint_black clean: - @-rm -Rf "$(BUILDDIR)" + @-rm -Rf "$(BUILDDIR)" linkcheck @-rm -Rf api/errors.rst developer/metrics.csv user/node-config.json active/rpc.rst ithaca/rpc.rst jakarta/rpc.rst alpha/rpc.rst shell/rpc.rst shell/p2p_api.rst user/default-acl.json CHANGES-dev.rst @-rm -Rf api/tezos-*.html api/tezos-*.txt active/tezos-*.html ithaca/tezos-*.html jakarta/tezos-*.html alpha/tezos-*.html diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 2c93683262d8d3b6f8d9c57dc970b674938d266b..b21248fce8651b0302a8bb331fe0a8bcb7866565 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -10,7 +10,7 @@ History Before Tenderbake, there was `Emmy* `_, a Nakamoto-style consensus consisting of a series of improvements of the one in -the `Tezos whitepaper `_. +the `Tezos whitepaper `_. Emmy*, like any Nakamoto-style consensus algorithm (such as `Bitcoin `_ or `Ouroboros diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index 3ccddf8a820c58165f2213e1e610b425c3b3e63e..a1fdef70dc020ca3b2d8f8eea252d547a091a01e 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -175,7 +175,7 @@ Further External Resources The original design of the proof-of-stake mechanism in Tezos can be found in the `whitepaper -`_. +`_. Another presentation of the Tezos' proof-of-stake mechanism can be found in the `Tezos agora wiki entry diff --git a/docs/alpha/randomness_generation.rst b/docs/alpha/randomness_generation.rst index 190a284258fc6a3561947d392cb13a31eb5b76d4..374cdcb71285ec1122acdacd13a0b259bb62dd2c 100644 --- a/docs/alpha/randomness_generation.rst +++ b/docs/alpha/randomness_generation.rst @@ -39,7 +39,7 @@ commitment publication. In the case of a rolling RANDAO, the previous seed may be used to initilialise the hash. We make the assumption that at least one participant is honest, that is, it -has indeed chosen a random value and this values was revealed. This is a +has indeed chosen a random value and this value was revealed. This is a necessary condition for the seed to be random. The randomness could however be biased as this protocol suffers from the following low-impact weakness: if a malicious participant can make sure she is the last revealer, then she diff --git a/docs/alpha/timelock.rst b/docs/alpha/timelock.rst index f756fe77047c671ded851054b17bc710702ab5e1..9fc225ee4c5d0e1f4439dcb1416621cae5817fa9 100644 --- a/docs/alpha/timelock.rst +++ b/docs/alpha/timelock.rst @@ -134,5 +134,5 @@ allows a user to create chests and chest keys to interact with a smart contract. Example ------- -The Raffle contract on Open Tezos (look for "raffle contract" using the search engine on ``https://opentezos.com/``) +The raffle contract on Open Tezos `here `__ gives a concrete example of using time-lock. diff --git a/docs/conf.py b/docs/conf.py index 162c187f15c44484670d2bde4a6b42874b193e74..eb38e090414fdbbaec471973754811595581bce6 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -211,7 +211,31 @@ linkcheck_ignore = [ # local files, e.g. ../api/api-inline.html#*', \.\./CHANGES.html#version-* # (interpreted by linkcheck as external links, generating false positives) r'^\.\./', + # flaky servers, to remove one day if they got more predictable + r'^https://opentezos\.com/', ] +linkcheck_allowed_redirects = dict( + [ + # 1. inocuous redirections (redirected with See Other / Found) + ( + r'https://www\.sphinx-doc\.org/.*', + r'https://www\.sphinx-doc\.org/en/master/.*', + ), + (r'https://docs\.pytest\.org/', r'https://docs\.pytest\.org/en/.*'), + ( + r'https://tools\.ietf\.org/html/.*', + r'https://datatracker\.ietf\.org/doc/.*', + ), + (r'https://ocaml\.org/.*', r'https://v2\.ocaml\.org/.*'), + ( + r'https://github\.com/serokell/tezos-packaging/releases/latest', + r'https://github\.com/serokell/tezos-packaging/releases/tag/.*', + ), + # 2. permanent redidections, maybe fix one day + (r'https://bitheap\.org/cram/', r'https://github\.com/aiiie/cram'), + ] +) + # Python module index generation is broken, deactivate it. html_domain_indices = False diff --git a/docs/developer/ppx_expect.rst b/docs/developer/ppx_expect.rst index cb8001a08ded2704d9b99ab6cda17b95e0d04208..726e51cb545dd0514f86440765c575924ceb5cfd 100644 --- a/docs/developer/ppx_expect.rst +++ b/docs/developer/ppx_expect.rst @@ -1,7 +1,7 @@ Ppx_expect ========== -`Ppx_expect :ref:` is a framework for writing tests for OCaml +:ref:`Ppx_expect` is a framework for writing tests for OCaml code printing textual output. There is pretty comprehensive documentation about ``Inline expectation tests`` and the ``ppx_expect`` tool for writing them: @@ -13,12 +13,12 @@ Here, we will just cover enough to get started using them inside the Tezos codeb How to run tests ---------------- -If you want to run tests and see whether they succeed, build the standard runtest alias :: +If you want to run tests and see whether they succeed, build the standard ``runtest`` alias:: dune runtest src/lib_stdlib # or dune build @@src/lib_stdlib/runtest -The result would look like this :: +The result would look like this:: File "src/lib_stdlib/bloomer.ml", line 97, characters 0-817: random_read_writes (0.006 sec) File "src/lib_stdlib/bloomer.ml", line 123, characters 0-1339: peek and poke work with bits = [1 .. Sys.int_size - 7] (0.012 sec) @@ -29,7 +29,7 @@ The result would look like this :: File "src/lib_stdlib/bloomer.ml", line 456, characters 4-137 (11.966 sec) File "src/lib_stdlib/bloomer.ml", line 461, characters 4-1695: <> (0.000 sec) -A test can fail because it generates an output different from what is expeceted or because it raises an exception. +A test can fail because it generates an output different from what is expected or because it raises an exception. Failures are reported as a diff in both cases. Different output:: @@ -120,7 +120,7 @@ In the manifest, just add the following argument to the library containing expec ~inline_tests:ppx_expect -Adding new tests is then just a matter of adding ``let%expect_test`` at toplevel:: +Adding new tests is then just a matter of adding ``let%expect_test`` at top level:: let%expect_test "optional name" = print_endline "hello world"; @@ -141,9 +141,9 @@ Where to put the tests ---------------------- Expect tests can live next to the implementation or in a different library dedicated to tests -(e.g. if you don't want to polute your source/binary or if your want to only test the exposed api). +(e.g. if you don't want to polute your source/binary or if your want to only test the exposed API). -Intergration with Lwt +Integration with Lwt --------------------- Ppx_expect can be used in combination with Lwt, see the diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index d847a8ec71ddf77d81d66d247543613ac73bfc28..1c6d152bf8b69ce05f0e2ed55060b91add0d3be0 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -127,7 +127,7 @@ References: - `Alcotest README `_. .. _ppx_expect_section: - + Ppx_expect ~~~~~~~~~~ @@ -136,8 +136,8 @@ framework for writing tests for OCaml code generating textual output, similar to `Cram `_ which is used for testing command line applications. Typical use cases: - - Unit test, integration test leveraging existing printers instead of checking properties. - - Test that change on purpose over time. One can easily make tests + - Unit tests and integration tests leveraging existing printers instead of checking properties. + - Tests that change on purpose over time. One can easily make tests pass again with a single dune invocation ``dune runtest --auto-promote`` Example tests: @@ -151,7 +151,7 @@ References: - `Ppx_expect README `_. - `Dune documentation about inline expectation tests `_. - `Ppx_inline_test README `_. - + .. _property_based_test: QCheck diff --git a/docs/index.rst b/docs/index.rst index f87b54692787bec345ea84190bae58d4e81973a7..4949261f61545843f89ec2f3131869faf0f1a043 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -50,7 +50,6 @@ The Community - https://tzstats.com - https://tezblock.io - - https://teztracker.com/ - https://tzkt.io (Baking focused explorer) - https://arronax.io (Analytics-oriented explorer) - https://mininax.io diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 709f2d2f28375e3e6e42b7eee562a56acccca62b..a1299cf91ef16a7041d25c35bdd216216e7888c1 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -178,6 +178,7 @@ baking for user *bob*:: Note that the baker needs direct access to the node data directory for performance reasons (to reduce the number of RPC calls to the node). +Note also that since version 13.0, option ``--liquidity-baking-toggle-vote`` is mandatory, see :ref:`the changelog `. .. warning:: @@ -203,7 +204,7 @@ chains and looks for: Upon finding such irregularity, it will emit respectively a double-baking, double-pre-endorsing, or double-endorsing denunciation operation, which will -cause the offender to be :ref:`slashed`, that is, to lose part of its security deposit. +cause the offender to be :ref:`slashed`, that is, to lose part of its security deposit. :: diff --git a/docs/ithaca/consensus.rst b/docs/ithaca/consensus.rst index a13883ed9901f332b5d145ab5227a9baa23d5d76..695c48f461c25430462999db42c3dbb68652f0dc 100644 --- a/docs/ithaca/consensus.rst +++ b/docs/ithaca/consensus.rst @@ -10,7 +10,7 @@ History Before Tenderbake, there was `Emmy* `_, a Nakamoto-style consensus consisting of a series of improvements of the one in -the `Tezos whitepaper `_. +the `Tezos whitepaper `_. Emmy*, like any Nakamoto-style consensus algorithm (such as `Bitcoin `_ or `Ouroboros diff --git a/docs/ithaca/proof_of_stake.rst b/docs/ithaca/proof_of_stake.rst index f25e2dfe738209ed44d6bb7fe2f4d5b7f2d9a5cc..2d7a7820070435f8611ac873e1320d66067322ff 100644 --- a/docs/ithaca/proof_of_stake.rst +++ b/docs/ithaca/proof_of_stake.rst @@ -95,7 +95,7 @@ previous cycle, they first commit to nonces and they only reveal their committed nonces later, in the current cycle. We make the assumption that at least one participant is honest, that -is, it has indeed chosen a random value and this values was revealed. This is a necessary +is, it has indeed chosen a random value and this value was revealed. This is a necessary condition for the seed to be random. The randomness could however be biased as this protocol suffers from the following low-impact weakness: if a malicious participant can make sure she is the last revealer, @@ -230,7 +230,7 @@ Further External Resources The original design of the proof-of-stake mechanism in Tezos can be found in the `whitepaper -`_. +`_. Another presentation of the Tezos' proof-of-stake mechanism can be found in the `Tezos agora wiki entry diff --git a/docs/ithaca/timelock.rst b/docs/ithaca/timelock.rst index f756fe77047c671ded851054b17bc710702ab5e1..9fc225ee4c5d0e1f4439dcb1416621cae5817fa9 100644 --- a/docs/ithaca/timelock.rst +++ b/docs/ithaca/timelock.rst @@ -134,5 +134,5 @@ allows a user to create chests and chest keys to interact with a smart contract. Example ------- -The Raffle contract on Open Tezos (look for "raffle contract" using the search engine on ``https://opentezos.com/``) +The raffle contract on Open Tezos `here `__ gives a concrete example of using time-lock. diff --git a/docs/jakarta/consensus.rst b/docs/jakarta/consensus.rst index 72358a9366c564cb86539bcbf19c6b0c3670873f..972d65a4169dd598a07efa37cf73292c8d5ed25c 100644 --- a/docs/jakarta/consensus.rst +++ b/docs/jakarta/consensus.rst @@ -10,7 +10,7 @@ History Before Tenderbake, there was `Emmy* `_, a Nakamoto-style consensus consisting of a series of improvements of the one in -the `Tezos whitepaper `_. +the `Tezos whitepaper `_. Emmy*, like any Nakamoto-style consensus algorithm (such as `Bitcoin `_ or `Ouroboros diff --git a/docs/jakarta/liquidity_baking.rst b/docs/jakarta/liquidity_baking.rst index e7ee01a29293cada93feeb7b565a42478d0df1f8..dfbff4d5f9c254774fce411a94d8d692b31b4d25 100644 --- a/docs/jakarta/liquidity_baking.rst +++ b/docs/jakarta/liquidity_baking.rst @@ -44,13 +44,13 @@ mechanism called the Liquidity Baking Toggle Vote. At every block, the baker producing the block includes a flag that requests ending the subsidy or on the contrary continuing or restarting it. The context maintains an exponential moving average of that flag. The baker has -three options for this flag: ``Off`` to request ending the subsidy, -``On`` to request continuing or restarting the subsidy, and ``Pass`` +three options for this flag: ``off`` to request ending the subsidy, +``on`` to request continuing or restarting the subsidy, and ``pass`` to abstain. -``e[n+1] = e[n]`` if the flag is set to ``Pass``. -``e[n+1] = (1999 * e[n] // 2000) + 1_000_000`` if the flag is set to ``Off``. -``e[n+1] = (1999 * e[n] // 2000)`` if the flag is set to ``On``. +``e[n+1] = e[n]`` if the flag is set to ``pass``. +``e[n+1] = (1999 * e[n] // 2000) + 1_000_000`` if the flag is set to ``off``. +``e[n+1] = (1999 * e[n] // 2000)`` if the flag is set to ``on``. When computing ``e[n+1]``, the division is rounded toward ``1_000_000_000```. If at any block ``e[n] >= 1_000_000_000`` then it means that an diff --git a/docs/jakarta/proof_of_stake.rst b/docs/jakarta/proof_of_stake.rst index 3825f09d8530ca6bca6d3894f56fdc9982d07a82..01706c881b0ed2bd11a83dceda1bad4f9eacdbe6 100644 --- a/docs/jakarta/proof_of_stake.rst +++ b/docs/jakarta/proof_of_stake.rst @@ -93,7 +93,7 @@ previous cycle, they first commit to nonces and they only reveal their committed nonces later, in the current cycle. We make the assumption that at least one participant is honest, that -is, it has indeed chosen a random value and this values was revealed. This is a necessary +is, it has indeed chosen a random value and this value was revealed. This is a necessary condition for the seed to be random. The randomness could however be biased as this protocol suffers from the following low-impact weakness: if a malicious participant can make sure she is the last revealer, @@ -225,7 +225,7 @@ Further External Resources The original design of the proof-of-stake mechanism in Tezos can be found in the `whitepaper -`_. +`_. Another presentation of the Tezos' proof-of-stake mechanism can be found in the `Tezos agora wiki entry diff --git a/docs/jakarta/timelock.rst b/docs/jakarta/timelock.rst index f756fe77047c671ded851054b17bc710702ab5e1..9fc225ee4c5d0e1f4439dcb1416621cae5817fa9 100644 --- a/docs/jakarta/timelock.rst +++ b/docs/jakarta/timelock.rst @@ -134,5 +134,5 @@ allows a user to create chests and chest keys to interact with a smart contract. Example ------- -The Raffle contract on Open Tezos (look for "raffle contract" using the search engine on ``https://opentezos.com/``) +The raffle contract on Open Tezos `here `__ gives a concrete example of using time-lock. diff --git a/docs/user/fa12.rst b/docs/user/fa12.rst index a1f8c8beb878561fdda4ed7267b310a9a5736b0f..263494824864dc36bf02c15f40aa9fd22ba382ed 100644 --- a/docs/user/fa12.rst +++ b/docs/user/fa12.rst @@ -25,7 +25,7 @@ supply. The Michelson interface is then described by the following entrypoints: Multiple implementations of such a standard exist within the ecosystem. For example, one is provided with the `TZIP-007 specification `_. -`Edukera `_ and +`Edukera `_ and `camlCase `_ both provide a contract that implements the standard, and both have been verified using the `Mi-Cho-Coq `_ framework (see related :gl:`merge diff --git a/scripts/snapshot_alpha.sh b/scripts/snapshot_alpha.sh index ade43a8af9db042c0918eed62d3fb055a33acf32..af02a6a854d7f164669aba89ad4c708acd2bca50 100755 --- a/scripts/snapshot_alpha.sh +++ b/scripts/snapshot_alpha.sh @@ -150,7 +150,7 @@ sed -i.old -e "s,tezos\.gitlab\.io/alpha/,tezos.gitlab.io/${version}_${label}/,g -e "s/_alpha\b/_${version}/g" \ -e "s/\balpha\b/${version}/g" \ $(find . -name \*.py) -echo "Fixing python regtests ouputs" +echo "Fixing python regtests outputs" cd _regtest_outputs sed -i.old -e "s/_alpha\b/_${version}/g" *.out cd ../.. diff --git a/src/proto_alpha/lib_client_commands/client_proto_context_commands.ml b/src/proto_alpha/lib_client_commands/client_proto_context_commands.ml index da6a9c4f9680f9ac01824144ed3cf81c63f96c11..06cf66a0930ca1dd2138fa3a6975b9dd2fd359a1 100644 --- a/src/proto_alpha/lib_client_commands/client_proto_context_commands.ml +++ b/src/proto_alpha/lib_client_commands/client_proto_context_commands.ml @@ -2042,7 +2042,7 @@ let commands_rw () = >>=? fun _res -> return_unit); command ~group - ~desc:"Finalize a commitment of an transaction rollup." + ~desc:"Finalize a commitment of a transaction rollup." (args7 fee_arg dry_run_switch @@ -2053,7 +2053,7 @@ let commands_rw () = counter_arg) (prefixes ["finalize"; "commitment"; "of"; "tx"; "rollup"] @@ Tx_rollup.tx_rollup_address_param - ~usage:"Tx rollup that have his commitment finalized." + ~usage:"Tx rollup that have its commitment finalized." @@ prefix "from" @@ ContractAlias.destination_param ~name:"src" @@ -2094,7 +2094,7 @@ let commands_rw () = >>=? fun _res -> return_unit); command ~group - ~desc:"Recover commitment bond from an transaction rollup." + ~desc:"Recover commitment bond from a transaction rollup." (args7 fee_arg dry_run_switch @@ -2145,7 +2145,7 @@ let commands_rw () = >>=? fun _res -> return_unit); command ~group - ~desc:"Remove a commitment from an transaction rollup." + ~desc:"Remove a commitment from a transaction rollup." (args7 fee_arg dry_run_switch @@ -2156,7 +2156,7 @@ let commands_rw () = counter_arg) (prefixes ["remove"; "commitment"; "of"; "tx"; "rollup"] @@ Tx_rollup.tx_rollup_address_param - ~usage:"Tx rollup that have his commitment removed." + ~usage:"Tx rollup that have its commitment removed." @@ prefix "from" @@ ContractAlias.destination_param ~name:"src" @@ -2197,7 +2197,7 @@ let commands_rw () = >>=? fun _res -> return_unit); command ~group - ~desc:"Reject a commitment of an transaction rollup." + ~desc:"Reject a commitment of a transaction rollup." (args7 fee_arg dry_run_switch @@ -2208,7 +2208,7 @@ let commands_rw () = counter_arg) (prefixes ["reject"; "commitment"; "of"; "tx"; "rollup"] @@ Tx_rollup.tx_rollup_address_param - ~usage:"Tx rollup that have one of his commitment rejected." + ~usage:"Tx rollup that have one of its commitment rejected." @@ prefixes ["at"; "level"] @@ Tx_rollup.level_param ~usage:"Level of the commitment disputed." @@ prefixes ["with"; "result"; "hash"]