Comments (7)
Ok I see from https://github.com/ethereum/tests/blob/develop/PRLOG.md that they're used in transition tests. Then I have the following questions/suggestions:
-
Why is this distinction between "regular forks" and "transition test forks" really needed in config? I think retesteth knows which chain configs are required for state tests (it's written in the test) and which others are required for transition tests. So it seems they all could be in a single list, not to complicate configuration for the user.
-
If you insist that it's needed, I'd say a better name could be maybe
transitionTestConfigs
, to more clearly show what's its purpose (maybe later you would need some other type of tests/configs, what would you call it then, "additionalForks2"?)
from retesteth.
no. the reason is that forks from regular forks section are ordered and dynamic. retesteth just takes names from those and apply operators from tests.
so the client could fill up tests a < b < c < d given that a,b,c,d could be any name.
so I had to extend the allowed fork names by another section. cause transition tests use unique fork names. and for that fork names tests should not be generated when parsing >=a
the transition tests still not quite work with retesteth + geth.
from retesteth.
no. the reason is that forks from regular forks section are ordered and dynamic. retesteth just takes names from those and apply operators from tests.
so the client could fill up tests a < b < c < d given that a,b,c,d could be any name.
Running a test or filling a test on a particular fork is independent of other forks, so I don't see why order matters.
So do you mean that the point of forks
is to allow filling only for the subset of forks? As I pointed out in #67 (striked out part) I think this should be better fine-tuned with command line options.
so I had to extend the allowed fork names by another section. cause transition tests use unique fork names. and for that fork names tests should not be generated when parsing >=a
I see, but to me this is an internal logic of retesteth. I think other clients would use these same srtings like FrontierToHomesteadAt5
if they would want to generate transition tests.
So my doubts from #67 apply here.
the transition tests still not quite work with retesteth + geth.
I guess they might yet not support at all these transition config names (but I don't know)
from retesteth.
Thats the point of configs. Any new client could use custom names and change any string
from retesteth.
I argue in #67 that this flexibility is not really needed by anyone, all the clients adapt their fork name strings when they integrate retesteth support anyway. It's just an additional configuration hassle to make it work right + additional maintenance pain for you.
from retesteth.
what about fork+EIP config?
I'd really like to keep custom fork support.
Maybe it should be split to a different config file then socket configuration.
from retesteth.
what about fork+EIP config?
In case clients would use the same chain config format for this case, too, then I think retesteth could also simplify this for the user (by creating the config with +EIP activated in it at runtime)
from retesteth.
Related Issues (20)
- sender field missing HOT 1
- "Tests finished: 0" HOT 1
- Bad TestSuite causes no errors HOT 1
- --vmtraceraw creates traces in a temp directory and doesn't delete them HOT 3
- Allow to use pipes to deal with big traces HOT 3
- Export additional test .info HOT 1
- Simplify Solidity LLLC build HOT 1
- Unable to build on MacOS (Apple M1 Max) HOT 3
- Error: ERROR OCCURED FILLING TESTS: Invalid block: base fee not correct! Expected: `10`, got: `0` HOT 1
- Error: CompareStates failed with errors: MissingExpectedAccount / address not expected to exist HOT 1
- `--filltests` with missing (or an outdated version of) `solc` should shout an error HOT 2
- Error: Invalid block: base fee not correct @ stRandom/randomStateTest153 HOT 1
- Retesteth Usage Guide HOT 2
- Error: ERROR(3): EIP-1559 config but missing 'currentBaseFee' in env section HOT 4
- Remove newline, `\n`, whitespace, and comments inside `:raw` fields in YML HOT 1
- Support the new vmtrace format from geth, even when there are errors. HOT 1
- Support `-d <num>` inside EOF tests HOT 1
- t8n: Add "sender" to JSON transaction HOT 4
- compile libboost filesystem and system packages to ubuntu 20. ppas
- Retesteth usage in a private network HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from retesteth.