On Wed, Jan 12, 2022 at 1:50 AM Jeremie Juste wrote:
>
> Hello John,
>
> Many thanks for reporting. I'm short of time right now, but I'll take a
> closer look at the problem over
> the weekend and keep you posted. Could you let me know which version of
> org-mode you are currently using?
Sure
Hello John,
Many thanks for reporting. I'm short of time right now, but I'll take a closer
look at the problem over
the weekend and keep you posted. Could you let me know which version of
org-mode you are currently using?
Best regards,
Jeremie Juste
On Tuesday, 11 Jan 2022 at 17:36, John
Greetings,
Apologies for writing off-list, but I don't have the original thread
anymore to reply to. I just pulled this group in directly from the
email I found... I just got bitten by this as well and burned most of
my afternoon trying to figure out what the issue was.
Any further thoughts on a
Hello,
I must apologize again for the delay. I'll be more responsive from now
on.
@Jack, I have applied the patch at the bottom of the mail. It is not
your latest patch but it works as well and is able to handle R errors.
> https://orgmode.org/list/87ft7t9wqk@gmail.com/
I have also added
Hello Jack,
> Thanks for volunteering to maintain ob-R.el :)
Thanks for the encouragements and the suggestions.
I need will take some time to dive into the existing code but
I will definitely look into it and keep you posted.
I've also noticed a [1] bug waiting to be fixed.
[1]
Hi Jeremie,
Thanks for volunteering to maintain ob-R.el :)
I'm bumping this patch [0] to see if it could be merged into ob-R.el. It
fixes some long-standing issues with prompt mangling for :session blocks
with :results output.
Elsewhere in the thread, Chuck had a suggestion [1] to allow
Thanks. This patch works for my org files.
On Tue 08 Sep 2020 at 12:41, Jack Kamm wrote:
Hi Chuck,
this is already present in `org-babel-R-evaluate-session' in
the call to
`org-babel-comint-eval-invisibly-and-wait-for-file'' just a
couple of lines further down in the `(cl-case
Hi Chuck,
> this is already present in `org-babel-R-evaluate-session' in the call to
> `org-babel-comint-eval-invisibly-and-wait-for-file'' just a couple of lines
> further down in the `(cl-case result-type (value ...))' branch.
>
> The other use of `tmp-file' in that block is the one that
Jack,
Maybe I am confused here:
> On Sep 8, 2020, at 7:51 AM, Jack Kamm wrote:
>
> Yes, if we did that then tmp-file would have a prefix like
> "/scp:user@hostname:", and elisp would then know to read the result file
> from the remote host.
>
> Before pasting tmp-file into R code, we should
"Berry, Charles" writes:
> Also, I wonder if the `:results value' case can be handled in a similar
> manner, viz.
>
> - (let ((tmp-file (org-babel-temp-file "R-")))
> + (let ((tmp-file (with-current-buffer session (org-babel-temp-file "R-"
Yes, if we did that then tmp-file would have a
Jack,
> On Sep 7, 2020, at 6:06 PM, Jack Kamm wrote:
>
> Hi Chuck,
>
>> I can confirm that this works on my setup in each of the scenarios in which
>> `default-directory' got set correctly in the session buffer.
>>
>> At some point, my default-directory got reset to drop the tramp prefix
>>
Hi Chuck,
> I can confirm that this works on my setup in each of the scenarios in which
> `default-directory' got set correctly in the session buffer.
>
> At some point, my default-directory got reset to drop the tramp prefix
> "/scp:/user@host:" in one session after faithfully running the src
Jack,
I can confirm that this works on my setup in each of the scenarios in which
`default-directory' got set correctly in the session buffer.
At some point, my default-directory got reset to drop the tramp prefix
"/scp:/user@host:" in one session after faithfully running the src block
Hi Chuck,
> This does not work for my remote session.
Thanks for testing this.
The remote tests I originally tried did not cover this case -- I only
tested the case where both org-file and session were remote, but didn't
test the case where org-file was local and session was remote.
I've now
Jack,
This does not work for my remote session.
I run from macOS locally and on a Linux host remotely. I use
M-x shell RET
R RET
M-x ess-remote RET R RET
to start the R session.
The problem is that tempfiles on the remote host are like
I just realized my patch had an issue where it freezes if there is an
error in the source block.
I'm attaching a second patch, to be applied on top of the first one, that fixes
the issue.
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index b37e3965a..5ddf0ebd1 100644
--- a/lisp/ob-R.el
+++
Hi Chuck and Dylan,
"Berry, Charles" writes:
> This problem has been bugging people for years and previous attempts to solve
> it have always run up against creating more problems in the process of
> solving this one.
>
> If you do decide to dig into solving this, please be sure that remote
Thanks for the workaround idea of grabbing the results as a
string.
I'm not sure why this issue cropped up for me right now when I did
not run into it in previous years. But I have run into other
:results output issues in the past when ess changed.
Thanks,
Dylan
On Sat 29 Aug 2020 at
Yes, the modified comint-prompt-regexp works for my use cases and
I'm back to expected output and what I had last time I taught the
course. This was my instinct for a simple solution as well, but
I've not tested against remote sessions and graphical outputs as
Charles Berry warns.
I'll take
This problem has been bugging people for years and previous attempts to solve
it have always run up against creating more problems in the process of solving
this one.
This workaround gives the same results with or without `:session "NEW"' and
same as OPs first src block:
#+header: :prologue
Hi Dylan,
> The patch does fix that issue -- but it introduces a different bug
> for code blocks with ~:session~: the R block now only produces
> output from the last statement evaluated.
Of course, you're right. Good catch.
Here's another attempt. It fixes the issue by modifying the R comint
Hi Jack,
The patch does fix that issue -- but it introduces a different bug
for code blocks with ~:session~: the R block now only produces
output from the last statement evaluated.
#+begin_src R :results output :exports both :session
4.0 * 3.5
log(10) # natural log
log10(10)
(3 + 1) * 5
Hi Dylan,
I'm able to reproduce your error. I think this same bug has been
previously reported at [1]. As discussed there, the reason is that
substrings ending in ">" get stripped out by
org-babel-comint-with-output because it thinks they are prompts (in
particular, they match
23 matches
Mail list logo