Re: [Bioc-devel] DMRcaller build error

2018-04-27 Thread Radu Zabet
Thanks for the feedback!

I've just done that!

Radu

On Fri, Apr 27, 2018 at 8:40 PM, Hervé Pagès  wrote:

> On 04/27/2018 12:31 PM, Radu Zabet wrote:
>
>> Thank you for that Herve!
>>
>> I managed to figure out what the problem was.
>>
>> I was using a GRangesList constructor and,  when validating the argument
>> passed to the function, I was checking if the class was GRangesList instead
>> of CompressedGRangesList.
>>
>
> CompressedGRangesList is a subclass of virtual class GRangesList that
> uses a particular internal representation to store the list in an
> efficient manner.
>
> Note that it's alway better to use is(x, "GRangesList") for this kind
> of checks. The exact class of 'x' does not matter as long as 'x' derives
> from GRangesList. Doing class(x) == "CompressedGRangesList" will be
> FALSE if 'x' is another GRangesList derivative and that is probably not
> what you want.
>
> Cheers,
> H.
>
>
>> Radu
>>
>> On Fri, Apr 27, 2018 at 8:11 PM, Hervé Pagès > > wrote:
>>
>> Hi Radu,
>>
>> DMRcaller is all green on today's report:
>>
>> https://bioconductor.org/checkResults/3.7/bioc-LATEST/DMRcaller/
>> > bioconductor.org_checkResults_3.7_bioc-2DLATEST_DMRcaller_=DwMFaQ=
>> eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJ
>> KaaPhzWA=sC2oO3c16mMorqdk5d8nvHzqg1dL7v228YdPl836xng=FzU
>> y1jhF6u2fVJ4oNL_dP1E2-djzZldXsth0bOXXfEg=>
>>
>> Remember that after you update (and push to git.bioconductor.org
>> > bioconductor.org=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3Xe
>> AvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=sC2oO3c16mMorqdk5d8nv
>> Hzqg1dL7v228YdPl836xng=XmaKhXkb20E2q6udR5bDulIMCnvWq3qxtVUhHLOTZiQ=>)
>> you
>> need to wait at least 18h before the update is visible on the build
>> report. 18h is if you pushed right before the builds start (the
>> software
>> builds start every day at 4:45 pm EST). If you push right after the
>> builds start then you will need to wait 42h!
>>
>> Cheers,
>> H.
>>
>> On 04/20/2018 07:47 AM, Radu Zabet wrote:
>>
>> Hi everyone,
>>
>> I am the maintainer of DMRcaller. I did an update yesterday and
>> on the
>> build report today, the package failed with the error.
>>
>> Error: processing vignette 'DMRcaller.Rnw' failed with
>> diagnostics:
>>methylationProfile needs to be a GRangesList
>> Execution halted
>>
>>
>> On my machine (MacOS with R 3.4.4) it works
>>
>> * creating vignettes ... OK
>>
>> Any suggestion of why this might happen? Is there something I am
>> missing?
>>
>> Radu
>>
>>
>>
>> -- Hervé Pagès
>>
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Canc
>> > google.com_-3Fq-3DFred-2BHutchinson-2BCanc-26entry-
>> 3Dgmail-26source-3Dg=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7
>> q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=sC2oO3c16mMorqdk5
>> d8nvHzqg1dL7v228YdPl836xng=9d0yj_ILpvoHB0vJLvElIr7feDGWvi
>> gQCz4J4bsuCbo=>er
>> 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
>>
>>
>>
>>
>> --
>> Best regards,
>>
>> Dr Nicolae Radu Zabet
>> Lecturer in Computational Biology,
>> School of Biological Sciences, University of Essex,
>> Colchester, CO4 3SQ, United Kingdom
>> T: +44(0)1206872630
>> E: nza...@essex.ac.uk 
>>
>
> --
> 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
>



-- 
Best regards,

Dr Nicolae Radu Zabet
Lecturer in Computational Biology,
School of Biological Sciences, University of Essex,
Colchester, CO4 3SQ, United Kingdom
T: +44(0)1206872630
E: nza...@essex.ac.uk

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] DMRcaller build error

2018-04-27 Thread Hervé Pagès

On 04/27/2018 12:31 PM, Radu Zabet wrote:

Thank you for that Herve!

I managed to figure out what the problem was.

I was using a GRangesList constructor and,  when validating the argument 
passed to the function, I was checking if the class was GRangesList 
instead of CompressedGRangesList.


CompressedGRangesList is a subclass of virtual class GRangesList that
uses a particular internal representation to store the list in an
efficient manner.

Note that it's alway better to use is(x, "GRangesList") for this kind
of checks. The exact class of 'x' does not matter as long as 'x' derives
from GRangesList. Doing class(x) == "CompressedGRangesList" will be
FALSE if 'x' is another GRangesList derivative and that is probably not
what you want.

Cheers,
H.



Radu

On Fri, Apr 27, 2018 at 8:11 PM, Hervé Pagès > wrote:


Hi Radu,

DMRcaller is all green on today's report:

https://bioconductor.org/checkResults/3.7/bioc-LATEST/DMRcaller/



Remember that after you update (and push to git.bioconductor.org

)
you
need to wait at least 18h before the update is visible on the build
report. 18h is if you pushed right before the builds start (the software
builds start every day at 4:45 pm EST). If you push right after the
builds start then you will need to wait 42h!

Cheers,
H.

On 04/20/2018 07:47 AM, Radu Zabet wrote:

Hi everyone,

I am the maintainer of DMRcaller. I did an update yesterday and
on the
build report today, the package failed with the error.

Error: processing vignette 'DMRcaller.Rnw' failed with diagnostics:
   methylationProfile needs to be a GRangesList
Execution halted


On my machine (MacOS with R 3.4.4) it works

* creating vignettes ... OK

Any suggestion of why this might happen? Is there something I am
missing?

Radu



-- 
Hervé Pagès


Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Canc

er
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




--
Best regards,

Dr Nicolae Radu Zabet
Lecturer in Computational Biology,
School of Biological Sciences, University of Essex,
Colchester, CO4 3SQ, United Kingdom
T: +44(0)1206872630
E: nza...@essex.ac.uk 


--
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


Re: [Bioc-devel] DMRcaller build error

2018-04-27 Thread Radu Zabet
Thank you for that Herve!

I managed to figure out what the problem was.

I was using a GRangesList constructor and,  when validating the argument
passed to the function, I was checking if the class was GRangesList instead
of CompressedGRangesList.

Radu

On Fri, Apr 27, 2018 at 8:11 PM, Hervé Pagès  wrote:

> Hi Radu,
>
> DMRcaller is all green on today's report:
>
>   https://bioconductor.org/checkResults/3.7/bioc-LATEST/DMRcaller/
>
> Remember that after you update (and push to git.bioconductor.org) you
> need to wait at least 18h before the update is visible on the build
> report. 18h is if you pushed right before the builds start (the software
> builds start every day at 4:45 pm EST). If you push right after the
> builds start then you will need to wait 42h!
>
> Cheers,
> H.
>
> On 04/20/2018 07:47 AM, Radu Zabet wrote:
>
>> Hi everyone,
>>
>> I am the maintainer of DMRcaller. I did an update yesterday and on the
>> build report today, the package failed with the error.
>>
>> Error: processing vignette 'DMRcaller.Rnw' failed with diagnostics:
>>   methylationProfile needs to be a GRangesList
>> Execution halted
>>
>>
>> On my machine (MacOS with R 3.4.4) it works
>>
>> * creating vignettes ... OK
>>
>> Any suggestion of why this might happen? Is there something I am missing?
>>
>> Radu
>>
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Canc
> er
> 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
>



-- 
Best regards,

Dr Nicolae Radu Zabet
Lecturer in Computational Biology,
School of Biological Sciences, University of Essex,
Colchester, CO4 3SQ, United Kingdom
T: +44(0)1206872630
E: nza...@essex.ac.uk

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] build machines

2018-04-27 Thread Hervé Pagès

On 04/27/2018 10:50 AM, Martin Morgan wrote:
For what it's worth, BiocParallel implemented as outlined in it's 
vignette limits the number of cores via


     if (nzchar(Sys.getenv("BBS_HOME")))
     cores <- min(4L, cores)

i.e., checking an environment variable set on the build system. This is 
highly fragile and I wouldn't necessarily recommend this outside the 
BiocParallel context.


One problem with this is that when people troubleshoot they don't
get the same thing than what they see on the build report.

How about detecting that code is being run in the context of
R CMD build or R CMD check instead? Is there an easy/robust
way to do this?

Thanks,
H.



Martin

On 04/27/2018 01:39 PM, Ludwig Geistlinger wrote:

Hi Hervé,


Some packages are good citizens and limit the number of
cores to 1 or 2 only during 'R CMD check' but some packages
try to use all the cores that are available


That seems to be an important note for developers using parallel 
computation.
What's best practice to realize this within my code, i.e. checking 
whether the code is currently subject to R CMD check (and accordingly 
reducing the number of cores used)?


Thanks,
Ludwig

--
Dr. Ludwig Geistlinger
CUNY School of Public Health


From: Bioc-devel  on behalf of 
Kasper Daniel Hansen 

Sent: Friday, April 27, 2018 10:29 AM
To: Hervé Pagès
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] build machines

Thanks.

I used
   /usr/bin/time -v R CMD check ...
to record the max memory usage of the check, which for minfi suggests
around 5Gb.  That's a lot.

Best,
Kasper

On Thu, Apr 26, 2018 at 3:02 PM, Hervé Pagès  
wrote:



Hi,

The Linux and Windows builders have 32 GB of RAM, the Mac
builders 64 Gb.

We also run concurrent R CMD check's.

Here is a summary:

   platform   RAM   nb of nb of concurrent
  (Gb)  cores    R CMD check's
   ---
   Linux (malbecs) 32  20   10
   Windows (tokays)    32  40   24
   Mac (meridas)   64  24   18

That's a lot of concurrency. And there is actually more
concurrency than that if you consider the fact that many
packages run things in parallel during 'R CMD check'.
Some packages are good citizens and limit the number of
cores to 1 or 2 only during 'R CMD check' but some packages
try to use all the cores that are available. This will have
a strong impact on the overall progress of the builds. We
don't have an easy way to identify those packages right now.

In average, based on our monitoring of the build machines
things seem to work ok i.e. the concurrent R CMD check's
don't seem to be competing too much to access resources.

But occasionally there could be too much competition. The
crazy big elapsed time compared to the relatively short user
and system times that you observed Kasper are likely to reflect
that. They could be the sign that the machine ran out of memory
and started swapping. Not because it happens to your package
means that your package uses too much memory. The swapping is
the result of the **cumulated** memory usage of all the
R CMD check's running at that moment. It could be worth checking
how much memory R CMD check'ing your package uses though.

The exact set of packages that are being R CMD check'ed at any
given time is in constant fluctuation and will also vary from
one day to the other. This would explain why some days you see
timeouts on some platforms and some days not. We don't have
an easy way to know which packages were competing with yours
during the 40 min window that 'R CMD check' was running on your
package until the build system declared a timeout. It's possible
(by looking at the BBS logs) but is time consuming.

We should probably add some memory at some point to the Windows
builders. 32 Gb is not enough to smoothly run 24 R CMD check's
concurrently.

H.


On 04/26/2018 08:48 AM, Diogo FT Veiga wrote:


Hi Daniel,

I have the same issue with my package (new contribution). I just finish
reviewing the package with the modifications requested.

I am having a warning because R CMD check is exceeding 5 min, but 
this is

happening only in the Windows machine.

In Linux and OSX the check finishes in <= 4min, while in Windows takes
~6min.

https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
ctor.org_spb-5Freports_maser-5Fbuildreport-5F20180425114748
.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY
_wJYbW0WYiZvSXAJJKaaPhzWA=JwiMI-3BEUJlonlihLD_mDkPuEIalQbk
rQPSGahzfsg=1aMitB3PnVLoojx1lnj_UT_ZeKlJ_OcJDFT4D6BPXow=


Not sure how to proceed from here.

Thanks,
Diogo


On Thu, Apr 26, 2018 at 9:52 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

We have been working on the minfi package lately, with a move to a

DelayedArray backend.

Right now there are some 

Re: [Bioc-devel] build machines

2018-04-27 Thread Martin Morgan
For what it's worth, BiocParallel implemented as outlined in it's 
vignette limits the number of cores via


if (nzchar(Sys.getenv("BBS_HOME")))
cores <- min(4L, cores)

i.e., checking an environment variable set on the build system. This is 
highly fragile and I wouldn't necessarily recommend this outside the 
BiocParallel context.


Martin

On 04/27/2018 01:39 PM, Ludwig Geistlinger wrote:

Hi Hervé,


Some packages are good citizens and limit the number of
cores to 1 or 2 only during 'R CMD check' but some packages
try to use all the cores that are available


That seems to be an important note for developers using parallel computation.
What's best practice to realize this within my code, i.e. checking whether the 
code is currently subject to R CMD check (and accordingly reducing the number 
of cores used)?

Thanks,
Ludwig

--
Dr. Ludwig Geistlinger
CUNY School of Public Health


From: Bioc-devel  on behalf of Kasper Daniel Hansen 

Sent: Friday, April 27, 2018 10:29 AM
To: Hervé Pagès
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] build machines

Thanks.

I used
   /usr/bin/time -v R CMD check ...
to record the max memory usage of the check, which for minfi suggests
around 5Gb.  That's a lot.

Best,
Kasper

On Thu, Apr 26, 2018 at 3:02 PM, Hervé Pagès  wrote:


Hi,

The Linux and Windows builders have 32 GB of RAM, the Mac
builders 64 Gb.

We also run concurrent R CMD check's.

Here is a summary:

   platform   RAM   nb of nb of concurrent
  (Gb)  coresR CMD check's
   ---
   Linux (malbecs) 32  20   10
   Windows (tokays)32  40   24
   Mac (meridas)   64  24   18

That's a lot of concurrency. And there is actually more
concurrency than that if you consider the fact that many
packages run things in parallel during 'R CMD check'.
Some packages are good citizens and limit the number of
cores to 1 or 2 only during 'R CMD check' but some packages
try to use all the cores that are available. This will have
a strong impact on the overall progress of the builds. We
don't have an easy way to identify those packages right now.

In average, based on our monitoring of the build machines
things seem to work ok i.e. the concurrent R CMD check's
don't seem to be competing too much to access resources.

But occasionally there could be too much competition. The
crazy big elapsed time compared to the relatively short user
and system times that you observed Kasper are likely to reflect
that. They could be the sign that the machine ran out of memory
and started swapping. Not because it happens to your package
means that your package uses too much memory. The swapping is
the result of the **cumulated** memory usage of all the
R CMD check's running at that moment. It could be worth checking
how much memory R CMD check'ing your package uses though.

The exact set of packages that are being R CMD check'ed at any
given time is in constant fluctuation and will also vary from
one day to the other. This would explain why some days you see
timeouts on some platforms and some days not. We don't have
an easy way to know which packages were competing with yours
during the 40 min window that 'R CMD check' was running on your
package until the build system declared a timeout. It's possible
(by looking at the BBS logs) but is time consuming.

We should probably add some memory at some point to the Windows
builders. 32 Gb is not enough to smoothly run 24 R CMD check's
concurrently.

H.


On 04/26/2018 08:48 AM, Diogo FT Veiga wrote:


Hi Daniel,

I have the same issue with my package (new contribution). I just finish
reviewing the package with the modifications requested.

I am having a warning because R CMD check is exceeding 5 min, but this is
happening only in the Windows machine.

In Linux and OSX the check finishes in <= 4min, while in Windows takes
~6min.

https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
ctor.org_spb-5Freports_maser-5Fbuildreport-5F20180425114748
.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY
_wJYbW0WYiZvSXAJJKaaPhzWA=JwiMI-3BEUJlonlihLD_mDkPuEIalQbk
rQPSGahzfsg=1aMitB3PnVLoojx1lnj_UT_ZeKlJ_OcJDFT4D6BPXow=


Not sure how to proceed from here.

Thanks,
Diogo


On Thu, Apr 26, 2018 at 9:52 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

We have been working on the minfi package lately, with a move to a

DelayedArray backend.

Right now there are some weird issues regarding timings in R CMD check.
Leaving aside the issue that the tests (now disabled) and examples are
too
slow, we get some very weird behaviour.

An example is the current (soon to be replace) build report of minfi
1.25.2
which prints

Examples with CPU or elapsed time > 5s
user system  

Re: [Bioc-devel] Build Error processing vignette

2018-04-27 Thread Shepherd, Lori
You should do exactly as the message suggests change to html_document instead 
of html_document2


http://bioconductor.org/checkResults/3.7/bioc-LATEST/debrowser/malbec2-buildsrc.html


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Kucukural, 
Alper 
Sent: Friday, April 27, 2018 1:26:37 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Build Error processing vignette

Hi,
I got build error processing the vignette.

The error is

Error: processing vignette 'DEBrowser.Rmd' failed with diagnostics:

'html_document2' is defunct.

How can I solve this problem?
Thanks,

Alper Kucukural, PhD
Assistant Professor, Program in Molecular Medicine
Bioinformatics Core
University of Massachusetts Medical School
368 Plantation St.Room AS4.2061
Worcester, MA 01605-2324
Phone: 774-312-4493
E-mail: alper.kucuku...@umassmed.edu


[[alternative HTML version deleted]]

___
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


Re: [Bioc-devel] build machines

2018-04-27 Thread Ludwig Geistlinger
Hi Hervé,

> Some packages are good citizens and limit the number of
> cores to 1 or 2 only during 'R CMD check' but some packages
> try to use all the cores that are available

That seems to be an important note for developers using parallel computation.
What's best practice to realize this within my code, i.e. checking whether the 
code is currently subject to R CMD check (and accordingly reducing the number 
of cores used)?

Thanks,
Ludwig 

--
Dr. Ludwig Geistlinger
CUNY School of Public Health


From: Bioc-devel  on behalf of Kasper Daniel 
Hansen 
Sent: Friday, April 27, 2018 10:29 AM
To: Hervé Pagès
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] build machines

Thanks.

I used
  /usr/bin/time -v R CMD check ...
to record the max memory usage of the check, which for minfi suggests
around 5Gb.  That's a lot.

Best,
Kasper

On Thu, Apr 26, 2018 at 3:02 PM, Hervé Pagès  wrote:

> Hi,
>
> The Linux and Windows builders have 32 GB of RAM, the Mac
> builders 64 Gb.
>
> We also run concurrent R CMD check's.
>
> Here is a summary:
>
>   platform   RAM   nb of nb of concurrent
>  (Gb)  coresR CMD check's
>   ---
>   Linux (malbecs) 32  20   10
>   Windows (tokays)32  40   24
>   Mac (meridas)   64  24   18
>
> That's a lot of concurrency. And there is actually more
> concurrency than that if you consider the fact that many
> packages run things in parallel during 'R CMD check'.
> Some packages are good citizens and limit the number of
> cores to 1 or 2 only during 'R CMD check' but some packages
> try to use all the cores that are available. This will have
> a strong impact on the overall progress of the builds. We
> don't have an easy way to identify those packages right now.
>
> In average, based on our monitoring of the build machines
> things seem to work ok i.e. the concurrent R CMD check's
> don't seem to be competing too much to access resources.
>
> But occasionally there could be too much competition. The
> crazy big elapsed time compared to the relatively short user
> and system times that you observed Kasper are likely to reflect
> that. They could be the sign that the machine ran out of memory
> and started swapping. Not because it happens to your package
> means that your package uses too much memory. The swapping is
> the result of the **cumulated** memory usage of all the
> R CMD check's running at that moment. It could be worth checking
> how much memory R CMD check'ing your package uses though.
>
> The exact set of packages that are being R CMD check'ed at any
> given time is in constant fluctuation and will also vary from
> one day to the other. This would explain why some days you see
> timeouts on some platforms and some days not. We don't have
> an easy way to know which packages were competing with yours
> during the 40 min window that 'R CMD check' was running on your
> package until the build system declared a timeout. It's possible
> (by looking at the BBS logs) but is time consuming.
>
> We should probably add some memory at some point to the Windows
> builders. 32 Gb is not enough to smoothly run 24 R CMD check's
> concurrently.
>
> H.
>
>
> On 04/26/2018 08:48 AM, Diogo FT Veiga wrote:
>
>> Hi Daniel,
>>
>> I have the same issue with my package (new contribution). I just finish
>> reviewing the package with the modifications requested.
>>
>> I am having a warning because R CMD check is exceeding 5 min, but this is
>> happening only in the Windows machine.
>>
>> In Linux and OSX the check finishes in <= 4min, while in Windows takes
>> ~6min.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
>> ctor.org_spb-5Freports_maser-5Fbuildreport-5F20180425114748
>> .html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY
>> _wJYbW0WYiZvSXAJJKaaPhzWA=JwiMI-3BEUJlonlihLD_mDkPuEIalQbk
>> rQPSGahzfsg=1aMitB3PnVLoojx1lnj_UT_ZeKlJ_OcJDFT4D6BPXow=
>>
>>
>> Not sure how to proceed from here.
>>
>> Thanks,
>> Diogo
>>
>>
>> On Thu, Apr 26, 2018 at 9:52 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> We have been working on the minfi package lately, with a move to a
>>> DelayedArray backend.
>>>
>>> Right now there are some weird issues regarding timings in R CMD check.
>>> Leaving aside the issue that the tests (now disabled) and examples are
>>> too
>>> slow, we get some very weird behaviour.
>>>
>>> An example is the current (soon to be replace) build report of minfi
>>> 1.25.2
>>> which prints
>>>
>>> Examples with CPU or elapsed time > 5s
>>>user system  elapsed
>>> preprocessFunnorm   99.388  0.632  148.554
>>> combineArrays   64.104  2.120   68.329
>>> bumphunter  62.540  1.392   64.107
>>> preprocessNoob  43.944  0.016   

[Bioc-devel] Build Error processing vignette

2018-04-27 Thread Kucukural, Alper
Hi,
I got build error processing the vignette.

The error is

Error: processing vignette 'DEBrowser.Rmd' failed with diagnostics:

'html_document2' is defunct.

How can I solve this problem?
Thanks,

Alper Kucukural, PhD
Assistant Professor, Program in Molecular Medicine
Bioinformatics Core
University of Massachusetts Medical School
368 Plantation St.Room AS4.2061
Worcester, MA 01605-2324
Phone: 774-312-4493
E-mail: alper.kucuku...@umassmed.edu


[[alternative HTML version deleted]]

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


Re: [Bioc-devel] How to update R version in terminal?

2018-04-27 Thread Hervé Pagès

Hi,

On 04/27/2018 09:34 AM, Yuande Tan wrote:

Dear Sirs,
I want to update R 3.3.1 in terminal in my local mac computer.
I use the following command to install r 3.5.0
brew cask install r-app

and also

brew link --overwrite r


But R --version shows

R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"

Copyright (C) 2016 The R Foundation for Statistical Computing

Platform: x86_64-apple-darwin11.0.0 (64-bit)


Anyone can help me to address this problem?


Any reason you're not installing the CRAN binary?

  https://cran.r-project.org/bin/macosx/

Please note that this is not a Bioconductor question. It is better to
ask this kind of question on general R discussion channels like the
R-help or R-SIG-Mac mailing list or Stack Overflow.

Cheers,
H.




Thanks



Yuande

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=HqvexBcWB-xz8MjS_TwC_bBhQlHytyjCHlOhaJf4nb8=TeoqGt6tumKLFdxpQcB4ys07vuqVmLjW-5n8OBCEkzo=



--
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


[Bioc-devel] How to update R version in terminal?

2018-04-27 Thread Yuande Tan
Dear Sirs,
I want to update R 3.3.1 in terminal in my local mac computer.
I use the following command to install r 3.5.0
brew cask install r-app

and also

brew link --overwrite r


But R --version shows

R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"

Copyright (C) 2016 The R Foundation for Statistical Computing

Platform: x86_64-apple-darwin11.0.0 (64-bit)


Anyone can help me to address this problem?


Thanks



Yuande

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] Prostar problems reported in the Multiple platform build/check report for BioC 3.7

2018-04-27 Thread Shepherd, Lori
I did respond on your other email to the mailing list


https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013412.html


It may take a day or two for all the packages to find each other.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of WIECZOREK 
Samuel 175264 
Sent: Friday, April 27, 2018 11:48:13 AM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Prostar problems reported in the Multiple platform 
build/check report for BioC 3.7

Hi

I jjust received that message to inform that there are errors in the BUILD 
process of DAPAR.
It says that DAPARdata_1.9.2 is needed (that is ok) but not available.
But, I have committed DAPARdata_1.9.2 a few days ago and it seems ok : 
https://master.bioconductor.org/packages/3.7/data/experiment/html/DAPARdata.html

So, I don't understand why DAPAR do not find it.

Have you got an idea ?

Best regards

Sam

De : bbs-nore...@bioconductor.org [bbs-nore...@bioconductor.org]
Envoy� : vendredi 27 avril 2018 17:02
� : WIECZOREK Samuel 175264
Objet : Prostar problems reported in the Multiple platform build/check report 
for BioC 3.7

[This is an automatically generated email. Please don't reply.]

Hi Prostar maintainer,

According to the Multiple platform build/check report for BioC 3.7,
the Prostar package has the following problem(s):

  o ERROR for 'R CMD INSTALL' on malbec2. See the details here:
  
https://master.bioconductor.org/checkResults/3.7/bioc-LATEST/Prostar/malbec2-install.html

  o ERROR for 'R CMD build' on malbec2. See the details here:
  
https://master.bioconductor.org/checkResults/3.7/bioc-LATEST/Prostar/malbec2-buildsrc.html

Please take the time to address this by committing and pushing
changes to your package at git.bioconductor.org

Notes:

  * This was the status of your package at the time this email was sent to you.
Given that the online report is updated daily (in normal conditions) you
could see something different when you visit the URL(s) above, especially if
you do so several days after you received this email.

  * It is possible that the problems reported in this report are false 
positives,
either because another package (from CRAN or Bioconductor) breaks your
package (if yours depends on it) or because of a Build System problem.
If this is the case, then you can ignore this email.

  * Please check the report again 24h after you've committed your changes to the
package and make sure that all the problems have gone.

  * If you have questions about this report or need help with the
maintenance of your package, please use the Bioc-devel mailing list:

  https://bioconductor.org/help/mailing-list/

(all package maintainers are requested to subscribe to this list)

For immediate notification of package build status, please
subscribe to your package's RSS feed. Information is at:

https://bioconductor.org/developers/rss-feeds/

Thanks for contributing to the Bioconductor project!


___
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


Re: [Bioc-devel] Prostar problems reported in the Multiple platform build/check report for BioC 3.7

2018-04-27 Thread WIECZOREK Samuel 175264
Hi

I jjust received that message to inform that there are errors in the BUILD 
process of DAPAR.
It says that DAPARdata_1.9.2 is needed (that is ok) but not available.
But, I have committed DAPARdata_1.9.2 a few days ago and it seems ok : 
https://master.bioconductor.org/packages/3.7/data/experiment/html/DAPARdata.html

So, I don't understand why DAPAR do not find it.

Have you got an idea ?

Best regards

Sam

De : bbs-nore...@bioconductor.org [bbs-nore...@bioconductor.org]
Envoyé : vendredi 27 avril 2018 17:02
À : WIECZOREK Samuel 175264
Objet : Prostar problems reported in the Multiple platform build/check report 
for BioC 3.7

[This is an automatically generated email. Please don't reply.]

Hi Prostar maintainer,

According to the Multiple platform build/check report for BioC 3.7,
the Prostar package has the following problem(s):

  o ERROR for 'R CMD INSTALL' on malbec2. See the details here:
  
https://master.bioconductor.org/checkResults/3.7/bioc-LATEST/Prostar/malbec2-install.html

  o ERROR for 'R CMD build' on malbec2. See the details here:
  
https://master.bioconductor.org/checkResults/3.7/bioc-LATEST/Prostar/malbec2-buildsrc.html

Please take the time to address this by committing and pushing
changes to your package at git.bioconductor.org

Notes:

  * This was the status of your package at the time this email was sent to you.
Given that the online report is updated daily (in normal conditions) you
could see something different when you visit the URL(s) above, especially if
you do so several days after you received this email.

  * It is possible that the problems reported in this report are false 
positives,
either because another package (from CRAN or Bioconductor) breaks your
package (if yours depends on it) or because of a Build System problem.
If this is the case, then you can ignore this email.

  * Please check the report again 24h after you've committed your changes to the
package and make sure that all the problems have gone.

  * If you have questions about this report or need help with the
maintenance of your package, please use the Bioc-devel mailing list:

  https://bioconductor.org/help/mailing-list/

(all package maintainers are requested to subscribe to this list)

For immediate notification of package build status, please
subscribe to your package's RSS feed. Information is at:

https://bioconductor.org/developers/rss-feeds/

Thanks for contributing to the Bioconductor project!


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


Re: [Bioc-devel] build machines

2018-04-27 Thread Kasper Daniel Hansen
Thanks.

I used
  /usr/bin/time -v R CMD check ...
to record the max memory usage of the check, which for minfi suggests
around 5Gb.  That's a lot.

Best,
Kasper

On Thu, Apr 26, 2018 at 3:02 PM, Hervé Pagès  wrote:

> Hi,
>
> The Linux and Windows builders have 32 GB of RAM, the Mac
> builders 64 Gb.
>
> We also run concurrent R CMD check's.
>
> Here is a summary:
>
>   platform   RAM   nb of nb of concurrent
>  (Gb)  coresR CMD check's
>   ---
>   Linux (malbecs) 32  20   10
>   Windows (tokays)32  40   24
>   Mac (meridas)   64  24   18
>
> That's a lot of concurrency. And there is actually more
> concurrency than that if you consider the fact that many
> packages run things in parallel during 'R CMD check'.
> Some packages are good citizens and limit the number of
> cores to 1 or 2 only during 'R CMD check' but some packages
> try to use all the cores that are available. This will have
> a strong impact on the overall progress of the builds. We
> don't have an easy way to identify those packages right now.
>
> In average, based on our monitoring of the build machines
> things seem to work ok i.e. the concurrent R CMD check's
> don't seem to be competing too much to access resources.
>
> But occasionally there could be too much competition. The
> crazy big elapsed time compared to the relatively short user
> and system times that you observed Kasper are likely to reflect
> that. They could be the sign that the machine ran out of memory
> and started swapping. Not because it happens to your package
> means that your package uses too much memory. The swapping is
> the result of the **cumulated** memory usage of all the
> R CMD check's running at that moment. It could be worth checking
> how much memory R CMD check'ing your package uses though.
>
> The exact set of packages that are being R CMD check'ed at any
> given time is in constant fluctuation and will also vary from
> one day to the other. This would explain why some days you see
> timeouts on some platforms and some days not. We don't have
> an easy way to know which packages were competing with yours
> during the 40 min window that 'R CMD check' was running on your
> package until the build system declared a timeout. It's possible
> (by looking at the BBS logs) but is time consuming.
>
> We should probably add some memory at some point to the Windows
> builders. 32 Gb is not enough to smoothly run 24 R CMD check's
> concurrently.
>
> H.
>
>
> On 04/26/2018 08:48 AM, Diogo FT Veiga wrote:
>
>> Hi Daniel,
>>
>> I have the same issue with my package (new contribution). I just finish
>> reviewing the package with the modifications requested.
>>
>> I am having a warning because R CMD check is exceeding 5 min, but this is
>> happening only in the Windows machine.
>>
>> In Linux and OSX the check finishes in <= 4min, while in Windows takes
>> ~6min.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__biocondu
>> ctor.org_spb-5Freports_maser-5Fbuildreport-5F20180425114748
>> .html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY
>> _wJYbW0WYiZvSXAJJKaaPhzWA=JwiMI-3BEUJlonlihLD_mDkPuEIalQbk
>> rQPSGahzfsg=1aMitB3PnVLoojx1lnj_UT_ZeKlJ_OcJDFT4D6BPXow=
>>
>>
>> Not sure how to proceed from here.
>>
>> Thanks,
>> Diogo
>>
>>
>> On Thu, Apr 26, 2018 at 9:52 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> We have been working on the minfi package lately, with a move to a
>>> DelayedArray backend.
>>>
>>> Right now there are some weird issues regarding timings in R CMD check.
>>> Leaving aside the issue that the tests (now disabled) and examples are
>>> too
>>> slow, we get some very weird behaviour.
>>>
>>> An example is the current (soon to be replace) build report of minfi
>>> 1.25.2
>>> which prints
>>>
>>> Examples with CPU or elapsed time > 5s
>>>user system  elapsed
>>> preprocessFunnorm   99.388  0.632  148.554
>>> combineArrays   64.104  2.120   68.329
>>> bumphunter  62.540  1.392   64.107
>>> preprocessNoob  43.944  0.016   44.955
>>> preprocessQuantile  33.968  0.064   36.547
>>> getAnnotation   31.072  0.024   31.126
>>> compartments18.668  0.188   18.871
>>> minfiQC 10.124  6.628 1102.929
>>> getSex  10.536  0.012   10.561
>>> read.metharray   7.504  2.116   82.713
>>> read.metharray.exp   9.076  0.032   10.592
>>> mapToGenome-methods  4.648  0.548  163.648
>>> mdsPlot  0.340  0.204   14.901
>>>
>>>
>>> on Tokay (Linux).  Note minfiQC which has an elapsed time which is crazy
>>> high compared to user+system.  Previous build report (which I didn't
>>> save)
>>> had a timeout on all platforms with a semingly similar behaviour but with
>>> the getSex function.  The code did not change in the meantime.  For
>>> today's
>>> build we only see this on 

Re: [Bioc-devel] Need some help to submit a R package.

2018-04-27 Thread Shepherd, Lori
I am still able to open the link:

https://github.com/Bioconductor/Contributions/issues/713



Perhaps there is some firewall or ani-virus program you are running that is 
blocking access?


When you try to go to the link, what message is displayed?


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Shepherd, Lori 

Sent: Friday, April 27, 2018 8:18:23 AM
To: Pijush Das; Morgan, Martin
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Need some help to submit a R package.

I am able to open this link.  Perhaps it was an intermittent internet 
connection issue?  Are you able to open the link now?


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Pijush Das 
Sent: Friday, April 27, 2018 7:06:07 AM
To: Morgan, Martin
Cc: Shepherd, Lori; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Need some help to submit a R package.

Dear Sir,


I have found some problem in github link given below:
https://github.com/Bioconductor/Contributions/issues/713
The link is not opening. Is there any problem in github repository?
Please check it.


Thank you


regards
Pijush







On Thu, Apr 26, 2018 at 2:32 PM, Martin Morgan 
> wrote:
Wait for the reviewer to comment further on your package.

On 04/26/2018 02:20 AM, Pijush Das wrote:
Dear Sir,


I have found that my package sigFeature had passed all the built test without 
errors or warnings
on all platforms.
What should I do next ?





regards
Pijush












On Tue, Apr 24, 2018 at 10:56 PM, Shepherd, Lori 
 
>> 
wrote:

It doesn't look like the webhook was ever initialized


Please follow the instructions here:


https://github.com/Bioconductor/Contributions/blob/master/CONTRIBUTING.md#adding-a-web-hook



After the webhook is set up you will need to do another version bump
to trigger the build -  Please post further correspondence regarding
your package submission on the open github issue


https://github.com/Bioconductor/Contributions/issues/713



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Pijush Das  
>>
*Sent:* Tuesday, April 24, 2018 11:33:14 AM
*To:* Shepherd, Lori
*Cc:* Morgan, Martin; 
bioc-devel@r-project.org
>

*Subject:* Re: [Bioc-devel] Need some help to submit a R package.
Dear sir,


I have uploaded the sigFeature package ( Version: 0.99.1) in the
existing git repository and did a version bump. The link is given below.
https://github.com/pijush1285/sigFeature

  But still now I am not getting any response.
Is there required to add the web hook again ?

Thank you

regards
Pijush



On Tue, Apr 24, 2018 at 5:34 PM, Shepherd, Lori


>> 
wrote:

We like to keep track of the changes and have the reviews in one
place.   If possible it would be better to replace the contents
of existing git repository and do a version bump.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Bioc-devel 


>>
 on behalf of Pijush
Das  
>>
*Sent:* Tuesday, April 24, 2018 7:43:04 AM
*To:* Morgan, Martin
*Cc:* 

Re: [Bioc-devel] Need some help to submit a R package.

2018-04-27 Thread Pijush Das
Now it is opening. It may be some kind of problem is there with the
internet connection.




On Fri, Apr 27, 2018 at 6:56 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> I am still able to open the link:
>
> https://github.com/Bioconductor/Contributions/issues/713
>
>
> Perhaps there is some firewall or ani-virus program you are running that
> is blocking access?
>
>
> When you try to go to the link, what message is displayed?
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of
> Shepherd, Lori 
> *Sent:* Friday, April 27, 2018 8:18:23 AM
> *To:* Pijush Das; Morgan, Martin
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
>
> I am able to open this link.  Perhaps it was an intermittent internet
> connection issue?  Are you able to open the link now?
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Pijush Das 
> Sent: Friday, April 27, 2018 7:06:07 AM
> To: Morgan, Martin
> Cc: Shepherd, Lori; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Need some help to submit a R package.
>
> Dear Sir,
>
>
> I have found some problem in github link given below:
> https://github.com/Bioconductor/Contributions/issues/713
> The link is not opening. Is there any problem in github repository?
> Please check it.
>
>
> Thank you
>
>
> regards
> Pijush
>
>
>
>
>
>
>
> On Thu, Apr 26, 2018 at 2:32 PM, Martin Morgan <
> martin.mor...@roswellpark.org>
> wrote:
> Wait for the reviewer to comment further on your package.
>
> On 04/26/2018 02:20 AM, Pijush Das wrote:
> Dear Sir,
>
>
> I have found that my package sigFeature had passed all the built test
> without errors or warnings
> on all platforms.
> What should I do next ?
>
>
>
>
>
> regards
> Pijush
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 24, 2018 at 10:56 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org <
> mailto:lori.sheph...@roswellpark.org  wrote:
>
> It doesn't look like the webhook was ever initialized
>
>
> Please follow the instructions here:
>
> https://github.com/Bioconductor/Contributions/
> blob/master/CONTRIBUTING.md#adding-a-web-hook
>  blob/master/CONTRIBUTING.md#adding-a-web-hook>
>
> After the webhook is set up you will need to do another version bump
> to trigger the build -  Please post further correspondence regarding
> your package submission on the open github issue
>
>
> https://github.com/Bioconductor/Contributions/issues/713
> 
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> 
> *From:* Pijush Das  <
> mailto:topij...@gmail.com  *Sent:* Tuesday, April 24, 2018 11:33:14 AM
> *To:* Shepherd, Lori
> *Cc:* Morgan, Martin; bioc-devel@r-project.org bioc-devel@r-project.org>
>  >>
>
> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
> Dear sir,
>
>
> I have uploaded the sigFeature package ( Version: 0.99.1) in the
> existing git repository and did a version bump. The link is given
> below.
> https://github.com/pijush1285/sigFeature
> 
>   But still now I am not getting any response.
> Is there required to add the web hook again ?
>
> Thank you
>
> regards
> Pijush
>
>
>
> On Tue, Apr 24, 2018 at 5:34 PM, Shepherd, Lori
> 
>  sheph...@roswellpark.org
>  wrote:
>
> We like to keep track of the changes and have the reviews in one
> place.   If possible it would be better to replace the contents
> of existing git repository and do a version bump.
>
>
> Lori Shepherd

[Bioc-devel] DEADLINE: commits to Bioc 3.7

2018-04-27 Thread Shepherd, Lori
The Bioconductor Release is occurring next week!  The last day to commit 
changes to the devel branch of 3.7 before we branch to RELEASE_3_7 is Sunday 
April 29th.

Please keep in mind - last minute pushes will likely not be checked with a 
daily build and could potentially have ERROR's in both release 3.7 and devel 
3.8 so it is not recommended.  We encourage you to build and check your 
packages locally before pushing (always! but especially) last minute changes.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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


Re: [Bioc-devel] Need some help to submit a R package.

2018-04-27 Thread Shepherd, Lori
I am able to open this link.  Perhaps it was an intermittent internet 
connection issue?  Are you able to open the link now?


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Pijush Das 
Sent: Friday, April 27, 2018 7:06:07 AM
To: Morgan, Martin
Cc: Shepherd, Lori; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Need some help to submit a R package.

Dear Sir,


I have found some problem in github link given below:
https://github.com/Bioconductor/Contributions/issues/713
The link is not opening. Is there any problem in github repository?
Please check it.


Thank you


regards
Pijush







On Thu, Apr 26, 2018 at 2:32 PM, Martin Morgan 
> wrote:
Wait for the reviewer to comment further on your package.

On 04/26/2018 02:20 AM, Pijush Das wrote:
Dear Sir,


I have found that my package sigFeature had passed all the built test without 
errors or warnings
on all platforms.
What should I do next ?





regards
Pijush












On Tue, Apr 24, 2018 at 10:56 PM, Shepherd, Lori 
 
>> 
wrote:

It doesn't look like the webhook was ever initialized


Please follow the instructions here:


https://github.com/Bioconductor/Contributions/blob/master/CONTRIBUTING.md#adding-a-web-hook



After the webhook is set up you will need to do another version bump
to trigger the build -  Please post further correspondence regarding
your package submission on the open github issue


https://github.com/Bioconductor/Contributions/issues/713



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Pijush Das  
>>
*Sent:* Tuesday, April 24, 2018 11:33:14 AM
*To:* Shepherd, Lori
*Cc:* Morgan, Martin; 
bioc-devel@r-project.org
>

*Subject:* Re: [Bioc-devel] Need some help to submit a R package.
Dear sir,


I have uploaded the sigFeature package ( Version: 0.99.1) in the
existing git repository and did a version bump. The link is given below.
https://github.com/pijush1285/sigFeature

  But still now I am not getting any response.
Is there required to add the web hook again ?

Thank you

regards
Pijush



On Tue, Apr 24, 2018 at 5:34 PM, Shepherd, Lori


>> 
wrote:

We like to keep track of the changes and have the reviews in one
place.   If possible it would be better to replace the contents
of existing git repository and do a version bump.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Bioc-devel 


>>
 on behalf of Pijush
Das  
>>
*Sent:* Tuesday, April 24, 2018 7:43:04 AM
*To:* Morgan, Martin
*Cc:* bioc-devel@r-project.org 
>
*Subject:* Re: [Bioc-devel] Need some help to submit a R package.
Dear Sir,

I have solved most of the issues raised by the reviewers.
There were significant amount of changes in the original code.
So should we submit our package (sigFeature) as a new submission
or replace the contents of existing git repository with version
increment.


regards
Pijush


On Mon, Apr 16, 2018 at 5:01 PM, Martin Morgan <
martin.mor...@roswellpark.org


Re: [Bioc-devel] Need some help to submit a R package.

2018-04-27 Thread Pijush Das
No Sir, Still now it is not opening.

On Fri, Apr 27, 2018 at 5:48 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> I am able to open this link.  Perhaps it was an intermittent internet
> connection issue?  Are you able to open the link now?
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Pijush Das 
> *Sent:* Friday, April 27, 2018 7:06:07 AM
> *To:* Morgan, Martin
> *Cc:* Shepherd, Lori; bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
>
> Dear Sir,
>
>
> I have found some problem in github link given below:
> https://github.com/Bioconductor/Contributions/issues/713
> The link is not opening. Is there any problem in github repository?
> Please check it.
>
>
> Thank you
>
>
> regards
> Pijush
>
>
>
>
>
>
>
> On Thu, Apr 26, 2018 at 2:32 PM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
> Wait for the reviewer to comment further on your package.
>
> On 04/26/2018 02:20 AM, Pijush Das wrote:
>
> Dear Sir,
>
>
> I have found that my package sigFeature had passed all the built test
> without errors or warnings
> on all platforms.
> What should I do next ?
>
>
>
>
>
> regards
> Pijush
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 24, 2018 at 10:56 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org >
> wrote:
>
> It doesn't look like the webhook was ever initialized
>
>
> Please follow the instructions here:
>
> https://github.com/Bioconductor/Contributions/blob/master/CO
> NTRIBUTING.md#adding-a-web-hook
>  ONTRIBUTING.md#adding-a-web-hook>
>
> After the webhook is set up you will need to do another version bump
> to trigger the build -  Please post further correspondence regarding
> your package submission on the open github issue
>
>
> https://github.com/Bioconductor/Contributions/issues/713
> 
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> 
> *From:* Pijush Das >
> *Sent:* Tuesday, April 24, 2018 11:33:14 AM
> *To:* Shepherd, Lori
> *Cc:* Morgan, Martin; bioc-devel@r-project.org
> 
>
> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
> Dear sir,
>
>
> I have uploaded the sigFeature package ( Version: 0.99.1) in the
> existing git repository and did a version bump. The link is given
> below.
> https://github.com/pijush1285/sigFeature
> 
>   But still now I am not getting any response.
> Is there required to add the web hook again ?
>
> Thank you
>
> regards
> Pijush
>
>
>
> On Tue, Apr 24, 2018 at 5:34 PM, Shepherd, Lori
>  > wrote:
>
> We like to keep track of the changes and have the reviews in one
> place.   If possible it would be better to replace the contents
> of existing git repository and do a version bump.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> 
> *From:* Bioc-devel  > on behalf of Pijush
> Das >
> *Sent:* Tuesday, April 24, 2018 7:43:04 AM
> *To:* Morgan, Martin
> *Cc:* bioc-devel@r-project.org 
> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
> Dear Sir,
>
> I have solved most of the issues raised by the reviewers.
> There were significant amount of changes in the original code.
> So should we submit our package (sigFeature) as a new submission
> or replace the contents of existing git repository with version
> increment.
>
>
> regards
> Pijush
>
>
> On Mon, Apr 16, 2018 at 5:01 PM, Martin Morgan <
> martin.mor...@roswellpark.org
> > wrote:
>
> > If you are still having problems understanding warnings, it is
> probably
> > better to use the github issue -- it may 

Re: [Bioc-devel] Need some help to submit a R package.

2018-04-27 Thread Pijush Das
Dear Sir,


I have found some problem in github link given below:
https://github.com/Bioconductor/Contributions/issues/713
The link is not opening. Is there any problem in github repository?
Please check it.


Thank you


regards
Pijush







On Thu, Apr 26, 2018 at 2:32 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> Wait for the reviewer to comment further on your package.
>
> On 04/26/2018 02:20 AM, Pijush Das wrote:
>
>> Dear Sir,
>>
>>
>> I have found that my package sigFeature had passed all the built test
>> without errors or warnings
>> on all platforms.
>> What should I do next ?
>>
>>
>>
>>
>>
>> regards
>> Pijush
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 24, 2018 at 10:56 PM, Shepherd, Lori <
>> lori.sheph...@roswellpark.org >
>> wrote:
>>
>> It doesn't look like the webhook was ever initialized
>>
>>
>> Please follow the instructions here:
>>
>> https://github.com/Bioconductor/Contributions/blob/master/
>> CONTRIBUTING.md#adding-a-web-hook
>> > CONTRIBUTING.md#adding-a-web-hook>
>>
>> After the webhook is set up you will need to do another version bump
>> to trigger the build -  Please post further correspondence regarding
>> your package submission on the open github issue
>>
>>
>> https://github.com/Bioconductor/Contributions/issues/713
>> 
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>> 
>> 
>> *From:* Pijush Das >
>> *Sent:* Tuesday, April 24, 2018 11:33:14 AM
>> *To:* Shepherd, Lori
>> *Cc:* Morgan, Martin; bioc-devel@r-project.org
>> 
>>
>> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
>> Dear sir,
>>
>>
>> I have uploaded the sigFeature package ( Version: 0.99.1) in the
>> existing git repository and did a version bump. The link is given
>> below.
>> https://github.com/pijush1285/sigFeature
>> 
>>   But still now I am not getting any response.
>> Is there required to add the web hook again ?
>>
>> Thank you
>>
>> regards
>> Pijush
>>
>>
>>
>> On Tue, Apr 24, 2018 at 5:34 PM, Shepherd, Lori
>> > > wrote:
>>
>> We like to keep track of the changes and have the reviews in one
>> place.   If possible it would be better to replace the contents
>> of existing git repository and do a version bump.
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>> 
>> 
>> *From:* Bioc-devel > > on behalf of Pijush
>> Das >
>> *Sent:* Tuesday, April 24, 2018 7:43:04 AM
>> *To:* Morgan, Martin
>> *Cc:* bioc-devel@r-project.org 
>> *Subject:* Re: [Bioc-devel] Need some help to submit a R package.
>> Dear Sir,
>>
>> I have solved most of the issues raised by the reviewers.
>> There were significant amount of changes in the original code.
>> So should we submit our package (sigFeature) as a new submission
>> or replace the contents of existing git repository with version
>> increment.
>>
>>
>> regards
>> Pijush
>>
>>
>> On Mon, Apr 16, 2018 at 5:01 PM, Martin Morgan <
>> martin.mor...@roswellpark.org
>> > wrote:
>>
>> > If you are still having problems understanding warnings, it is
>> probably
>> > better to use the github issue -- it may take some time to get
>> an answer,
>> > because the reviewers have many responsibilities.
>> >
>> > It looks like your 'webhook' is not correct, and that you are
>> not changing
>> > the version of your package (from 0.99.0 to 0.99.1, 0.99.2,
>> ...) when you
>> > wish to generate another build report. @grimbough indicated in
>> the github
>> > issue how to address these problems.
>> >
>> > Martin
>> >
>> >
>> > On 04/16/2018 03:58 AM, Pijush Das wrote:
>> >
>> >> Dear  Ruqian,
>>