Summarize a model from an already-parsed structure - #29
Merged
Merged
Conversation
A host opening a model parses it twice. It runs parseModel itself to build the
model's rows, and summarizeFiles runs parseModel again over the same bytes to
build the usage summary — a second full parse per model open, spent to produce
nothing the caller was not already holding.
summarizeParsedModel takes the parse instead of the bytes. It is the model
branch of summarizeFiles with the parse lifted out: it reuses modelSummary, and
summarizeFiles' own model branch now goes through it, so the two ways to
summarise a model are one implementation rather than two that agree today.
It answers with a whole FileSummaries holding just that one model, not a bare
ModelSummary, so it is exactly what summarizeFiles([{srcId, filename, bytes}])
returns for a model and mergeFileSummaries folds it in beside the dictionaries
and MAT-files a host only ever reads as bytes.
Purely additive: no existing signature or behaviour changes. What the tests pin
is the equality BETWEEN the two paths, per model fixture — block parameters, a
real model workspace, mask workspaces, file links with no blocks, and a model
that parses and defines nothing, where both paths owe the same empty-ish summary
rather than a throw. Bytes the parser refuses have no parsed path at all: the
caller's own parseModel threw and has nothing to hand over, which is the one case
the two cannot be compared and is pinned as such.
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
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.
A host opening a model parses it twice: once itself, to build the model rows, and once inside
summarizeFiles, to build the usage summary over the same bytes. The second parse produces nothing the caller was not already holding.summarizeParsedModeltakes the parse instead of the bytes. It is the model branch ofsummarizeFileswith the parse lifted out, andsummarizeFiles' own model branch now routes through it — so the two ways to summarize a model are one implementation rather than two that happen to agree.It answers with a whole
FileSummariesholding just that one model rather than a bareModelSummary, so it is exactly whatsummarizeFiles([{srcId, filename, bytes}])returns for a model, andmergeFileSummariesfolds it in beside the dictionaries and MAT-files a host only ever reads as bytes.Purely additive — no existing signature or behaviour changes. The tests pin the equality BETWEEN the two paths per model fixture: block parameters, a real model workspace, mask workspaces, file links with no blocks, and a model that parses and defines nothing (where both paths owe the same empty-ish summary rather than a throw). Bytes the parser refuses have no parsed path at all — the caller's own
parseModelthrew and has nothing to hand over — and that is pinned as the one case the two cannot be compared.Version bumped to 1.20.0 on the branch so the release tag can match, per the pattern in 684e36c.
Consumer:
data-explorer-vscode's shared-source-cache work, which calls this to build the Usage graph from the parse it already has.