Re: [Rd] Undocumented S4 method Warning For Bracket
On 12/05/2013 07:00 PM, Dario Strbenac wrote:
Hello,
With R version 3.0.2 Patched (2013-10-30 r64123) I don't see warnings that I
get in R Under development (unstable) (2013-11-03 r64145)
The warnings are like :
Undocumented S4 methods:
generic '[' and siglist 'BayMethList,ANY,ANY'
The function actually looks like :
setMethod("[", "BayMethList",
function(x, i) {
# Code to subset object.
}
It has 2 parameters, not 3. The warning also happens in R 3.0.2 Release. Has
this been fixed in Patched but not in the development version ?
Not a complete answer but actually the generic is
> getGeneric("[")
standardGeneric for "[" defined from package "base"
function (x, i, j, ..., drop = TRUE)
standardGeneric("[", .Primitive("["))
Methods may be defined for arguments: x, i, j, drop
Use showMethods("[") for currently available ones.
and the fact that you've implemented a simpler method signature doesn't change
the overall signature
> getMethod("[", "BayMethList")
Method Definition:
function (x, i, j, ..., drop = TRUE)
{
.local <- function (x, i)
{
}
.local(x, i, ...)
}
Signatures:
x
target "BayMethList"
defined "BayMethList"
Notice how your method actually accepts and then silently ignores a 'j'
argument. A better (?) method definition would be
setMethod("[", c("BayMethList", "ANY", "missing"),
function(x, i, j, ..., drop=TRUE) {})
so a user providing a 'j' argument would be told that there was no matching
method.
Martin
--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strategies for keeping autogenerated .Rd files out of a Git tree
Hi Quite a few R packages are now available on GitHub long before they appear on CRAN, installation is simple thanks to devtools::install_github(). However, it seems to be common practice to keep the .Rd files (and NAMESPACE and the Collate section in the DESCRIPTION) in the Git tree, and to manually update it, even if they are autogenerated from the R code by roxygen2. This requires extra work for each update of the documentation and also binds package development to a specific version of roxygen2 (because otherwise lots of bogus changes can be added by roxygenizing with a different version). What options are there to generate the .Rd files during build/install? In https://github.com/hadley/devtools/issues/43 the issue has been discussed, perhaps it can be summarized as follows: - The devtools package is not the right place to implement roxygenize-before-build - A continuous integration service would be better for that, but currently there's nothing that would be easy to use - Roxygenizing via src/Makefile could work but requires further investigation and an installation of Rtools/xcode on Windows/OS X Especially the last point looks interesting to me, but since this is not widely used there must be pitfalls I'm not aware of. The general idea would be: - Place code that builds/updates the .Rd and NAMESPACE files into src/Makefile - Users installing the package from source will require infrastructure (Rtools/make) - For binary packages, the .Rd files are already generated and added to the .tar.gz during R CMD build before they are submitted to CRAN/WinBuilder, and they are also generated (in theory) by R CMD build --binary I'd like to hear your opinion on that. I have also found a thread on package development workflow (https://stat.ethz.ch/pipermail/r-devel/2011-September/061955.html) but there was nothing on un-versioning .Rd files. Cheers Kirill __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strategies for keeping autogenerated .Rd files out of a Git tree
Hi, this is maybe mostly a personal preference, but I prefer not to put generated files in the vc repository. Changes in the generated files, especially if there is many of them, pollute the diffs and make them less useful. If you really want to be able to install the package directly from github, one solution is to 1. create another repository, that contains the complete generated package, so that install_github() can install it. 2. set up a CI service, that can download the package from github, build the package or the generated files (check the package, while it is at it), and then push the build stuff back to github. 3. set up a hook on github, that invokes the CI after each commit. I have used this setup in various projects with jenkins-ci and it works well. Diffs are clean, the package is checked and built frequently, and people can download it without having to install the tools that generate the generated files. The only downside is that you need to install a CI, so you need a "server" for that. Maybe you can do this with travis-ci, maybe not, I am not familiar with it that much. Best, Gabor On Wed, Dec 11, 2013 at 7:39 PM, Kirill Müller wrote: > Hi > > Quite a few R packages are now available on GitHub long before they appear > on CRAN, installation is simple thanks to devtools::install_github(). > However, it seems to be common practice to keep the .Rd files (and NAMESPACE > and the Collate section in the DESCRIPTION) in the Git tree, and to manually > update it, even if they are autogenerated from the R code by roxygen2. This > requires extra work for each update of the documentation and also binds > package development to a specific version of roxygen2 (because otherwise > lots of bogus changes can be added by roxygenizing with a different > version). > > What options are there to generate the .Rd files during build/install? In > https://github.com/hadley/devtools/issues/43 the issue has been discussed, > perhaps it can be summarized as follows: > > - The devtools package is not the right place to implement > roxygenize-before-build > - A continuous integration service would be better for that, but currently > there's nothing that would be easy to use > - Roxygenizing via src/Makefile could work but requires further > investigation and an installation of Rtools/xcode on Windows/OS X > > Especially the last point looks interesting to me, but since this is not > widely used there must be pitfalls I'm not aware of. The general idea would > be: > > - Place code that builds/updates the .Rd and NAMESPACE files into > src/Makefile > - Users installing the package from source will require infrastructure > (Rtools/make) > - For binary packages, the .Rd files are already generated and added to the > .tar.gz during R CMD build before they are submitted to CRAN/WinBuilder, and > they are also generated (in theory) by R CMD build --binary > > I'd like to hear your opinion on that. I have also found a thread on package > development workflow > (https://stat.ethz.ch/pipermail/r-devel/2011-September/061955.html) but > there was nothing on un-versioning .Rd files. > > > Cheers > > Kirill > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] freetype 2.5.2, problem with the survival package, build R 2.15.x with gcc 4.8.x
Here is a rather long discussion etc about freetype 2.5.2, problem with the survival package, and build R 2.15.x with gcc 4.8.x. Please feel free to skip forward. - freetype 2.5.2: the fix to cope with one of the Mac OS X's system fonts just before the release of freetype 2.5.1 caused a regression, crashing over one of Microsoft windows' system fonts. So there is a 2.5.2. There are new 2.5.2 bundles for windows & Mac OS X. The official win/mac binaries of R were built statically with 2+-years-old freetype with a few known problems. Most should upgrade/rebuild. http://sourceforge.net/projects/outmodedbonsai/files/R/ - problem with the survival package: Trying to re-run a vignette to get the same result as two years ago reveal a strange change. I went and bisected it down to r11513 and r11516 of the survival package. -- r11513 clogit(cc ~ addContr(A) + addContr(C) + addContr(A.C) + strata(set)) coef exp(coef) se(coef) z p addContr(A)2 -0.620 0.5380.217 -2.86 0.0043 addContr(C)2 0.482 1.6200.217 2.22 0.0270 addContr(A.C)1-2 -0.778 0.4590.275 -2.83 0.0047 addContr(A.C)2-1 NANA0.000NA NA addContr(A.C)2-2 NANA0.000NA NA Likelihood ratio test=26 on 3 df, p=9.49e-06 n= 13110, number of events= 3524 -- - r11516 - clogit(cc ~ addContr(A) + addContr(C) + addContr(A.C) + strata(set)) coef exp(coef) se(coef) z p addContr(A)2 -0.14250 0.867 110812 -1.29e-06 1 addContr(C)2 0.00525 1.005 110812 4.74e-08 1 addContr(A.C)1-2 -0.30097 0.740 110812 -2.72e-06 1 addContr(A.C)2-1 -0.47712 0.621 110812 -4.31e-06 1 addContr(A.C)2-2 NANA0NA NA Likelihood ratio test=26 on 4 df, p=3.15e-05 n= 13110, number of events= 3524 -- r11514 does not build, and r11515 have serious memory hogs, so the survival package broke somewhere between r11513 and r11516. Anyway, here is the diff in the vignette, and the data, etc is in the directory above. If somebody want to fix this before I spend any more time on this particular matter, please feel free to do so. http://sourceforge.net/projects/outmodedbonsai/files/Manuals%2C%20Overviews%20and%20Slides%20for%20talks/2013SummerCourse/practicals/with-answers/practical8_survival-clogit-diff.pdf/download That's the one problem from David's 10 practicals which are not due to bugs in snpStats. Some might find it reassuring that only 3 of the 4 problems with the practicals are due to snpStats bugs. http://sourceforge.net/projects/outmodedbonsai/files/Manuals%2C%20Overviews%20and%20Slides%20for%20talks/2013SummerCourse/practicals/with-answers/practical7_snpStatsBug-diff.pdf/download http://sourceforge.net/projects/outmodedbonsai/files/Manuals%2C%20Overviews%20and%20Slides%20for%20talks/2013SummerCourse/practicals/with-answers/practical6_snpStatsBug-diff.pdf/download http://sourceforge.net/projects/outmodedbonsai/files/Manuals%2C%20Overviews%20and%20Slides%20for%20talks/2013SummerCourse/practicals/with-answers/practical3_snpStatsBug-diff.pdf/download - build R 2.15.x with gcc 4.8.x I wish the R commit log was a bit more detailed with r62430 than just "tweak needed for gcc 4.8.x". Anyway, building R 2.15.x with gcc 4.8.x could result in segfaults in usage as innocent and essential as running summary() on a data.frame: *** caught segfault *** address 0x2f8e6a00, cause 'memory not mapped' Traceback: 1: sort.list(y) 2: factor(a, exclude = exclude) 3: table(object, exclude = NULL) 4: summary.default(X[[3L]], ...) 5: FUN(X[[3L]], ...) 6: lapply(X = as.list(object), FUN = summary, maxsum = maxsum, digits = 12, ...) 7: summary.data.frame(support) ... r62430 needs a bit of adapting to apply to R 2.15.x , but you get the idea. I hope this info is useful to somebody else who is still using R 2.15.x , no doubt for very good reasons. Hin-Tak Leung wrote: The freetype people fixed the 2nd set of issues with system fonts shipped with Mac OS X, and released 2.5.1 almost immediately after that. So there are new bundles under http://sourceforge.net/projects/outmodedbonsai/files/R/ . Just a reminder that the official R binaries for windows/mac OS X are statically linked with rather dated versions of freetype with a few known issues. This affects the cairo-based functionalities in R. So a rebuild is needed. Most unix users should just upgrade their system's libfreetype, and dynamic-linking should take care of the rest. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD INSTALL may create invalid DLL under Windows
Under Windows the make include share/make/winshlib.mk uses nm to grab symbols from object files to insert into a module definition file tmp.def that is used to create a package DLL. This works fine provided the DLL is only used via exported function entry points, which is the case currently, I suspect. But the pattern SYMPAT (defined in Makeconf) used to capture symbols includes non-function symbols of type's BCDR, not just T (.text or code). These symbols need to be flagged in the module definition file by adding the string DATA after the symbol name. If this is not done then a client of this DLL (another DLL or a main program) will not be able to import these variables correctly (using dllexport/dllimport decorations is another less convenient strategy). I have checked this with gcc 4.6.3 (shipped with Rtools), and also with gcc 4.8.1 (MinGW). In both cases if the value of a simple 'int' is fetched from a DLL where the int is exported without the DATA keyword, the result is garbage, and inserting the DATA keyword fixes the problem. Thus the fix here is very simple. Just modify winshlib.mk so that the DATA flag follows non-function symbols. Alternatively, only function symbols can be captured, in which case only SYMPAT needs to change. Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
