1. 15 May, 2020 13 commits
  2. 14 May, 2020 3 commits
  3. 13 May, 2020 3 commits
    • Moremi Vannak's avatar
      [#178] Add a `makeVoid` expression in Indigo · 49fbec10
      Moremi Vannak authored
      Problem: Indigo has `makeView` expression to create `View` but none to
      create `Void_`
      Solution: Add `makeVoid` expression to create `Void_`
    • Moremi Vannak's avatar
      Merge branch 'rinn7e/#154-remove-catch-all-typecheckinstr' into 'master' · 44ea1729
      Moremi Vannak authored
      [#154] Handle all unmatched cases in typeCheckInstr
      Closes #154
      See merge request !377
    • Moremi Vannak's avatar
      [#154]: Handle all unmatched cases in typeCheckInstr · 6d323b26
      Moremi Vannak authored
      Problem: Currently typeCheckInstr in `Michelson.TypeCheck.Instr` contains
      a lot of pattern match clauses that match all valid instructions, and then
      one catch-all case that just reports generic error about failed instructions.
      This should be replaced with pattern match on all possible instructions,
      to give more fine-grained error messages. For example,
      UPDATE should report what type it expects and what were given.
      Solution: Handle all unmatched cases in typeCheckInstr and make it reports
      understandable and specific errors for all syntactically possible, but incorrect instructions.
      [#154] Changes according to review
  4. 12 May, 2020 2 commits
  5. 11 May, 2020 10 commits
    • Maxim Koltsov's avatar
      Merge branch 'maksbotan/tm-366-compileLorentzWithOptions' into 'master' · be72c764
      Maxim Koltsov authored
      [TM-366] Preprocessing in Lorentz compilation
      See merge request !360
    • Maxim Koltsov's avatar
      [TM-366] Use raw Lorentz Contract in Indigo AST · 8c4a83ad
      Maxim Koltsov authored
      Problem: Indigo has `CreateContract` instruction which uses
      `Lorentz.createContract` in its interpretation. Since `createContract`
      now expects full `Contract` rather than just `ContractCode`, Indigo
      needs to be changed to accomodate that.
      Solution: change `CreateContract` AST node to store full
      `Lorentz.Contract` and apply `defaultContract . compileIndigoContract`
      in `createContract` smart constructor to attach default compilation
      options for the Lorentz compiler. Provide `createLorentzContract`
      function for Indigo users to be able to use any `Lorentz` contract with
      custom compilation options.
    • Maxim Koltsov's avatar
      [TM-366] Introduce Lorentz.Contract · 095d1a11
      Maxim Koltsov authored
      Problem: a Lorentz contract is more than just its `ContractCode`.
      Namely, the developer of the contract should be able to attach meta-info
      like compilation options to their contract.
      Solution: introduce `Lorentz.Contract` data type that combines
      `ContractCode` with `CompilationOptions`. Replace all bare usages of
      `ContractCode` with `Contract` and change all our actual contract to be
      in form of `Contract`.
    • Pinto Pasquale's avatar
      Merge branch 'pasqu4le/#135-indigo-fromInteger' into 'master' · fd4bd4f9
      Pinto Pasquale authored
      [#135] add custom Indigo fromInteger
      Closes #135
      See merge request !392
    • Pinto Pasquale's avatar
      [#135] add custom Indigo fromInteger · 2afa4bb2
      Pinto Pasquale authored
      Problem: type signatures or annotations always need to be specified for
      numeric values in Indigo code, because they are otherwise ambiguous.
      However, Indigo uses `RebindableSyntax` that allows to define a
      `fromInteger` function used to resolve numeric literals, and this can
      be used to implement (some) custom resolution logic.
      Solution: implement a `fromInteger` that takes an additional value
      (beside the Integer) that provides disambiguation for the resulting
      value type, with function constructors for this type that match the
      target Michelson type.
      Additionally, because of this, the 'int' expression has been renamed
    • Pinto Pasquale's avatar
      Merge branch 'pasqu4le/#185-update-managedledger' into 'master' · 29dd1ed2
      Pinto Pasquale authored
      [#185] update ManagedLedger implementation
      Closes #185
      See merge request !387
    • Pinto Pasquale's avatar
      [#185] update documentation of ManagedLedger approve entrypoint · c35e855d
      Pinto Pasquale authored
      Problem: the documentation for approve does not properly clarify that
      self-allowance is always ignored nor how to safely use it to avoid
      the corresponding attack vector.
      Solution: update the documentation to fix both problems.
    • Pinto Pasquale's avatar
      [#185] update ManagedLedger implementation · e34a34e4
      Pinto Pasquale authored
      Problem: the current ManagedLedger implementation (both Indigo and
      Lorentz) has 2 things that can be improved:
      1. `transfer` considers the `from == to` case as a no-op. This
         increases the cost on the most common case and probably
         contradicts FA1.2
      2. currently `LedgerValue` can increase arbitrarily in size, because
         it contains a `Map` of approvals. This does not create particular
         problems here (one could only affect its own `LedgerValue`) but it
         can in contract that are based on ManagedLedger. Plus, it is not
         efficient to keep data this way.
      Solution: modify the contract implementation, in particular:
      1. avoid treating `from == to` as a special case in `transfer`
      2. store approvals in a separate big_map from `ledger`
    • Moremi Vannak's avatar
      Merge branch 'rinn7e/tm-267-bad-error-messages' into 'master' · 6312d72e
      Moremi Vannak authored
      [TM-267]: Fix bad error messages in let-block
      See merge request !384
    • Moremi Vannak's avatar
      [TM-267]: Fix bad error messages in let-block · 4bc4cea9
      Moremi Vannak authored
      Problem: Bad error message in let-block
      For example, if we have this in let-block:
      let {
        type Store = (BigMap Address Nat, Nat);
        test :: '[option int] -> '[int]
        = { IF_SOME { nop } { PUSH int 3 }; };
        #             ^^^
        # Adding `nop` here will cause an error
      Expected error message:
      morley: ../../contracts/FA1/custom.mtz:10:16:
      10 |   = { IF_SOME {nop} { PUSH int 3 }; };
         |                ^
      unexpected 'n'
      Actual error message:
      morley: ../../contracts/FA1/custom.mtz:9:3:
      9 |   test :: '[option int] -> '[int]
        |   ^
      unexpected 't'
      expecting '}'
      This is due to backtracing issues.
      Solution: Fixed by narrowing down the `try` backtracing.
  6. 08 May, 2020 4 commits
  7. 07 May, 2020 5 commits
    • Anton Myasnikov's avatar
      Merge branch 'awkure/#52-direct-rpc-and-batching-in-morley-nettest' into 'master' · 918854a9
      Anton Myasnikov authored
      [#52] [#54] Use RPC directly and add batching in morley-nettest
      Closes #54 and #52
      See merge request !287
    • Anton Myasnikov's avatar
      [#54] Add morley-client bindings to morley-nettest · a1dcdf9c
      Anton Myasnikov authored
      There're several problems that are emphasised here
        1. In current morley-nettest implementation we use direct
      bindings to `tezos-client` via `process` and since we have already
      similar implementation in `morley-client` it would be nice to
      make nettest depend on this implementation
        2. When transferring we pass `Word64` values for the amount of
      xtz to transfer which is not safe and would be great to change it
      to `Mutez`
        1. Refactor `Morley.Nettest.Client` to use morley-client diretly
      and remove `Morley.Nettest.CLI` within it
        2. Make `OriginateData` and `TransferData` accept `Mutez` for
    • Anton Myasnikov's avatar
      [#52] Add batching and the ability of read tezos config in morley-client · ccb88bc5
      Anton Myasnikov authored
      Problem: There're several problems that are emphasised in this
      commit, specifically
        1. Our current morley-client implementation posesses an inability
      of reading the configuration file from tezos-client
        2. Within the aforementioned problem with reading external
      configuration file, it would be great rewriting some of the values
      retrieved from it by our command-line interface and vise-versa, so
      that some cli arguments are optional and by default retreived from
      tezos-client configuration such as `node-address` and `node-port`,
      if none provided, use the hadrcoded default values.
        3. We pass secret keys to sign operations explicitly which is not
      supposed to be that way and would be better sign them through
      tezos-client binary
        4. Awaiting for operation inclusion is implemented by reading the
      header block every 10 seconds through RPC interface which is not
      bad, but may be better using tezos-client binary which is also
      debatable of whether one solution has more benefits than the other
      so let's leave both these implementations here
        5. Refactor morley-client so that we use `MorleyClientConfig` as
      an environment of morley-client reader interface and can pass it
      explicitly to all of its methods
        6. Transferring in morley-client currently weren't possible since
      we transfer 0xtz between addresses also add the corresponding
      interfaces for it as well as it's Lorentz variant
        7. It would be great if we make some of the methods (such as
      `transfer`) accept not only contract addresses but also their
      aliases (as handled by `AddrOrAlias` data here) and resolve them
      consequently whenever it's possible.
        8. Some mocking tests are failing and should be updated within
      this commit as well.
        9. Documentation needs to be updated.
        10. Weeder fails for some unused constructors.
        1. Add the corresponding lookup from "TEZOS_CLIENT_PATH"
      environment variable or use "tezos-client" by default.
        2. Rewrite parser to provide the corresponding defaults and
      some other processing helpers of the client configuration in
        3. Add the corresponding `signOperationWithTezosClient` function
      and `defaultSignOperation` helper that chooses the corresonding
      sign method depending on the presence of scret key inside config
      file of morley-client
        4. Add the corresponding `waitForOperationInclusion` function
      that uses tezos-client for such occasion and leave
      `waitForOperationInclusionRpc` for the time being so that it may
      come handy later when we try to make morley-client independent
      from tezos-client binary if we'll someday have a proper interface
      for communication with tezos network
        5. Make current morley-client application depend on
      `MorleyClientConfig` datatype rather than servant's `ClientEnv` as
      of reader environment and rewrite every method accordingly. We can
      still retreive `ClientEnv` by using the corresponding helper
      `getClientEnv` from `Morley.Client.HttpClient`.
        6. Rewrite `runTransactions` so that it accepts a list of pairs
      of entrypoint parameters and amounts of xtz to transfer across the
      network, also add `transfer` and `lTransfer` functions to simplify
      this interface a bit
        7. Add `AddrOrAlias` datatype and refactor all the methods needed
      resolving addresses through tezos-client binary
        8. Update `TestM` instances to satisfy all mocking tests.
        9. Update README.md file.
        10. Add additional weeder rules to ignore these warnings.
    • Ivan Gromakovskii's avatar
      [#54] Do not return block hash from `waitForOperationInclusion` · b99171b3
      Ivan Gromakovskii authored
      Problem: we are going to implement waiting for operation via
      `tezos-client` and parsing block hash from it is inconvenient.
      This information is not useful for us at this point, so it
      seems easier to just drop hash printing.
      Solution: do not return anything from `waitForOperationInclusion`.
    • Anton Myasnikov's avatar
      [#52] Add untyped contract origination to morley-client · 9e3442b6
      Anton Myasnikov authored
      Problem: We want to be able originate michelson contracts for
      instance that are imported from a file.
      Solution: Add originateUntypedContract function to origination