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

Set output evaluation context for a single node #8440

Merged
merged 44 commits into from
Dec 15, 2023
Merged

Conversation

somebody1234
Copy link
Contributor

@somebody1234 somebody1234 commented Dec 1, 2023

Pull Request Description

Important Notes

None

Screenshots

image
image

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

…mplementation for AST replacement

Untested

The matched segments also need to be hidden to, but we need to make sure that the propagated content edits have the correct offset.
@somebody1234 somebody1234 added CI: No changelog needed Do not require a changelog entry for this PR. x-new-feature Type: new feature request -gui labels Dec 1, 2023
@somebody1234 somebody1234 marked this pull request as ready for review December 4, 2023 10:19
@vitvakatu
Copy link
Contributor

A little issue in logic:

Kapture.2023-12-05.at.13.07.29.mp4

When using the button near the node, context switch expressions should never stack; instead, we should replace the existing expression with the correct one. Having a “no-op” expression, like enabling output context in the “live” environment is totally okay, and should be considered as no context switch expression present on a node.

@somebody1234
Copy link
Contributor Author

@vitvakatu Hmm... that would mean you can't have different overrides for different environments, right?

@vitvakatu
Copy link
Contributor

@vitvakatu Hmm... that would mean you can't have different overrides for different environments, right?

Yes, this is how the old GUI is implemented. We can confirm with @jdunkerley to make sure. I tried to find the actual discussion around this behavior but failed (there were a lot of drastic changes to the design).

I’m sure that any operation on button shouldn’t cause the change in the visible node’s expression.

@somebody1234
Copy link
Contributor Author

I’m sure that any operation on button shouldn’t cause the change in the visible node’s expression.

@vitvakatu note that there are alternatives that still preserve this behavior - I think ideally we would recursively hide all context overrides, but only modify the override for the current context (or add one, if none are for the current context)

@somebody1234
Copy link
Contributor Author

@Frizi thoughts on using widgets for this instead? i think it'd be a cleaner (+ more generic?) solution, but the issue is that we have to communicate the "is node overridden" data all the way up the tree back to the GraphNode (or via an inject) - which is doable, but doesn't exist yet

Copy link
Contributor

@farmaazon farmaazon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any chance for output context overwriting tests? They could be E2E tests if UT would be hard, and they can be done in a separate PR.

app/gui2/src/components/GraphEditor/GraphNode.vue Outdated Show resolved Hide resolved
app/gui2/src/components/GraphEditor/GraphNode.vue Outdated Show resolved Hide resolved
app/gui2/src/components/GraphEditor/GraphNode.vue Outdated Show resolved Hide resolved
app/gui2/src/util/ast/string.ts Outdated Show resolved Hide resolved
@somebody1234
Copy link
Contributor Author

i'll see what i can do for UT

Warnings about `onScopeDispose` being called outside an effect scope

Errors caused by unhandled promise rejections
@somebody1234
Copy link
Contributor Author

Re-requesting review from @farmaazon for feedback on UT: Implementation

@somebody1234
Copy link
Contributor Author

i think the new approach is a huge bandaid. but for now it works, and hopefully most of the jank can be removed once we get real AST edits?

@somebody1234
Copy link
Contributor Author

oh yeah, one minor (okay, major) issue: for now at least, i've made the new AST types public, because i need to read and mutate them outside of abstract.ts

@somebody1234
Copy link
Contributor Author

requesting review from @kazcw because of ast-related changes... maybe this task should be delayed until we have edits?

Copy link
Contributor

@kazcw kazcw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will need to make some changes to the AST-editing support here to fit my planned direction for the APIs, but I think it's OK to merge; I can update it in-tree in my next PR.

return mockNode()
}

export function waitForMainModule(projectStore?: ProjectStore) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find any usages of this function. Can it be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was required previously when I used component tests for GraphNode

import { Rect } from '../src/util/rect'
import { Vec2 } from '../src/util/vec2'

export const graphNavigator: GraphNavigator = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this have to be mocked? I feel like no providers should need any mocking, except for things related to network requests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

previously we had component tests for GraphNode... I guess the correct solution is maybe to use a wrapper component then?

but also, we're no longer doing component tests so it's not like these are currently used either.


// It is currently not feasible to use generics here, as the type of the component's emits
// is not exposed.
export function handleEmit(wrapper: VueWrapper<any>, event: string, fn: (...args: any[]) => void) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this used anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above, previously used for component tests. i figured it's fine to keep it if we may want to do component testing in the future, but i have no problems with removing all unused code because we are probably not planning to do that anytime soon anyway.

placeholder,
)
if (replacements.length !== 0) {
// throw new Error(`${replacements.length} unused replacements.`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this error commented out unintentionally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no - nice catch, thanks, will fix.

@somebody1234
Copy link
Contributor Author

somebody1234 commented Dec 8, 2023

For posterity: the additional logs added on errors were added because Vitest was throwing "unhandled exception" errors .

Note also that the fix that worked there, was to add mocks for the LS and data server.

@kazcw kazcw added the CI: Clean build required CI runners will be cleaned before and after this PR is built. label Dec 13, 2023
@somebody1234 somebody1234 added CI: Ready to merge This PR is eligible for automatic merge and removed CI: Clean build required CI runners will be cleaned before and after this PR is built. labels Dec 15, 2023
@mergify mergify bot merged commit 927df16 into develop Dec 15, 2023
33 of 35 checks passed
@mergify mergify bot deleted the wip/sb/set-eval-ctx branch December 15, 2023 10:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-gui CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge x-new-feature Type: new feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Setting evaluation context on a single node.
5 participants