[Bioc-devel] Dependency on windowing systems in the flowCore package

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-request at r-project.org wrote:

Subject:
Re: [Bioc-devel] Dependency on windowing systems in the flowCore 
package
From:
Kieran O'Neill <koneill at bccrc.ca>
Date:
04/10/2014 05:20 PM

To:
Kevin Ushey <kevinushey at gmail.com>
CC:
"bioc-devel at r-project.org" <bioc-devel at 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<kevinushey at 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 <
kasperdanielhansen at 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<kevinushey at 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]]