On 8/30/2006 1:35 PM, John Chambers wrote:
> Henrik Bengtsson wrote:
>> [Cross-posting to BioC-devel to]
>>
>> Thank you for this.
>>
>>> The changes are internal but extensive. All packages that use S4
>>> methods and classes need to be reinstalled from source to use the new
>>> version.
>>
>> Is there an easy way to detect if a package is using S4 or not?
>
> If you have your package source in various directories under a single
> directory (which is how I usually work), then, from the directory above
> the package directories, the comand:
> grep "Depends:.*methods" */DESCRIPTION
> will pick up the packages that declare a dependency on methods. There
> may be cleaner techniques.
This does the same within R:
> pkgs <- installed.packages()
> pkgs[grep("methods", pkgs[,"Depends"]),]
Duncan Murdoch
>> If
>> so, I could scan my already installed libraries and call
>> install.packages() on its S4 subset of packages. The alternative is
>> to do install.packages() an all libraries (sic!). Bioconductor: maybe
>> biocLite() could have such an update mechanism built in internally?
>>
>> If I miss to reinstall one S4 package, what should I expect?
>
> The typical symptom is a clutch of warning messages when you attach the
> package. The warnings try to mention that the package may need
> reinstallling, though sometimes the package name is misleading.
>
>> I assume
>> there will be an error, but I just want to confirm that there is no
>> risk of getting weird "results" but still a running program?
>>
>> Reinstallation is also required for all package that comes as Windows
>> binaries, correct?
> Anything that uses S4 methods will have out-of-date objects for class
> and method definitions.
>
> John
>>
>> Best
>>
>> Henrik
>>
>> On 8/30/06, John Chambers <[EMAIL PROTECTED]> wrote:
>>> A revision of r-devel 2.4.0 is being committed today with changes to
>>> method and class management.
>>>
>>> The changes are internal but extensive. All packages that use S4
>>> methods and classes need to be reinstalled from source to use the new
>>> version.
>>>
>>> The main effects are to speed up method caching and dispatch, and to fix
>>> some problems with selecting inherited methods. The new design is also
>>> cleaner, so we can experiment more easily in the future with changes for
>>> efficiency or semantics.
>>>
>>> The change will mostly be noticeable in attaching packages with many
>>> methods. The CPU time for attaching package Matrix, for example, goes
>>> down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5.
>>>
>>> The other major change is that now _all_ inherited methods are examined
>>> and one of the closest matches is chosen. The old selection took the
>>> first candidate found, so the current version is better defined, and
>>> will also let us experiment with various tuning & strategies.
>>>
>>> There is a draft paper describing method selection at
>>> http://developer.r-project.org/howMethodsWork.pdf
>>> (It's a document in progress, so go back in a few days for a revised
>>> version.)
>>>
>>> If a package uses inheritance for method selection with multiple
>>> arguments, there may well be changes in behavior. We found examples in
>>> both methods itself and in Matrix that needed attention.
>>>
>>> John
>>>
>>> ______________________________________________
>>> 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
