Hi, Charlotte:
I'm not sure what you mean. If you mean writing something like
print.foo (myfoo, ...), this is relatively benign I suppose, but I
avoid it where feasible. On multiple occasions, I've pushed
collaborators and even maintainers of other packages to change this or
allow
I'm not familiar with 'class and object diagrams', but have you tried
the sos package available from CRAN via something like the following:
library(sos)
cod - findFn('class and object diagram')
cods - findFn('class and object diagrams')
(cod. - cod|cods)
summary(cod.)
When I ran this
Beyond what Gabor said, I might download a package that uses zoo, then
use zoo directly in other contexts without ever downloading it
directly. Total downloads would capture that; top level downloads
would not. The flip side is that a package that requires zoo may only
use it for features
I write *.Rd files primarily because it helps me think through what I
want the software to do AND because the \examples provide any degree
of unit testing I feel I need to create trustworth software (to quote
Chambers). The fact that I can then share the resulting package with
others is a
There are many arguments in many functions that are rarely used. I
prefer to see it all documented in the help pages. If they are not
documented in the help pages (and sometimes even if they are), a user
who wants them can invent other ways to get similar information with
much greater
I hope you will forgive a serious comment on this thread, but the
new sos package makes greping through the headers shockingly easy.
It returns the 'RSiteSearch( ___ , function)' information in a
data.frame of class findFn sorted to put the package with the most
matches first. Duncan
Dirk Eddelbuettel wrote:
On 11 September 2009 at 17:25, Kurt Hornik wrote:
| I thought I had already explained the last time the GPL-only suggestion
| came up that this will not happen for CRAN.
|
| But again: we have invested considerable time into getting the license
| specs standardized,
I will offer my opinion as a user and contributer to R packages
via R-Forge and CRAN:
1. How difficult would it be to split CRAN into two parts,
depending on whether the package carried an acceptable license allowing
free distribution? The second might carry a name like
Hello:
What should I do regarding code to write an Excel file in a
non-Windows platform?
The sos package [new version of RSiteSearch] on R-Forge
includes writeFindFn2xls, which starts with require(RODBC). The
next line calls odbcConnectExcel. This works under Windows but
] sos_1.0-5 brew_1.0-3 WriteXLS_1.8.1
###
Dirk Eddelbuettel wrote:
On 9 August 2009 at 12:04, spencerg wrote:
| What should I do regarding code to write an Excel file in a
| non-Windows platform?
[...]
| What would you suggest we do about
Dear Gabor:
Good suggestion. I will probably do that if WriteXLS is not
installed or if it is but testPerl() is FALSE.
Thanks,
Spencer
Gabor Grothendieck wrote:
Instead of writing out an xls file you could write out a file
in any format that Excel can read, e.g. csv, with a
Hello:
How can one get the number of functions and data sets in a package?
I've written a function PackageSum2 to get an extended package
summary for an installed package. I get much of what I want from the
object returned by help(package=pkgName). For example,
Dear Gabor:
Thanks very much. I will study codoc with great interest. (The
code already uses packageDescription.)
Thanks again,
Spencer
Gabor Grothendieck wrote:
On Thu, Jul 9, 2009 at 10:33 AM, spencergspencer.gra...@prodsyse.com wrote:
Hello:
How can one get
What do I need to do to get install.packages to work properly
for me in R 2.9.1 under Vista?
Currently, install.packages in Rgui 2.9.1 by default goes to
C:\\Users\\sgraves\\Documents/R/win-library/2.9. This is a problem
for me, because R running under Emacs does not currently
again.
Best Wishes,
Spencer
Uwe Ligges wrote:
spencerg wrote:
What do I need to do to get install.packages to work properly
for me in R 2.9.1 under Vista?
Currently, install.packages in Rgui 2.9.1 by default goes to
C:\\Users\\sgraves\\Documents/R/win-library/2.9
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this
is to make
it as easy as possible for R users to find what they want in
contributed
packages. A referee for our R Journal manuscript complained that
RSiteSearch.function was too much to type
for all your suggestions.
Best Wishes,
Spencer
Duncan Murdoch wrote:
On 6/5/2009 9:41 AM, spencerg wrote:
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this is to
make it as easy as possible for R users to find what they want
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All:
What do you think of adding
.
Thanks,
Spencer
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All
Hello All:
What do you think of adding a function RSiteSeach to the package
of that name, masking the RSiteSearch function in utils, trapping
any call RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function and passing all others to utils:::RSiteSearch?
This was
I don't have an answer, but I suspect that if you
install.packages(RSiteSearch), you might find information relevant to
your question from the following:
library(RSiteSearch)
java - RSiteSearch.function('Java')
summary(java)
# Reports that 136 help pages contained Java, 23 of which are
1. Whatever we do with the RSiteSearch function, it should
still be available every time R starts. If we put it in its own
package, it should still be autoloaded with base, utils, stats, etc.
2. Sundar indicated to me that, if Jonathan would like to remove
the search
22 matches
Mail list logo
