Re: [Bioc-devel] Compatibility of S4 and tidyverse

[Bernat Gel Moreno]

Hi Stefano,

Your message to the list was completely empty, thus the joke by Michael.

I think you'll have to resend your message to the list and check it 
arrives as expected so you can get some feedback! :)

Bernat

El 2/6/20 a las 12:29 PM, stefano escribió:
> Hello,
>
> Happy to trigger good laughs, although I did not understand the irony.
>
> If anyone has a clear idea of the issue  or similar experience  and can
> help out would be great!
>
> On Thu, 6 Feb 2020, 8:46 PM Martin Maechler 
> wrote:
>
>>> Michael Lawrence via Bioc-devel
>>>  on Wed, 5 Feb 2020 20:52:52 -0800 writes:
>>  > Yep that about sums it up.
>>
>> :-) ;-)
>>
>> Thank you, Michael !!
>> I haven't laughed  as much from reading e-mails in a long while !!
>>
>> Martin
>>
>>
>>  > On Wed, Feb 5, 2020 at 8:37 PM Stefano Mangiola <
>> mangiolastef...@gmail.com>
>>  > wrote:
>>
>>  {an empty message}
>>
>>  >> ___
>>  >> Bioc-devel@r-project.org mailing list
>>  >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>  >>
>>
>>
>>  > --
>>  > Michael Lawrence
>>  > Senior Scientist, Bioinformatics and Computational Biology
>>  > Genentech, A Member of the Roche Group
>>  > Office +1 (650) 225-7760
>>  > micha...@gene.com
>>
>   [[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

Re: [Bioc-devel] DESeq2 package

[Bernat Gel Moreno]

Hi,

I'm no way related to the DESEq2 package. Its author is Mike Love. Te best way 
is to ask your questions in the bioconductor support site.

https://support.bioconductor.org/

Bernat

De: Bioc-devel  de part de Claudio A Bravo 

Enviat el: dimarts, 24 de gener de 2023 0:22
Per a: bioc-devel@r-project.org 
Tema: [Bioc-devel] DESeq2 package

[No soleu rebre correu d'cbrav...@uw.edu. Descobriu per qu? aquest fet ?s 
important a https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi-

Could you please direct me to the person that can answer questions about this 
package?

Best,

-
Claudio Bravo, MD, FACC, FESC
Assistant Professor
Advanced Heart Failure & Transplant Cardiology
University of Washington



[[alternative HTML version deleted]]

___
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

Re: [Bioc-devel] Windows error "UCSC library operation failed" in package karyoploteR

[Bernat Gel Moreno]

Ops, ok, thanks. Should have reread the documentation.

Thanks

Bernat


El 01/10/2018 a las 2:00, Dario Strbenac escribió:
> Good day,
>
> The import of BigWig files does not work on Windows and is documented. 
> Execute ?BigWigFile-class and notice in the Description section: "These 
> functions do not work on Windows.".
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> 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

[Bioc-devel] Timeout in check for a new submission

[Bernat Gel Moreno]

Hi all,

I've submitted a new package (CopyNumberPlots, issue 1076) and I have a 
problem. It keeps giving me a warning because on windows it takes  more 
than 5 minutes to check (in Lunix it works with no problems). I've 
reduced the examples, removed part of the vignette... and in my machine 
it take 3min 20seconds to check, of which only 30seconds are spent in 
the examples and vignette and the other 2min 50 seconds are spent in all 
other checks.

Other than reducing the vignette and examples I don't know how to reduce 
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Timeout in check for a new submission

[Bernat Gel Moreno]

Thanks Lori :)

I've already written to my reviewer (Qian Liu) asking if it's possible to 
proceed with the review in the current situation.

The code in the package is quite fast (and simple) but I'll take a look at that 
link to see  if I can get a few more seconds out.

Bernat







El 4/5/19 a las 4:43 PM, Shepherd, Lori escribi�:

Also,  the reviewer might be able to glance at the code and help try to make it 
run more efficiently.  See points on 
http://bioconductor.org/developers/how-to/efficient-code/  for things like 
vectorization and pre-allocation.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
<mailto:bioc-devel-boun...@r-project.org> on 
behalf of Shepherd, Lori 
<mailto:lori.sheph...@roswellpark.org>
Sent: Friday, April 5, 2019 10:40:07 AM
To: Bernat Gel Moreno; bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>
Subject: Re: [Bioc-devel] Timeout in check for a new submission

If the check time is passing on the other platforms,  and the windows check 
isn't incredibly over the time limit,  you should be okay.  Talk with your 
reviewer but in general we would make an exception for this warning.

Most of the time subsets of data can be used for examples and vignettes which 
also help to reduce the check time but still retain usefulness of an 
application, without knowing your data just an example  instead of running over 
all chromosomes,  limit to one smaller chromosome, etc...   If this has already 
been done then you should be able to proceed through the submission process 
despite this warning.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
<mailto:bioc-devel-boun...@r-project.org> on 
behalf of Bernat Gel Moreno <mailto:b...@igtp.cat>
Sent: Friday, April 5, 2019 10:27:21 AM
To: bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>
Subject: [Bioc-devel] Timeout in check for a new submission


Hi all,

I've submitted a new package (CopyNumberPlots, issue 1076) and I have a
problem. It keeps giving me a warning because on windows it takes  more
than 5 minutes to check (in Lunix it works with no problems). I've
reduced the examples, removed part of the vignette... and in my machine
it take 3min 20seconds to check, of which only 30seconds are spent in
the examples and vignette and the other 2min 50 seconds are spent in all
other checks.

Other than reducing the vignette and examples I don't know how to reduce
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[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

This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you.


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] TIMEOUTS in the submission systems

[Bernat Gel Moreno]

Hi,

I assume you are already aware of it, but there's a problem with the builder 
for the new packages. It works fine in Windows but Mac and Linux cannot access 
CRAN

checking package dependencies ...Warning: unable to access index for repository 
https://CRAN.R-project.org/src/contrib:
  cannot open URL 'https://CRAN.R-project.org/src/contrib/PACKAGES'

This causes a WARNING in Malbec2 and a TIMEOUT in Celaya2.

Thanks!

Bernat


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] InteractionSet for structural variants

[Bernat Gel Moreno]

Hi all,

Is there any standard recommended container for genomic structural 
variants? I think InteractionSet would work fine for translocation and 
GRanges for inversions and copy number changes, but I don't know what 
would be the recommended way to store them all together using standard 
Bioconductor objects.

And actually, is there any package that would load a SV VCF by lumpy or 
delly and build that object?

Thanks!

Bernat


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] InteractionSet for structural variants

[Bernat Gel Moreno]

Hi Aaron,

Thanks for your response. So far my intention is to to plot them and I 
do not intend on performing any other operation. The first step would be 
read in the VCF file and transform it into a meaningful object and I was 
hoping there was a core package already taking care of that, but I get 
from your answer that there's no such functionality implemented.

Thanks again

Bernat





El 5/18/19 a las 4:47 AM, Aaron Lun escribió:
> I would say that it depends on what operations you intend to perform 
> on them. You can _store_ things any way you like, but the trick is to 
> ensure that operations and manipulations on those things are 
> consistent and meaningful. It is not obvious that there are meaningful 
> common operations that one might want to apply to all structural 
> variants.
>
> For example, translocations involve two genomic regions (i.e., the two 
> bits that get stuck together) and so are inherently two-dimensional. A 
> lot of useful operations will be truly translocation-specific, e.g., 
> calculation of distances between anchor regions, identification of 
> bounding boxes in two-dimensional space. These operations will be 
> meaningless to 1-dimensional variants on the linear genome, e.g., 
> CNVs, inversions. The converse also applies where operations on the 
> linear genome have no single equivalent in the two-dimensional case.
>
> So, I would be inclined to store them separately. If you must keep 
> them in one object, just lump them into a List with "translocation" 
> (GInteractions), "cnv" (GRanges) and "inversion" (another GRanges) 
> elements, and people/programs can pull out bits and pieces as needed.
>
> -A
>
>
> On 5/17/19 4:38 AM, Bernat Gel Moreno wrote:
>> Hi all,
>>
>> Is there any standard recommended container for genomic structural
>> variants? I think InteractionSet would work fine for translocation and
>> GRanges for inversions and copy number changes, but I don't know what
>> would be the recommended way to store them all together using standard
>> Bioconductor objects.
>>
>> And actually, is there any package that would load a SV VCF by lumpy or
>> delly and build that object?
>>
>> Thanks!
>>
>> Bernat
>>
>>
>> ___
>> 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

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Python Z trees to hclust

[Bernat Gel Moreno]

Hi,

For one of our packages (CopyNumberPlots) we'll need to read 10X CNV 
data in H5 format. I've read in everything I need except for the cell 
clustering tree. It's in a format called Z format produced by SciPy 
hierarchical clustering. The format itself is relatively easy to parse 
and not so different from hclust return objects so it would be possible 
to create a small function to translate the Z notation into an hclust 
object, if needed, but I'll need to figure out the "order" vector, since 
it's not present in Z.

   - Is the Z to hclust function available in any other package? Or 
something equivalent to that?
   - If I end up transforming it by hand in a custom function, Is there 
a function somewhere to compute the order vector in an hclust object?

Thanks

Bernat


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bernat Gel Moreno]

Hi all,

I'm the developer of karyoploteR.

@Michael: I never though about using seqinfo as the source for the 
genome information. I'll add this as an option to define the genome. 
Thanks for the suggestion.

@Aditya: If you want to plot just your relevant chromosomes, you don't 
need to alter the genome. You can use the "chromosomes" parameter to 
give a vector of chromosome names. Is it not working for you for some 
reason?

Bernat


El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
> I'm pretty surprised that the karyoploteR package does not accept a
> Seqinfo since it is plotting chromosomes. But again, please consider
> just doing as(seqinfo(bsgenome), "GRanges").
>
> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>  wrote:
>> Hi Herve,
>>
>> Thank you for your responses.
>>  From your response, it is clear that the vcountPDict use case does not need 
>> a BSgenome -> GRanges coercer.
>>
>> The karyoploteR use case still requires it, though, to allow plotting of 
>> only the chromosomal BSgenome portions:
>>
>>  chromranges <- as(bsegenome, "GRanges")
>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>
>> Or do you see any alternative for this purpose too?
>>
>> Aditya
>>
>> 
>> From: Pages, Herve [hpa...@fredhutch.org]
>> Sent: Wednesday, September 11, 2019 12:24 PM
>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>> BiocGenerics (and others)?
>>
>> Hi Aditya,
>>
>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>> Hi Herve,
>>>
>>>
>>>   > It feels that a coercion method from BSgenome to GRanges should
>>> rather be defined in the BSgenome package itself.
>>>
>>> :-)
>>>
>>>
>>>   > Patch/PR welcome on GitHub.
>>>
>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>
>>>
>>>   > Is this what you have in mind for this coercion?
>>>   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>
>>> Yes.
>>>
>>> Perhaps also useful to share the wider context, allowing your and others
>>> feedback for improved software design.
>>> I wanted to subset a
>>> BSgenome
>>> (without the _random or _unassigned), but Lori explained this is not
>>> possible.
>>> 
>>>
>>> Instead Lori suggested to coerce a BSgenome into a GRanges
>>> ,
>>> which is a useful solution, but for which currently no exported S4
>>> method exists
>>> 
>>> So I defined an S4 coercer in my multicrispr package, making sure to
>>> properly import the Bsgenome class
>>> .
>>> Then, after coercing a BSgenome into a GRanges, I can extract the
>>> chromosomes, after properly importing IRanges::`%in%`
>>> 
>> Looks like you don't need to coerce the BSgenome object to GRanges. See
>> https://support.bioconductor.org/p/123489/#124581
>>
>> H.
>>
>>> Which I can then on end to karyoploteR
>>> ,
>>> for genome-wide plots of crispr target sites.
>>>
>>> A good moment also to say thank you to all of you who helped me out, it
>>> helps me to make multicrispr fit nicely into the BioC ecosystem.
>>>
>>> Speeking of BioC design philosophy, can any 

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bernat Gel Moreno]

Oh, and Aditya, take into account taht if you give karyoploteR a custom 
genome as you are planning to do, it will not paint the cytobands by 
default, you'll have to get them yourself and give them to plotKaryotype.

If possible, I would recommend giving the genome by name ("hg19") and 
selecting the chromosomes to plot using "chromosomes".

Bernat




El 9/12/19 a las 8:47 AM, Bernat Gel Moreno escribió:
> Hi all,
>
> I'm the developer of karyoploteR.
>
> @Michael: I never though about using seqinfo as the source for the
> genome information. I'll add this as an option to define the genome.
> Thanks for the suggestion.
>
> @Aditya: If you want to plot just your relevant chromosomes, you don't
> need to alter the genome. You can use the "chromosomes" parameter to
> give a vector of chromosome names. Is it not working for you for some
> reason?
>
> Bernat
>
>
> El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
>> I'm pretty surprised that the karyoploteR package does not accept a
>> Seqinfo since it is plotting chromosomes. But again, please consider
>> just doing as(seqinfo(bsgenome), "GRanges").
>>
>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>  wrote:
>>> Hi Herve,
>>>
>>> Thank you for your responses.
>>>   From your response, it is clear that the vcountPDict use case does not 
>>> need a BSgenome -> GRanges coercer.
>>>
>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>> only the chromosomal BSgenome portions:
>>>
>>>   chromranges <- as(bsegenome, "GRanges")
>>>   kp <- karyoploteR::plotKaryotype(chromranges)
>>>   karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>
>>> Or do you see any alternative for this purpose too?
>>>
>>> Aditya
>>>
>>> 
>>> From: Pages, Herve [hpa...@fredhutch.org]
>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> Hi Aditya,
>>>
>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>> Hi Herve,
>>>>
>>>>
>>>>> It feels that a coercion method from BSgenome to GRanges should
>>>> rather be defined in the BSgenome package itself.
>>>>
>>>> :-)
>>>>
>>>>
>>>>> Patch/PR welcome on GitHub.
>>>>
>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>
>>>>
>>>>> Is this what you have in mind for this coercion?
>>>>> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>
>>>> Yes.
>>>>
>>>> Perhaps also useful to share the wider context, allowing your and others
>>>> feedback for improved software design.
>>>> I wanted to subset a
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI&e=>BSgenome
>>>> (without the _random or _unassigned), but Lori explained this is not
>>>> possible.
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI&e=>
>>>>
>>>> Instead Lori suggested to coerce a BSgenome into a GRanges
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA&e=>,
>>>> which is a useful solution, but for which currently no exported S4
>>>> method exists
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y&e=>
>>>> So I defined a

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bernat Gel Moreno]

I have updated karyoploteR and it's now (from version 1.11.9 in devel) 
possible to use a BSgenome object or a seqinfo object as genome 
definitions in plotKaryotype. In both cases, if possible, it will by 
default automatically filter the chromosomes to the canonical ones (if 
defined) and retrieve the cytobands for the genome. Or you can specify 
the exact chromosomes you want to plot. I think this should help with 
the specific question at hand.

Bernat


El 9/12/19 a las 10:09 AM, Bernat Gel Moreno escribió:
> Oh, and Aditya, take into account taht if you give karyoploteR a custom
> genome as you are planning to do, it will not paint the cytobands by
> default, you'll have to get them yourself and give them to plotKaryotype.
>
> If possible, I would recommend giving the genome by name ("hg19") and
> selecting the chromosomes to plot using "chromosomes".
>
> Bernat
>
>
>
>
> El 9/12/19 a las 8:47 AM, Bernat Gel Moreno escribió:
>> Hi all,
>>
>> I'm the developer of karyoploteR.
>>
>> @Michael: I never though about using seqinfo as the source for the
>> genome information. I'll add this as an option to define the genome.
>> Thanks for the suggestion.
>>
>> @Aditya: If you want to plot just your relevant chromosomes, you don't
>> need to alter the genome. You can use the "chromosomes" parameter to
>> give a vector of chromosome names. Is it not working for you for some
>> reason?
>>
>> Bernat
>>
>>
>> El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
>>> I'm pretty surprised that the karyoploteR package does not accept a
>>> Seqinfo since it is plotting chromosomes. But again, please consider
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>>  wrote:
>>>> Hi Herve,
>>>>
>>>> Thank you for your responses.
>>>>From your response, it is clear that the vcountPDict use case does not 
>>>> need a BSgenome -> GRanges coercer.
>>>>
>>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>>> only the chromosomal BSgenome portions:
>>>>
>>>>chromranges <- as(bsegenome, "GRanges")
>>>>kp <- karyoploteR::plotKaryotype(chromranges)
>>>>karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>>
>>>> Or do you see any alternative for this purpose too?
>>>>
>>>> Aditya
>>>>
>>>> 
>>>> From: Pages, Herve [hpa...@fredhutch.org]
>>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>>> BiocGenerics (and others)?
>>>>
>>>> Hi Aditya,
>>>>
>>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>>> Hi Herve,
>>>>>
>>>>>
>>>>> > It feels that a coercion method from BSgenome to GRanges should
>>>>> rather be defined in the BSgenome package itself.
>>>>>
>>>>> :-)
>>>>>
>>>>>
>>>>> > Patch/PR welcome on GitHub.
>>>>>
>>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>>
>>>>>
>>>>> > Is this what you have in mind for this coercion?
>>>>> > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>>
>>>>> Yes.
>>>>>
>>>>> Perhaps also useful to share the wider context, allowing your and others
>>>>> feedback for improved software design.
>>>>> I wanted to subset a
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI&e=>BSgenome
>>>>> (without the _random or _unassigned), but Lori explained this is not
>>>>> possible.
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367&d=DwMFAw&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY&s=xNa-6ZKTD1MnnfT55

Re: [Bioc-devel] Python Z trees to hclust

[Bernat Gel Moreno]

Hi Peter,

Thanks for the advice and pointers to the relevant files. After reading 
the Fortran code and thinking about it I ended up coding from scratch my 
own pure R function to set the plotting order of an hclust object. It 
might not be as fast as the Fortran implementation, but it works pretty 
well and as far as I can tell the resulting order is exactly the same to 
the original hclust code. If anyone is interested it's available at the 
CopyNumberPlots package at 
https://github.com/bernatgel/CopyNumberPlots/blob/5b9a1efea53e424a32616b7d82560d81c9ba4a10/R/utils.R#L933

Bernat



El 8/3/19 a las 8:41 PM, Peter Langfelder escribió:
> Hi Bernat,
>
> my advice may not be that useful, but it may be better than the
> silence so far...
>
> Regarding the ordering of objects in hclust, if you're willing to do a
> bit of hacking, have a look at the stats::hclust function; you will
> see that the ordering is computed by a call to Fortran function
> hcass2. That function could be used or perhaps adapted (it uses an
> additional step that you will probably need to skip) to give you the
> ordering. If you're good at understanding Fortran code, you may even
> be able to re-write it directly in R.
>
> Peter
>
> On Tue, Jul 30, 2019 at 12:39 AM Bernat Gel Moreno  wrote:
>> Hi,
>>
>> For one of our packages (CopyNumberPlots) we'll need to read 10X CNV
>> data in H5 format. I've read in everything I need except for the cell
>> clustering tree. It's in a format called Z format produced by SciPy
>> hierarchical clustering. The format itself is relatively easy to parse
>> and not so different from hclust return objects so it would be possible
>> to create a small function to translate the Z notation into an hclust
>> object, if needed, but I'll need to figure out the "order" vector, since
>> it's not present in Z.
>>
>> - Is the Z to hclust function available in any other package? Or
>> something equivalent to that?
>> - If I end up transforming it by hand in a custom function, Is there
>> a function somewhere to compute the order vector in an hclust object?
>>
>> Thanks
>>
>> Bernat
>>
>>
>> ___
>> 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