Roy,
> All internet calls are wrapped in 'try()'. If that shows an error, I
> write a message to the screen about the error, and call stop(),
> perhaps with a further message in that call.
out of ignorance, i ask ...
in your package's operational code ("its API", or whatever), when a
required i
> In short, no matter how large you try to span your test coverage and surface,
> there will always be a residual chance for something slipping through.
"the narrower the window, the more likely you are to hit it." :)
__
R-package-devel@r-project.org m
Dirk and Duncan,
thanks. the slight nudge towards =R CMD INSTALL= is a helpful reminder,
and hewing close to the straight-and-narrow is undoubtedly a good thing.
cheers, Greg
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/l
Wolfgang,
> You might want to look into the load_all() function from 'devtools'.
thanks very much. that seems to do a great job.
cheers, Greg
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
hi.
when developing packages, my current work flow is to change the code,
(re-)build the package, detach/load the package, test (to find the
N+1'st bug, sigh).
the building step takes tens of seconds.
is there an obvious way to present some code to the R command line and
have it replace the appr
Duncan,
probably you know this one, but as we're sharing, and as i'm a fan, the
=miniCRAN= package has some such functionality, and the results can be
graphed. e.g.,
require(miniCRAN)
pdb <- pkgAvail()
dg <- makeDepGraph(c("acs", "cdlTools", "maps"), enhances=TRUE,availPkgs=pdb)
plot(dg, leg
hi. i use emacs org-mode to write my literate (semi-, in my case)
code. then, 'tangle' the results into package/R/foo.R, etc.
the tangling is driven by a makefile. (my methodology is to make the
package source tree as a subdirectory of where my makefile sits; i
realize this is non-standard, and
