Re: Bug: :session results in unfriendly error reporting
(all -- just re-sending this with the WOOF header... the original thread is at https://list.orgmode.org/87ee9aquje@gnu.org/T/#t ) Tim, thanks. > It isn't so much that nothing is possible but rather nobody has > implemented a consistent model which can be adopted and has been > implemented by all backends. This is why I consider this to be a > feature request and not a bug report. This is not expected/defined > behaviour which is not behaving according to spec - this is new > unimplemented behaviour, a new feature which needs to be designed and > implemented across all backends. yes, i agree this is really a feature request. in general, as far as i can see, consistency across languages "at the fringes", is pretty much "a work in progress" (or not, as the case might be). if there is ever the chance to detect and propagate errors in :session, that would be great. (and, again "in general", trying to reduce the [reducible] gap between non- and :session, across languages, would be a nice goal.) cheers, Greg
Re: Bug: :session results in unfriendly error reporting
Greg Minshall writes: > yes, i agree this is really a feature request. If you think the feature request is important enough, you can add X-Woof-Help: Please help implementing XXX in your email, the call for help will be listed on updates.orgmode.org HTH, -- Bastien
Re: Bug: :session results in unfriendly error reporting
Tim, thanks. > It isn't so much that nothing is possible but rather nobody has > implemented a consistent model which can be adopted and has been > implemented by all backends. This is why I consider this to be a > feature request and not a bug report. This is not expected/defined > behaviour which is not behaving according to spec - this is new > unimplemented behaviour, a new feature which needs to be designed and > implemented across all backends. yes, i agree this is really a feature request. in general, as far as i can see, consistency across languages "at the fringes", is pretty much "a work in progress" (or not, as the case might be). if there is ever the chance to detect and propagate errors in :session, that would be great. (and, again "in general", trying to reduce the [reducible] gap between non- and :session, across languages, would be a nice goal.) cheers, Greg
Re: Bug: :session results in unfriendly error reporting
Greg Minshall writes: > Charles, > > being sympathetic with the idea of better error reporting, i'm curious > about the following. > >> Right. But there is no error as far as babel is concerned. R has >> handled the condition. So there is nothing for babel to see/do. > ... >> Running R in this fashion starts a fresh process which signals an >> error that babel can handle. I see no easy way to get sessions to >> sends signals that babel can process. > > what is going on here? is the issue that in the no-session case, the R > process exits with a non-zero exit code, and that is how "babel" picks > up on it? > > i put "babel" in quotes ("\"babel\"" :) above, because, in my simple > mind, babel isn't just the main bit that runs inside org/emacs, but also > some glue bits that run in the various languages' environments. things > like initializing variables, and harvesting results. so, might one not > argue that checking execution status, in a session environment, could > also be part of babel? > I think what Charles is talking about is that with a session, the state of the session and what it returns is not necessarily anything to do with what has occured in the code which was executed in the session. Think of the session as a basic REPL. It reads and expression, tries to parse and evaluate it, 'prints' out the result and then waits for the next expression. Whenn you don't have a session, you just have a basic interpreter. It reads the input, parses and tries to execute it and either returns what the successful execution returns or returns some form of error when something goes wrong. It exits while the session doesn't (yet). Dealing with errors in the interpreter case is much easier. Dealing with them in a session is not because the session has not ended and the whole idea of the session is to manage such things and get ready for the next thing. The session only ends once all blocks have been processed. What happens when you add another block at the end of the org file which is to use the same session - it has to still be running or you have to evaluate all the blocks again. Yes, you could add session variables and use them to track error states etc. But that would be something each separate language would have to do and the ability to capture that information for different languages probably varies. It isn't so much that nothing is possible but rather nobody has implemented a consistent model which can be adopted and has been implemented by all backends. This is why I consider this to be a feature request and not a bug report. This is not expected/defined behaviour which is not behaving according to spec - this is new unimplemented behaviour, a new feature which needs to be designed and implemented across all backends. This would be a good feature to have. The work is non-trivial and would take significant time to implement.
Re: Bug: :session results in unfriendly error reporting
Charles, being sympathetic with the idea of better error reporting, i'm curious about the following. > Right. But there is no error as far as babel is concerned. R has > handled the condition. So there is nothing for babel to see/do. ... > Running R in this fashion starts a fresh process which signals an > error that babel can handle. I see no easy way to get sessions to > sends signals that babel can process. what is going on here? is the issue that in the no-session case, the R process exits with a non-zero exit code, and that is how "babel" picks up on it? i put "babel" in quotes ("\"babel\"" :) above, because, in my simple mind, babel isn't just the main bit that runs inside org/emacs, but also some glue bits that run in the various languages' environments. things like initializing variables, and harvesting results. so, might one not argue that checking execution status, in a session environment, could also be part of babel? cheers, Greg
Re: Bug: :session results in unfriendly error reporting
James, > On Aug 15, 2021, at 4:41 PM, James Powell wrote: > > I write a deliberate syntax error into a code block: > > : #+begin_src R :session > : x <- 1 > : y xx z > : #+end_src > > I put my cursor in there and C-c C-c. > > What I expect: a gentle useful report about the error. Right. But there is no error as far as babel is concerned. R has handled the condition. So there is nothing for babel to see/do. > Maybe even org would move the cursor to the point of the > error in the org buffer. If not, at least the buffer > "*Org-Babel Error Output*" will open and show me the error, > something like this (see also [1]), > > : Error: unexpected symbol in: > : "x <- 1 > : y xx" > : -UUU:@**--F2 *Org-Babel Error Output* All L17(Compilation etu) > 4:13PM 0.53 Mail --$ > `:results output' might help you here, since it will send the terminal output back to babel. If that doesn't suffice, you might use handlers provided by R to find your way out. But I think that will get sticky as what you create in your example is a parse error. If the source blocks are eval'ed as part of an export, you have the option of exporting via ox-ravel[*] and using the knitr chunk options to handle errors in the way you want. > What happens instead: > > - the *R* buffer is displayed. It contains a long spammy traceback > that has run off of the top of the screen. To learn more I have to > move the cursor into the *R* buffer and page back to the top of the > traceback. > > On the other hand, if I set ":session none", I get much friendlier > behavior. The Error Output buffer opens with the simple error message > in it as I showed above when I use this source block: > > : #+begin_src R :session none > : x <- 1 > : y xx z > : #+end_src > Running R in this fashion starts a fresh process which signals an error that babel can handle. I see no easy way to get sessions to sends signals that babel can process. > I do not want to abandon :session because my code reads in a lot of > data to get started and I want my scripts, not my environment to be > "real" so I am not depending on R's ability to save and reload the > workspace at all [2] or on "Org's (clever and useful but) somewhat clunky > and inflexible method of passing data explicitly" [3]. One of the motivating factors for creating ox-ravel[*] was to have flexible caching of R objects. This is provided in knitr, Sweave, and similar report generators. For interactive use, knit-ing a document that has caching enabled at the start of a session is a fast and painless way to get all the objects needed to modify a document. HRH, Chuck [*] https://github.com/chasberry/orgmode-accessories > > Is there a way to get back to the "Error Output" buffer opening with a > simple message /while/ having :session being enabled? > > thank you, > James P. > > References > > [1] "Currently the only action Babel takes with STDERR is to display it in a > pop-up buffer when code block evaluation fails" (Eric Schulte in 2012, at > https://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg00057.html). > > [2] « what will you save as your lasting record of what happened? > [...[ As a beginning R user, it's OK to consider your environment > [...] "real." However, in the long run, you'll be much better off > if you consider your R scripts as "real." » (p. 111, Wickham, H. "R > for data science : import, tidy, transform, visualize, and model > data" O'Reilly Media, 2016). To facilitate this, I have disabled > 'save workspace' permanently: > : q <- function (save = "no", status = 0, runLast = TRUE) > : .Internal(quit(save, status, runLast)) > > [3] «When I look at Org and think of "session-based" blocks, I see a > potential big benefit in having multiple source-blocks throughout > my document share the same session» > (https://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00654.html, > the only good hit for a search for "session Org-Babel Error Output" at > https://lists.gnu.org/archive/html/emacs-orgmode/ as of > [2021-08-15 Sun]). > > > -- > James E. Powell, MS > Pronouns: he/him/his > Applied Physics PhD Candidate > Department of Physics > Portland State University > Home page: http://web.pdx.edu/~powellj > Office: SRTC 409B Phone: +1-503-725-8515 > > >
Bug: :session results in unfriendly error reporting
I write a deliberate syntax error into a code block: : #+begin_src R :session : x <- 1 : y xx z : #+end_src I put my cursor in there and C-c C-c. What I expect: a gentle useful report about the error. Maybe even org would move the cursor to the point of the error in the org buffer. If not, at least the buffer "*Org-Babel Error Output*" will open and show me the error, something like this (see also [1]), : Error: unexpected symbol in: : "x <- 1 : y xx" : -UUU:@**--F2 *Org-Babel Error Output* All L17 (Compilation etu) 4:13PM 0.53 Mail --$ What happens instead: - the *R* buffer is displayed. It contains a long spammy traceback that has run off of the top of the screen. To learn more I have to move the cursor into the *R* buffer and page back to the top of the traceback. On the other hand, if I set ":session none", I get much friendlier behavior. The Error Output buffer opens with the simple error message in it as I showed above when I use this source block: : #+begin_src R :session none : x <- 1 : y xx z : #+end_src I do not want to abandon :session because my code reads in a lot of data to get started and I want my scripts, not my environment to be "real" so I am not depending on R's ability to save and reload the workspace at all [2] or on "Org's (clever and useful but) somewhat clunky and inflexible method of passing data explicitly" [3]. Is there a way to get back to the "Error Output" buffer opening with a simple message /while/ having :session being enabled? thank you, James P. References [1] "Currently the only action Babel takes with STDERR is to display it in a pop-up buffer when code block evaluation fails" (Eric Schulte in 2012, at https://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg00057.html). [2] « what will you save as your lasting record of what happened? [...[ As a beginning R user, it's OK to consider your environment [...] "real." However, in the long run, you'll be much better off if you consider your R scripts as "real." » (p. 111, Wickham, H. "R for data science : import, tidy, transform, visualize, and model data" O'Reilly Media, 2016). To facilitate this, I have disabled 'save workspace' permanently: : q <- function (save = "no", status = 0, runLast = TRUE) : .Internal(quit(save, status, runLast)) [3] «When I look at Org and think of "session-based" blocks, I see a potential big benefit in having multiple source-blocks throughout my document share the same session» (https://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00654.html, the only good hit for a search for "session Org-Babel Error Output" at https://lists.gnu.org/archive/html/emacs-orgmode/ as of [2021-08-15 Sun]). -- James E. Powell, MS Pronouns: he/him/his Applied Physics PhD Candidate Department of Physics Portland State University Home page: http://web.pdx.edu/~powellj Office: SRTC 409B Phone: +1-503-725-8515