Merge PR cosmos#98: Fix CI, a bit of cleanup

* Update CoffeeScript syntax
* Update link checks

scripts/check_links.py

@@ -3,6 +3,7 @@
 import re, os, sys
 
 link_regex = re.compile('\[(.*)\]\(../ics([^\)]*)\)')
+title_regex = re.compile('ICS ([0-9]+)([ .:])')
 
 specs = [f.path for f in os.scandir('./spec') if f.is_dir()]
 files = [f.path for spec in specs for f in os.scandir(spec) if f.is_file() and f.path[-3:] == '.md']
@@ -18,3 +19,9 @@
         if not found:
             print('Link to {} not found!'.format(link))
             sys.exit(1)
+    titles = [int(x[0]) for x in title_regex.findall(data)]
+    for num in titles:
+        matched = [f for f in files if f[7:7+4+len(str(num))+1] == 'ics-' + str(num) + '-']
+        if len(matched) > 0:
+            print('Expected "ICS {}" to link to {} but not found!'.format(num, matched[0]))
+            sys.exit(1)

spec/ics-1-ics-standard/README.md

@@ -161,8 +161,8 @@ This specification was significantly inspired by and derived from Ethereum's [EI
 was in turn derived from Bitcoin's BIP process and Python's PEP process. Antecedent authors are not responsible for any shortcomings of this ICS spec or
 the ICS process. Please direct all comments to the ICS repository maintainers.
 
-March 4th, 2019: Initial ICS 1 draft finished and submitted as a PR
-March 7th, 2019: ICS 1 draft merged
+March 4th, 2019: Initial draft finished and submitted as a PR
+March 7th, 2019: Draft merged
 April 11th, 2019: Updates to pseudocode formatting, add definitions subsection
 
 ## Copyright

spec/ics-18-relayer-algorithms/README.md

@@ -40,12 +40,16 @@ The relayer algorithm is defined over a set `C` of chains implementing the IBC p
 `submitDatagram` is a procedure defined per-chain (submitting a transaction of some sort).
 
 ```coffeescript
-function relay(C)
+relay = (C) ->
   for chain in C
-    for counterparty in C if counterparty != chain
-      datagrams = pendingDatagrams(chain, counterparty)
-      for datagram in datagrams
-        submitDatagram(counterparty, datagram)
+    do (chain) ->
+      for counterparty in C
+        do (counterparty) ->
+          if counterparty != chain
+            datagrams = pendingDatagrams(chain, counterparty)
+            for datagram in datagrams
+              do (datagram) ->
+                submitDatagram(counterparty, datagram)
 ```
 
 ### Incentivization

spec/ics-23-vector-commitments/README.md

@@ -45,7 +45,7 @@ An commitment construction MUST specify the following datatypes, which are other
 An `CommitmentState` is the full state of the commitment, which will be stored by the manager.
 
 ```golang
-type CommitmentState struct
+type CommitmentState struct {}
 ```
 
 #### Root
@@ -55,15 +55,15 @@ An `CommitmentRoot` commits to a particular commitment state and should be succi
 In certain commitment constructions with succinct states, `CommitmentState` and `CommitmentRoot` may be the same type.
 
 ```golang
-type CommitmentRoot struct
+type CommitmentRoot struct {}
 ```
 
 #### Proof
 
 An `CommitmentProof` demonstrates membership or non-membership for an element or set of elements, verifiable in conjunction with a known commitment root. Proofs should be succinct.
 
 ```golang
-type CommitmentProof struct
+type CommitmentProof struct {}
 ```
 
 ### Required functions

spec/ics-24-host-requirements/README.md

@@ -19,7 +19,7 @@ IBC is designed to be a common standard which will be hosted by a variety of blo
 
 ### Definitions
 
-`ConsensusState` is as defined in [ICS 2](../ics-2-consensus-requirements).
+`ConsensusState` is as defined in ICS 2.
 
 ### Desired Properties
 

spec/ics-3-connection-semantics/README.md

@@ -15,13 +15,13 @@ This standards document describes the abstraction of an IBC *connection*: two st
 
 ### Motivation
 
-The core IBC protocol provides *authorization* and *ordering* semantics for packets: guarantees, respectively, that packets have been committed on the sending blockchain (and according state transitions executed, such as escrowing tokens), and that they have been committed exactly once in a particular order and can be delivered exactly once in that same order. The *connection* abstraction specified in this standard, in conjunction with the *client* abstraction specified in [ICS 2](../spec/ics-2-consensus-verification), defines the *authorization* semantics of IBC. Ordering semantics are described in [ICS 4](../spec/ics-4-channel-packet-semantics)).
+The core IBC protocol provides *authorization* and *ordering* semantics for packets: guarantees, respectively, that packets have been committed on the sending blockchain (and according state transitions executed, such as escrowing tokens), and that they have been committed exactly once in a particular order and can be delivered exactly once in that same order. The *connection* abstraction specified in this standard, in conjunction with the *client* abstraction specified in ICS 2, defines the *authorization* semantics of IBC. Ordering semantics are described in [ICS 4](../spec/ics-4-channel-packet-semantics)).
 
 ### Definitions
 
-`ConsensusState`, `Header`, and `updateConsensusState` are as defined in [ICS 2: Consensus Verification](../spec/ics-2-consensus-verification).
+`ConsensusState`, `Header`, and `updateConsensusState` are as defined in ICS 2.
 
-`CommitmentProof`, `verifyMembership`, and `verifyNonMembership` are as defined in [ICS 23: Vector Commitments](../spec/ics-23-vector-commitments).
+`CommitmentProof`, `verifyMembership`, and `verifyNonMembership` are as defined in [ICS 23](../spec/ics-23-vector-commitments).
 
 `Identifier` and other host state machine requirements are as defined in [ICS 24](../spec/ics-24-host-requirements). The identifier is not necessarily intended to be a human-readable name (and likely should not be, to discourage squatting or racing for identifiers).
 
@@ -87,7 +87,7 @@ type Connection struct {
 
 ### Subprotocols
 
-This ICS defines two subprotocols: opening handshake and closing handshake. Header tracking and closing-by-equivocation are defined in ICS 2. Datagrams defined herein are handled as external messages by the IBC relayer module defined in [ICS 26](../spec/ics-26-relayer-module).
+This ICS defines two subprotocols: opening handshake and closing handshake. Header tracking and closing-by-equivocation are defined in ICS 2. Datagrams defined herein are handled as external messages by the IBC relayer module defined in ICS 26.
 
 ![State Machine Diagram](state.png)
 
@@ -250,7 +250,7 @@ function connOpenTimeout(identifier, proofTimeout, timeoutHeight)
 
 #### Header Tracking
 
-Headers are tracked at the client level. See [ICS 2](../ics-2-consensus-requirements).
+Headers are tracked at the client level. See ICS 2.
 
 #### Closing Handshake
 
@@ -368,15 +368,15 @@ function connOpenTimeout(identifier, proofTimeout, timeoutHeight)
 
 The equivocation detection subprotocol is defined in ICS 2. If a client is frozen by equivocation, all associated connections are immediately frozen as well.
 
-Implementing chains may want to allow applications to register handlers to take action upon discovery of an equivocation. Further discussion is deferred to [ICS 12: Byzantine Recovery Strategies](../ics-12-byzantine-recovery-strategies).
+Implementing chains may want to allow applications to register handlers to take action upon discovery of an equivocation. Further discussion is deferred to ICS 12.
 
 ## Backwards Compatibility
 
 Not applicable.
 
 ## Forwards Compatibility
 
-A future version of this ICS will include version negotiation in the opening handshake. Once a connection has been established and a version negotiated, future version updates can be negotiated per [ICS 6](../spec/ics-6-connection-channel-versioning).
+A future version of this ICS will include version negotiation in the opening handshake. Once a connection has been established and a version negotiated, future version updates can be negotiated per ICS 6.
 
 The consensus state can only be updated as allowed by the `updateConsensusState` function defined by the consensus protocol chosen when the connection is established.