Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC

2013-04-01 Thread Yihui Xie
I do not know much about S4, but I figured out one possible solution on knitr's side, which I do not really understand. In short, your S4 methods need to be evaluated in globalenv(), but knitr uses the parent.frame() by default, which is not the global environment when it is called as the vignette

Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC

2013-04-01 Thread Martin Morgan
On 04/01/2013 05:37 PM, Henrik Bengtsson wrote: Hi, things have indeed changed on how non-Sweave vignettes are built (this happened around R devel 2013-03-05 r62130). However, it's not clear to me what changes would be behind your problems, if any. Build your vignette with the following buildV

Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC

2013-04-01 Thread Henrik Bengtsson
Hi, things have indeed changed on how non-Sweave vignettes are built (this happened around R devel 2013-03-05 r62130). However, it's not clear to me what changes would be behind your problems, if any. Build your vignette with the following buildVignette(), which emulates what R does when it buil

[Rd] missing exported methods when compiling vignettes in R 3.0.0 RC

2013-04-01 Thread Richard D. Morey
A new problem has cropped up with compiling vignettes for my package BayesFactor. I'm not sure when it started, but I can tell you it didn't occur on R 2.15.3, and it does on 3.0.0 RC (2013-03-31 r62463) (session info is at the bottom of this message). I have defined methods for which.min and w

Re: [Rd] Timing of SET_VECTOR_ELT

2013-04-01 Thread Simon Urbanek
On Apr 1, 2013, at 2:54 PM, Terry Therneau wrote: > > > On 04/01/2013 12:44 PM, Simon Urbanek wrote: >> On Apr 1, 2013, at 1:10 PM, Terry Therneau wrote: >> >>> Assume a C program invoked by .Call, that returns a list. >>> >>> Near the top of the program we allocate space for all the list elem

Re: [Rd] Timing of SET_VECTOR_ELT

2013-04-01 Thread Terry Therneau
On 04/01/2013 12:44 PM, Simon Urbanek wrote: On Apr 1, 2013, at 1:10 PM, Terry Therneau wrote: Assume a C program invoked by .Call, that returns a list. Near the top of the program we allocate space for all the list elements. (It is my habit to use "xyz2" for the name of the R object and "x

Re: [Rd] Timing of SET_VECTOR_ELT

2013-04-01 Thread Duncan Murdoch
On 01/04/2013 1:10 PM, Terry Therneau wrote: Assume a C program invoked by .Call, that returns a list. Near the top of the program we allocate space for all the list elements. (It is my habit to use "xyz2" for the name of the R object and "xyz" for the pointer to its contents.) PROTE

Re: [Rd] Timing of SET_VECTOR_ELT

2013-04-01 Thread Simon Urbanek
On Apr 1, 2013, at 1:10 PM, Terry Therneau wrote: > Assume a C program invoked by .Call, that returns a list. > > Near the top of the program we allocate space for all the list elements. (It > is my habit to use "xyz2" for the name of the R object and "xyz" for the > pointer to its contents.)

[Rd] Timing of SET_VECTOR_ELT

2013-04-01 Thread Terry Therneau
Assume a C program invoked by .Call, that returns a list. Near the top of the program we allocate space for all the list elements. (It is my habit to use "xyz2" for the name of the R object and "xyz" for the pointer to its contents.) PROTECT(means2 = allocVector(REALSXP, nvar)); means

Re: [Rd] R/Sweave/cairo/freetype bug fix.

2013-04-01 Thread Simon Urbanek
On Apr 1, 2013, at 5:18 AM, Hin-Tak Leung wrote: > --- On Sat, 30/3/13, Hin-Tak Leung wrote: > >> "... was committed to freetype in January and will form the >> next release (2.4.12)". > > It is perhaps worth repeating the quote: 'The official R binaries for > windows ... are compiled again

Re: [Rd] R/Sweave/cairo/freetype bug fix.

2013-04-01 Thread Hin-Tak Leung
--- On Sat, 30/3/13, Hin-Tak Leung wrote: > "... was committed to freetype in January and will form the > next release (2.4.12)". It is perhaps worth repeating the quote: 'The official R binaries for windows ... are compiled against static libraries of cairo 1.10.2 ... are firmly in the "do