Re: [Rd] proposed changes to RSiteSearch
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 capability, it would be rather simple to move RSiteSearch to
nabble" for the listserve archives. The "RSiteSearch" function could be
modified to combine that with a separate search of only the help pages
on Jonathan's server.
3. However, I can't volunteer to do much more on this at least
until late June and probably not before late August. If you wanted to
move the "RSiteSearch" function to the "RSiteSearch" package on R-Forge,
Romain, Sundar and I would be happy to have other developers and let
them implement the group consensus.
Best Wishes,
Spencer
Gabor Grothendieck wrote:
But help really needs to be delivered with R, not an addon.
It should not be necessary to know how to install packages
just to get this level of help. I think it needs to be where it
is now.
On Thu, May 7, 2009 at 4:02 PM, Liaw, Andy wrote:
I agree! Recall, though, I had added the RSiteSearch() functionality
to the Rgui under Windows (Help / search.r-project.org...), so if
RSiteSearch() is taken out, this need to go, too.
Best,
Andy
From: Jonathan Baron
There is something to be said for taking all of these functions,
including the original RSiteSearch, out of utils and putting them in
the new RSiteSearch package. These are the sorts of things that will
get revised frequently, and this way (I think) we won't have to bother
whoever takes care of utils, which is part of the regular R
distribution.
I'm adding Spencer Graves to the cc list. Maybe he is interested in
doing this.
Jon
On 05/07/09 20:54, Romain Francois wrote:
We could have a few functions similar to RSiteSearch or
gmaneSearch I
just posted and then cook a summary html page with R ...
Here is a function that grabs relevant groups from gmane:
gmaneGroups <- function( prefix = "gmane.comp.lang.r." ){
url <- URLencode( sprintf(
"http://dir.gmane.org/index.php?prefix=%s";, prefix) )
txt <- grep( '^
url ), value =
TRUE )
rx <- '^.*?(.*?).*(.*?).*$'
out <- data.frame(
url = gsub( rx, "\\1", txt ),
group = gsub( rx, "\\2", txt ),
description = gsub( rx, "\\3", txt ),
stringsAsFactors = FALSE
)
out$group <- sub( "...", ".*", out$group, fixed = TRUE )
out
}
I'll clean this up and write a man page if there is
interest in adding
this to R, but this might be more appropriate in a package,
for example:
http://r-forge.r-project.org/projects/rsitesearch/
Romain
Liaw, Andy wrote:
From: Jonathan Baron
On 05/07/09 13:48, Liaw, Andy wrote:
From: Duncan Murdoch
I'll incorporate the changes if you like
Yes. Please do. I understand that it won't take effect
for a while.
When it does, I'll change my site.
What do you think
of the idea
of adding a gmane (or other archive) search to your results
page? Then
if someone doesn't like what the man pages show, you can
send them
somewhere else, rather than leaving them to find out the
other resources
themselves.
gmane has sample code for this on their search page
search.gmane.org, so
it looks reasonably easy. I'd suggest following their
last example,
with a drop-down box to select mailing lists, with
comp.lang.r.* as an
option for "all lists".
Duncan Murdoch
Good idea. I will do this. But there are also two
other good search
engines. Maybe I'll add all three search alternatives.
But then,
according to Sheena Iyengar, people won't choose any! Hmm.
Actually, I was thinking about a possible RHelpSearch() in
addition, if
Jon is no longer going to include the R-help archive in the
search. I
used the current RSiteSearch() a lot more for searching
R-help archive
than functions in packages. Ideas? comments?
This is OK with me, but I don't want to do it. I guess it would
search gmane. MarkMail is also pretty good, as is
http://tolstoy.newcastle.edu.au/R/ All these are much better than
Namazu for searching the R-help list.
Sorry I didn't make it clear: I meant something like the
gmaneSearcg()
that Romain posted, not hitting your site.
Best,
Andy
Jon
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
--
Jonathan Baron, Professor of Psychology, University of Pennsylvania
Re: [Rd] R & Java
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 in a
package "rJava", 16 in "R.utils", etc.
HTML(java)
# Opens a table with 136 rows in a browser,
# with the "rJava" pages first, followed by those in "R.utils", etc.,
# the last column of which contains links to the HTML versions of the
help pages.
Hope this helps.
Spencer Graves
Philippe Lamote wrote:
Hey guys,
I'm a (Java) integration architect.
We are currently stuck with SAS but I'd be happy to switch that to R! (of
course ;-).
Now, a big argument for the latter, is that we can integrate it seamlessly
with all our existing (java) apps.
Therefore: has anyone heard of a java API (like SAS has it's Java API for
enterprise integration) or a Service we can call (e.g. a web service, a http
invoker service , ...), ... ?
The ideal solution -to my view- would be to integrate it with ESB
functionality (e.g. Mule: http://www.mulesource.org/display/COMMUNITY/Home).
It allows you to stitch/knit/... together what/how/where you want.
Has anyone ever done such a thing?
Thx for advice,
Regards,
Philippe
__
Philippe Lamote
Technology Lead @TSSC - Johnson & Johnson Pharmaceutical R&D
__
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] proposed changes to RSiteSearch
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 suggested by a referee to a manuscript on this new capability
submitted to "R Journal". The current version of this manuscript is
available via "system.file('doc', 'RSiteSearch.pdf',
package='RSiteSearch')" if you have the "RSiteSearch" package installed.
Thanks,
Best Wishes,
Spencer
Liaw, Andy wrote:
I agree! Recall, though, I had added the RSiteSearch() functionality
to the Rgui under Windows (Help / search.r-project.org...), so if
RSiteSearch() is taken out, this need to go, too.
Best,
Andy
From: Jonathan Baron
There is something to be said for taking all of these functions,
including the original RSiteSearch, out of utils and putting them in
the new RSiteSearch package. These are the sorts of things that will
get revised frequently, and this way (I think) we won't have to bother
whoever takes care of utils, which is part of the regular R
distribution.
I'm adding Spencer Graves to the cc list. Maybe he is interested in
doing this.
Jon
On 05/07/09 20:54, Romain Francois wrote:
We could have a few functions similar to RSiteSearch or
gmaneSearch I
just posted and then cook a summary html page with R ...
Here is a function that grabs relevant groups from gmane:
gmaneGroups <- function( prefix = "gmane.comp.lang.r." ){
url <- URLencode( sprintf(
"http://dir.gmane.org/index.php?prefix=%s";, prefix) )
txt <- grep( '^
url ), value =
TRUE )
rx <- '^.*?(.*?).*(.*?).*$'
out <- data.frame(
url = gsub( rx, "\\1", txt ),
group = gsub( rx, "\\2", txt ),
description = gsub( rx, "\\3", txt ),
stringsAsFactors = FALSE
)
out$group <- sub( "...", ".*", out$group, fixed = TRUE )
out
}
I'll clean this up and write a man page if there is
interest in adding
this to R, but this might be more appropriate in a package,
for example:
http://r-forge.r-project.org/projects/rsitesearch/
Romain
Liaw, Andy wrote:
From: Jonathan Baron
On 05/07/09 13:48, Liaw, Andy wrote:
From: Duncan Murdoch
I'll incorporate the changes if you like
Yes. Please do. I understand that it won't take effect
for a while.
When it does, I'll change my site.
What do you think
of the idea
of adding a gmane (or other archive) search to your results
page? Then
if someone doesn't like what the man pages show, you can
send them
somewhere else, rather than leaving them to find out the
other resources
themselves.
gmane has sample code for this on their search page
search.gmane.org, so
it looks reasonably easy. I'd suggest following their
last example,
with a drop-down box to select mailing lists, with
comp.lang.r.* as an
option for "all lists".
Duncan Murdoch
Good idea. I will do this. But there are also two
other good search
engines. Maybe I'll add all three search alternatives.
But then,
according to Sheena Iyengar, people won't choose any! Hmm.
Actually, I was thinking about a possible RHelpSearch() in
addition, if
Jon is no longer going to include the R-help archive in the
search. I
used the current RSiteSearch() a lot more for searching
R-help archive
than functions in packages. Ideas? comments?
This is OK with me, but I don't want to do it. I guess it would
search gmane. MarkMail is also pretty good, as is
http://tolstoy.newcastle.edu.au/R/ All these are much better than
Namazu for searching the R-help list.
Sorry I didn't make it clear: I meant something like the
gmaneSearcg()
that Romain posted, not hitting your site.
Best,
Andy
Jon
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
--
Jonathan Baron, Professor of Psychology, University of Pennsylvania
Home page: http://www.sas.upenn.edu/~baron
Editor: Judgment and Decision Making (http://journal.sjdm.org)
Notice: This e-mail message, together with any attach...{{dropped:15}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed changes to RSiteSearch
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
wrote:
spencerg wrote:
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 suggested by
a
referee to a manuscript on this new capability submitted to "R Journal".
The current version of this manuscript is available via
"system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch')" if you have the "RSiteSearch"
package installed.
I suppose this depends on your long term plans for the function and
package.
If you think it should eventually replace the utils function, then it
makes
sense to use the same name: users won't get used to a new name in the
meantime. But if you think it will diverge from that function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at least while it is
the only significant export in the package. If people don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering the existing
function or not using it and that is not very nice. What is wanted is
both to be able to use it and allow it to coexist in a nice way.
It is essentially a rename of the existing one to utils::RSiteSearch. I
would only suggest this if RSiteSearch::RSiteSearch expanded on its
capabilities (which I think was Spencer's proposal), rather than replacing
them with something different.
How about R changing its RSiteSearch to be an S3 generic with the
main functionality being placed into RSiteSearch.default? Then
RSiteSearch.function can become RsiteSearch.character and
- RSiteSearch will give the new functionality when the package is
loaded and the old functionality if not.
- RSiteSearch.character can be used in place of RSiteSearch.function
to force only the new functionality (or an error if not present)
- RSiteSearch.default will give the old functionality whether or not the
package is loaded
(If there is a NAMESPACE then Its assumed here that both methods are
exported.)
How is that an improvement? Just replace your (RSiteSearch,
RSiteSearch.character, RSiteSearch.default) with (RSiteSearch,
RSiteSearch::RSiteSearch, utils::RSiteSearch) in my proposal and you get the
same behaviour. The point isn't that Spencer has invented a way for
RSiteSearch to handle character vectors, it already knows that. The point
is that he has enhanced it. Or maybe he has written something similar but
different, in which case he should pick a new name.
Duncan Murdoch
He simply renames it RSiteSearch.character (and possibly some other
changes depending on arguments). Then if the core cooperates
by making RSiteSearch a generic with a default method then everything
works as one would expect based on an understanding of S3.
No conflicts in names are involved.
To clarify: RSiteSearch.function{RSiteSearch} accesses Johathan Baron's
RSiteSearch data base for functions only, returning the result as a
data.frame, sorts it to put the most frequently cited package first and
then help page within package.
Spencer
__
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] proposed changes to RSiteSearch
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, suggesting we consider
masking "RSiteSearch". From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., "web.search" or "doc.search". Another colleague
suggested "RSearch".
What do you think about renaming the current
"RSiteSearch.function{RSiteSearch}" to "RSearch{RSearch}"?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named "prettysweetsmellingthingamabob" might not sell as well.
Thanks,
Spencer
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
wrote:
spencerg wrote:
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 suggested by
a
referee to a manuscript on this new capability submitted to "R Journal".
The current version of this manuscript is available via
"system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch')" if you have the "RSiteSearch"
package installed.
I suppose this depends on your long term plans for the function and
package.
If you think it should eventually replace the utils function, then it
makes
sense to use the same name: users won't get used to a new name in the
meantime. But if you think it will diverge from that function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at least while it is
the only significant export in the package. If people don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering the existing
function or not using it and that is not very nice. What is wanted is
both to be able to use it and allow it to coexist in a nice way.
It is essentially a rename of the existing one to utils::RSiteSearch. I
would only suggest this if RSiteSearch::RSiteSearch expanded on its
capabilities (which I think was Spencer's proposal), rather than replacing
them with something different.
How about R changing its RSiteSearch to be an S3 generic with the
main functionality being placed into RSiteSearch.default? Then
RSiteSearch.function can become RsiteSearch.character and
- RSiteSearch will give the new functionality when the package is
loaded and the old functionality if not.
- RSiteSearch.character can be used in place of RSiteSearch.function
to force only the new functionality (or an error if not present)
- RSiteSearch.default will give the old functionality whether or not the
package is loaded
(If there is a NAMESPACE then Its assumed here that both methods are
exported.)
How is that an improvement? Just replace your (RSiteSearch,
RSiteSearch.character, RSiteSearch.default) with (RSiteSearch,
RSiteSearch::RSiteSearch, utils::RSiteSearch) in my proposal and you get the
same behaviour. The point isn't that Spencer has invented a way for
RSiteSearch to handle character vectors, it already knows that. The point
is that he has enhanced it. Or maybe he has written something similar but
different, in which case he should pick a new name.
Duncan Murdoch
He simply renames it RSiteSearch.character (and possibly some other
changes depending on arguments). Then if the core cooperates
by making RSiteSearch a generic with a default method then everything
works as one would expect based on an understanding of S3.
No conflicts in names are involved.
__
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] proposed changes to RSiteSearch
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, suggesting we consider
masking "RSiteSearch". From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., "web.search" or "doc.search". Another
colleague
suggested "RSearch".
What do you think about renaming the current
"RSiteSearch.function{RSiteSearch}" to "RSearch{RSearch}"?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named "prettysweetsmellingthingamabob" might not sell
as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
"findFunction" sounds to me like the best name I've heard so far.
RSiteSearch() was named what it was because it was meant as an interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing ("Roogle"?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like "yum info" or "yum
search" for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) "Title", "Version", "Author", "Maintainer", and (date)
"Packaged". If the package is not installed, these fields are left
blank. I've used this to prioritize which packages (and then which
functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
wrote:
spencerg wrote:
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 suggested by
a
referee to a manuscript on this new capability
submitted to "R Journal".
The current version of this manuscript is available via
"system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch')" if you have
the "RSiteSearch"
package installed.
I suppose this depends on your long term plans for the
function and
package.
If you think it should eventually replace the utils
function, then it
makes
sense to use the same name: users won't get used to a
new name in the
meantime. But if you think it will diverge from that
function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at
least while it is
the only significant export in the package. If people
don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering
the existing
function or not using it and that is not very nice.
What is wanted is
both to be able to use it and allow
Re: [Rd] proposed changes to RSiteSearch
Dear Andy, Duncan, et al.
Based on comments from Andy and Duncan, I'd like to revise my
proposal as follows:
1. Rename the current "RSiteSearch.function" to
"findFunction" and the package name from "RSiteSearch.function" to
"findFunction", with "findFun" being an alias for "findFunction".
2. Try to write code so '???"differential equation"(999)'
works the same as 'RSiteSearch.function("differential equation", 999)'
does now.
What do you think? I've made this as two steps, because I can do
"1" myself, but I may need help to develop "2".
Thanks again 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 in
contributed packages. A referee for our "R Journal" manuscript
complained that "RSiteSearch.function" was too much to type,
suggesting we consider masking "RSiteSearch". From the discussion,
I do not see a strong consensus for doing that. I like Romain's
suggestion to shorten the name further to, e.g., "web.search" or
"doc.search". Another colleague suggested "RSearch".
What do you think about renaming the current
"RSiteSearch.function{RSiteSearch}" to "RSearch{RSearch}"?
I'm happy to support the consensus of this group on a name
(and even enhancements) that seems likely to maximize its utility
to R users. I ask, because a rose by any other name would smell as
sweet, but one named "prettysweetsmellingthingamabob" might not
sell as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this
through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main
goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
"findFunction" sounds to me like the best name I've heard so far.
But it isn't looking for functions, it's looking for help pages about
functions. Another possibility is ???, e.g.
???topic
This is done by masking the utils function `?`, and you'd have to be
careful to pass along requests with one or two (or more than three?)
question marks to the original; it also feels a bit strange to type
hits <- ???topic
though I think it's syntactic and well-defined. I'm not sure how
you'd include your optional arguments, it would be really weird (but
again well defined) to say
z <- ???spline(maxPages = 2)
(Your first example in ?RSiteSearch.function, translated).
Duncan Murdoch
RSiteSearch() was named what it was because it was meant as an
interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including
other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing ("Roogle"?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like "yum info" or "yum
search" for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) "Title", "Version", "Author", "Maintainer", and
(date) "Packaged". If the package is not installed, these fields are
left blank. I've used this to prioritize which packages (and then
which functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function "RSiteSeach"
to the package
of
that name, masking the "RSiteSearch" function in
[Rd] install.packages with R 2.9.1 under Vista?
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 look there. I made the mistake last night of first installing R 2.9.1 in the default "C:\Program Files". When I found that packages I installed using Rgui could not be found from within Emacs, I uninstalled R from "C:\Program Files" and reinstalled it under "C:\Users\sgraves\R" alongside R 2.9.0, which has allowed "install.packages" from Rgui to be accessed from R under Emacs. I've traced the problem to the different behavior of ".libPaths()": *** Rgui: .libPaths() [1] "C:\\Users\\sgraves\\Documents/R/win-library/2.9" [2] "C:/Users/sgraves/R/R-2.9.1/library" *** R under Emacs: > .libPaths() [1] "c:/Users/sgraves/R/R-2.9.1/library" What do you suggest? Thanks, Spencer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages with R 2.9.1 under Vista?
Dear Uwe: Thanks very much. Based on your suggestion, I deleted "C:\\Users\\sgraves\\Documents/R/win-library/2.9", which got created when I first installed R 2.9.1 into the default, write-protected area and then did "install.packages". When I uninstalled that write-protected copy and installed it in a different location, the directory "C:\\Users\\sgraves\\Documents/R/win-library/2.9" remained, and Rgui directed "install.packages" to that directory, though Rterm did not. I had not intentionally set "R_LIBS" nor any other special thing like that, so I was confused. Thanks 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". This is a problem for me, because R running under Emacs does not currently look there. I made the mistake last night of first installing R 2.9.1 in the default "C:\Program Files". When I found that packages I installed using Rgui could not be found from within Emacs, I uninstalled R from "C:\Program Files" and reinstalled it under "C:\Users\sgraves\R" alongside R 2.9.0, which has allowed "install.packages" from Rgui to be accessed from R under Emacs. I've traced the problem to the different behavior of ".libPaths()": *** Rgui: .libPaths() [1] "C:\\Users\\sgraves\\Documents/R/win-library/2.9" [2] "C:/Users/sgraves/R/R-2.9.1/library" *** R under Emacs: > .libPaths() [1] "c:/Users/sgraves/R/R-2.9.1/library" What do you suggest? Thanks, Either set for the second setup "C:\\Users\\sgraves\\Documents/R/win-library/2.9" as a default library path (e.g. via env var R_LIBS) or remove it from the first setup (in a personal startup file). Best wishes, Uwe Spencer __ 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] Number of functions, data sets, ..., in a package?
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,
"help(pac=...)$info[[1]]" is a character vector giving author,
maintainer, date built, etc. "help(pac=...)$info[[2]]" is a character
vector with at least one row for each help page; I can get the number
of help pages by subtracting the number starting with blank (" ") from
the length. And "help(pac=...)$info[[3]]" is a character matrix
describing the vignettes.
Is there a reasonably easy way to get numbers of (a) functions and
(b) data sets in the package?
I want this for a the next version of "PackageSum2" in the
"RSiteSearch" package. Based partly on previous input from this list,
the package is being renamed to "sos" with the primary
"RSiteSearch.function" function being renamed to "findFn". You can
install the current development version via 'install.packages("sos",
repos="http://R-Forge.R-project.org";)'.
Thanks,
Spencer
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Number of functions, data sets, ..., in a package?
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, spencerg wrote:
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, "help(pac=...)$info[[1]]"
is a character vector giving author, maintainer, date built, etc.
"help(pac=...)$info[[2]]" is a character vector with at least one row for
each help page; I can get the number of help pages by subtracting the
number starting with blank (" ") from the length. And
"help(pac=...)$info[[3]]" is a character matrix describing the vignettes.
Also look at ?packageDescription
Is there a reasonably easy way to get numbers of (a) functions and (b)
data sets in the package?
I want this for a the next version of "PackageSum2" in the "RSiteSearch"
package. Based partly on previous input from this list, the package is
being renamed to "sos" with the primary "RSiteSearch.function" function
being renamed to "findFn". You can install the current development version
via 'install.packages("sos", repos="http://R-Forge.R-project.org";)'.
Check out the source of codoc in the tools package.
Thanks,
Spencer
__
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] odbcConnectExcel on non-Windows?
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 fails under Linux and MacOS. What would you suggest we do about this? It currently tests (.Platform$OS.type == "windows"); if(FALSE), it issues an error, saying that it only works under Windows. Also, the help page skips those tests if the the platform is not Windows. If there is a better way to handle this, I would like to know. Thanks, Spencer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odbcConnectExcel on non-Windows?
Dear Marc: In spite of your efforts to help me, I still get an "F" in your "WriteXLS" class. Consider the following: > library(WriteXLS) > help(pac=WriteXLS) > testPerl() Perl found. The following Perl modules were not found on this system: Text::CSV_XS If you have more than one Perl installation, be sure the correct one was used here. Otherwise, please install the missing modules. See the package INSTALL file for more information. ## Might it be feasible to include the required Perl modules with the "WriteXLS" package? Then you would not have to rely on fools like me not knowing how to get the preferred copy of any required Perl modules. On my Windows platform (Vista), I got RODBC to work for "writeFindFn2xls" in the "sos" package. Unfortunately, the "daily checks" on R-Forge failed on non-Windows platforms. When I saw that, I asked R-Devel for help. Dirk suggested I try "WriteXLS"; see below. What do you suggest? If I don't hear an answer, I propose to NOT add "WriteXLS" to the "DESCRIPTION" file but rather to modify the code for "writeFindFn2xls" so that on non-Windows platforms, it tests to see if "WriteXLS" is installed. If no, it will issue an appropriate error message. If it finds "WriteXLS", it will try to use it. However, if you have other suggestions, I'd be pleased to hear them. Best Wishes, Spencer Graves > sessionInfo() R version 2.9.1 (2009-06-26) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] 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 this? [...] | If there is a better way to handle this, I would like to know. http://cran.r-project.org/web/packages/WriteXLS/index.html Portable (in the sense of used by Perl, Python, ... or other scripting engines) solutions have existed for a dozen years. We have a wrapper to Perl code for a long time too (having been of the initial discussions that lead to Greg's initial read.xls from the gdata package). Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odbcConnectExcel on non-Windows?
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 suitable renaming of your function. On Sun, Aug 9, 2009 at 1:04 PM, spencerg wrote: 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 fails under Linux and MacOS. What would you suggest we do about this? It currently tests (.Platform$OS.type == "windows"); if(FALSE), it issues an error, saying that it only works under Windows. Also, the help page skips those tests if the the platform is not Windows. If there is a better way to handle this, I would like to know. Thanks, Spencer __ 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] Non-GPL packages for R
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 RANC (R Archive Network - Commercial), and the first would retain the CRAN name. 2. R-Forge allows public access to the source code, at least for some packages. Moreover, users applying for R-Forge support must specify the license they plan to use. Support may be denied for a project that does not use one of the standard public distribution licenses like GPL. Spencer Dirk Eddelbuettel wrote: On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: | > Subject: Non-GPL packages for R | > | > Packages that are not licensed in a way that permits re-distribution on | > CRAN are frequently a source of comment and concern on R-help and other | > lists. A good example of this problem is the Rdonlp2 package that has caused | > a lot of annoyance for a number of optimization users in R. They are also an | > issue for efforts like Dirk Eddelbuettel's cran2deb. | > | > There are, however, a number of circumstances where non-GPL equivalent | > packages may be important to users. This can imply that users need to | > both install an R package and one or more dependencies that must be | > separately obtained and licensed. One such situation is where a new | > program is still under development and the license is not clear, as in | > the recent work we pursued with respect to Mike Powell's BOBYQA. We | > wanted to verify if this were useful before we considered distribution, | > and Powell had been offering copies of his code on request. Thus we | > could experiment, but not redistribute. Recently Powell's approval to | > redistribute has been obtained. | > | > We believe that it is important that non-redistributable codes be | > excluded from CRAN, but that they could be available on a repository | > such as r-forge. However, we would like to see a clearer indication of | > the license status on r-forge. One possibility is an inclusion of a | > statement and/or icon indicating such status e.g., green for GPL or | > equivalent, amber for uncertain, red for restricted. Another may be a | > division of directories, so that GPL-equivalent packages are kept | > separate from uncertain or restricted licensed ones. | > | > We welcome comments and suggestions on both the concept and the | > technicalities. | > | > John Nash & Ravi Varadhan | > | > __ | > 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 -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
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, and writing code to compute on these. Time | permitting, R 2.10.0 will feature code that allows specifying license | filters which can be customized according to individuals' needs. But I | see no point in physically representing one particular license profile. | | Btw, there are less non-free packages on CRAN than packages which claim | to be free but have non-free installation dependencies: some would argue | that the latter is impossible from a license perspective. I feel little | desire to start arguing about this, as being able to control package | installation by license filters will resolve matters anyway. Indeed, that would possibly solve some our (as in cran2deb) worries too. So a nig Thanks! for working on this, and of course for providing CRAN in the first place. I second that. People all over the world are more quantitative than they would otherwise be because the R project including CRAN (and R-Forge) make it economically feasible for them to access and use high quality software to better understand their world and communicate that improved understanding more effectively to others. Knowledge is power, and this increased knowledge gives more people more control over their lives. We are not laying brick but building a cathedral. Spencer Dirk -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Because it's Friday. was creating environments in package's C code
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 Murdoch wrote a "???" alias for this "findFn"
function. Union and intersection operators are defined for
"findFn"objects. The "findFn2xls" function writes an Excel file with
three sheets giving an extended package summary, the matches (including
the URLs), and the call. An article on this is scheduled to appear in
the next issue of "R Journal" and is available now via vignette('sos').
This "sos" package is not as good as greping Ripley's frontal
lobe, but it makes it quite easy to do a literature search of all
contributed R packages.
Spencer
Jeffrey Horner wrote:
Simon Urbanek wrote on 10/01/2009 11:51 AM:
[...]
I suspect you like reinventing the wheel ;). Your NewInteger is part
of the R API and is called ScalarInteger(). When you need something,
chances are that R has it already, so it's worth greping through the
headers (and sometimes even through the main sources).
I am reminded of what Robert Gentleman said at DSC 2005 during the R/S
round-chair discussion: "Brian Ripley is the only one I know who keeps
R in his frontal lobe."
I can only aspire to such greatness, Simon.
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
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 effort, and do so for years only to eventually find a much easier way buried in the documentation. Example: I was frustrated for years that "nls" would refuse to produce output if it did not converge. I often used "optim" instead of "nls" for that reason. However, the list returned by "optim" does not have the nice methods that one can use with an "nls" object. Eventually, I found the "warnOnly" option documented under "nls.control", which has made "nls" easier for me to use. Spencer Graves William Dunlap wrote: There are several help files in the R sources that describe concepts and not particular R objects. E.g., help(Methods), help(Syntax), and help(regex). They don't have a docType entry and their alias entries do not refer to functions. Perhaps your debugging documentation could go into a similar *.Rd file. Does check balk at such help files in a package? Should it? Should there be a special docType for such help files? Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Charles Geyer Sent: Monday, October 05, 2009 10:51 AM To: r-devel@r-project.org Subject: [Rd] how to document stuff most users don't want to see The functions metrop and temper in the mcmc package have a debug = FALSE argument that when TRUE adds a lot of debugging information to the returned list. This is absolutely necessary to test the functions, because one generally knows nothing about the simulated distribution except what what one learns from MCMC samples. Hence you must expose all details of the simulation to have any hope of checking that it is doing what it is supposed to do. However, this information is of interested mostly (perhaps solely) to developers. So I didn't document it in the Rd files for these functions. But it has ocurred to me that people might be interested in how these functions are validated, and I would like to document the debug output somewhere, but I don't want to clutter up the documentation that ordinary users see. That suggests a separate help page for debugging. Looking at "Writing R Extensions" it doesn't seem like there is a type of Rd file for this purpose. I suppose it could be added in (fairly long) sections titled "Debug Output" in metrop.Rd and temper.Rd or it could be put in a package help page (although that's not what that kind of page is really for). Any other possibilities to consider? -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu __ 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 -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unit testing for R packages?
I put unit test in the examples, using "\dontshow" to hide "stopifnot".
Many help pages I've written contain code like the following:
A <- functionDocumentedHere()
B <- manuallyComputedAnswer
\dontshow{stopifnot(}
all.equal(A, B)
\dontshow{)}
I think it helps the documentation to include an example comparing
a special case computed using a function with a manual computation.
However, "stopifnot" contributes nothing to user understanding, so I
hide it. One could also use "\dontshow" to hide entire examples that
check trivial details you think would not interest users.
Spencer
Seth Falcon wrote:
Hi,
On Mon, Oct 5, 2009 at 12:01 PM, Blair Christian
wrote:
I'm interested in putting some unit tests into an R package I'm
building. I have seen assorted things such as Runit library, svUnit
library, packages
with 'tests' directories, etc
I grep'd "unit test" through the writing R extensions manual but didn't find
anything. Are there any suggestions out there? Currently I have
several (a lot?) classes/methods that I keep tinkering with, and I'd
like to run a script frequently to check that I don't cause any
unforeseen problems.
I've had good experiences using RUnit. To date, I've mostly used
RUnit by putting tests in inst/unitTests and creating a Makefile there
to run the tests. You should also be able to use RUnit in a more
interactive fashion inside an interactive R session in which you are
doing development.
The vignette in svUnit has an interesting approach for integrating
unit testing into R CMD check via examples in an Rd file within the
package.
+ seth
--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unit testing for R packages?
Hi, Duncan:
Thanks for the warning. Can you give me a hint of which release
might require this? In particular, will it be R 2.10.0, coming quite
soon?
Thanks,
Spencer
Duncan Murdoch wrote:
On 05/10/2009 4:39 PM, spencerg wrote:
I put unit test in the examples, using "\dontshow" to hide
"stopifnot". Many help pages I've written contain code like the
following:
A <- functionDocumentedHere()
B <- manuallyComputedAnswer
\dontshow{stopifnot(}
all.equal(A, B)
\dontshow{)}
This will fail in a future release of R, because those aren't valid
expressions within \dontshow{}, which expects R code. You can achieve
the same effect using the clearer
all.equal(A,B)
\dontshow{ stopifnot(isTrue(.Last.value)) }
Duncan Murdoch
I think it helps the documentation to include an example
comparing a special case computed using a function with a manual
computation. However, "stopifnot" contributes nothing to user
understanding, so I hide it. One could also use "\dontshow" to hide
entire examples that check trivial details you think would not
interest users.
Spencer
Seth Falcon wrote:
Hi,
On Mon, Oct 5, 2009 at 12:01 PM, Blair Christian
wrote:
I'm interested in putting some unit tests into an R package I'm
building. I have seen assorted things such as Runit library, svUnit
library, packages
with 'tests' directories, etc
I grep'd "unit test" through the writing R extensions manual but
didn't find
anything. Are there any suggestions out there? Currently I have
several (a lot?) classes/methods that I keep tinkering with, and I'd
like to run a script frequently to check that I don't cause any
unforeseen problems.
I've had good experiences using RUnit. To date, I've mostly used
RUnit by putting tests in inst/unitTests and creating a Makefile there
to run the tests. You should also be able to use RUnit in a more
interactive fashion inside an interactive R session in which you are
doing development.
The vignette in svUnit has an interesting approach for integrating
unit testing into R CMD check via examples in an Rd file within the
package.
+ seth
--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
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 marvelous byproduct of this approach to software development, but not the primary reason I do it. Earlier today, I read where Hadley had had problems with my code and had to read the help file carefully to understand how to fix the problem. I immediately wrote to Hadley inviting more input (and to my collaborator to suggest that the package be placed on R-Forge to make it easier for people to improve documentation, etc.). Adding my $0.02 to Seth's. Spencer Seth Falcon wrote: Writing good documentation is hard. I can appreciate the desire to find technological solutions that improve documentation. However, the benefit of a help system that allows for varying degrees of verbosity is very likely to be overshadowed by the additional complexity imposed on the help system. Users would need to learn how to tune the help system. Developers would need to learn and follow the system of variable verbosity. This time would be better spent by developers simply improving the documentation and by users by simply reading the improved documentation. My $0.02. + seth -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN Server download statistics (Was: R Usage Statistics)
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 that I don't use. This would support the use of top level downloads over total downloads. Spencer Gabor Grothendieck wrote: On Mon, Nov 23, 2009 at 3:51 PM, Fellows, Ian wrote: 6. Regarding package dependancies, I was thinking about also counting the number of top level downloads, as approximated by the number of downloads where a reverse dependancy was not downloaded in the next 5 min by the same IP. Top level downloads discriminates against infrastructure packages, i.e. packages that are not necessarily directly used by users or even downloaded directly by users. It can make it seem as if a package that is widely used, but not directly by users, is barely used at all so total downloads seems a better metric of popularity than top level downloads. I can't find it just now but remember reading a post on another list, or maybe it was his blog, by the author of certain software (not related to R) that was fundamental to Ruby on Rails but as infrastructure would not be directly observed by the user yet Ruby on Rails got all the credit and his key contribution got almost none despite the fact that Ruby on Rails likely would have never achieved its current high level of popularity without his contribution. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] UML Class and Object Diagrams in R
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 just now, cod included 287 matches and cods 126,
totalling 413. Their union 'cod.' 356 links in 100 packages; the print
method opened the results as a table in a browser sorted to put the
packages with the most, best matches first, with links to each manual
page. The 7 packages with the most, best matches were given by the
summary:
Packages with at least 7 matches using pattern
'class+and+object+diagram | class+and+object+diagrams'
Package Count MaxScore TotalScore Date
1 ade433 24117 2009-12-16
2diagram25 27166 2009-10-19
3 vegan15 25 79 2009-07-01
4 CHNOSZ14 56183 2009-12-16
5oce14 26114 2009-11-26
6plotrix12 39193 2009-05-14
7 compositions12 26 91 2009-03-17
8Epi11 37146 2009-11-26
9 psych10 31107 2009-11-05
10 alphahull 9 33100 2009-12-16
11 BiodiversityR 7 48112 2009-12-16
12 verification 7 28 60 2009-08-16
Hope this helps.
Spencer
Charlotte Maia wrote:
Hi all
Does anyone know if there are any R packages available for creating
UML class and object diagrams in R (suitable for use with Latex)?
I'm considering developing such a system...
Note, I'm aware there are Latex packages (so no one needs to state the obvious).
On a side issue I'm thinking about (mostly) abandoning the class
system I mentioned earlier. Thank you to Martin Maechler, Thomas
Petzoldt and Barry Rowlingson, for their feedback.
kind regards
--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Darwinian software development and the library function
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 me to change it to conform to the standard; if my memory is correct, there have been several violations of this standard in the "fda" package, which are no longer there because I changed them. If a user with an object "x" of class "foo" writes print(x=x) or print(foo=x), I'm not sure what it would do, but it might not be what you want. My "sos" package masks "?". However, I don't like it. I generally consider such to be potentially user hostile, and whenever feasible, I prefer to avoid such code. I did it in this case for a couple of reasons. First, using "?" (actually "???") seems so much easier to remember than "findFn" that it justifies this transgression of standard protocol. Second, one of the leading figures in the R community (Duncan Murdoch) contributed suggested we do this and contributed the code. If you change the definition of "print" itself, that seems to me to be a much bigger issue, with consequences much more difficult to predict. If someone else also overwrites "print" making it different and incompatible with yours, then your code may not work or theirs may not, depending on which gets loaded first in the search path. Worse, your code cannot possibly have been tested as thoroughly as the standard code. If your code includes a subtle bug that only occurs under special circumstances, it may be hard for the person experiencing the problem to find, because they don't expect it. Hope this helps. Spencer Charlotte Maia wrote: Hi all, Legend has it, that polite R programmers don't overwrite, say, the print function. However, this seems quite un-Darwinian to me (especially given that I don't want to call all my arguments x and y). I might want a function print.foo (myfoo, ...). So I decided to be very impolite (in one of my packages) and overwrite a few standard generics. Plus, to the best of my knowledge it doesn't interfere with normal use (yay...). This brings us to the library function. Which by default gives a whole lot of warnings loading my package (and any other package that does something similar), scaring off polite R programmers and perhaps some mainstream R users. I'm starting to think that the default for library, should be warn.conflicts=FALSE. However, just reading the documentation, I noticed a reference to something called .conflicts.OK. Not sure what that does, however if it does what it sounds like, then it largely fixes the problem. The biggest issue though, is whether or not one should be impolite (i.e. Darwinian) and overwrite print etc in the first place...? I'm inclined to go in favour of overwriting the functions. However, it has the potential to introduce some technical problems. Other's opinions appreciated. kind regards -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
