Thanks, Martin!
Yes, it was '%in%' method that failed.
I guess it is not a good idea to define the 'duplicated S4 class ' in
these two closely related packages anyway.
So we decided to move 'curv1Filter' and 'curv2Filter' from 'flowCore'
to 'flowStats' instead(leaving 'norm2Filter' untouched).
I have checked the 16 packages in the 'reverse depends list', actually
only one package ('plateCore') needs minor updates in its NAMESPACE file.
Thus the impact to the user package should be minimum.
Mike
On 04/18/2014 09:20 AM, Martin Morgan wrote:
On 04/17/2014 04:43 PM, Mike wrote:
I am in the processing of deprecating 'curv2Filter', 'curv1Filter' and
'norm2filter' in 'flowCore' and make these three filters available in
'flowStats'.
Here is what I am trying to do:
1. add warning message in 'flowCore' through '.Deprecate()'
2. copy the S4 classes and methods and constructors of the three filters
to 'flowStats' so that other packages can make update their NAMESPACE
and dependencies before they are finally 'Defunct' after 2 release
cycles.
However, I'm having these notes when I install the new 'flowStats'
(installation succeeds though)
Note: the specification for class "curv1Filter" in package 'flowStats'
seems equivalent to one from package 'flowCore': not turning on
duplicate class definitions for this class.
Note: the specification for class "curv2Filter" in package 'flowStats'
seems equivalent to one from package 'flowCore': not turning on
duplicate class definitions for this class.
Note: the specification for class "norm2Filter" in package 'flowStats'
seems equivalent to one from package 'flowCore': not turning on
duplicate class definitions for this class.
and the 'filter` method defined in 'flowCore' no longer dispatches
correctly because of this. Here is reproducible example
(install modified 'flowStats' from 'curvFilter' branch of
https://github.com/RGLab/flowStats)
library(flowStats)
dat <- read.FCS(system.file("extdata","0877408774.B08",
package="flowCore"))
c1f <- curv1Filter(filterId="myCurv1Filter", x=list("FSC-H"), bwFac=2)
## Filtering using curv1Filter
fres <- filter(dat, c1f)
Error in match(x, table, nomatch = 0L) :
'match' requires vector arguments
No solution to offer here. It seems like it's actually dispatch to
%in%, where the method selected is
> fres <- filter(dat, c1f)
Error in match(x, table, nomatch = 0L) :
'match' requires vector arguments
> traceback()
7: match(x, table, nomatch = 0L)
6: x %in% filter
5: x %in% filter
4: .class1(object)
3: as(x %in% filter, "filterResult")
2: filter(dat, c1f)
1: filter(dat, c1f)
> showMethods("%in%")
Function: %in% (package base)
...
x="flowFrame", table="curv1Filter"
(inherited from: x="ANY", table="ANY")
...
Before the call to filter there is actually an explicit
> showMethods("%in%")
Function: %in% (package base)
...
x="flowFrame", table="curv1Filter"
I'm suspecting that the method here is specific to
curv1Filter,flowCore-class, whereas dispatch is looking for
curv1Fitler,flowStats-class.
Maybe a solution is in the fact that 'filter' actually seems to work --
> selectMethod(filter, c(class(dat), class(c1f)))
...
Signatures:
x filter
target "flowFrame" "curv1Filter"
defined "flowFrame" "filter"
it finds the method for the base class shared by
curv1Filter,flowCore-class and curv1Filter,flowStats-class, so
defining a common class curv1Filter_migration and methods on that ?
Martin
Before I decide to remove the duplicated definitions from 'flowCore'
entirely (which is not desired), Does anyone know how to solve this
issue?
Thanks,
Mike
On 04/16/2014 05:06 PM, Mike wrote:
Kevin's fix is already pushed to the latest bioc release and devel.
Thanks,
Mike
On 04/10/2014 11:44 PM, bioc-devel-requ...@r-project.org wrote:
Subject:
Re: [Bioc-devel] Dependency on windowing systems in the flowCore
package
From:
Kieran O'Neill <kone...@bccrc.ca>
Date:
04/10/2014 05:20 PM
To:
Kevin Ushey <kevinus...@gmail.com>
CC:
"bioc-devel@r-project.org" <bioc-devel@r-project.org>
Thanks Kevin!
That would have been my proposed option 3 if I had realised it
would be
that simple.
This will make my (and several other analysts I know's) lives a lot
easier!
Cheers,
Kieran
On 10 April 2014 16:11, Kevin Ushey<kevinus...@gmail.com> wrote:
Hi Kieran,
I've kickstarted the process by sending a pull request here:
https://github.com/RGLab/flowCore/pull/21
Thanks,
Kevin
On Thu, Apr 10, 2014 at 3:48 PM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:
My 2ct is that it is worthwhile to have a lean core package.
It sounds
like it would be trivial to separate gating into a new package,
and -
provided functions are not renamed - would be trivial for
downstream
packages to adapt to.
Especially in situations where competing groups work on the
same analysis
domain, it is great if they can agree on basic data
representation, and
that chance is increased (IMO) if the core package does not
include too
much analysis tools.
Best,
Kasper
On Thu, Apr 10, 2014 at 6:35 PM, Kevin
Ushey<kevinus...@gmail.com>wrote:
Hi Kieran, Dan,
I would suggest that you open an issue at
https://github.com/RGLab/flowCore/issues/new.
Perhaps the easiest solution is to copy featureSignif from
feature into
flowCore (giving adequate citation and such, respecting
licenses...). It
looks like the function doesn't depend too much on other
functionality in
the feature package, so this shouldn't be too much of a problem.
Thanks,
Kevin
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
