Re: [Rd] dependencies on system packages
Dear all, From the writing extensions manual: "Other dependencies (external to the R system) should be listed in the ‘SystemRequirements’ field, possibly amplified in a separate README file." I guess one problem is the user may not realize that the -dev version is needed, and just sees libxml2 installed but the R package installation stopping with the respective error. Giving the package name for specific distributions is of course polite (if the developer knows it). As developer you may also put into the README that the package's mailing list/forum/wiki/... contains information and ask the user to enter the package name on his distro if it is not already there. my 2 ct Claudia Am 04.02.2011 04:48, schrieb Simon Urbanek: Jeroen, On Feb 3, 2011, at 9:31 PM, Jeroen Ooms wrote: Many R packages depend on some unix libraries that are not part of most default installations. I often spend a significant amount of time figuring out where to get the appropriate libraries for compiling these packages, after they give some vague error of something missing. I was wondering why there is no formal system of specifying non-R dependencies in the DESCRIPTION file. If this would be the case, then during the installation of an R package, the user could be prompted to install required system packages (if they have appropriate privileges). So for example: Package: XML Version: 3.2-0 Depends: R (>= 1.2.0), methods, utils Depends-debian: libxml2-dev Depends-ubuntu: libxml2-dev Depends-redhat: libxml2-devel Depends-suse: libxml2-devel etc. This might make life for many people just a little easier. If they are root and the package is in their system repositories, than it will install automatically. If not, at least they know for which package to look, or request their sys admin to install. Well, there is already such system in place and it is the corresponding descriptions in the distributions. Obviously as an author of the package I don't care what any particular Linux distribution uses as a name for the needed dependencies as the corresponding chaos is distribution-specific. The only person who can reasonably determine the dependencies is the maintainer of the distribution and that's what they do and as a user of the above mentioned distributions you should be thankful to them. Fortunately, normal users don't have to worry about it as major distributions already come with a large set of R packages resolving all dependencies. Hence I don't see any reason why this should have anything to do with the DESCRIPTION file. The improvements I could think of would be a parseable entry or a canonical pointer to dependency sources, but that's a whole another story. Cheers, Simon __ 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] Strange behaviour of read and writeBin
To me it seems like writeBin() writes one char/byte more than expected.
> con <- file("testbin", "wb")
> writeBin("ttccggaa", con)
> close(con)
> con <- file("testbin", "rb")
> readBin(con, what="character")
[1] "ttccggaa"
> seek(con, what=NA)
[1] 9
> close(con)
> con <- file("testbin", "rb")
> readBin(con, what="raw", n=20)
[1] 74 74 63 63 67 67 61 61 00
> seek(con, what=NA)
[1] 9
> close(con)
As the numbering starts with 0 the position should be 8 and not 9 after
reading. There were two older threads which look very similar to my problem:
http://tolstoy.newcastle.edu.au/R/e2/devel/06/11/1119.html
http://r.789695.n4.nabble.com/Re-Problem-reading-binaries-created-with-fortran-More-infos-td974396.html
Thanks in advance,
Christian
> sessionInfo()
R version 2.12.0 (2010-10-15)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Biostrings_2.18.2 IRanges_1.8.8
loaded via a namespace (and not attached):
[1] Biobase_2.10.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of read and writeBin
from ?seek
‘seek’ returns the current position (before any move), as a
(numeric) byte offset from the origin, if relevant, or ‘0’ if not.
Your string is nul terminated (9 bytes long). That would be the
current offset. If you only read one byte, you'd have to be more than
0 bytes offset.
Jeff
On Fri, Feb 4, 2011 at 4:35 AM, Christian Ruckert
wrote:
> To me it seems like writeBin() writes one char/byte more than expected.
>
>> con <- file("testbin", "wb")
>> writeBin("ttccggaa", con)
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="character")
> [1] "ttccggaa"
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="raw", n=20)
> [1] 74 74 63 63 67 67 61 61 00
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
> As the numbering starts with 0 the position should be 8 and not 9 after
> reading. There were two older threads which look very similar to my problem:
>
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/11/1119.html
> http://r.789695.n4.nabble.com/Re-Problem-reading-binaries-created-with-fortran-More-infos-td974396.html
>
> Thanks in advance,
> Christian
>
>
>
>> sessionInfo()
> R version 2.12.0 (2010-10-15)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
> [1] C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] Biostrings_2.18.2 IRanges_1.8.8
>
> loaded via a namespace (and not attached):
> [1] Biobase_2.10.0
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of read and writeBin
On 04/02/2011 5:35 AM, Christian Ruckert wrote:
To me it seems like writeBin() writes one char/byte more than expected.
You want writeChar rather than writeBin to avoid the null termination of
strings.
Duncan Murdoch
> con<- file("testbin", "wb")
> writeBin("ttccggaa", con)
> close(con)
> con<- file("testbin", "rb")
> readBin(con, what="character")
[1] "ttccggaa"
> seek(con, what=NA)
[1] 9
> close(con)
> con<- file("testbin", "rb")
> readBin(con, what="raw", n=20)
[1] 74 74 63 63 67 67 61 61 00
> seek(con, what=NA)
[1] 9
> close(con)
As the numbering starts with 0 the position should be 8 and not 9 after
reading. There were two older threads which look very similar to my problem:
http://tolstoy.newcastle.edu.au/R/e2/devel/06/11/1119.html
http://r.789695.n4.nabble.com/Re-Problem-reading-binaries-created-with-fortran-More-infos-td974396.html
Thanks in advance,
Christian
> sessionInfo()
R version 2.12.0 (2010-10-15)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Biostrings_2.18.2 IRanges_1.8.8
loaded via a namespace (and not attached):
[1] Biobase_2.10.0
__
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] keep.source when semicolons separate statements on the one line
Thanks for the report. I'll take a look.
I'm now past one major time sink, and will have some time to catch up on
old problems; I'll add this to that list.
Duncan Murdoch
On 03/02/2011 7:09 PM, John Maindonald wrote:
The following is 'semicolon.Rnw'
> \SweaveOpts{engine=R, keep.source=TRUE}
>
> <>=
> library(SMIR); data(bronchit); library(KernSmooth)
> @ %
>
> Code for panel A is
> <>=
> <>
> @ %
Sweave("semicolon") yields the following 'semicolon.tex'
> Code for panel A is
> \begin{Schunk}
> \begin{Sinput}
>> library(SMIR); data(bronchit); library(KernSmooth)
>> library(SMIR); data(bronchit); library(KernSmooth)
>> library(SMIR); data(bronchit); library(KernSmooth)
> \end{Sinput}
> \end{Schunk}
(I have omitted three blank lines at the start)
With keep.source=FALSE, the commands are split onto
separate lines, and there is no repetition.
John Maindonald email: john.maindon...@anu.edu.au
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics& Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
http://www.maths.anu.edu.au/~johnm
__
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] dependencies on system packages
Claudia, thanks for you comments . On Feb 4, 2011, at 3:18 AM, Claudia Beleites wrote: > Dear all, > > From the writing extensions manual: > "Other dependencies (external to the R system) should be listed in the > ‘SystemRequirements’ field, possibly amplified in a separate README file." > > I guess one problem is the user may not realize that the -dev version is > needed, and just sees libxml2 installed but the R package installation > stopping with the respective error. > I'd argue that if a user attempts to install a package from sources instead of using the distribution binaries, he should know what he's doing as there is much more involved (proper tools, usually a different library location etc.). And anyone who knows what he's doing also knows that -dev packages are needed (at the latest when the installation fails you remember ;)). If he doesn't then it should give him a clue that he may want to use something else (and especially Linux users should know better ;)). Clearly, it doesn't prevent users from doing stupid things and I completely agree with you that the README should have the instructions as far as the developer knows. And as a package developer you'll learn soon enough when people start complaining ;). Thanks, Simon > Giving the package name for specific distributions is of course polite (if > the developer knows it). As developer you may also put into the README that > the package's mailing list/forum/wiki/... contains information and ask the > user to enter the package name on his distro if it is not already there. > > > my 2 ct > > Claudia > > > > Am 04.02.2011 04:48, schrieb Simon Urbanek: >> Jeroen, >> >> On Feb 3, 2011, at 9:31 PM, Jeroen Ooms wrote: >> >>> >>> Many R packages depend on some unix libraries that are not part of most >>> default installations. I often spend a significant amount of time figuring >>> out where to get the appropriate libraries for compiling these packages, >>> after they give some vague error of something missing. I was wondering why >>> there is no formal system of specifying non-R dependencies in the >>> DESCRIPTION file. If this would be the case, then during the installation of >>> an R package, the user could be prompted to install required system packages >>> (if they have appropriate privileges). >>> >>> So for example: >>> >>> Package: XML >>> Version: 3.2-0 >>> Depends: R (>= 1.2.0), methods, utils >>> Depends-debian: libxml2-dev >>> Depends-ubuntu: libxml2-dev >>> Depends-redhat: libxml2-devel >>> Depends-suse: libxml2-devel >>> etc. >>> >>> This might make life for many people just a little easier. If they are root >>> and the package is in their system repositories, than it will install >>> automatically. If not, at least they know for which package to look, or >>> request their sys admin to install. >> >> Well, there is already such system in place and it is the corresponding >> descriptions in the distributions. Obviously as an author of the package I >> don't care what any particular Linux distribution uses as a name for the >> needed dependencies as the corresponding chaos is distribution-specific. The >> only person who can reasonably determine the dependencies is the maintainer >> of the distribution and that's what they do and as a user of the above >> mentioned distributions you should be thankful to them. Fortunately, normal >> users don't have to worry about it as major distributions already come with >> a large set of R packages resolving all dependencies. Hence I don't see any >> reason why this should have anything to do with the DESCRIPTION file. The >> improvements I could think of would be a parseable entry or a canonical >> pointer to dependency sources, but that's a whole another story. >> >> Cheers, >> Simon >> >> __ >> 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] terribly annoying bug with POSIXlt : one o'clock is midnight?
Apparently, as.POSIXlt takes one o'clock as the start of the day : > as.POSIXlt(0,origin="1970-01-01") [1] "1970-01-01 01:00:00 CET" > as.POSIXlt(0,origin="1970-01-01 00:00:00") [1] "1970-01-01 01:00:00 CET" > as.POSIXlt(0,origin="1970-01-01 23:59:59") [1] "1970-01-02 00:59:59 CET" Cheers -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] terribly annoying bug with POSIXlt : one o'clock is midnight?
Been too fast : I am in Central European Time (GMT +1), which explains the time conversion. Still, I find it highly annoying that as.POSIXlt assumes that the time is given in GMT and has to be converted to whatever timezone you're in if you don't specify anything. Probably this behaviour is not going to be changed, but it's causing very hard-to-track-down bugs nonetheless. Cheers Joris On Fri, Feb 4, 2011 at 4:21 PM, Joris Meys wrote: > Apparently, as.POSIXlt takes one o'clock as the start of the day : > >> as.POSIXlt(0,origin="1970-01-01") > [1] "1970-01-01 01:00:00 CET" >> as.POSIXlt(0,origin="1970-01-01 00:00:00") > [1] "1970-01-01 01:00:00 CET" >> as.POSIXlt(0,origin="1970-01-01 23:59:59") > [1] "1970-01-02 00:59:59 CET" > > Cheers > > > > -- > Joris Meys > Statistical consultant > > Ghent University > Faculty of Bioscience Engineering > Department of Applied mathematics, biometrics and process control > > tel : +32 9 264 59 87 > joris.m...@ugent.be > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] terribly annoying bug with POSIXlt : one o'clock is midnight?
On Fri, 2011-02-04 at 16:21 +0100, Joris Meys wrote: > Apparently, as.POSIXlt takes one o'clock as the start of the day : > > > as.POSIXlt(0,origin="1970-01-01") > [1] "1970-01-01 01:00:00 CET" > > as.POSIXlt(0,origin="1970-01-01 00:00:00") > [1] "1970-01-01 01:00:00 CET" > > as.POSIXlt(0,origin="1970-01-01 23:59:59") > [1] "1970-01-02 00:59:59 CET" > > Cheers Isn't this just a timezone thing? CET is an hour ahead of UTC (GMT) > as.POSIXlt(0,origin="1970-01-01") [1] "1970-01-01 01:00:00 BST" > as.POSIXlt(0,origin="1970-01-01", tz = "GMT") [1] "1970-01-01 GMT" > as.POSIXlt(0,origin="1970-01-01 00:00:00") [1] "1970-01-01 01:00:00 BST" > as.POSIXlt(0,origin="1970-01-01 00:00:00", tz = "GMT") [1] "1970-01-01 GMT" > as.POSIXlt(0,origin="1970-01-01 23:59:59", tz = "GMT") [1] "1970-01-01 23:59:59 GMT" G -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Dr. Gavin Simpson [t] +44 (0)20 7679 0522 ECRC, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] terribly annoying bug with POSIXlt : one o'clock is midnight?
Much of TZ-hell (I almost dare say all) has been sorted through in xts. http://cran.r-project.org/web/packages/xts/index.html Peruse the sources for inspiration or just take some comfort in that you are not the only one ;-) Jeff On Fri, Feb 4, 2011 at 9:24 AM, Joris Meys wrote: > Been too fast : I am in Central European Time (GMT +1), which explains > the time conversion. Still, I find it highly annoying that as.POSIXlt > assumes that the time is given in GMT and has to be converted to > whatever timezone you're in if you don't specify anything. > > Probably this behaviour is not going to be changed, but it's causing > very hard-to-track-down bugs nonetheless. > > Cheers > Joris > > On Fri, Feb 4, 2011 at 4:21 PM, Joris Meys wrote: >> Apparently, as.POSIXlt takes one o'clock as the start of the day : >> >>> as.POSIXlt(0,origin="1970-01-01") >> [1] "1970-01-01 01:00:00 CET" >>> as.POSIXlt(0,origin="1970-01-01 00:00:00") >> [1] "1970-01-01 01:00:00 CET" >>> as.POSIXlt(0,origin="1970-01-01 23:59:59") >> [1] "1970-01-02 00:59:59 CET" >> >> Cheers >> >> >> >> -- >> Joris Meys >> Statistical consultant >> >> Ghent University >> Faculty of Bioscience Engineering >> Department of Applied mathematics, biometrics and process control >> >> tel : +32 9 264 59 87 >> joris.m...@ugent.be >> --- >> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >> > > > > -- > Joris Meys > Statistical consultant > > Ghent University > Faculty of Bioscience Engineering > Department of Applied mathematics, biometrics and process control > > tel : +32 9 264 59 87 > joris.m...@ugent.be > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] axTicks.Rd documentation bug
?axTicks says:
usr: numeric vector of length four, defaulting to ‘par("usr")’
giving horizontal (‘x’) and vertical (‘y’) user coordinate
limits.
but this is not how the function is implemented -- in fact 'usr' should
be a vector of length two corresponding to the appropriate elements of
par("usr") [1:2 if side is 1 or 3, 3:4 if side is 2 or 4].
A patch for src/library/graphics/man/axTicks.Rd against the latest SVN
is attached (I hope it makes it through).
I also included an extended example of how to use axTicks without
reference to an existing plot in the logarithmic axis case: it took me
quite a bit of digging in documentation and source code to figure out
how to do this for myself, so I think it would be useful to others ...
Ben Bolker
Index: axTicks.Rd
===
--- axTicks.Rd (revision 54221)
+++ axTicks.Rd (working copy)
@@ -19,19 +19,23 @@
\item{side}{integer in 1:4, as for \code{\link{axis}}.}
\item{axp}{numeric vector of length three, defaulting to
\code{\link{par}("xaxp")} or \code{\link{par}("yaxp")}
-depending on the \code{side} argument.}
- \item{usr}{numeric vector of length four, defaulting to
-\code{\link{par}("usr")} giving horizontal (\sQuote{x}) and vertical
-(\sQuote{y}) user coordinate limits.}
+depending on the \code{side} argument (\code{par("xaxp")}
+if \code{side} is 1 or 3, \code{par("yaxp")} if side is 2 or 4).}
+ \item{usr}{numeric vector of length two giving user coordinate
+limits, defaulting to
+the relevant portion of \code{\link{par}("usr")}
+(\code{par("usr")[1:2]} or \code{par("usr")[3:4]}
+for \code{side} in (1,3) or (2,4) respectively).}
\item{log}{logical indicating if log coordinates are active; defaults
-to \code{\link{par}("xlog")} or \code{\link{par}("ylog")}.}
+to \code{\link{par}("xlog")} or \code{\link{par}("ylog")}
+depending on \code{side}.}
}
\details{
The \code{axp}, \code{usr}, and \code{log} arguments must be consistent
as their default values (the \code{par(..)} results) are. If you
specify all three (as non-NULL), the graphics environment is not used
- at all. Note that the meaning of \code{axp} alters very much when \code{log}
- is \code{TRUE}, see the documentation on \code{\link{par}(xaxp=.)}.
+ at all. Note that the meaning of \code{axp} differs significantly when
\code{log}
+ is \code{TRUE}; see the documentation on \code{\link{par}(xaxp=.)}.
\code{axTicks()} can be regarded as an \R implementation of the
C function \code{CreateAtVector()} in \file{/src/main/plot.c}
@@ -64,6 +68,25 @@
rug(T, col="red")
}
par(op)
+
+## an example using axTicks without reference to an existing plot
+## (copying R's internal procedures for setting axis ranges etc.):
+## standard logarithmic y axis labels
+ylims <- c(0.2,88)
+extend_lims <- function(r) { r+c(-1,1)*0.04*diff(r) }
+get_axp <- function(x) { 10^c(ceiling(x[1]),floor(x[2])) }
+## mimic par("yaxs")=="i"
+usr.i <- log10(ylims)
+axTicks(side=2,usr=usr.i,axp=c(get_axp(usr.i),n=3),log=TRUE)
+plot(0:1,ylims,log="y",yaxs="i")
+axTicks(side=2)
+## mimic (default) par("yaxs")=="r"
+usr.r <- extend_lims(log10(ylims))
+axTicks(side=2,usr=usr.r,
+axp=c(get_axp(usr.r),3),
+log=TRUE)
+plot(0:1,ylims,log="y",yaxs="r")
+axTicks(side=2)
}
\keyword{dplot}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.csv trap
This is not specifically a bug, but an (implicitly/obscurely)
documented behavior of read.csv (or read.table with fill=TRUE) that can
be quite dangerous/confusing for users. I would love to hear some
discussion from other users and/or R-core about this ... As always, I
apologize if I have missed some obvious workaround or reason that this
is actually the desired behavior ...
In a nutshell, when fill=TRUE R guesses the number of columns from the
first 5 rows of the data set. That's fine, and ?read.table documents this:
The number of data columns is determined by looking at the first
five lines of input (or the whole file if it has less than five
lines), or from the length of ‘col.names’ if it is specified and
is longer. This could conceivably be wrong if ‘fill’ or
‘blank.lines.skip’ are true, so specify ‘col.names’ if necessary.
What is dangerous/confusing is that R silently **wraps** longer lines if
fill=TRUE (which is the default for read.csv). I encountered this when
working with a colleague on a long, messy CSV file that had some phantom
extra fields in some rows, which then turned into empty lines in the
data frame.
Here is an example and a workaround that runs count.fields on the
whole file to find the maximum column length and set col.names
accordingly. (It assumes you don't already have a file named "test.csv"
in your working directory ...)
I haven't dug in to try to write a patch for this -- I wanted to test
the waters and see what people thought first, and I realize that
read.table() is a very complicated piece of code that embodies a lot of
tradeoffs, so there could be lots of different approaches to trying to
mitigate this problem. I appreciate very much how hard it is to write a
robust and general function to read data files, but I also think it's
really important to minimize the number of traps in read.table(), which
will often be the first part of R that new users encounter ...
A quick fix for this might be to allow the number of lines analyzed
for length to be settable by the user, or to allow a settable 'maxcols'
parameter, although those would only help in the case where the user
already knows there is a problem.
cheers
Ben Bolker
===
writeLines(c("A,B,C,D",
"1,a,b,c",
"2,f,g,c",
"3,a,i,j",
"4,a,b,c",
"5,d,e,f",
"6,g,h,i,j,k,l,m,n"),
con=file("test.csv"))
read.csv("test.csv")
try(read.csv("test.csv",fill=FALSE))
## assumes header=TRUE, fill=TRUE; should be a little more careful
## with comment, quote arguments (possibly explicit)
## ... contains information about quote, comment.char, sep
Read.csv <- function(fn,sep=",",...) {
colnames <- scan(fn,nlines=1,what="character",sep=sep,...)
ncolnames <- length(colnames)
maxcols <- max(count.fields(fn,sep=sep,...))
if (maxcols>ncolnames) {
colnames <- c(colnames,paste("V",(ncolnames+1):maxcols,sep=""))
}
## assumes you don't have any other columns labeled "V[large number]"
read.csv(fn,...,col.names=colnames)
}
Read.csv("test.csv")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dependencies on system packages
Simon, On 4 February 2011 at 10:01, Simon Urbanek wrote: | Claudia, | | thanks for you comments . | | On Feb 4, 2011, at 3:18 AM, Claudia Beleites wrote: | | > Dear all, | > | > From the writing extensions manual: | > "Other dependencies (external to the R system) should be listed in the ‘SystemRequirements’ field, possibly amplified in a separate README file." | > | > I guess one problem is the user may not realize that the -dev version is needed, and just sees libxml2 installed but the R package installation stopping with the respective error. | > | | I'd argue that if a user attempts to install a package from sources instead | of using the distribution binaries, he should know what he's doing as there | is much more involved (proper tools, usually a different library location | etc.). And anyone who knows what he's doing also knows that -dev packages | are needed (at the latest when the installation fails you remember ;)). If | he doesn't then it should give him a clue that he may want to use something | else (and especially Linux users should know better ;)). | | Clearly, it doesn't prevent users from doing stupid things and I completely | agree with you that the README should have the instructions as far as the | developer knows. And as a package developer you'll learn soon enough when | people start complaining ;). I respectfully disagree. Based on a number of years of supporting users on Linux where people install frequently from source, I can assure you that a rather large number of people fails. Not everybody is fluent with compilers, knows about libraries and their interdependencies, or can even read configure error messages. We all see the r-help messages (or the traffic on the SIG lists). People want to use the wealth of software that is CRAN, and we should help them. I have also been involved in by now two attempts to overcome this in an automated fashion via cran2deb. We had that working somewhat reliably until parts of the infrastructure misteriously self-destructed (a large sqlite table) right when I visited Vienna, and are now in a rewrite which may be never ending (for lack of resources). There was a lot of interest for it when it worked, and there is ongoing interest right now (as a few guys from across Europe just met last weekend to try to use for BioC builds). There were also folks from other distros who tried something similar. What Jeroen suggested is along those lines with the needed meta-data. Whether we make it per-package (as per Jeroen's idea) or 'per-repo-distro-pair' (which is what cran2deb does) is a detail. We need to address this: With 2600+ packages and continued growth, manually wading through README is not good enough. We should do better. Resources (time, money, servers, ...) would help. Maybe one day someone with more time can fold this into a proper sub-project of a larger grant application. It would be worth, and I would try to help, time permitting. Cheers, Dirk | | Thanks, | Simon | | | | > Giving the package name for specific distributions is of course polite (if the developer knows it). As developer you may also put into the README that the package's mailing list/forum/wiki/... contains information and ask the user to enter the package name on his distro if it is not already there. | > | > | > my 2 ct | > | > Claudia | > | > | > | > Am 04.02.2011 04:48, schrieb Simon Urbanek: | >> Jeroen, | >> | >> On Feb 3, 2011, at 9:31 PM, Jeroen Ooms wrote: | >> | >>> | >>> Many R packages depend on some unix libraries that are not part of most | >>> default installations. I often spend a significant amount of time figuring | >>> out where to get the appropriate libraries for compiling these packages, | >>> after they give some vague error of something missing. I was wondering why | >>> there is no formal system of specifying non-R dependencies in the | >>> DESCRIPTION file. If this would be the case, then during the installation of | >>> an R package, the user could be prompted to install required system packages | >>> (if they have appropriate privileges). | >>> | >>> So for example: | >>> | >>> Package: XML | >>> Version: 3.2-0 | >>> Depends: R (>= 1.2.0), methods, utils | >>> Depends-debian: libxml2-dev | >>> Depends-ubuntu: libxml2-dev | >>> Depends-redhat: libxml2-devel | >>> Depends-suse: libxml2-devel | >>> etc. | >>> | >>> This might make life for many people just a little easier. If they are root | >>> and the package is in their system repositories, than it will install | >>> automatically. If not, at least they know for which package to look, or | >>> request their sys admin to install. | >> | >> Well, there is already such system in place and it is the corresponding descriptions in the distributions. Obviously as an author of the package I don't care what any particular Linux distribution uses as a name for the needed dependencies as the corresponding chaos is distribution-specific. The only person who ca
Re: [Rd] dependencies on system packages
On 2/4/11 9:01 AM, "Simon Urbanek" wrote: >I'd argue that if a user attempts to install a package from sources >instead of using the distribution binaries, he should know what he's >doing as there is much more involved (proper tools, usually a different >library location etc.). Most of the time when I build an existing package from source, it's because I'm doing The Open Source Thing, either trying to fix some bug or add some new feature. One should only need to be a competent writer of R code to do that, but often the mechanics of building the package get in the way. -- Ken Williams Senior Research Scientist Thomson Reuters http://labs.thomsonreuters.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dependencies on system packages
On Feb 4, 2011, at 1:24 PM, Dirk Eddelbuettel wrote: > > Simon, > > On 4 February 2011 at 10:01, Simon Urbanek wrote: > | Claudia, > | > | thanks for you comments . > | > | On Feb 4, 2011, at 3:18 AM, Claudia Beleites wrote: > | > | > Dear all, > | > > | > From the writing extensions manual: > | > "Other dependencies (external to the R system) should be listed in the > ‘SystemRequirements’ field, possibly amplified in a separate README file." > | > > | > I guess one problem is the user may not realize that the -dev version is > needed, and just sees libxml2 installed but the R package installation > stopping with the respective error. > | > > | > | I'd argue that if a user attempts to install a package from sources instead > | of using the distribution binaries, he should know what he's doing as there > | is much more involved (proper tools, usually a different library location > | etc.). And anyone who knows what he's doing also knows that -dev packages > | are needed (at the latest when the installation fails you remember ;)). If > | he doesn't then it should give him a clue that he may want to use something > | else (and especially Linux users should know better ;)). > | > | Clearly, it doesn't prevent users from doing stupid things and I completely > | agree with you that the README should have the instructions as far as the > | developer knows. And as a package developer you'll learn soon enough when > | people start complaining ;). > > I respectfully disagree. > > Based on a number of years of supporting users on Linux where people install > frequently from source, I can assure you that a rather large number of people > fails. Not everybody is fluent with compilers, knows about libraries and > their interdependencies, or can even read configure error messages. We all > see the r-help messages (or the traffic on the SIG lists). > > People want to use the wealth of software that is CRAN, and we should help > them. I have also been involved in by now two attempts to overcome this in > an automated fashion via cran2deb. We had that working somewhat reliably > until parts of the infrastructure misteriously self-destructed (a large > sqlite table) right when I visited Vienna, and are now in a rewrite which may > be never ending (for lack of resources). There was a lot of interest for it > when it worked, and there is ongoing interest right now (as a few guys from > across Europe just met last weekend to try to use for BioC builds). > > There were also folks from other distros who tried something similar. What > Jeroen suggested is along those lines with the needed meta-data. Whether we > make it per-package (as per Jeroen's idea) or 'per-repo-distro-pair' (which > is what cran2deb does) is a detail. > > We need to address this: With 2600+ packages and continued growth, manually > wading through README is not good enough. We should do better. Resources > (time, money, servers, ...) would help. Maybe one day someone with more time > can fold this into a proper sub-project of a larger grant application. It > would be worth, and I would try to help, time permitting. > Well, as far as I can see you're only agreeing with me :). I said people like you are solving the issues by creating the corresponding distro-specific description and people should be thankful for that. Also I said that the distro-specific way is the only reliable way as package authors cannot know the intricacies of the distros involved. If the distros could share a system that helps to maintain this, it would be perfect - by all mean supported by us if we can, but it's separate from the package authors. And, finally, I also said that it would be nice to have a parseable field that is disto-independent so the distro-maintainer don't need to weed through READMEs to find dependency sources. I'm sorry to hear that cran2deb self-destructed as your Debian handling of packages is immensely helpful, especially for package with intricate dependencies. On a similar note, I also think that it would be useful to have a common support already at the package level -- very few people know how to write good configure scripts and there are many pitfalls that catch the unwary, so we could have a template for the most common case of requiring a few libraries. This would also allow some auto-maigc handling of the extended requirement, possibly with some site support ... (e.g. you could imagine searching debs for the library files that are required and coming up with a suggestion of packages etc.). Cheers, Simon > | > | Thanks, > | Simon > | > | > | > | > Giving the package name for specific distributions is of course polite > (if the developer knows it). As developer you may also put into the README > that the package's mailing list/forum/wiki/... contains information and ask > the user to enter the package name on his distro if it is not already there. > | > > | > > | > my 2 ct > | > > | > Claudia >
Re: [Rd] dependencies on system packages
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of ken.willi...@thomsonreuters.com >Sent: February-04-11 1:58 PM >To: simon.urba...@r-project.org; cbelei...@units.it >Cc: r-devel@r-project.org >Subject: Re: [Rd] dependencies on system packages >On 2/4/11 9:01 AM, "Simon Urbanek" wrote: > >>I'd argue that if a user attempts to install a package from sources >>instead of using the distribution binaries, he should know what he's >>doing as there is much more involved (proper tools, usually a different >>library location etc.). > >Most of the time when I build an existing package from source, it's because I'm doing The Open Source Thing, either trying to fix some bug or add some new feature. One should only need to be a competent writer of R code to do that, but often the mechanics of >building the package get in the way. Actually, I develop enough software that I don't really have the time to do this (debug a package's source, or extend it), though that may change at any time as I start using it more intensively. Normally, the only time I have been compiling R packages from source is when there were no 64 bit Windows binaries. Using the right RTools, along with R's ability to install from source allowed me to use PostGreSQL and MySQL in 64 bit R on 64 biw Windows 7. This is a counter-example related to Simon's remarks about a user building packages from source. His remark is valid IF the user is making repairs or extensions, as Ken says he does. However, it is problemtic for those users who are faced with a situation in which there IS no binary distribution for their specific platform. I do precisely the same thing with open source software written for some flavour of Unix, even though I don't have a machine with a real unix. On my machine (64 bit Windows 7), I have cygwin installed (and it works fine), and for that unix software I want to use, the usual process of "./configure" followed by make, "make check" or "make test", and "make install" works great. All I have to do is read the documentation for the software or library I want to use, in order to make certain the dependancy requirements are satisfied. NB: I use cygwin ONLY to pass my C++ code through gcc, as a check on the quality of code I have already passed through MSVC++, but that is another story. Yes, I have the skills needed to deal with the issues Simon raises WRT building software n a unix machine, but I know several R users who do not, and I would not want them to be unable to use one package or another because of there being no binary distribution for their specific platform (of course, you know who they ask when they encounter this sort of issue). Thus, I agree with Dirk that more robust and user friendly option is required. For me, I don't care if it is a script that runs from the shell (bash, Windows shell, &c.) or from the R menu, but I know some potential users who would be lost unless it is something simple that can be invoked from R's menu. Cheers, Ted __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] matching symbols to objects
Hello, I'm trying to access an object, given only its name as a symbol. I cannot figure out how to proceed. Suppose I call substitute( ) on the expression 'x + 2': > parse.tree <- substitute(x + 2); The constituents of parse.tree are of type symbol and numeric: > str(parse.tree[[1]]) symbol + > str(parse.tree[[2]]) symbol x > str(parse.tree[[3]]) num 2 Suppose that x is S4 object, and that I need to access a slot of that object. How can I do so, using only 'parse.tree' (or parse.tree coerced into a list)? Thanks, Patrick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matching symbols to objects
Patrick, Take a look at all.vars to start with That will return the vars as characters, from there you can use get to test/proceed. > all.vars(parse.tree) [1] "x" Best, Jeff On Fri, Feb 4, 2011 at 1:37 PM, Patrick Leyshock wrote: > Hello, > > I'm trying to access an object, given only its name as a symbol. I cannot > figure out how to proceed. Suppose I call substitute( ) on the expression > 'x + 2': > >> parse.tree <- substitute(x + 2); > > The constituents of parse.tree are of type symbol and numeric: > >> str(parse.tree[[1]]) > symbol + > >> str(parse.tree[[2]]) > symbol x > >> str(parse.tree[[3]]) > num 2 > > Suppose that x is S4 object, and that I need to access a slot of that > object. How can I do so, using only 'parse.tree' (or parse.tree coerced > into a list)? > > Thanks, Patrick > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matching symbols to objects
There we go, thank you! > On Fri, Feb 4, 2011 at 11:42 AM, Jeff Ryan wrote: > >> Patrick, >> >> Take a look at all.vars to start with That will return the vars as >> characters, from there you can use get to test/proceed. >> >> > all.vars(parse.tree) >> [1] "x" >> >> >> Best, >> Jeff >> >> On Fri, Feb 4, 2011 at 1:37 PM, Patrick Leyshock >> wrote: >> > Hello, >> > >> > I'm trying to access an object, given only its name as a symbol. I >> cannot >> > figure out how to proceed. Suppose I call substitute( ) on the >> expression >> > 'x + 2': >> > >> >> parse.tree <- substitute(x + 2); >> > >> > The constituents of parse.tree are of type symbol and numeric: >> > >> >> str(parse.tree[[1]]) >> > symbol + >> > >> >> str(parse.tree[[2]]) >> > symbol x >> > >> >> str(parse.tree[[3]]) >> > num 2 >> > >> > Suppose that x is S4 object, and that I need to access a slot of that >> > object. How can I do so, using only 'parse.tree' (or parse.tree coerced >> > into a list)? >> > >> > Thanks, Patrick >> > >> >[[alternative HTML version deleted]] >> > >> > __ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> >> >> -- >> Jeffrey Ryan >> jeffrey.r...@lemnica.com >> >> www.lemnica.com >> > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] keep.source when semicolons separate statements on the one line
This is probably the same underlying bug, but it is not caused by
semicolons.
If you use keep,soure=TRUE with expand=FALSE and interpolate a code
chunk, the name of the chunkl is sent to the TeX file once for every
line in the chunk. Specifically, the source file:
%%%
\documentclass{article}
\begin{document}
<>=
x <- 1
y <- 2
x+y
@
<>=
<>
@
\end{document}
%%%
produces the output LaTeX file:
%%%
\documentclass{article}
\usepackage{Sweave}
\begin{document}
\begin{Schunk}
\begin{Sinput}
> x <- 1
> y <- 2
> x + y
\end{Sinput}
\begin{Soutput}
[1] 3
\end{Soutput}
\end{Schunk}
\begin{Schunk}
\begin{Sinput}
> <>
> <>
> <>
\end{Sinput}
\begin{Soutput}
[1] 3
\end{Soutput}
\end{Schunk}
\end{document}
%%%
On 2/4/2011 7:56 AM, Duncan Murdoch wrote:
Thanks for the report. I'll take a look.
I'm now past one major time sink, and will have some time to catch up
on old problems; I'll add this to that list.
Duncan Murdoch
On 03/02/2011 7:09 PM, John Maindonald wrote:
The following is 'semicolon.Rnw'
> \SweaveOpts{engine=R, keep.source=TRUE}
>
> <>=
> library(SMIR); data(bronchit); library(KernSmooth)
> @ %
>
> Code for panel A is
> <>=
> <>
> @ %
Sweave("semicolon") yields the following 'semicolon.tex'
> Code for panel A is
> \begin{Schunk}
> \begin{Sinput}
>> library(SMIR); data(bronchit); library(KernSmooth)
>> library(SMIR); data(bronchit); library(KernSmooth)
>> library(SMIR); data(bronchit); library(KernSmooth)
> \end{Sinput}
> \end{Schunk}
(I have omitted three blank lines at the start)
With keep.source=FALSE, the commands are split onto
separate lines, and there is no repetition.
John Maindonald email: john.maindon...@anu.edu.au
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics& Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
http://www.maths.anu.edu.au/~johnm
__
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] matching symbols to objects
There we go, thank you! On Fri, Feb 4, 2011 at 11:42 AM, Jeff Ryan wrote: > Patrick, > > Take a look at all.vars to start with That will return the vars as > characters, from there you can use get to test/proceed. > > > all.vars(parse.tree) > [1] "x" > > > Best, > Jeff > > On Fri, Feb 4, 2011 at 1:37 PM, Patrick Leyshock > wrote: > > Hello, > > > > I'm trying to access an object, given only its name as a symbol. I > cannot > > figure out how to proceed. Suppose I call substitute( ) on the > expression > > 'x + 2': > > > >> parse.tree <- substitute(x + 2); > > > > The constituents of parse.tree are of type symbol and numeric: > > > >> str(parse.tree[[1]]) > > symbol + > > > >> str(parse.tree[[2]]) > > symbol x > > > >> str(parse.tree[[3]]) > > num 2 > > > > Suppose that x is S4 object, and that I need to access a slot of that > > object. How can I do so, using only 'parse.tree' (or parse.tree coerced > > into a list)? > > > > Thanks, Patrick > > > >[[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > Jeffrey Ryan > jeffrey.r...@lemnica.com > > www.lemnica.com > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reading a specific file during "R CMD check"?
Hello, All:
How can I obtain the location of an example data file in a
package during "R CMD check"?
I want to include sample raw data files in a package and have
them read by a function in the package. It occurs to me to put such a
file in "\inst\rawdata" and have examples find the data using something
like "system.file('rawdata', package='MyPackage')". However, this will
only work if the desired data are already in a version of 'MyPackage'
that is already installed. If I change the data, this will return the
old data, not the modified. I've looked at packages RUnit and svUnit,
but have not spent enough time with either to know if they include a
solution to this problem.
Thanks for your help.
Spencer
--
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
Re: [Rd] Reading a specific file during "R CMD check"?
Hi Spencer,
I think one of the early phases of R CMD check is R CMD install - it
installs the package into a special location so that it doesn't
override existing installed packages, but still allows function to
work exactly as if they were in an installed package.
Hadley
On Fri, Feb 4, 2011 at 7:57 PM, Spencer Graves
wrote:
> Hello, All:
>
>
> How can I obtain the location of an example data file in a package
> during "R CMD check"?
>
>
> I want to include sample raw data files in a package and have them read
> by a function in the package. It occurs to me to put such a file in
> "\inst\rawdata" and have examples find the data using something like
> "system.file('rawdata', package='MyPackage')". However, this will only work
> if the desired data are already in a version of 'MyPackage' that is already
> installed. If I change the data, this will return the old data, not the
> modified. I've looked at packages RUnit and svUnit, but have not spent
> enough time with either to know if they include a solution to this problem.
>
>
> Thanks for your help.
> Spencer
>
> --
> 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
>
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
