On Tue, 1 Mar 2011, Martin Morgan wrote:
On 03/01/2011 03:19 PM, Benilton Carvalho wrote:
Hi,
I have a BioC infra-structure package that works fine (I can build,
check and load it successfully) on revision r53950. The very same
package fails on r54591 with the error below:
Error in loadNamespace(package, c(which.lib.loc, lib.loc), keep.source
= keep.source) :
cyclic name space dependency detected when loading ‘oligoClasses’,
already loading ‘oligoClasses’
I don't see anything obvious in the name space that would indicate
cyclic dependency and I wonder:
The message is slightly misleading, which is why I added the
additional information (in r54520, so this came in a litte before
that) about what is being loaded. 'oligoClasses' is loading itself
(which would be seen as a cycle on a graph). I first saw it on a CRAN
package which was loading oligoClasses via several other packages and
it was not at all clear which namespaces were involved.
For what it's worth, saying
trace(stop, recover)
prior to library(oligoClasses) leads to
7: loadNamespace(package, c(which.lib.loc, lib.loc), keep.source =
keep.source
8: methods:::cacheMetaData(ns, TRUE, ns)
9: getGeneric(f, FALSE, searchWhere, fpkg)
10: tryCatch(loadNamespace(package), error = function(e) e)
where 'package' is oligoClasses in lines 7 and 10, and the 'f' in 9 is
'relocateObject'. Line 10 is evaluated when methods:::.getGeneric
returns NULL.
In oligoClasses we have
oligoClasses/R> grep relocateObject *
AllGenerics.R:setGeneric("relocateObject", function(object, ...)
standardGeneric("relocateObject"))
methods-CNSet.R:relocateObject <- function(object, to){
which I guess is not as intended.
My guess is that setGeneric adds the generic to a cache of some sort
when the name space is created, but doesn't remove it when the generic
is overwritten by a plain function.
No idea why this shows up in the current R revision.
r54487 has caused some other changes in behaviour: I think the
oligoClasses problem appeared about that time.
Martin
a) if there were changes that were meant to affect this;
b) what is the recommended strategy to solve this issue.
Thank you very much for any suggestion,
benilton
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
