Re: [Rd] RFC: 'igraph' package update and backward compatibility
On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote: > Dear R developers, > > I am seeking advice on some $subject matter. > > My package will have an update soon, that is not backward compatible > with the current version. It will likely break much of the existing > code. Many (~50) packages depend on 'igraph' and they, too, will most > probably break with the new version. > Don't forget the indirect dependencies - might be many more. One approach used by e.g. ggplot and roxygen, is to call the new package ggplot2 or roxygen2. This would not break old packages. > My intended solution is, that I create a snapshot of the current > package, under another name (igraph0), and ask package maintainers to > depend on that version. Then, after a short time, I'll update the > current igraph version. > I would rather give the new one a a new name by appending the 2 > Do you see any drawbacks of this solution? Is there some existing > practice for situations like this? Suggestions are greatly > appreciated. > Well - they require immediate action by the package maintainers. Yo could put a warning in the original iplot package, that the package is not updated any more and that a switch to iplot 2 is suggested. So no immediate action by the package maintainers is required. Cheers, Rainer > Btw. an alternative would be to ask them to depend on the exact > current version of the package. This is an easier solution, but it > won't give people the opportunity to load both versions of the package > at the same time, if they want to run their old code. > > Thank You, Best Regards, > Gabor > > -- > Gabor Csardi Dept. Statistics, Harvard University > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
Sorry - not iplot, but igraph. On Thu, Oct 20, 2011 at 9:21 AM, Rainer M Krug wrote: > > > On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote: > >> Dear R developers, >> >> I am seeking advice on some $subject matter. >> >> My package will have an update soon, that is not backward compatible >> with the current version. It will likely break much of the existing >> code. Many (~50) packages depend on 'igraph' and they, too, will most >> probably break with the new version. >> > > Don't forget the indirect dependencies - might be many more. > > One approach used by e.g. ggplot and roxygen, is to call the new package > ggplot2 or roxygen2. This would not break old packages. > > >> My intended solution is, that I create a snapshot of the current >> package, under another name (igraph0), and ask package maintainers to >> depend on that version. Then, after a short time, I'll update the >> current igraph version. >> > > I would rather give the new one a a new name by appending the 2 > > >> Do you see any drawbacks of this solution? Is there some existing >> practice for situations like this? Suggestions are greatly >> appreciated. >> > > Well - they require immediate action by the package maintainers. Yo could > put a warning in the original iplot package, that the package is not updated > any more and that a switch to iplot 2 is suggested. So no immediate action > by the package maintainers is required. > > Cheers, > > Rainer > > >> Btw. an alternative would be to ask them to depend on the exact >> current version of the package. This is an easier solution, but it >> won't give people the opportunity to load both versions of the package >> at the same time, if they want to run their old code. >> >> Thank You, Best Regards, >> Gabor >> >> -- >> Gabor Csardi Dept. Statistics, Harvard >> University >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Stellenbosch University > South Africa > > Tel : +33 - (0)9 53 10 27 44 > Cell: +33 - (0)6 85 62 59 98 > Fax (F): +33 - (0)9 58 10 27 44 > > Fax (D):+49 - (0)3 21 21 25 22 44 > > email: rai...@krugs.de > > Skype: RMkrug > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On Thu, 20 Oct 2011, Rainer M Krug wrote: On Wed, Oct 19, 2011 at 8:05 PM, G?bor Cs?rdi wrote: Dear R developers, I am seeking advice on some $subject matter. If this is intended to be a CRAN update, then really you need to ask the CRAN crew about the possible implications (and I've sent a private reply to Gábor and them). My package will have an update soon, that is not backward compatible with the current version. It will likely break much of the existing code. Many (~50) packages depend on 'igraph' and they, too, will most probably break with the new version. Don't forget the indirect dependencies - might be many more. Why would they need to change? There are indeed current 50 CRAN/BioC packages which directly depend on igraph according to tools::dependsOnPkgs(). However, there are another 12 which 'Suggests: igraph', and those might need to change. One approach used by e.g. ggplot and roxygen, is to call the new package ggplot2 or roxygen2. This would not break old packages. My intended solution is, that I create a snapshot of the current package, under another name (igraph0), and ask package maintainers to depend on that version. Then, after a short time, I'll update the current igraph version. I would rather give the new one a a new name by appending the 2 Do you see any drawbacks of this solution? Is there some existing practice for situations like this? Suggestions are greatly appreciated. Well - they require immediate action by the package maintainers. Yo could put a warning in the original iplot package, that the package is not updated any more and that a switch to iplot 2 is suggested. So no immediate action by the package maintainers is required. Cheers, Rainer Btw. an alternative would be to ask them to depend on the exact current version of the package. This is an easier solution, but it won't give people the opportunity to load both versions of the package at the same time, if they want to run their old code. Thank You, Best Regards, Gabor -- Gabor Csardi Dept. Statistics, Harvard University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
Thanks for the insight! It is indeed true that naming the new version 'igraph1' (this is a better name for the change it introduces), is optimal for the existing packages. I was a bit reluctant to do this, because of two reasons. First, igraph exists as a Python package, and a C library as well, and I was afraid that it would cause confusion for users to have different names for the different packages. I can already see the emails with people asking questions about the difference between Python igraph and R igraph1 and whether igraph1 is available for Python, etc. The second reason was that I want users to use the newer version of the package; I was afraid that most them would probably not notice that there is a new version under a different name. But this issue is neatly solved by a warning in the old package, as Rainer suggested. H, it is a hard decision. I think I'll just write an email to the maintainers of the packages in question and see how many of them responds. Maybe breaking a couple of unmaintained packages is not a huge tragedy. But of course I can see the burden for CRAN maintainers and don't want to exploit them. Thank you, Gabor On Thu, Oct 20, 2011 at 3:27 AM, Prof Brian Ripley wrote: > We've had examples of that approach (e.g. mclust02) and also of packages > becoming foo2 (e.g. ggplot2). > > The problem is > >> ask package maintainers to depend on that version. > > In our experience that takes years to achieve! I think that any solution > which requires the maintainers of 50 others to submit new versions is going > to cause a lot of work for the CRAN crew and not be very comprehensive. > > I do prefer the igraph2 route. But you also need to be aware that would > need igraph to be maintained for a long time to come: our experience with > e.g. ncdf/ncdf4 is that the maintainers simply do not change. (In the case > of ggplot, the author did not even migrate his own dependent packages!) > > I think you should assume that a high proportion of packages are not > actively maintained. > > Cc:ed to CRAN, since it is really Kurt's place to advise you what CRAN would > like. > > Brian Ripley > > On Wed, 19 Oct 2011, Gábor Csárdi wrote: > >> Dear R developers, >> >> I am seeking advice on some $subject matter. >> >> My package will have an update soon, that is not backward compatible >> with the current version. It will likely break much of the existing >> code. Many (~50) packages depend on 'igraph' and they, too, will most >> probably break with the new version. >> >> My intended solution is, that I create a snapshot of the current >> package, under another name (igraph0), and ask package maintainers to >> depend on that version. Then, after a short time, I'll update the >> current igraph version. >> >> Do you see any drawbacks of this solution? Is there some existing >> practice for situations like this? Suggestions are greatly >> appreciated. >> >> Btw. an alternative would be to ask them to depend on the exact >> current version of the package. This is an easier solution, but it >> won't give people the opportunity to load both versions of the package >> at the same time, if they want to run their old code. >> >> Thank You, Best Regards, >> Gabor >> >> -- >> Gabor Csardi Dept. Statistics, Harvard University >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 -- Gabor Csardi MTA KFKI RMKI __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
> My package will have an update soon, that is not backward compatible > with the current version. It will likely break much of the existing > code. Many (~50) packages depend on 'igraph' and they, too, will most > probably break with the new version. > > My intended solution is, that I create a snapshot of the current > package, under another name (igraph0), and ask package maintainers to > depend on that version. Then, after a short time, I'll update the > current igraph version. The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages installed, and different versions loaded simultaneously so that different packages could depend on different versions. This is what (e.g.) ruby gems do. Unfortunately this is a hard problem to solve - namespaces go some way to help, but I think there are still outstanding S3 and S4 issues. My work around of renaming packages after API breaking changes is definitely a sub-optimal fix. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On 11-10-20 10:56 AM, Hadley Wickham wrote: My package will have an update soon, that is not backward compatible with the current version. It will likely break much of the existing code. Many (~50) packages depend on 'igraph' and they, too, will most probably break with the new version. My intended solution is, that I create a snapshot of the current package, under another name (igraph0), and ask package maintainers to depend on that version. Then, after a short time, I'll update the current igraph version. The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages installed, and different versions loaded simultaneously so that different packages could depend on different versions. This is what (e.g.) ruby gems do. Unfortunately this is a hard problem to solve - namespaces go some way to help, but I think there are still outstanding S3 and S4 issues. We did have an attempt at that for some versions, but I don't think it ever achieved all of its goals, and we've dropped it. I'm not sure it would be "optimal" even if it was completely implemented. It introduces a lot of complexity. Simplicity is better, even if it is sometimes more work. My work around of renaming packages after API breaking changes is definitely a sub-optimal fix. Yes. The optimal solution would be for all the packages that use yours to update to the latest version. More work, but they end up in a better place. (Or even better, if all package writers got it right the first time :-). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
> We did have an attempt at that for some versions, but I don't think it ever
> achieved all of its goals, and we've dropped it.
Yes, I remembered it used to be possible to do versioned installs, but
I don't think you could ever have them loaded simultaneously.
> I'm not sure it would be "optimal" even if it was completely implemented.
> It introduces a lot of complexity. Simplicity is better, even if it is
> sometimes more work.
But the current simplicity also makes more work - each time a new
package is uploaded to CRAN all dependencies need to be rechecked.
That would not be the case if packages could specify versioned
dependencies.
Another problem that I face is that I often release a new version of
plyr at the same time as a new version of ggplot2. The new version of
ggplot2 requires the latest version of plyr, but
install.packages("ggplot2") will not reinstall plyr if it is present
but an outdated version. Dependencies are checked at build time, but
not install time.
>> My work around of renaming packages after API breaking changes is
>> definitely a sub-optimal fix.
>
> Yes. The optimal solution would be for all the packages that use yours to
> update to the latest version. More work, but they end up in a better place.
> (Or even better, if all package writers got it right the first time :-).
The problem is not just packages, but reproducible code in general.
As it stands currently, to make sure a script continues to work in the
long run you need a library containing the versions of the packages
you used at the time. It would be a little easier if you could do
library("ggplot2", version = 0.85) or similar. (Ignoring the other
difficulties of capturing the current version of R, other system
libraries, OS, hardware etc).
Generally, the absence of versioned dependencies makes it extremely
difficult to aggressively improve the design of a package. You are
locked into your first attempt at an API because it is so difficult
for users to work with the non-latest version. Namespaces help with
this a little (by not exporting experimental functions), but I find
there are many initial design decisions that I now regret in ggplot2,
and I can not easily remedy them without breaking large amounts of
existing code or starting work on ggplot3.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On Thu, 20 Oct 2011, Hadley Wickham wrote: The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages You used to be able to have a versioned install of a package, and then load a particular version. Not sure when it was removed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On 20.10.2011 18:25, Geoff Jentry wrote: On Thu, 20 Oct 2011, Hadley Wickham wrote: The optimal solution would be if R packages could depend on a specific version of a package, and a user could have multiple packages You used to be able to have a versioned install of a package, and then load a particular version. Not sure when it was removed. See the NEWS files. Anyway, it was always intended for development purposes only. You can still install various versions into separate libraries and explicitly load from such libraries. Both, the removed feature and my suggested workaround were/are *not* intended for "production use". Best, Uwe Ligges __ 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] cygwing warming when creating a package in windows
Dear All, I am a beginner creating R packages. I followed the Leisch (2009) tutorial and the document “Writing R Extensions” to write an example. I installed R 2.12.2 (I also tried R2.13.2), the last version of Rtools and the recommended packages in a PC with Windows 7 Home Premium. I can run R CMD INSTALL linmod in the command prompt and the R CMD check linmod. The following outputs are obtained: * installing *source* package 'linmod' ... ** R ** preparing package for lazy loading ** help *** installing help indices ** building package indices ... ** testing if installed package can be loaded * DONE (linmod) * using log directory 'D:/mypkg/linmod.Rcheck' * using R version 2.12.2 (2011-02-25) * using platform: i386-pc-mingw32 (32-bit) * using session charset: ISO8859-1 * checking for file 'linmod/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'linmod' version '1.0' * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'linmod' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... OK * checking whether the package can be loaded with stated dependencies ... OK * checking whether the package can be unloaded cleanly ... OK * checking for unstated dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R code for possible problems ... OK * checking Rd files ... OK * checking Rd metadata ... WARNING Rd files with duplicated alias 'linmod.default': linmod.Rd linmod.default.Rd Rd files with duplicated alias 'linmod.formula': linmod.Rd linmod.formula.Rd Rd files with duplicated alias 'print.linmod': linmod.Rd print.linmod.Rd Rd files with duplicated alias 'summary.linmod': linmod.Rd summary.linmod.Rd * checking Rd cross-references ... WARNING Unknown package(s) '' in Rd xrefs * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking Rd contents ... OK * checking for unstated dependencies in examples ... OK * checking examples ... OK * checking PDF version of manual ... OK WARNING: There were 2 warnings, see 'D:/my pkg/linmod.Rcheck/00check.log' for details I don’t know if it is possible to run R CMD build linmod even though I have two warning. But if I do it, I get the following cygwin warning: cygwin warning: MS-DOS style path detected: D:/mypkg/linmod_1.0.tar Preferred POSIX equivalent is: /cygdrive/d/mypkg/linmod_1.0.tar CYGWIN environment variable option “nodosfilewarning” turns off this warning. Consult the user’s guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames I am not a Linux expert, and I don’t how to fix this error (I couldn’t find any help in the manuals or forums, at least for me). Please, any help would be really appreciated. Many thanks in advance. Alba Martinez-Ruiz - Facultad de Ingeniería Universidad Católica de la Ssma. Concepción Alonso de Rivera 2850, C.P. 409-0541 Concepción, Chile Tel: + 0056 41 2345232 Fax: + 0056 41 2345300 -- View this message in context: http://r.789695.n4.nabble.com/cygwing-warming-when-creating-a-package-in-windows-tp3915660p3915660.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
Re: [Rd] cygwing warming when creating a package in windows
That. Cygwin warning is expected on Windows. You can still build the package and it should be fine, although it looks like the documentation may need a bit of tweaking to pass R CMD check. 2.13.2 is the latest version of R, and I would recommend using it over 2.12.2. Both for the improvements and because others on this list tend to have the later version so helping is easier. Cheers, Josh On Oct 18, 2011, at 7:56, Alba Martinez-Ruiz wrote: > Dear All, > > I am a beginner creating R packages. I followed the Leisch (2009) tutorial > and the document “Writing R Extensions” to write an example. > > I installed R 2.12.2 (I also tried R2.13.2), the last version of Rtools and > the recommended packages in a PC with Windows 7 Home Premium. > > I can run R CMD INSTALL linmod in the command prompt and the R CMD check > linmod. The following outputs are obtained: > > * installing *source* package 'linmod' ... > ** R > ** preparing package for lazy loading > ** help > *** installing help indices > ** building package indices ... > ** testing if installed package can be loaded > > * DONE (linmod) > > * using log directory 'D:/mypkg/linmod.Rcheck' > * using R version 2.12.2 (2011-02-25) > * using platform: i386-pc-mingw32 (32-bit) > * using session charset: ISO8859-1 > * checking for file 'linmod/DESCRIPTION' ... OK > * checking extension type ... Package > * this is package 'linmod' version '1.0' > * checking package dependencies ... OK > * checking if this is a source package ... OK > * checking for executable files ... OK > * checking whether package 'linmod' can be installed ... OK > * checking package directory ... OK > * checking for portable file names ... OK > * checking DESCRIPTION meta-information ... OK > * checking top-level files ... OK > * checking index information ... OK > * checking package subdirectories ... OK > * checking R files for non-ASCII characters ... OK > * checking R files for syntax errors ... OK > * checking whether the package can be loaded ... OK > * checking whether the package can be loaded with stated dependencies ... OK > * checking whether the package can be unloaded cleanly ... OK > * checking for unstated dependencies in R code ... OK > * checking S3 generic/method consistency ... OK > * checking replacement functions ... OK > * checking foreign function calls ... OK > * checking R code for possible problems ... OK > * checking Rd files ... OK > * checking Rd metadata ... WARNING > Rd files with duplicated alias 'linmod.default': > linmod.Rd linmod.default.Rd > Rd files with duplicated alias 'linmod.formula': > linmod.Rd linmod.formula.Rd > Rd files with duplicated alias 'print.linmod': > linmod.Rd print.linmod.Rd > Rd files with duplicated alias 'summary.linmod': > linmod.Rd summary.linmod.Rd > * checking Rd cross-references ... WARNING > Unknown package(s) '' in Rd xrefs > * checking for missing documentation entries ... OK > * checking for code/documentation mismatches ... OK > * checking Rd \usage sections ... OK > * checking Rd contents ... OK > * checking for unstated dependencies in examples ... OK > * checking examples ... OK > * checking PDF version of manual ... OK > WARNING: There were 2 warnings, see 'D:/my pkg/linmod.Rcheck/00check.log' > for details > > I don’t know if it is possible to run R CMD build linmod even though I have > two warning. But if I do it, I get the following cygwin warning: > > cygwin warning: > MS-DOS style path detected: D:/mypkg/linmod_1.0.tar > Preferred POSIX equivalent is: /cygdrive/d/mypkg/linmod_1.0.tar > CYGWIN environment variable option “nodosfilewarning” turns off this > warning. > Consult the user’s guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > > I am not a Linux expert, and I don’t how to fix this error (I couldn’t find > any help in the manuals or forums, at least for me). Please, any help would > be really appreciated. > > Many thanks in advance. > > Alba Martinez-Ruiz > - > Facultad de Ingeniería > Universidad Católica de la Ssma. Concepción > Alonso de Rivera 2850, > C.P. 409-0541 Concepción, Chile > Tel: + 0056 41 2345232 > Fax: + 0056 41 2345300 > > -- > View this message in context: > http://r.789695.n4.nabble.com/cygwing-warming-when-creating-a-package-in-windows-tp3915660p3915660.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] cygwing warming when creating a package in windows
On 20/10/2011 3:06 PM, Joshua Wiley wrote: That Cygwin warning is expected on Windows. It can be suppressed by setting an environment variable named CYGWIN with value nodosfilewarning, e.g. by doing this at the command line: SET CYGWIN=nodosfilewarning Duncan Murdoch You can still build the package and it should be fine, although it looks like the documentation may need a bit of tweaking to pass R CMD check. 2.13.2 is the latest version of R, and I would recommend using it over 2.12.2. Both for the improvements and because others on this list tend to have the later version so helping is easier. Cheers, Josh On Oct 18, 2011, at 7:56, Alba Martinez-Ruiz wrote: > Dear All, > > I am a beginner creating R packages. I followed the Leisch (2009) tutorial > and the document “Writing R Extensions” to write an example. > > I installed R 2.12.2 (I also tried R2.13.2), the last version of Rtools and > the recommended packages in a PC with Windows 7 Home Premium. > > I can run R CMD INSTALL linmod in the command prompt and the R CMD check > linmod. The following outputs are obtained: > > * installing *source* package 'linmod' ... > ** R > ** preparing package for lazy loading > ** help > *** installing help indices > ** building package indices ... > ** testing if installed package can be loaded > > * DONE (linmod) > > * using log directory 'D:/mypkg/linmod.Rcheck' > * using R version 2.12.2 (2011-02-25) > * using platform: i386-pc-mingw32 (32-bit) > * using session charset: ISO8859-1 > * checking for file 'linmod/DESCRIPTION' ... OK > * checking extension type ... Package > * this is package 'linmod' version '1.0' > * checking package dependencies ... OK > * checking if this is a source package ... OK > * checking for executable files ... OK > * checking whether package 'linmod' can be installed ... OK > * checking package directory ... OK > * checking for portable file names ... OK > * checking DESCRIPTION meta-information ... OK > * checking top-level files ... OK > * checking index information ... OK > * checking package subdirectories ... OK > * checking R files for non-ASCII characters ... OK > * checking R files for syntax errors ... OK > * checking whether the package can be loaded ... OK > * checking whether the package can be loaded with stated dependencies ... OK > * checking whether the package can be unloaded cleanly ... OK > * checking for unstated dependencies in R code ... OK > * checking S3 generic/method consistency ... OK > * checking replacement functions ... OK > * checking foreign function calls ... OK > * checking R code for possible problems ... OK > * checking Rd files ... OK > * checking Rd metadata ... WARNING > Rd files with duplicated alias 'linmod.default': > linmod.Rd linmod.default.Rd > Rd files with duplicated alias 'linmod.formula': > linmod.Rd linmod.formula.Rd > Rd files with duplicated alias 'print.linmod': > linmod.Rd print.linmod.Rd > Rd files with duplicated alias 'summary.linmod': > linmod.Rd summary.linmod.Rd > * checking Rd cross-references ... WARNING > Unknown package(s) '' in Rd xrefs > * checking for missing documentation entries ... OK > * checking for code/documentation mismatches ... OK > * checking Rd \usage sections ... OK > * checking Rd contents ... OK > * checking for unstated dependencies in examples ... OK > * checking examples ... OK > * checking PDF version of manual ... OK > WARNING: There were 2 warnings, see 'D:/my pkg/linmod.Rcheck/00check.log' > for details > > I don’t know if it is possible to run R CMD build linmod even though I have > two warning. But if I do it, I get the following cygwin warning: > > cygwin warning: > MS-DOS style path detected: D:/mypkg/linmod_1.0.tar > Preferred POSIX equivalent is: /cygdrive/d/mypkg/linmod_1.0.tar > CYGWIN environment variable option “nodosfilewarning” turns off this > warning. > Consult the user’s guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > > I am not a Linux expert, and I don’t how to fix this error (I couldn’t find > any help in the manuals or forums, at least for me). Please, any help would > be really appreciated. > > Many thanks in advance. > > Alba Martinez-Ruiz > - > Facultad de Ingeniería > Universidad Católica de la Ssma. Concepción > Alonso de Rivera 2850, > C.P. 409-0541 Concepción, Chile > Tel: + 0056 41 2345232 > Fax: + 0056 41 2345300 > > -- > View this message in context: http://r.789695.n4.nabble.com/cygwing-warming-when-creating-a-package-in-windows-tp3915660p3915660.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] Speed difference between df$a[1] and df[1,"a"]
`$` and `[` are primitives while `[.data.frame` is a longish R function that does all sorts of clever things. On 19/10/11 22:34, Stavros Macrakis wrote: I was surprised to find that df$a[1] is an order of magnitude faster than df[1,"a"]: df<- data.frame(a=1:10) system.time(replicate(10, df$a[3])) user system elapsed 0.360.000.36 system.time(replicate(10, df[3,"a"])) user system elapsed 4.090.004.09 A priori, I'd have thought that combining the row and column selections into a single operation would at worst be equally fast, at best would be faster by having fewer intermediate results and avoiding redundant operations. I thought this might be because df[,] builds a data frame before simplifying it to a vector, but with drop=F, it is even slower, so that doesn't seem to be the problem: system.time(replicate(10, df[3,"a",drop=FALSE])) user system elapsed 15.000.00 14.99 I then wondered if it might be because '[' allows multiple columns and handles rownames. Sure enough, '[[,]]', which allows only one column, and does not handle rownames, is almost 3x faster: system.time(replicate(10, df[[3,"a"]])) user system elapsed 1.480.001.48 ...but it is still 4x slower than $[]. The timings are not sensitive to the number of rows in df (except for the drop=FALSE case, which is much slower for large dfs). I will be avoiding [,] and [[,]] when I don't need their functionality, but I still wonder why they should be so much slower than $[]. -s R 2.13.1 on Windows 7, i7-860 (2.8GHz) 8GB RAM [[alternative HTML version deleted]] __ 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] Speed difference between df$a[1] and df[1,"a"]
On Wed, Oct 19, 2011 at 2:34 PM, Stavros Macrakis wrote: > I was surprised to find that df$a[1] is an order of magnitude faster than > df[1,"a"]: Yes. This treats a data frame as a list, and is much faster. > I thought this might be because df[,] builds a data frame before simplifying > it to a vector, but with drop=F, it is even slower, so that doesn't seem to > be the problem: drop=FALSE creates a data frame first, and then simplifies it to a vector, so this test isn't showing what you think it is. > I then wondered if it might be because '[' allows multiple columns and > handles rownames. Sure enough, '[[,]]', which allows only one column, and > does not handle rownames, is almost 3x faster: That's part of it, but if you look at [.data.frame you see there is also quite a bit of copying that could be avoided in simple cases but is hard to avoid in full generality. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
