Re: [Rd] R/Sweave/cairo/freetype bug fix.
--- 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 not work correctly" category' The minimum version of cairo to work being 1.11.2. On closer examination, the official bundle (http://www.rforge.net/Cairo/files/cairo-current-win.tar.gz) is built with neither fontconfig nor freetype. So even if it is bumped to current version (1.12.x), it does not work correctly. Perhaps also wasn't clear in the bugzilla thread - everybody from fontconfig/cairo/freetype involved knew it being the issue so it has never been explicitly spelled out - the problem was (is) with cairo's pdf/ps generation, aided by freetype. > -- > On Sat, Mar 30, 2013 18:54 GMT Simon Urbanek wrote: > > >On Mar 30, 2013, at 9:24 AM, Hin-Tak Leung wrote: > > > >> Perhaps that's too much details. There is (will be) > a new freetype because of cairo's unanticipated usage (which > R uses, among other cairo users). Most people should upgrade > or request an upgrade eventually, when they are > comfortable. > >> > > > >Which versions are affected? R binary for OS X uses > freetype 2.4.11 (and cairo 1.12.14) so I just need to know > if there is an action item. > > > >Thanks, > >SImon > > > > > > > >> --- On Sat, 30/3/13, peter dalgaard > wrote: > >> > >> Huh? > >> > >> This is utterly incomprehensible without reading > the redhat > >> bugzilla, and even after reading, I'm not sure what > the > >> issue is. Something with bold Chinese fonts in X11, > but > >> maybe also affecting Latin fonts, ? > >> > >> Please explain yourself. > >> > >> -pd > >> > >> On Mar 30, 2013, at 09:25 , Hin-Tak Leung wrote: > >> > >>> The problem was first seen with R/Sweave (#c0) > then > >> reproduced directly with cairo (#c10) and was > eventually > >> traced to freetype. The 5-part bug fix: > >>> 610ee58e07090ead529849b2a454bb6c503b4995 > >>> da11e5e7647b668dee46fd0418ea5ecbc33ae3b2 > >>> e1a2ac1900f2f16ec48fb4840a6b7965a8373c2b > >>> 869fb8c49ddf292d6daf4826172a308973d3e11f > >>> d56e544d653b09c657911629557ffc5277a503e3 > >>> was committed to freetype in January and will > form the > >> next release (2.4.12). They were back ported to > 2.4.11 > >>> https://bugzilla.redhat.com/show_bug.cgi?id=891457#c35 > >>> and the redhat people had further back-ported > it to > >> 2.4.10 for fedora 18/19 (#c51). > >>> > >>> The freetype people had reproduced the problem > with a > >> latin font, so this affects most people, unlike > what the > >> initial report (#c0) suggests. > >>> > >>> Since freetype is part of X11, most unix/linux > users > >> would be understandably nervous about breaking X > (see #c45 > >> for screenshot of broken gnome terminal!) and > should wait up > >> to a year before the new and not-yet-released > 2.4.12 becomes > >> an official upgrade; or contact their favourite > unix vendors > >> and/or Apple for upgrades. AFAIK, current > up-to-date linux > >> distributions ships the rather older 2.4.10, with > the > >> exception of fedora 18/19 (#c51). Mac OS X 10.5 > ships > >> freetype 2.3.5 as part of X11; I haven't bother > looking up > >> later Mac OS X's. > >>> > >>> The official R binaries for windows and mac OS > X are > >> compiled against static libraries of cairo 1.10.2 > (over 2 > >> years old), and cairo 1.11.2 and freetype 2.4.4 > >> respectively, and are firmly in the "do not work > correctly" > >> category. > >>> > >>> The long and short of the story is that > R/Sweave uses a > >> feature of cairo which wasn't implemented before > cairo > >> 1.11.2 (#c13, Jan 2011), which in turn depends on a > feature > >> of freetype that has been around since 2005 but did > not > >> anticipate cairo's usage. It is commendable that > the > >> freetype people did not refer to cairo's usage as > "misuse" > >> but took the patience to address the problem, > unlike some > >> group's style. > >>> > >>> It has been an interesting few months returning > to > >> freetype after about 17 years, I think. > >>> > >>> Here is how to look up what version of freetype > - > >> libfreetype.so.x.y.z for most unix platforms, and > >> /usr/X11/lib/libfreetype.x.y.z.dylib on Mac OS X: > >>> > >>> (excerpt from docs/VERSION.DLL) > >>> > >>> version > >> x.y.z date of release > >>> 2.4.11 > >> 6.10.0 Dec 2012 > >>> 2.4.10 > >> 6.9.0 June 2012 > >>> 2.4.9 > > >> 6.8.1 March 2012 > >>> ... > >>> 2.4.4 > > >> 6.6.2 Nov 2010 (official R > mac > >> binaries) > >>> ... > >>> 2.3.5 > > >> 6.3.16 July 2007 (Mac OS X 10.5) > >>> > >>> > >>> __ > >>> R-devel@r-project.org > >> mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> -- > >> Peter Dalgaard, Professor, > >> C
Re: [Rd] R/Sweave/cairo/freetype bug fix.
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 against static libraries of cairo 1.10.2 ... are > firmly in the "do not work correctly" category' > > The minimum version of cairo to work being 1.11.2. On closer examination, the > official bundle (http://www.rforge.net/Cairo/files/cairo-current-win.tar.gz) > is built with neither fontconfig nor freetype. So even if it is bumped to > current version (1.12.x), it does not work correctly. > That is not "the official bundle" - that is merely a convenience binary for the Cairo package (not to be confused with cairo back-end in R) for users that don't have cairographics installed on their system. I don't think that CRAN uses this for R builds. > Perhaps also wasn't clear in the bugzilla thread - everybody from > fontconfig/cairo/freetype involved knew it being the issue so it has never > been explicitly spelled out - the problem was (is) with cairo's pdf/ps > generation, aided by freetype. > But then why would even the old binary in the Cairo package be an issue? It uses Win32 API, not freetype. Cheers, Simon >> -- >> On Sat, Mar 30, 2013 18:54 GMT Simon Urbanek wrote: >> >>> On Mar 30, 2013, at 9:24 AM, Hin-Tak Leung wrote: >>> Perhaps that's too much details. There is (will be) >> a new freetype because of cairo's unanticipated usage (which >> R uses, among other cairo users). Most people should upgrade >> or request an upgrade eventually, when they are >> comfortable. >>> >>> Which versions are affected? R binary for OS X uses >> freetype 2.4.11 (and cairo 1.12.14) so I just need to know >> if there is an action item. >>> >>> Thanks, >>> SImon >>> >>> >>> --- On Sat, 30/3/13, peter dalgaard >> wrote: Huh? This is utterly incomprehensible without reading >> the redhat bugzilla, and even after reading, I'm not sure what >> the issue is. Something with bold Chinese fonts in X11, >> but maybe also affecting Latin fonts, ? Please explain yourself. -pd On Mar 30, 2013, at 09:25 , Hin-Tak Leung wrote: > The problem was first seen with R/Sweave (#c0) >> then reproduced directly with cairo (#c10) and was >> eventually traced to freetype. The 5-part bug fix: > 610ee58e07090ead529849b2a454bb6c503b4995 > da11e5e7647b668dee46fd0418ea5ecbc33ae3b2 > e1a2ac1900f2f16ec48fb4840a6b7965a8373c2b > 869fb8c49ddf292d6daf4826172a308973d3e11f > d56e544d653b09c657911629557ffc5277a503e3 > was committed to freetype in January and will >> form the next release (2.4.12). They were back ported to >> 2.4.11 > https://bugzilla.redhat.com/show_bug.cgi?id=891457#c35 > and the redhat people had further back-ported >> it to 2.4.10 for fedora 18/19 (#c51). > > The freetype people had reproduced the problem >> with a latin font, so this affects most people, unlike >> what the initial report (#c0) suggests. > > Since freetype is part of X11, most unix/linux >> users would be understandably nervous about breaking X >> (see #c45 for screenshot of broken gnome terminal!) and >> should wait up to a year before the new and not-yet-released >> 2.4.12 becomes an official upgrade; or contact their favourite >> unix vendors and/or Apple for upgrades. AFAIK, current >> up-to-date linux distributions ships the rather older 2.4.10, with >> the exception of fedora 18/19 (#c51). Mac OS X 10.5 >> ships freetype 2.3.5 as part of X11; I haven't bother >> looking up later Mac OS X's. > > The official R binaries for windows and mac OS >> X are compiled against static libraries of cairo 1.10.2 >> (over 2 years old), and cairo 1.11.2 and freetype 2.4.4 respectively, and are firmly in the "do not work >> correctly" category. > > The long and short of the story is that >> R/Sweave uses a feature of cairo which wasn't implemented before >> cairo 1.11.2 (#c13, Jan 2011), which in turn depends on a >> feature of freetype that has been around since 2005 but did >> not anticipate cairo's usage. It is commendable that >> the freetype people did not refer to cairo's usage as >> "misuse" but took the patience to address the problem, >> unlike some group's style. > > It has been an interesting few months returning >> to freetype after about 17 years, I think. > > Here is how to look up what version of freetype >> - libfreetype.so.x.y.z for most unix platforms, and /usr/X11/lib/libfreetype.x.y.z.dylib on Mac OS X: > > (excerpt from docs/VERSION.DLL) > > version x.y.z date of
[Rd] Timing of SET_VECTOR_ELT
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 = REAL(means2); PROTECT(u2 = allocVector(REALSXP, nvar)); u = REAL(u2); PROTECT(loglik2 = allocVector(REALSXP, 2)); loglik = REAL(loglik2); PROTECT(rlist = mknamed(VECSXP, outnames)); Can I assign the individual elements into rlist using SET_VECTOR_ELT at this point, or do I need to wait until the end of the program, after I've filled in means[i], u[i], etc.? I likely depends on whether I'm assigning a pointer or a copy. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timing of SET_VECTOR_ELT
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.) > >PROTECT(means2 = allocVector(REALSXP, nvar)); >means = REAL(means2); >PROTECT(u2 = allocVector(REALSXP, nvar)); >u = REAL(u2); >PROTECT(loglik2 = allocVector(REALSXP, 2)); >loglik = REAL(loglik2); > >PROTECT(rlist = mknamed(VECSXP, outnames)); > > Can I assign the individual elements into rlist using SET_VECTOR_ELT at this > point, or do I need to wait until the end of the program, after I've filled > in means[i], u[i], etc.? I likely depends on whether I'm assigning a pointer > or a copy. > You're assigning a pointer, so it doesn't matter. FWIW, you can avoid all the PROTECTion mess if you alloc+assign, e.g. SEXP rlist = PROTECT(mknamed(VECSXP, outnames)); SEXP means = SET_VECTOR_ELT(rlist, 0, allocVector(REALSXP, nvar)); ... since you only need to protect the parent object. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timing of SET_VECTOR_ELT
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.) PROTECT(means2 = allocVector(REALSXP, nvar)); means = REAL(means2); PROTECT(u2 = allocVector(REALSXP, nvar)); u = REAL(u2); PROTECT(loglik2 = allocVector(REALSXP, 2)); loglik = REAL(loglik2); PROTECT(rlist = mknamed(VECSXP, outnames)); Can I assign the individual elements into rlist using SET_VECTOR_ELT at this point, or do I need to wait until the end of the program, after I've filled in means[i], u[i], etc.? I likely depends on whether I'm assigning a pointer or a copy. You could assign them at this point, but only if you're sure the pointers won't change. You might change the pointers if you reallocate a vector to lengthen it or shorten it, for example. Generally speaking this won't happen behind your back, but you might forget and do it in the future when you modify the function, so I'd say it's safer to wait until the last minute to put the pointers in the list. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timing of SET_VECTOR_ELT
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 "xyz" for the pointer to its contents.) PROTECT(means2 = allocVector(REALSXP, nvar)); means = REAL(means2); PROTECT(u2 = allocVector(REALSXP, nvar)); u = REAL(u2); PROTECT(loglik2 = allocVector(REALSXP, 2)); loglik = REAL(loglik2); PROTECT(rlist = mknamed(VECSXP, outnames)); Can I assign the individual elements into rlist using SET_VECTOR_ELT at this point, or do I need to wait until the end of the program, after I've filled in means[i], u[i], etc.? I likely depends on whether I'm assigning a pointer or a copy. You're assigning a pointer, so it doesn't matter. FWIW, you can avoid all the PROTECTion mess if you alloc+assign, e.g. SEXP rlist = PROTECT(mknamed(VECSXP, outnames)); SEXP means = SET_VECTOR_ELT(rlist, 0, allocVector(REALSXP, nvar)); ... since you only need to protect the parent object. Cheers, Simon Neat trick. I take it that SET_VECTOR_ELT returns a pointer to the object that was just created? I haven't found a description of the function in any of the documents, only examples of its use, so this is a surprise to me. Lacking documentation, can I count on it in the future? Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timing of SET_VECTOR_ELT
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 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 = REAL(means2); >>>PROTECT(u2 = allocVector(REALSXP, nvar)); >>>u = REAL(u2); >>>PROTECT(loglik2 = allocVector(REALSXP, 2)); >>>loglik = REAL(loglik2); >>> >>>PROTECT(rlist = mknamed(VECSXP, outnames)); >>> >>> Can I assign the individual elements into rlist using SET_VECTOR_ELT at >>> this point, or do I need to wait until the end of the program, after I've >>> filled in means[i], u[i], etc.? I likely depends on whether I'm assigning >>> a pointer or a copy. >>> >> You're assigning a pointer, so it doesn't matter. >> >> FWIW, you can avoid all the PROTECTion mess if you alloc+assign, e.g. >> >> SEXP rlist = PROTECT(mknamed(VECSXP, outnames)); >> SEXP means = SET_VECTOR_ELT(rlist, 0, allocVector(REALSXP, nvar)); >> ... >> >> since you only need to protect the parent object. >> >> Cheers, >> Simon > Neat trick. I take it that SET_VECTOR_ELT returns a pointer to the object > that was just created? I haven't found a description of the function in any > of the documents, only examples of its use, so this is a surprise to me. > Lacking documentation, can I count on it in the future? > Well, it's a pretty fundamental function, so if its behavior changed, the whole world would collapse ;) so if you can't rely on SET_VECTOR_ELT then I don't know what else you can rely on. Its return value is also used in R itself, so it's not an obscure use. It may look a bit scary as the upper-case may suggest it's a macro, but R-exts clarifies that it is a function so the above is ok (and it's frequently used with allocations in R itself). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
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 which.max for a class (I've defined both S3 and S4 methods for the class "BFBayesFactor") in my package. I've exported the S4 class using exportMethods, and declared the S3 method with S3method. You can see the NAMESPACE file here: https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl and the methods here: https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl I have code in a vignette that calls the which.max method on a BFBayesFactor object. However, when that happens as the vignette is being compiled, I get an error: which.max(bf) ## Error: no method for coercing this S4 class to a vector This also occurs with which.min, but oddly not any other method (including the is.na method, which is declared exactly the same way, as far as I can tell). This seems to imply that the which.min and which.max methods are not exported. When I use double colon notation - which as I understand, only works with exported functions - it works (see below). When I compile the Rmd file manually, I do not see this problem; I get no errors. This seems to be a problem unique to compiling the vignette. I've tried it in Rstudio, R from the command line, and using Rscript and calling knitr directly. It only occurs when building a vignette for the source package. Steps to reproduce: 1. Check out latest version of BayesFactor package from R-forge (https://r-forge.r-project.org/scm/?group_id=554) (revision 320) 2. Create a source package (which compiles the vignette) 3. Open tar to see compiled vignette HTML (doc/manual.html - or, alternatively, see https://www.dropbox.com/s/6csznytp8i1akjl/manual.html). Search for second occurrence of "which.max", and see the following lines: ## which model index is the best? is(bf, "BFBayesFactor") ## [1] TRUE BayesFactor::which.max(bf) ## complaints ## 1 BayesFactor::which.min(bf) ## critical + advance ## 21 which.max(bf) ## Error: no method for coercing this S4 class to a vector which.min(bf) ## Error: no method for coercing this S4 class to a vector I've been pulling my hair out on this, especially because something seems to have changed over the past few weeks that caused this, but I didn't catch exactly when, and I don't know if the issue lies with R 3.0.0 or my package. > sessionInfo() R version 3.0.0 RC (2013-03-31 r62463) Platform: x86_64-apple-darwin10.8.0 (64-bit) locale: [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] BayesFactor_0.9.5 markdown_0.5.4 knitr_1.1.6 coda_0.16-1 lattice_0.20-15 loaded via a namespace (and not attached): [1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0 mvtnorm_0.9-9994 [6] pbapply_1.0-5 stringr_0.6.2 tools_3.0.0 Any help would be greatly appreciated, Richard __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
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 builds vignettes (cf. tools::buildVignettes()).
As you'll see, it reproduces your error:
if (!exists("buildVignette", mode="function")) {
source("http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R.rsp/R/buildVignette.R?root=r-dots";);
}
EXAMPLE (in a fresh R session):
url <-
"http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/BayesFactorPCL/vignettes/manual.Rmd?root=bayesfactorpcl";
if (!file.exists("manual.Rmd")) download.file(url, "manual.Rmd");
output <- buildVignette("manual.Rmd", buildPkg="knitr");
browseURL(output);
bfr <- readLines(output);
idxs <- grep("which.max(bf)", bfr, fixed=TRUE);
idxs <- sort(sapply(idxs, FUN=function(idx) idx+(-5:5)));
cat(sprintf("%03d: %s\n", idxs, bfr[idxs]));
> cat(sprintf("%03d: %s", idxs, bfr[idxs]), sep="\n")
2517:
2518:
2519: ## [1] TRUE
2520:
2521:
2522: BayesFactor::which.max(bf)
2523:
2524:
2525: ## complaints
2526: ## 1
2527:
2531:
2532: ## critical + advance
2533: ## 21
2534:
2535:
2536: which.max(bf)
2537:
2538:
2539: ## Error: no method for coercing this S4 class to a vector
2540:
2541:
So, have a look at browseVignette() and how it calls the 'knitr' weave
function. That should help you narrow down what's going on.
> sessionInfo()
R version 3.0.0 RC (2013-03-31 r62463)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] BayesFactor_0.9.3 markdown_0.5.4coda_0.16-1 lattice_0.20-15
[5] knitr_1.1.7
loaded via a namespace (and not attached):
[1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0
[5] mvtnorm_0.9-9994 pbapply_1.0-5stringr_0.6.2
Hope this helps
/Henrik
On Mon, Apr 1, 2013 at 4:52 PM, Richard D. Morey wrote:
> 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 which.max for a class (I've defined
> both S3 and S4 methods for the class "BFBayesFactor") in my package. I've
> exported the S4 class using exportMethods, and declared the S3 method with
> S3method. You can see the NAMESPACE file here:
>
> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl
>
> and the methods here:
>
> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl
>
> I have code in a vignette that calls the which.max method on a BFBayesFactor
> object. However, when that happens as the vignette is being compiled, I get
> an error:
>
> which.max(bf)
> ## Error: no method for coercing this S4 class to a vector
>
>
>
> This also occurs with which.min, but oddly not any other method (including
> the is.na method, which is declared exactly the same way, as far as I can
> tell). This seems to imply that the which.min and which.max methods are not
> exported.
>
> When I use double colon notation - which as I understand, only works with
> exported functions - it works (see below).
>
> When I compile the Rmd file manually, I do not see this problem; I get no
> errors. This seems to be a problem unique to compiling the vignette. I've
> tried it in Rstudio, R from the command line, and using Rscript and calling
> knitr directly. It only occurs when building a vignette for the source
> package.
>
> Steps to reproduce:
> 1. Check out latest version of BayesFactor package from R-forge
> (https://r-forge.r-project.org/scm/?group_id=554) (revision 320)
>
> 2. Create a source package (which compiles the vignette)
>
> 3. Open tar to see compiled vignette HTML (doc/manual.html - or,
> alternatively, see https://www.dropbox.com/s/6csznytp8i1akjl/manual.html).
> Search for second occurrence of "which.max", and see the following lines:
>
> ## which model index is the best?
> is(bf, "BFBayesFactor")
> ## [1] TRUE
> BayesFactor::which.max(bf)
> ## complaints
> ## 1
> BayesFactor::which.min(bf)
> ## critical + advance
> ## 21
> which.max(bf)
> ## Error: no method for coercing this S4 class to a vector
> which.min(bf)
> ## Error: no method for coercing this S4 class to a vector
>
>
>
> I've been pulling my hair out on this, especially because something seems to
> have changed over the past few weeks that caused this, but I didn't c
Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
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 buildVignette(), which emulates
what R does when it builds vignettes (cf. tools::buildVignettes()).
As you'll see, it reproduces your error:
Maybe to further move this along, the vignette can be replaced with
```{r}
library(BayesFactor)
which.min
```
and built with
tools:::buildVignettes(dir="~/tmp/pkg/BayesFactorPCL/")
and the output shows that which.min is not the expected S4 generic.
BayesFactorPCL/vignettes$ tail manual.html
## function (x)
## .Internal(which.min(x))
##
This contrasts with, e.g.,
R -e "knitr::knit2html('~/tmp/pkg/BayesFactorPCL/vignettes/manual.Rmd')"
which gives
BayesFactorPCL/vignettes$ tail manual.html
## function (x)
## standardGeneric("which.min")
##
## Methods may be defined for arguments: x
## Use showMethods("which.min") for currently available ones.
One (or two) other minor points -- which.min / which.max are _not_ S3 generics,
so I'm not sure it makes sense to define / export S3 methods. The implicit
generics which.min / which.max need to be documented.
Martin
if (!exists("buildVignette", mode="function")) {
source("http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R.rsp/R/buildVignette.R?root=r-dots";);
}
EXAMPLE (in a fresh R session):
url <-
"http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/BayesFactorPCL/vignettes/manual.Rmd?root=bayesfactorpcl";
if (!file.exists("manual.Rmd")) download.file(url, "manual.Rmd");
output <- buildVignette("manual.Rmd", buildPkg="knitr");
browseURL(output);
bfr <- readLines(output);
idxs <- grep("which.max(bf)", bfr, fixed=TRUE);
idxs <- sort(sapply(idxs, FUN=function(idx) idx+(-5:5)));
cat(sprintf("%03d: %s\n", idxs, bfr[idxs]));
cat(sprintf("%03d: %s", idxs, bfr[idxs]), sep="\n")
2517:
2518:
2519: ## [1] TRUE
2520:
2521:
2522: BayesFactor::which.max(bf)
2523:
2524:
2525: ## complaints
2526: ## 1
2527:
2531:
2532: ## critical + advance
2533: ## 21
2534:
2535:
2536: which.max(bf)
2537:
2538:
2539: ## Error: no method for coercing this S4 class to a vector
2540:
2541:
So, have a look at browseVignette() and how it calls the 'knitr' weave
function. That should help you narrow down what's going on.
sessionInfo()
R version 3.0.0 RC (2013-03-31 r62463)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] BayesFactor_0.9.3 markdown_0.5.4coda_0.16-1 lattice_0.20-15
[5] knitr_1.1.7
loaded via a namespace (and not attached):
[1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0
[5] mvtnorm_0.9-9994 pbapply_1.0-5stringr_0.6.2
Hope this helps
/Henrik
On Mon, Apr 1, 2013 at 4:52 PM, Richard D. Morey wrote:
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 which.max for a class (I've defined both S3 and
S4 methods for the class "BFBayesFactor") in my package. I've exported the S4
class using exportMethods, and declared the S3 method with S3method. You can see the
NAMESPACE file here:
https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl
and the methods here:
https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl
I have code in a vignette that calls the which.max method on a BFBayesFactor
object. However, when that happens as the vignette is being compiled, I get an
error:
which.max(bf)
## Error: no method for coercing this S4 class to a vector
This also occurs with which.min, but oddly not any other method (including the
is.na method, which is declared exactly the same way, as far as I can tell).
This seems to imply that the which.min and which.max methods are not exported.
When I use double colon notation - which as I understand, only works with
exported functions - it works (see below).
When I compile the Rmd file manually, I do not see this problem; I get no
errors. This seems to be a problem unique to compiling the vignette. I've tried
it in Rstudio, R from the command line, and using Rscript and calling knitr
directly. It only occurs when building a vignette for the source package.
St
Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
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 builder.
Now I have forced the evaluation to be in the global environment, and
pushed the changes to the knitr development version on Github:
https://github.com/yihui/knitr
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Mon, Apr 1, 2013 at 7: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 buildVignette(), which emulates
> what R does when it builds vignettes (cf. tools::buildVignettes()).
> As you'll see, it reproduces your error:
>
> if (!exists("buildVignette", mode="function")) {
>
> source("http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R.rsp/R/buildVignette.R?root=r-dots";);
> }
>
> EXAMPLE (in a fresh R session):
>
> url <-
> "http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/BayesFactorPCL/vignettes/manual.Rmd?root=bayesfactorpcl";
> if (!file.exists("manual.Rmd")) download.file(url, "manual.Rmd");
>
> output <- buildVignette("manual.Rmd", buildPkg="knitr");
> browseURL(output);
>
> bfr <- readLines(output);
> idxs <- grep("which.max(bf)", bfr, fixed=TRUE);
> idxs <- sort(sapply(idxs, FUN=function(idx) idx+(-5:5)));
> cat(sprintf("%03d: %s\n", idxs, bfr[idxs]));
>
>> cat(sprintf("%03d: %s", idxs, bfr[idxs]), sep="\n")
> 2517:
> 2518:
> 2519: ## [1] TRUE
> 2520:
> 2521:
> 2522: BayesFactor::which.max(bf)
> 2523:
> 2524:
> 2525: ## complaints
> 2526: ## 1
> 2527:
> 2531:
> 2532: ## critical + advance
> 2533: ## 21
> 2534:
> 2535:
> 2536: which.max(bf)
> 2537:
> 2538:
> 2539: ## Error: no method for coercing this S4 class to a vector
> 2540:
> 2541:
>
> So, have a look at browseVignette() and how it calls the 'knitr' weave
> function. That should help you narrow down what's going on.
>
>> sessionInfo()
> R version 3.0.0 RC (2013-03-31 r62463)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] tools stats graphics grDevices utils datasets methods
> [8] base
>
> other attached packages:
> [1] BayesFactor_0.9.3 markdown_0.5.4coda_0.16-1 lattice_0.20-15
> [5] knitr_1.1.7
>
> loaded via a namespace (and not attached):
> [1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0
> [5] mvtnorm_0.9-9994 pbapply_1.0-5stringr_0.6.2
>
> Hope this helps
>
> /Henrik
>
> On Mon, Apr 1, 2013 at 4:52 PM, Richard D. Morey wrote:
>> 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 which.max for a class (I've defined
>> both S3 and S4 methods for the class "BFBayesFactor") in my package. I've
>> exported the S4 class using exportMethods, and declared the S3 method with
>> S3method. You can see the NAMESPACE file here:
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl
>>
>> and the methods here:
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl
>>
>> I have code in a vignette that calls the which.max method on a BFBayesFactor
>> object. However, when that happens as the vignette is being compiled, I get
>> an error:
>>
>> which.max(bf)
>> ## Error: no method for coercing this S4 class to a vector
>>
>>
>>
>> This also occurs with which.min, but oddly not any other method (including
>> the is.na method, which is declared exactly the same way, as far as I can
>> tell). This seems to imply that the which.min and which.max methods are not
>> exported.
>>
>> When I use double colon notation - which as I understand, only works with
>> exported functions - it works (see below).
>>
>> When I compile the Rmd file manually, I do not see this problem; I get no
>> errors. This seems to be a problem unique to compiling the vignette. I've
>> tried it in Rstudio, R from the command line, and using Rscript and calling
>> knitr directly. It only occurs when building a vignette for the source
>> package.
>>
>> Steps to reproduce:
>> 1. Check out latest version of BayesFactor pack
