[Rd] building a libR.a for BlueGene/L
We would like to compile a minimal R library that could be linked into an application that will be run on a BlueGene/L system with 8,192 processors. This is a system that requires no shared libraries, no graphical interface, must be single threaded, and will be cross- compiled. I would statically link the code for the packages we require. From looking through the code, it seems like it should be possible to build such a version. However, it would be invaluable to have the advice and aid of the people who truly know this software. Thus far, I have configured the build to use the appropriate compilers. I had to tell configure that it was crosscompiling by editing the config.site file (it didn't recognize that it was). However, I am currently hitting a roadblock with configure failing with the report: WARNING: blrts_xlf and blrts_xlc disagree on int and double configure: error: Maybe change CFLAGS or FFLAGS The last lines in config.log are: #ifdef __cplusplus extern "C" void exit (int) throw (); configure: exit 1 Thank you very much for any assistance, Best Sean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Wiki: how useful for developers?
Thank you very much for this Philippe and everyone else who contibuted to the R Wiki. Great initiative and work. I'm interested in the 'R packages section' for adding extra help on my packages. What kind of backup is there for the wiki? Best Henrik On 6/18/06, Philippe Grosjean <[EMAIL PROTECTED]> wrote: > Hello all R developers, > > I just send the official annoucement of the R Wiki at > http://wiki.r-project.org (was also officially annouced at useR!2006). I > would like to insist here on the aspects of the Wiki that could be of > particular interest for you, as R developer: > > 1) The 'R documentation' section is dedicated to hold the latest > "wikified" version of all Rd files (base, recommended, as well as all > packages on CRAN and Bioconductor). Users can append exemple, discuss > points that are unclear for them, etc. at the end of these Wiki pages. > So, looking from time to time to these page is a good way to get > feedback from the users to improve your Rd files. (note that, currently > only base packages are on the Wiki; Also, several bugs in the Rd -> Wiki > conversion still need to be fixed, but that will be done as soon as > possible and all other Rd files will be published then). > > 2) The 'R packages' section of the Wiki is an ideal place to allow > developers *and* users of R packages to add useful material like further > examples, tutorials, tips, etc. related to your packages. Although this > section is still in development, here is how you can create a page for > your own package and advertise it: > > - After login to the R Wiki site, type this in the search box (top right > of any R Wiki page): > > packages:[cran|bioconductor|others]:[pckgname] > > with: [cran|bioconductor|others] depending on where you package is > located, and [pckgname] being the name of your package (note that the R > Wiki uses only lowercase letters for page names, so that your package > name will be automatically tranformed into lowercase in the URL of your > page) > > - An error message indicate that the page does not exist yet. Click on > 'Create this page' at the top left. > > - Start editing your page and click 'Save'. > > - Copy and paste the URL of your page in the URL section of your > description file. > > Best, > > Philippe Grosjean > -- > ..<°}))>< > ) ) ) ) ) > ( ( ( ( (Prof. Philippe Grosjean > ) ) ) ) ) > ( ( ( ( (Numerical Ecology of Aquatic Systems > ) ) ) ) ) Mons-Hainaut University, Mons, Belgium > ( ( ( ( (web: http://www.umh.ac.be/~econum > ) ) ) ) ) http://www.sciviews.org > ( ( ( ( ( > .. > > __ > 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] R Wiki: how useful for developers?
Henrik Bengtsson wrote: > Thank you very much for this Philippe and everyone else who contibuted > to the R Wiki. Great initiative and work. > > I'm interested in the 'R packages section' for adding extra help on my > packages. What kind of backup is there for the wiki? > > Best > > Henrik For the moment, there is a weekly backup of the whole data section done on another machine. I plan to make a daily backup on the same machine, keep all daily backups for 30 days, and then, keep only weekly backups for older data. There is also a plan to install another dedicated server equiped with a tape backup. Otherwise, **all** versions of your documents are saved and you can revert easily to any of those (in case of vandalism); see the 'Old revisions' button. Best, Philippe Grosjean > On 6/18/06, Philippe Grosjean <[EMAIL PROTECTED]> wrote: > >>Hello all R developers, >> >>I just send the official annoucement of the R Wiki at >>http://wiki.r-project.org (was also officially annouced at useR!2006). I >>would like to insist here on the aspects of the Wiki that could be of >>particular interest for you, as R developer: >> >>1) The 'R documentation' section is dedicated to hold the latest >>"wikified" version of all Rd files (base, recommended, as well as all >>packages on CRAN and Bioconductor). Users can append exemple, discuss >>points that are unclear for them, etc. at the end of these Wiki pages. >>So, looking from time to time to these page is a good way to get >>feedback from the users to improve your Rd files. (note that, currently >>only base packages are on the Wiki; Also, several bugs in the Rd -> Wiki >>conversion still need to be fixed, but that will be done as soon as >>possible and all other Rd files will be published then). >> >>2) The 'R packages' section of the Wiki is an ideal place to allow >>developers *and* users of R packages to add useful material like further >>examples, tutorials, tips, etc. related to your packages. Although this >>section is still in development, here is how you can create a page for >>your own package and advertise it: >> >>- After login to the R Wiki site, type this in the search box (top right >>of any R Wiki page): >> >>packages:[cran|bioconductor|others]:[pckgname] >> >>with: [cran|bioconductor|others] depending on where you package is >>located, and [pckgname] being the name of your package (note that the R >>Wiki uses only lowercase letters for page names, so that your package >>name will be automatically tranformed into lowercase in the URL of your >>page) >> >>- An error message indicate that the page does not exist yet. Click on >>'Create this page' at the top left. >> >>- Start editing your page and click 'Save'. >> >>- Copy and paste the URL of your page in the URL section of your >>description file. >> >>Best, >> >>Philippe Grosjean >>-- >>..<°}))>< >> ) ) ) ) ) >>( ( ( ( (Prof. Philippe Grosjean >> ) ) ) ) ) >>( ( ( ( (Numerical Ecology of Aquatic Systems >> ) ) ) ) ) Mons-Hainaut University, Mons, Belgium >>( ( ( ( (web: http://www.umh.ac.be/~econum >> ) ) ) ) ) http://www.sciviews.org >>( ( ( ( ( >>.. >> >>__ >>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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MacOS X - R crashes & import problem (PR#9005)
Full_Name: Oliver Balmer Version: 2.3.1 OS: Mac OS 10.4.6 Submission from: (NULL) (157.161.74.75) when working in the editor R crashes regularly. no other program ever crashes. one quite reliable way to crash it is by marking some code and then pressing the "find" command. I have had this problem with other R versions before. I have the feeling the editor is the problem. Another problem with the editor is that I always need to hit the carriage return twice after inserting the cursor at a certain point, after the first time, nothing happens. Not a big problem but probably not as it should be, and maybe a hint for a deeper problem. Another bug: if the imported data frame contains a µ (greek mu, as in microliter), R can't read the file. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X - R crashes & import problem (PR#9005)
[EMAIL PROTECTED] writes: > Another bug: if the imported data frame contains a µ (greek mu, as in > microliter), R can't read the file. Imported from what? If it is a text file, encoding issues may come into play, and a valid mu in one encoding can be an invalid character in another. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building a libR.a for BlueGene/L
Quoting the last few lines of config.log is not useful - you need to post the whole of it (or let it be downloaded from somewhere), since the error is a good deal further up. The error and fix is as it says - it seems that your fortran compiler (blrts_xlf) disagree with your C compiler (blrts_xlf) about how big is int and double (On most usual boxes these days int is 32-bit and double is 64-bit), and you will need to read your compiler's manual about what size are used for int and double accordingly; this is highly compiler-specific so you'll have to read it up yourself. Sean Hill wrote: > We would like to compile a minimal R library that could be linked > into an application that will be run on a BlueGene/L system with > 8,192 processors. This is a system that requires no shared libraries, > no graphical interface, must be single threaded, and will be cross- > compiled. I would statically link the code for the packages we require. > > From looking through the code, it seems like it should be possible > to build such a version. However, it would be invaluable to have the > advice and aid of the people who truly know this software. > > Thus far, I have configured the build to use the appropriate > compilers. I had to tell configure that it was crosscompiling by > editing the config.site file (it didn't recognize that it was). > However, I am currently hitting a roadblock with configure failing > with the report: > WARNING: blrts_xlf and blrts_xlc disagree on int and double > configure: error: Maybe change CFLAGS or FFLAGS > > The last lines in config.log are: > #ifdef __cplusplus > extern "C" void exit (int) throw (); > > configure: exit 1 > > Thank you very much for any assistance, > Best > Sean > > __ > 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] MacOS X - R crashes & import problem (PR#9005)
On Jun 19, 2006, at 11:43 AM, [EMAIL PROTECTED] wrote: > Full_Name: Oliver Balmer > Version: 2.3.1 > OS: Mac OS 10.4.6 > Submission from: (NULL) (157.161.74.75) > > > when working in the editor R crashes regularly. no other program > ever crashes. one quite reliable way to crash it is by marking some > code and then pressing the "find" command. Unfortunately I cannot reproduce this problem. A very common source of problems are 3rd-party haxies that are know to crash other applications. Please send me the crash report - without it we can't really do anything (it will also include important details you omitted like what Mac you are using etc.). > Another bug: if the imported data frame contains a µ (greek mu, as > in microliter), R can't read the file. > I cannot reproduce this either, it works flawlessly for me. As Peter mentioned earlier my guess is that you failed to use/define the correct encoding. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building a libR.a for BlueGene/L
On Mon, 19 Jun 2006, Sean Hill wrote: > > We would like to compile a minimal R library that could be linked > into an application that will be run on a BlueGene/L system with > 8,192 processors. This is a system that requires no shared libraries, > no graphical interface, must be single threaded, and will be cross- > compiled. I would statically link the code for the packages we require. > > From looking through the code, it seems like it should be possible > to build such a version. However, it would be invaluable to have the > advice and aid of the people who truly know this software. > > Thus far, I have configured the build to use the appropriate > compilers. I had to tell configure that it was crosscompiling by > editing the config.site file (it didn't recognize that it was). There is no support for cross-compiling R (except for Windows on Linux/...). This may explain the test failure below, as it runs an executable. > However, I am currently hitting a roadblock with configure failing > with the report: > WARNING: blrts_xlf and blrts_xlc disagree on int and double > configure: error: Maybe change CFLAGS or FFLAGS > > The last lines in config.log are: > #ifdef __cplusplus > extern "C" void exit (int) throw (); > > configure: exit 1 > > Thank you very much for any assistance, > Best > Sean > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.foreign (SPSS) writes illegal SPSS variable names (PR#9006)
Full_Name: Ulrich Keller
Version: Version 2.3.1 Patched (2006-06-05 r38290)
OS: Windows XP SP2
Submission from: (NULL) (158.64.77.159)
The variable names specified in SPSS syntax files created by
write.foreign(...,package="SPSS") contain hyphens ("-") if these were present in
the R variable names. Hyphens are illegal in SPSS variable names. As a result,
the syntax file is not executed by SPSS and no data is loaded.
According to the SPSS Base Syntax Guide, the only legal characters apart from
letters and numbers are "the period, underscore, and the characters $, #, and
@".
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Function hints
I've moved this from R-help to R-devel, where I think it is more
appropriate, and interspersed comments below.
On 6/19/2006 8:51 AM, hadley wickham wrote:
> One of the recurring themes in the recent UserR conference was that
> many people find it difficult to find the functions they need for a
> particular task. Sandy Weisberg suggested a small idea he would like
> to see: a hints function that given an object, lists likely
> operations. I've done my best to implement this function using the
> tools currently available in R, and my code is included at the bottom
> of this email (I hope that I haven't just duplicated something already
> present in R). I think Sandy's idea is genuinely useful, even in the
> limited form provided by my implementation, and I have already
> discovered a few useful functions that I was unaware of.
>
> While developing and testing this function, I ran into a few problems
> which, I think, represent underlying problems with the current
> documentation system. These are typified by the results of running
> hints on a object produced by glm (having class c("glm", "lm")). I
> have outlined (very tersely) some possible solutions. Please note
> that while these solutions are largely technological, the problem is
> at heart sociological: writing documentation is no easier (and perhaps
> much harder) than writing a scientific publication, but the rewards
> are fewer.
>
> Problems:
>
> * Many functions share the same description (eg. head, tail).
> Solution: each rdoc file should only describe one method. Problem:
> Writing rdoc files is tedious, there is a lot of information
> duplicated between the code and the documenation (eg. the usage
> statement) and some functions share a lot of similar information.
> Solution: make it easier to write documentation (eg. documentation
> inline with code), and easier to include certain common descriptions
> in multiple methods (eg. new include command)
I think it's bad to document dissimilar functions in the same file, but
similar related functions *should* be documented together. Not doing
this just adds to the burden of documenting them, and the risk of
modifying only part of the documentation so that it is inconsistent.
The user also gets the benefit of seeing a common description all at
once, rather than having to decide whether to follow "See also" links.
Your solutions would both be interesting on their own merits regardless
of the above. We did decide to work on preprocessing directives for .Rd
files at the R core meetings; some sort of include directive may be
possible.
I don't think I would want complete documentation mixed with the
original source, but it would certainly be interesting to have partial
documentation there. (Complete documentation is too long, and would
make it harder to read the source without a dedicated editor that could
hide it. Though ESS users may see it as a reasonable requirement to
have everyone use the same editor, I don't think it is.) However, this
is a lot of work, depending on infrastructure that is not in place.
> * It is difficult to tell which functions are commonly
> used/important. Solution: break down by keywords. Problem: keywords
> are not useful at the moment. Solution: make better list of keywords
> available and encourage people to use it. Problem: people won't
> unless there is a strong incentive, plus good keywording requires
> considerable expertise (especially in bulding up list). This is
> probably insoluable unless one person systematically keywords all of
> the base packages.
I think it is worse than that. There are concepts in packages that just
don't arise in base R, and hence there would be no keywords for them
other than "misc", even if someone redesigned the current system.
Keywording is hard, and it's not clear to me how to do much better than
we currently do.
We do already have user-defined keywords (via \concept), but these are
not widely used.
>
> * Some functions aren't documented (eg. simulate.lm, formula.glm) -
> typically, these are methods where the documentation is in the
> generic. Solution: these methods should all be aliased to the generic
> (by default?), and R CMD check should be amended to check for this
> situation. You could also argue that this is a deficiency with my
> function, and easily fixed by automatically referring to the generic
> if the specific isn't documented.
I'd say it's a deficiency of your function. You might want to look at
the code in get("?") and .helpForCall() to see how those functions work
out things like
?simulate(x)
where x is an lm object. (But notice that .helpForCall is an
undocumented internal function; don't depend on its implementation
working forever).
> * It can't supply suggestions when there isn't an explicit method
> (ie. .default is used), this makes it pretty useless for basic
> vectors. This may not really be a problem, as all possible operations
> are probably too
Re: [Rd] R Wiki: how useful for developers?
I also want to express my appreciation to the R Wiki developers. I used it 6/18/2006 12:46 PM in answering a post to s-news (citing something I learned from Venables and Ripley). Best Wishes, Spencer Graves Philippe Grosjean wrote: > Henrik Bengtsson wrote: >> Thank you very much for this Philippe and everyone else who contibuted >> to the R Wiki. Great initiative and work. >> >> I'm interested in the 'R packages section' for adding extra help on my >> packages. What kind of backup is there for the wiki? >> >> Best >> >> Henrik > > For the moment, there is a weekly backup of the whole data section done > on another machine. I plan to make a daily backup on the same machine, > keep all daily backups for 30 days, and then, keep only weekly backups > for older data. > > There is also a plan to install another dedicated server equiped with a > tape backup. > > Otherwise, **all** versions of your documents are saved and you can > revert easily to any of those (in case of vandalism); see the 'Old > revisions' button. > > Best, > > Philippe Grosjean > >> On 6/18/06, Philippe Grosjean <[EMAIL PROTECTED]> wrote: >> >>> Hello all R developers, >>> >>> I just send the official annoucement of the R Wiki at >>> http://wiki.r-project.org (was also officially annouced at useR!2006). I >>> would like to insist here on the aspects of the Wiki that could be of >>> particular interest for you, as R developer: >>> >>> 1) The 'R documentation' section is dedicated to hold the latest >>> "wikified" version of all Rd files (base, recommended, as well as all >>> packages on CRAN and Bioconductor). Users can append exemple, discuss >>> points that are unclear for them, etc. at the end of these Wiki pages. >>> So, looking from time to time to these page is a good way to get >>> feedback from the users to improve your Rd files. (note that, currently >>> only base packages are on the Wiki; Also, several bugs in the Rd -> Wiki >>> conversion still need to be fixed, but that will be done as soon as >>> possible and all other Rd files will be published then). >>> >>> 2) The 'R packages' section of the Wiki is an ideal place to allow >>> developers *and* users of R packages to add useful material like further >>> examples, tutorials, tips, etc. related to your packages. Although this >>> section is still in development, here is how you can create a page for >>> your own package and advertise it: >>> >>> - After login to the R Wiki site, type this in the search box (top right >>> of any R Wiki page): >>> >>> packages:[cran|bioconductor|others]:[pckgname] >>> >>> with: [cran|bioconductor|others] depending on where you package is >>> located, and [pckgname] being the name of your package (note that the R >>> Wiki uses only lowercase letters for page names, so that your package >>> name will be automatically tranformed into lowercase in the URL of your >>> page) >>> >>> - An error message indicate that the page does not exist yet. Click on >>> 'Create this page' at the top left. >>> >>> - Start editing your page and click 'Save'. >>> >>> - Copy and paste the URL of your page in the URL section of your >>> description file. >>> >>> Best, >>> >>> Philippe Grosjean >>> -- >>> ..<°}))>< >>> ) ) ) ) ) >>> ( ( ( ( (Prof. Philippe Grosjean >>> ) ) ) ) ) >>> ( ( ( ( (Numerical Ecology of Aquatic Systems >>> ) ) ) ) ) Mons-Hainaut University, Mons, Belgium >>> ( ( ( ( (web: http://www.umh.ac.be/~econum >>> ) ) ) ) ) http://www.sciviews.org >>> ( ( ( ( ( >>> .. >>> >>> __ >>> 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 >> >> > > __ > 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] Compiling R with ACML on FC5, gcc 4.1.1
I'm trying to compile R with the AMD core math library (ACML) on Fedora Core 5 with gcc 4.1.1 and am having difficulty getting R to recognize it. I'm using the file acml-3-1-0-gfortran-64bit.tgz from the AMD website. On Fedora Core 4 I had no trouble getting this to work (with gcc 4.0.2) but I seem to be missing something now. Has anyone had any problems and/or luck? Thanks for any tips, -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: [R-SIG-Mac] Window titles
On Mon, 19 Jun 2006, Simon Urbanek wrote:
> On Jun 17, 2006, at 8:02 AM, Paul Roebuck wrote:
>
> > Is there a means to provide a title for a Quartz window?
>
> Yes, now introduced in 3244: you can specify the desired name in the
> call to quartz, e.g.
> quartz("My Precious Plot")
> We have never used the device name, so now we have at least some use
> for it ;). Thanks for the request. Apparently the description for the
> `quartz' command is bogus as well, it is copied from the X11 device
> and the device parameter makes no sense at all. I'll think about some
> more reasonable parameters/description for R-devel.
>
> > When running code that creates lots of plots, it would be nice to
> > be able to choose the desired window based on its title rather than
> > attempting to remember the associated window number. Even better if
> > the Window menu could display this information as well.
>
> Yes, the window title and the windows menu are directly linked.
Think there's any chance of getting a 'title' argument
being added to all the interactive devices, even if just
as a placeholder (not implemented on this device)? All
windowing environments provide the means to handle this
capability. Haven't tried it but title should be able to
be done with X11 already (indirectly) via XWindow resources.
I am unaware of a documented list of arguments available
for use by any interactive device. Since the code I write
passes its arguments to the default interactive device, it
would be preferable to avoid "unused argument" errors when
run with alternative devices.
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Function hints
[This is not about the feasibility of a "hints" function-- which would
be incredibly useful, but perhaps very very hard to do-- but about some
of the other documentation issues raised in Hadley's post and in
Duncan's reply]
WRTO documentation & code together: for several years, I've successfully
used the 'mvbutils' package to keep every function definition & its
documentation together, editing them together in the same file--
function first, then documentation in plain-text (basically the format
you see if you use "vanilla help" inside R). Storage-wise, the
documentation is just kept as an attribute of the function (with a print
method that hides it by default)-- I also keep a text backup of the
combination. Any text editor will do. When it's time to create a
package, the Rd file is generated automatically.
For me, it's been extremely helpful to keep function & documentation
together during editing-- it greatly increases the chance that I will
actually update the doco when I change the code, rather than putting it
off until I've forgotten what I did. Also, writing Rd format is a
nightmare (again, personal opinion)-- being able to write plain-text
makes the whole documentation thing bearable.
The above is not quite to the point of the original post, I think, which
talks about storing the documentation as commented bits *inside* the
function code. However, I'm not sure the latter is really desirable;
there is some merit in forcing authors to write an explicit "Details" or
"Description" section that is not just a paraphrase of programming
comments, and such sections are unlikely to fit easily inside code. At
any rate, I wouldn't want to have to interpret my *own* programming
comments as a usage guide!
WRTO automatic "usage" sections: it is easy to write code to do this
('prompt', and there is also some in 'mvbutils'-- not sure if it's in
the current release though) but at least as far as the "usage" section
goes, I think people should be "vigorously encouraged" to write their
own, showing as far as possible how one might actually *use* the
function. For many functions, just duplicating the argument list is not
helpful to the user-- a function can often be invoked in several
different ways, with different arguments relevant to different
invocations. I think it's good to show how this can be done in the
"usage" section, with comments, rather than deferring all practical
usage to "examples". For one thing, "usage" is near the top, and so
gives a very quick reminder without having to scroll through the entire
doco; for another, "usage" and "arguments" are visually adjacent,
whereas "examples" can be widely separated from "arguments".
My general point here is: the documentating process should be as
painless as possible, but not more so. Defaults that are likely to lead
to unhelpful documentation are perhaps best avoided.
For this general reason, I applaud R's fairly rigid documentation
standards, even though I frequently curse them. (And I would like to see
some bits more rigid, such as compulsory "how-to-use-this" documentation
for each package!)
The next version of 'mvbutils' will include various tools for easy "live
editing" and automated preparation of packages-- I've been using them
for a while, but still have to get round to finishing the documentation
;)
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Murdoch
> Sent: Tuesday, 20 June 2006 12:39 AM
> To: hadley wickham; R-devel
> Subject: Re: [Rd] [R] Function hints
>
> I've moved this from R-help to R-devel, where I think it is
> more appropriate, and interspersed comments below.
>
>
>
> On 6/19/2006 8:51 AM, hadley wickham wrote:
> > One of the recurring themes in the recent UserR conference was that
> > many people find it difficult to find the functions they need for a
> > particular task. Sandy Weisberg suggested a small idea he
> would like
> > to see: a hints function that given an object, lists likely
> > operations. I've done my best to implement this function using the
> > tools currently available in R, and my code is included at
> the bottom
> > of this email (I hope that I haven't just duplicated
> something already
> > present in R). I think Sandy's idea is genuinely useful,
> even in the
> > limited form provided by my implementation, and I have already
> > discovered a few useful functions that I was unaware of.
> >
> > While developing and testing this function, I ran into a
> few problems
> > which, I think, represent underlying problems with the current
> > documentation system. These are typified by the results of running
> > hints on a object produced by glm (having class c("glm", "lm")). I
> > have outlined (very tersely) some possible solutions. Please note
> > that while these so
