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 t
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 Hend
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 the
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]
https://orgmode
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 :results
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 result-type
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 requi
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 al
"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 p
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 b
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
several
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 te
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
"/tmp/RtmpeFHudh/file23a66d2fc1
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
+++ b/lisp/ob-
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
>
Hi Chuck,
"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
> sessions
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 15:3
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 a
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 "c
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
3^-1
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 comint-prompt-regexp
I returned to an org file this week and found that I am getting
some strange source code block output for R code when I use the
:session header. I have been able to duplicate this with a minimal
init file. I strongly suspect it is some problem at my end but
perhaps folks here can help me know h
25 matches
Mail list logo
