Re: [Rd] unit testing for R packages?
If you haven't done so already, you might want to read the RUnit Vignette: http://cran.r-project.org/web/packages/RUnit/vignettes/RUnit.pdf. On a somewhat related note: is anyone doing "continuous integration" with their R packages? I'm thinking about trying to use something like CruiseControl (which I used before for Java development), and was wondering if anyone had experience with how much work will be involved... On Mon, Oct 5, 2009 at 3:01 PM, Blair Christian wrote: > Hi All, > > 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. > > Right now I'm writing the classes/methods, but will be packaging it up > soon. > > Thx, > Blair > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ 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 think the problem is more subtle than Spencer implies. It is good to have as much documentation as possible. However, if a help file is long and complex, then people get intimidated and don't read it at all. It would be nice to have a feature so that help files can be displayed with different levels of detail. A sophisticated version of this scheme might even assume different levels of knowledge of the user so that the least detailed level might be longer (but easier) than a more detailed level. Patrick Burns patr...@burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of "The R Inferno" and "A Guide for the Unwilling S User") spencerg wrote: 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() gives odd looking output on complex vectors that are not purely imaginary (PR#13985)
> "RC" == Rich Calaway > on Tue, 6 Oct 2009 01:00:10 +0200 (CEST) writes: RC> Full_Name: Rich Calaway RC> Version: R 2.9.2 RC> OS: Windows Vista RC> Submission from: (NULL) (65.47.30.18) RC> Try this: RC> x <- rnorm(25) RC> y <- rnorm(25)*1i RC> z <- x+y RC> str(z) RC> str(y) RC> When I try this, I see the following: >> str(z) RC> cplx [1:25] 0.0102+ 0.9463-1 -1.+ ... >> str(y) RC> cplx [1:25] 0+0.0975i 0-1.5060i 0+0.4071i ... RC> I see this in 2.9.2 and in the alpha build of 2.10.0: Thank you, Rich. That is indeed a bug in prettyNum(*, drop0trailing=TRUE) which I will fix ASAP. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help file doesn't display correctly
Dear R Developer,
It seems to be a problem with help file. Not sure if it is related to
the new format of Rd parser. Multiple lines are joined together
without proper line break.
> ?mean
There were 14 warnings (use warnings() to see them)
## All lines are joined together and not easy to read.
> warnings()
Warning messages:
1: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
2: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
3: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
4: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
5: In grep("^[[:space:]]*$", buffer) : input string 4 is invalid in this locale
6: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
7: In grep("^[[:space:]]*$", buffer) : input string 6 is invalid in this locale
8: In grep("^[[:space:]]*$", buffer) : input string 7 is invalid in this locale
9: In grep("^[[:space:]]*$", buffer) : input string 9 is invalid in this locale
10: In grep("^[[:space:]]*$", buffer) : input string 10 is invalid in
this locale
11: In grepl("^[[:space:]]*$", txt[1L]) :
input string 1 is invalid in this locale
12: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
13: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
14: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
> sessionInfo()
R version 2.10.0 alpha (2009-10-04 r49936)
i386-pc-mingw32
locale:
[1] LC_COLLATE=Chinese_People's Republic of China.936
LC_CTYPE=Chinese_People's Republic of China.936
[3] LC_MONETARY=Chinese_People's Republic of China.936 LC_NUMERIC=C
[5] LC_TIME=Chinese_People's Republic of China.936
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
--
HUANG Ronggui, Wincent
Doctoral Candidate
Dept of Public and Social Administration
City University of Hong Kong
Home page: http://asrr.r-forge.r-project.org/rghuang.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help file doesn't display correctly
On 10/6/2009 5:12 AM, Ronggui Huang wrote:
Dear R Developer,
It seems to be a problem with help file. Not sure if it is related to
the new format of Rd parser. Multiple lines are joined together
without proper line break.
Thanks, we're looking into it. Please try again in a day or two and let
us know if this is not fixed.
Duncan Murdoch
?mean
There were 14 warnings (use warnings() to see them)
## All lines are joined together and not easy to read.
warnings()
Warning messages:
1: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
2: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
3: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
4: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
5: In grep("^[[:space:]]*$", buffer) : input string 4 is invalid in this locale
6: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
7: In grep("^[[:space:]]*$", buffer) : input string 6 is invalid in this locale
8: In grep("^[[:space:]]*$", buffer) : input string 7 is invalid in this locale
9: In grep("^[[:space:]]*$", buffer) : input string 9 is invalid in this locale
10: In grep("^[[:space:]]*$", buffer) : input string 10 is invalid in
this locale
11: In grepl("^[[:space:]]*$", txt[1L]) :
input string 1 is invalid in this locale
12: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
13: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
14: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
sessionInfo()
R version 2.10.0 alpha (2009-10-04 r49936)
i386-pc-mingw32
locale:
[1] LC_COLLATE=Chinese_People's Republic of China.936
LC_CTYPE=Chinese_People's Republic of China.936
[3] LC_MONETARY=Chinese_People's Republic of China.936 LC_NUMERIC=C
[5] LC_TIME=Chinese_People's Republic of China.936
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help file doesn't display correctly
On Tue, 6 Oct 2009, Ronggui Huang wrote:
Dear R Developer,
It seems to be a problem with help file. Not sure if it is related to
the new format of Rd parser. Multiple lines are joined together
without proper line break.
It was a problem with the handling of fancy quotes in a DBCS encoding
(as used for CJK languages). We don't attempt to use them for
sQuote(), and will no longer attempt to use them for help. This will
take effect in r49952 and later, and seems to work for me in CP936.
It is not easy for us to test in Chinese Windows (most non-Chinese
editions do not support it, or need add-ons installed), so please keep
on reporting issues, particularly those with help (text, HTML, PDF?)
rendering.
?mean
There were 14 warnings (use warnings() to see them)
## All lines are joined together and not easy to read.
warnings()
Warning messages:
1: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
2: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
3: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
4: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
5: In grep("^[[:space:]]*$", buffer) : input string 4 is invalid in this locale
6: In grep("^[[:space:]]*$", buffer) : input string 5 is invalid in this locale
7: In grep("^[[:space:]]*$", buffer) : input string 6 is invalid in this locale
8: In grep("^[[:space:]]*$", buffer) : input string 7 is invalid in this locale
9: In grep("^[[:space:]]*$", buffer) : input string 9 is invalid in this locale
10: In grep("^[[:space:]]*$", buffer) : input string 10 is invalid in
this locale
11: In grepl("^[[:space:]]*$", txt[1L]) :
input string 1 is invalid in this locale
12: In grepl("^[[:blank:]]*$", buffer[length(buffer)]) :
input string 1 is invalid in this locale
13: In grep("^[[:space:]]*$", buffer) : input string 1 is invalid in this locale
14: In grep("^[[:space:]]*$", buffer) : input string 2 is invalid in this locale
sessionInfo()
R version 2.10.0 alpha (2009-10-04 r49936)
i386-pc-mingw32
locale:
[1] LC_COLLATE=Chinese_People's Republic of China.936
LC_CTYPE=Chinese_People's Republic of China.936
[3] LC_MONETARY=Chinese_People's Republic of China.936 LC_NUMERIC=C
[5] LC_TIME=Chinese_People's Republic of China.936
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
--
HUANG Ronggui, Wincent
Doctoral Candidate
Dept of Public and Social Administration
City University of Hong Kong
Home page: http://asrr.r-forge.r-project.org/rghuang.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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
Re: [Rd] unit testing for R packages?
> If you haven't done so already, you might want to read the RUnit Vignette: > http://cran.r-project.org/web/packages/RUnit/vignettes/RUnit.pdf. > On a somewhat related note: is anyone doing "continuous integration" with > their R packages? I'm thinking about trying to use something like > CruiseControl (which I used before for Java development), and was wondering > if anyone had experience with how much work will be involved... It's not quite continuous integration, but I've been working on some code for autotesting - i.e. any time your code or tests change, rerun the appropriate part of the test suite (as much as I can guess at that) Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unit testing for R packages?
On a related note: I recently started to set up CruiseControl ( http://cruisecontrol.sourceforge.net/) to do continuous integration with my R packages (along with my RUnit test cases). Has anyone had any luck with this before? I use it for other software and it provides a very nice interface... On Tue, Oct 6, 2009 at 10:33 AM, hadley wickham wrote: > > If you haven't done so already, you might want to read the RUnit > Vignette: > > http://cran.r-project.org/web/packages/RUnit/vignettes/RUnit.pdf. > > On a somewhat related note: is anyone doing "continuous integration" with > > their R packages? I'm thinking about trying to use something like > > CruiseControl (which I used before for Java development), and was > wondering > > if anyone had experience with how much work will be involved... > > It's not quite continuous integration, but I've been working on some > code for autotesting - i.e. any time your code or tests change, rerun > the appropriate part of the test suite (as much as I can guess at > that) > > Hadley > > > -- > http://had.co.nz/ > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help file doesn't display correctly
2009/10/6 Prof Brian Ripley : > On Tue, 6 Oct 2009, Ronggui Huang wrote: > >> Dear R Developer, >> >> It seems to be a problem with help file. Not sure if it is related to >> the new format of Rd parser. Multiple lines are joined together >> without proper line break. > > It was a problem with the handling of fancy quotes in a DBCS encoding (as > used for CJK languages). We don't attempt to use them for sQuote(), and > will no longer attempt to use them for help. This will take effect in > r49952 and later, and seems to work for me in CP936. > > It is not easy for us to test in Chinese Windows (most non-Chinese editions > do not support it, or need add-ons installed), so please keep on reporting > issues, particularly those with help (text, HTML, PDF?) rendering. As for the HTML help, it works if I launch it by help.start(), but the link becomes broken if I launch it by click menu "help- html help". -- HUANG Ronggui, Wincent Doctoral Candidate Dept of Public and Social Administration City University of Hong Kong Home page: http://asrr.r-forge.r-project.org/rghuang.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help file doesn't display correctly
On Tue, 6 Oct 2009, Ronggui Huang wrote: 2009/10/6 Prof Brian Ripley : On Tue, 6 Oct 2009, Ronggui Huang wrote: Dear R Developer, It seems to be a problem with help file. Not sure if it is related to the new format of Rd parser. Multiple lines are joined together without proper line break. It was a problem with the handling of fancy quotes in a DBCS encoding (as used for CJK languages). We don't attempt to use them for sQuote(), and will no longer attempt to use them for help. This will take effect in r49952 and later, and seems to work for me in CP936. It is not easy for us to test in Chinese Windows (most non-Chinese editions do not support it, or need add-ons installed), so please keep on reporting issues, particularly those with help (text, HTML, PDF?) rendering. As for the HTML help, it works if I launch it by help.start(), but the link becomes broken if I launch it by click menu "help- html help". That is the expected behaviour, since it uses static HTML help and no prebuilt package HTML pages are being shipped. I don't know if Duncan wants to change it to call an R function, but that would have the disadvantage of being unavailable when R is running (you will note that that menu item is not greyed out when Rgui is running computations, unlike most others). -- Brian D. Ripley, rip...@stats.ox.ac.uk 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
Re: [Rd] how to document stuff most users don't want to see
In some cases it would be nice to have a lot of examples explaining the different uses of different parameters instead of the more usual. I like the way in which log4j allows one to parameterise at runtime the verboseness of different parts of a runtime. So hypothetically (and assuming a lot!) one could have a default amount of help info and a different default amount of examples... so when printed the default info wouldn't be too overwhelming - but it would be possible to ask for more info. Sean On Tue, Oct 6, 2009 at 8:53 AM, Patrick Burns wrote: > I think the problem is more subtle > than Spencer implies. It is good > to have as much documentation as > possible. However, if a help file > is long and complex, then people > get intimidated and don't read it > at all. > > It would be nice to have a feature > so that help files can be displayed > with different levels of detail. A > sophisticated version of this scheme > might even assume different levels of > knowledge of the user so that the least > detailed level might be longer (but > easier) than a more detailed level. > > > > Patrick Burns > patr...@burns-stat.com > +44 (0)20 8525 0696 > http://www.burns-stat.com > (home of "The R Inferno" and "A Guide for the Unwilling S User") > > > > spencerg wrote: > >> 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 >>> >>> >>> >> >> >> > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]]
Re: [Rd] Help file doesn't display correctly
On 10/6/2009 12:01 PM, Prof Brian Ripley wrote: On Tue, 6 Oct 2009, Ronggui Huang wrote: 2009/10/6 Prof Brian Ripley : On Tue, 6 Oct 2009, Ronggui Huang wrote: Dear R Developer, It seems to be a problem with help file. Not sure if it is related to the new format of Rd parser. Multiple lines are joined together without proper line break. It was a problem with the handling of fancy quotes in a DBCS encoding (as used for CJK languages). We don't attempt to use them for sQuote(), and will no longer attempt to use them for help. This will take effect in r49952 and later, and seems to work for me in CP936. It is not easy for us to test in Chinese Windows (most non-Chinese editions do not support it, or need add-ons installed), so please keep on reporting issues, particularly those with help (text, HTML, PDF?) rendering. As for the HTML help, it works if I launch it by help.start(), but the link becomes broken if I launch it by click menu "help- html help". That is the expected behaviour, since it uses static HTML help and no prebuilt package HTML pages are being shipped. I don't know if Duncan wants to change it to call an R function, but that would have the disadvantage of being unavailable when R is running (you will note that that menu item is not greyed out when Rgui is running computations, unlike most others). I think it is better to make the change, so that the help pages are available. You can jump between pages once the browser is open (hopefully the server is handling this safely; it hasn't crashed for me yet). I'll commit this... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] openNLP Segmentation Fault (PR#13986)
Full_Name: Michael Olschimke
Version: 2.9
OS: Ubuntu 8.04 TLS
Submission from: (NULL) (188.96.220.32)
When using openNLP (0.0-7) with rJava (0.7-0) with java-6-sun-1.6.0.07 on Ubuntu
8.04 TLS 32 bit I get the following error message (see below) when calling
tagPOS. I have installed the packages as super user, and using it as super user.
Sometimes the message does not appear but the desired behavior occurs (once or
twice).
tagPOS("dies ist ein test", language="de")
[itchy:08338] *** Process received signal ***
[itchy:08338] Signal: Segmentation fault (11)
[itchy:08338] Signal code: Invalid permissions (2)
[itchy:08338] Failing at address: 0xb7535100
[itchy:08338] [ 0] [0xb7eef440]
[itchy:08338] [ 1] [0xb4b2dc9f]
[itchy:08338] [ 2] [0xb4b36707]
[itchy:08338] [ 3] [0xb4b3658a]
[itchy:08338] [ 4] [0xb4b37496]
[itchy:08338] [ 5] [0xb4a9ed6a]
[itchy:08338] [ 6] [0xb4a9c249]
[itchy:08338] [ 7]
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so
[0x621c63d]
[itchy:08338] [ 8]
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so
[0x63107b8]
[itchy:08338] [ 9]
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so
[0x621c4d0]
[itchy:08338] [10]
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so
[0x6245d67]
[itchy:08338] [11]
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/lib/i386/client/libjvm.so
[0x622a1ca]
[itchy:08338] [12]
/usr/local/lib/R/site-library/rJava/libs/rJava.so(RcallMethod+0x6e1)
[0xb758c951]
[itchy:08338] [13] /usr/lib/R/lib/libR.so [0xb7c811a9]
[itchy:08338] [14] /usr/lib/R/lib/libR.so(Rf_eval+0x714) [0xb7ca9d04]
[itchy:08338] [15] /usr/lib/R/lib/libR.so [0xb7cad00e]
[itchy:08338] [16] /usr/lib/R/lib/libR.so(Rf_eval+0x451) [0xb7ca9a41]
[itchy:08338] [17] /usr/lib/R/lib/libR.so [0xb7cac28c]
[itchy:08338] [18] /usr/lib/R/lib/libR.so(Rf_eval+0x451) [0xb7ca9a41]
[itchy:08338] [19] /usr/lib/R/lib/libR.so [0xb7cab280]
[itchy:08338] [20] /usr/lib/R/lib/libR.so(Rf_eval+0x451) [0xb7ca9a41]
[itchy:08338] [21] /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac) [0xb7cad97c]
[itchy:08338] [22] /usr/lib/R/lib/libR.so(Rf_eval+0x349) [0xb7ca9939]
[itchy:08338] [23] /usr/lib/R/lib/libR.so [0xb7cab280]
[itchy:08338] [24] /usr/lib/R/lib/libR.so(Rf_eval+0x451) [0xb7ca9a41]
[itchy:08338] [25] /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac) [0xb7cad97c]
[itchy:08338] [26] /usr/lib/R/lib/libR.so(Rf_eval+0x349) [0xb7ca9939]
[itchy:08338] [27] /usr/lib/R/lib/libR.so [0xb7caee4f]
[itchy:08338] [28] /usr/lib/R/lib/libR.so(Rf_eval+0x1d8) [0xb7ca97c8]
[itchy:08338] [29] /usr/lib/R/lib/libR.so(Rf_eval+0x622) [0xb7ca9c12]
[itchy:08338] *** End of error message ***
Segmentation fault
__
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
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 -- Seth Falcon | @sfalcon | http://userprimary.net/user __ 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
