I just noticed one more thing, regarding ess-eval-visibly etc:
>> + (setq user-inject-src-param ess-inject-source)
>> (setq ess-eval-visibly nil)
>> + (setq ess-inject-source 'function-and-buffer)
>> (ess-eval-buffer nil))
>> - (setq ess-eval-visibly
Hi Jeremie and Chuck,
>> But changing to `:async yes', the error aborts in a way that omits the
>> output.
>
> Interesting, I haven't thought about errors cases enough. Async process
> will be on the 9.5 release and this issue will be next on the todo list.
> Many thanks again for the feedback.
Hi Jeremie,
Many thanks for bringing this over the finish line! I'm very glad it
made it into Org 9.5.
All the tests passed on my end, and and I successfully ran a few async
R blocks without any issues.
I do have some suggestions for code style below. They apply to both the
original patch, as
Hello Chuck,
> OK. The patch works when applied on top of the previous 2 (but the second one
> has the same name, so there is that to watch out for).
Thanks for the feedback, I'll make sure to provide unique names for
patches in the future.
>
> However, I think we are not quite home free. With
Jeremie,
> On Sep 28, 2021, at 12:34 AM, Jeremie Juste wrote:
>
> Thanks for the feedback. With the following patch, I made sure that
> ess-inject-source is set to default before evaluating the buffer.
>
> So even if I set
> (setq ess-inject-source 'function-and-buffer), I get the following
>
Hello Chuck,
On Monday, 27 Sep 2021 at 23:40, Berry, Charles wrote:
> Jeremie,
>
>> On Sep 27, 2021, at 3:56 PM, Berry, Charles wrote:
>>
>> There is something in my init that doesn't play nice with this.
>
> (setq ess-inject-source nil)
Thanks for the feedback. With the following patch, I
Hi Jeremie,
> For the parameter :async without any values assigned to it. I'm
> coordinating with ob-python.el and the orginal package
> https://github.com/jackkamm/ob-session-async.
>
> Jack do you see the need to change it and expect :async to have the
> value yes or no?
I wrote the :async
Jeremie,
> On Sep 27, 2021, at 3:56 PM, Berry, Charles wrote:
>
> There is something in my init that doesn't play nice with this.
(setq ess-inject-source nil)
seems to be the culprit.
Also note, even with ess-inject-source set to t, there is an indentation issue:
#+begin_src R
Jeremie,
There is something in my init that doesn't play nice with this.
IOW, emacs -q and then load the minimal stuff works OK, but my usual startup
does not.
#+begin_src R :session *R* :results output :async yes
Sys.sleep(5)
1:5
#+end_src
#+RESULTS:
: > >
: [1] 1 2 3 4 5
: >
It may
Hello Chuck,
On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>
> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a
> default setting.
Thanks again for your suggestion. The following patch to be applied on
top of the previous one, solves the issue.
#+begin_src R
Hello Chuck,
On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>
> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a
> default setting.
>
Many thanks for the feedback.
>
> which is better, but the prompts still need cleaning along the lines of
>
Hello,
On Monday, 27 Sep 2021 at 08:48, Bastien wrote:
> Hi Greg and Jeremie,
>
> Greg Minshall writes:
>
>> if this is not already idiomatic for org mode, i'd vote to require the
>> "yes" or "no". just my 2 cents.
>
> Agreed: even if a syntax is allowed, let's use the idiomatic form in
>
Jeremie,
> On Sep 26, 2021, at 10:13 AM, Jeremie Juste wrote:
>
> But for the time being result output produces the following output.
>
> #+begin_src R :session *R* :results output :async
> Sys.sleep(1)
> print(1:5)
> #+end_src
>
> #+RESULTS:
> : > Sys.sleep(1)
> : > print(1:5)
> : [1] 1 2 3
Hi Jeremie,
Jeremie Juste writes:
> I have integrated some of the ob-session-async package in ob-R.el
> (finally). Most of the heavy lifting has been made by Jack.
When this is reliable enough, feel free to commit and push.
You can also enhance it later on.
Thanks,
--
Bastien
Hi Greg and Jeremie,
Greg Minshall writes:
> if this is not already idiomatic for org mode, i'd vote to require the
> "yes" or "no". just my 2 cents.
Agreed: even if a syntax is allowed, let's use the idiomatic form in
examples.
2 cts,
--
Bastien
hi, Jeremie,
> Many thanks for the feedback, assigning yes or no to async will work
> as expected.
thanks for the answer.
> I am not sure if it is a desirable feature or not.
if this is not already idiomatic for org mode, i'd vote to require the
"yes" or "no". just my 2 cents.
cheers, Greg
Hello Greg,
>
> i was surprised by =:async= standing alone, i.e., with no following
> "yes" or "no". is that an org-mode "idiom"? i.e., unadorned header
> arguments default to (some form of) "yes"?
Many thanks for the feedback, assigning yes or no to async will work as
expected.
#+begin_src R
Jeremie,
a question. in
> #+begin_src R :session *R* :results value :async :colnames yes
> Sys.sleep(10)
> as.list(1:5)
> #+end_src
i was surprised by =:async= standing alone, i.e., with no following
"yes" or "no". is that an org-mode "idiom"? i.e., unadorned header
arguments default to
Hello,
I have integrated some of the ob-session-async package in ob-R.el
(finally). Most of the heavy lifting has been made by Jack.
So with the patch async evaluation is expected to work out of the box
for :result value
#+begin_src R :session *R* :results value :async :colnames yes
19 matches
Mail list logo
