1. 22 May, 2020 3 commits
    • Moremi Vannak's avatar
      [#138] Reduce the usage `$` in Indigo · 89ae9d78
      Moremi Vannak authored
      Problem: Indigo code often contains the `$` Haskell operator,
      however since the language is meant to be used by people not
      familiar with Haskell it would be great to not make it a necessity.
      Solution: Reduce usage of `$` in 2 places:
      1. right before `do` is used for a block code
      - Solved by using `BlockArguments`
      2. right after `new`
      - Solved by treating `new$` as one keyword
    • Moremi Vannak's avatar
      Merge branch 'rinn7e/#206-split-indigo-prelude' into 'master' · 7e35220f
      Moremi Vannak authored
      [#206] Split `Indigo.Prelude` into 2 modules
      Closes #206
      See merge request !411
    • Moremi Vannak's avatar
      [#206] Split `Indigo.Prelude` into 2 modules · c33b6891
      Moremi Vannak authored
      Problem: `Indigo.Prelude` was originally used to define all the
      hiding rules in one place and then to be imported within Indigo.
      However, we also export as part of `Indigo` module which then
      creating conflicts due to we re-using the same function names
      and syntax to write Indigo contract.
      Solution: Split current `Indigo.Prelude` into two.
      `Indigo.Backend.Prelude` which is used like it original purpose.
      New `Indigo.Prelude` which should be used as Export to write
      Indigo contract.
  2. 21 May, 2020 6 commits
  3. 20 May, 2020 11 commits
  4. 19 May, 2020 20 commits
    • Ivan Gromakovskii's avatar
      Merge branch 'gromak/update-gitlab-files' into 'master' · f4a79b75
      Ivan Gromakovskii authored
      Update gitlab files
      See merge request !417
    • Ivan Gromakovskii's avatar
      Require cabal-version to be 2.2 · 6be834a4
      Ivan Gromakovskii authored
      Problem: somehow hpack decided to set `cabal-version` to 2.0 and
      now `indigo` fails the check for common mistakes:
      Package check reported the following errors:
      The package uses RebindableSyntax with OverloadedStrings or
      OverloadedLists in default-extensions, and also Paths_ autogen module.
      That configuration is known to cause compile failures with Cabal < 2.2.
      To use these default-extensions with Paths_ autogen module specify at
      least 'cabal-version: 2.2'.
      Solution: in order to avoid such errors we explicitly require
      cabal-version to be 2.2.
    • Ivan Gromakovskii's avatar
      morley-1.3.0 · 2d2baa37
      Ivan Gromakovskii authored
    • Ivan Gromakovskii's avatar
      lorentz-0.3.0 · ff60a527
      Ivan Gromakovskii authored
    • Ivan Gromakovskii's avatar
      Update license information in Haskell packages · 9754db3a
      Ivan Gromakovskii authored
      Problem: we recently updated license that applies to all files.
      Now it's MIT. But Haskell packages still say it's AGPL.
      Solution: update `LICENSE` files and `license` fields.
    • Ivan Gromakovskii's avatar
      Add root LICENSE file · 0b9ddcc2
      Ivan Gromakovskii authored
      Problem: gitlab UI says there is no license, but actually there is one.
      Apparently it expects a license in the root.
      Solution: add LICENSE file to the root.
    • Ivan Gromakovskii's avatar
      Add 'Legal' chapter to the contribution guidelines · 4bbc3b9c
      Ivan Gromakovskii authored
      Problem: we now follow REUSE practices, but not all developers are
      familiar with them, so we should describe them.
      Solution: describe them in CONTRIBUTING.md.
    • Ivan Gromakovskii's avatar
      Remove build recommendations from the contributing guidelines · 6170e094
      Ivan Gromakovskii authored
      Problem: our contributing guidelines say something about `intero`, but
      `intero` project is dead, so these guidelines are pretty much useless
      Solution: remove that section entirely.
    • Ivan Gromakovskii's avatar
      Fix some broken/obsolete links · 9680cdfb
      Ivan Gromakovskii authored
      Problem: recently gitlab changed the way URLs are formed, specifically:
      1. There is `/-/` in many URLs such as
      2. Because of that some relative links like `../blob/foo` are broken.
      3. And of course many links are a bit obsolete because they get
      1. Apparently now we can use saner links in MR templates, e. g.
      just `README.md` instead of `../blob/master/README.md`. So we do it.
      2. Obsolete links are updated to include this `/-` thing.
    • Ivan Gromakovskii's avatar
      Merge branch 'gromak/hack-storage-size-computation' into 'master' · b7e0b104
      Ivan Gromakovskii authored
      [#139] Use a hackier way to compute storage size in client
      See merge request !423
    • Ivan Gromakovskii's avatar
      [#139] Use a hackier way to compute storage size in client · 4ea6dca5
      Ivan Gromakovskii authored
      Problem: currently `morley-client` computes storage size incorrectly.
      If there are multiple transactions and at least one of them targets
      an implicit account it will compute `arStorageSize` as `Nothing`
      and eventually we will assume that storage limit is 257 (and add 20
      for safety).
      But the real storage size consumption can be much greater because
      for example a transfer to a smart contract can be involved.
      Solution: compute `arStorageSize` pessimistically and treat each
      `Nothing` as 257. We may set higher limit than necessary, but normally
      it shouldn't be a problem, especially given that we are currently
      using this code only for testing. Storage limit is only a safety
      A better solution is postponed and will be handled in #139.
      At this point I need a hotfix for another project.
    • Ivan Gromakovskii's avatar
      Merge branch 'gromak/#183-refactor-morley-client' into 'master' · 0c106a4d
      Ivan Gromakovskii authored
      [#183] Refactor morley-client
      See merge request !412
    • Ivan Gromakovskii's avatar
      [#183] Use `signWithTezosClient` in client actions · c0dc82fa
      Ivan Gromakovskii authored
      Problem: currently actions like `originateContract` that depend
      on both tezos-client and RPC have two ways of signing abstractions:
      1. `HasTezosClient` type class with its `signWithTezosClient` method.
      2. `ByteString -> m Signature` argument.
      It leads to extra code and there is no reason to have both
      abstractions. Currently we are using the second one and abstract
      `signWithTezosClient` is unused.
      Solution: remove the second abstraction for consistency with other
      abstractions, i. e. use only abstract `signWithTezosClient`.
      In tests we define it using pure `Ed25519.sign`.
      Apart from that now it takes `AddressOrAlias` argument instead of
      `Alias` to remove the need to call `getAlias` outside.
    • Ivan Gromakovskii's avatar
      [#183] Change HexJSONByteString to ByteString in signing functions · 6de0067e
      Ivan Gromakovskii authored
      Problem: there are some `sign*` functions that take
      `HexJSONByteString` argument. The only purpose of `HexJSONByteString`
      type is to provide instances used by `aeson`, i. e. specify JSON
      encoding. `sign*` functions don't care about JSON encoding, it's
      irrelevant for signing. So there is no reason to pass
      `HexJSONByteString` ther.
      Solution: pass `ByteString` instead.
    • Ivan Gromakovskii's avatar
      [#183] Decouple HasTezosClient and HasCli · f202c085
      Ivan Gromakovskii authored
      Problem: currently `HasTezosClient` requires `HasCli` constraint
      but there is no reason for that, these are unrelated concerns.
      And presence of HasCli in TezosClient.Class looks weird.
      Moreover, it leads to too strict constraints when `HasTezosClient`
      is requested but `HasCli` is sufficient (and there is no warning in
      this case).
      Solution: move `HasCli` outside and remove it from `HasTezosRpc`
    • Ivan Gromakovskii's avatar
      [#183] Remove `instance HasCli IO` and `parseArgs` · dc13108c
      Ivan Gromakovskii authored
      Problem: this instance and `parseArgs` are not used anymore, we
      can safely remove them.
      Solution: remove them.
      Even if we ever want to write mock tests involving command line
      parsing, abstractions for that shouldn't be in `morley-client`
      or anywhere else in this repo, they are not bound to Tezos in any way.
    • Ivan Gromakovskii's avatar
      [#183] Hide `decodeOriginationScriptCode` · 2f6469ec
      Ivan Gromakovskii authored
      Problem: `OriginationScript` is quite RPC-specific type. It's
      inconvenient to use it outside of RPC modules because it operates
      with `Expression` type and there are basically no functions to work
      with `Expression` outside of RPC.
      However, `getContractScript` is the only way to get contract for
      an address and it returns `OriginationScript`.
      Solution: define `getContract` that combines `getContractScript` and
      `decodeOriginationScriptCode`, use it in `Main`.
    • Ivan Gromakovskii's avatar
      [#183] Remove `waitForOperationRpc` · 25168f28
      Ivan Gromakovskii authored
      Problem: we have two ways to wait for inclusion of a certain operation.
      One of them is `waitForOperationRpc`. It is supposed to be a simple
      and lightweight alternative to `waitForOperation` that calls
      `tezos-client`. We were not sure what is better.
      However, `waitForOperationRpc` is implemented quite incorrectly
      because it waits for 10 seconds before checking again. If block
      creation interval is 1 second, it will wait much more than necessary.
      So ideally it should know block creation interval and wait depending
      on that value, there is no perfect value for all cases (since it can
      be 1 second or 1 minute or something else).
      We probably can implement it correctly, but it won't be simple anymore
      and at this point it seems definitely easier to just remove it.
      Solution: remove `waitForOperationRpc`.
    • Ivan Gromakovskii's avatar
      [#183] Use Address in client API · d49e78d4
      Ivan Gromakovskii authored
      Problem: currently our API uses `Text` for everything even if it
      is something more specific like `Address`. For this reason
      users of API have to apply `formatAddress`. And API is not as
      descriptive and type-safe as it could be.
      Solution: a straightforward solution is to define `ToHttpApiData`
      instance for `Address` but it would lead to an orphan instance.
      So we define a helper newtype wrapper `Address'` and use it in API.
      And we define trivial helpers that hide `Address'`.
    • Ivan Gromakovskii's avatar
      [#183] Separate tezos-client and RPC parts of client · b0b93876
      Ivan Gromakovskii authored
      Problem: currently there is some mess in `morley-client`,
      especially its `Morley.Client.Types` module that mixes
      RPC-specific types, tezos-client-specific types and generally useful
      1. Update `Morley.Client` hierarchy by making it more granular.
      We have:
      * `Morley.Client.RPC` that deals with node RPC;
      * `Morley.Client.TezosClient` that provides and interface to
      * `Morley.Client.Action` with actions requiring both RPC and
      2. Update the list of things that are exported from `Morley.Client`.
      It's a top-level catch-all module of `morley-client`, so now it
      exports all high-level functionality (some of it was missing) and
      does not export various low-level details such as RPC types.
      3. Executables now use `execParser` directly because it eliminates
      one level of indirection and because we will never want to test CLI
      parser of those executables (they are not for production usage).
      Note that RPC and TezosClient are still a bit coupled by
      MorleyClientEnv that contains more stuff than either of these parts
      needs. So TezosClient requires servant stuff (and doesn't use it)
      while RPC requires alias prefix for example.