[Rd] proposed changes to RSiteSearch
Romain Francois
romain.francois at dbmail.com
Fri May 8 17:09:05 CEST 2009
yes, and r graph gallery. those two would be easy to implement once the
system is up.
Philippe Grosjean wrote:
> Don't forget R wiki in the list.
> Best,
>
> Philippe
> ..............................................<°}))><........
> ) ) ) ) )
> ( ( ( ( ( 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", etc.
>>>
>>> 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
>>>
>>> http://finzi.psych.upenn.edu/~baron/notes.namazu.txt
>>>
>>> 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.
>>>
>>> Jon
>>>
>>
>>
>
>
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
More information about the R-devel
mailing list