Re: [O] Babel R source blocks problem
On Mon, 13 Mar 2017, Thomas S. Dye wrote:
Aloha Chuck,
Charles C. Berry writes:
On Fri, 10 Feb 2017, Thomas S. Dye wrote:
Aloha Chuck,
Charles C. Berry writes:
A look at the `slidify-example.org' file in the `org-9-plus' branch of my
(chasberry) `orgmode-accessories' github repo might be a good start with
.Rmd exports even if you do not want to use `slidify'.
{snip - discussion of how to export to R markdown]
Just a short note to let you know that ox-ravel was a terrific tool for
my project of producing a workable R Markdown file for an upcoming
conference. I was dreading the requirement to provide .Rmd source for a
handout, but ox-ravel made it one of the easiest steps.
I just got back from two weeks offline and it was nice to find your note.
I am glad ox-ravel did the job for you!
Best,
Chuck
Re: [O] Babel R source blocks problem
Aloha Chuck,
Charles C. Berry writes:
> On Fri, 10 Feb 2017, Thomas S. Dye wrote:
>
>> Aloha Chuck,
>>
>> Charles C. Berry writes:
>>>
>>> A look at the `slidify-example.org' file in the `org-9-plus' branch of my
>>> (chasberry) `orgmode-accessories' github repo might be a good start with
>>> .Rmd exports even if you do not want to use `slidify'.
>>
>> Your ox-ravel exporter is a pleasure to use. I'm farther along than I
>> thought I'd be at this point.
>>
>
> Thanks. I am glad to hear this.
>
>
>> I'm new to much of the R ecosystem, including slidify, so forgive some
>> noob ignorance in the following three questions:
>>
>> 1) I've specified the properties EXPORT_TITLE and EXPORT_AUTHOR, but
>> they don't show up in the .Rmd file. Is this a limitation of ox-ravel,
>> or do I need to learn how to insert them in the Org mode source?
>>
>
> Both, I guess.
>
> Arguably, it is a limitation in the markdown backends available that
> there isn't one that will create the yaml header from the export
> options in the org buffer. I think the long term fix is to create a
> backend derived from 'md, but this is far down my todo list. For now,
> either hand tool a yaml header like that in
>
> : slidify-example.org::#tds-headline
>
> (If you are viewing that on my github repo, be sure to click 'raw' or the
> yaml header will not be visible!)
>
> or create a src block that will pull the title, author, et cetera and wrap
> them as a yaml header in an md export block and put it at the top of the
> output. If you want to do the src block, I can provide a skeleton version.
>
>
>> 2) How do I instruct ox-ravel to include the graphics output of a source
>> code block? I tried :ravel fig=TRUE as a header to the source code
>> block, but no dice. Most of my experience is with ox-latex, so that
>> colors my expectations here; i.e. I'm expecting a [[file:myfile.pdf]]
>> link to produce a graphic in the output.
>
> Often it `just works', but it depends on the vignette engine. `fig=TRUE'
> is correct for Sweave. See
>
> : demos.org::#36234656-157D-4F1D-B441-E727DFCC0251
>
> for an example of that. For knitr, you usually do not need to include
> anything if there is just one plot produced, but there are loads of
> options. See
>
> https://yihui.name/knitr/options/#plots
>
>
> I find myself using ~:ravel fig.cap=my_caption~ (where `my_caption' is
> an R string from an earlier src block) a lot. See
>
> : demos.org::#C341969B-90F3-4C27-AA7F-5352A9669506
>
> for an example of a lengthy caption done in latex.
>
> There is a src block that produces a plot in the slidify-example.org file.
> No special header was needed for ~slidify()~ to render it. But I cannot
> be sure whether the yaml block does something special for the graphics.
>
>>
>> 3) I've been knitting the .Rmd output using RStudio, which is also new
>> to me. I don't mind doing this (it is what the session organizer is
>> going to do with the .Rmd file I send next week), but I'm wondering
>> if you have an emacs-only solution?
>>
>
> I don't know RStudio, but here is a start:
>
> #+BEGIN_SRC R :exports none :results silent
> require(rmarkdown)
> render("my-file.Rmd")
> #+END_SRC
>
> If you look at the =demos.org= file, you will see examples and the src
> blocks used to run ~knitr::knit2pdf()~. If you export some of the
> examples to *.Rmd files and run the equivalent ~render(...)~ on the .Rmd
> files, you will get html by default.
>
> ---
>
> Let me know how it works out!
Just a short note to let you know that ox-ravel was a terrific tool for
my project of producing a workable R Markdown file for an upcoming
conference. I was dreading the requirement to provide .Rmd source for a
handout, but ox-ravel made it one of the easiest steps.
Thanks for your contribution to Org mode and your support when I was
flailing around last month.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Babel R source blocks problem
On Fri, 10 Feb 2017, Thomas S. Dye wrote:
Aloha Chuck,
Charles C. Berry writes:
A look at the `slidify-example.org' file in the `org-9-plus' branch of my
(chasberry) `orgmode-accessories' github repo might be a good start with
.Rmd exports even if you do not want to use `slidify'.
Your ox-ravel exporter is a pleasure to use. I'm farther along than I
thought I'd be at this point.
Thanks. I am glad to hear this.
I'm new to much of the R ecosystem, including slidify, so forgive some
noob ignorance in the following three questions:
1) I've specified the properties EXPORT_TITLE and EXPORT_AUTHOR, but
they don't show up in the .Rmd file. Is this a limitation of ox-ravel,
or do I need to learn how to insert them in the Org mode source?
Both, I guess.
Arguably, it is a limitation in the markdown backends available that
there isn't one that will create the yaml header from the export
options in the org buffer. I think the long term fix is to create a
backend derived from 'md, but this is far down my todo list. For now,
either hand tool a yaml header like that in
: slidify-example.org::#tds-headline
(If you are viewing that on my github repo, be sure to click 'raw' or the
yaml header will not be visible!)
or create a src block that will pull the title, author, et cetera and wrap
them as a yaml header in an md export block and put it at the top of the
output. If you want to do the src block, I can provide a skeleton version.
2) How do I instruct ox-ravel to include the graphics output of a source
code block? I tried :ravel fig=TRUE as a header to the source code
block, but no dice. Most of my experience is with ox-latex, so that
colors my expectations here; i.e. I'm expecting a [[file:myfile.pdf]]
link to produce a graphic in the output.
Often it `just works', but it depends on the vignette engine. `fig=TRUE'
is correct for Sweave. See
: demos.org::#36234656-157D-4F1D-B441-E727DFCC0251
for an example of that. For knitr, you usually do not need to include
anything if there is just one plot produced, but there are loads of
options. See
https://yihui.name/knitr/options/#plots
I find myself using ~:ravel fig.cap=my_caption~ (where `my_caption' is
an R string from an earlier src block) a lot. See
: demos.org::#C341969B-90F3-4C27-AA7F-5352A9669506
for an example of a lengthy caption done in latex.
There is a src block that produces a plot in the slidify-example.org file.
No special header was needed for ~slidify()~ to render it. But I cannot
be sure whether the yaml block does something special for the graphics.
3) I've been knitting the .Rmd output using RStudio, which is also new
to me. I don't mind doing this (it is what the session organizer is
going to do with the .Rmd file I send next week), but I'm wondering
if you have an emacs-only solution?
I don't know RStudio, but here is a start:
#+BEGIN_SRC R :exports none :results silent
require(rmarkdown)
render("my-file.Rmd")
#+END_SRC
If you look at the =demos.org= file, you will see examples and the src
blocks used to run ~knitr::knit2pdf()~. If you export some of the
examples to *.Rmd files and run the equivalent ~render(...)~ on the .Rmd
files, you will get html by default.
---
Let me know how it works out!
Best,
Chuck
Re: [O] Babel R source blocks problem
Aloha Chuck, Charles C. Berry writes: > > A look at the `slidify-example.org' file in the `org-9-plus' branch of my > (chasberry) `orgmode-accessories' github repo might be a good start with > .Rmd exports even if you do not want to use `slidify'. Your ox-ravel exporter is a pleasure to use. I'm farther along than I thought I'd be at this point. I'm new to much of the R ecosystem, including slidify, so forgive some noob ignorance in the following three questions: 1) I've specified the properties EXPORT_TITLE and EXPORT_AUTHOR, but they don't show up in the .Rmd file. Is this a limitation of ox-ravel, or do I need to learn how to insert them in the Org mode source? 2) How do I instruct ox-ravel to include the graphics output of a source code block? I tried :ravel fig=TRUE as a header to the source code block, but no dice. Most of my experience is with ox-latex, so that colors my expectations here; i.e. I'm expecting a [[file:myfile.pdf]] link to produce a graphic in the output. 3) I've been knitting the .Rmd output using RStudio, which is also new to me. I don't mind doing this (it is what the session organizer is going to do with the .Rmd file I send next week), but I'm wondering if you have an emacs-only solution? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Babel R source blocks problem
Aloha Chuck, Charles C. Berry writes: > > Fair enough! > > If you are running org-9.0 or later, please use the `org-9-plus' branch > (the default, now) of ox-ravel. It has a lot more capabilities than the > old `master' branch. The code is cleaner, too. :-) > > As far as .Rmd files go, =(require 'ox-ravel)= and (if not already done in > your init) either =(require 'ox-md)= or selecting markdown from the > customize menu should allow `C-c C-e r m' to export a buffer as .Rmd. Works perfectly. Thanks! > A look at the `slidify-example.org' file in the `org-9-plus' branch of my > (chasberry) `orgmode-accessories' github repo might be a good start with > .Rmd exports even if you do not want to use `slidify'. Got it. This looks like the place to learn about ravel attributes. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Babel R source blocks problem
On Sat, 28 Jan 2017, Thomas S. Dye wrote: Aloha Chuck, [snip] Thanks, too, for asking about export. I'm giving a demo at a conference this spring and the organizer has asked for a .rmd file, which is new to me. I hope to produce it with your ox-ravel, also new to me, so I might be pestering the list again :) Fair enough! If you are running org-9.0 or later, please use the `org-9-plus' branch (the default, now) of ox-ravel. It has a lot more capabilities than the old `master' branch. The code is cleaner, too. :-) As far as .Rmd files go, =(require 'ox-ravel)= and (if not already done in your init) either =(require 'ox-md)= or selecting markdown from the customize menu should allow `C-c C-e r m' to export a buffer as .Rmd. A look at the `slidify-example.org' file in the `org-9-plus' branch of my (chasberry) `orgmode-accessories' github repo might be a good start with .Rmd exports even if you do not want to use `slidify'. Best, Chuck
Re: [O] Babel R source blocks problem
Aloha Chuck, Charles C. Berry writes: > I hope somebody recognizes that message. If not, here are som suggestions: > > > #+NAME: alpha > #+BEGIN_SRC emacs-lisp > "abc" > #+END_SRC > > produces > > #+RESULTS: alpha > : abc > > when you run `org-babel-execute-src-block'. Does changing "emacs-lisp" > to "R" and running again erase the result or fail to insert it if > you first run `org-babel-remove-result'? > > You have already checked that C-c C-v C-i for both versions yields > identical results, right? > > If so, I'd instrument `org-babel-execute-src-block', execute and then > type 'h' just before the `(org-babel-insert-result ... ' --- a couple > of lines from the bottom --- once you enter edebug. Then `e' and > `results' to see that it is what you suppose it should be. Then step > thru the next few lines to insert the result. Then check the buffer to > see what happened. If no result was inserted, then I'd instrument > `org-babel-insert-result' and work from there. > > HTH, > > Chuck > > p.s. You are not trying to export this and depending on the exporter > to run babel, right? Because there is another trick lying in wait... That helped me find the user error, duplicate NAME. Sorry for the noise and thanks for the help. Thanks, too, for asking about export. I'm giving a demo at a conference this spring and the organizer has asked for a .rmd file, which is new to me. I hope to produce it with your ox-ravel, also new to me, so I might be pestering the list again :) All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Babel R source blocks problem
On Sat, 28 Jan 2017, Thomas S. Dye wrote: Aloha all, I've run into a problem running R code blocks in a new Spacemacs setup. Results are not written to the Org mode buffer. In *Messages* I see this the first time I evaluate the R source code block: Error during redisplay: (jit-lock-function 804) signaled (search-failed "^> ") If I run R in a :session, then I see that the source code block is executing correctly. Other languages don't seem to have a problem writing results to the Org mode buffer. Any ideas how I might debug this? I hope somebody recognizes that message. If not, here are som suggestions: #+NAME: alpha #+BEGIN_SRC emacs-lisp "abc" #+END_SRC produces #+RESULTS: alpha : abc when you run `org-babel-execute-src-block'. Does changing "emacs-lisp" to "R" and running again erase the result or fail to insert it if you first run `org-babel-remove-result'? You have already checked that C-c C-v C-i for both versions yields identical results, right? If so, I'd instrument `org-babel-execute-src-block', execute and then type 'h' just before the `(org-babel-insert-result ... ' --- a couple of lines from the bottom --- once you enter edebug. Then `e' and `results' to see that it is what you suppose it should be. Then step thru the next few lines to insert the result. Then check the buffer to see what happened. If no result was inserted, then I'd instrument `org-babel-insert-result' and work from there. HTH, Chuck p.s. You are not trying to export this and depending on the exporter to run babel, right? Because there is another trick lying in wait...
