1. 25 Sep, 2020 3 commits
  2. 24 Sep, 2020 6 commits
  3. 23 Sep, 2020 3 commits
    • Maxim Koltsov's avatar
      Merge branch 'maksbotan/#253-dap-init' into 'master' · 9190f939
      Maxim Koltsov authored
      [#253] DAP initialization sequence
      Closes #253
      See merge request !484
    • Maxim Koltsov's avatar
      [#253] Implement DAP initialization sequence · c01bf900
      Maxim Koltsov authored
      Problem: we have a parser for DAP and can successfully read VSCode's
      messages, but we don't answer to them, so VSCode does not consider our
      debugger initialized and ready to run.
      Solution: implement DAP writer thread which accepts DAP messages and
      writes them to stdout. Handle DAP messages that are related to the
      initialization of the adapter. At this point VSCode thinks that we are
      initialized and that the debuggee is running.
    • Maxim Koltsov's avatar
      [#253] Add more DAP types and instances · f34f1ad6
      Maxim Koltsov authored
      Problem: 1. There were some response and event types missing from our
      DAP sum types. 2. For some of the types there were no ToJSON / FromJSON
      Solution: add missing types. Rewrite TH instance generator to keep track
      of seen Name's to avoid duplicate instances and be able to derive
      instances for all needed types.
  4. 16 Sep, 2020 2 commits
  5. 14 Sep, 2020 3 commits
    • Moremi Vannak's avatar
      Merge branch 'rinn7e/#269-indigo-executable' into 'master' · 48cc2608
      Moremi Vannak authored
      [#269] Make Indigo a tool
      Closes #269
      See merge request !544
    • Roman Melnikov's avatar
      [#269] Indigo binary via docker · a1e2daf4
      Roman Melnikov authored
      Problem: It's inconvenient to run stack on nixos in our CI pipeline,
      since it will probably require nuking `~/.stack` quite often, thus we'll
      have to rebuild all dependencies very often.
      Solution: Test indigo binary inside docker container based on ubuntu
    • 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.
  6. 11 Sep, 2020 1 commit
  7. 10 Sep, 2020 10 commits
    • Diogo Castro's avatar
      [#342] Add tests for `branchout` and `offshoot` · 23202e6f
      Diogo Castro authored
      Problem: we added `branchout` and `offshoot` to Nettest, but we haven't
      added tests yet.
      Solution: write tests for `branchout` and `offshoot`.
    • Diogo Castro's avatar
      [#342] Make `PureM` a newtype · db757c69
      Diogo Castro authored
      Problem: Some compiler errors involving `PureM` are a bit cryptic since
      `PureM` is a type alias, and its details (StateT, Aliases, etc)
      sometimes leak into use sites.
      Solution: Make `PureM` a newtype.
    • Diogo Castro's avatar
      [#342] Make `runEmulated` easier to compose · f099b715
      Diogo Castro authored
      Problem: `runEmulated` cannot be used together with the existing
      functions in `Pure`. Specifically, we cannot compose it with
      `nettestTestProp` to run it via Hedgehog. If we want to run an
      `EmulatedScenario` via Hedgehog, we have to create a separate
      `emulatedTestProp` function. In practice, this would mean duplicating
      almost every function in `Pure`.
      Solution: Change `runEmulated` so that it passes *only* a `EmulatedImpl`
      dictionary into the scenario, and leaves the `NettestImpl` dict for
      later. Now, we can use compose like so: `runNettestViaIntegrational .
      runEmulated`, or `nettestTestProp . runEmulated`. 
      This required making `NettestScenario` and `EmulatedScenario`'s type
      parameter `m` universally rather than existentially quantified.
    • Diogo Castro's avatar
      [#342] [#53] Added `branchout` and `offshoot` to `Morley.Nettest` · 5cfde43f
      Diogo Castro authored
      Problem: we want Nettest to support every feature from
      `Michelson.Test.Integrational`, and eventually replace it.
      Solution: Add `branchout` and `offshoot` to Nettest.
    • Diogo Castro's avatar
      [#342] Removed `*Action` functions from Nettest · a1785a5a
      Diogo Castro authored
      Problem: We have lots of `*Action` functions in
      `Morley.Nettest.Abstract`, most of them are simple aliases to `ni*`
      functions. They're an abstraction layer for people who prefer explicit
      dictionary passing style, but no one has so far expressed that wish, so
      they turned out to be more of a maintenance burden.
      Solution: Delete the `*Action` functions that are aliases, and rename
      the ones that aren't from `*Action` to `ni*` (to match the namings cheme
      of the functions already defined in `NettestImpl`).
    • Roman Melnikov's avatar
      Merge branch 'rvem/#334-expect-custom-error-in-nettest' into 'master' · 619915ce
      Roman Melnikov authored
      [#334] Expect custom contract errors in nettest
      Closes #334
      See merge request !572
    • Roman Melnikov's avatar
      [#334] Add tests · e5cd4e1d
      Roman Melnikov authored
      Problem: New actions need to be tested.
      Solution: Add simple scenario that originates contract which always
      fails with custom error and expect this error using new action in the
      nettest sceanrio while calling this contract.
    • Roman Melnikov's avatar
      [#334] Add actions similar to `lExpectCustomError` · 2bd2c4a7
      Roman Melnikov authored
      Problem: Currently it's very inconvenient to expect contract failure
      in nettest scenario when contract fails with custom defined error.
      Solution: Add `expectCustomError` and `expectCustomError_` actions
      to the nettest which are similar to `lExpectCustomError` and
      `lExpectCustomError_` from `Lorentz.Test.Integrational`.
    • Ivan Gromakovskii's avatar
      Merge branch 'martoon/pr506-add-test' into 'master' · 1d0e1adb
      Ivan Gromakovskii authored
      [PR-506] Add test on Nops in optimizer
      See merge request !529
    • Konstantin Ivanov's avatar
      [PR-506] Add test on Nops in optimizer · 2a493bee
      Konstantin Ivanov authored
      Problem: we seem to have no test which would solely ensure that all
      extra Nops are eliminated.
      Solution: add one.
  8. 08 Sep, 2020 4 commits
  9. 07 Sep, 2020 8 commits
    • Diogo Castro's avatar
      Merge branch 'diogo/#235-address-accuracy' into 'master' · 66fc73d5
      Diogo Castro authored
      [#235] [TM-273] Improve address computation accuracy
      Closes #235
      See merge request !548
    • Diogo Castro's avatar
    • Diogo Castro's avatar
      [#235] Reduce duplication of typechecking logic · 315fc2e6
      Diogo Castro authored
      Problem: In previous commits, we ended up duplicating the logic of
      typechecking a contract and then verifying its storage is of the
      expected type.
      Solution: Add a `typeCheckContractAndStorage` function and reuse it
    • Diogo Castro's avatar
      [#235] Use binary encoding to compute hash for transfer ops · 15057831
      Diogo Castro authored
      Problem: Our interpreter should mirror the reference implementation as
      much as possible. However, at the moment, we use JSON encoding to
      compute a transfer's `OperationHash`, whereas the reference
      implementation uses binary serialization.
      Solution: Use binary serialization to compute a transfer's
      This required some small changes to the interpreter's API. Previously,
      we used `withGlobalOperation op $ execute* op` to execute a global
      operation, where `withGlobalOperation` was responsible for calculating
      the `OperationHash`. The `execute*` functions (e.g.
      `executeOrigination`, `executeTransfer`) would then consume this
      However, because:
      1. calculating the `OperationHash` for a transfer operation now uses
         binary serialization,
      2. binary serialization can only be used on *typed* values,
      3. the transfer's value can be untyped, and then later typechecked
         inside `executeTransfer`,
      ... we can't calculate the `OperationHash` upfront (in
      `withGlobalOperation`) anymore. It can only be calculated inside
      `executeTransfer`, *after* the transfer's value has been typechecked.
      To solve this, we removed `withGlobalOperation` function, and moved the
      calculation of the `OperationHash` inside the `execute*` functions.
    • Diogo Castro's avatar
      [#235] [TM-273] Use binary encoding to compute hash for origination ops · af2c0d04
      Diogo Castro authored
      Problem: Our interpreter should mirror the reference implementation as
      much as possible. However, at the moment, we use JSON encoding to
      compute an origination's `OperationHash` (and addresses), whereas the
      reference implementation uses binary serialization.
      Solution: Use binary serialization to compute an origination's
      As a result of this, `Michelson.Test.Integrational.tOriginate` no longer
      needs to untype & typecheck again, therefore addressing part of the
      issue described in TM-273
    • Roman Melnikov's avatar
      Merge branch 'rvem/#220-new-gitlab-features' into 'master' · 3c4a3714
      Roman Melnikov authored
      [#220] New Gitlab CI features
      Closes #220
      See merge request !564
    • Roman Melnikov's avatar
      [#220] Use 'rules' instead of 'only/except' · b29b39c3
      Roman Melnikov authored
      Problem: Currently suggested syntax for setting job policies is using
      'rules', 'only' and 'except' are candidates for deprectaion anc can be
      removed in the future.
      Solution: Use 'rules' everywhere in our pipeline config.
    • Roman Melnikov's avatar
      [#220] Inherit env for publish-indigo-website · 8220d3e0
      Roman Melnikov authored
      Problem: Currently we put variable contents to a file and pass it as a
      artifact, however, gitlab CI now has feature for environment variables
      Solution: Put ARTIFACTS_JOB_ID to build.env in 'build-indigo-website'
      step which will be automatically inherited in 'publish-indigo-website'.