Debugger. #28441
Debugger. #28441
Conversation
interpreter/src/cursor.rs
Outdated
| integers::Integer as SvmIntegerParam, | ||
| }; | ||
|
|
||
| type SvmAddress = SvmAddressParam<TestnetV0>; |
There was a problem hiding this comment.
Do we want these types parameterized over the Network?
There was a problem hiding this comment.
At the moment the interpreter only works with TestnetV0. It's not clear to me whether it's important that it works with the other Networks. What do you think?
There was a problem hiding this comment.
We just rolled some updates where TestnetV0 and MainnetV0 can differ in behavior depending on the block height. I could see that as being a potential case, but not much else.
interpreter/src/cursor.rs
Outdated
| } | ||
|
|
||
| #[derive(Clone, Debug, Default, Eq, PartialEq, Hash)] | ||
| pub struct Future(pub Vec<AsyncExecution>); |
There was a problem hiding this comment.
That way I've been thinking about Futures is that they are a single AsyncExecution, whose arguments can be other AsyncExecutions. I'm sure I'll understand as I make it further down, but is there a reason why it's a vec here?
There was a problem hiding this comment.
What I have is that a Future is a sequence of AsyncExecutions, and when an async function calls await, it collects that Future's AsyncExecutions into its Future, which it will return when it finishes executing.
It's not clear to me that there is any advantage in having a tree of executions as opposed to just a sequence. Is there?
|
We should be also allow the debugger to start in a non-Leo context. |
|
It would be nice for the cursor for the REPL loop to show where we are currently at |
mikebenfield
force-pushed
the
interpreter
branch
from
0a68aa4 to
b2f7fd7
Compare
mikebenfield
force-pushed
the
interpreter
branch
3 times, most recently
from
31b030c to
e34d782
Compare
mikebenfield
force-pushed
the
interpreter
branch
from
e8f93b2 to
28b9324
Compare
No description provided.