Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Filetests]: Add assert helper function #229

Merged
merged 3 commits into from
Feb 23, 2024
Merged

Conversation

MCJOHN974
Copy link

@MCJOHN974 MCJOHN974 commented Feb 22, 2024

This PR adds few helper functions:
assert_eq, assert_neq, assert_dump. Filetest infra not ready yet, so I didn't change old asserts to new ones. Should I do it before merge or it can be done after? Or I should add .zkasm file somewhere to make testing this helper easy outside my machine?

@MCJOHN974 MCJOHN974 changed the base branch from main to viktar/filetests February 22, 2024 12:33
@MCJOHN974 MCJOHN974 changed the title Viktar/custom assert [Filetests]: Add assert helper function Feb 22, 2024
Base automatically changed from viktar/filetests to main February 22, 2024 12:54
@aborg-dev
Copy link

This PR adds few helper functions: assert_eq, assert_neq, assert_dump. Filetest infra not ready yet, so I didn't change old asserts to new ones. Should I do it before merge or it can be done after? Or I should add .zkasm file somewhere to make testing this helper easy outside my machine?

I would lean towards keeping PRs smaller (so not changing filetests for now), but whatever is convenient to you works.

@MCJOHN974
Copy link
Author

This PR adds few helper functions: assert_eq, assert_neq, assert_dump. Filetest infra not ready yet, so I didn't change old asserts to new ones. Should I do it before merge or it can be done after? Or I should add .zkasm file somewhere to make testing this helper easy outside my machine?

I would lean towards keeping PRs smaller (so not changing filetests for now), but whatever is convenient to you works.

In that case I'm ok to keep this one as is

Comment on lines 27 to 28
// TODO: why arg* is list of two integers with last zero and first value in register???
// Is it chunks? If yes they should be merged instead of ignoring second one
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I see it is really chunks and total number can be calculated as ctx[tag.params[idx].regName][0] + ctx[tag.params[idx].regName][1] * 2**32 But maybe it worth to ask Polygon team?

Copy link

@aborg-dev aborg-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM modulo the comments.

}

/** Writes results to `config.outputFile`. */
eval_assert_dump(ctx, tag) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to call eval_assert_dump from zkAsm for some reason?
If not, we can make it a normal method of this helper class (without eval_ prefix) and call it in run-tests-zkasm.js directly.

This way we can avoid the use of fs in this class and the need to pass the outputFile in the constructor and instead do all of this in run-tests-zkasm.js. This will make this class simpler (less responsibilities) and will make it easier to write unit-tests for it.

@@ -0,0 +1,68 @@
const fs = require("fs");

class InstrumentInst {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be AssertHelper?

* ${assert_neq(regname, regname, tag)}, for example:
* ${assert_neq(A, B, test_generated_from_line_3000)}
*/
eval_assert_neq(ctx, tag) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation is off here.

@@ -10,6 +10,7 @@ const {
newCommitPolsArray
} = require('pilcom');
const buildPoseidon = require('@0xpolygonhermez/zkevm-commonjs').getPoseidon;
const assert_helper = require('./assert');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use AssertHelper name here instead of assert_helper to signal that this is a class. This will also make it easier to search the codebase as this name will match the one in the assert.js.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably assert_helper.js would be a less ambiguous name.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there will be more helpers (e.g. for benchmarking), I would propose to generate a directory like tests/zkasm/helpers and put all helpers there.

@@ -0,0 +1,68 @@
const fs = require("fs");

class InstrumentInst {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InstrumentInst is probably copied over from the helper in #214. I think here a class name like Assert or AssertHelpers would make more sense.

Comment on lines 21 to 23
* Helper function must be used in format:
* ${assert_eq(regname, regname, tag)}, for example:
* ${assert_eq(A, B, test_generated_from_line_3000)}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments usually go before any @param in JSDoc (ref).

Comment on lines 27 to 28
// TODO: why arg* is list of two integers with last zero and first value in register???
// Is it chunks? If yes they should be merged instead of ignoring second one
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this TODO should be resolved before merging. A starting point to find out more about ctx and tag passed to helpers might be helper invocation in zkevm-proverjs.

const arg1 = ctx[tag.params[1].regName][0];
const testname = tag.params[2].varName;
this.results[testname] = arg0 === arg1 ? 'pass' : 'fail';
return 0;
Copy link

@mooori mooori Feb 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the return value supposed to be written into a register? If yes, why does it not depend on the assertion?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find, thanks! It is because I used only one dollar and functions with one dollar expect output.

@MCJOHN974 MCJOHN974 added this pull request to the merge queue Feb 22, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 22, 2024
@MCJOHN974 MCJOHN974 added this pull request to the merge queue Feb 22, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 22, 2024
@MCJOHN974
Copy link
Author

Hm, seems one of the tests is failing due to update of some node packages

@aborg-dev
Copy link

Hm, seems one of the tests is failing due to update of some node packages

I think that was a flaky run, rerunning the same test now passes: https://github.com/near/wasmtime/actions/runs/8009020692

@aborg-dev aborg-dev added this pull request to the merge queue Feb 23, 2024
Merged via the queue into main with commit 6922232 Feb 23, 2024
22 checks passed
@aborg-dev aborg-dev deleted the viktar/custom-assert branch February 23, 2024 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants