[Rd] proposed changes to RSiteSearch
phgrosjean at sciviews.org
Fri May 8 17:03:13 CEST 2009
Don't forget R wiki in the list.
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( ( Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons-Hainaut University, Belgium
( ( ( ( (
Romain Francois wrote:
> Jonathan Baron wrote:
>> After reading all this, I favor doing one of two things:
>> 1. Put all the search stuff, including the proposed gmane function, in
>> Spencer's new package but make it one of the default packages, like
>> utils, etc., or,
>> 2. Put everything in utils, including Spencer's new package and the
>> gmane function.
>> I do not know enough to choose between these.
> I would tend to prefer #1 so that the functionality can incubate in a
> separate package, and then when it is mature enough, we can make a call
> about what to do with it.
> Something like this:
> - a generic abstract function that sets up the interface to query a
> search engine.
> - implementations of this, here are what I can think of:
> + jon's RSiteSearch for help pages
> + r graphical manuals
> + gmane, markmail for mail archives
> + classic help.search
> + R news (not clear how to do this right now)
> + vignettes (not clear how to do this right now)
> + JSS articles (not clear how to this right now)
> + FAQ (not clear how to this right now)
> + ... add your own by simply register your implementation
> The point about having some sort of central generic function is that it
> can be responsible for asking all engines and bring all results back in
> a single format.
> This somehow duplicates work I have been doing with the rsitesearch
> firefox extension, but doing it in R has several advantages.
> This I think is enough design to be a separate package.
> I am not sure what are the requirements for a package to be shipped with
> the distribution of R (QA, documentation, ...), but I am sure whoever
> steps me (maybe me) can make it compliant.
> There is precedent for functionality that was in a package and was
> merged into utils afterwards (rcompgen), but I think it was included
> because this was necessary, don't think these search engines __have__ to
> be in utils.
>> On 05/07/09 14:42, spencerg wrote:
>>> 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",
>> Good point.
>>> 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.
>> I do not understand "rather simple" at all. For those who are
>> interested, I've put my notes on how to manage my site (which still
>> need a bit of revision, but this will give you some idea of what is
>> involved) in
>> The problem is that I have not found a way to automate this, so I
>> still spend several hours each month doing it by hand. Too many
>> little glitches come up along the way, and the main problem is the
>> mailing lists. Moreover, Namazu just doesn't work all that well for
>> mailing lists of this size, because of the page footers in each post.
>> (Now I remove them. That was a bad idea. But if we're going to get
>> rid of this anyway I will not take the time to figure out how to put
>> them back properly.)
>> Also, Liviu Androic argued that vignettes should be searchable
>> separately from help pages. This makes sense, but I would strongly
>> prefer to move ahead on other changes and leave this until later.
>> The need for this sort of modification is what makes me favor option
>> #1 at the beginning (separate package) on the theory that it would be
>> easier for me to make changes than if it were part of utils, but I
>> don't know how this works.
>> So, if someone can make a decision about how to proceed, I'll do what
>> I can, as soon as I can.
More information about the R-devel