positron
positron copied to clipboard
execution of code in quarto cell sometimes works, sometimes does not
Positron Version: 2024.07.0 build 21
Code - OSS Version: 1.90.0 Commit: 82b335e27545e804b7fd806db00477a6eb49951d Date: 2024-07-09T03:06:22.884Z Electron: 29.4.0 Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 6.9.3-76060903-generic R: 4.3.0
Steps to reproduce the issue:
- Create a new quarto document
- Insert a code cell
- Try to evaluate code by line or piped statement
- Only partial evaluation happens
Screencast from 07-09-2024 04:13:08 PM.webm
In this example, I tried to run the code block containing
data(mtcars)
using Ctrl+Enter. But only the data part is called. Another code block, with a library call, seemed to work fine. Also, executing the full block, via Ctrl+Shift+Enter also works (not shown in recording).
I've also had this fail for using cells containing code that spans multiple lines with pipes, and only a single or a couple of lines of the pipe will be executed.
What did you expect to happen?
Expect full code statement to be evaluated.
Were there any error messages in the output or Developer Tools console?
No.
I couldn't reproduce this after typing out the example from the screenshot above.
@rmflight Could you share any other examples, maybe one with the partial pipes?
Sure thing. I also checked the logs, and there is something weird in there.
Better example
---
title: "Untitled"
format: html
---
```{r}
#| label: test-block
data("mtcars")
```
```{r}
#| label: run-ggplot
library(ggplot2)
```
```{r}
#| label: test-piped
mtcars |>
dplyr::filter(mpg > 20) |>
dplyr::summarise(n = dplyr::n())
```
```{r}
#| label: another-piped
mtcars |>
dplyr::filter(mpg < 20) |>
dplyr::summarise(n = dplyr::n())
```
Screencast of today:
Screencast from 07-10-2024 03:28:48 PM.webm
And log output.
You can see that only one line of the pipe is being sent at a time, when I expect the full thing to be sent.
In addition, ark is restarting my R kernel when it tries to access the variables so I can see them in my dplyr call.
Also, I'm running R 4.3.0, in case that matters.
Might this be related to #3792 as well, and something going wrong with the mapping between .qmd and .R?
I'm not sure what has changed from build 21 to build 52, but this issue seems to have gone away as of now.
I installed latest release this morning, and it seems to be behaving properly in my .qmd documents now.
I am still seeing this issue with today's build, no rendering of output within a quarto document
mean(rnorm(10))
hist(rnorm(100))
should look like this from Rstudio
Ah @coreysparks I believe you are expecting to see inline output for a Quarto document, which is not what this issue is about. You can read more about using Quarto in an inline mode (vs. a "send to console" mode) in #1418, #1533, #3718, and #4033.
Positron Version: 2024.08.0 build 24
I keep downloading the new releases to see if this has been fixed yet, and to see if I can figure out where exactly the issue comes from.
I just noticed today, that if I open a project with a quarto document in it, I can pass any lines already written in the document when I opened the project, but if I try and write any new r code blocks, or start a new document, it doesn't work.
Nothing shown in the output log besides R starting up.
I'm seeing this in the logs that @rmflight posted, making me think this is indeed related to #3792
[R] 2024-07-10T19:29:37.116795Z ERROR Requesting line 27 but only 17 lines exist. Document: '#
[R] #
[R] #
[R] #
[R] #
[R] #
[R] #| label: test-block
[R] data("mtcars")
[R] #
[R] #
[R] #
[R] #| label: run-ggplot
[R] library(ggplot2)
[R] #
[R] #
[R] #
[R] '.
[R] at crates/ark/src/lsp/encoding.rs:84
It would be nice if we saw a full traceback in the logs here, so we can determine where exactly this is coming from in ark. (The error is here but I'd like the full call stack https://github.com/posit-dev/ark/blob/5c803695fca80ef5514db0a7224bd008e003898b/crates/ark/src/lsp/encoding.rs#L84)
So one thing we should definitely do is try and either convert this error log to an actual error, or maybe try and force a backtrace capture right here and log it (I think we can do that), and then request that @rmflight reupload logs after triggering it again.
I'm not sure if the Positron Version: 2024.09.0 build 27 has what you wanted @DavisVaughan , or if I'm waiting on another build, but I went ahead an forced the error again.
Logs attached from today.
Thanks, looks like the backtrace itself didn't prove that useful (probably because you are on a release build with some debug symbols stripped out) but this is still useful for us to start playing with
[R] 2024-09-13T18:52:04.611438Z ERROR Requesting line 33 but only 31 lines exist.
[R]
[R] Document:
[R] #
[R] #
[R] #
[R] #
[R] #
[R] #
[R] #| label: test-block
[R] data("mtcars")
[R] #
[R] #
[R] #
[R] #| label: run-ggplot
[R] library(ggplot2)
[R] #
[R] #
[R] #
[R] #| label: test-piped
[R] mtcars |>
[R] dplyr::filter(mpg > 20) |>
[R] dplyr::summarise(n = dplyr::n())
[R] #
[R] #
[R] #
[R] #| label: another-piped
[R] mtcars |>
[R] dplyr::filter(mpg < 20) |>
[R] dplyr::summarise(n = dplyr::n())
[R] #
[R] #
[R] #
[R]
[R]
[R]
[R] at crates/ark/src/lsp/encoding.rs:86
In particular, reverse engineering the qmd...
---
title: "Untitled"
format: html
---
```{r}
#| label: test-block
data("mtcars")
```
```{r}
#| label: run-ggplot
library(ggplot2)
```
```{r}
#| label: test-piped
mtcars |>
dplyr::filter(mpg > 20) |>
dplyr::summarise(n = dplyr::n())
```
```{r}
#| label: another-piped
mtcars |>
dplyr::filter(mpg < 20) |>
dplyr::summarise(n = dplyr::n())
```
I still can't force the panic when playing around with this qmd but maybe someone on the team can
It seems to evaluate pre-existing code blocks OK when I open the file. It's when I add a new code block that it seems to have trouble with.
Also, I have custom snippet for QMD files, that when I hit "r" -> "tab" I get the option to insert a qmd code block. 😉
If someone wanted to email me instructions on getting a non-release version installed (my email is listed on my profile) I could totally do that and see if we can get more output that helps things.
We have a possible fix for you to try out @rmflight if you are willing, which looks like it has helped in #3792. Can you please try:
- Download the artifact from this GH action run: https://github.com/quarto-dev/quarto/actions/runs/11508346112
- Unzip the artifact
- Install the
.vsixin Positron using the command "Extensions: Install from VSIX" - Restart the extension host, as instructed by the button
- See what happens as you try to use Quarto???? 🤞
@juliasilge I think it works! I just went through my normal testing file, adding more and more multiline blocks, and it just works, as I expect it to. And yeah, #3792 sounds suspiciously like almost the same issue, in that whatever is already written seems to work, but creating new blocks is when it decides to crash. I'm still curious why it seems almost impossible for all y'all to reproduce ....
I will attempt to use Positron on another document in an actual analysis project, and see how it goes as well.
Thank you so much for being willing to try it out @rmflight! We would really appreciate it if you could continue to test out this proposed fix. ❤
Just FYI, I was using it last week with no issues, and have continued to use it, and it seems to be working perfectly with no issues. I'm finally enjoying coding in Positron.
We've got another new dev version of the Quarto extension here with a cleaned-up version of the fix, if you would like to again download, unzip, and install the .vsix: https://github.com/quarto-dev/quarto/actions/runs/11581960140
We will do an official release of the Quarto extension with this fix probably before the end of the week.
Since we don't have an internally reproducible way of generating the original problem, I am going to move this issue straight to "Done" (no QA verification). I used the .vsix from main as of now to run through normal Quarto workflows, and all appears to be working well! Thank you again for your feedback and patience. 🙌
I downloaded the new dev version you pointed out, and it also seems to be working.
Thank you so much for believing me on this, and working to create a fix. Very much enjoying Positron now that I can easily work with my Quarto documents!