[-- Attachment #1: Type: text/plain, Size: 1110 bytes --] Hi there, I got back to an org file after upgrading to the latest release of org-mode and tried executing the contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I had to exit using C-g. Here's a minimal example src block that causes emacs to get stuck: #+begin_src R :results output :session *R* :exports both a <- 10 a #+end_src R itself does start and the code is also executed correctly. However, the output from that session is apparently not returned to emacs or the buffer. When removing the :session argument it executes and returns as expected. When bisecting this issue, I found that this commit causes it: ac8c009e006197d2dad226dbe822d450aec23d23 lisp/ob-R.el: Fix session output with substrings matching prompts Reverting it fixes the issue for earlier release (9.5.3) as well as for the current main branch. The (with-current-buffer session ... ) somehow seems to break it for me, but I am unsure why no one else here seems to experience this as the commit is from 2020? Any suggestions? Thanks! Christian [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes:
> I got back to an org file after upgrading to the latest release of org-mode and tried executing the
> contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I had to
> exit using C-g.
>
> Here's a minimal example src block that causes emacs to get stuck:
>
> #+begin_src R :results output :session *R* :exports both
> a <- 10
> a
> #+end_src
>
> R itself does start and the code is also executed correctly. However, the output from that session
> is apparently not returned to emacs or the buffer.
I tried you example using Emacs >=26 and it works just fine.
Best,
Ihor
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --] Hi, thanks, that's what I had expected since that patch has been around for a long time. I run emacs -q --load /tmp/init.el --file=/tmp/test.org with my /tmp/init.el being only > (require 'package) > (package-initialize) > (add-to-list 'load-path "~/.emacs.d/straight/repos/org/lisp/") > (require 'org) > > ;(require 'ess-site) > (org-babel-do-load-languages > 'org-babel-load-languages > '((R . t))) I hope this constitutes a minimal example for a config - please correct me if I'm wrong. My test.org contains the source block I had already posted: #+begin_src R :results output :session *R* :exports both a <- 10 a #+end_src Any ideas how I could continue to debug this? If I just remove that patch, everything works flawlessly for me but I would like to figure out what causes the issues. Thanks! Christian On Sun, 2022-05-15 at 16:08 +0800, Ihor Radchenko wrote: > Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes: > > > I got back to an org file after upgrading to the latest release of org-mode and tried executing > > the > > contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I > > had to > > exit using C-g. > > > > Here's a minimal example src block that causes emacs to get stuck: > > > > #+begin_src R :results output :session *R* :exports both > > a <- 10 > > a > > #+end_src > > > > R itself does start and the code is also executed correctly. However, the output from that > > session > > is apparently not returned to emacs or the buffer. > > I tried you example using Emacs >=26 and it works just fine. > > Best, > Ihor [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
Hello Christian,
Thanks for reporting but I cannot reproduce the bug with the org and
emacs version below.
Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @
/home/djj/src/org-mode/lisp/)
GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24) of
2022-01-16
Can you please let me know which version of org-mode you are actually
using?
Ihor, many thanks for checking.
Best regards,
Jeremie
On Sunday, 15 May 2022 at 16:08, Ihor Radchenko wrote:
> Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes:
>
>> I got back to an org file after upgrading to the latest release of org-mode and tried executing the
>> contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I had to
>> exit using C-g.
>>
>> Here's a minimal example src block that causes emacs to get stuck:
>>
>> #+begin_src R :results output :session *R* :exports both
>> a <- 10
>> a
>> #+end_src
>>
>> R itself does start and the code is also executed correctly. However, the output from that session
>> is apparently not returned to emacs or the buffer.
>
> I tried you example using Emacs >=26 and it works just fine.
>
> Best,
> Ihor
[-- Attachment #1: Type: text/plain, Size: 2743 bytes --] Hi Jeremie, I just tested with Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ /home/heinrich/.emacs.d/straight/repos/org/lisp/) using GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2021- 11-27, modified by Debian I am on Debian Testing and that is the default emacs version. Using the unmodified org (git hash from above) I get the following messages when executing a src block with R: executing R code block... Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' expected! Type C-h m for help on ESS version 15.09 ess-tracebug mode enabled Quit Package cl is deprecated Note that the "Quit" is me pressing Ctrl-g after a few seconds. Removing the commit in question makes the block return instantaneously: executing R code block... Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' expected! Type C-h m for help on ESS version 15.09 ess-tracebug mode enabled Code block evaluation complete. Package cl is deprecated I anticipated that this would not be obvious, since this feature is used too much to go unnoticed for two years - but I am clueless as to how I should continue with debugging... Thanks for your help! Christian On Sun, 2022-05-15 at 16:16 +0200, Jeremie Juste wrote: > > Hello Christian, > > Thanks for reporting but I cannot reproduce the bug with the org and > emacs version below. > > Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @ > /home/djj/src/org-mode/lisp/) > GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24) of > 2022-01-16 > > Can you please let me know which version of org-mode you are actually > using? > > Ihor, many thanks for checking. > > Best regards, > Jeremie > > On Sunday, 15 May 2022 at 16:08, Ihor Radchenko wrote: > > Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes: > > > > > I got back to an org file after upgrading to the latest release of org-mode and tried > > > executing the > > > contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I > > > had to > > > exit using C-g. > > > > > > Here's a minimal example src block that causes emacs to get stuck: > > > > > > #+begin_src R :results output :session *R* :exports both > > > a <- 10 > > > a > > > #+end_src > > > > > > R itself does start and the code is also executed correctly. However, the output from that > > > session > > > is apparently not returned to emacs or the buffer. > > > > I tried you example using Emacs >=26 and it works just fine. > > > > Best, > > Ihor [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
Um... > On May 15, 2022, at 2:46 AM, Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> wrote: > > I run > > emacs -q --load /tmp/init.el --file=/tmp/test.org > > with my /tmp/init.el being only > >> (require 'package) >> (package-initialize) >> (add-to-list 'load-path "~/.emacs.d/straight/repos/org/lisp/") >> (require 'org) >> >> ;(require 'ess-site) The line above is commented out. So how do you load ess-site? >> (org-babel-do-load-languages >> 'org-babel-load-languages >> '((R . t))) > > I hope this constitutes a minimal example for a config - please correct me if I'm wrong. Just spitballing here: Have you tried instrumenting `org-babel-R-evaluate-session'? Maybe watching changes made to the session buffer on first evaluation and comparing to subsequent evals helps. HTH, Chuck
Hello Christian On Sunday, 15 May 2022 at 20:06, Christian Heinrich wrote: > I just tested with > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > using > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2021- > 11-27, modified by Debian Many thanks for reporting back. I updated to gcdbb1c and it is still working fine. My minimum working example is the following. From the org-mode root directory, $ emacs -Q -L ./lisp -l org -l ~/ess-barebone.el where ~/ess-barebone.el is the following: #+begin_src elisp (add-to-list 'load-path "/home/djj/.emacs.d/elpa/ess-20220125.2207/") (require 'ess-r-mode) (org-babel-do-load-languages 'org-babel-load-languages '((R . t))) (setq org-confirm-babel-evaluate nil) #+end_src Note that I'm still using a rather old ess version. Could you please try with the above configuration? Note that I am using a rather old ess version but the I haven't experienced issues with the newer one. Best regards Jeremie > Hi Jeremie, > > I just tested with > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > using > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2021- > 11-27, modified by Debian > > I am on Debian Testing and that is the default emacs version. > > Using the unmodified org (git hash from above) I get the following messages when executing a src > block with R: > > executing R code block... > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' expected! > Type C-h m for help on ESS version 15.09 > ess-tracebug mode enabled > Quit > Package cl is deprecated > > Note that the "Quit" is me pressing Ctrl-g after a few seconds. > > Removing the commit in question makes the block return instantaneously: > > executing R code block... > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' expected! > Type C-h m for help on ESS version 15.09 > ess-tracebug mode enabled > Code block evaluation complete. > Package cl is deprecated > > I anticipated that this would not be obvious, since this feature is used too much to go unnoticed for > two years - but I am clueless as to how I should continue with debugging... > > Thanks for your help! > Christian > > On Sun, 2022-05-15 at 16:16 +0200, Jeremie Juste wrote: >> >> Hello Christian, >> >> Thanks for reporting but I cannot reproduce the bug with the org and >> emacs version below. >> >> Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @ >> /home/djj/src/org-mode/lisp/) >> GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24) of >> 2022-01-16 >> >> Can you please let me know which version of org-mode you are actually >> using? >> >> Ihor, many thanks for checking. >> >> Best regards, >> Jeremie >> >> On Sunday, 15 May 2022 at 16:08, Ihor Radchenko wrote: >> > Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes: >> > >> > > I got back to an org file after upgrading to the latest release of org-mode and tried >> > > executing the >> > > contained R source blocks. Unfortunately, emacs got stuck in the execution and was blocked; I >> > > had to >> > > exit using C-g. >> > > >> > > Here's a minimal example src block that causes emacs to get stuck: >> > > >> > > #+begin_src R :results output :session *R* :exports both >> > > a <- 10 >> > > a >> > > #+end_src >> > > >> > > R itself does start and the code is also executed correctly. However, the output from that >> > > session >> > > is apparently not returned to emacs or the buffer. >> > >> > I tried you example using Emacs >=26 and it works just fine. >> > >> > Best, >> > Ihor
[-- Attachment #1: Type: text/plain, Size: 4818 bytes --] Hi Jeremie, thank you for providing this example! The ess that was found in the load path was years old and once updated, all issues were resolved. In fact, my so-called minimum init still used (require 'package) and I didn't even think about ESS causing this trouble. It's now a bit clearer how to build a real minimum init - thank you! This is hence resolved. Best regards Christian On Mon, 2022-05-16 at 00:21 +0200, Jeremie Juste wrote: > > Hello Christian > > On Sunday, 15 May 2022 at 20:06, Christian Heinrich wrote: > > I just tested with > > > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > > > using > > > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of > > 2021- > > 11-27, modified by Debian > > > Many thanks for reporting back. I updated to gcdbb1c and it is still working fine. > > My minimum working example is the following. From the org-mode root directory, > > $ emacs -Q -L ./lisp -l org -l ~/ess-barebone.el > > where ~/ess-barebone.el is the following: > > #+begin_src elisp > (add-to-list 'load-path "/home/djj/.emacs.d/elpa/ess-20220125.2207/") > (require 'ess-r-mode) > > (org-babel-do-load-languages > 'org-babel-load-languages > '((R . t))) > > (setq org-confirm-babel-evaluate nil) > #+end_src > > Note that I'm still using a rather old ess version. Could you please try > with the above configuration? Note that I am using a rather old ess > version but the I haven't experienced issues with the newer one. > > Best regards > Jeremie > > > > Hi Jeremie, > > > > I just tested with > > > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > > > using > > > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of > > 2021- > > 11-27, modified by Debian > > > > I am on Debian Testing and that is the default emacs version. > > > > Using the unmodified org (git hash from above) I get the following messages when executing a src > > block with R: > > > > executing R code block... > > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' > > expected! > > Type C-h m for help on ESS version 15.09 > > ess-tracebug mode enabled > > Quit > > Package cl is deprecated > > > > Note that the "Quit" is me pressing Ctrl-g after a few seconds. > > > > Removing the commit in question makes the block return instantaneously: > > > > executing R code block... > > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' > > expected! > > Type C-h m for help on ESS version 15.09 > > ess-tracebug mode enabled > > Code block evaluation complete. > > Package cl is deprecated > > > > I anticipated that this would not be obvious, since this feature is used too much to go > > unnoticed for > > two years - but I am clueless as to how I should continue with debugging... > > > > Thanks for your help! > > Christian > > > > On Sun, 2022-05-15 at 16:16 +0200, Jeremie Juste wrote: > > > > > > Hello Christian, > > > > > > Thanks for reporting but I cannot reproduce the bug with the org and > > > emacs version below. > > > > > > Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @ > > > /home/djj/src/org-mode/lisp/) > > > GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24) of > > > 2022-01-16 > > > > > > Can you please let me know which version of org-mode you are actually > > > using? > > > > > > Ihor, many thanks for checking. > > > > > > Best regards, > > > Jeremie > > > > > > On Sunday, 15 May 2022 at 16:08, Ihor Radchenko wrote: > > > > Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes: > > > > > > > > > I got back to an org file after upgrading to the latest release of org-mode and tried > > > > > executing the > > > > > contained R source blocks. Unfortunately, emacs got stuck in the execution and was > > > > > blocked; I > > > > > had to > > > > > exit using C-g. > > > > > > > > > > Here's a minimal example src block that causes emacs to get stuck: > > > > > > > > > > #+begin_src R :results output :session *R* :exports both > > > > > a <- 10 > > > > > a > > > > > #+end_src > > > > > > > > > > R itself does start and the code is also executed correctly. However, the output from that > > > > > session > > > > > is apparently not returned to emacs or the buffer. > > > > > > > > I tried you example using Emacs >=26 and it works just fine. > > > > > > > > Best, > > > > Ihor > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4820 bytes --] Hi Jeremie, thank you for providing this example! The ess that was found in the load path was years old and once updated, all issues were resolved. In fact, my so-called minimum init still used (require 'package) and I didn't even think about ESS causing this trouble. It's now a bit clearer how to build a real minimum init - thank you! This is hence resolved. Best regards Christian On Mon, 2022-05-16 at 00:21 +0200, Jeremie Juste wrote: > > Hello Christian > > On Sunday, 15 May 2022 at 20:06, Christian Heinrich wrote: > > I just tested with > > > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > > > using > > > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of > > 2021- > > 11-27, modified by Debian > > > Many thanks for reporting back. I updated to gcdbb1c and it is still working fine. > > My minimum working example is the following. From the org-mode root directory, > > $ emacs -Q -L ./lisp -l org -l ~/ess-barebone.el > > where ~/ess-barebone.el is the following: > > #+begin_src elisp > (add-to-list 'load-path "/home/djj/.emacs.d/elpa/ess-20220125.2207/") > (require 'ess-r-mode) > > (org-babel-do-load-languages > 'org-babel-load-languages > '((R . t))) > > (setq org-confirm-babel-evaluate nil) > #+end_src > > Note that I'm still using a rather old ess version. Could you please try > with the above configuration? Note that I am using a rather old ess > version but the I haven't experienced issues with the newer one. > > Best regards > Jeremie > > > > Hi Jeremie, > > > > I just tested with > > > > Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c @ > > /home/heinrich/.emacs.d/straight/repos/org/lisp/) > > > > using > > > > GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of > > 2021- > > 11-27, modified by Debian > > > > I am on Debian Testing and that is the default emacs version. > > > > Using the unmodified org (git hash from above) I get the following messages when executing a src > > block with R: > > > > executing R code block... > > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' > > expected! > > Type C-h m for help on ESS version 15.09 > > ess-tracebug mode enabled > > Quit > > Package cl is deprecated > > > > Note that the "Quit" is me pressing Ctrl-g after a few seconds. > > > > Removing the commit in question makes the block return instantaneously: > > > > executing R code block... > > Loading ‘ess-bugs-l’: unescaped character literals `?(', `?)' detected, `?\(', `?\)' > > expected! > > Type C-h m for help on ESS version 15.09 > > ess-tracebug mode enabled > > Code block evaluation complete. > > Package cl is deprecated > > > > I anticipated that this would not be obvious, since this feature is used too much to go > > unnoticed for > > two years - but I am clueless as to how I should continue with debugging... > > > > Thanks for your help! > > Christian > > > > On Sun, 2022-05-15 at 16:16 +0200, Jeremie Juste wrote: > > > > > > Hello Christian, > > > > > > Thanks for reporting but I cannot reproduce the bug with the org and > > > emacs version below. > > > > > > Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @ > > > /home/djj/src/org-mode/lisp/) > > > GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24) of > > > 2022-01-16 > > > > > > Can you please let me know which version of org-mode you are actually > > > using? > > > > > > Ihor, many thanks for checking. > > > > > > Best regards, > > > Jeremie > > > > > > On Sunday, 15 May 2022 at 16:08, Ihor Radchenko wrote: > > > > Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> writes: > > > > > > > > > I got back to an org file after upgrading to the latest release of org-mode and tried > > > > > executing the > > > > > contained R source blocks. Unfortunately, emacs got stuck in the execution and was > > > > > blocked; I > > > > > had to > > > > > exit using C-g. > > > > > > > > > > Here's a minimal example src block that causes emacs to get stuck: > > > > > > > > > > #+begin_src R :results output :session *R* :exports both > > > > > a <- 10 > > > > > a > > > > > #+end_src > > > > > > > > > > R itself does start and the code is also executed correctly. However, the output from that > > > > > session > > > > > is apparently not returned to emacs or the buffer. > > > > > > > > I tried you example using Emacs >=26 and it works just fine. > > > > > > > > Best, > > > > Ihor > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1274 bytes --] Hi Charles, ob-R.el requires ess and the (require 'package) makes sure the ~/.emacs.d/elpa/ directory was added to the load path. But you were somewhat right already: the loaded ESS was years old and caused the issue. Thanks for your help! Christian On Sun, 2022-05-15 at 19:58 +0000, Berry, Charles wrote: > > Um... > > > On May 15, 2022, at 2:46 AM, Christian Heinrich <com-orgmode-mailinglist@gladbachcity.de> wrote: > > > > I run > > > > emacs -q --load /tmp/init.el --file=/tmp/test.org > > > > with my /tmp/init.el being only > > > > > (require 'package) > > > (package-initialize) > > > (add-to-list 'load-path "~/.emacs.d/straight/repos/org/lisp/") > > > (require 'org) > > > > > > ;(require 'ess-site) > > The line above is commented out. So how do you load ess-site? > > > > > (org-babel-do-load-languages > > > 'org-babel-load-languages > > > '((R . t))) > > > > I hope this constitutes a minimal example for a config - please correct me if I'm wrong. > > > Just spitballing here: > > Have you tried instrumenting `org-babel-R-evaluate-session'? > > Maybe watching changes made to the session buffer on first evaluation and comparing to subsequent > evals helps. > > HTH, > Chuck > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]