[Rd] utils package: .Rd to .dvi (PR#9079)
# R for Windows will not send your bug report automatically.
# Please copy the bug report (after finishing it) to
# your favorite email program and send it to
#
# [EMAIL PROTECTED]
#
##
I am building a package. I discovered that all \usage{} and
\examples{} in the .Rd file that are too long to fit on the .dvi page
are left as is. They run over the edge of the page and just keep on
going.
I propose that a WARNING or ERROR be generated as part of Rcmd check
for such cases.
The "test <-" line and both "test(" lines below are single lines.
My mailer folds at about 100 characters.
Rich
## test/R/test.R
test <- function(this, is, a, very, long, argument, list, designed, to, show,
the, difficulty,
with, .Rd, To, .dvi, conversion) {
"Hello, World!"
}
## end test/R/test.R
## test/man/test.Rd
\name{test}
\alias{test}
\title{demonstrate a problem}
\description{demonstrate a problem}
\usage{
test(this, is, a, very, long, argument, list, designed, to, show, the,
difficulty, with, .Rd,
To, .dvi, conversion)
}
\arguments{
\item{this}{}
\item{is}{}
\item{a}{}
\item{very}{}
\item{long}{}
\item{argument}{}
\item{list}{}
\item{designed}{}
\item{to}{}
\item{show}{}
\item{the}{}
\item{difficulty}{}
\item{with}{}
\item{.Rd}{}
\item{To}{}
\item{.dvi}{}
\item{conversion}{}
}
\examples{
test(this, is, a, very, long, argument, list, designed, to, show, the,
difficulty, with, .Rd,
To, .dvi, conversion)
}
\keyword{package}
## end test/man/test.Rd
## test/DESCRIPTION
Package: test
Type: Package
Title: demonstrate a problem
Version: 1.0
Date: 2006-05-15
Author: Richard M. Heiberger
Maintainer: Richard M. Heiberger <[EMAIL PROTECTED]>
Depends: R (>= 2.3.1)
Description: demonstrate a problem
License: GPL version 2 or newer
## test/DESCRIPTION
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 3.1
year = 2006
month = 06
day = 01
svn rev = 38247
language = R
version.string = Version 2.3.1 (2006-06-01)
Windows XP Professional (build 2600) Service Pack 2.0
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
Search Path:
.GlobalEnv, package:methods, package:stats, package:utils, package:datasets,
file:c:/HOME/rmh/h2/library/H2/.RData,
file:c:/HOME/rmh/hh/splus.library/HH/.RData,
package:multcomp, package:mvtnorm, package:graphics, package:lattice,
package:grid,
package:grDevices, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R as shell script
Hi,
I am considering if I should invest in learning R. Based on the
language definition and introductory documents, it seems nice. But now
I am faced with a problem: I want to be able to run R programs easily
from the unix shell, and write scripts that can automatically select R
as the interpreter:
#!/usr/bin/R
cat("Hello world.\n")
This of course doesn't work, because /usr/bin/R is a shell script.
I have been able to create a binary wrapper that calls R with the
correct arguments, which is documented here:
http://kavaro.fi/mediawiki/index.php/Using_R_from_the_shell
This still lacks eg. standard input (but I have no idea how I can
implement it in R) and full command line argument passing (can be
done), but am I on the right track, or is there already something that
does what I need?
juha
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dweibull retuns NaN instead of Inf (PR#9080)
Full_Name: Göran Broström Version: 2.3.1 OS: Linux, ubuntu Submission from: (NULL) (85.11.40.53) > dweibull(0, 0.5, 1) [1] NaN Warning message: NaNs produced in: dweibull(x, shape, scale, log) should give Inf (and no Warning). Compare with > dgamma(0, 0.5, 1) [1] Inf This happens when 'shape' < 1. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R as shell script
Juha Vierinen wrote:
> Hi,
>
> I am considering if I should invest in learning R. Based on the
> language definition and introductory documents, it seems nice. But now
> I am faced with a problem: I want to be able to run R programs easily
> from the unix shell, and write scripts that can automatically select R
> as the interpreter:
>
> #!/usr/bin/R
> cat("Hello world.\n")
>
> This of course doesn't work, because /usr/bin/R is a shell script.
>
> I have been able to create a binary wrapper that calls R with the
> correct arguments, which is documented here:
>
> http://kavaro.fi/mediawiki/index.php/Using_R_from_the_shell
>
> This still lacks eg. standard input (but I have no idea how I can
> implement it in R) and full command line argument passing (can be
> done), but am I on the right track, or is there already something that
> does what I need?
If you search the mailing list archives:
http://tolstoy.newcastle.edu.au/R/
you can find entries like the following (searching on "bang"):
http://tolstoy.newcastle.edu.au/R/devel/05/01/1910.html
which implements similar functionality. But I thought this would be a
fun little (distracting) project, so I created an R wiki page:
http://wiki.r-project.org/rwiki/doku.php?id=developers:rinterp
with source code describing how to solve this problem by embedding R
within your C program. Here's the main function:
/* rinterp: shebang support for R
*
* Usage:
*
* From the command line:
* $ rinterp filename
*
* In a file:
*
* #!/path/to/rinterp
* cat("hello world\n");
*
*/
int main(int argc, char **argv){
/* R embedded arguments */
char *R_argv[] = {"RINTERP", "--gui=none", "--slave", "--silent",
"--vanilla","--no-readline"};
int R_argc = sizeof(R_argv)/sizeof(R_argv[0]);
struct stat sbuf;
/* Setenv R_HOME: insert or replace into environment.
* The RHOME macro is defined during configure
*/
if (setenv("R_HOME",RHOME,1) != 0){
perror("ERROR: couldn't set/replace R_HOME");
exit(1);
}
/* Assume last argument is the file we want to source.
* Ignore other args for now.
*/
if (argc > 1) {/* don't try and source rinterp binary */
if (stat(argv[argc-1],&sbuf) != 0){
perror(argv[argc-1]);
exit(1);
}
} else {
fprintf(stderr,"Usage: rinterp filename\n");
exit(1);
}
/* Initialize R interpreter */
Rf_initEmbeddedR(R_argc, R_argv);
/* Now call R function source(filename) */
call_fun1str("source",argv[argc-1]);
exit(0);
}
Feel free to logon to the R wiki and contribute to the page. I think it
would be interesting to solve this once and for all.
Cheers!
--
Jeffrey Horner Computer Systems Analyst School of Medicine
615-322-8606 Department of Biostatistics Vanderbilt University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dialog box does not go away (PR#9081)
Full_Name: Pat Lorch Version: Version 2.3.1 (2006-06-01) OS: OS X 10.4.7 Submission from: (NULL) (131.123.232.162) I have noticed that when I save a Quartz graphic and sometimes when I source a file, the dialog box persists and causes certain functions (Quit and Load/Save Default Workspace) to be grayed out. I must then Force quit and I lose changes made since last save.image(). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] chron vs. POSIX
Hi, One of the big decisions when writing code is how to handle dates and times. Gabor Grothendieck provided an excellent overview of the issue in his R News 4/1 (2004) article, and many users and developers are probably using it as a guide. The proposed guideline is to use the simplest class required; as Gabor put it "use Date if possible, otherwise use chron, and otherwise use POSIX". This seems to me a very efficient strategy, judging from my own experiences and those of others users. All but the simplest calculations with POSIX objects demand great care, due to time zone and and daylight savings considerations. Therefore, I've always chosen chron for relatively complex projects, where I don't need to deal with time zones or daylight savings problems. The ease with which objects can be switched from numeric to chron representations is a major advantage IMHO¹. If Gabor's recommendations are to be followed, wouldn't it make sense to include chron in base R? Given that flexibility for handling time variables is so fundamental, the addition of chron to base R would provide users everything they need to work with time, without the need to rely on an external package. What do others think? + *Footnotes* + ¹ This is possible with POSIX classes too by using the structure() function, but a post by Brian Ripley to the effect that it may not be practical in the long term further convinced me of this. -- Sebastian P. Luque Department of Biology Memorial University of Newfoundland [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 14 July 2006 at 14:38, Sebastian Luque wrote: | If Gabor's recommendations are to be followed, wouldn't it make sense to | include chron in base R? Given that flexibility for handling time Future historians will provide a fuller account of the extended debates, but my reading of these discussions here over the last few years leaves me with the impression that Gabor is arguing for chron in a manner that is simultaneously informed, polite, persistent and yet ... utterly isolated. Date and POSIXt have served me well over the last few years. They are maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is dead code so I'd bet against it appearing in core R any time soon. Regards, Dirk [ 1 ] I had some pleasant exchanges with Brian Ripley where I was able to suggest a few extension relative to the new millisecond granularity in POSIXt and its interfaces. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 7/14/06, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > On 14 July 2006 at 14:38, Sebastian Luque wrote: > | If Gabor's recommendations are to be followed, wouldn't it make sense to > | include chron in base R? Given that flexibility for handling time > > Future historians will provide a fuller account of the extended debates, but > my reading of these discussions here over the last few years leaves me with > the impression that Gabor is arguing for chron in a manner that is > simultaneously informed, polite, persistent and yet ... utterly isolated. > > Date and POSIXt have served me well over the last few years. They are > maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is > dead code so I'd bet against it appearing in core R any time soon. > > Regards, Dirk > > [ 1 ] I had some pleasant exchanges with Brian Ripley where I was able to > suggest a few extension relative to the new millisecond granularity in POSIXt > and its interfaces. Recent releases of chron include - July 14th (today!), see http://cran.r-project.org/src/contrib/Descriptions/chron.html - June 23rd (less than one month ago), - May 9th (two months ago) (this may not be a complete list of recent releases) so I would characterize chron as actively maintained and given the occasional question on r-help its likely that its widely used too. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: On 14 July 2006 at 14:38, Sebastian Luque wrote: | If Gabor's recommendations are to be followed, wouldn't it make sense to | include chron in base R? Given that flexibility for handling time Future historians will provide a fuller account of the extended debates, but my reading of these discussions here over the last few years leaves me with the impression that Gabor is arguing for chron in a manner that is simultaneously informed, polite, persistent and yet ... utterly isolated. Date and POSIXt have served me well over the last few years. They are maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is dead code so I'd bet against it appearing in core R any time soon. Regards, Dirk [ 1 ] I had some pleasant exchanges with Brian Ripley where I was able to suggest a few extension relative to the new millisecond granularity in POSIXt and its interfaces. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 14 July 2006 at 16:32, Gabor Grothendieck wrote: | On 7/14/06, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: | > Date and POSIXt have served me well over the last few years. They are | > maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is | > dead code so I'd bet against it appearing in core R any time soon. [...] | Recent releases of chron include | | - July 14th (today!), see | http://cran.r-project.org/src/contrib/Descriptions/chron.html | | - June 23rd (less than one month ago), | | - May 9th (two months ago) | | (this may not be a complete list of recent releases) so I would characterize | chron as actively maintained and given the occasional question on r-help | its likely that its widely used too. Shows you what 'the best of my knowledge' is worth :) I must have confused it with the date package where the sole change in the last 2+ years was the addition of a file inst/CITATION. Sorry for spreading misinformation. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
[Sorry for my previous empty post]
Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> On 14 July 2006 at 14:38, Sebastian Luque wrote:
> | If Gabor's recommendations are to be followed, wouldn't it make sense
> | to include chron in base R? Given that flexibility for handling time
> Future historians will provide a fuller account of the extended debates,
> but my reading of these discussions here over the last few years leaves
> me with the impression that Gabor is arguing for chron in a manner that
> is simultaneously informed, polite, persistent and yet ... utterly
> isolated.
> Date and POSIXt have served me well over the last few years. They are
> maintained and being extended [ 1 ]. Chron, to the best of my knowledge,
> is dead code so I'd bet against it appearing in core R any time soon.
That is not true, as Gabor pointed out. At any rate, I can't understand
why there's only a choice between a dates-only class and another one
including every detail of time in R base. As mentioned in Gabor's R News
article, the latter requires the user to pay attention to time zones and
daylight savings details that are completely irrelevant in some cases.
The drawbacks of using POSIX classes, in cases where TZ and DS are
irrelevant, can be quite serious when writing relatively complex code¹.
[...]
Cheers,
+ *Footnotes* +
¹ In addition to the list in the R News article, there's also issues with
TZ attribute being lost after operations such as 'sapply' with POSIX
objects. Spotting that problem, and how to recover your POSIX object
after that is not as simple as doing chron('sapply return value').
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 7/14/2006 3:38 PM, Sebastian Luque wrote: > Hi, > > One of the big decisions when writing code is how to handle dates and > times. Gabor Grothendieck provided an excellent overview of the issue in > his R News 4/1 (2004) article, and many users and developers are probably > using it as a guide. The proposed guideline is to use the simplest class > required; as Gabor put it "use Date if possible, otherwise use chron, and > otherwise use POSIX". > > This seems to me a very efficient strategy, judging from my own > experiences and those of others users. All but the simplest calculations > with POSIX objects demand great care, due to time zone and and daylight > savings considerations. Therefore, I've always chosen chron for > relatively complex projects, where I don't need to deal with time zones or > daylight savings problems. The ease with which objects can be switched > from numeric to chron representations is a major advantage IMHO¹. > > If Gabor's recommendations are to be followed, wouldn't it make sense to > include chron in base R? Given that flexibility for handling time > variables is so fundamental, the addition of chron to base R would provide > users everything they need to work with time, without the need to rely on > an external package. What do others think? Putting something into base R essentially means that it is to be taken over by R core. I think chron is being adequately maintained now (the R maintainer is already a member of R core), so I don't see a need for that. I don't see a problem having a package on CRAN. If it's a good package and people realize that it's good, and it remains available for others to use, then what problem is being solved? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
