similar to: RE: [R] debugging non-visible functions

Hi, I would like to step-through a non-visible function. but apparently I don't know enough about namespaces to get that to work: > methods(predict) ... deleted lines ... [27] predict.rpart* predict.smooth.spline* [31] predict.survreg.penal* Non-visible functions are asterisked > debug(predict.rpart) Error: Object "predict.rpart" not found >

[I'm diverting this to R-devel, as I believe my questions are more appropriate for that.] > From: Prof Brian Ripley [snip] > Luke Tierney recommends removing the NAMESPACE file during > development of > a package if you need frequent access to debug/change its functions. But isn't that a bit troublesome if there is a shared object to be loaded in the NAMESPACE file? If I

On Wed, 13 Oct 2004, Duncan Temple Lang wrote: > Prof Brian Ripley wrote: > > On Wed, 13 Oct 2004, Liaw, Andy wrote: > > > > > > > On a slightly different topic: In R-2.0.0, packages with NAMESPACE no > > > longer need to use the package= argument in .C/.Fortran. Does that mean if > > > I remove those arguments, I should put R version >=

> From: Duncan Temple Lang > > Prof Brian Ripley wrote: > > On Wed, 13 Oct 2004, Liaw, Andy wrote: > > > > > > > On a slightly different topic: In R-2.0.0, packages with > NAMESPACE no > > > longer need to use the package= argument in .C/.Fortran. > Does that mean if > > > I remove those arguments, I should put R version >=

On 09/08/2019 4:37 p.m., Gabriel Becker wrote: > Duncan, > > > On Fri, Aug 9, 2019 at 1:17 PM Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > On 09/08/2019 2:41 p.m., Gabriel Becker wrote: > > Note that this proposal would make mypackage_2.3.1 a valid > *package name*, > > whose

I'd like to have a class A that computes a likelihood, and a subclass B that computes the same likelihood by sometimes throws in an additional term (B includes measurement error). So B's likelihood needs to call A's, and then (sometimes) multiply by an additional term. It sounds as if, in the S3 scheme, NextMethod is supposed to do this: like.A <- function(stuff) compute value

Martin, Thank you for discussing this amongst R-core and for detailing the R-core discussion here. Some specific examples where having underscores available would have been useful. 1. My primerTree package (2013) was originally primer_tree, but I had to change the name to camelCase to comply with the check requirements. Using camelCase in the package name makes reading code jarring, as the

Hello everyone, I'm trying to update the locfit package so that it passes package check in R 2.6.0. However, the check seems to think some of the functions with dot in the names are S3 methods (thus warns about the format of the \usage{} part) when they are not. Can anyone recommend a workaround for this? I tried reading R-exts, but couldn't find any hint. I'd very much appreciate

Please point me to the documentation explaining why some of the functions returned by calling methods() are marked as "non-visible" and whether there is indeed no way of viewing the R code of such functions thanks Steve _________________________________________________________________

Hola! I am programming a class (S3) "symarray" for storing the results of functions symmetric in its k arguments. Intended use is for association indices for more than two variables, for instance coresistivity against antibiotics. There is one programming problem I haven't solved, making an inverse of the index function indx() --- se code below. It could for instance return the

Dear R People: When creating a package, how do you include new methods and classes, please? I'm using the pacakge.skeleton command as a starting point. Thanks, Sincerely, Erin Hodgess Associate Professor Department of Computer and Mathematical Sciences University of Houston - Downtown mailto: hodgess at gator.uhd.edu

That's one of the purposes of the namespace. See Prof. Tierney's article in the R Newsletter, or the slides of his keynote lecture at the useR! 2004 conference. It's also explained in the `Writing R Extensions' manual. Basically you only export functions that the users should see. The manual also explains how to not document functions that aren't intended to be called by

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional

Dear R-devel, We are pleased to inform you that the R Consortium OOP Working Group has been making progress on the S7 (formerly named R7) package and are preparing to submit it to CRAN. The S7 package is a new OOP system designed to be a successor to S3 and S4. As part of that effort, the group has identified a minimal set of narrow changes to base R that would allow S7 to exist as a CRAN

Recent R function names seem to be using CaseOfTheLetters to mark words rather than dots as was done previously. Is the use of dots in function names deprecated, or is that simply a style choice? Will function names with dots cause problems in future revisions? Mike Prager

I would like to follow up on another one of the documentation issues raised in the discussion on function hints. Duncan mentioned that the R core were working on preprocessing directives for .Rd files, which could possibly include some sort of include directive. I was wondering if a "includeexamples" directive might also be considered. It often makes sense to use the same example to

# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### > x <- rnorm(10) > y <- 1:10 > xyplot(y ~ x) >

Hi all, I have newly discovered the power of connections (although just a small part of it, namely the file() connection). It allowed me to process data file with arbitrary number of fields per line, which I was using awk for preprocessing before readling into R. The combination of the connection, readLines() and strsplit() really make the work a lot easier and more organized. Thanks a bundle

Dear R-devel, Can anyone give me some hints on how to go about debugging a strange segfault in my randomForest package? Here's the scoop: A user reported segfault when running predict() in the randomForest package. I asked for the data and code. The combination runs fine under WinXPPro, but does give segfault on one of our Linux boxes running R (1.7.0 through R-devel_2004-01-08) on

Looking at the MSI implementation I have a couple of questions: 1) There currently seems to be a hidden requirement of NR_PIRQS in the kernel needing to be no smaller than NR_IRQS in the hypervisor. Otherwise, the pirq returned from PHYSDEVOP_map_pirq may collide with the dynamic IRQs in the kernel or even be out of range altogether. Therefore I think that NR_PIRQS has to become a variable