Re: [Rd] alpha, portable use
I am still confused about this (and it is still happening with R-beta).
Writing R Extensions suggests I need a Makefile or Makevars in my
package, but that has not been the case previously. Is there now a
requirement that all packages need Makefiles or Makevars if there is
fortran to be compiled? This is only happening on one of my systems.
Building R and make check work fine on that system, but it seems that
not all the information gets passed along to package compiles.
(BTW, this is just a warning, but Kurt suggested we try to eliminate
warnings.)
Paul Gilbert
Prof Brian Ripley wrote:
On Wed, 20 Sep 2006, Paul Gilbert wrote:
When I build one of my packages with alpha from yesterday I am getting
* checking for portable use of $BLAS_LIBS ... WARNING
apparently missing $(FLIBS) in 'PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)'
Is this something I should worry about? (Possibly I got this before and
didn't notice.)
Yes, please do check Writing R Extensions
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] alpha, portable use
Doug
I do indeed have a Makevars file after all. Thanks for spelling out the
interpretation of the warning message.
Paul
Douglas Bates wrote:
On 9/25/06, Paul Gilbert [EMAIL PROTECTED] wrote:
I am still confused about this (and it is still happening with R-beta).
Writing R Extensions suggests I need a Makefile or Makevars in my
package, but that has not been the case previously. Is there now a
requirement that all packages need Makefiles or Makevars if there is
fortran to be compiled? This is only happening on one of my systems.
Building R and make check work fine on that system, but it seems that
not all the information gets passed along to package compiles.
(BTW, this is just a warning, but Kurt suggested we try to eliminate
warnings.)
From the warning it seems that you have a Makevars file in the src
directory for your package. The change in R-2.4.0 is that packages
that did have a Makevars file of the form
PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)
should change that to
PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
Paul Gilbert
Prof Brian Ripley wrote:
On Wed, 20 Sep 2006, Paul Gilbert wrote:
When I build one of my packages with alpha from yesterday I am getting
* checking for portable use of $BLAS_LIBS ... WARNING
apparently missing $(FLIBS) in 'PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)'
Is this something I should worry about? (Possibly I got this
before and
didn't notice.)
Yes, please do check Writing R Extensions
La version française suit le texte anglais.
This email may contain privileged and/or confidential
inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] alpha, portable use
When I build one of my packages with alpha from yesterday I am getting
* checking for portable use of $BLAS_LIBS ... WARNING
apparently missing $(FLIBS) in 'PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)'
Is this something I should worry about? (Possibly I got this before and
didn't notice.)
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
check
c) conveys extra information about the package's context, to humans, and
d) will potentially be used in automated or semi-manual
``R package database management''
I think d) is important, but I think there are too many variations on a)
and c) to hope that this would be used consistently. As Fritz said, the
thing he can remember (and what I would remember) is whether a package
is mandatory or optional. Fine variations within optional are just
too hard to define clearly in a two-level classification.
On the other hand, they are relatively easy to convey in clearly written
documentation. So I'd still recommend that we stay with just Depends
and Suggests, but encourage authors to document what they mean by
Suggests.
The problem I see here is that this is a change from the status quo,
which is likely to make a real mess for some time. The status quo is
that packages in Depends and Suggests are needed to check examples and
vignettes. I would not change this without a very good reason. It would
be best to put other suggestions of extensions, that some users may want
to use, somewhere else. The current situation is that these suggestions
are sprinkled in Rd files, vignettes, web pages, etc. This situation is
not too bad, but it might be nice to have some place users would expect
to find this information. However, changing the meaning of Suggests to
be developer defined does not strike me as an improvement.
Paul Gilbert
Duncan Murdoch
Martin
FrL Ad the wording in the manual: obviously that is not
FrL optimal (otherwise no need for parts of this email
FrL thread), perhaps somebody else than the original author
FrL (=me) could try to improve it for 2.4 after this
FrL clarifications? Otherwise I will give it a shot next
FrL week after I return from Rome.
__
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
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch wrote:
On 8/30/2006 12:28 PM, Paul Gilbert wrote:
Duncan Murdoch wrote:
On 8/30/2006 4:44 AM, Martin Maechler wrote:
FrL == friedrich leisch [EMAIL PROTECTED]
on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
Duncan Murdoch [EMAIL PROTECTED] writes:
I think we need an option to R CMD check rather than a new
field in the
DESCRIPTION. Currently a package could be mentioned for any
of these
reasons:
1. To make functions, examples or vignettes work
2. To allow optional functionality in functions, examples
or vignettes.
3. Because it contains complementary functions.
I don't think we really need to worry about 3: it
should be contained
in 1 or 2, if reasonably complete examples are given.
Case 1 is handled by Depends.
I think there is an important distinction between a
dependency needed
for the package to function and a dependency needed to
demonstrate
said functionality via an example or vignette. The former is
what
Depends is about, the latter is something else (Suggests).
FrL Sorry to join in late, I am at the Compstat conference and
have limited
FrL email access. What Seth describes in the above paragraph is
exactly what I
FrL had in mind when splitting the single Depends field we had
into Depends
FrL and Suggests: Depends are a necessity to run the package,
Suggests is nice
FrL to have but not necessary. If you know how to use a package
you may the
FrL decide not to install a package that is only suggested, but
FrL * may not be interested to execute the examples,
FrL * know that you never need the extra functionality
FrL * ...
FrL so it should not be auto-installed unless you ask for
FrL it (the default could also be the other way round, the
FrL point is that it should be possible to have package foo
FrL but not the packages it only suggests). On CRAN we
FrL check with all suggestions to test all bits and pieces,
FrL having an option in R CMD check to test only with
FrL suggests may be nice, if there is use for it.
Yes.
However, I see two (related) problems with the current 'Suggests'
and that's why I opened this thread proposing to have a (what I now
would want to simply call) 'canUse' :
1) For 'R CMD check' (and hence CRAN checking),
Packages in 'Suggests' must be require()able, and
hence all testing only happens *with* the suggested packages
being there, and not without.
2) Suggests suggests to the human reader of DESCRIPTION that
the package authors suggest to also install the packages listed
there.
Now there are cases, I (as package author) want to show some
stuff, or even provide compatibility functionality for some
packages that are related to mine, but which I really do not
``suggest''
to also be installed, e.g., because the other packages do
similar stuff as mine, but I believe my package to be
superior. In such a case, I may, e.g., want to provide
functions for porting the other package classes to my package's.
Duncan Murdoch has proposed to take care of 1) by
still only use 'Suggests' but adding another option to 'R CMD
check', let's say --no-suggests which would run all the
checks without having the suggested packages available ---
something not quite easy to implement, BTW:
Imagine the typical windows users who (AFAICS) always only use
one library into which they install all packages.
How do you want the if( require(my_suggested_package) ) {
...
}
clause *not* to be triggered in such a case ?
I would expect require to return FALSE. This could be done by check
installing a new version of require() (as it installs new T and F),
or by the standard require() being modified to check a stop list
before acting (I'd prefer this, because it would make it easier for
developers to experiment with functions in different environments),
or by playing around with the names of things in the library
(probably not workable on Windows), etc.
I think the default check behaviour on CRAN should be my middle case:
test based on what is currently installed, don't require packages
listed in Suggests to be installed. I'm not sure if that should be
the default behaviour for R CMD check at the command line: as Kurt
said, usually a developer wants to check all of the code.
I do agree quite a bit that such a '--no-suggests' option would
be very useful for 'R CMD check' -- in addition to my proposal.
I think the other extreme (which I think is there now as
_R_CHECK_FORCE_SUGGESTS_) is also important.
Further, I think 2) above is not taken care of anyway.
After all the interesting statements and alternative proposals,
I'm still proposing to introduce a 'canUse' field for DESCRIPTION
which
a) has a human-readable intent of being weaker than
Re: [Rd] PATCH: Add fields argument to installed.packages and available.packages
Martin Maechler wrote:
...
The idea was a field related to but weaker than 'Suggests' :
Something like
'canMakeUseOf: pkg1 [, pkg2, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If pkg1 is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith'
What do you (R-devel listeners) think about the idea?
I still like this idea. I prefer 'canMakeUseOf' to
'isHappilyCoworkingWith' mainly because it seems less ambiguous.
Paul Gilbert
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was .. Add 'fields' argument ..]
Duncan Murdoch wrote:
On 8/29/2006 10:12 AM, Martin Maechler wrote:
PaulG == Paul Gilbert [EMAIL PROTECTED]
on Tue, 29 Aug 2006 09:55:09 -0400 writes:
PaulG Martin Maechler wrote:
...
The idea was a field related to but weaker than
'Suggests' :
Something like
'canMakeUseOf: pkg1 [, pkg2, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If pkg1 is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith'
What do you (R-devel listeners) think about the idea?
PaulG I still like this idea. I prefer 'canMakeUseOf' to
PaulG 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
Thanks, Paul.
As you may have guessed I should have put a :-) beside the
'isHappily...' .
Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.
I think we need an option to R CMD check rather than a new field in
the DESCRIPTION. Currently a package could be mentioned for any of
these reasons:
1. To make functions, examples or vignettes work
2. To allow optional functionality in functions, examples or vignettes.
3. Because it contains complementary functions.
I don't think we really need to worry about 3: it should be contained
in 1 or 2, if reasonably complete examples are given.
Case 1 is handled by Depends.
Well, from Writing R Extensions
The optional Suggests field uses the same syntax as Depends and
lists packages that are not
necessarily needed. This includes packages used only in examples or
vignettes
So case 1 is handled by the combination of Depends and Suggests, and we
need something to handle case 2.
The related question is whether the CRAN checks should try to check 2,
or perhaps there needs to be 2a and 2b. There are cababilities (and
data) that CRAN may not have, so it would be nice distinguish things
that should be checked on CRAN from things that should not be.
Paul
An author should check case 2 both with and without the suggested
package. A user might be satisfied with a simple check as things
currently stand, or might want a stringent check like the author
wants. The author can't know that, because it will depend on the user.
So I don't think this is something that should be changed in
DESCRIPTION. There should be an option to R CMD check to include or
exclude packages mentioned in the Suggests entry. (I'd suggest a 3
level option: check as though they are not available, check as
currently installed, require that they be available.)
Duncan Murdoch
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Seth Falcon wrote:
Duncan Murdoch [EMAIL PROTECTED] writes:
On 8/29/2006 11:58 AM, Seth Falcon wrote:
I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette. The former is what
Depends is about, the latter is something else (Suggests).
Yes, that's a good point, especially with vignettes. Only the package
author needs to be able to run them.
Yes, but just to keep things clear: the value of vignettes is that
users can follow along. So the ability to programatically identify
the extra required packages is valuable.
But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error. Package authors should wrap optional examples in code like if
(require(...)).
This is a work around that is ok for the developer's testing and to
prevent failure on CRAN, and I use it. But, other than actually reading
the examples, it provides no hints to other testers or users about
things that might be installed, or installed first, to give more
complete testing and more functionality.
Looking toward the future, I think it would be useful to have a standard
mechanism to indicate extensions that are available in a package, and
might be tested and used, but are not necessarily available on CRAN. For
instance, an example might access to a purchased database or take
advantage of a computer cluster. It seems limiting to think that all
testing that cannot be done on CRAN must be done almost exclusively by
the developer.
Paul
I agree. As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.
Best,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch wrote:
On 8/29/2006 2:24 PM, Paul Gilbert wrote:
Seth Falcon wrote:
Duncan Murdoch [EMAIL PROTECTED] writes:
On 8/29/2006 11:58 AM, Seth Falcon wrote:
I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette. The former is what
Depends is about, the latter is something else (Suggests).
Yes, that's a good point, especially with vignettes. Only the package
author needs to be able to run them.
Yes, but just to keep things clear: the value of vignettes is that
users can follow along. So the ability to programatically identify
the extra required packages is valuable.
But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error. Package authors should wrap optional examples in code like if
(require(...)).
This is a work around that is ok for the developer's testing and to
prevent failure on CRAN, and I use it. But, other than actually
reading the examples, it provides no hints to other testers or users
about things that might be installed, or installed first, to give
more complete testing and more functionality.
I'm not saying to use this instead of Suggests, I'm saying to do both.
This way the Suggests entries really are suggestions: the examples
will run with or without the presence of the suggested packages.
I think there are so many variations on when a Suggested package
should be installed, that it's not reasonable to expect to be able to
encode them all in a machine readable way. They should be documented
in human readable format.
Looking toward the future, I think it would be useful to have a
standard mechanism to indicate extensions that are available in a
package, and might be tested and used, but are not necessarily
available on CRAN. For instance, an example might access to a
purchased database or take advantage of a computer cluster. It seems
limiting to think that all testing that cannot be done on CRAN must
be done almost exclusively by the developer.
If by mechanism you mean human-readable documentation, I agree with
this.
Yes, I was think of human-readable and in a standard location, like a
field in the DESCRIPTION file. (You are thinking of fields in the
DESCRIPTION file as human-readable, are you not?)
Paul
Duncan Murdoch
Paul
I agree. As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.
Best,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential
inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] foo2Args()
I was just considering trying to clean up the arguments to a function
that calls other functions,
and was playin with a suggestion Achim made during a conversation at
useR. The idea is, instead of using list(), use a small function to
construct and check arguments. My hope was to be able to do this without
making it globally visible:
foo - function(x, args=foo2Args()) {
foo2Args - function(a=1, b=2){list(a,b)}
# above would actual do more testing of args
#now I would call foo2 with args, but to test just
args
}
Now,
foo(1) # should I be surprized that this works
[[1]]
[1] 1
[[2]]
[1] 2
foo(1, args=foo2Args(a=2, b=10)) # or that this does not
Error in foo(1, args = foo2Args(a = 2, b = 10)) :
could not find function foo2Args
Paul
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] foo2Args()
Duncan Murdoch wrote:
On 6/30/2006 5:12 PM, Paul Gilbert wrote:
Duncan Murdoch wrote:
On 6/30/2006 4:19 PM, Paul Gilbert wrote:
I was just considering trying to clean up the arguments to a
function that calls other functions,
and was playin with a suggestion Achim made during a conversation at
useR. The idea is, instead of using list(), use a small function to
construct and check arguments. My hope was to be able to do this
without making it globally visible:
foo - function(x, args=foo2Args()) {
foo2Args - function(a=1, b=2){list(a,b)}
# above would actual do more testing of args
#now I would call foo2 with args, but to test just
args
}
Now,
foo(1) # should I be surprized that this works
[[1]]
[1] 1
[[2]]
[1] 2
I don't think it really works, it's just a coincidence that the
answer matches your expectations:
foo(3)
[[1]]
[1] 1
[[2]]
[1] 2
Or maybe I am completely misunderstanding your expectations...
foo(1, args=foo2Args(a=2, b=10)) # or that this does not
Error in foo(1, args = foo2Args(a = 2, b = 10)) :
could not find function foo2Args
This is a somewhat subtle thing about the way args are evaluated.
What is done makes lots of sense once you understand it:
- When you specify an argument in the call, the expression you give
is evaluated in the current context. In the context where you made
this call, foo2Args is not defined, hence the error.
- When you specify a default for an argument, it is evaluated in the
local context of the function evaluation. So as a default, foo2Args
is recognized, because it's a local variable within foo.
You also need to remember lazy evaluation: neither of the above
actually take place until args is used.
R is pretty flexible, so it's probably possible to do whatever you
intended here; can you describe exactly what you want to happen?
I guess what I want to happen is that when args is used it it gets
evaluated in the local context of the function, whether or not I am
specifying the argument or using the default. Is there a way to do that?
I think this would work:
foo - function(x, args=foo2Args()) {
foo2Args - function(a=1, b=2){list(a,b)}
# above would actual do more testing of args
#now I would call foo2 with args, but to test just
args - eval(substitute(args))
args
}
The explanation is this:
substitute(args) gets the expression attached to args without evaluating
it. eval( substitute(args) ) then evaluates it; since I didn't say which
environment to work in, it defaults to the current evaluation environment.
HOWEVER, this function is a bad idea. Users don't expect evaluation
like this. For example, this would mess it up:
args - 2
foo(1, args=foo2Args(a=args, b=10))
because it would try to evaluate args in the local environment, rather
than where the user put it. You'd get weird behaviour if any of the
values in foo2Args used variables rather than constants, because they'd
be evaluated in the function, not in the user's workspace.
Yes, I realized on the way home that what I want is not what I said,
because I need the function to be found (thus in the local context) but
I need the arguments to foo2Args from the calling context, if they are
supplied.
The general idea is to provide a nice clean way to pass arguments along
to other functions. If foo is calling a few functions this becomes
really messy, and even moreso if those functions call other functions
that need arguments passed along. The way I have always done this is
with a list, but there may be some advantage to using a function that
constructs the argument. However, there are likely to be namespace
conflicts if everyone does this and this constructing function name has
to be exported, or even visible outside of the call to the function. For
example, one of the function I want to call is optim. If everyone that
calls optim wants to do this (supposing it is a good idea), they would
all probably decide a good name for the function is optimArgs.
Perhaps sticking with a list is the best idea.
Thanks,
Paul
Duncan Murdoch
What I expected to happen was that it would always get evaluated
either in the local context or in the calling context, i.e., it would
fail or not fail, but that would not depend on whether I am specifying
the argument or using the default, so your first points explain this.
Thanks,
Paul
Duncan Murdoch
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] UTF-8 and .Rd files
I've been following this thread hoping for the definitive answer...
Peter Dalgaard wrote:
Well, I do tend to think that we should just use utf, assuming that
people have the relevant glyphs. If they don't, then they might get
little hollow rectangles but so what?
My problem is that I put an ö in a reference in an Rd file, and now my
builds fail on some of my systems. I can switch which systems work and
which are broken, but I can not get it to work on all systems. I have
spent way too much time trying to figure out what is wrong. So, wrt so
what, I need to choose between checking my packages on all the
different systems I use, or having an ö in the Rd file. I think my
problem is more complicated than having the relevant glyphs. I suspect
it has to do with having the same locale on all systems doing NFS
mounts, or on my cvs server, or something strange like that.
Paul
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE and bundle
Iago
There is a problem that bundle checking works slightly differently than
individual package checking in this regard. I think it has to do with
when the namespace gets registered, or something like that. As I recall,
the work around is to explicitely require the package in the test files
for it. I.e. put
require(pac)
in all the files in pac/tests. If that does not work, let me know and
I will look more carefully to find what I had to do.
Paul
Iago Mosqueira wrote:
Dear all,
I have a package that passes R CMD check, and shows no problems when using all
its methods as declared in NAMESPACE. When this package is added to a bundle,
which already consists of 5 packages, the examples in the Rd pages thta call a
number of methods fail during the bundle check. These all passed when check is
run on this package alone. Other packages in the bundle are very similar, in
that all import all S4 classes and methods from the first package (using
import(FLCore) in NAMESPACE) in the bundle, and export their own overloaded
methods.
If I run check on a mini-bundle consisting only of the main package (FLCore)
and this problematic package, it shows no problem. So I assume a problem of
NAMESPACE conflict is the culprit, but experimnting with various package
combinations, to try and isolate the conflict, has not worked. This package
seems to conflict with every other secondary package.
I am dealing with internal dependencies by adding a require(FLCore) line to
the .onLoad() call in zzz.R
Can anybody point me at what to look for? What could be the reason for this
problem?
I hope the explanation was clear enough. Many thanks,
Iago
Dr. Iago Mosqueira
Marine Research Division
AZTI Tecnalia
Txatxarramendi Ugartea, z/g
48395 Sukarrieta - Bizkaia
Spain
+34 946 029 448
+34 946 029 400
+34 946 029 401 (Fax)
[EMAIL PROTECTED]
http://www.azti.es/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE and bundle
Iago
I think your R code file needs an .onLoad function. Here is the
..onLoad from my dse1 package which is in the dse bundle, as is tframe,
along with comments which I had forgotten.
..onLoad - function(library, section) {
.DSEflags(list(COMPILED=TRUE, DUP=TRUE))
# next require is necessary for bundle check to run examples,
# but does not seem to be necessary when packages are not bundled
require(tframe)
invisible(TRUE)
}
Hope this works,
Paul
Iago Mosqueira wrote:
-Mensaje original-
De: Paul Gilbert [mailto:[EMAIL PROTECTED]
Enviado el: jue 22/06/2006 15:47
Para: Iago Mosqueira
CC: r-devel@r-project.org
Asunto: Re: [Rd] NAMESPACE and bundle
Iago
There is a problem that bundle checking works slightly differently than
individual package checking in this regard. I think it has to do with
when the namespace gets registered, or something like that. As I recall,
the work around is to explicitely require the package in the test files
for it. I.e. put
require(pac)
in all the files in pac/tests. If that does not work, let me know and
I will look more carefully to find what I had to do.
Paul
Paul,
Many thanks. The problem is in the examples contained in the Rd files,
where we do not explictely load the package, as we do in test files.
But it is only a problem for the examples in this package, not in the
others that share the same package dependencies. Can you see any
solution or something I else I should check for?
Thanks
Iago
Iago Mosqueira wrote:
Dear all,
I have a package that passes R CMD check, and shows no problems when
using all its methods as declared in NAMESPACE. When this package is
added to a bundle, which already consists of 5 packages, the examples
in the Rd pages thta call a number of methods fail during the bundle
check. These all passed when check is run on this package alone. Other
packages in the bundle are very similar, in that all import all S4
classes and methods from the first package (using import(FLCore) in
NAMESPACE) in the bundle, and export their own overloaded methods.
If I run check on a mini-bundle consisting only of the main package
(FLCore) and this problematic package, it shows no problem. So I
assume a problem of NAMESPACE conflict is the culprit, but
experimnting with various package combinations, to try and isolate the
conflict, has not worked. This package seems to conflict with every
other secondary package.
I am dealing with internal dependencies by adding a require(FLCore)
line to the .onLoad() call in zzz.R
Can anybody point me at what to look for? What could be the reason
for this problem?
I hope the explanation was clear enough. Many thanks,
Iago
Dr. Iago Mosqueira
Marine Research Division
AZTI Tecnalia
Txatxarramendi Ugartea, z/g
48395 Sukarrieta - Bizkaia
Spain
+34 946 029 448
+34 946 029 400
+34 946 029 401 (Fax)
[EMAIL PROTECTED]
http://www.azti.es/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential information, and
the Bank of
Canada does not waive any related rights. Any distribution, use, or
copying of this
email or the information it contains by other than the intended
recipient is
unauthorized. If you received this email in error please delete it
immediately from
your system and notify the sender promptly by email that you have done so.
Le présent courriel peut contenir de l'information privilégiée ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent.
Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il
contient par une
personne autre que le ou les destinataires désignés est interdite. Si
vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer
sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez
éliminé de votre
ordinateur toute copie du courriel reçu.
La version française suit le texte anglais.
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you
[Rd] task view errors
I am getting several errors about Windows only packages when I use task
views. Is this suppose to be a Windows-centric utility?
Also, I am sure there must be a simple way to tell which packages are in
a view, but I haven't found it. If there isn't, it would be nice to have.
Paul Gilbert
___
install.views(c(
Multivariate, Econometrics, Finance, gR, Bayesian,
SocialSciences),
repos = http://cran.at.r-project.org;)
* Installing *source* package 'rcom' ...
Package 'rcom' can only be installed/used under Windows.
ERROR: configuration failed for package 'rcom'
** Removing
'/home/paul/toolchain/R/Linux-2.6.7-mm6/R-2.3.0/site-library/rcom'
* Installing *source* package 'BRugs' ...
Package 'BRugs' currently only works under Windows.\nIt is supposed to
work under Linux in future releases.
ERROR: configuration failed for package 'BRugs'
** Removing
'/home/paul/toolchain/R/Linux-2.6.7-mm6/R-2.3.0/site-library/BRugs'
* Installing *source* package 'mimR' ...
Package 'mimR' can only be installed/used under Windows.
ERROR: configuration failed for package 'mimR'
** Removing
'/home/paul/toolchain/R/Linux-2.6.7-mm6/R-2.3.0/site-library/mimR'
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package installation errors
I installed R-2.3.1 and ran make check without problem, but I am having
trouble installing several packages using gcc (GCC) 3.2.3 20030502 (Red
Hat Linux 3.2.3-53)
on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) Kernel
2.4.21-40.ELsmp on an x86_64
Below are the messages from MCMCpack. Perhaps my systems are messed up?
Paul Gilbert
install.packages(MCMCpack)
Warning in install.packages(MCMCpack) : argument 'lib' is missing:
using /home/mfa/gilp/toolchain/R/asd05546/R-2.3.1/site-library
--- Please select a CRAN mirror for use in this session ---
Selection: 3
trying URL 'http://cran.at.r-project.org/src/contrib/MCMCpack_0.7-2.tar.gz'
Content type 'application/x-tar' length 303618 bytes
opened URL
==
downloaded 296Kb
* Installing *source* package 'MCMCpack' ...
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking for trunc... no
configure: creating ./config.status
config.status: creating src/Makevars
** libs
g++ -I/home/mfa/gilp/toolchain/R/asd05546/R-2.3.1/include
-I/home/mfa/gilp/toolchain/R/asd05546/R-2.3.1/include
-I/usr/local/include -DSCYTHE_COMPILE_DIRECT -DSCYTHE_NO_RANGE -fpic
-g -O2 -c distributions.cc -o distributions.o
distributions.cc: In function `double SCYTHE::INTERNAL::dbinom_raw(const
double, const double, const double, const double)':
distributions.cc:2048: could not split insn
(insn:TI 454 450 91 (set (reg:DF 23 rxmm2 [58])
(if_then_else:DF (eq (mem:DF (reg/v/u/f:DI 3 rbx [59]) [5 S8 A64])
(reg:DF 23 rxmm2 [58]))
(reg:DF 21 rxmm0 [160])
(const_double:DF 0 [0x0] 0 [0x0] 0 [0x0]))) 660
{*sse_movdfcc_const0_3} (insn_list 76 (insn_list 450 (nil)))
(expr_list:REG_DEAD (reg/v/u/f:DI 3 rbx [59])
(expr_list:REG_DEAD (reg:DF 21 rxmm0 [160])
(nil
distributions.cc:2048: Internal compiler error in final_scan_insn, at
final.c:
2624
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla/ for instructions.
make: *** [distributions.o] Error 1
chmod: failed to get attributes of
`/home/mfa/gilp/toolchain/R/asd05546/R-2.3.1/site-library/MCMCpack/libs/*':
No such file or directory
ERROR: compilation failed for package 'MCMCpack'
** Removing
'/home/mfa/gilp/toolchain/R/asd05546/R-2.3.1/site-library/MCMCpack'
The downloaded packages are in
/tmp/RtmpZMSbbz/downloaded_packages
Warning message:
installation of package 'MCMCpack' had non-zero exit status in:
install.packages(MCMCpack)
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: checking examples: how to (not) pause execution
I think the more usual way to solve this is to have the user set
par(ask=TRUE) is they want to be prompted. This gives the user the
option of being prompted, or not. It makes the example tests work, and
simplifies your code because you don't need to worry about the prompt
mechanism. It also potentially helps with multi-language support, etc, etc.
Paul
Lutz Prechelt wrote:
Hello all,
trying to prepare my first package for submission to CRAN
I am stumbling over the checking examples step
of R CMD check.
I have some examples that produce more than one plot.
I currently separate those plot calls by
readline(Press Return for a plot including a density plot)
or some such to have R wait before producing the next plot.
This works OK for end users, but fails miserably
during R CMD check, which appears to just eat the
next line of the example source file for the input of readline
(which took me quite a while to understand it).
What is the right way to solve this problem?
I can hardly believe that there is none (although the
examples of 'plot' suggest exactly this: They run
through multiple plots in a hurry.)
I guess the appropriate approach would be if
example() had some kind of single-stepping option?
Any hints?
Lutz Prechelt
P.S.:
Documentation remark:
For users struggling with R CMD check it might be
very helpful if R-exts.pdf contained some pointers
to the functions or mechanisms used by R CMD check,
or the names of source files where to find such information
so they can better understand what is going on.
Prof. Dr. Lutz Prechelt; [EMAIL PROTECTED]
Institut fuer Informatik; Freie Universitaet Berlin
Takustr. 9; 14195 Berlin; Germany
+49 30 838 75115; http://www.inf.fu-berlin.de/inst/ag-se/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-devel and PGI 6.0 compile error
I am trying to compile R-devel (R-devel_2006-05-17.tar.gz) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) using the Portland Group compiler 6.0. (I have not yet successful compiled R on this configuration, so I don't know if this is a new problem.) I get an error pgcc -L/usr/local/pgi/linux86-64/6.0/libso -L/usr/lib64 -o dftables dftables.o ../dftables chartables.h ../dftables: error while loading shared libraries: libpgc.so: cannot open shared object file: No such file or directory make[3]: *** [chartables.h] Error 127 The library containing libpgc.so is in both my LD_LIBRARY_PATH and in LDFLAGS. More details are below. In configure I am also getting checking whether C99 double complex is supported... checking complex.h usability... no checking complex.h presence... yes configure: WARNING: complex.h: present but cannot be compiled configure: WARNING: complex.h: check for missing prerequisite headers? configure: WARNING: complex.h: see the Autoconf documentation configure: WARNING: complex.h: section Present But Cannot Be Compiled configure: WARNING: complex.h: proceeding with the preprocessor's result configure: WARNING: complex.h: in the future, the compiler will take precedence configure: WARNING: ## --- ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## --- ## checking for complex.h... yes Paul Gilbert _ ~/toolchain/R/clusterPGI/R-devel:../../src/R-devel/configure --with-x=no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu loading site script '../../src/R-devel/config.site' checking for pwd... /bin/pwd checking whether builddir is srcdir... no checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking for gawk... gawk checking for egrep... grep -E checking whether ln -s works... yes checking for ranlib... ranlib checking for bison... bison -y checking for ar... ar checking for a BSD-compatible install... /usr/bin/install -c checking for sed... /bin/sed checking for less... /usr/bin/less checking for perl... /usr/bin/perl checking whether perl version is at least 5.004... yes checking for dvips... no checking for tex... no checking for latex... no configure: WARNING: you cannot build DVI versions of the R manuals checking for makeindex... no checking for pdftex... no checking for pdflatex... no configure: WARNING: you cannot build PDF versions of the R manuals checking for makeinfo... /usr/bin/makeinfo checking for unzip... /usr/bin/unzip checking for zip... /usr/bin/zip checking for gzip... /bin/gzip checking for firefox... no checking for mozilla... no checking for netscape... no checking for galeon... no checking for kfmclient... no checking for opera... no checking for gnome-moz-remote... no checking for open... /usr/bin/open using default browser ... /usr/bin/open checking for acroread... no checking for acroread4... no checking for xpdf... no checking for gv... no checking for gnome-gv... no checking for ggv... no checking for kghostview... no checking for open... /usr/bin/open checking for gcc... pgcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether pgcc accepts -g... yes checking for pgcc option to accept ANSI C... none needed checking how to run the C preprocessor... pgcc -E checking how to run the C preprocessor... pgcc -E defining F77 to be pgf77 checking whether we are using the GNU Fortran 77 compiler... no checking whether pgf77 accepts -g... yes checking whether we are using the GNU C++ compiler... no checking whether pgCC accepts -g... yes checking how to run the C++ preprocessor... pgCC -E checking whether __attribute__((visibility())) is supported... no checking whether pgcc accepts -fvisibility... yes checking whether pgf77 accepts -fvisibility... yes checking for a sed that does not truncate output... /bin/sed checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes
Re: [Rd] helping out
Kevin
The developers page is available from the left side menu frame on the
main R page http://www.r-project.org/ , but not from CRAN.
(BTW, R-devel does not have nearly as much traffic as R-help, so digest
mode may not be so important.)
Paul Gilbert
Kevin B. Hendricks wrote:
Hi,
I just joined the list and wanted to introduce myself. I am a
professor of operations management at a Canadian University and an
empirical researcher (using mainly archival data from finance and
accounting primarily with econometric methods). I have finally made
the leap to remove all of SAS from my machines (damn license code
nonsense was killing me) and decided to adopt R. So I am very new to
the R system and still just getting up to speed (reading the fine
*long* manuals and etc).
I am also an old programmer (read that late 1970s, early 1980s
timeframe) and more recently I have been an open source volunteer for
OpenOffice.org (ran their lingucomponent project until last year), a
volunteer for the Blackdown Java project (helped do the initial port
of Java 1.1.1 to PowerPC Linux) and I have submitted bug fixes and
patches to the Linux kernel, glibc, gcc, and the like, mainly to
support PPC Linux. I now primarily use x86_64 Linux and MacOSX. I
can program in C, C++, Fortran and a number of other languages.
So once I get up to speed, I would love to volunteer to help pay back
for the really nice system you have made available.
I found this mailing list by accident looking for something to tell
me about the NULL environment issue that hit me when I moved from
version 2.2.1 to version 2.3.0. If there is a developers page that
lists cvs checkout info (or do you use subversion or some other
system) and the details of who to submit all patches and things to
(is this list for diffs?), I would love to be pointed at it.
I am on too many mailing lists right now, so I signed up for digest
mode. So if anyone wants/needs an immediate response please simply
cc me.
Thanks,
Kevin Hendricks
Professor of Operations Management and Information Technology
Richard Ivey School of Business
University of Western Ontario
London, ON
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] PGI 6.1 compile error
I am trying to compile R-2.3.0 (both first release and patched
2006-05-10) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7)
using the Portland Group compiler version 6.1 and the notes from
Jennifer Lai on p33 of R Installation and Administration version 2.3.0
(2006-04-24). I have not used this compiler before, so it is possible
things are messed up more than usual, even for me.
Following the R Installation and Administration notes I set
export PGI=/usr/pgi/linux86-64/6.1
export PATH=$PGI/bin:$PATH
export MANPATH=$MANPATH=$PGI/man:/
export CC=pgcc
export CFLAGS=-g -O2 -Kieee
export CPPFLAGS=-I$PGI/include -I$PGI/include/CC
export F77=pgf77
export FFLAGS=-g -O2 -Kieee
export CXX=pgCC
export CXXFLAGS=-g -O2 -Kieee
export F95=pgf95
export FCFLAGS=-g -O2 -Kieee
export SHLIB_CXXLDFLAGS=-shared
export SHLIB_LDFLAGS=-shared
export LDFLAGS=-L$PGI/libso -L/usr/lib64
However, the last line causes
:../../src/R-2.3.0-patched/configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
loading site script '../../src/R-2.3.0-patched/config.site'
checking for gcc... pgcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Either unsetting LDFLAGS, or setting it to -L/usr/lib64
.../../src/R-2.3.0-patched/configure --x-libraries=/usr/X11R6/lib64
configures but I get
checking whether C99 double complex is supported...
checking complex.h usability... no
checking complex.h presence... yes
configure: WARNING: complex.h: present but cannot be compiled
configure: WARNING: complex.h: check for missing prerequisite headers?
configure: WARNING: complex.h: see the Autoconf documentation
configure: WARNING: complex.h: section Present But Cannot Be Compiled
configure: WARNING: complex.h: proceeding with the preprocessor's result
configure: WARNING: complex.h: in the future, the compiler will take
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
checking for complex.h... yes
checking for double complex... no
no
checking for cblas_cdotu_sub in vecLib framework... no
R is now configured for x86_64-unknown-linux-gnu
Source directory: ../../src/R-2.3.0-patched
Installation directory:/usr/local
C compiler:pgcc -g -O2 -Kieee
Fortran 77 compiler: pgf77 -g -O2 -Kieee
C++ compiler: pgCC -g -O2 -Kieee
Fortran 90/95 compiler:pgf95 -g -O2 -Kieee
Interfaces supported: X11, tcltk
External libraries:readline
Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
Options enabled: R profiling
Recommended packages: yes
configure: WARNING: you cannot build info or html versions of the R manuals
However, when I make I get
pgcc -shared -L/usr/lib64 -o tools.so text.o init.o Rmd5.o md5.o
mkdir -p -- ../../../../library/tools/libs
make[5]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools/src'
make[4]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools/src'
**ERROR: in routine alloca() there is a
stack overflow: thread 0, max 10228KB, used 0KB, request 16B
make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools'
make[2]: *** [R] Error 1
make[2]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library'
make[1]: *** [R] Error 1
make[1]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src'
make: *** [R] Error 1
Any help would be appreciated.
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] slot named C
C appears to be an illegal name for a slot in an S4 class (example
below). If this is a known limitation, and not a bug, it would be nice
if it were caught by setClass.
Paul Gilbert
setClass(testobj, representation ( C = numeric))
[1] testobj
new(testobj, C= 2)
Error in methodsPackageMetaName(C, name) :
'The name of the object (e.g,. a class or generic function) to
find in the meta-data' must be a single string (got an object of class
numeric)
setClass(testobj, representation ( C. = numeric))
[1] testobj
new(testobj, C.= 2)
An object of class testobj
Slot C.:
[1] 2
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slot named C
Ok, but I'm surprised. I thought partial matching only happened for
named arguments. I guess I've been lucky.
Paul
Prof Brian Ripley wrote:
It's an error in your usage The args of new() are
args(new)
function (Class, ...)
and what does 'C' match? You need to name your arguments here.
On Mon, 17 Apr 2006, Paul Gilbert wrote:
C appears to be an illegal name for a slot in an S4 class (example
below).
It is rather an example of something which does not work.
foo - new(testobj)
[EMAIL PROTECTED] - 2
does, for example.
If this is a known limitation, and not a bug, it would be nice
if it were caught by setClass.
Paul Gilbert
setClass(testobj, representation ( C = numeric))
[1] testobj
new(testobj, C= 2)
Error in methodsPackageMetaName(C, name) :
'The name of the object (e.g,. a class or generic function) to
find in the meta-data' must be a single string (got an object of class
numeric)
setClass(testobj, representation ( C. = numeric))
[1] testobj
new(testobj, C.= 2)
An object of class testobj
Slot C.:
[1] 2
La version française suit le texte anglais.
This email may contain privileged and/or confidential
inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slot named C
Prof Brian Ripley wrote:
On Mon, 17 Apr 2006, Paul Gilbert wrote:
Ok, but I'm surprised. I thought partial matching only happened for
named arguments. I guess I've been lucky.
Here C is named, so what did you mean?
Now I guess I've really been confused. I thought named arguments in a
function were the optional ones you named when you define the function
(with name=default, so Class is not a named argument in the call to
new). Are you saying the named arguments are the ones you name when you
call the function?
Paul
Partial matching happens for all arguments called by name, except for
those following ... in the formals.
Paul
Prof Brian Ripley wrote:
It's an error in your usage The args of new() are
args(new)
function (Class, ...)
and what does 'C' match? You need to name your arguments here.
On Mon, 17 Apr 2006, Paul Gilbert wrote:
C appears to be an illegal name for a slot in an S4 class (example
below).
It is rather an example of something which does not work.
foo - new(testobj)
[EMAIL PROTECTED] - 2
does, for example.
If this is a known limitation, and not a bug, it would be nice
if it were caught by setClass.
Paul Gilbert
setClass(testobj, representation ( C = numeric))
[1] testobj
new(testobj, C= 2)
Error in methodsPackageMetaName(C, name) :
'The name of the object (e.g,. a class or generic function) to
find in the meta-data' must be a single string (got an object of class
numeric)
setClass(testobj, representation ( C. = numeric))
[1] testobj
new(testobj, C.= 2)
An object of class testobj
Slot C.:
[1] 2
La version française suit le texte anglais.
This email may contain privileged and/or confidential
inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential
inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] xmkmf? problem
I am having the xmkmf problem below with todays beta, but I also am
trying to use an new (PGI 6.1), so lots of other things in my setup may
be wrong, and the warning may also be important. Any hints would be
appreciated.
Paul
_
Red Hat Enterprise Linux AS release 3 (Taroon Update 7)
checking whether C runtime needs -D__NO_MATH_INLINES... no
checking for xmkmf... /usr/X11R6/bin/xmkmf
Usage: which [options] [--] programname [...]
Options: --version, -[vV] Print version and exit successfully.
--help, Print this help and exit successfully.
--skip-dot Skip directories in PATH that start with a dot.
--skip-tilde Skip directories in PATH that start with a tilde.
--show-dot Don't expand a dot to current directory in output.
--show-tilde Output a tilde for HOME directory for non-root.
--tty-only Stop processing options on the right if not on
tty.
--all, -aPrint all matches in PATH, not just the first
--read-alias, -i Read list of aliases from stdin.
--skip-alias Ignore option --read-alias; don't read stdin.
--read-functions Read shell functions from stdin.
--skip-functions Ignore option --read-functions; don't read stdin.
Usage: which [options] [--] programname [...]
Options: --version, -[vV] Print version and exit successfully.
--help, Print this help and exit successfully.
--skip-dot Skip directories in PATH that start with a dot.
--skip-tilde Skip directories in PATH that start with a tilde.
--show-dot Don't expand a dot to current directory in output.
--show-tilde Output a tilde for HOME directory for non-root.
--tty-only Stop processing options on the right if not on
tty.
--all, -aPrint all matches in PATH, not just the first
--read-alias, -i Read list of aliases from stdin.
--skip-alias Ignore option --read-alias; don't read stdin.
--read-functions Read shell functions from stdin.
--skip-functions Ignore option --read-functions; don't read stdin.
configure: WARNING: I could not determine SHLIB_LDFLAGS.
configure: error: See the file doc/html/R-admin.html for more information.
~/toolchain/R/mfa04559/R-beta:
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package?pac
When I use
package?pac
the author field gets reproduced twice, once with the \author{ } string
and a secod time formatted.
Also, would it be possible to make package?pac find the overview
without the package being attached, or at least give a more informative
error message.
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bundle internal dependencies
Iago
What you are trying to do should work, but there are a couple of things
to watch out for. In the bundle DESCRIPTION Contains line be sure to
put the packages in the order that they should be checked. In the R
code for package B be sure to put an .onload function with
requires(A), or else require(A) explicitly for anything that needs
it. As I recall, this is not necessary for packages, if the package
DESCRIPTION has Depends: A, but with bundles R CMD check does not work
unless you explicitly do requires(A) in the code. It may also be
necessary to specify the package in the data() function - I always do.
I think that is all, but is has been awhile since I worked this out, so
I may have forgotten something.
Paul
Iago Mosqueira wrote:
Dear all,
When creating a bundle with some internal dependencies (package B in
bundle depends on package A), would having the same version installed
suffice? Can I ignore the dependencie in package B's description? The
test of package B fails when calling data() for an object in pacakge A,
so I am not sure right now whether the whole dependencie is not being
met or simple relates to data(). What is the best way of dealing with
this structure?
Many thanks,
Iago Mosqueira
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Peculiar timing result
Doug This is probably not your reason, but I am finding my dual core Athlon 64 is much slower running 64 bit Linux and R than it was running 32 bit Linux and R. All the programs are bigger. (Some, like the clock applet, are a lot bigger for no obvious reason.) The difference is enough to put my meager 1GB machine into swapping much more, with the result that it is a lot slower. Paul Douglas Bates wrote: I have been timing a particular model fit using lmer on several different computers and came up with a peculiar result - the model fit is considerably slower on a dual-core Athlon 64 using Goto's multithreaded BLAS than on a single-core processor. Here is the timing on a single-core Athlon 64 3000+ running under today's R-devel with version 0.995-5 of the Matrix package. library(Matrix) data(star, package = 'mlmRev') system.time(fm1 - lmer(math~gr+sx+eth+cltype+(yrs|id)+(1|tch)+(yrs|sch), star, control = list(nit=0,grad=0,msV=1))) 0 241720.: 1.16440 0.335239 0.0 1.78732 0.867209 0.382318 0.0 1 239722.: 1.94952 5.0e-10 0.00933767 1.65999 0.858003 0.341520 0.00908757 2 239580.: 1.95924 0.0884059 0.00933767 1.65308 0.857487 0.339296 0.00954718 3 239215.: 2.60877 0.0765848 0.0177699 1.45739 0.843562 0.275100 0.0236849 4 239204.: 2.62582 0.106670 0.0239698 1.41976 0.841086 0.261033 0.0267073 5 239176.: 2.63149 0.0787924 0.0367185 1.37952 0.838527 0.245076 0.0301134 6 239141.: 2.64949 0.108534 0.0594586 1.28846 0.832543 0.208404 0.0375456 7 239049.: 2.64794 0.0789214 0.121782 1.10436 0.819711 0.126101 0.0524965 8 239004.: 2.66044 0.117957 0.181505 0.932202 0.798982 0.0718116 0.0628958 9 238944.: 2.66310 0.0819653 0.334477 0.631735 0.740855 0.258359 0.0806590 10 238893.: 2.72626 0.0975205 0.653432 0.703912 0.666067 0.109922 0.201809 11 238892.: 2.74381 0.46 0.666155 0.693544 0.662000 0.104060 0.207591 12 23.: 2.75052 0.0990238 0.689199 0.694588 0.655781 0.106516 0.216460 13 238861.: 2.80325 0.126935 1.05912 0.733914 0.556162 0.159296 0.360938 14 238832.: 2.82656 0.117617 1.59471 0.607916 0.441371 0.0749944 0.976142 15 238811.: 2.87350 0.136332 1.59046 0.653141 0.353763 0.226061 1.79285 16 238810.: 2.87663 0.125135 1.58992 0.656808 0.352605 0.220488 1.79282 17 238806.: 2.89342 0.141551 1.58607 0.676523 0.344212 0.181833 1.79268 18 238804.: 2.90080 0.125137 1.56624 0.682921 0.261295 0.180598 1.74325 19 238802.: 2.91950 0.128569 1.56836 0.680436 0.336051 0.159940 1.80400 20 238801.: 2.92795 0.134762 1.56597 0.685121 0.331695 0.145547 1.80414 21 238801.: 2.93741 0.125667 1.56139 0.687827 0.332700 0.138854 1.81495 22 238800.: 2.94588 0.131757 1.55294 0.687909 0.330414 0.137834 1.82826 23 238799.: 2.96867 0.129716 1.52943 0.688678 0.323171 0.139912 1.84615 24 238799.: 2.98994 0.133378 1.52188 0.700038 0.337387 0.131403 1.77623 25 238799.: 3.00312 0.135308 1.51475 0.697550 0.311750 0.145683 1.78037 26 238799.: 3.00461 0.129920 1.51083 0.697666 0.306722 0.138745 1.81188 27 238799.: 3.00504 0.134882 1.50539 0.696745 0.302949 0.135897 1.84405 28 238799.: 3.00422 0.134013 1.47947 0.698115 0.303243 0.133806 1.86486 29 238799.: 3.00819 0.134378 1.48185 0.701871 0.307097 0.134637 1.84996 30 238799.: 3.01313 0.134279 1.49098 0.702883 0.304788 0.133682 1.86254 31 238799.: 3.01291 0.134253 1.49060 0.701818 0.303155 0.133771 1.84613 32 238799.: 3.01142 0.134314 1.48921 0.701782 0.303589 0.134439 1.84653 33 238799.: 3.01174 0.134315 1.48926 0.701641 0.304120 0.134145 1.84635 34 238799.: 3.01175 0.134304 1.48942 0.701740 0.303762 0.134185 1.84649 35 238799.: 3.01173 0.134307 1.48937 0.701724 0.303809 0.134206 1.84647 [1] 43.10 3.78 48.41 0.00 0.00 (If you run the timing yourself and don't want to see the iteration output, take the msV=1 out of the control list. I keep it in there so I can monitor the progress.) If I time the same model fit on a dual-core Athlon 64 X2 3800+ with the same version of R, BLAS and Matrix package, the timing ends up with something like 90 140 235 0 0 I do see that the multithreading is working on a calculation that is essentially BLAS-bound such as mm - Matrix(rnorm(1e6), nc = 1e3) system.time(crossprod(mm)) [1] 0.57 0.02 0.60 0.00 0.00 On the X2 processor it still takes about 0.6 seconds user time but only 0.3 seconds elapsed time when the machine is otherwise idle and both cores are available for the calculation. Any suggestions why the dual-core processor is so much slower than the single core processor? By the way, I would be interested in accumulating timings of this model fit on other systems. If you do time it please send me (off-list) a summary of the version of R, version
[Rd] package introductions
I have been experimenting with different possibilities for an
introduction page for my packages. That is, a good place to tell users
about the most important things in a package, and where to start.
Recently there was a discussion about this, and a suggestion to use
foo-package.Rd, and also a function that generates a skeleton
document. My problem with this suggestion is that foo-package may not
be high in the sort order, so users will not find this unless they know
to look for it (and so there is difficulty establishing the convention).
A second problem is that the skeleton document has information that may
be useful, but is not really what I am looking for. (It has all the
methods in the package, but what I want is to tell users the most
important ones to look at first. It also has high maintenance
information, like version numbers. I want something that is either
completely automatic, or manual but low maintenance.) Another related
problem is that the information put in the skeleton foo-package.Rd
possibly should be in a man page somewhere, so if this does happen, that
naming convention will likely be used and would then conflict with my
introduction.
I now think I have found something that works fairly well. I put the
introduction in a file 00.foo.Intro.Rd and in that file have
/name{00.foo.Intro}
/alias{00.foo.Intro}
/alias{foo.Intro}
Then sorting puts the 00 version at the beginning of the table of
contents in both the pdf version with all the help pages, and in the
html version for the help.start() system. Also, ?foo.Intro works.
(?00.foo.Intro works too, but the quote marks are necessary and this
seems likely to cause problems for beginners.)
It is also helpful to put something like See ?foo.Intro for more
details in the Description: line of the DESCRIPTION file, so users
see this with help(package=foo). (I don't think users of the
help.start() system ever see this, but perhaps someone can correct me.)
I also would like to put in my vote for a DESCRIPTION file tag
GettingStarted: foo.Intro
probably as an optional tag to begin.
Of course, the biggest simplification happens when things like this are
done in a similar way by everyone. ( configure ; make is not
intuitively simple, but everyone now knows the incantation.)
Paul Gilbert
La version française suit le texte anglais.
This email message from the Bank of Canada is given in good faith, and shall
not be
binding or construed as constituting any obligation on the part of the Bank.
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
Recipients are advised to apply their own virus checks to this message upon
receipt.
L'information communiquée dans les courriels en provenance de la Banque du
Canada
est soumise de bonne foi, mais elle ne saurait lier la Banque et ne doit
aucunement
être interprétée comme constituant une obligation de sa part.
Le présent courriel peut contenir de l'information privilégiée ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite Si vous
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
votre
ordinateur toute copie du courriel reçu.
Dès la réception du présent message, le ou les destinataires doivent activer
leur
programme de détection de virus pour éviter toute contamination possible.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in factanal.Rd
In the file factanal.Rd the line
then the first fit is started at the value suggested by J\ureskog
should be
then the first fit is started at the value suggested by
\enc{J\ureskog}{Joreskog}
or whatever that translates to on a system that does not mangle cut and
paste of special characters.
Paul
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] ouml in an .Rd
(moved from r-help)
Ok, UTF-8 works on some of my machines and latin1 on others. If I use
one I get failure or spurious characters when I build on the wrong
machine. Are .Rd files suppose to work on different platforms when there
are special characters, or is this a known limitation?
Paul
Prof Brian Ripley wrote:
It means what it says: you need to put the actual character in the file,
and specify the encoding for the file via \encoding. (For you, UTF-8 or
latin1, I would guess.)
It's not a question of trying variations, rather of following instructions.
On Fri, 6 Jan 2006, Paul Gilbert wrote:
I am trying to put an ouml in an .Rd file with no success. Writing R
Extensions suggests:
Text which might need to be represented differently in different
encodings should be marked by |\enc|, e.g. |\enc{Jöreskog}{Joreskog}|
where the first argument will be used where encodings are allowed and
the second should be ASCII (and is used for e.g. the text conversion).
(Above may get mangled by the mail.) I have tried variations
\enc{Joreskog}{Joreskog}
\enc{J\oreskog}{Joreskog}
\enc{Jo\reskog}{Joreskog}
\enc{Jo\reskog}{Joreskog}
\enc{J\{o}reskog}{Joreskog}
\enc{J\\{o}reskog}{Joreskog}
\enc{Jouml;oreskog}{Joreskog}
all with no effect on the generated pdf file. Suggestions would be
appreciated.
Thanks,
Paul Gilbert
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal to make loadings() generic in R-devel
I propose that loadings() be made generic in R-devel with definition loadings - function(x, ...) UseMethod(loadings) loadings.default - function(x, ...) x$loadings The default is the current definition of loadings with the ... argument added. The current definition is not specific about the returned value, though $loadings may usually be a matrix. I'm not sure what would be broken if a more strict definition of the return value is enforced. For my purposes a matrix is fine, but I am not sure that there is a benefit from imposing that the returned value must be a matrix, so I suggest sticking with the current non-specific structure for the return value. (For piecewise linear or other non-linear analysis there may be good reasons to allow more general structures for the loadings.) Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking S3 generic/method consistency
Kurt Ok, but I'm still confused about what as seen from the package means. I'm especially confused because at first in my testing (on Linux) a method (in a package not in dse but using dse1) was being compared against the stats generic, so I put in a work around. Then I discovered in Solaris the comparison was made against the generic in dse1. And now, after some further ongoing development I find that in some of my packages in Linux it is compared against the dse1 generic, and I can't see what is different between the ones compared with dse1 and the ones compared with stats. This is all with the released version of R-2.2.0. I can't figure out what changes this, but I'm not even sure where to start looking. Is the package's view determined by its NAMESPACE, Depends in the DESCRIPTION file, or if there is requires() in the .onLoad will that override? This is all with a fairly clean test environment. What happens when other packages are attached? Where/how does it break when there are other packages attached that need conflicting generics (or can that actually work)? Thanks, Paul Kurt Hornik wrote: Paul Gilbert writes: In R-2.2.0, how does checking S3 generic/method consistency determine which generic to check against when there are two? I have a generic simulate in dse1 and there is a new generic simulate in stats, and I don't seem to be able to get my simulate methods to be checked consistently against one or the other. Is this deteremined by Depends in the DESCRIPTION file, the NAMESPACE, or something else? It is attempted to use the generic as seen from the package. Actually, I made a code change to get things right for dse ... -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
Uwe Ligges wrote:
Dean, David P wrote:
Dear list,
I've just installed R-2.2.0 under Solaris and have a question about
installing packages. If a package fails to install for any reason and I go
to install another package, I get this message:
$ R-2.2.0-64bit --vanilla CMD INSTALL ~/srca/cran/RSQLite_0.4-0.tar.gz
ERROR: failed to lock directory
'/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
I can remove the lock directory by hand, and then the next package installs,
but this makes it quite difficult to download and install a batch of
packages from CRAN or Biocondctor! Is this lock directory a new feature with
R-2.2.0? Is there a work around in the R build itself or the installation
scripts?
No, not a new feature in R-2.2.0, it has been there for some time now.
I have the impression the feature behaves slightly differently as of
R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
unsuccessful install. (In Linux I think it does get removed.)
Paul Gilbert
After a *successful* installation, the 00LOCK directory should be
deleted by the installation tools themselves.
After an unsuccessful installation, the installation tools should
restore the stuff in the 00LOCK directory.
Do you abort the installtion manually (this is the only way I figured
out how not to remove 00LOCK automatically)?
Uwe Ligges
Much thanks!!!
-
David P Dean
Research Informatics
PGRD Groton Labs
(860)-441-5053
[EMAIL PROTECTED]
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
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] automatically adding smooth to plot: options(plot.add.smooth)
Duncan Murdoch wrote: On 9/19/2005 10:01 AM, Paul Gilbert wrote: Martin Maechler wrote: I've changed the subject in the hope some more people would voice an opinion... ... Now I even propose to have options(add.smooth = TRUE) as a new default. Do I get a reaction now? Martin I think you may break a lot of things if you make this the default for plot. Plot gets used by other things (like matplot) where this default may not make much sense. (But I may have missed too much of the earlier discussion under some other subject.) This was going to affect only plot.lm, as far as I know. From the earlier discussion I thought so, but it was not really clear in the new subject line. Paul Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] simulate in stats
BTW, I think there is a problem with the way the argument seed is used
in the new simulate in stats. The problem is that repeated calls to
simulate using the default argument will introduce a new pattern into
the RNG:
stats:::simulate
function (object, nsim = 1, seed = as.integer(runif(1, 0,
.Machine$integer.max)), ...)
UseMethod(simulate)
environment: namespace:stats
stats:::simulate.lm
function (object, nsim = 1, seed = as.integer(runif(1, 0,
.Machine$integer.max)),...)
{
if (!exists(.Random.seed, envir = .GlobalEnv))
runif(1)
RNGstate - .Random.seed
set.seed(seed)
...
This should not be done, as the resulting RNG has not been studied or
proven. A better mechanism is to have a default argument equal NULL,
and not touch the seed in that case. There are several examples of this
in the package dse1 (in bundle dse), see for example simulate.ARMA and
simulate.SS. They also use the utilities in the setRNG package to save
more of the information necessary to reproduce simulations. Roughly it
is done like this:
simulate.x - function (model, rng = NULL, ...)
{if (is.null(rng)) rng - setRNG() #returns the RNG setting to be
saved with the result
else {
old.rng - setRNG(rng)
on.exit(setRNG(old.rng))
}
...
The seed by itself is not very useful if the purpose is to be able to
reproduce things, and I think it would be a good idea to incorporate the
few small functions setRNG into stats (especially if the simulate
mechanism is being introduced).
The argument nsim presumably alleviates to some extent the above
concern about changing the RNG pattern. However, in my fairly extensive
experience it is not very workable to produce all the simulations and
then do the analysis of them. In a Monte Carlo experiment the generated
data set is just too big. A better approach is to do the analysis and
save only necessary information after each simulation. That is the
approach, for example, in dse2:::EstEval.
Paul
Paul Gilbert wrote:
Can the arguments nsim and seed be passed as part of ... in the new
simulate generic in R-2.2.0alpha package stats?
This would potentially allow me to use the stats generic rather than
the one I define in dse. There are contexts where nsim and seed do not
make sense. I realize that the default arguments could be ignored, but
it does not really make sense to introduce a new generic with that in
mind. (I would also prefer that the object argument was called
model but this is less important.)
Paul Gilbert
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] loadings() generic in R alpha
Could loadings() in R-2.2.0 please be made generic? Thanks, Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] acf() generic in R alpha
Could acf() in R-2.2.0 please be made generic? Thanks, Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] simulate in stats
(Sorry if this was posted twice. I seem to be having some email issues.) Can the arguments nsim and seed be passed as part of ... in the new simulate generic in R-2.2.0alpha package stats? This would potentially allow me to use the stats generic rather than the one I define in dse. There are contexts where nsim and seed do not make sense. I realize that the default arguments could be ignored, but it does not really make sense to introduce a new generic with that in mind. (I would also prefer that the object argument was called model but this is less important.) Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
