Thanks Sven. That indeed works. And if anyone has ideas how it could be put into R so Windows users could benefit, I'm sure it would be useful in checks of packages.
In other investigations of this, I realized that install.R has to prepare the .rdb and .rdx files and at that stage duplication might be detected. If install.R puts both versions of a duplicated name into these files, then the lazy load of library() or require() could be a place where detection would be useful, though only one of the names gets actually made available for use. However, my expertise with this internal aspect of R is rather weak. Cheers, JN On 16-07-23 12:04 PM, Sven E. Templer wrote: > Despite it might help, learning/using git is not tackling this specific > problem, I suggest code that does: > > sed -e 's/^[\ \t]*//' -e 's/#.*//' R/* | awk '/function/{print $1}' | sort | > uniq -d > > or > > https://gist.github.com/setempler/7fcf2a3a737ce1293e0623d2bb8e08ed > (any comments welcome) > > If one knows coding R, it might be more productive developing a tiny tool for > that, instead of learning a new (and complex) one (as git). > > Nevertheless, git is great! > > Best wishes, > > Sven > > --- > > web: www.templer.se > twitter: @setempler >> On 23 Jul 2016, at 16:17, Hadley Wickham <h.wick...@gmail.com> wrote: >> >> I think this sort of meta problem is best solved with svn/git because you >> can easily see if the changes you think you made align with the changes you >> actually made. Learning svn or git is a lot of work, but the payoff is >> worth it. >> >> Hadley >> >> On Friday, July 22, 2016, ProfJCNash <profjcn...@gmail.com> wrote: >> >>> In trying to rationalize some files in a package I'm working on, I >>> copied a function from one file to another, but forgot to change the >>> name of one of them. It turns out the name of the file containing the >>> "old" function was later in collation sequence than the one I was >>> planning to be the "new" one. To debug some issues, I put some print() >>> and cat() statements in the "new" file, but after building the package, >>> they weren't there. Turns out the "old" function got installed, as might >>> be expected if files processed in order. Debugging this took about 2 >>> hours of slightly weird effort with 2 machines and 3 OS distributions >>> before I realized the problem. It's fairly obvious that I should expect >>> issues in this case, but not so clear how to detect the source of the >>> problem. >>> >>> Question: Has anyone created a script to catch such duplicate functions >>> from different files during build? I think a warning message that there >>> are duplicate functions could save some time and effort. Maybe it's >>> already there, but I saw no obvious message. In this case, I'm only >>> working in R. >>> >>> I've found build.R in the R tarball, which is where I suspect such a >>> check should go, and I'm willing to prepare a patch when I figure out >>> how this should be done. However, it seems worth asking if anyone has >>> needed to do this before. I've already done some searching, but the >>> results seem to pick up quite different posts than I need. >>> >>> Cheers, JN >>> >>> ______________________________________________ >>> R-package-devel@r-project.org <javascript:;> mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>> >> >> >> -- >> http://hadley.nz >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel