Re: [Rd] R-2.15.0 and Exporting Methods Converted To S4 Generic
You have to export the new generic as well.
Uwe Ligges
On 12.04.2012 20:41, Roebuck,Paul L wrote:
Late to the show on this release, unfortunately.
One of our production packages no longer builds under R-2.15.0
with the following message.
** testing if installed package can be loaded
Error: Function found when exporting methods from the namespace
'SuperCurve' which is not S4 generic: 'image'
Possibly relevant clues follow:
## From R/AllGenerics.R
if (!isGeneric("image")) {
setGeneric("image",
function(x, ...) standardGeneric("image"))
}
We have done the same for many S3 generics, converting them
to S4 and adding specific method-combinations as such...
## From various other R files...
setMethod("image", signature(x="RPPA"), ...
setMethod("image", signature(x="RPPADesign"), ...
And then exported them for use outside the package.
## NAMESPACE
import(methods)
importFrom("graphics", image)
exportClasses()
exportMethods(image)
If the problem is because of the exportMethods(), I'm left
stumped as to how to work around this. Making our S4 objects
useable externally was kind of the point.
Source package available, if needed.
oompa<- "http://bioinformatics.mdanderson.org/OOMPA/2.14";
download.packages("SuperCurve", destdir=".", repos=oompa, type="source")
__
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] [patch] giving library() a 'version' argument
> Roebuck,Paul L
> on Thu, 12 Apr 2012 14:17:45 -0500 writes:
> On 4/12/12 1:56 PM, "Ken Williams" wrote:
>> On April 12, 2012 1:48 PM, Paul Roebuck wrote:
>>
>>> Not sure I follow you here. The packageVersion() method is
>>> essentially a shortcut to packageDescription("MyPackage")$Version. I
>>> generally avoid doing package upgrades in my scripts so the loaded
>>> package IS the installed package (even when playing .libPaths()
>>> tricks).
>>
>> The scenario is:
>>
>> library(PackageX) # Quietly loads version 1 of PackageY
>>
>> # Try to load a specific version of PackageY
>> .libPaths('directory/containing/PackageY/version-2') library(PackageY)
>> # actually does nothing, since it's already loaded
>> stopifnot(packageVersion('PackageY') >= 2) # ??
>>
>>
>> The intention of the stopifnot() expression is to make sure version 2
>> is loaded.
>>
>> If packageVersion() goes & looks for PackageY in .libPaths() even when
>> the package is already loaded, it will provide the wrong answer -
>> because it will find version 2, but version 1 is what's loaded.
>> However, if packageVersion() checks the version of what's already
>> loaded, then it would do the right thing here.
>>
>> I don't think the docs for packageDescription() clarify what happens
>> in this case, but I could be missing it.
> If you're going to "play" with .libPaths() like that,
> it should be done prior to ANY libraries being loaded.
> Going about the style you do below, you'd need to parse
> sessionInfo() instead. packageVersion() as well as
> packageDescription() give you the information based on
> the first package in the path with the same name. If you
> dynamically change the path, the returned information
> could be different...
Aa..h, now we are getting into a more interesting issue:
Fortunately, what you say above has *not* been true for a while
(I think, but am not sure, that I was involved in fixing it..):
Indeed nowadays, packageDescription() *) *does*
use the correct package version, by inspecting the "path"
attribute of the package, in the same way as
searchpaths()
does --- a function, BTW, that I think should be known and used
more than I think it is.
*) packageVersion() is built on packageDescription() and hence
is also correct accordingly.
--
Martin Maechler, ETH Zurich (and R core).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reference Class import() behaviour
Dear All,
In a project I've been working on we've been using Reference Classes
and grid extensively. However, something that I have come across is
that when using the import() method on refclass objects, it does not
work as expected with grid grobs and viewports.
I have prepared test cases that illustrate the point but the general
idea is that importing appears to work fine for everything except
viewports and grid grobs.
Code to illustrate the point follows.
# This first case is an example to show that the importing process
# I have been using works for simple cases
test <- setRefClass("classTest", fields = c("nums", "testlist"),
methods = list(
initialize = function(nums = 1:10, testlist = NULL) {
nums <<- nums
testlist <<- testlist
},
view = function() {
print(nums)
print(testlist)
}))
test2 <- setRefClass("classTest2", contains = "classTest")
t1 <- test$new(11:20, list(test = "hello, world!"))
t1$view()
t2 <- test2$new()
t2$view()
t2$import(t1) # Now lets grab t1's nums and list
t2$view()
# Now observe that when we start dealing with grid grobs and viewports
# the importing process breaks.
a.gen <- setRefClass("classA", fields = c("vps", "gt", "nums"),
methods = list(
initialize = function(vps = NULL, gt = NULL, nums = 1:10) {
vps <<- vps
gt <<- gt
nums <<- nums
},
view = function() {
print(vps)
print(gt)
print(nums)
}))
b.gen <- setRefClass("classB", contains = "classA")
library(grid)
my.vps <- vpTree(viewport(name = "parent"),
vpList(viewport(name = "child")))
my.gtree <- gTree(name = "tree",
children = gList(rectGrob(vp = "parent"),
textGrob("test", vp = "child")))
a <- a.gen$new(vps = my.vps, gt = my.gtree, nums = 11:20)
b <- b.gen$new()
a$view()
b$view()
# Everything works as expected so far...
# Now lets try importing the fields from a into b
# Note that viewports and gTrees break the import process.
# Numbers and lists work fine, as in the example above.
b$import(a)
b$view()
# A workaround is to perform manual assignment
b$vps <- a$vps
b$gt <- a$gt
b$nums <- a$nums
b$view() # Desired result
I'm not sure what's causing this, or whether I'm going about this in
the wrong way but any assistance would be much appreciated.
-- Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.15.0 and Exporting Methods Converted To S4 Generic
On 04/13/2012 01:40 AM, Uwe Ligges wrote:
You have to export the new generic as well.
that's not correct.
Uwe Ligges
On 12.04.2012 20:41, Roebuck,Paul L wrote:
Late to the show on this release, unfortunately.
One of our production packages no longer builds under R-2.15.0
with the following message.
** testing if installed package can be loaded
Error: Function found when exporting methods from the namespace
'SuperCurve' which is not S4 generic: 'image'
Possibly relevant clues follow:
## From R/AllGenerics.R
if (!isGeneric("image")) {
setGeneric("image",
function(x, ...) standardGeneric("image"))
}
I think this paradigm is left over from an earlier time; at the time of
package installation you know that your namespace has access to
graphics::image, and that graphics::image is not an S4 generic. Also,
your intention is to make an S4 generic without changing the signature.
So just
setGeneric("image")
though the more explicit setGeneric is not incorrect, and the
conditional promotion shouldn't be incorrect either.
We have done the same for many S3 generics, converting them
to S4 and adding specific method-combinations as such...
## From various other R files...
setMethod("image", signature(x="RPPA"), ...
setMethod("image", signature(x="RPPADesign"), ...
And then exported them for use outside the package.
## NAMESPACE
import(methods)
importFrom("graphics", image)
exportClasses()
exportMethods(image)
conceptually, having created the generic it seems like you should export
it, but exportMethods will export the generic as well.
Your package actually installs under R-devel, and I wonder if this is a
manifestation of the bug reported here
https://stat.ethz.ch/pipermail/r-devel/2012-April/063783.html
A work-around seems to be an unconditional setGeneric("image").
Martin
If the problem is because of the exportMethods(), I'm left
stumped as to how to work around this. Making our S4 objects
useable externally was kind of the point.
Source package available, if needed.
oompa<- "http://bioinformatics.mdanderson.org/OOMPA/2.14";
download.packages("SuperCurve", destdir=".", repos=oompa, type="source")
__
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
--
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
Re: [Rd] [patch] giving library() a 'version' argument
From: Martin Maechler [maech...@stat.math.ethz.ch]
> Indeed nowadays, packageDescription() *) *does*
> use the correct package version, by inspecting the "path"
> attribute of the package, in the same way as
> searchpaths()
Yeah, that's what I suspected, but only from reading the code of
packageDescription(). It doesn't seem to mention this in the docs. And I
wasn't 100% confident from reading the code, in case it was a 'promise' or
something like that.
I'm willing to write a doc patch but it'll take a few days, I'm traveling.
---
Ken Williams, Senior Research Scientist
Applied Mathematics Group, WindLogics Inc.
CONFIDENTIALITY NOTICE: This e-mail message is for the s...{{dropped:7}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating a reference manual during R CMD build
I'd like to have a way to create reference manuals during R CMD build (and have them go in the build/ directory of the resulting package tarball), whether or not any of my Rd files have \Sexpr macros in them. It seems like there are a couple of ways to suppress the building of manuals during R CMD build: 1) using --no-manual and 2) putting BuildManual: no in DESCRIPTION, but there are no corresponding ways to force a reference manual to be built during R CMD build. I know the manual is produced during R CMD check, but for the purposes of putting together the Bioconductor website, it is simpler if the manual is creating during build and then extracted from the source tarball later when we propagate newly built packages to our website. If we instead use the manuals produced during R CMD check, it's possible that the package and manual can get out of sync. Is this something that can be added? I'd prefer for it to be a command-line switch to R CMD build (such as --force-build-manual) rather than a package-level metadata item in the DESCRIPTION file, because I want manuals built for all Bioconductor packages without having to worry whether I've added the appropriate line to the DESCRIPTION file. Thanks very much, Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
