1. 11 May, 2020 6 commits
    • 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
      'toInt'.
      2afa4bb2
    • 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
      29dd1ed2
    • 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.
      c35e855d
    • 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`
      e34a34e4
    • 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
      6312d72e
    • 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.
      4bc4cea9
  2. 08 May, 2020 4 commits
  3. 07 May, 2020 9 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
      918854a9
    • Anton Myasnikov's avatar
      [#54] Add morley-client bindings to morley-nettest · a1dcdf9c
      Anton Myasnikov authored
      Problem:
      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`
      
      Solution:
        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
      balance.
      a1dcdf9c
    • 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.
      
      Solution:
        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
      `Morley.Client.Types`
        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.
      ccb88bc5
    • 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`.
      b99171b3
    • 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
      module.
      9e3442b6
    • Anton Myasnikov's avatar
      [#52] Make arStorageSize in AppliedResult optional · fba05982
      Anton Myasnikov authored
      Problem: Babylonnet sends different data on transaction response if
      such happened between two implicit addresses or contract and address.
      More specifically it sends an additional 'storage_size' field when
      transaction happened with contract address involved which does not
      for implicit account implying that they do not have storage at all.
      
      Solution: Make arStorageSize in AppliedResult optional and tweak
      all of its appearances.
      fba05982
    • Anton Myasnikov's avatar
      [#52] Move AddrOrAlias to morley-client · cbf1adda
      Anton Myasnikov authored
      Problem: We'll need AddrOrAlias capability in morley-client to
      resolve addresses that we are planning to use later in morley-nettest.
      
      Solution: Move AddrOrAlias and rename it to AddressOrAlias as well as
      its constructors.
      cbf1adda
    • Zhenya Vinogradov's avatar
      Merge branch 'zhenya/hackage-pin' into 'master' · a25f52cf
      Zhenya Vinogradov authored
      CI: pin hackage and stackage indexes independently of haskell.nix
      
      See merge request !388
      a25f52cf
    • Zhenya Vinogradov's avatar
      CI: pin hackage and stackage indexes independently of haskell.nix · d8feb88d
      Zhenya Vinogradov authored
      Problem: we use default hackage and stackage pins provided by
      haskell.nix. It means that when a developer wants to add a new
      dependency, they have to bump haskell.nix, which means that CI might
      need to rebuild GHC and all haskell dependencies, which takes a long
      time
      
      Solution: use separate pins for hackage and stackage indexes, so that
      they can be updated independently
      d8feb88d
  4. 05 May, 2020 7 commits
  5. 04 May, 2020 5 commits
  6. 01 May, 2020 9 commits