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

Add steppable/interruptible interpreter #79

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

6J7KZg2f
Copy link

This pull is for a variation on Interp; IterativeInterp.

It makes it possible to step through hscript blocks of arbitrary complexity in discrete steps while maintaining variables and so on. There is theoretically no hscript expression that will cause this interpreter to hang.

Use cases include time sharing between multiple scripts, splitting a script over multiple frames, implementing script containing endless loops on single-threaded targets, and debugging scripts by stepping over each expression (nearly) one at a time.

See IterativeREADME.md for usage details.

It's a secret tool we'll use later on.
Add IterativeInterp, a modified version of Interp that can be stepped through execution, preventing infinite loops.
Just using the readme to explain what this fork is.
Forgot about this little thinger...
Should quiet things down a bit
`assign()`  (usually triggered by `EBinop("="...`) was not searching through the stack to find local vars outside of the immediate block's scope. It now does so. 

Also identified a few areas that used the same search method and merged them into a single inlined function, `find_local(id:String):Dynamic`. 

There are only minor differences between `find_local` and `resolve`, and they could potentially be merged with some adjustments to `assign`, `increment`, etc.
@6J7KZg2f
Copy link
Author

6J7KZg2f commented Apr 24, 2019

This in general needs a pretty major code review, if anyone would be keen to give one. There are some cases already where it should fail (array instantiation is something I haven't looked into a great deal yet, for example). The majority of the effort was spent on EFunction/ECall.

It also does not in any way support hscriptPos at this point. I need to get my head around how to work with ExprDefs.

@skial skial mentioned this pull request Apr 24, 2019
1 task
Two codeblocks ending consecutively with no expression in between 
eg
```
if(foo){
    if(bar){
        trace('hello');
    }
    //no expression here would trigger the bug
}
```
Would crash the script. The fetch phase will now, on encountering the end of a block, continue bubbling up through stack frames until it either finds one that will continue or returns a value and ends the script.
Now fully compatible with -DhscriptPos. Internally-generated expressions simply show "Internal" source and zero for all line/position telemetry. 

Fixed a bug where pushing a new frame to the stack wasn't updating locals.
Tools.exprify(e:Expr/ExprDef):Expr is basically the equivalent of Tools.mk for runtime-generated (ie, has no position in source hscript) exprs. It allows hscript.IterativeInterp to be compatible with -DhscriptPos.
@6J7KZg2f
Copy link
Author

6J7KZg2f commented May 7, 2019

With the latest updates, this is now compatible with the hscriptPos flag. There are some situations, however, where PosInfo will become inaccurate at runtime for certain expressions.

Added support for for loop syntax; for loops exist in their own stack frame and can be interrupted as with other loops.

Array declarations now support function calls as members.

Improved PosInfo for internal expressions.
`continue` now works as expected in while, dowhile, and for loops.
@muchitto
Copy link

muchitto commented May 5, 2020

What's the situation with this? I have a use for this kind of thing as I'm currently working around it in a kinda annoyingly hacky way by wrapping expression after they come out of parsing in my own "execution stack closure list" and running those one by one. An interpreter that could be halted/yielded from the outside, would fix this issue. :)

@ncannasse
Copy link
Member

ncannasse commented May 5, 2020 via email

@6J7KZg2f
Copy link
Author

6J7KZg2f commented May 8, 2020

What's the situation with this? I have a use for this kind of thing as I'm currently working around it in a kinda annoyingly hacky way by wrapping expression after they come out of parsing in my own "execution stack closure list" and running those one by one. An interpreter that could be halted/yielded from the outside, would fix this issue. :)

I use it in production for https://talosfray.TV with no issues as far as I can tell, so using it from my fork is an option if you're desperate.

@mundusnine
Copy link

mundusnine commented Aug 18, 2020

I would also have a use for this.

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.

4 participants