Re: We have asynchronous sessions, why have anything else?

[Ivar Fredholm]

Hi, Ihor,
I believe the two could be unified if we expand the functionality of the async 
filter to look for 'exception' tags. Then each language implementation must 
only put the org-babel src block in a try-except type construction and put the 
error message into the except block. The async filter will then find the error 
information and report it back to the org-buffer. We could then emulate the 
synchronous session functionality by adding a filter to the async-filter which 
blocks until an 'end' or 'exception' tag is detected. This way, all four 
combinations of session/session-less and synchronous/asynchronous header 
arguments could be handled by the asynchronous code alone.
Best, Guacho




Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, June 25th, 2022 at 10:28 PM, Ihor Radchenko <yantar92@gmail.com> 
wrote:


> Ivar Fredholm freddyholms@protonmail.com writes:
>
> > A session-less block can be executed by starting a session with a special 
> > name (say "*none") which always gets killed after block execution is 
> > completed. For interpreter-less languages, we could use the shell as an 
> > interpreter (for instance, if we wanted to execute C, we could just start a 
> > shell, and send it the gcc command to compile and execute). Would this not 
> > cut down the amount of code that needs to be maintained and uniformize the 
> > existing code?
>
>
> Feel free to compare ob-eval.el and ob-comint.el. Their functionality is
> not equivalent. In particular ob-eval.el has a better handling of
> errors.
>
> If you find a way to unify the two without loosing the functionality, it
> will be welcome.
>
> Best,
> Ihor