Re: [Rd] changes in recent R-devel revisions?
Martin and Professor Ripley,
Thank you very much for your attention and time on this.
I've fixed the package accordingly.
benilton
On 2 March 2011 06:39, Prof Brian Ripley wrote:
> 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
Re: [Rd] Small enhancement for CMD check
On Mon, 28 Feb 2011, Prof Brian Ripley wrote: Unfortunately it would need a major rewrite, and either piping output through a pager (surely the standard Unix way to handle this) or redirecting to a file is the simplest way to do this. R CMD check calls a process to run .runPackageTestsR, which calls further processes to run each test and diff the results. We could simply capture stdout/stderr of .runPackageTestsR, but then one would have to wait until all the tests had run before seeing any output, which may mean waiting hours -- that was decided to be too undesirable. I've implemented in R-devel something that copies the output on a per-test basis to 00check.log. It may not be perfect (in particular if a test crashes its R process badly enough), but it will at least record a test-by-test summary of success/failure. On Fri, 25 Feb 2011, Terry Therneau wrote: It would be nice if the 00check.log file also included this part of the output: Running ‘bladder.R’ Comparing ‘bladder.Rout’ to ‘bladder.Rout.save’ ... OK Running ‘book1.R’ Comparing ‘book1.Rout’ to ‘book1.Rout.save’ ... OK Running ‘book2.R’ Comparing ‘book2.Rout’ to ‘book2.Rout.save’ ... OK etc. The survival package has enough test scripts that it exceeds my terminal's scroll bar; I have to either watch closely or run R CMD check survival >& mylog The most prolix are survival portfoliomatlab kappalab spatstat 6836323028 BBHSAUR2fields pcalg aster 2622222221 The remedy seems to be to group the tests into larger units. Terry Therneau -- 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, UKFax: +44 1865 272595 -- 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, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.rename(): Guaranteed to be complete or not at all?
Thank you very much for these pointers. In order to lower the risk for proceeding unknowingly with (3) or (4), I'll keep my post-rename tests for them (understanding that it is still not bullet proof). /Henrik On Tue, Mar 1, 2011 at 11:01 PM, Prof Brian Ripley wrote: > As the help says: > > This is subject to the limitations of the OS's corresponding system > call: > > E.g. on Fedora 14 'man 2 rename' says, inter alia, > > 'If newpath already exists it will be atomically replaced (subject to a few > conditions; see ERRORS below), so that there is no point at which another > process attempting to access newpath will find it missing. > > However, when overwriting there will probably be a window in which both > oldpath and newpath refer to the file being renamed. > > BUGS > > On NFS file systems, you can not assume that if the operation failed the > file was not renamed.' > > and for Windows see > > http://msdn.microsoft.com/en-us/library/aa365240%28v=vs.85%29.aspx > > where R uses flags (MOVEFILE_REPLACE_EXISTING | MOVEFILE_COPY_ALLOWED | > MOVEFILE_WRITE_THROUGH) > > Windows 95 was an example of an OS which could delete the 'to' file and fail > to move 'from'. > > On Tue, 1 Mar 2011, Henrik Bengtsson wrote: > >> Hi, >> >> assume I have an existing file 'pathname' and I want to rename it to >> 'pathnameN' (which does not exist). I use: >> >> res <- file.rename(pathname, pathnameN); >> >> Is it guaranteed that: >> >> (1) if res == TRUE, the file now have name 'pathnameN' and there is no >> file with name 'pathname'? >> (2) if res == FALSE, nothing has changed? >> >> or could it theoretically also be the case that >> >> (3) there are say two identical files named 'pathname' and 'pathnameN', >> (4) or worse, that neither exists? >> >> I can see how (3) could happen if the file is renamed by first using >> file.copy() and then file.remove() while there is lack of write/delete >> permission for the latter. >> >> Currently, my code asserts that (3) and (4) did not happen. Is that >> unnecessary - does file.rename() do that for me (regardless of OS)? >> >> Thanks >> >> Henrik >> >> __ >> 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
