Re: [Rd] S4 coercion
Hi,
I am having a similar issue as reported by Paul, but I don't think Martin's
example is precisely representative of the problem.
Consider a hierarchy A <- B <- C:
> setClass("A")
[1] "A"
> setClass("B", contains="A")
[1] "B"
> setClass("C", contains="B")
[1] "C"
Now define a coerce method:
> setAs("A", "list", function(from) list())
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
Coercing an instance "B" to a list works fine:
> as(new("B"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="B", to="list"
(inherited from: from="A", to="list")
But note the coerce method has now been cached. It seems though that a
cached "inherited" B->list coerce method is given equal priority to the
original A->list coerce method during method selection for coercing C->list:
> as(new("C"), "list")
list()
Warning message:
Ambiguous method selection for "coerce", target "C#list" (the first of the
signatures shown will be used)
B#list
A#list
And so we have an ambiguity. Is this by design? Note that coercing (and thus
caching) C->list first, avoids this problem:
> setAs("A", "list", function(from) list())
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
> as(new("C"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="C", to="list"
(inherited from: from="A", to="list")
> as(new("B"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="B", to="list"
(inherited from: from="A", to="list")
from="C", to="list"
(inherited from: from="A", to="list")
> as(new("C"), "list")
list()
Thanks,
Michael
On Wed, Aug 27, 2008 at 7:46 AM, Martin Morgan <[EMAIL PROTECTED]> wrote:
> Hi Paul -- does this make the problem more explicit?
>
> > ## class hierarchy
> > setClass("A", representation=representation(a="numeric"))
> [1] "A"
> > setClass("B", representation=representation(b="numeric"))
> [1] "B"
> > setClass("C", contains=c("A", "B"))
> [1] "C"
>
> > ## coerce methods -- in some instances implicitly created
> > setAs("A", "numeric", function(from) slot(from, "a"))
> > setAs("B", "numeric", function(from) slot(from, "b"))
>
> > ## trouble: C equidistant from A, B so no unambiguous nearest 'coerce'
> > ## method
> > as(new("C"), "numeric")
> numeric(0)
> Warning message:
> Ambiguous method selection for "coerce", target "C#numeric" (the first
> of the signatures shown will be used)
> A#numeric
>B#numeric
>
> The solution is to define a method to resolve the conflict, e.g.,
>
> setAs("C", "numeric", function(from) {
>## avoid breaking the class abstraction
>as(as(from, "A"), "numeric") *
>as(as(from, "B"), "numeric")
> })
>
> I don't know how you want to break your particular tie; that has to do
> with the classes you're extending.
>
> Martin
>
> Paul Gilbert <[EMAIL PROTECTED]> writes:
>
> > I am extending a DBI connection by
> >
> > setClass("TSPostgreSQLConnection",
> > contains=c("PostgreSQLConnection","TSdbOptions"))
> >
> > but the first time I use this I am getting a warning when it tries to
> > coerce the TSPostgreSQLConnection to a PostgreSQLConnection. After
> > the first use the warning stops, but the first warning is causing me
> > problems when I do automatic checks and set my tests to stop on
> > warnings. (I think there should be a correct way to do this that does
> > not produce a warning.) I can trace it back by setting
> > options(warn=2) as below. Do I need to be more specific about how the
> > coercion happens? If so, what is the correct way to coerce the
> > TSPostgreSQLConnection into a PostgreSQLConnection? If not, how to a
> > get rid of the warning?
> >
> > Paul Gilbert
> >
> >
> > > TSdelete("vec", con)
> > Error: (converted from warning) Ambiguous method selection for
> > "coerce", target "TSPostgreSQLConnection#integer" (the first of the
> > signatures shown will be used)
> >PostgreSQLConnection#integer
> >dbObjectId#integer
> > > traceback()
> > 15: doWithOneRestart(return(expr), restart)
> > 14: withOneRestart(expr, restarts[[1]])
> > 13: withRestarts({
> >.Internal(.signalCondition(simpleWarning(msg, call), msg,
> >call))
> >.Internal(.dfltWarn(msg, call))
> >}, muffleWarning = function() NULL)
> > 12: .signalSimpleWarning("Ambiguous method selection for \"coerce\",
> > target \"TSPostgreSQLConnection#integer\" (the first of the signatures
> > shown will be used)\nPostgreSQLConnection#integer\n
> > dbObjectId#integer\n",
> >quote(NULL))
> > 11: warning(gettextf(paste("Ambiguous method selection for \"%s\",
> > target \"%s\"",
> >"(the first of the signatures shown will be used)\n%s\n"),
> >
Re: [Rd] Checking your package's help files
The check summaries now available at
http://cran.r-project.org/web/checks/check_summary.html
will indicate most of the problems being detected in CRAN packages: look
at the log (click on the link) for your package in the first or second
column.
On Sun, 7 Dec 2008, Prof Brian Ripley wrote:
It seems that many package authors do not proofread the help installed with
their packages. The Rd converter is not a parser, and it will silently
produce incorrect results on incorrect input (and some correct input).
Here are a few hints about some common errors:
1) When you run R CMD check you get a PDF manual at
.Rcheck/-manual.pdf. Read through it looking for missing/empty and
mis-formatted entries.
2) Try installing the package under a current R-devel (as of today). This
will report on errors of the form
\item{foo} {item text}
with, NB, invalid space between the two arguments. Earlier versions of R
assume that the item had no text and so '{item text}' is never processed (not
even checked for validity). This results in at best missing information and
at worse nonsense.
3) Grep the installed help for internal constructs, e.g.
grep normal-bracket /help/*
Three ways I have found such constructs to appear in the processed files:
a) If you see 'eqnnormal-bracket' then you have a one-argument \eqn (or
possibly \deqn) command immediately followed by }. This is correct Rd but
mis-processed in earlier versions of R. In all the cases I have seen it
comes from grammatically incorrect help files of the form
\item{foo}{... \eqn{x}}
where the item should end in ',' or '.'. But if you don't want to do that,
at least use a space before the brace. I found this in packages
distrMod, flexclust, geepack, geoR, psychometric, robustbase and uroot.
b) Many packages have help files with 'normal-bracket' at the end of a
processed \value section. In all the cases I looked at, this results from
using \itemize{} inside \value -- that does not work as \value is implicitly
an itemize environment.
c) Using markup in verbatim-like environments will lead to nonsensical
output: it seems the most common error is to use \code inside \examples. What
markup is allowed where is not very well defined: Duncan Murdoch has started
to document this at http://developer.r-project.org/parseRd.pdf but that
currently is more a description of what should happen, not what has been
implemented.
These issues are not rare (except 3a): about 10% of CRAN packages have them.
--
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
--
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] enhancement proposals to R
Hello, I am not aware of any facility for users to submit proposals for R enhancements. Something along the lines Phython has: http://www.python.org/dev/peps/ It would also be interesting to have a way for people to vote on the proposals in order to get a feeling for the importance of the additions from the point of view of the user. R-core could then gauge better the useRs current needs. For a major project that would require significant resources, maybe some work can be outsourced to other developers if R-core is too busy or if the supporters are willing to sponsor the project financially. One such large project would be to add multi-threading capabilities into R. What do you think? Adrian Dragulescu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package development
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a product, but I can't find anything on how
to set up a reasonable DEVELOPMENT environment.
In my local world, I had the .c and .s files in a common directory, with
a Makefile that I had created, and the test suite in a subdirectory. Debugging
and development was quite nice.
make
cd test
R
attach("..")
try something and perhaps it fails
q()
cd ..
Fix and repeat. The Makefile took some time to create, but paid for itself a
hundred times over.
So, I've now rearranged everything into standard R order. Then I did the
only thing I could find
R CMD INSTALL ~/myRlib survival
where "survival" is said directory. This turns out to be not useful at all.
The survival package is large, and I rather suspected that I would goof
something up, and I did, resulting in the following message
Error in parse(n = -1, file = file) : unexpected end of input at
14450: }
14451:
It is not exactly obvious which of the 132 files in my R/ directory is the
culprit here.
In general:
1. The library is large, and recompiling/reparsing everything is very far from
instantaneous. It is not the edit/load cycle I desire.
2. I take testing seriously: the test suite takes on the order of 15 minutes to
run on a fast machine. I most certainly don't want to run it in the mid cycle.
Someone must have tackled this. I'm hoping that there is some documentation
that I have managed to overlook which discussess a good setup for this middle
ground between concieving of a library and packaging it for delivery; the
"build, test, make sure it acually works" part of development.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Dear Terry,
One way to locate which file is wrong - surely not the most brillant
way! You could do an R script that sources each of your .R files within
a "for (file in file.names)" loop.
When R will stop, it will indicate which file has a wrong syntax and
more info.
Cheers,
Mathieu
Terry Therneau a écrit :
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a product, but I can't find anything on how
to set up a reasonable DEVELOPMENT environment.
In my local world, I had the .c and .s files in a common directory, with
a Makefile that I had created, and the test suite in a subdirectory. Debugging
and development was quite nice.
make
cd test
R
attach("..")
try something and perhaps it fails
q()
cd ..
Fix and repeat. The Makefile took some time to create, but paid for itself a
hundred times over.
So, I've now rearranged everything into standard R order. Then I did the
only thing I could find
R CMD INSTALL ~/myRlib survival
where "survival" is said directory. This turns out to be not useful at all.
The survival package is large, and I rather suspected that I would goof
something up, and I did, resulting in the following message
Error in parse(n = -1, file = file) : unexpected end of input at
14450: }
14451:
It is not exactly obvious which of the 132 files in my R/ directory is the
culprit here.
In general:
1. The library is large, and recompiling/reparsing everything is very far from
instantaneous. It is not the edit/load cycle I desire.
2. I take testing seriously: the test suite takes on the order of 15 minutes to
run on a fast machine. I most certainly don't want to run it in the mid cycle.
Someone must have tackled this. I'm hoping that there is some documentation
that I have managed to overlook which discussess a good setup for this middle
ground between concieving of a library and packaging it for delivery; the
"build, test, make sure it acually works" part of development.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Hi Terry
I suspect many people struggle with similar issues.
The new version of mvbutils contains a number of routines that facilitate
creation & maintenance of a package, hopefully through its entire life-cycle:
from "documenting your own stuff for personal use", through "giving out
semi-documented code that your mates can use", through "getting it through all
the CRAN hoops", through "maintaining & changing an
already-installed-and-loaded package".
There is support for creating & editing functions (etc) in your own
"development" package while it's already loaded, plus speedy on-the-fly
updating of the installed version of the package. These in particular are
things that R does not make easy by default (probably for good reasons). Plus:
you don't have to learn Rd format if you don't want to-- the package-creator in
mvbutils will generate Rd documentation for you based on plain-text
documentation.
Use of these package-creation-maintenance routines does require some level of
buy-in to 'mvbutils's view of how your working life in R should be organized...
basically 'cd' and 'fixr'. I don't reckon this should be much of a drama for
most people, but there are so many different ways of working in R, so who knows?
I use these routines perpetually (maintaining about 6 packages), but as far as
the rest of the universe goes, they are still alpha-releases. They are geared
to the way I work, and so as yet might not do what others want; however, if
there's demand and feasibility, I'm happy to try to incorporate other features.
In particular, the documentation is incomplete at present, and I therefore
haven't over-advertised the package-maintenance stuff until I get time to write
a "how-to" article.
[I've had to release the package-maintenance stuff in a slightly undercooked
state, because it is intimately bound to the guts of mvbutils, and it became
necessary to roll out a maintenance release of mvbutils for other reasons.]
Let me know if this might be of further interest to you
Mark
--
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
Terry Therneau wrote:
> I'm making the move of the survival package from my own environment
> to,
> and have stumbled into a vacuum. The R Extensions manual has really
> nice instructions about how to lay out the directories, order the
> files, and
> run tests for DISTRIBUTION of a product, but I can't find anything on
> how
> to set up a reasonable DEVELOPMENT environment.
>In my local world, I had the .c and .s files in a common
> directory, with
> a Makefile that I had created, and the test suite in a subdirectory.
> Debugging and development was quite nice.
> make
> cd test
> R
> attach("..")
> try something and perhaps it fails
> q()
> cd ..
> Fix and repeat. The Makefile took some time to create, but paid for
> itself a hundred times over.
>
> So, I've now rearranged everything into standard R order. Then I
> did the only thing I could find
> R CMD INSTALL ~/myRlib survival
> where "survival" is said directory. This turns out to be not useful
> at all. The survival package is large, and I rather suspected that I
> would goof something up, and I did, resulting in the following message
>
> Error in parse(n = -1, file = file) : unexpected end of input at
> 14450: }
> 14451:
>
> It is not exactly obvious which of the 132 files in my R/ directory
> is the culprit here.
>
>In general:
> 1. The library is large, and recompiling/reparsing everything is very
> far from instantaneous. It is not the edit/load cycle I desire.
>
> 2. I take testing seriously: the test suite takes on the order of 15
> minutes to run on a fast machine. I most certainly don't want to run
> it in the mid cycle.
>
>Someone must have tackled this. I'm hoping that there is some
> documentation that I have managed to overlook which discussess a good
> setup for this middle ground between concieving of a library and
> packaging it for delivery; the "build, test, make sure it acually
> works" part of development.
>
> Terry Therneau
>
> __
> 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] package development
On 11/12/2008 6:04 PM, Terry Therneau wrote:
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a product, but I can't find anything on how
to set up a reasonable DEVELOPMENT environment.
In my local world, I had the .c and .s files in a common directory, with
a Makefile that I had created, and the test suite in a subdirectory. Debugging
and development was quite nice.
make
cd test
R
attach("..")
try something and perhaps it fails
q()
cd ..
Fix and repeat. The Makefile took some time to create, but paid for itself a
hundred times over.
So, I've now rearranged everything into standard R order. Then I did the
only thing I could find
R CMD INSTALL ~/myRlib survival
where "survival" is said directory. This turns out to be not useful at all.
The survival package is large, and I rather suspected that I would goof
something up, and I did, resulting in the following message
Error in parse(n = -1, file = file) : unexpected end of input at
14450: }
14451:
It is not exactly obvious which of the 132 files in my R/ directory is the
culprit here.
That's something I would like to fix too. There are (at least) two
possible ways: stop concatenating the files (which is not really needed
nowadays, most packages install saved images), or add some markup to the
concatenated file so that the parser can report on the original filename
and line number (like the #LINE directives output by the C preprocessor).
In general:
1. The library is large, and recompiling/reparsing everything is very far from
instantaneous. It is not the edit/load cycle I desire.
If you install from the directory, the compiling should only be done
once (unless you change a file, of course). (The alternative is
installing from the tarball, which is recommended for later stages of
testing before distribution, because it's possible something could go
wrong in building the tarball. But it won't include any object files,
so you'll recompile every time.)
You can also use option "--docs=none" to skip building the help system;
this will save a bit of time.
2. I take testing seriously: the test suite takes on the order of 15 minutes to
run on a fast machine. I most certainly don't want to run it in the mid cycle.
I don't quite follow this. If you want to run all your tests, you would
use R CMD check. If you only want to run some of them, then you can
source things out of the tests directory while running interactively.
Someone must have tackled this. I'm hoping that there is some documentation
that I have managed to overlook which discussess a good setup for this middle
ground between concieving of a library and packaging it for delivery; the
"build, test, make sure it acually works" part of development.
I find the process I follow is to organize the files in the distribution
structure from the beginning. When adding new functions, I'll
generally use source() a few times to get the syntax right, and perhaps
run simple tests. (But remember, if you use a NAMESPACE, the functions
may not behave the same when they're sourced into the global
environment.) In the early stages, I'll do a lot of installs of the
packages.
If I was porting a big package and wanted to find syntax errors, to work
around the not-very-helpful error message you saw I'd do something like
for (f in list.files("pkg/R", full=TRUE)) source(f)
which will report the error more informatively.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
