profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/seanparsons/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

create barnchconcrete-utopia/react-vtree

branch : fix/dist-in-repo

created branch time in 2 days

PullRequestReviewEvent

issue commentconcrete-utopia/utopia

Put limits on browser tests running concurrently

We can manage this (currently) with the jest option --maxWorkers.

maltenuhn

comment created time in 3 days

issue closedconcrete-utopia/utopia

Put limits on browser tests running concurrently

Problem Too many concurrent browser tests can slow down machines because of multiple Electron / Chromium instances

closed time in 3 days

maltenuhn

push eventconcrete-utopia/utopia

Sean Parsons

commit sha be61a035612510d16f3516a27322ddbf33e159d7

fix(canvas) Protect against infinite depth content. (#1840) - Fixes #1590. - Add a condition to `createComponentRendererComponent` to protect against an excessive depth of calls. - Removed the filtering of `App` from the insertable components.

view details

push time in 3 days

delete branch concrete-utopia/utopia

delete branch : fix/protect-against-infinite-depth

delete time in 3 days

PR merged concrete-utopia/utopia

Protect against infinite depth content.

Fixes #1590

Problem: Previously we prevented insertion of an element called App as a heuristic to avoid having an infinite render loop in the canvas if that component ever ended up inside itself. But that only works if it matches that name, which is highly unlikely and a complex project could easily have many components which could induce infinite recursion.

Fix: The original intent of the bug was to improve the filtering, but that becomes an increasingly complicated nest of checks especially once an element in the hierarchy has any kind of conditional rendering or if it gets passed in a prop, which may hide it from introspection.

Instead this thresholds the depth of rendering in the canvas, so that an exception will be thrown to prevent it from running forever or crashing the whole editor, with a message indicating that it was because of an excessive render depth.

Commit Details:

  • Fixes #1590.
  • Add a condition to createComponentRendererComponent to protect against an excessive depth of calls.
  • Removed the filtering of App from the insertable components.
+83 -5

2 comments

5 changed files

seanparsons

pr closed time in 3 days

issue closedconcrete-utopia/utopia

right now App is filtered out from the insert menu based on name. we should be smarter than that

The insert menu should try to not contain elements that can lead to circular render loops.

I think a good heuristic would be to filter out every element that matches the edited component hierarchy.

So if we are editing Card focused inside App, filter out App and Card.

closed time in 3 days

balazsbajorics

Pull request review commentconcrete-utopia/utopia

Protect against infinite depth content.

 export function getComponentGroups(         file.fileContents.parsed,       )       if (possibleExportedComponents != null) {-        const componentsWithoutApp_KILLME = possibleExportedComponents.filter(

Well you could argue the inverse, as it was preventing anything from being inserted if it was called App.

seanparsons

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

PR opened concrete-utopia/utopia

Reviewers
Protect against infinite depth content.

Fixes #1590

Problem: Previously we prevented insertion of an element called App as a heuristic to avoid having an infinite render loop in the canvas if that component ever ended up inside itself. But that only works if it matches that name, which is highly unlikely and a complex project could easily have many components which could induce infinite recursion.

Fix: The original intent of the bug was to improve the filtering, but that becomes an increasingly complicated nest of checks especially once an element in the hierarchy has any kind of conditional rendering or if it gets passed in a prop, which may hide it from introspection.

Instead this thresholds the depth of rendering in the canvas, so that an exception will be thrown to prevent it from running forever or crashing the whole editor, with a message indicating that it was because of an excessive render depth.

Commit Details:

  • Fixes #1590.
  • Add a condition to createComponentRendererComponent to protect against an excessive depth of calls.
  • Removed the filtering of App from the insertable components.
+83 -5

0 comment

5 changed files

pr created time in 3 days

create barnchconcrete-utopia/utopia

branch : fix/protect-against-infinite-depth

created branch time in 3 days

issue closedconcrete-utopia/utopia

VSCode's user state cache can cause issues with our project state

VSCode stores a cache of the user state in the vscode-userdata-store, which includes several keys related to the open project (/User/state/<project_id>.json, /User/workspaceStorage/<project_id>/meta.json, /User/Backups/<project_id>/*), which can clash with our project model when opening a project (leading to an occasional rogue conflict error message about the open file, or even undesired project forking).

We need to ensure that this cache does not overwrite files on load, or trigger saving / forking.

closed time in 6 days

Rheeseyb

issue commentconcrete-utopia/utopia

VSCode's user state cache can cause issues with our project state

I've tried all sorts of combinations of forking, reloading and even disabling updates from VS Code reaching the editor and never once managed to reproduce this.

Rheeseyb

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentconcrete-utopia/utopia

snip the BundlerWorker / ts-worker from the main editor

 const FailJestOnCanvasError = () => {   const stableCallback = React.useCallback((newRuntimeErrors: Array<RuntimeErrorInfo>) => {     // we have new runtime errors, let's take the tests down     if (newRuntimeErrors.length > 0) {+      console.error('Canvas Error!!!!!', newRuntimeErrors[0]?.error)+      fail(newRuntimeErrors[0]?.error)       expect(newRuntimeErrors[0]?.error ?? null).toEqual(null)

Isn't this unreachable?

balazsbajorics

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventconcrete-utopia/utopia

Sean Parsons

commit sha 5c55ca396d9bbaf7ea0c548b61c0f9bbcf96fc24

fix(vscode) Add a ready indicator for VS Code to the editor state. (#1830) - Fixes #1821. - Added `vscodeReady` to `EditorState`. - In `editorDispatch`, don't send any changes to VS Code unless `vscodeReady` is set to `true`. - Have the `SEND_CODE_EDITOR_INITIALISATION` action mark VS Code as ready. - Wire in the `SEND_CODE_EDITOR_INITIALISATION` action, as it wasn't ever previously being fired...

view details

push time in 6 days

delete branch concrete-utopia/utopia

delete branch : fix/vscode-ready-indicator

delete time in 6 days

PR merged concrete-utopia/utopia

Reviewers
Add a ready indicator for VS Code to the editor state.

Fixes #1821

Problem: Updates to the project contents were being sent to VS Code before it had been fully initialised, resulting in errors on creating a new project.

Fix: Added a flag to indicate VS Code has fully initialised so that the editor knows it can send those changes.

Commit Details:

  • Fixes #1821.
  • Added vscodeReady to EditorState.
  • In editorDispatch, don't send any changes to VS Code unless vscodeReady is set to true.
  • Have the SEND_CODE_EDITOR_INITIALISATION action mark VS Code as ready.
  • Wire in the SEND_CODE_EDITOR_INITIALISATION action, as it wasn't ever previously being fired...
+23 -12

1 comment

4 changed files

seanparsons

pr closed time in 6 days

issue closedconcrete-utopia/utopia

Bug: Error sending update to VSCode

STR:

  • Open editor
  • make changes via canvas to any property

Observed: changes are ok in code, but console shows error

image

Analysis:

This is most definitely caused by the early loading of VS Code. Most likely harmless but worth investigating

closed time in 6 days

maltenuhn

PR opened concrete-utopia/utopia

Reviewers
Add a ready indicator for VS Code to the editor state.

Fixes #1821

Problem: Updates to the project contents were being sent to VS Code before it had been fully initialised, resulting in errors on creating a new project.

Fix: Added a flag to indicate VS Code has fully initialised so that the editor knows it can send those changes.

Commit Details:

  • Fixes #1821.
  • Added vscodeReady to EditorState.
  • In editorDispatch, don't send any changes to VS Code unless vscodeReady is set to true.
  • Have the SEND_CODE_EDITOR_INITIALISATION action mark VS Code as ready.
  • Wire in the SEND_CODE_EDITOR_INITIALISATION action, as it wasn't ever previously being fired...
+23 -12

0 comment

4 changed files

pr created time in 7 days