[Rd] R CMD build when the package name is different from the directory name
Hi,
I was really happy when I saw that in R version 2.3.0 "R CMD check" works for
packages whose package name is different from the directory name in which it
is located (see http://cran.r-project.org/src/base/NEWS).
Now, I can have branches of my packages in directories like
"[...]/branches//", while I had to use
"[...]/branches//" before.
"R CMD check " runs as expected but when I build the package
with "R CMD build ", the file name of the source package is
"_-.tar.gz" (and not "_-.tar.gz"). Furthermore the base directory
inside the .tar.gz archive is "" (and not "").
Is there a possibility to tell "R CMD build" to use the correct package name
("R CMD check" uses the correct package name.) Can you change the (default)
behaviour of "R CMD build" in future releases?
Do I have to change the file name and/or the name of the base directory before
uploading the package to CRAN?
I use R version 2.3.1 (2006-06-01) on i686-pc-linux-gnu.
The same happens with R version 2.4.0 RC.
Thanks,
Arne
--
Arne Henningsen
Department of Agricultural Economics
University of Kiel
Olshausenstr. 40
D-24098 Kiel (Germany)
Tel: +49-431-880 4445
Fax: +49-431-880 1397
[EMAIL PROTECTED]
http://www.uni-kiel.de/agrarpol/ahenningsen/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unloadNamespace inside .Last.lib
In my package's zzz.R, I put
.Last.lib <- function(libpath) {
unloadNamespace("mypackage")
}
and I exported .Last.lib in NAMESPACE, with the intent that detaching
the package would also cause the name space to be unloaded. However, the
result of detach("package:mypackage") is then
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in library.dynam.unload("mypackage", libpath) :
shared library 'mypackage' was not loaded
Error in as.character() : cannot coerce to vector
Error in unregisterNamespace(nsname) : name space not registered
Error in detach(pos) : detaching "package:base" is not allowed
Error in detach(pos) : detaching "package:base" is not allowed
Error in detach(pos) : detaching "package:base" is not allowed
With a hundred more or so of the last error. What is the correct way (if
any) to unload a name space using detach() alone ?
Thanks,
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build when the package name is different from the directory name
Another possibility is to store your code in svn or other version
control system.
On 9/28/06, Arne Henningsen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was really happy when I saw that in R version 2.3.0 "R CMD check" works for
> packages whose package name is different from the directory name in which it
> is located (see http://cran.r-project.org/src/base/NEWS).
> Now, I can have branches of my packages in directories like
> "[...]/branches//", while I had to use
> "[...]/branches//" before.
> "R CMD check " runs as expected but when I build the package
> with "R CMD build ", the file name of the source package is
> "_-.tar.gz" (and not " name>_-.tar.gz"). Furthermore the base directory
> inside the .tar.gz archive is "" (and not "").
>
> Is there a possibility to tell "R CMD build" to use the correct package name
> ("R CMD check" uses the correct package name.) Can you change the (default)
> behaviour of "R CMD build" in future releases?
>
> Do I have to change the file name and/or the name of the base directory before
> uploading the package to CRAN?
>
> I use R version 2.3.1 (2006-06-01) on i686-pc-linux-gnu.
> The same happens with R version 2.4.0 RC.
>
> Thanks,
> Arne
>
> --
> Arne Henningsen
> Department of Agricultural Economics
> University of Kiel
> Olshausenstr. 40
> D-24098 Kiel (Germany)
> Tel: +49-431-880 4445
> Fax: +49-431-880 1397
> [EMAIL PROTECTED]
> http://www.uni-kiel.de/agrarpol/ahenningsen/
>
> __
> 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] Warning on backslash sequences (was sprintf behavior)
Thanks, Bill, that is helpful.
I've been running a prototype across R itself and CRAN. It is clear that
we do have lots of strings with escaped newlines (the escape is generated
in the parser if there is an embedded newline) so they need to be an
exception. On my first version 99 CRAN packages got picked up on this,
but about 40 are problems with escaped newlines only (often from
inst/CITATION files).
I don't understand why \` is regarded as intentional. It crops up in
packages date and survival (the same code) in
stop(paste("\`", .Generic, "' not meaningful for dates",
sep = ""))
which clearly should use sQuote(.Generic) in R, but there seems no reason
to escape in either R or Splus.
On Wed, 27 Sep 2006, Bill Dunlap wrote:
>>> Splus's parser emits a warning when it sees a backslash
>>> outside of the recognized backslash sequence. E.g.,
>>>
>>> > nchar("\Backslashed?")
>>> [1] 12
>>> Warning messages:
>>>The initial backslash is ignored in \B -- not a recognized escape
>>> sequence.
>>> Use \\ to make a backslash
>>>
>>> You might want to add that warning to R's parser. I've
>>> seen the error in several R packages. E.g.,
>>>
>>> bayesmix/R/JAGScontrol.R: text[4] <- "-inits.R\"\n\initialize\n"
>>> SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep("[\.]",
>>> basename(res))) == 0)
>>>
>>> The warning is mostly emitted when the error is benign, but it
>>> might help get people to think about what they are typing.
>>
>> I am not at all sure about this. R's documentation says
>> ...
>> '\n' newline
>> '\r' carriage return
>> '\t' tab
>> '\b' backspace
>> '\a' alert (bell)
>> '\f' form feed
>> '\v' vertical tab
>> '\\' backslash '\'
>> '\nnn'character with given octal code (1, 2 or 3 digits)
>> '\xnn'character with given hex code (1 or 2 hex digits)
>> '\u' Unicode character with given code (1-4 hex digits)
>> '\U' Unicode character with given code (1-8 hex digits)
>>
>> so it is not an error in R. People tend not to like being warned about
>> legitimate usage (and one can see this sort of thing being intentional in
>> machine-generated scripts: for example to escape spaces in file paths
>> and to escape line feeds).
>
> We had that same sort of argument here, but enough people were
> asking our support people about the matter that we put in
> the warning. As I said, the warning is odd in that it warns
> about legitimate usage in the hopes that people will know to
> use "\\" for a backslash when they need to.
>
>> What exactly does Splus's parser allow as intentional?
>
> Splus currently "supports" (does not warn about)
>\nnn (1-3 octal digits)
>\n, \t, \b, \r, \', \", and \`
> We do not support the \f, \v, \xnn, \u, or \U.
> We should add the \f, \v, \a, and \xnn (as well as 0xnn for integers),
> but we overlooked those. (Adding new backslash sequences is relatively
> safe: we have been warning about unrecognized \f's for for years so
> we shouldn't expect to find too many folks using \f where they intended
> either \\f or f.)
>
> We don't support unicode so we won't do anything with the \u or
> \U. That is something Splus does need to warn about to aid in
> porting stuff from R.
>
> Neither of the examples I showed cause any ill effect,
> but using the grep pattern of '[\.]' shows that he
> doesn't know that dots are taken literally inside of
> square brackets in regular expressions and the use of
> "\." outside of brackets would give incorrect results.
>
>>> bayesmix/R/JAGScontrol.R: text[4] <- "-inits.R\"\n\initialize\n"
>>> SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep("[\.]",
>>> basename(res))) == 0)
>
> In SciViews I also see
> command <- sub("view\.[A-Za-z0-9\._]+[(]", "view(", command)
> which is almost certainly wrong and I suspect that its
> cat(";for Options\AutoIndent: 0=Off, 1=follow language scoping and 2=copy
> from previous line\n",
> wants an extra \ before AutoIndent.
>
>
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> 360-428-8146
>
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
One area where a problem might appear is if one is
generating R code, e.g.
paste("a <-", dQuote("xyz")) # wrong!
since in UTF-8 dQuote (and sQuote) do not necessarily
generate double quotes (and single quotes) so one winds
up using double quotes within single quotes or else
backslash-protected double quotes within double quotes.
If there were an argument on dQuote and sQuote to
specify that they should generate double and single
quotes acceptable for code regardless then that would
help in this instance.
On 9/28/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> Thanks, Bill, that is helpful.
>
> I've been running a prototype across R itself and CRAN. It is clear that
> we do have lots of strings with escaped newlines (the escape is generated
> in the parser if there is an embedded newline) so they need to be an
> exception. On my first version 99 CRAN packages got picked up on this,
> but about 40 are problems with escaped newlines only (often from
> inst/CITATION files).
>
> I don't understand why \` is regarded as intentional. It crops up in
> packages date and survival (the same code) in
>
>stop(paste("\`", .Generic, "' not meaningful for dates",
>sep = ""))
>
> which clearly should use sQuote(.Generic) in R, but there seems no reason
> to escape in either R or Splus.
>
> On Wed, 27 Sep 2006, Bill Dunlap wrote:
>
> >>> Splus's parser emits a warning when it sees a backslash
> >>> outside of the recognized backslash sequence. E.g.,
> >>>
> >>> > nchar("\Backslashed?")
> >>> [1] 12
> >>> Warning messages:
> >>>The initial backslash is ignored in \B -- not a recognized escape
> >>> sequence.
> >>> Use \\ to make a backslash
> >>>
> >>> You might want to add that warning to R's parser. I've
> >>> seen the error in several R packages. E.g.,
> >>>
> >>> bayesmix/R/JAGScontrol.R: text[4] <- "-inits.R\"\n\initialize\n"
> >>> SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep("[\.]",
> >>> basename(res))) == 0)
> >>>
> >>> The warning is mostly emitted when the error is benign, but it
> >>> might help get people to think about what they are typing.
> >>
> >> I am not at all sure about this. R's documentation says
> >> ...
> >> '\n' newline
> >> '\r' carriage return
> >> '\t' tab
> >> '\b' backspace
> >> '\a' alert (bell)
> >> '\f' form feed
> >> '\v' vertical tab
> >> '\\' backslash '\'
> >> '\nnn'character with given octal code (1, 2 or 3 digits)
> >> '\xnn'character with given hex code (1 or 2 hex digits)
> >> '\u' Unicode character with given code (1-4 hex digits)
> >> '\U' Unicode character with given code (1-8 hex digits)
> >>
> >> so it is not an error in R. People tend not to like being warned about
> >> legitimate usage (and one can see this sort of thing being intentional in
> >> machine-generated scripts: for example to escape spaces in file paths
> >> and to escape line feeds).
> >
> > We had that same sort of argument here, but enough people were
> > asking our support people about the matter that we put in
> > the warning. As I said, the warning is odd in that it warns
> > about legitimate usage in the hopes that people will know to
> > use "\\" for a backslash when they need to.
> >
> >> What exactly does Splus's parser allow as intentional?
> >
> > Splus currently "supports" (does not warn about)
> >\nnn (1-3 octal digits)
> >\n, \t, \b, \r, \', \", and \`
> > We do not support the \f, \v, \xnn, \u, or \U.
> > We should add the \f, \v, \a, and \xnn (as well as 0xnn for integers),
> > but we overlooked those. (Adding new backslash sequences is relatively
> > safe: we have been warning about unrecognized \f's for for years so
> > we shouldn't expect to find too many folks using \f where they intended
> > either \\f or f.)
> >
> > We don't support unicode so we won't do anything with the \u or
> > \U. That is something Splus does need to warn about to aid in
> > porting stuff from R.
> >
> > Neither of the examples I showed cause any ill effect,
> > but using the grep pattern of '[\.]' shows that he
> > doesn't know that dots are taken literally inside of
> > square brackets in regular expressions and the use of
> > "\." outside of brackets would give incorrect results.
> >
> >>> bayesmix/R/JAGScontrol.R: text[4] <- "-inits.R\"\n\initialize\n"
> >>> SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep("[\.]",
> >>> basename(res))) == 0)
> >
> > In SciViews I also see
> > command <- sub("view\.[A-Za-z0-9\._]+[(]", "view(", command)
> > which is almost certainly wrong and I suspect that its
> > cat(";for Options\AutoIndent: 0=Off, 1=follow language scoping and 2=copy
> > from previous line\n",
> > wants an extra \ before AutoIndent.
> >
> > -
Re: [Rd] S4 accessors
Maybe this was not as obvious or well-known as I assumed would be the case on this list. In an OOP system (I dislike the term but let's use it), the programming mechanism is to invoke a method on an object. Say method flag on object x: x$flag() (using "$" in R style instead of the usual "." in Java, et al.) The key conceptual difference from flag(x, ) in a functional language is that the flag method invocation in the OOP language is always part of the class definition for class(x). There is no inherent reason why two methods named flag() would have any connection if the two classes involved had no connection, even if they were in the same package. That's fundamentally different for the user in R, where functions (plot() to take a strong example) come with their own mental model. (If you had a slot named "plot", you would be unwise to have an accessor of the same name, but get_plot() would be unambiguous.) The point is that in a functional language function names are like verbs and tend to mean something, as they should. It is not an assertion that all functions are meaningful for all objects. Even OOP languages often use essentially the same sort of syntactic convention discussed in this thread (see Java Beans, for example). Henrik's mail gave some R examples. Having an accessor mechanism would allow accessors to be generated automatically, including specifying cases where you don't want an explicit set_foo() method. Again, see systems like Java Beans for a somewhat similar approach. If you want to name accessor methods to disguise the fact that they relate to a specific slot, you can always do that. But a syntactic convention could implement a current design automatically, without preventing future software from changing the set of slots while retaining the earlier accessor method names, though now they won't have the same implementation. We don't have such a mechanism now, so you can do whatever seems best. A decision to have accessor methods for _all_ slots would likely lead to conflicts with function names eventually, unless some syntactic convention was used or the slot names themselves were forced to follow some naming convention. Ross Boylan wrote: > I'm trying to understand what the underlying issues are here--with the > immediate goal of how that affects my design and documentation > decisions. > > On Wed, Sep 27, 2006 at 02:08:34PM -0400, John Chambers wrote: > >> Seth Falcon wrote: >> >>> John Chambers <[EMAIL PROTECTED]> writes: >>> >>> >>> There is a point that needs to be remembered in discussions of accessor functions (and more generally). We're working with a class/method mechanism in a _functional_ language. Simple analogies made from class-based languages such as Java are not always good guides. In the example below, "a function foo that only operates on that class" is not usually a meaningful concept in R. > > The sense of "meaningful" here is hard for me to pin down, even with > the subsequent discussion. > > I think the import is more than formal: R is not strongly typed, so > you can hand any argument to any function and the language will not > complain. > > >>> If foo is a generic and the only method defined is for class Bar, then >>> the statement seems meaningful enough? >>> >>> >> This is not primarily a question about implementation but about what the >> user understands. IMO, a function should have an intuitive meaning to >> the user. Its name is taking up a "global" place in the user's brain, >> and good software design says not to overload users with too many >> arbitrary names to remember. >> > > It's true that clashing uses of the same name may lead to confusion, > but that need not imply that functions must be applicable to all > objects. Many functions only make sense in particular contexts, and > sometimes those contexts are quite narrow. > > One of the usual motivations for an OO approach is precisely to limit > the amount of global space taken up by, for example, functions that > operate on the class (global in both the syntactic sense and in the > inside your brain sense). Understanding a traditional OO system, at > least for me, is fundamentally oriented to understanding the objects > first, with the operations on them as auxiliaries. As you point out, > this is just different from the orientation of a functional language, > which starts with the functions. > > >> To be a bit facetious, if "flag is a slot in class Bar, it's really not >> a good idea to define the accessor for that slot as >> flag <- function(object)[EMAIL PROTECTED] >> >> Nor is the situation much improved by having flag() be a generic, with >> the only method being for class Bar. We're absconding with a word that >> users might think has a general meaning. OK, if need be we will have >> different flag() f
Re: [Rd] R CMD build when the package name is different from the directory name
Dear Gabor,
Thank you for your message.
On Thursday 28 September 2006 15:30, Gabor Grothendieck wrote:
> Another possibility is to store your code in svn or other version
> control system.
Unfortunately, I can't see why this should make a difference for
"R CMD build". Do I miss something?
The entire package is in an SVN repository. I have working copies of "trunk"
and of "branches". Therefore, the working copy of, say, branch "0.8"
is "branches/0.8/" (see below).
>
> On 9/28/06, Arne Henningsen <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was really happy when I saw that in R version 2.3.0 "R CMD check" works
> > for packages whose package name is different from the directory name in
> > which it is located (see http://cran.r-project.org/src/base/NEWS).
> > Now, I can have branches of my packages in directories like
> > "[...]/branches//", while I had to use
> > "[...]/branches//" before.
> > "R CMD check " runs as expected but when I build the
> > package with "R CMD build ", the file name of the source
> > package is "_-.tar.gz" (and
> > not "_-.tar.gz"). Furthermore
> > the base directory inside the .tar.gz archive is "" (and
> > not "").
> >
> > Is there a possibility to tell "R CMD build" to use the correct package
> > name ("R CMD check" uses the correct package name.) Can you change the
> > (default) behaviour of "R CMD build" in future releases?
> >
> > Do I have to change the file name and/or the name of the base directory
> > before uploading the package to CRAN?
> >
> > I use R version 2.3.1 (2006-06-01) on i686-pc-linux-gnu.
> > The same happens with R version 2.4.0 RC.
> >
> > Thanks,
> > Arne
> >
--
Arne Henningsen
Department of Agricultural Economics
University of Kiel
Olshausenstr. 40
D-24098 Kiel (Germany)
Tel: +49-431-880 4445
Fax: +49-431-880 1397
[EMAIL PROTECTED]
http://www.uni-kiel.de/agrarpol/ahenningsen/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build when the package name is different from the directory name
Arne Henningsen <[EMAIL PROTECTED]> writes: > Hi, > > I was really happy when I saw that in R version 2.3.0 "R CMD check" works for > packages whose package name is different from the directory name in which it > is located (see http://cran.r-project.org/src/base/NEWS). > Now, I can have branches of my packages in directories like > "[...]/branches//", while I had to use > "[...]/branches//" before. > "R CMD check " runs as expected but when I build the package > with "R CMD build ", the file name of the source package is > "_-.tar.gz" (and not " name>_-.tar.gz"). Furthermore the base directory > inside the .tar.gz archive is "" (and not " name>"). I think that's a feature. Note that R CMD INSTALL on such a package does install the package under its "real" name. It is a feature because it allows me to distinguish the tarballs from each other. Perhaps you can make this work for you by using a more meaningful description than version number in your branch name. For example: .../branches/foo-release .../branches/foo-devel .../branches/foo-someNewFeature As another poster suggested, an SCM is the right tool for tracking versions. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply: new behaviour for factors in R-2.4.0
Dear Brian
Thank you for your answer and the comment you included on the
apply() help page.
1)
You are correct. My data.frame is coerced into a matrix in
apply()
2)
I agree that the new version of unlist() is better and works
correctly and that in array() (due to as.vector()) the factor
"ans" is coerced into a character matrix.
Nevertheless I disagree that this is "feature freeze" with
R version 2.3.1:
Since in R-2.3.1, unlist() on a list of factors returned an
integer vector, the result of apply was an integer matrix and
not a character matrix.
Therefore my question is if it would be desirable to return an
integer matrix by changing apply. One could include additional
code to handle the case if the output "should" be a factor
matrix and coerce into an integer matrix.
Then the outcome would be consistent with R-2.3.1 without
changing something in unlist() or array().
But in the end I am not sure if an integer matrix is better than
a character matrix or a factor matrix. I am not sure what output
is best if one uses as.factor in apply.
Regards,
Christoph
--
Christoph Buser <[EMAIL PROTECTED]>
Seminar fuer Statistik, LEO C13
ETH Zurich 8092 Zurich SWITZERLAND
phone: x-41-44-632-4673 fax: 632-1228
http://stat.ethz.ch/~buser/
--
Prof Brian Ripley writes:
> Christoph,
>
> This is more complicated than your analysis.
>
> 1) apply takes a matrix as an argument, not a data frame, and so first
> coerced 'dat' to a character matrix.
>
> 2) unlist is working quite correctly. The issue is array(), which
> contains as.vector(data). Thus although the result could be a factor
> matrix, as.vector is coercing it to a character matrix. It might be
> desirable to return a factor matrix, but we are not going to do that in
> feature freeze (if ever) and I really don't think it would be what you
> wanted.
>
> Perhaps the help page should contain an explicit statement that the result
> will be coerced to a basic vector type by as.vector().
>
> On Mon, 25 Sep 2006, Christoph Buser wrote:
>
> > Dear R-core
> >
> > There is a different output for the apply function due to the
> > change of unlist as mentioned in the R news.
> >
> > Newly, applying as.factor() (or factor()) in
> >
> > str(dat <- data.frame(x = 1:10, f1 = gl(2,5,labels = c("A", "B"
> > (d1 <- apply(dat,2,as.factor))
> >
> > newly returns a character matrix while in R-2.3.1 the same
> > command resulted in an integer matrix that was consistent (up to
> > the ordering of the factor levels) with data.matrix().
>
> That's coincidence -- try x=11:20.
>
> > The change is caused by the change of unlist() that, used for a
> > list of factors, newly returns a single factor instead of an
> > integer. I am happy with this change, but:
> >
> > Is it desirable to change apply so that it does not return a
> > character matrix in the example above or include a warning for
> > such a case?
> >
> > Thank you very much for an answer.
> >
> > Regards,
> >
> > Christoph Buser
> >
> > --
> > Christoph Buser <[EMAIL PROTECTED]>
> > Seminar fuer Statistik, LEO C13
> > ETH Zurich 8092 Zurich SWITZERLAND
> > phone: x-41-44-632-4673fax: 632-1228
> > http://stat.ethz.ch/~buser/
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> One area where a problem might appear is if one is
> generating R code, e.g.
>
> paste("a <-", dQuote("xyz")) # wrong!
>
> since in UTF-8 dQuote (and sQuote) do not necessarily
> generate double quotes (and single quotes) so one winds
> up using double quotes within single quotes or else
> backslash-protected double quotes within double quotes.
>
> If there were an argument on dQuote and sQuote to
> specify that they should generate double and single
> quotes acceptable for code regardless then that would
> help in this instance.
deparse() would be more to the point, would it not?
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build when the package name is different from the directory name
I normally only keep one version locally since everything else
can be retrieved, if needed, from the repository. If you do want
to keep multiple versions locally then, of course, there is still
a potential problem.
On 9/28/06, Arne Henningsen <[EMAIL PROTECTED]> wrote:
> Dear Gabor,
>
> Thank you for your message.
>
> On Thursday 28 September 2006 15:30, Gabor Grothendieck wrote:
> > Another possibility is to store your code in svn or other version
> > control system.
>
> Unfortunately, I can't see why this should make a difference for
> "R CMD build". Do I miss something?
> The entire package is in an SVN repository. I have working copies of "trunk"
> and of "branches". Therefore, the working copy of, say, branch "0.8"
> is "branches/0.8/" (see below).
>
> >
> > On 9/28/06, Arne Henningsen <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I was really happy when I saw that in R version 2.3.0 "R CMD check" works
> > > for packages whose package name is different from the directory name in
> > > which it is located (see http://cran.r-project.org/src/base/NEWS).
> > > Now, I can have branches of my packages in directories like
> > > "[...]/branches//", while I had to use
> > > "[...]/branches//" before.
> > > "R CMD check " runs as expected but when I build the
> > > package with "R CMD build ", the file name of the source
> > > package is "_-.tar.gz" (and
> > > not "_-.tar.gz"). Furthermore
> > > the base directory inside the .tar.gz archive is "" (and
> > > not "").
> > >
> > > Is there a possibility to tell "R CMD build" to use the correct package
> > > name ("R CMD check" uses the correct package name.) Can you change the
> > > (default) behaviour of "R CMD build" in future releases?
> > >
> > > Do I have to change the file name and/or the name of the base directory
> > > before uploading the package to CRAN?
> > >
> > > I use R version 2.3.1 (2006-06-01) on i686-pc-linux-gnu.
> > > The same happens with R version 2.4.0 RC.
> > >
> > > Thanks,
> > > Arne
> > >
>
> --
> Arne Henningsen
> Department of Agricultural Economics
> University of Kiel
> Olshausenstr. 40
> D-24098 Kiel (Germany)
> Tel: +49-431-880 4445
> Fax: +49-431-880 1397
> [EMAIL PROTECTED]
> http://www.uni-kiel.de/agrarpol/ahenningsen/
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
On 28 Sep 2006 16:33:17 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> "Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
>
> > One area where a problem might appear is if one is
> > generating R code, e.g.
> >
> > paste("a <-", dQuote("xyz")) # wrong!
> >
> > since in UTF-8 dQuote (and sQuote) do not necessarily
> > generate double quotes (and single quotes) so one winds
> > up using double quotes within single quotes or else
> > backslash-protected double quotes within double quotes.
> >
> > If there were an argument on dQuote and sQuote to
> > specify that they should generate double and single
> > quotes acceptable for code regardless then that would
> > help in this instance.
>
> deparse() would be more to the point, would it not?
That's a good idea for the case I mentioned although there is still
the case where one requires a single quoted string (maybe for
generating code for some other language) and that is
not handled by deparse.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes: > That's a good idea for the case I mentioned although there is still > the case where one requires a single quoted string (maybe for > generating code for some other language) and that is > not handled by deparse. Yes, but there be devils lurking in there. I think you do in general need to know what the other language is. Take a look at shQuote(), for instance. (Why, BTW, does that not simply "escape" single quotes using '"'"' instead of switching to double-quotes and escaping everything in sight?) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unable to load lapack.so
Hi, I'm having problems using ACML with R. I made two changes in config.site by setting LDFLAGS="-L/opt/acml3.1.0/gnu64/lib" BLAS_LIBS="-lacml" ./config and make go through but when I try to use the lm() function, I get the error message Error in chol2inv(Qr$qr[p1, p1, drop = FALSE]) : lapack routines cannot be loaded In addition: Warning message: unable to load shared library '/usr/local/R-patched/modules//lapack.so': Shared object "libRlapack.so" not found, required by "lapack.so" What am I missing? > version _ platform x86_64-unknown-freebsd6.1 arch x86_64 os freebsd6.1 system x86_64, freebsd6.1 status Patched major 2 minor 3.1 year 2006 month 06 day01 svn rev38258 language R version.string Version 2.3.1 Patched (2006-06-01 r38258) -- -- Hiroyuki Kawakatsu Business School Dublin City University Dublin 9, Ireland Tel +353 (0)1 700 7496 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
On Thu, 28 Sep 2006, Peter Dalgaard wrote: > "Gabor Grothendieck" <[EMAIL PROTECTED]> writes: > >> That's a good idea for the case I mentioned although there is still >> the case where one requires a single quoted string (maybe for >> generating code for some other language) and that is >> not handled by deparse. > > Yes, but there be devils lurking in there. I think you do in general > need to know what the other language is. Take a look at shQuote(), for > instance. (Why, BTW, does that not simply "escape" single quotes using > '"'"' instead of switching to double-quotes and escaping everything in > sight?) I suspect because the references consulted suggested that was not portable. Since 'sh' covers many variants (at least Bourne sh, ash, bash, ksh, zsh) it is hard to get definitive answers. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply: new behaviour for factors in R-2.4.0
On Thu, 28 Sep 2006, Christoph Buser wrote:
> Dear Brian
>
> Thank you for your answer and the comment you included on the
> apply() help page.
>
> 1)
>
> You are correct. My data.frame is coerced into a matrix in
> apply()
>
> 2)
>
> I agree that the new version of unlist() is better and works
> correctly and that in array() (due to as.vector()) the factor
> "ans" is coerced into a character matrix.
>
> Nevertheless I disagree that this is "feature freeze" with
> R version 2.3.1:
It is R 2.4.0 that is in 'feature freeze': we cannot change 2.4.0 now (and
would not have done so when I answered).
See developer.r-project.org for a fuller explanation.
> Since in R-2.3.1, unlist() on a list of factors returned an
> integer vector, the result of apply was an integer matrix and
> not a character matrix.
>
> Therefore my question is if it would be desirable to return an
> integer matrix by changing apply. One could include additional
> code to handle the case if the output "should" be a factor
> matrix and coerce into an integer matrix.
>
> Then the outcome would be consistent with R-2.3.1 without
> changing something in unlist() or array().
>
>
> But in the end I am not sure if an integer matrix is better than
> a character matrix or a factor matrix. I am not sure what output
> is best if one uses as.factor in apply.
It seems best not to do so!
>
> Regards,
>
> Christoph
>
> --
> Christoph Buser <[EMAIL PROTECTED]>
> Seminar fuer Statistik, LEO C13
> ETH Zurich8092 Zurich SWITZERLAND
> phone: x-41-44-632-4673 fax: 632-1228
> http://stat.ethz.ch/~buser/
> --
>
> Prof Brian Ripley writes:
> > Christoph,
> >
> > This is more complicated than your analysis.
> >
> > 1) apply takes a matrix as an argument, not a data frame, and so first
> > coerced 'dat' to a character matrix.
> >
> > 2) unlist is working quite correctly. The issue is array(), which
> > contains as.vector(data). Thus although the result could be a factor
> > matrix, as.vector is coercing it to a character matrix. It might be
> > desirable to return a factor matrix, but we are not going to do that in
> > feature freeze (if ever) and I really don't think it would be what you
> > wanted.
> >
> > Perhaps the help page should contain an explicit statement that the result
> > will be coerced to a basic vector type by as.vector().
> >
> > On Mon, 25 Sep 2006, Christoph Buser wrote:
> >
> > > Dear R-core
> > >
> > > There is a different output for the apply function due to the
> > > change of unlist as mentioned in the R news.
> > >
> > > Newly, applying as.factor() (or factor()) in
> > >
> > > str(dat <- data.frame(x = 1:10, f1 = gl(2,5,labels = c("A", "B"
> > > (d1 <- apply(dat,2,as.factor))
> > >
> > > newly returns a character matrix while in R-2.3.1 the same
> > > command resulted in an integer matrix that was consistent (up to
> > > the ordering of the factor levels) with data.matrix().
> >
> > That's coincidence -- try x=11:20.
> >
> > > The change is caused by the change of unlist() that, used for a
> > > list of factors, newly returns a single factor instead of an
> > > integer. I am happy with this change, but:
> > >
> > > Is it desirable to change apply so that it does not return a
> > > character matrix in the example above or include a warning for
> > > such a case?
> > >
> > > Thank you very much for an answer.
> > >
> > > Regards,
> > >
> > > Christoph Buser
> > >
> > > --
> > > Christoph Buser <[EMAIL PROTECTED]>
> > > Seminar fuer Statistik, LEO C13
> > > ETH Zurich8092 Zurich SWITZERLAND
> > > phone: x-41-44-632-4673 fax: 632-1228
> > > http://stat.ethz.ch/~buser/
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > --
> > Brian D. Ripley, [EMAIL PROTECTED]
> > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> > University of Oxford, Tel: +44 1865 272861 (self)
> > 1 South Parks Road, +44 1865 272866 (PA)
> > Oxford OX1 3TG, UKFax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
On Thu, 28 Sep 2006, Prof Brian Ripley wrote:
> I don't understand why \` is regarded as intentional. It crops up in
> packages date and survival (the same code) in
>
> stop(paste("\`", .Generic, "' not meaningful for dates",
> sep = ""))
>
> which clearly should use sQuote(.Generic) in R, but there seems no reason
> to escape in either R or Splus.
The Splus parser uses the same subroutine to parse
both quoted strings and backquoted names, so we added
"\`" to the list of things not to warn about. E.g.,
we don't want to warn about "\`" in
`back\`quoted name`
We could warn about it in strings but not in names,
but to be consistent we would also have to warn about
unneeded backslashes in
"double\'quoted string"
and
'single\"quoted string'
? We chose not to bother and don't warn about any
sort of backslash-quote.
> > Splus currently "supports" (does not warn about)
> >\nnn (1-3 octal digits)
> >\n, \t, \b, \r, \', \", and \`
> > We do not support the \f, \v, \xnn, \u, or \U.
> > We should add the \f, \v, \a, and \xnn (as well as 0xnn for integers),
> > but we overlooked those. (Adding new backslash sequences is relatively
> > safe: we have been warning about unrecognized \f's for for years so
> > we shouldn't expect to find too many folks using \f where they intended
> > either \\f or f.)
> >
> > We don't support unicode so we won't do anything with the \u or
> > \U. That is something Splus does need to warn about to aid in
> > porting stuff from R.
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unable to load lapack.so
On Thu, 28 Sep 2006, Hiroyuki Kawakatsu wrote: > Hi, > > I'm having problems using ACML with R. I made two changes in > config.site by setting > LDFLAGS="-L/opt/acml3.1.0/gnu64/lib" > BLAS_LIBS="-lacml" That's not how the R-admin manual describes how to do this. Please try the way it does describe (and please try 2.4.0 RC rather than an old patched version of 2.3.1). I am a bit puzzled: currently ACML is only available for Linux, Solaris and Windows, so where did you find a FreeBSD version? > ./config and make go through but when I try to use the lm() function, > I get the error message > > Error in chol2inv(Qr$qr[p1, p1, drop = FALSE]) : >lapack routines cannot be loaded > In addition: Warning message: > unable to load shared library '/usr/local/R-patched/modules//lapack.so': > Shared object "libRlapack.so" not found, required by "lapack.so" > > What am I missing? Apparently libRlapack.so. Is it there (in R_HOME/lib)? >> version > _ > platform x86_64-unknown-freebsd6.1 > arch x86_64 > os freebsd6.1 > system x86_64, freebsd6.1 > status Patched > major 2 > minor 3.1 > year 2006 > month 06 > day01 > svn rev38258 > language R > version.string Version 2.3.1 Patched (2006-06-01 r38258) > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Accesing R c-code
Hi r-devel, I am working on a R extension. My package is writen on C++ and in my code I require a R function object. I received the R function object, then a point x in which the "function" is going to be evaluated is generated in some way, then I evalue the "function" at x and I repete this process several thousand of times. Since I am using the function eval(SEXP fn, SEXP env) my code is really slow. Due to my major concern is speed, I wonder to know when it is posible to access to the parse tree of the R function object and build my own c++ parser tree in order to have c++ doing the evaluations of the function instead of R, as it is now working in my c++ code. What I want to avoid is to have to develope a complete parser mainly because it would take me too much time since I am a newe in compilers and parsers. It would also help me to know how R mcmc packages work, because it is more or less the same situation. In mcmc packages a target density function is required, and I suppose this density function is evaluated many many times, but this packages are not too slow. Then, if anyone is able to provide me any insight into what I might to, I would be grateful. pb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accesing R c-code
On Thursday 28 September 2006 13:36, Patricia Bautista Otero wrote: > Hi r-devel, > > I am working on a R extension. My package is writen on C++ and in my code > I require a R function object. I received the R function object, then a > point x in which the "function" is going to be evaluated is generated in > some way, then I evalue the "function" at x and I repete this process > several thousand of times. Since I am using the function eval(SEXP fn, > SEXP env) my code is really slow. Due to my major concern is speed, I > wonder to know when it is posible to access to the parse tree of the R > function object and build my own c++ parser tree in order to have c++ > doing the evaluations of the function instead of R, as it is now working > in my c++ code. What I want to avoid is to have to develope a complete > parser mainly because it would take me too much time since I am a newe in > compilers and parsers. > > It would also help me to know how R mcmc packages work, because it is more > or less the same situation. In mcmc packages a target density function is > required, and I suppose this density function is evaluated many many > times, but this packages are not too slow. If you want to look at a package, you can just download the source and look at it. The source for most packages is available on CRAN. Sean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation patch for 'match' and 'palette'
Here is a patch to improve documentation for finding useful, yet newish,
functions: 'findInterval' and 'colorRamp'. I think that it is worthwhile
to mention these in the 'seealso' section of the similar 'match' and
'palette' documents. I had difficulty finding these functions at first,
as they have compound names. Modify the patch as needed:
Index: src/library/base/man/match.Rd
===
--- src/library/base/man/match.Rd (revision 39542)
+++ src/library/base/man/match.Rd (working copy)
@@ -65,6 +65,8 @@
\code{\link{pmatch}} and \code{\link{charmatch}} for (\emph{partial})
string matching, \code{\link{match.arg}}, etc for function argument
matching.
+ \code{\link{findInterval}} similarly returns a vector of positions, but
+ finds numbers within intervals, rather than exact matches.
\code{\link{is.element}} for an S-compatible equivalent of \code{\%in\%}.
}
Index: src/library/grDevices/man/palette.Rd
===
--- src/library/grDevices/man/palette.Rd(revision 39542)
+++ src/library/grDevices/man/palette.Rd(working copy)
@@ -31,7 +31,7 @@
\code{\link{colors}} for the vector of built-in \dQuote{named} colors;
\code{\link{hsv}}, \code{\link{gray}}, \code{\link{rainbow}},
\code{\link{terrain.colors}},\dots to construct colors;
-
+ \code{\link{colorRamp}} to interpolate colors, making custom palettes;
\code{\link{col2rgb}} for translating colors to RGB 3-vectors.
}
\examples{
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build error/zlib question
Hi, I am unable to build a package I maintain using a relatively current build of R-2.4.0 alpha, whereas the package builds just fine on R-2.3.1. Both versions of R were built from source. I'm hoping a guRu might be able to give some help. Some snippets from the build process: R-2.3.1 making DLL ... gcc -Ic:/R-2.3.1/src/extra/zlib -DHAVE_ZLIB -Ic:/R-2.3.1/include -Wall -O2 -c read_cdffile.c -o read_cdffile.o read_cdffile.c: In function `readQC': read_cdffile.c:565: warning: unused variable `param_unit' windres --include-dir c:/R-2.3.1/include -i makecdfenv_res.rc -o makecdfenv_res.o gcc -shared -s -o makecdfenv.dll makecdfenv.def read_cdffile.o makecdfenv_res.o -Lc:/R-2.3.1/bin -lR ... DLL made R-2.4.0 beta making DLL ... gcc -Ic:/rw2040dev/src/extra/zlib -DHAVE_ZLIB -Ic:/rw2040dev/include -Wall -O2 -std=gnu99 -c read_cdffile.c -o read_cdffile.o read_cdffile.c: In function `readQC': read_cdffile.c:565: warning: unused variable `param_unit' windres --include-dir c:/rw2040dev/include -i makecdfenv_res.rc -o makecdfenv_res.o gcc -shared -s -o makecdfenv.dll makecdfenv.def read_cdffile.o makecdfenv_res.o -Lc:/rw2040dev/bin -lR read_cdffile.o:read_cdffile.c:(.text+0x42): undefined reference to `gzgets' read_cdffile.o:read_cdffile.c:(.text+0xf3): undefined reference to `gzopen' read_cdffile.o:read_cdffile.c:(.text+0x10f): undefined reference to `gzgets' read_cdffile.o:read_cdffile.c:(.text+0x140): undefined reference to `gzrewind' read_cdffile.o:read_cdffile.c:(.text+0x177): undefined reference to `gzclose' collect2: ld returned 1 exit status make[3]: *** [makecdfenv.dll] Error 1 make[2]: *** [srcDynlib] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-makecdfenv] Error 2 > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status alpha major 2 minor 4.0 year 2006 month 09 day10 svn rev39242 language R version.string R version 2.4.0 alpha (2006-09-10 r39242) TIA, Jim James W. MacDonald, M.S. Biostatistician Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623 ** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build when the package name is different from the directory name
Dear Seth, Thank you for your message. On Thursday 28 September 2006 16:22, Seth Falcon wrote: > Arne Henningsen <[EMAIL PROTECTED]> writes: > > Hi, > > > > I was really happy when I saw that in R version 2.3.0 "R CMD check" works > > for packages whose package name is different from the directory name in > > which it is located (see http://cran.r-project.org/src/base/NEWS). > > Now, I can have branches of my packages in directories like > > "[...]/branches//", while I had to use > > "[...]/branches//" before. > > "R CMD check " runs as expected but when I build the > > package with "R CMD build ", the file name of the source > > package is "_-.tar.gz" (and > > not "_-.tar.gz"). Furthermore > > the base directory inside the .tar.gz archive is "" (and > > not ""). > > I think that's a feature. Note that R CMD INSTALL on such a package > does install the package under its "real" name. I don't think that this is a feature -- it is IMHO rather a bug. While "R CMD check" and "R CMD INSTALL" take the real name (as expected), "R CMD build" does not. However, if I don't have to change the file name and the name of the base directory before uploading the package to CRAN, the current behaviour of "R CMD build" is IMHO acceptable. (I did not yet get an answer on my question regarding CRAN.) > It is a feature because it allows me to distinguish the tarballs from > each other. You can distinguish the tarballs according their version number and patch level (they are called "--.tar.gz" > Perhaps you can make this work for you by using a more meaningful > description than version number in your branch name. For example: > > .../branches/foo-release > .../branches/foo-devel > .../branches/foo-someNewFeature In this case, the file name of the package is e.g. "-release--.tar.gz" and the base directory is e.g. "-release". Is this accepted on CRAN? > As another poster suggested, an SCM is the right tool for tracking > versions. > > + seth Arne > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Arne Henningsen Department of Agricultural Economics University of Kiel Olshausenstr. 40 D-24098 Kiel (Germany) Tel: +49-431-880 4445 Fax: +49-431-880 1397 [EMAIL PROTECTED] http://www.uni-kiel.de/agrarpol/ahenningsen/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
