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
bugfix: keep evaluated worksheets synced with dependencies in presentation compiler #5248
bugfix: keep evaluated worksheets synced with dependencies in presentation compiler #5248
Conversation
2ca0152
to
0aed575
Compare
worksheetsDigests
synced with dependencies in presentation compilerworksheets
synced with dependencies in presentation compiler
worksheets
synced with dependencies in presentation compilerworksheetsDigests
synced with dependencies in presentation compiler
worksheetsDigests
synced with dependencies in presentation compilerThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a great catch! The fix is quite clever, but I wonder if we could try to reduce the coupling
sourceDeps.filter(_.toString().endsWith("-sources.jar")), | ||
) | ||
} | ||
maybeRestartWorksheetPresentationCompiler(path, evaluatedWorksheet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if instead of getting evaluatedWorksheet
we could save the dependency sources together in the Compilers class? This would avoid the bidirectional flow between the two classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree, the bidirectional flow is terrible here. So when we cancel and clear, we don't clean those saved dependencies? I was just a bit worried that it's a bit counterintuitive to leftover something after cancel. But it's still probably better then what we have now.
The other possibility I was considering was so that WorksheetProvider
wouldn't create the pc
but Compilers
would create a new one for the worksheet if the digest went out of sync between WorksheetProvider
and Compilers
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just a bit worried that it's a bit counterintuitive to leftover something after cancel. But it's still probably better then what we have now.
That's basically a target data (classpath etc.), which we also reuse after restarting, so that's fine.
The other possibility I was considering was so that WorksheetProvider wouldn't create the pc but Compilers would create a new one for the worksheet if the digest went out of sync between WorksheetProvider and Compilers.
If we keep the digest in the Compilers, we should be fine? MAybe in something like WorksheetData
that would contain both digest and source jars? And anything more needed to start the presentation compiler?
We would update it and maybe restart the compiler in case of change deps?
0aed575
to
c2ca6da
Compare
c2ca6da
to
990a403
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Previously:
If compilers were reloaded (e.g. when doing
import build
)worksheetsDigests
would fall out of sync with dependencies in the presentation compiler.Now:
worksheetsDigests
to compilers so it's reset with presentation compilers too.pc
s, so if there is nopc
forworksheet
we askWorksheetProvider
to produce one if it has this worksheet evaluated incache
.should fix: #5199