Changes.rst for 0.17.0 #842
Closed
Conversation
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
They're all part of the KOSNameTagWindow so I changed them all in one go.
When I examined it, I saw that this is how it's
meant to work in normal cases:
There are two instruction pointers - one for where
you are in the interpreter context and another for
where you are in the program context.
When you run a program, it does this:
1. Interpreter context has an OpcodeCall that calls built-in function run().
2. Function run() tells CPU it should switch to program context on the
next instruction.
3. Function run() calls compiler, and populates the CPU's program context
with the resulting program.
4. Function run() finishes.
5. CPU, like it does for all opcode executions, updates the instruction
pointer of the current context to the next opcode.
6. CPU finishes loop iteration, and begins new loop.
7. CPU now is in the new program context, and is running the program.
8. When program finishes or errors out, CPU returns to interpreter context and picks up where it left the instruction pointer for the interpreter.
The problem is when step 3 barfs and throws an exception, the CPU was
*already* told in step 2 that it is no longer going to be in interpreter
context, so when it handles the error it's handling it as if it had come
from a program instead of from the interpreter, and thus is does NOT advance
the interpreter's instruction pointer, thinking that had already been
done before in step 5 of the previous iteration just before it had
jumped into the "program" it thought it was running.
Thus the interpreter tries to run the same Opcode a second time, and gets
the new error because the stack was already popped in the first attempt
to call the run() function. The second time it tries to call run(), the
args it needs aren't there on the stack anymore, thus the null ref error.
The fix was to detect when the compiler failed in step 3, and when it did,
to undo the "you are now in program context" setup it did in step 2, so
the CPU knows it's still in interpreter context and it does therefore need
to advance the interpreter's instruction pointer.
Update bindings.rst
Set sasmode documentation - issue KSP-KOS#837
…o docs_link_for_examples
| Kerbal Alarm Clock support | ||
| :::::::::::::::::::::::::: | ||
|
|
||
| If you have the Kerbal Alarm Clock Mod isntalled, you can now |
There was a problem hiding this comment.
thanks. edited in my branch. thankfully it wasn't pulled yet.
|
All these changes are ALREADY in develop!! But github is showing the diffs all wrong claiming they're not. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I read through this long list:
#716
and tried to extract all the things that were new features rather than bugs, and point to their locations in the documentation:
The relevant change is the file doc/source/changes.rst