emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Ivar Fredholm <freddyholms@protonmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Using exec functions to simplify session code
Date: Fri, 24 Jun 2022 01:31:28 +0000	[thread overview]
Message-ID: <4GgreROUkMant3E8LK7kKgeciZbHZDaEywwaKsZk34klCmvBr9paFe9ay4YziC80ubNd7mqwbbETwbjv6Q9EIs_3M1mM_Mv3H9cHOOyVr1I=@protonmail.com> (raw)
In-Reply-To: <87tu8a7txl.fsf@gmail.com>

Hi, Tim,
Let's say in your example that we are executing Python cells with the same session. When you execute block 1, the routines in org-babel-execute-src-block process the code into something that can be inserted into a file (say 'tmp_code.py') and be run from the command line with python3 tmp_code.py.

At this point, Babel calls org-babel-execute:python, which decides, based on the 'session' header, whether or not to call python3 tmp_code.py or to feed each line in tmp_code.py into the session interpreter. What I am wondering is if we could replace the code for the latter option (in ob-comint.el) by just sending the interpreter the command 'exec(open("tmp_code.py").read())'.

Now you can still run block 2 or 3, or block 2 twice, or neither. I think this would simplify a lot of the comint code. All we would need to do is change how we implement the 'exec(open...' code in other languages, for instance, I believe in julia this could be done by an 'include'.

Best, Guacho





Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, June 23rd, 2022 at 7:53 PM, Tim Cross <theophilusx@gmail.com> wrote:


> Ivar Fredholm freddyholms@protonmail.com writes:
>
> > I have been browsing the orgmode code and it feels like we have to do a lot to implement sessions. At least for Python
> > or Julia, I am wondering if we could instantiate an interpreter, and send the code as a single 'exec' or 'include'
> > command. Other languages like R and groovy also have facilities to run code from a file. I believe this would reduce the
> > amount of code needing maintenance, as we would only need to manipulate the string to pass to the interpreter based
> > on the language. If this has been considered before, could someone explain why this approach was not used?
> > Best, Guacho
>
>
> I agree that supporting session can be complex, especially with some
> languages. The big limitation I can see with your suggestion (assuming I
> understand what your proposing) is that you may not necessarily want to
> execute all the blocks at once or only execute a block once.
>
> For example, I might have an org file with 4 code blocks which I want to
> all run in the same session. However, I might want to execute each block
> interactively, not run all four blocks sequentially all in one batch. I
> might execute block 1, then based on the result/output form that block,
> execute block 2 or 3, but maybe not both or perhaps I will execute block
> 2 twice before executing block 3 etc.
>
> If you adopt your approach, we would loose that flexibility. The session
> argument would essentially boil down to execute all code blocks in this
> file within the same batch rather than execute each one in a separate
> environment/instance. While this could be a valid interpretation of
> session, we would need to be sure it was one which all users found
> agreeable. It is possible, for stability and maintainability, a new
> definition of session would be acceptable, but it is a change with
> implications that would need to be managed carefully.

next prev parent reply	other threads:[~2022-06-24  1:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 23:57 Using exec functions to simplify session code Ivar Fredholm
2022-06-24  0:53 ` Tim Cross
2022-06-24  1:31   ` Ivar Fredholm [this message]
2022-06-26  4:33     ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='4GgreROUkMant3E8LK7kKgeciZbHZDaEywwaKsZk34klCmvBr9paFe9ay4YziC80ubNd7mqwbbETwbjv6Q9EIs_3M1mM_Mv3H9cHOOyVr1I=@protonmail.com' \
    --to=freddyholms@protonmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).