search for: weaving

Hi, Recently I saw a couple of cases in which the package vignettes were somewhat complicated so that Stangle() (or knitr::purl() or other tangling functions) can fail to produce the exact R code that is executed by the weaving function Sweave() (or knitr::knit(), ...). For example, this is a valid document that can pass the weaving process but cannot generate a valid R script to be source()d: \documentclass{article} \begin{document} Assign 1 to x: \Sexpr{x <- 1} <<>>= x + 1 @ \end{document} That is becau...

I thought some of you might be amused by this. In my non-work time, I'm an avid weaver and teacher of weaving. I'm working on a project involving creating many detailed weaving patterns, so I wrote R code to automate it. Details here: http://stringpage.com/blog/?p=822 If the overlap between R users and avid tablet weavers turns out to be >> 1, I'll polish it up and turn it into a package....

Now that R 3.0.0+ supports non-Sweave vignettes, R-exts \S 1.4.2 seems to imply that it is possible to include both Sweave and knitr vignettes in a single package. I'm wondering if anyone has tried this and/or if there are some hidden gotchas putting this into practice, and concerned about creating problems with CRAN checks if I try this. Consider two vignettes: pkg/vignettes/vign1.Rnw,

Hello, I'm seeing three different vignette-related errors with recent versions of R-3.0.0 alpha. First, with the package BitSeq (http://bioconductor.org/packages/2.12/bioc/html/BitSeq.html), I get the following when trying to build the package: Error: processing vignette ?BitSeq.Rnw' failed with diagnostics: Failed to locate the ?weave? output file (by engine ?utils::Sweave?) for

Hi, as far as I understand it, the new R devel feature of processing non-Sweave vignettes will (a) locate any "[.][RrSs](nw|tex)$" or ".Rmd" files, (b) check for a registered vignette engine, (c) process the file using the registered "weave" function, (d) and possibly post process the generated weave artifact (e.g. a *.tex file). I'd like to propose to extend

If I understand correctly, all vignettes in a package are built in the same R process. Global options, loaded packages, etc., in an earlier vignette persist in later vignettes. This can introduce user confusion (e.g., when a later vignette builds successfully because a package is require()'ed in an earlier vignette, but not the current one), difficult-to-identify bugs (e.g., when a setting

Interesting, yesterday I had exactly this problem, but today I solved it (see the R-pkg-devel list) by _installing_ R-devel and > update.packages(checkBuilt = TRUE) I also tried it on Martin's Fedora 26 example below. Worked fine (had to install some packages...) On ubuntu 16.04. G?ran Brostr?m On 2017-12-06 11:29, Martin Maechler wrote: >>>>>> Pearce, Robert

I have two questions about packaging up code. 1) Weave/tangle advisable? In the course of extending some C code already in S, I had to work out the underlying math. It seems to me useful to keep this information with the code, using Knuth's tangle/weave type tools. I know there is some support for this in R code, but my question is about the wisdow of doing this with C (or Fortran, or other

I am resubmitting this bug report but with additional information. I am running this with windows 10: w64-mingw32 with R Under development (unstable) (2017-12-04 r73829). I build 'httk' from the command prompt using 'R CMD build httk' after installing the required packages. Then when the vignettes are being created, it crashes. Today I installed the latest versions of Rtools,

Dear useRs, here is the announcement for the next "new" package: sandwich 0.1-3. sandwich provides heteroskedasticity (and autocorrelation) consistent covariance matrix estimators (also called HC and HAC estimators). The former are implemented in the function vcovHC() (which was available in strucchange before - and independently in hccm() in John Fox's car package). And the

Dear useRs, here is the announcement for the next "new" package: sandwich 0.1-3. sandwich provides heteroskedasticity (and autocorrelation) consistent covariance matrix estimators (also called HC and HAC estimators). The former are implemented in the function vcovHC() (which was available in strucchange before - and independently in hccm() in John Fox's car package). And the

...gt;>= <<Chunk1>> <<Chunk2>> EndOfTheCode @ That works ... as long as SomeCode, MoreCode and EndOfTheCode are self- standing pieces of R code, but *not* code fragments. You can *not* intersperse comments in, say, a function body, or local() environment this way : when Sweaving, *R* complains of an incomplete source (makes noise about an unexpected end of input at the end of Chunk1, IIRC, and never sees Chunk2). I hoped that Sweave's "alternative" syntax could offer a way out : no such luck. There seems to be no way to delay R evaluation of a R chunk pa...

>>>>> Pearce, Robert <Pearce.Robert at epa.gov> >>>>> on Tue, 5 Dec 2017 21:31:09 +0000 writes: > I am resubmitting this bug report but with additional information. I am running this with windows 10: w64-mingw32 with R Under development (unstable) (2017-12-04 r73829). There is no such message (as you cite below) in the R-devel archives:

Hello, I want to use seq with multiple from values and am getting unexpected (to me) behavior. I'm wondering if this behavior is intentional or not. > seq(2, by=3, length.out=4) [1] 2 5 8 11 > seq(3, by=3, length.out=4) [1] 3 6 9 12 Now if I want the combined sequence, I thought I could pass in c(2,3), and I get: > seq(c(2,3), by=3, length.out=8) [1] 2 6 8 12 14 18 20 24

...@ \includegraphics[width=\linewidth]{test-binom-sim-fig} \end{document} ---<--------------------cut here---------------end--------------------->--- If the embedded chunks are evaluated directly in an R session, two different panel data are produced by layout(), as expected. However, when weaving and latexing the file produces, then the two panels show the same data, corresponding to the last data set. This doesn't happen if the data are much simpler, say using matplot() with simple sequences of numbers. Any ideas what is causing this and how to get around it? Cheers, -- Seb

Sometimes you want to compute the physical size of a plot based on data. In R itself this is no problem. But is there a way to compute the values of height and width in S-weave, say: <<graph,fig=TRUE,height=xx,width=yy>>= where xx and yy are computed and not physically written in the document? Bendix ______________________________________________ Bendix Carstensen Senior

Thanks Brian. Indeed, the vignette is in markdown form. When I updated my system to R 3.1.3 I ran update.packages() and this seems to have upset things (including R-studio processing of markdown files). I tried removing rmarkdown and reverting to an older version so that my sessionInfo() is Loading required package: rmarkdown > sessionInfo() R version 3.1.3 (2015-03-09) Platform:

Robert, To expand a bit on Goran's point, is it possible that you have an old library with packages installed that your R-devel is hitting. The R headers changes relatively recently, so any packages with compiled code that were built long enough ago (I don't have the exact date off the top of my head) need to be rebuilt before they can be safely used. If this is happening in a state

Background: I run tools::testInstalledPackage on all packages that dependend on survival (605 as of today) before sending a new release to CRAN. It has a few false positives which I then follow up on.? (Mostly packages with as-yet-incomplete tests in their inst directory). ?Issue: testInstalledPackage("mets")? generates an? "Error in checkVignettes(pkg, lib.loc, latex = FALSE,

I've written some "rough" functions for base conversion and digit interweaving (as in x=135, y=246, interwoven=123456) which are ok for a small number of conversions or weaves, but, to be able to handle a large number of conversions or weaves, I'm hoping that some faster code already exists (ideally calling C or FORTRAN). Any suggestions for going base10 to base2, base2...