emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: :session results in unfriendly error reporting


From: Tim Cross
Subject: Re: Bug: :session results in unfriendly error reporting
Date: Tue, 17 Aug 2021 16:23:48 +1000
User-agent: mu4e 1.6.3; emacs 28.0.50

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]