System details:

Positron Version: 2024.09.0 (Universal) build 27

Code - OSS Version: 1.92.0
Commit: d996153
Date: 2024-09-11T02:38:46.408Z
Electron: 30.1.2
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.5.0

Interpreter details:

R 4.4

Describe the issue:

Copied from: #4658 (comment) via @brndngrhm

I often use View() at the end of dplyr chains to quickly check my logic before assigning the output to an object.

In Positron, I'm finding that once i execute a 2nd View() command, the first one is no longer viewable (see below). I am used to being lazy and just comparing outputs across multiple View() statements without having to assign to objects, which i am able to do in R Studio but not in Positron.

Is this capability something that can be added to Positron?

Steps to reproduce the issue:

library(tidyverse)

# View 1 - executing this opens the data pane showing mtcars (screenshot 1)
mtcars %>% View()

# View 2 - executing this opens a new data pane showing summarized mtcars  (screenshot 2)
#        - trying to go back to the first data pane results in a message: object no longer available (screenshot 3)
mtcars %>% 
  group_by(mpg) %>% 
  tally() %>% 
  View()

Expected or desired behavior:

comparing outputs across multiple View() statements without having to assign to objects, which i am able to do in R Studio but not in Positron.

Were there any error messages in the UI, Output panel, or Developer Tools console?

Per @jmcphers this is expected.

I think it's "sort of" intended. RStudio's data viewer makes a copy of everything you give it, so data viewer tabs can keep working if you remove the original copy. Positron's data viewer doesn't ever make copies; it only runs against the original object. A simpler repo case:

mt <- mtcars
View(mt)
rm(mt)

In Positron this will result in your data viewer immediately going offline with the "object is no longer available" message, whereas in RStudio you can keep using the viewer.

Choosing to serve all requests from the original data (vs making a cached copy) was an intentional design decision that was made with the goal of keeping memory use under control (especially for big objects). But we could walk it back or fine tune it, especially for R (where copy-on-write can make most copies zero/low cost) and when the data is small.