1. 27 Oct, 2020 6 commits
    • Ivan Gromakovskii's avatar
      indigo-0.3.1 · d0ba0ed6
      Ivan Gromakovskii authored
      Problem: we need to release a new indigo version compatible with
      latest lorentz where `UStore` stuff was removed.
      Solution: update its version, record changes in the changelog.
    • Ivan Gromakovskii's avatar
      Rename U* constructors of Expr to St* · c71405c3
      Ivan Gromakovskii authored
      Problem: in indigo, things like `uUpdate` were renamed to `stUpdate`
      recently, however, the corresponding constructors were not renamed,
      so now naming is inconsistent and a bit confusing.
      Solution: rename constructors accordingly.
    • Roman Melnikov's avatar
      [#352] Explicitly define bin-path for indigo · fae7496f
      Roman Melnikov authored
      Problem: Currently `stack install` installs executables to
      `$HOME/.local/bin` and we use this fact in our tests. However,
      default location can be changed one day.
      Solution: Explicitly use default location via `--local-bin-path` option.
    • Roman Melnikov's avatar
      [#352] Install indigo via install.sh and test it · 5409683c
      Roman Melnikov authored
      Problem: We have an installation script for indigo that needs
      to be tested.
      Solution: Use `install.sh` script in the nearly bare ubuntu docker image
      to test that it correctly installs indigo with all its dependencies.
      Also run simple scenario that incorporates 'indigo' calls using newly
      script-based install indigo binary.
    • Konstantin Ivanov's avatar
      Remove UStore usages in indigo · c9eb8f4d
      Konstantin Ivanov authored
      Problem: indigo uses `UStore` in its operations, but `UStore` is going
      to be moved to another repository.
      Solution: be polymorphic over storage via using `StoreClass` module.
      Also replace `UStore` usages in tests with some simple storage
      containing `Map` (not `BigMap` for simplicity).
    • Roman Melnikov's avatar
      [#389] Fix haddock in the repo · 9f9a53ae
      Roman Melnikov authored
  2. 26 Oct, 2020 1 commit
    • Moremi Vannak's avatar
      [#349] Remove the usage of mixin from Indigo CLI's generated boilerplate · 7c670dd4
      Moremi Vannak authored
      Problem: Since `indigo` CLI calls `stack` behind the scene, the usage of
      mixin in `indigo` CLI causes a lot of issue due the fact that `stack`
      does not work well with mixin currently.
      Solution: Remove the usage of `mixin` from the generated boilerplate,
      replace `morley-prelude` with `universum` and update docker script to
      ensure that the REPL command of docker indigo works properly.
  3. 21 Oct, 2020 3 commits
    • Roman Melnikov's avatar
      [#349] Strip useless stack cache parts · 892b1179
      Roman Melnikov authored
      Problem: We want to make resulting indigo image as small as possible.
      Solution: Remove some useless files and directories from /root/.stack
      that don't affect compilation time.
    • Roman Melnikov's avatar
      [#349] Move indigo dockerfiles and reuse contents · fe5c47c0
      Roman Melnikov authored
      Problem: Currently indigo related dockerfiles are located in the
      repository root. Also, they're very similar.
      Solution: Move them to `code/indigo` and base image for trial usage
      on the image that is used for indigo binary testing.
    • Roman Melnikov's avatar
      [#349] Use `--allow-different-user` in docker · d3ce53ad
      Roman Melnikov authored
      Problem: There is a different root user inside the docker container
      that builds indigo project, so it's required to use
      `--allow-different-user` stack flag when running indigo commands
      inside the container.
      Solution: Use `--allow-different-user` stack flag when
      `INDIGO_IN_DOCKER` env variable is set.
  4. 11 Oct, 2020 1 commit
    • Alyona Antonova's avatar
      [#319] Add Michelson style `div` and `mod` to Indigo tests · 0ac2c419
      Alyona Antonova authored
      Problem: Some Indigo tests contain `div` and `mod`, which
      are replaced by `divMich` and `modMich` anywhere because
      of different performance of integer division and modulo
      in Haskell and Michelson.
      Solution: Replace `div` with `divMich` and `mod` with `modMich`.
  5. 07 Oct, 2020 1 commit
  6. 02 Oct, 2020 1 commit
  7. 01 Oct, 2020 3 commits
    • Ilya Peresadin's avatar
      [#279] Combine Decompose and Sequential approach · 923952eb
      Ilya Peresadin authored
      Problem: currently Sequential machinery incompatible with
      exising decomposition approach (which has been removed)
      Solution: glue them together to get working code.
    • Pinto Pasquale's avatar
      [#279] add intermediate compilation representation for optimization · dfd43d66
      Pinto Pasquale authored
      Problem: performing analysis and modification of Indigo's code for the
      purpose of optimization during compilation is not robust, nor
      convenient. The problem resides in the fact that to manipulate the
      frontend freer monad before it is compiled to the backend we have to
      interpret it and break the bindings.
      This was circumvented based on predictability of the `Var`s resulting
      from statements, but we need something better to have a wider and more
      stable machinery for optimization.
      Solution: add an intermediate representation that is not a Monad, but a
      data-type that also contains (as "argument") the resulting vars (if
      any). The variable are all assigned in the conversion between the
      frontend and this new representation. This in turns frees the backend
      from generating variables, making its function without a return value
      as well (and allowing a conversion to happen).
      Additinally, because it was easier to solve these now instead of
      updating them and solve them later, this also solves some exising
    • Pinto Pasquale's avatar
      [#279] remove Indigo's machinery for field decomposition · 7fe0beea
      Pinto Pasquale authored
      Problem: current field-based optimization is built around decomposed
      structures, this is not compatible with the SRA compiler optimization
      that we want to implement.
      Solution: revert the field decomposition machinery, return to a simple
      variable representation and field manipulation.
      As a result of this semplification the `Indigo.Internal.Object` module
      has been renamed to `Indigo.Internal.Var`.
  8. 29 Sep, 2020 2 commits
  9. 25 Sep, 2020 1 commit
    • Moremi Vannak's avatar
      [#270] Add Indigo CLI installation script · 812bb78e
      Moremi Vannak authored
      Problem: Currently to get started with Indigo, we need to ask the users
      following its tutorial to do two things:
      - install `stack`
      - compile Indigo
      This is not ideal, because it requires to read about `stack` and a lot of
      patience just to try out even the first, simplest, example.
      What we would like for the user instead is to be able to "grab" and/or
      install Indigo directly without having to jump through hoops.
      Solution: Create a script that will install stack and
      Indigo CLI and add how to install Indigo CLI in the tutorial.
  10. 24 Sep, 2020 1 commit
  11. 16 Sep, 2020 1 commit
    • Moremi Vannak's avatar
      indigo-0.2.2 · d3827ea9
      Moremi Vannak authored
      Problem: After indigo executable is merged, we need to release new version
      since it is needed in #270.
      Solution: Update to version 0.2.2, record in the changelog.
  12. 14 Sep, 2020 1 commit
    • Moremi Vannak's avatar
      [#269] Make Indigo a tool · f2baa6f8
      Moremi Vannak authored
      Problem: Indigo is currently only a library, meaning it can be used only as
      part of another project or using `ghci` (which is why the tutorial is based on this).
      However, it would be nice to have Indigo as an executable tool as well.
      Such application needs to be standalone and, for starters, be able to replace the
      `stack ghci :indigo-repl` from the tutorial in all its (non-interactive) uses, namely:
      compile an Indigo contract to Michelson and print it (to file as well).
      Solution: Make `indigo executable` that could create a boilerplate,
      wrap around `stack` for `build`, `run`, and `repl` commands, and wrap
      around lorentz `ContractRegistry` commands.
  13. 04 Sep, 2020 3 commits
    • Pinto Pasquale's avatar
      [#337] update Indigo version to 0.2.1 · 5c53c33c
      Pinto Pasquale authored
      Problem: after the previous changes we need to make a new version
      of Indigo to be used in other packages.
      Solution: update Indigo changelog and package files to bump up the
    • Pinto Pasquale's avatar
      [#337] use specific coercions for Indigo's name/unname compilation · cb1873ab
      Pinto Pasquale authored
      Problem: Indigo compiles 'name' and 'unname' expressions to Lorentz
      by using the generic 'forcedCoerce_' coercion, however there are
      more specific instructions in Lorentz for them.
      Solution: use the more specific 'toNamed' and 'fromNamed' Lorentz
      instruction to compile 'name' and 'unname' Indigo expressions.
    • Pinto Pasquale's avatar
      [#337] add expression to coerce to Indigo · 008a4460
      Pinto Pasquale authored
      Problem: there is no way in Indigo to coerce from a type to another
      that has the same Michelson representation.
      Solution: add a 'coerce' and 'forcedCoerce' expressions to allow
      coercing between these types.
      fixup! [#337] add expression to coerce to Indigo
  14. 02 Sep, 2020 2 commits
    • Pinto Pasquale's avatar
      [#316] Use `IsExpr` only on the front-facing Indigo functions · 2ab1575a
      Pinto Pasquale authored
      Problem: using `IsExpr` in data constructors and for backend
      functions arguments has no real advantage and has some problems.
      Mainly, it causes the manipulation of statements and expressions
      to be require many unwrapping.
      Solution: use `Expr` everywhere except on the functions that the
      user ultimately interfaces with, making the `toExpr` conversion at
      the very beginning.
      Additionally, this removed the `AreExpr`, for lack of usage.
    • Pinto Pasquale's avatar
      [#330] add wrap and unwrap expressions for sum types constructors · a946fe8a
      Pinto Pasquale authored
      Problem: Indigo lacks an equivalent of Lorent'z `wrap_` to make
      values of sum types from a single-field constructor.
      Moreover, the same can be said for unwrapping.
      Solution: add expression to Indigo to perform wrapping and unwrapping
      of values to/from single-field constructors of sum types
  15. 01 Sep, 2020 1 commit
    • Moremi Vannak's avatar
      [#277] Add good example contracts to the Indigo website · 15489cf4
      Moremi Vannak authored
      Problem: People want to see examples of Indigo smart contracts,
      but our website does not have anything beside toy examples. We have
      some examples that demonstrate how Indigo can be used to write non-toy
      contracts, we should make it easy to find them. If you consider using
      Indigo for your non-toy project, you want to see examples of successful
      non-toy smart contracts.
      Solutions: Add examples of Indigo smart contracts in the Indigo doc such as:
      - AbstractLedger and ManagedLedger
      - Globacap
  16. 31 Aug, 2020 1 commit
    • Moremi Vannak's avatar
      [#180] Add contract documentation tutorial to Indigo website · a1550c8c
      Moremi Vannak authored
      Problem: The first problem is that documenting entrypoints requires defining
      instances of a big typeclass, which is scary-looking for beginners,
      especially if they are not Haskell-friendly.
      The second problem is that, while there are ways to print and create contracts
      from ghci explained in the tutorial, there is no explanation of docs in it or
      method to interact with them.
      Solution: Add documentation tutorial including the interacting docs via the
  17. 27 Aug, 2020 1 commit
    • Pinto Pasquale's avatar
      [#315] remove FromLorentz machinery from Indigo · 103e3cb6
      Pinto Pasquale authored
      Problem: we had some machinery to convert Lorentz instruction to
      Indigo, but it was meant to be temporary and we no longer use it
      (given that it is a feature of Indigo's backend only).
      Solution: remove the TH function and the exporting of the generated
  18. 26 Aug, 2020 1 commit
    • Artem Yurchenko's avatar
      [#140] Use `with-utf8` to handle encoding issues · 1beb25d1
      Artem Yurchenko authored
      Problem: There already is some effort to handle encoding
      correctly. However, current tools not as comprehensive as the existing
      `with-utf8` library. More over, it's time and effort wasting to
      reimplement existing functionality with no clear benefits.
      Solution: Rewrite necessary functions using `with-utf8`.
      In some cases, encoding into utf-8 is redundant (e.g. Aeson.encode
      already emits a utf-8 bytestring), so I got rid of it altogether.
      Michelson code (actually, just comments) is also supposed to be utf-8
      encoded, so we can safely use utf-8 for console output.
  19. 24 Aug, 2020 2 commits
    • Ivan Gromakovskii's avatar
      [Chore] Prepare new releases · b46f8cb1
      Ivan Gromakovskii authored
      Problem: latest releases of `morley` and `lorentz` have been made
      from `0574c85b`. However, `cleveland` there is quite unusable due to
      the problem fixed in
      And newer version of `cleveland` is inconvenient to use with old
      versions of its dependencies.
      Solution: update versions of packages to release them.
    • Pinto Pasquale's avatar
      [#314] move `#=` to Indigo's frontend and make it a synonym for `//->` · c9502faf
      Pinto Pasquale authored
      Problem: we had a `#=` operator that was a synonym of `/->`, but the
      former is no longer usable and the latter is not used in favor of
      `//->` (in the frontend).
      Solution: `move `#=` to Indigo's frontend and make it a synonym for
      `//->` instead.
  20. 18 Aug, 2020 1 commit
  21. 12 Aug, 2020 1 commit
    • Ivan Gromakovskii's avatar
      Remove redundant pragmas · a14ad1e5
      Ivan Gromakovskii authored
      Problem: we have a lot of extensions enabled in default-extensions,
      some of them are additionally enabled in some modules.
      It's redundant and, subjectively, makes code a bit more verbose which
      I personally dislike. I propose to remove this redundancy.
      Solution: remove redundant LANGUAGE pragmas that duplicate default
  22. 07 Aug, 2020 1 commit
    • Moremi Vannak's avatar
      [#236] Handle constructor annotation in Lorentz · 46e19339
      Moremi Vannak authored
      Problem: Good smart contracts should have annotations for nearly each
      meaningful component of their parameter and storage types. So we should
      enforce usage of annotations and somehow indicate if a contract does not
      have annotations that we think it should have. However, we should do it
      carefully for parameter, so that we don't introduce extra entrypoints.
      Solution: Allow generating constructor annotation for other meaningful
      parts of parameter and storage while ensure no extra entrypoints are
  23. 05 Aug, 2020 2 commits
    • Pinto Pasquale's avatar
      [TM-410] fix Indigo website included lines · e0f2026b
      Pinto Pasquale authored
      Problem: Some lines included in the website from source files are not
      correct. The mistake was probably caused by an incorrect update after
      switching from 0-indexed to 1-indexed, so there are 2 issues:
      - single lines are included still using 0-indexes
      - some line indexes have not been updated, pointing at some wrong lines
      Solution: update the line-including plugin to use 1-indexing for single
      lines and update the indexes in document inclusions that are incorrect.
    • Pinto Pasquale's avatar
      [#311] add more info for contributing to Indigo's Website · 72e648b6
      Pinto Pasquale authored
      Problem: Indigo's website does not explain how to open issues or merge
      requests for it. Additionally, its directory's README does not specify
      well how to build it or check the result of changes.
      Solution: add a paragraph for contributing to the website's main page
      and more building info in its source code README.
  24. 22 Jul, 2020 1 commit
    • Anton Myasnikov's avatar
      [#27] Rename EntryPoints to Entrypoints · 18f53c2c
      Anton Myasnikov authored
      Problem: Currently we have some appearances of
      "EntryPoints" throughout the project which should
      be renamed to "Entrypoints".
      Solution: Rename the corresponding types, functions
      and modules.
  25. 20 Jul, 2020 1 commit
    • Moremi Vannak's avatar
      [#282] Add safe initial values for mutez · 6c6f6526
      Moremi Vannak authored
      Problem: It would be nice to have safe initial values for mutez like zero and one,
      available directly from the library and they are pretty common things to have for
      Natural-like numbers.
      Solution: Add `zeroMutez` and `oneMutez`.