[Bioc-devel] IMPORTANT inst/doc/*Rnw to vignettes/
Hi Martin,
Thanks for the heads-up. I think I've made the changes necessary, but am
having trouble confirming whether the changes are correct on a Windows
machine.
Could you tell me hows Bioconductor builds the Windows binaries of
Bioconductor packages?
To see how things work, I am playing around with Biobase on svn. I can
build Biobase from the svn source including the pdfs of the vignettes
using
R CMD build Biobase
on my Windows machine. This gives me a tar.gz file of Biobase with an
inst/doc directory containing Rnws and pdfs of all the vignettes. This
shows that my LaTeX etc is working fine.
However when I run
R CMD INSTALL --build Biobase
which is the recommended way to install a package under Windows, I get a
zip file containing no sign of any vignette. In fact there is no doc or
inst or vignette directory in the zip file.
What else do I need to do to install the package from source with the
vignettes build under Windows?
No doubt the answer is somewhere in one of the R manuals (writing R
extensions or admin and installation perhaps) but I cannot find it.
Thanks
Gordon
PS. I am running Rtools3.1 with:
sessionInfo()
R Under development (unstable) (2013-10-18 r64076)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_Australia.1252
[2] LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] parallel stats graphics grDevices utils
[6] datasets methods base
other attached packages:
[1] Biobase_2.23.1 BiocGenerics_0.9.0
Date: Fri, 18 Oct 2013 14:58:52 -0700
From: Martin Morgan mtmor...@fhcrc.org
To: bioc-devel@r-project.org bioc-devel@r-project.org
Subject: [Bioc-devel] IMPORTANT inst/doc/*Rnw to vignettes/
Bioconductor developers,
Thank you for your contributions to our last release, with a total of 749
packages! This is a great resource for the bioninformatics community.
No good deed goes unpunished. The 'devel' version of R no longer builds
vignettes in the inst/doc directory. Vignette sources (.Rnw or perhaps .Rmd
files) must be in the vignettes/ directory. There's a lot of work to be done to
make this happen, and we'd really like your help with this. Here's one recipe
for the neccessary changes, illustrtated with Biobase
1. Find the url of your package in the devel version of the Bioconductor svn
repository, e.g., for Biobase
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/Biobase
2. Make a clean check-out of the source into a directory where `Biobase' does
not already exist
svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/Biobase
3. Re-name the inst/doc directory. Using svn rename preserves the commit history
svn rename Biobase/inst/doc Biobase/vignettes
4. Increase the least significant part of the package version number in
Biobase/DESCRIPTION. I changed Biobase from 2.23.0 to 2.23.1.
5. Build the package, using the latest devel version of R
R CMD build Biobase
6. Check that the built version contains .Rnw, .R, and .pdf files in the
inst/doc directory, e.g.,
tar tzf Biobase_2.23.1.tar.gz |grep inst/doc
7. Make sure the built package passes R CMD check
R CMD check Biobase_2.23.1.tar.gz
8. Review and check in your changes
svn st Biobase
svn diff Biobase/DESCRIPTION
svn ci
This will work for many cases, but if you have problems please do not hesitate
to bring up issues on the mailing list.
If things go smoothly, you might wish to follow the instructions in the
BiocStyle vignette
http://bioconductor.org/packages/devel/bioc/vignettes/BiocStyle/inst/doc/LatexStyle.pdf
for creating vignettes with a consistent look-and-feel. The text is wider, for
instance, so code generally formats better, and packages are easily linked to
their 'landing page' on the Bioconductor web site
Please don't hesitate to ask if there are any questions, and thanks in advance
for your continued effort to support the project.
Martin
--
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
__
The information in this email is confidential and intend...{{dropped:4}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Rd] Subversion log no longer being updated daily
The subversion log for 2013 (http://developer.r-project.org/R_svnlog_2013) on the R developer page hasn't been updated since September 29. I would appreciate the daily updates returning. Berend Hasselman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question about selective importing of package functions...
I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? --j -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
Duncan: Thanks -- learning something new today -- quick follow-up, will using the import statements in the NAMESPACE, when a user goes to install.packages(), auto-install the dependent packages the same way Depends forces? --j On Sun, Oct 20, 2013 at 3:49 PM, Duncan Murdoch murdoch.dun...@gmail.comwrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) Duncan Murdoch -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) That may answer the specific case of the poster but how does one handle the case where one wants the user to be able to access the functions in the dependent package. For example, sqldf depends on gsubfn which provides fn which is used with sqldf to perform substitutions in the SQL string. library(sqldf) tt - 3 fn$sqldf(select * from BOD where Time $tt) I don't want to ask the user to tediously issue a library(gsubfn) too since fn is frequently needed and for literally years this has not been necessary. Also I don't want to duplicate fn's code in sqldf since that makes the whole thing less modular -- it would imply having to change fn in two places if anything in fn changed. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
One more follow-up -- will I now need to include a library() statement in each function? --j On Sun, Oct 20, 2013 at 3:58 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) That may answer the specific case of the poster but how does one handle the case where one wants the user to be able to access the functions in the dependent package. For example, sqldf depends on gsubfn which provides fn which is used with sqldf to perform substitutions in the SQL string. library(sqldf) tt - 3 fn$sqldf(select * from BOD where Time $tt) I don't want to ask the user to tediously issue a library(gsubfn) too since fn is frequently needed and for literally years this has not been necessary. Also I don't want to duplicate fn's code in sqldf since that makes the whole thing less modular -- it would imply having to change fn in two places if anything in fn changed. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On 20 October 2013 at 16:20, Jonathan Greenberg wrote: | One more follow-up -- will I now need to include a library() statement in | each function? No. NAMESPACE entry, coupled with Imports: in DESCRIPTION. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
To be clear, if I used Depends: somepackage before, and switched over to using Imports: somepackage, I'll need to mod my code that used to have a call to, say, somefunction to now have somepackage::somefunction, correct? --j On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote: On 20 October 2013 at 16:20, Jonathan Greenberg wrote: | One more follow-up -- will I now need to include a library() statement in | each function? No. NAMESPACE entry, coupled with Imports: in DESCRIPTION. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On 13-10-20 4:54 PM, Jonathan Greenberg wrote: Duncan: Thanks -- learning something new today -- quick follow-up, will using the import statements in the NAMESPACE, when a user goes to install.packages(), auto-install the dependent packages the same way Depends forces? You need to list the other packages in Imports instead of Depends; then the answer is yes. Duncan Murdoch --j On Sun, Oct 20, 2013 at 3:49 PM, Duncan Murdoch murdoch.dun...@gmail.com mailto:murdoch.dun...@gmail.com wrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net mailto:spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) Duncan Murdoch -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ http://www.geog.illinois.edu/%7Ejgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com mailto:jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
Jonathan, import/importFrom directives within the NAMESPACE places the symbol(s) within your package's namespace. They are treated exactly the same as (non-exported) symbols your code defines. ~G On Sun, Oct 20, 2013 at 3:41 PM, Jonathan Greenberg j...@illinois.eduwrote: To be clear, if I used Depends: somepackage before, and switched over to using Imports: somepackage, I'll need to mod my code that used to have a call to, say, somefunction to now have somepackage::somefunction, correct? --j On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote: On 20 October 2013 at 16:20, Jonathan Greenberg wrote: | One more follow-up -- will I now need to include a library() statement in | each function? No. NAMESPACE entry, coupled with Imports: in DESCRIPTION. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On 13-10-20 6:41 PM, Jonathan Greenberg wrote: To be clear, if I used Depends: somepackage before, and switched over to using Imports: somepackage, I'll need to mod my code that used to have a call to, say, somefunction to now have somepackage::somefunction, correct? No. You need to modify both the DESCRIPTION file as you say above, and the NAMESPACE file to say what to import. Once you do that, those functions will appear to your own package functions without any prefix needed. Duncan Murdoch --j On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote: On 20 October 2013 at 16:20, Jonathan Greenberg wrote: | One more follow-up -- will I now need to include a library() statement in | each function? No. NAMESPACE entry, coupled with Imports: in DESCRIPTION. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On 13-10-20 04:58 PM, Gabor Grothendieck wrote: On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) That may answer the specific case of the poster but how does one handle the case where one wants the user to be able to access the functions in the dependent package. There are two answers to this, depending on how much of the dependent package you want to make available to the user. If you want most of that package to be available then this is the (only?) exception to the rule. From Writing R Extensions: Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available. If you really only want to make a couple of functions available then you can import and export the functions. Currently this has the unfortunate side effect that you need to document the functions, you cannot just re-direct to the documentation in the imported package, at least, I have not figured out how to do that. Paul For example, sqldf depends on gsubfn which provides fn which is used with sqldf to perform substitutions in the SQL string. library(sqldf) tt - 3 fn$sqldf(select * from BOD where Time $tt) I don't want to ask the user to tediously issue a library(gsubfn) too since fn is frequently needed and for literally years this has not been necessary. Also I don't want to duplicate fn's code in sqldf since that makes the whole thing less modular -- it would imply having to change fn in two places if anything in fn changed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parallel R expression evaluations
Jai, On Oct 19, 2013, at 1:37 AM, JaiReddy wrote: Thanks Simon. May I know how R works if two expressions come at the same time for evaluation. When I debug my case I found that issue was found with indexed values of protected items. As R is single threaded engine, I just want to know how does R behave when 2nd expression comes for parsing and evaluation even before 1st expression evaluation does complete? As I said, no API calls may be performed in parallel, that includes parsing and evaluation. Typically, R is run in a sequential loop: read, parse, eval, print so anything that is not processed is blocked until the loop is back to reading. However, given that R can be called from arbitrary front-ends, it's really up to the front-end to decide what to do - as long as it serializes the calls appropriately. Cheers, Simon Thanks Jai -- View this message in context: http://r.789695.n4.nabble.com/Parallel-R-expression-evaluations-tp4678352p4678587.html Sent from the R devel mailing list archive at Nabble.com. __ 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
Re: [Rd] Subversion log no longer being updated daily
On Oct 20, 2013, at 2:00 AM, Berend Hasselman wrote: The subversion log for 2013 (http://developer.r-project.org/R_svnlog_2013) on the R developer page hasn't been updated since September 29. I would appreciate the daily updates returning. Sorry, my bad, with all the server switching I forgot to put some pieces that Duncan was running on the new server. It should be all working now. Thanks, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subversion log no longer being updated daily
On 21-10-2013, at 03:38, Simon Urbanek simon.urba...@r-project.org wrote: On Oct 20, 2013, at 2:00 AM, Berend Hasselman wrote: The subversion log for 2013 (http://developer.r-project.org/R_svnlog_2013) on the R developer page hasn't been updated since September 29. I would appreciate the daily updates returning. Sorry, my bad, with all the server switching I forgot to put some pieces that Duncan was running on the new server. It should be all working now. Thanks. All working again. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
