process_tangle.block now includes opts.label

[jreynolds01]

No description provided.

[yihui]

Thanks, but I'm afraid this is unlikely work even though it is a correct thing to do, since the tangle process does not evaluate the R code in a document, which means opts_template$set() does not work if you have it in a certain code chunk. The much more reliable approach for tangling R code is to set knit_hooks$set(purl = hook_purl). You are not recommended to use the purl() function with default settings when your document has any advanced features that require evaluating certain R code chunks to make purl() work correctly, such as opts_chunk$set().

[jreynolds01]

Thanks -- I will take a look at this and see if it meets my needs.

Best,
-Jeremy

On Sun, Jul 20, 2014 at 10:11 AM, Yihui Xie notifications@github.com
wrote:

Thanks, but I'm afraid this is unlikely work even though it is a correct
thing to do, since the tangle process does not evaluate the R code in a
document, which means opts_template$set() does not work if you have it in
a certain code chunk. The much more reliable approach for tangling R code
is to set knit_hooks$set(purl = hook_purl). You are not recommended to
use the purl() function with default settings when your document has any
advanced features that require evaluating certain R code chunks to make
purl() work correctly, such as opts_chunk$set().

—
Reply to this email directly or view it on GitHub
#812 (comment).

Try Enterprise R Now!
https://aws.amazon.com/marketplace/seller-profile/ref=_ptnr_emailfooter?ie=UTF8&id=3c6536d3-8115-4bc0-a713-be58e257a7be
Get a 14 Day Free Trial of Revolution R Enterprise on AWS Marketplace

[jreynolds01]

I see the issue now and why my solution was working for my use-case, but
would not work more generally.

Basically, I want to render (and tangle) a document twice, once with some
code included, and a second time without that code included. I was
effectively doing:

knitr::opts_template$set(solution = list(include=FALSE, purl=FALSE))
knitr::knit()
knitr::purl()
knitr::opts_template$set(solution = list(include=TRUE, purl=TRUE))
knitr::knit()
knitr::purl()

where opts.label="solution" for only a subset of code.

That seemed to do exactly what I wanted it to do. I could see how if you
used the opts_template::set() function in an actual chunk, the purl call
wouldn't execute it. It's not clear to me how to achieve the same usage
with knit_hooks$set(purl = hook_purl),but I will dig a little deeper and
see if I can solve it a different way.

Thanks again.

Also, I apologize for not responding earlier -- i was out of town without
much access to email.

-Jeremy

On Mon, Aug 4, 2014 at 9:08 AM, Jeremy Reynolds <
jeremy.reynolds@revolutionanalytics.com> wrote:

Thanks -- I will take a look at this and see if it meets my needs.

Best,
-Jeremy

On Sun, Jul 20, 2014 at 10:11 AM, Yihui Xie notifications@github.com
wrote:

Thanks, but I'm afraid this is unlikely work even though it is a correct
thing to do, since the tangle process does not evaluate the R code in a
document, which means opts_template$set() does not work if you have it
in a certain code chunk. The much more reliable approach for tangling R
code is to set knit_hooks$set(purl = hook_purl). You are not recommended
to use the purl() function with default settings when your document has
any advanced features that require evaluating certain R code chunks to make
purl() work correctly, such as opts_chunk$set().

—
Reply to this email directly or view it on GitHub
#812 (comment).

Try Enterprise R Now!
https://aws.amazon.com/marketplace/seller-profile/ref=_ptnr_emailfooter?ie=UTF8&id=3c6536d3-8115-4bc0-a713-be58e257a7be
Get a 14 Day Free Trial of Revolution R Enterprise on AWS Marketplace

[jamiefolson]

@yihui Calling purl calls knit with tangle=TRUE and subsequently uses process_tangle, which is why code chunks aren't actually executed. Are you suggesting that you can get the desired purl output behavior with tangle=FALSE(running process_group so you get consistent chunk options semantics) and just manually setting the "purl" hook? Or do you mean that you should just manually set the knitr hook before calling purl or knit(...,tangle=TRUE)?

[jamiefolson]

I understand things a bit better now. The hook_purl create the R script as a side-effect unrelated to the normal knit output. Although the current default output, out.purl = sub_ext(input, 'R'), is certainly reasonable, it might be desirable for this to be configurable if it's going to be the recommended process for advanced usage. If we, for example, wanted the purl output to be sub_ext(input, 'R'), it seems that we would need to manually copy it after calling knit.

[yihui]

purl() can be extremely tricky in knitr, and I would suggest you not use it at all when your chunk settings are so complicated. It is too difficult to get it correct, and sometimes I even regret having included purl() in knitr. When your document grows complicated, I recommend you to treat knit() as the new source(), and forget about the R script produced by purl():

knitr/man/knit.Rd

Lines 126 to 133 in 986da4f

	N.B. There is no guarantee that the R script generated by \code{purl()} can
	reproduce the computation done in \code{knit()}. The \code{knit()} process
	can be fairly complicated (special values for chunk options, custom chunk
	hooks, computing engines besides R, and the \code{envir} argument, etc). If
	you want to reproduce the computation in a report generated by
	\code{knit()}, be sure to use \code{knit()}, instead of merely executing
	the R script generated by \code{purl()}. This seems to be obvious, but some
	people \href{http://bit.ly/SnLi6h}{just do not get it}.

[jamiefolson]

We were able to get this solution to work, but I noticed that opts_template$set(mylabel=list(include=FALSE)) leads to content excluded from the knitted document, but included in the purled document generated by knit_hooks$set(purl=hook_purl).

In order to get consistency, it was necessary to use opts_template$set(mylabel=list(include=FALSE,purl=FALSE)). Is this the intended behavior?

[yihui]

Yes, I think so. include is for knitting only.

[jamiefolson]

That behavior is obviously consistent with the behavior of purl(...), but I just wanted to point out that knit_hooks$set(purl=hook_purl) does not create a script consistent with the behavior of knit(...).

I know you're saying "just use knit to run the code", but it may be inconvenient/unacceptable to share the original Rmd file.

[yihui]

I understand the frustration, but as I said, it is not trivial for purl() to be entirely consistent with knit(). In my eyes, sharing the original Rmd file looks easier than coming up with a perfect purl(), and it is low priority on my plan. Sorry.

[jamiefolson]

No need to apologize. You've created a fantastically useful tool. I just
wanted to be sure to document any inconsistencies. Like many of the other
specific issues, this is pretty easy to work around once you know the
behavior.

Jamie Olson

On Fri, Aug 22, 2014 at 3:22 PM, Yihui Xie notifications@github.com wrote:

I understand the frustration, but as I said, it is not trivial for purl()
to be entirely consistent with knit(). In my eyes, sharing the original Rmd
file looks easier than coming up with a perfect purl(), and it is low
priority on my plan. Sorry.

—
Reply to this email directly or view it on GitHub
#812 (comment).

[yihui]

Great. Thanks for the understanding.