-
Notifications
You must be signed in to change notification settings - Fork 2
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
Finish implementing initial Simulation interface #26
Closed
Closed
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
e184b27
Update types to reflect changes in the spec.
gjtrowbridge c429ffe
Save progress...
gjtrowbridge 0dd70f8
Clean up error handling a bit, start filling in methods.
gjtrowbridge fdb5a01
More stuff in create_shard_block...
gjtrowbridge 694a77b
Finish shard block func.
gjtrowbridge fab29b9
Fill in get_ee.
gjtrowbridge e0d59b8
Fill in get ee state method.
gjtrowbridge 49ef476
Implement get_shard_block.
gjtrowbridge 0dc693e
Implement get_shard_state.
gjtrowbridge 00730d0
Implement tests for create, get ee and for simulation.new.
gjtrowbridge c8e2668
Add test for running transactions.
gjtrowbridge 3048eac
Finish tests.
gjtrowbridge 79a7a69
Add some comments.
gjtrowbridge 59d497f
More small changes.
gjtrowbridge b14447b
Run cargo fmt
gjtrowbridge 084755a
Address review comments.
gjtrowbridge 42371d3
Change from vl_wasm_code to wasm_code.
gjtrowbridge File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,11 @@ authors = ["Greg Trowbridge <[email protected]>"] | |
edition = "2018" | ||
|
||
[dependencies] | ||
ewasm = "0.2.2" | ||
snafu = "0.6.0" | ||
ssz_types = { path = "../utils/ssz_types" } | ||
types = { path = "../types" } | ||
typenum = "1.11.2" | ||
|
||
[dev-dependencies] | ||
hex = "0.4.0" |
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,36 @@ | ||
mod errors; | ||
mod simulation; | ||
mod store; | ||
|
||
use snafu::Snafu; | ||
use std::fmt; | ||
|
||
/// Shorthand for result types returned from the Simulation simulation. | ||
pub type Result<V, E = Error> = std::result::Result<V, E>; | ||
|
||
#[derive(Debug)] | ||
pub enum WhatBound { | ||
ExecutionEnvironment, | ||
ExecutionEnvironmentState, | ||
ShardBlock(usize), | ||
Shard, | ||
} | ||
|
||
impl fmt::Display for WhatBound { | ||
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | ||
match self { | ||
WhatBound::ExecutionEnvironment => write!(f, "execution environment"), | ||
WhatBound::ExecutionEnvironmentState => write!(f, "execution environment state"), | ||
WhatBound::Shard => write!(f, "shard"), | ||
WhatBound::ShardBlock(shard) => write!(f, "block on shard {}", shard), | ||
} | ||
} | ||
} | ||
|
||
/// Errors arising from the simulation. | ||
#[derive(Debug, Snafu)] | ||
pub enum Error { | ||
#[snafu(display("{} exceeds max allowable length", what))] | ||
MaxLengthExceeded { what: String }, | ||
#[snafu(display("no {} exists at index: {}", what, index))] | ||
OutOfBounds { what: WhatBound, index: usize }, | ||
} |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is
MaxLengthExceeded
always triggered from assz_types::Error
?Either way, I'd add a
source
field here, to give more context on the error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, currently
MaxLengthExceeded
is only triggered from assz_types::Error
. However, I could envision it being useful for other types of errors in the future.Though, unless I'm misuderstanding Snafu, I believe that 1) I can only use
context()?;
if I add asource
field (unless I'm calling.context()
on a function returning anOption
), and 2) this error type will ONLY ever be able to be used forssz_types::Error
if I do that approach, which could be OK but if so I'd want to change the name fromMaxLengthExceeded
to something likeSszTypeError
or similar.One last note: my original implementation did use Snafu's canonical
.context(...)?;
pattern, along with asource
field. However,ssz_types::Error
doesn't actually implementstd::error::Error
, which means thatssz_types::Error
can't be used as asource
error. Obviously, I can update thessz_types::Error
type to implementstd:error::Error
, but I opted not to do this immediately, since I anticipate thatssz_types
will eventually be a crate instead of "owned code" in this repo. That said, prior to pushing this as a crate, I'm sure thessz_types
authors would make theError
type compliant with thestd::error::Error
trait.TL;DR: I don't feel too strongly here, as I see it, there are 2 paths forward:
source
field now, which would entail:ssz_types::Error
field to implement thestd:error:Error
traitMaxLengthExceeded
to something likeSszTypeError
, and have the display implementation of the wrapper just show the underlying display implementation of the ssz error (which I would have just added in the first bullet point). This way the error could wrap any of the ssz error types that may come back.Either way works, and #2 is fairly easy to do. #2 has the advantage of the lower-level visibility, and would make it easier to give more info like what the max length was when it was exceeded. #1 is obviously already in use, and has the advantage of in my opinion being simpler and more readable.
My preference is #1 for now unless/until we have a compelling need for #2, but if you or others feel strongly #2 is easy enough to implement.