-
Notifications
You must be signed in to change notification settings - Fork 103
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
base: master
Are you sure you want to change the base?
Conversation
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.
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.
|
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.
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.
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. :) |
That's interesting, but I have not much time to review it atm.
Le mar. 5 mai 2020 à 13:32, muchitto <[email protected]> a écrit :
… 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. :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHZXQA5OERTD45AKTDMYUDRP72NLANCNFSM4HIASISA>
.
|
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. |
I would also have a use for this. |
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.