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
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
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
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
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
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
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
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.)
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
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
--- 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
11 matches
Mail list logo