pontem-network / dove Goto Github PK

Hello again!
While dove prove works fine with 1.3.0-44c7e88, the --z3-exe switch seems broken in 1.3.0-9283954.

One used to be able to run dove prove --boogie-exe ~/.dotnet/tools/boogie --z3-exe ~/bin/z3 successfully, but with the current version, the output is as follows:

➜  taohe git:(master) ✗ dove prove --boogie-exe ~/.dotnet/tools/boogie --z3-exe ~/bin/z3

ERROR: z3 executable not found in PATH. Please install it from https://github.com/Z3Prover/z3

The only way I got this to work was setting up PATH correctly, and running dove prove without arguments. (With the arguments above, I would still get errors: cvc4 cannot be found, and --cvc4-exe does not seem to fix the problem.)

Since 1.2.3 the following does not seem to work anymore:
dove run --file folder --signers "0x2f66c09143acc52a85fec529a4e20c85" "somethinghere()"

Giving:
ERROR: unable to parse AccoutAddress.

When creating a project with a recursive dependency, an error occurs:

Download:[https://github.com/vladimirovmm/for_test_dove_repositories]

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)

Example of a recursive dependency:
https://github.com/vladimirovmm/for_test_dove_repositories/tree/cyclic_dependency

Or in dove.toml:

dependencies = [
    { git = "https://github.com/pontem-network/move-stdlib", tag = "v0.1.2" },
    { git = "https://github.com/vladimirovmm/for_test_dove_repositories", branch = "cyclic_dependency" },
]

There is errors when user using pre-compiled Dove binary:

See screen contains error.

dove run does not handle script files with multiple script{}s correctly.

Example

Consider the following example:

// dummy.move:
script {
    fun main() {
        assert(true, 0);
    }
}

script {
    fun main() {
        assert(true, 0);
    }
}

And try to run it with: dove run --file dummy

Expected result

script{}s should be run one-by-one, in the specified order.

Actual result

thread 'main' panicked at 'removal index (is 0) should be < len (is 0)', library/alloc/src/vec/mod.rs:1355:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The decompiler doesn't work on *.mvt files.
How to reproduce: Just generate any *.mvt file and try to decompile it, you will get error:

status BAD_MAGIC of type Deserialization

Hello, fellow Move soldiers!
We continue marching on, despite the negative news lately.
Glad to see 1.6 being released nevertheless 🎉

The previous issue with dove test that was fixed in 1.5.6 (#180) reincarnated in 1.6.0-86817ac.

The test problem being:

┌── test_wrap ──────
│ ITE: An unknown error was reported. Location: 
│ VMError (if there is one): VMError {
│     major_status: UNEXPECTED_VERIFIER_ERROR,
│     sub_status: None,
│     message: Some(
│         "Unexpected verifier/deserialization error! This likely means there is code stored on chain that is unverifiable!\nError: VMError { major_status: MISSING_DEPENDENCY, sub_status: None, message: None, location: Module(ModuleId { address: 0000000000000000000000000000000000000000000000000000000000000001, name: Identifier(\"DiemAccount\") }), indices: [(FunctionHandle, 0)], offsets: [] }",
│     ),
│     location: Module(
│         ModuleId {
│             address: 0000000000000000000000000000000000000000000000000000000000000001,
│             name: Identifier(
│                 "DiemAccount",
│             ),
│         },
│     ),
│     indices: [
│         (
│             FunctionHandle,
│             0,
│         ),
│     ],
│     offsets: [],
│ }
└──────────────────

Hello!
Do you plan to develop and support Dove (with Diem) after move-build lands (diem/diem#8775)?

It would be great to have only one build system for all the MoveVM platforms, so as a developer I would hope that either:

• Pontem would switch to move-build, or
• Pontem would continue supporting Diem 🙂

E.g.

• cargo install --bin=dove --path dove
• cargo install --bin=dove --git=this_repo_branch

Hello everyone!
When Move 1.4 (https://github.com/diem/diem/releases/tag/diem-core-v1.4.1) would be supported?
I would need phantom support 😆 (Specifically, I would need support for different abilities for phantom types than the struct itself. In my understanding this is not supported in "vanilla" Move, although older Move conceptually supports phantom types.)

Move 1.4 changelog is a bit misleading, since phantom is not listed in changes/ on that tag, but is still implemented, as can be seen here.

Now we use the documentation comments to describe the skate tests. Which is not valid from the point of view of the compiler. Now we ignore this problem.
And we are also tied to the standard library.
To fix this, we are adding a DSL to initialize the state of the test story.

Samples:

It is executed before the test is executed and allows you to configure the state.

#[before(
    use 0x1::Block;
    Block::set_block(1000);
    let coin = {value : 42};
    move_to(0x1, 0x1::Account::Balance<0x1::Coins::BTC> { coin: coin })
)]

A flag indicating that changes made during the script execution will be ignored by the following scripts.
#[dry_run]

Expectations that the test will fail with an abortion error.
#[failure=1]

• diem fork
• dove
  • land
    • compiler
    • decompiler
  • executor
• resource viewer
• language server

e.g.: dove build --account-address

While trying to run "dove run" with Dove 1.3.0, I get:

➜  taohe git:(master) ✗ dove run --file immutable                                                                  
Execution failed with unexpected error CODE_DESERIALIZATION_ERROR

This used to work with 1.2.8.

You can use https://github.com/taoheorg/taohe for testing (master supports Dove 1.3.0).

EDIT: If you are using TaoHe for testing, it's probably noteworthy that dove run --file dummy does not produce any output, but instead terminates silently.

We need tests of local and git dependencies.

• check cyclic dependencies.
• check transitive dependencies.
• check git dependencies with local dependencies.

Hello!
Until recently, I was able to install Dove by running: cargo install --path dove. However, it does not work anymore, resulting:

➜  move-tools git:(9283954) ✗ cargo install --path dove
  Installing dove v1.3.0 (/home/ville/projects/move-tools/dove)
    Updating crates.io index
    Updating git repository `https://github.com/pontem-network/diem.git`
    Updating git repository `https://github.com/scs/substrate-api-client.git`
error: failed to compile `dove v1.3.0 (/home/ville/projects/move-tools/dove)`, intermediate artifacts can be found at `/home/ville/projects/move-tools/target`

Caused by:
  failed to select a version for the requirement `crypto-mac = "^0.7"`
  candidate versions found which didn't match: 0.11.1, 0.11.0, 0.10.1, ...
  location searched: crates.io index
  required by package `hmac v0.7.0`
      ... which is depended on by `hmac-drbg v0.2.0`
      ... which is depended on by `libsecp256k1 v0.3.4`
      ... which is depended on by `sp-io v2.0.0`
      ... which is depended on by `substrate-api-client v0.4.9-sub2.0.0 (https://github.com/scs/substrate-api-client.git?rev=62afbac0be1928681d8c70565fa0cc39a92cf4c8#62afbac0)`
      ... which is depended on by `net v0.1.0 (/home/ville/projects/move-tools/net)`
      ... which is depended on by `dove v1.3.0 (/home/ville/projects/move-tools/dove)`

However, this does not seem to be problem with move-tools since this does not work on tag 1.2.8, which used to work just fine. I have now tried 1.3.0, 1.2.8 and 44c7e88 but to no avail. 1.2.8 and 44c7e88 used to work, I even have 44c7e88 installed:

➜  taohe git:(master) ✗ dove --version
Dove 1.3.0-44c7e88

But as said, this does not seem to be move-tools problem, but just reporting this, in case you guys can do something about it 🙂

There's already existing templates but configurable with manifest only.
Would be great to call something like dove doc-gen template to gen template in default place fo future use.
Then you edit the template and then build neat docs with it.

Hello!
Using TaoHe, consider the following file, and place it to scripts/:

script {
    use TaoHe::Errors;

    fun dummy_1() {
        assert(true, Errors::ownable_not_owned());
    }
}

It results the following error message while running dove run -v "dummy_1()":

error[E03002]: unbound module
   ┌─ /home/ville/projects/taohe/scripts/dummy.move:17:9
   │
17 │     use TaoHe::Errors;
   │         ^^^^^^^^^^^^^ Invalid 'use'. Unbound module: 'TaoHe::Errors'

error[E03002]: unbound module
   ┌─ /home/ville/projects/taohe/scripts/dummy.move:20:22
   │
20 │         assert(true, Errors::ownable_not_owned());
   │                      ^^^^^^ Unbound module alias 'Errors'

...while this works fine (also you can use the upstream dummy() to verify this):

script {
    fun dummy_2() {
        assert(true, 123);
    }
}

TaoHe namespace (and even TaoHe::Errors) is used multiple times in sources/, and is compiling fine. This problem (or some variation of it) seems to occur with dove test too.

Hello!
Recently the Diem Association (read: Facebook 😆 ) has been very interested to expand Move support to platforms such as NEAR (in fact, directly sponsored by Facebook).

This can lead to a situation, where a feature (for example: retrieving current time) can be implemented differently on Diem, Pontem and NEAR (since that would be platform specific, not language specific).

So, I would like to request a feature that would permit compiling different files if on a certain platform, and would also include (and exclude) some dependencies accordingly.

For example:

• If on Diem, would compile DiemHelpers.move implementing Helpers-module, and include diem-stdlib as a dependency.
• If on Pontem, would compile PontemHelpers.move implementing Helpers-module (and not DiemHelpers.move).
• Other .move files could then just use Helper::getTime().

(Of course all of this would be project specific, and defined in Dove.toml.)

Hello!
It seems that binaries are not produced if warnings are encountered (1.6.1-5ac671a).

Consider the following file, let's call it Invalid.move:

/** invalid documentation comment **/

Running dove build will report:

warning[W01004]: invalid documentation comment
  ┌─ ./sources/Invalid.move:1:1
  │
1 │ /** invalid documentation comment **/
  │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Documentation comment cannot be matched to a language item

While most of the warnings are worth fixing, some warnings don't need fixing: for example generics in script functions, which currently report:

warning[W04022]: script function cannot be invoked with this signature (NOTE: this may become an error in the future)

(Ending up not generating binaries.)

The compilation process itself is not aborted, you can see warnings from multiple files. Final binaries are not generated, though.