Prerelease/2025.01 #6065
Closed
Prerelease/2025.01 #6065
Conversation
This file contains 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
…into duckdb (#5890) Addresses #5860. duckdb-wasm has some kind of file caching behavior that is not resilient to file changes on the underlying file system. This patch nukes this issue from orbit by always registering the file contents as a virtual file and reading from that. I think if and when we migrate to the duckdb NodeJS bindings per #5889 that we can avoid this chicanery. This does the same thing for Parquet files, too, since they would also become stale. e2e: @:data-explorer ### QA Notes Here was the reproducible failure from the issue: * Run iris |> readr::write_csv("test.csv") * Click on the file in the File Explorer to open it up; note that we correctly see the iris data * Run mtcars |> readr::write_csv("test.csv") * Again click on the file in the File Explorer to open it up; note that we incorrectly still see the iris data
### Description Addresses #5718 The web build of Positron was showing the "No interpreters found" dialog to users even if an interpreter was found. This bug is only present on the web build because there are two extension hosts for the web build. VS Code has a 'web extension host' that runs installed extensions in the browser. Thus the Positron web build has this additional 'web extension host'. For our case, the 'web extension host' will never find any interpreters during the runtime startup process. When the 'web extension host' completes discovery before the extension host does, our list of registered runtimes will be empty which causes the "No interpreters found" dialog to be shown. The runtime startup service needs to know about the existence of all extension hosts and wait for all of the extension hosts to complete their own language runtime discovery. ### Release Notes #### New Features - N/A #### Bug Fixes - The web build of Positron no longer shows the "No interpreters found" dialog when interpreters are found. The runtime startup process now waits for all extension hosts to complete runtime discovery. ### QA Notes - [ ] Verify the "No interpreters found" dialog is not shown when there are interpreters. - [ ] Verify the "No interpreters found" dialog is shown only ONCE when there aren't any interpreters. - The following scenarios cover when the dialog can be shown: - There are no Python/R installations at all - There are only outdated versions of Python/R installed which we do not support, e.g. only having R 4.1 installed on the machine (we currently support 4.2+) - The Python/R installations are in hidden locations that Positron does not check ### Screenshots **Web Build - No Interpreters** https://github.com/user-attachments/assets/5247d580-5eb7-44d5-8b75-1ff7b1f29565 **Web Build - Interpreters Found** https://github.com/user-attachments/assets/adaa925b-5b0b-4f2e-bd7b-2690853138af
This PR updates the 2025.01 release with changes from the 1.96 version of Code OSS. --------- Co-authored-by: positron-bot[bot] <173392469+positron-bot[bot]@users.noreply.github.com> Co-authored-by: sharon wang <[email protected]>
This change addresses an app boot failure on Windows, which was due to (surprise) path separators. Positron recently added a patch to work around an issue in which the file content mapper that concatenates startup scripts was being passed Windows-style path separators instead of Unix-style path separators. It appears that in 1.96 this patch isn't necessary any more as the arguments to this function are once again arriving Unix-normalized, so the fix here is just to wholly revert our patch so that this behavior matches upstream.
Upstream `main` was missing a few changes that are needed for the Workbench patch, see PR: rstudio/vscode-server#162 - address Snyk vulnerabilities in micromatch and dompurify - use correct table name when saving state to Workbench - update extension host agent server to send first heartbeat on startup in Workbench - bump workbench extension ### Release Notes <!-- Optionally, replace `N/A` with text to be included in the next release notes. The `N/A` bullets are ignored. If you refer to one or more Positron issues, these issues are used to collect information about the feature or bugfix, such as the relevant language pack as determined by Github labels of type `lang: `. The note will automatically be tagged with the language. These notes are typically filled by the Positron team. If you are an external contributor, you may ignore this section. --> #### New Features - N/A #### Bug Fixes - N/A ### QA Notes <!-- Add additional information for QA on how to validate the change, paying special attention to the level of risk, adjacent areas that could be affected by the change, and any important contextual information not present in the linked issues. --> --------- Co-authored-by: petetronic <[email protected]> Co-authored-by: Jonathan McPherson <[email protected]>
This change addresses an issue in which Positron Server doesn't start
due to an error like this one:
```
(node:11206) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/home/ubuntu/vscode-reh-web-linux-x64/out/server-main.js:26
export function __extends(d, b) {
^^^^^^
SyntaxError: Unexpected token 'export'
at wrapSafe (node:internal/modules/cjs/loader:1378:20)
at Module._compile
```
The problem was caused by an incompletely merged line in the initial
1.95 merge, which caused a cascade of silent failures that led to
`package.json` being omitted from the `reh-web` bundle, which led to the
above failure since `package.json` was responsible for setting `"type":
"module"` as noted above. The fix is just to update the line to match
what it was before the merge:
https://github.com/posit-dev/positron/blob/fa567b23598d7f91eab1f2aa182ae8b1e8b50099/build/gulpfile.reh.js#L378-L383
Addresses, coincidentally,
#5775, which is where this
error was first spotted.
After the change, it ought to be possible to run `./positron-server`
without error. E.g.:
```
./positron-server --version
Positron: 2025.01.1 build 4
Positron SHA: 9f520e6
Code OSS: 1.96.0
Arch: arm64
```
- addresses rstudio/rstudio-pro#7306 - adds help.html and external ESM modules to the reh-web build ### Release Notes #### New Features - N/A #### Bug Fixes - Fix issue preventing Positron from loading in Posit Workbench ### QA Notes These files should no longer be missing, so Positron should now load in Workbench. <img width="236" alt="image" src="https://github.com/user-attachments/assets/2142d440-58cb-4149-86fa-81b19b9da138" /> I also noticed that help.html was missing, which was preventing the Help Pane from working. Opening Help for R and Python from a Console should now work: R Console ```r ?iris ``` Python Console ```python ?print ``` --------- Co-authored-by: sharon wang <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Release Notes
New Features
Bug Fixes
QA Notes