[Rd] Error in Rd[[which]] : subscript out of bounds
I'm getting the following form R CMD CHECK mypackage --- * checking Rd files ... WARNING Error in Rd[[which]] : subscript out of bounds problem found in ‘myfunction.Rd’ - This is... not the most helpful error. I'd be happy to make a minimal .Rd example file if someone can point me to what a minimal .Rd file has in it. The file is already pretty minimal, so it's possible I've already gone to small and that is the reason for the error. Best, Paul Bailey __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in Rd[[which]] : subscript out of bounds
sessionInfo()? If not R v2.14.0, try with that version first. Then
have a look checkRd() of the 'tools' package, cf. help("checkRd",
package="tools"). That function allows you to check your Rd file from
within R so that you get more information/so that you can use
traceback() etc.
My $.02
/Henrik
On Sun, Nov 27, 2011 at 1:46 PM, Paul Bailey wrote:
> I'm getting the following form R CMD CHECK mypackage
> ---
> * checking Rd files ... WARNING
> Error in Rd[[which]] : subscript out of bounds
>
> problem found in ‘myfunction.Rd’
> -
> This is... not the most helpful error.
>
> I'd be happy to make a minimal .Rd example file if someone can point me to
> what a minimal .Rd file has in it.
>
> The file is already pretty minimal, so it's possible I've already gone to
> small and that is the reason for the error.
>
> Best,
> Paul Bailey
> __
> 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] Error in Rd[[which]] : subscript out of bounds
> sessionInfo()? If not R v2.14.0, try with that version first. Then
> have a look checkRd() of the 'tools' package, cf. help("checkRd",
> package="tools"). That function allows you to check your Rd file from
> within R so that you get more information/so that you can use
> traceback() etc.
>
Sorry, should have said this is in 2.14.0.
Using traceback() as you suggested solved this problem for me, thanks. this
made it pretty obvious:
2: checkUnique("\\description")
looks like I typed description when I wanted details.
Thanks!
Best,
Paul Bailey
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to deal with package conflicts
Hi Michael, As promised, I've moved survival to Suggests in the development version of the car package on R-Forge. AFAICS, this doesn't cause any problems (and should solve your problem). I incidentally added Anova() and linearHypothesis() methods for svyglm objects, and placed the survey package under Suggests. Best, John > -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- > project.org] On Behalf Of John Fox > Sent: November-25-11 11:47 AM > To: 'Michael Friendly' > Cc: 'Terry Therneau'; r-devel@r-project.org > Subject: Re: [Rd] How to deal with package conflicts > > Hi Michael, > > I'll look into moving survival to suggests (this weekend, if I have > time), but that doesn't address the more general issue. > > Best, > John > > > -Original Message- > > From: Michael Friendly [mailto:frien...@yorku.ca] > > Sent: November-25-11 10:43 AM > > To: Terry Therneau > > Cc: r-devel@r-project.org; John Fox; Duncan Murdoch > > Subject: Re: [Rd] How to deal with package conflicts > > > > On 11/25/2011 9:10 AM, Terry Therneau wrote: > > > The ridge() function was put into the survival package as a simple > > > example of what a user could do with penalized functions. It's not > > > a "serious" function, and I'd be open to any suggestions for > change. > > > > > > Actually, for any L2 penalty + Cox model one is now better off > using > > > coxme as the maximization process is much better thought out there. > > > I'd be happy to remove ridge from survival -- except that there are > > > bound to be lots of folks using the function and any such changes > > > (even good > > > ones) to the survival package are fraught with peril. > > Duncan provided one suggestion: make ridge() an S3 generic, and > > rename > > ridge() > > to ridge.coxph(), but this won't work, since you use ridge() inside > > coxph() and > > survreg() to add a penalty term in the model formula. > > Another idea might be simply to not export ridge(), but I have the > > feeling this will break your R CMD checks. > > > > Alternatively, my particular problem (wanting to use car::vif in my > > package documentation) would be solved if John Fox considered making > > making survival a Suggests: > > package rather than a > > Depends: one. This might work, since survival is only referenced in > > car by providing Anova() methods for coxph models. > > > > I think all of this raises a general issue of unintended consequences > > of "package bloat," where > > (a) Depends: packages are forced to load by require()/library(), > > whether they are really needed or not; > > (b) There is nothing like require(car, depends=FALSE) to circumvent > > this; > > (c) Once a require()'d package is loaded, it cannot be unloaded; > > (d) AFAIK, there is no way for a package author to override the > > masking of functions or data provided by other other packages, except > > by using > > mypackage::myfun() calls. > > > > To me this seems to be a flaw in the namespace mechanism. > > > > best, > > -Michael > > > > > > > > > > > > > > > > -- > > Michael Friendly Email: friendly AT yorku DOT ca > > Professor, Psychology Dept. > > York University Voice: 416 736-5115 x66249 Fax: 416 736-5814 > > 4700 Keele StreetWeb: http://www.datavis.ca > > Toronto, ONT M3J 1P3 CANADA > > __ > 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] Holding back on source code
Hi All, A few years back when I was a CSIRO (an Australian research centre) intern I developed a BLAS package for R that uses the GPU. I believe that there is something similar right now, except it uses a few CuBLAS (Nvidia BLAS) routines, but doesnt replace them. My question is, is it technically illegal to hold back on source code? Thanks, Sachin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Holding back on source code
On 27/11/2011 23:07, Sachinthaka Abeywardana wrote: Hi All, A few years back when I was a CSIRO (an Australian research centre) intern I developed a BLAS package for R that uses the GPU. I believe that there is something similar right now, except it uses a few CuBLAS (Nvidia BLAS) routines, but doesnt replace them. We haven't much idea what 'something similar' refers to. My question is, is it technically illegal to hold back on source code? It depends entirely on the licenses involved. Nothing prevents Adobe distributing Acrobat without source code, for example. This is the R development list: questions not specific to R are best asked elsewhere (and, to take a recent example, that includes questions about licenses of packages on R-forge or CRAN). 'Elsewhere' may mean an IP lawyer. Thanks, Sachin [[alternative HTML version deleted]] __ 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
