On 02/19/2018 06:43 AM, Michael Lawrence wrote:
On Mon, Feb 19, 2018 at 2:10 AM, Bernat Gel <b...@igtp.cat
<mailto:b...@igtp.cat>> wrote:
Hi Hervé,
I completely agree with the goal of having the semantics of
list-like operations standardised and documented to avoid surprises,
and if to do so, the current use of as.list must be changed I'm
pefectly ok with that. I had not seen the strange behaviour with
IRanges,
Just want to point out that it's important to keep in mind that many of
our users never use IRanges directly, so consistency is not an absolute
requirement.
Even if you only use GRanges objects, it's confusing that lapply()
works on them but not mapply(). The undergoing changes will also
address inconsistencies within the GRanges API, not just the
inconsistencies between the GRanges and IRanges APIs.
H.
so I was not aware of the problem.
In any case, thanks for fixing (and simplifying) karyoploteR. In
retrospective I don't know why I didn't use simple vectorization!
So, thanks
Bernat
*Bernat Gel Moreno*
Bioinformatician
Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)
Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain
Tel: (+34) 93 554 3068 <tel:%28%2B34%29%2093%20554%203068>
Fax: (+34) 93 497 8654 <tel:%28%2B34%29%2093%20497%208654>
08916 Badalona, Barcelona, Spain
b...@igtp.cat <mailto:b...@igtp.cat> <mailto:b...@igtp.cat
<mailto:b...@igtp.cat>>
www.germanstrias.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=ecVcL7fCYBvQUBiQR1iEPlGypQlW1bL-uT77qy5i3rQ&e=>
<http://www.germanstrias.org/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=U2fT0SvLZq-JipogjNgeAMproXB4yH_oBQgNjS8HWsA&e=>>
<http://www.germanstrias.org/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=U2fT0SvLZq-JipogjNgeAMproXB4yH_oBQgNjS8HWsA&e=>>
El 02/17/2018 a las 04:19 AM, Hervé Pagès escribió:
Hi Bernat,
On 02/15/2018 11:57 PM, Bernat Gel wrote:
Hi Hervé and others,
Thanks for the responses.
I woudn't call as.list() of a GRanges an "obscure behaviour"
but more a "works as expected, even if not clearly
documented" behaviour.
Most users/developers will probably agree that as.list() worked
as expected on a GRanges object. But then they'll be surprised
and confused when they use it on an IRanges object and discover
that it does something completely different. The current effort
is to bring more consistency between GRanges and IRanges objects
and to have their list-like semantics aligned and documented so
there will be no more such surprise.
In any case I can change the code to as(gr, "GRangesList")
as suggested.
I went ahead and fixed karyoploteR. This is karyoploteR 1.5.2. Make
sure to resync your GitHub repo by following the instructions here:
https://bioconductor.org/developers/how-to/git/sync-existing-repositories/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_developers_how-2Dto_git_sync-2Dexisting-2Drepositories_&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=Axg4lFtwzxFvnQIBBnj3vmFyle7QPiJNHtqKzBgRKAI&e=>
Note that the loop on the GRanges object (via the call to Map())
was not needed and could be replaced with a solution that uses
proper vectorization.
Best,
H.
Thanks again for the responses and discussion :)
Bernat
*Bernat Gel Moreno*
Bioinformatician
Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer
(PMPPC)
Germans Trias i Pujol Research Institute (IGTP)
Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain
Tel: (+34) 93 554 3068 <tel:%28%2B34%29%2093%20554%203068>
Fax: (+34) 93 497 8654 <tel:%28%2B34%29%2093%20497%208654>
08916 Badalona, Barcelona, Spain
b...@igtp.cat <mailto:b...@igtp.cat> <mailto:b...@igtp.cat
<mailto:b...@igtp.cat>>
www.germanstrias.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=ecVcL7fCYBvQUBiQR1iEPlGypQlW1bL-uT77qy5i3rQ&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=>>
El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:
On 02/15/2018 01:57 PM, Michael Lawrence wrote:
On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès
<hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>
<mailto:hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>>> wrote:
On 02/15/2018 11:53 AM, Cook, Malcolm wrote:
Hi,
Can I ask, is this change under discussion
in current release or
so far in Bioconductor devel only (my
assumption)?
Bioconductor devel only.
> On 02/15/2018 08:37 AM, Michael
Lawrence wrote:
> > So is as.list() no longer supported
for GRanges objects?
I have found it
> > useful in places.
>
> Very few places. I found a dozen of
them in the entire
software repo.
However there are probably more in the wild...
What as.list() was doing on a GRanges object
was not documented. Relying
on some kind of obscure undocumented feature is
never a good idea.
There's just too much that is documented implicitly
through inherited behaviors, or where we say things
like "this data structure behaves as one would
expect given base R". It's not fair to claim that
those features are undocumented. Our documentation
is not complete enough to use it as an excuse.
It's not fair to suggest that this is a widely used
feature either.
I've identified all the places in the 1500 software
packages where
this was used, and, as I said, there were very few
places. BTW I
fixed most of them but my plan is to fix all of them.
Some of the
code that is outside the Bioc package corpus might be
affected but
it's fair to assume that this will be a very rare
occurence. This can
be mitigated by temporary restoring as.list() on
GRanges, with a
deprecation message, and wait 1 more devel cycle to
replace it with
the new behavior. I chose to disable it for now, on
purpose, so I can
identify packages that break (the build report is a
great tool for
that) and fix them.
I'm not using the fact that as.list() on a GRanges is
not documented
as an excuse for anything. Only to help those with
concerns to
relativize and relax.
H.
> Now you should use as.list(as(gr,
"GRangesList")) instead.
> as.list() was behaving inconsistently
on IRanges and
GRanges objects,
> which is blocking new developments. It
will come back with
a consistent
> behavior. More generally speaking
IRanges and GRanges will
behave
> consistently as far as their "list
interpretation" is
concerned.
Can we please be assured to be reminded of
this prominently in
release notes?
The changes will be announced and described on
this list a
<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3Dribed-2Bon-2Bthis-2Blist-2Ba-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=e9q-L1pMV510XgM79pkeGGN0iGFdI0FBAT5_JDvEdg4&e=>nd
in the
NEWS files of the IRanges and GenomicRanges
packages.
H.
Thanks!
~malcolm
-- Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>
<mailto:hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>>
Phone: (206) 667-5791
<tel:%28206%29%20667-5791> <tel:%28206%29%20667-5791>
Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
<tel:%28206%29%20667-1319>
_______________________________________________
Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
<https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yfkWiY-f8hZ6C9aR8HdZEQurWS_HnLMEGwRYr5dTJCo&s=DBJ5ypaS2ZH3bdLZPuMqn8SfDrhbYAEP_x5BnJLlPnQ&e=>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
