ks is required by the code copied from feature package, which has been 
moved to flowStats. And 'norm2Filter' is not using it.
Sio with the removal of curv*Filters, flowCore should not depend on ks 
anymore.

Mike
On 04/22/2014 12:14 PM, Kieran O'Neill wrote:
> Thanks all for this work. It definitely makes the most sense to factor 
> out this functionality.
>
> One thing, though: Josef Spidlen pointed out to me the other day that, 
> despite Kevin's fix, there is still a dependency on the ks package, 
> which in turn depends on rgl, which also creates an X11 dependency.
>
> Does the new flowCore, with curv1Filter and curv2Filter removed, but 
> norm2Filter still in, depend on the ks package? If so, there is still 
> the problem of flowCore depending unnecessarily on a windowing system.
>
>
> On 18 April 2014 11:54, Mike <wjiang2@fhcrc.org 
> <mailto:wjiang2@fhcrc.org>> wrote:
>
>     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-request@r-project.org
>     <mailto:bioc-devel-request@r-project.org> wrote:
>     >>>> Subject:
>     >>>> Re: [Bioc-devel] Dependency on windowing systems in the flowCore
>     >>>> package
>     >>>> From:
>     >>>> Kieran O'Neill <koneill@bccrc.ca <mailto:koneill@bccrc.ca>>
>     >>>> Date:
>     >>>> 04/10/2014 05:20 PM
>     >>>>
>     >>>> To:
>     >>>> Kevin Ushey <kevinushey@gmail.com <mailto:kevinushey@gmail.com>>
>     >>>> CC:
>     >>>> "bioc-devel@r-project.org <mailto:bioc-devel@r-project.org>"
>     <bioc-devel@r-project.org <mailto: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<kevinushey@gmail.com
>     <mailto:kevinushey@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@gmail.com
>     <mailto:kasperdanielhansen@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@gmail.com
>     <mailto:kevinushey@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 <mailto:Bioc-devel@r-project.org>
>     mailing list
>     >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>     >>
>     >
>     >
>
>     _______________________________________________
>     Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing
>     list
>     https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>


	[[alternative HTML version deleted]]

