Bug: :session results in unfriendly error reporting

Bug: :session results in unfriendly error reporting

[James Powell]

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

Re: Bug: :session results in unfriendly error reporting

[Berry, Charles via General discussions about Org-mode.]

James,

> On Aug 15, 2021, at 4:41 PM, James Powell <powellj@pdx.edu> 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
> 
> 
> 

Re: Bug: :session results in unfriendly error reporting

[Greg Minshall]

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

[Tim Cross]

Greg Minshall <minshall@umich.edu> 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

[Greg Minshall]

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

[Bastien]

Greg Minshall <minshall@umich.edu> 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

[Greg Minshall]

(all -- just re-sending this with the WOOF header... the original thread
is at https://list.orgmode.org/87ee9aquje.fsf@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