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 <wjia...@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-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
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
