Interactive eval #1351
Merged
Interactive eval #1351
Conversation
This file contains hidden or 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
3dbc461 to
c83de10
Compare
35b0c19 to
f3610da
Compare
f3610da to
95e2d03
Compare
Will allow other uses and extra constructors. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
This is unused for now. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Signed-off-by: George Thomas <georgefsthomas@gmail.com>
…ions Signed-off-by: George Thomas <georgefsthomas@gmail.com>
IDs should be unique within a page, so it's best to be careful to avoid clashes. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
This is a proof-of-concept, with UI choices being driven largely by implementation simplicity. One quirk is that we can't change eval opts on the fly during interactive evaluation, because this resets the evaluation state completely, i.e. it takes the history back to a singleton list. This is because we also want full (i.e. non-interactive) eval to be in sync with the opts. Note that we no longer show the timeout error, since we now consider timing out to be fine and normal, as interaction can be continued interactively. Besides, it's obvious whether an expression has finished eval, by whether there are redexes highlighted (at least for small expressions), and anyway, the old `"No selection for eval"` message was never actually shown, since we mistakenly didn't show the `error` field when `expr` was `Nothing`. We still show `"No definition selected for evaluation"`, so nothing has been lost with this change. For similar reasons, we set `stepLimit = 0`, instead of the arbitrary `stepLimit = 10`, which is also consistent with using `False` for checkboxes, in terms of initial state being reflected in the UI. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
95e2d03 to
9362c2e
Compare
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.
As mentioned in the last commit message, this is still kind of proof-of-concept, but it works rather well.
And even with less-than-perfect UX, it feels great to be able to explore eval steps again, seeing as we never got this far with the JS frontend. This brings back a key Primer feature which we effectively haven't had for three and a half years!