[Bioc-devel] Mac builds in devel

2018-04-10 Thread Obenchain, Valerie
We've been having some space issues with our devel Mac builder that has caused 
the builds to fail the past 2 days. Tomorrow the machine will be down briefly 
for some maintenance but should be back up in time to build at 5pm EST.  If all 
goes well merida2 will be back in the report on Thursday the 12th.

Sorry for the inconvenience.

Valerie


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] iGraph depending packages failing on Windows build machines

2018-04-10 Thread petr smirnov
I noticed that our Bioconductor package (PharmacoGx) is failing to build on
Windows development, with the error:

 error: DLL 'maps' not found: maybe not installed for this architecture?

A google search brings up the package 'sincell', which has experienced this
error before.

The only dependency that package has is iGraph (CRAN), which we share with
them. Checking some of the build reports, there's a handful of packages
failing with the same issue.

There is also at least one package, 'Mulcom', that is failing with the
error:

Error : package 'maps' is not installed for 'arch = i386'

The CRAN package 'maps' seems to be the one providing the 'maps.dll' file.
There seems to be a successful binary build of the 'maps' package on CRAN
for both the release and prerelease versions of R.

Is this is an issue with the package 'maps' not being successfully
installed on the Windows build system?

-- 
Petr Smirnov

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] single-package build, from git trigger: new linux build report missing

2018-04-10 Thread Martin Morgan
I *think* this is back up; you could do a version bump or resubmit the 
web hook (go to your repository --> settings --> webhooks -> edit -> 
'Redeliver' the event with 'X-GitHub-event: push').


Thanks for the heads-up

Martin

On 04/10/2018 06:09 PM, Paul Shannon wrote:

Maybe this is already known.  Maybe it’s my error.

As recently as April 4th, a single-package build, initiated from a git push 
trigger, produced reports for all three architectures: merida2 (OS X), malbec2 
(linux), and tokay2 (windows).

Since then, and still today, I only get reports from tokay2 and merida2.  The 
linux build report is not included.

Any suggestions for those of us hustling to get clean builds on all three 
architectures?

- Paul

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




This email message may contain legally privileged and/or...{{dropped:2}}

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


[Bioc-devel] right version "masked" by wrong version - not sure what "masked means"

2018-04-10 Thread Paul Shannon
I am trying to build IGV (a new submission) on windows (tokay2) after linux and 
macOS build clean.

IGV needs its base class package, BrowserViz, at version >= 2.0, whose build 
report is OK for install, build, and build bin.   BrowserViz 2.0.11 fails 
check, probably because now web browser is available on the build machines.

The IGV build on windows reports an error I have not seen before.  Can anyone 
help?  What does “masked” mean in this context - not of a function, method or 
variable, but apparently of the entire package?

- Paul

* installing *source* package 'IGV' ...
** R
** inst
** byte-compile and prepare package for lazy loading
Warning: version 2.0.11 of 'BrowserViz' masked by 1.11.0 in 
C:/Users/pkgbuild/packagebuilder/workers/jobs/704/R-libs
Error : package 'BrowserViz' 1.11.0 was found, but >= 2.0 is required by 'IGV'

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


Re: [Bioc-devel] single-package build, from git trigger: new linux build report missing

2018-04-10 Thread Paul Shannon
Thanks, Martin.  It is indeed back up.

 - Paul

> On Apr 10, 2018, at 4:09 PM, Martin Morgan  
> wrote:
> 
> I *think* this is back up; you could do a version bump or resubmit the web 
> hook (go to your repository --> settings --> webhooks -> edit -> 'Redeliver' 
> the event with 'X-GitHub-event: push').
> 
> Thanks for the heads-up
> 
> Martin
> 
> On 04/10/2018 06:09 PM, Paul Shannon wrote:
>> Maybe this is already known.  Maybe it’s my error.
>> As recently as April 4th, a single-package build, initiated from a git push 
>> trigger, produced reports for all three architectures: merida2 (OS X), 
>> malbec2 (linux), and tokay2 (windows).
>> Since then, and still today, I only get reports from tokay2 and merida2.  
>> The linux build report is not included.
>> Any suggestions for those of us hustling to get clean builds on all three 
>> architectures?
>> - Paul
>> ___
>> 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.

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


Re: [Bioc-devel] BiocCheck error

2018-04-10 Thread Martin Morgan
Hi Aimin -- the problem is that your vignette has two VignetteEngine 
commands in it


PathwaySplice/vignettes master$ grep VignetteEngine *
tutorial.Rmd:  %\VignetteEngine{knitr::rmarkdown}
tutorial.Rmd:  %\VignetteEngine{knitr::knitr}

Also, please avoid writing to files in the user system, replace 
'C:/temp' with tempfile() or dir = tempfile(); dir.create(dir) in code 
like the following


PathwaySplice master$ grep -r "C:/" *
man/runPathwaySplice.Rd: 
output.file='C:/temp/test.csv')
man/runPathwaySplice.Rd: 
output.file='C:/temp/test.csv')
man/enrichmentMap.Rd:  label.node.by.index = TRUE, 
output.file.dir='C:/temp')
man/enrichmentMap.Rd:  label.node.by.index = FALSE, 
output.file.dir='C:/temp')}
man/compareResults.Rd:compareResults(20, res.adj, res.unadj, 
gene.based.table, type.boxplot='Only3',output.dir='C:/TEMP')
R/Run_pathwaysplice.R:#' 
output.file='C:/temp/test.csv')
R/Run_pathwaysplice.R:#' 
output.file='C:/temp/test.csv')
R/Run_pathwaysplice.R:#'   label.node.by.index = 
TRUE, output.file.dir='C:/temp')
R/Run_pathwaysplice.R:#'   label.node.by.index = 
FALSE, output.file.dir='C:/temp')}
R/Run_pathwaysplice.R:#' compareResults(20, res.adj, res.unadj, 
gene.based.table, type.boxplot='Only3',output.dir='C:/TEMP')


Martin

On 04/10/2018 04:39 PM, Aimin Yan wrote:

I used "R CMD check PathwaySplice_1.3.0.tar.gz", and get it passed
without errors and warnings.

However I get the following error when I use "R CMD BiocCheck
PathwaySplice_1.3.0.tar.gz"

R CMD BiocCheck PathwaySplice_1.3.0.tar.gz

This is BiocCheck version 1.15.8. BiocCheck is a work in progress.

Output and severity of issues may change. Installing package...

* Checking for version number mismatch...

* Checking if other packages can import this one...

* Checking to see if we understand object initialization...

 * NOTE: Consider clarifying how 12 object(s) are initialized. Maybe

   they are part of a data set loaded with data(), or perhaps part

   of an object referenced in with() or within().

 object (function)

   winMenuAddItem (.onAttach)

   ggplot (compareResults2)

   aes (compareResults2)

   random_sampling_200k (compareResults2)

   PValue (compareResults2)

   PathwaySplice (compareResults2)

   geom_point (compareResults2)

   geom_smooth (compareResults2)

   labs (compareResults2)

   scale_colour_manual (compareResults2)

   scale_shape_manual (compareResults2)

   get.col.scale (netplot)

* Checking vignette directory...

 This is a software package

Error in vapply(vigdircontents, vigHelper, logical(1), builder = desc) :

   values must be length 1,

  but FUN(X[[1]]) result is length 2

Calls:  ... BiocCheck -> checkVignetteDir -> checkVigBuilder ->
vapply

Execution halted



Any idea about this?


Here is my sessionInfo()

https://gist.github.com/aiminy/764718da9b9eeedd6f5eea196ce956b4

Thank you,

Aimin

[[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...{{dropped:2}}

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


[Bioc-devel] single-package build, from git trigger: new linux build report missing

2018-04-10 Thread Paul Shannon
Maybe this is already known.  Maybe it’s my error.

As recently as April 4th, a single-package build, initiated from a git push 
trigger, produced reports for all three architectures: merida2 (OS X), malbec2 
(linux), and tokay2 (windows).

Since then, and still today, I only get reports from tokay2 and merida2.  The 
linux build report is not included.

Any suggestions for those of us hustling to get clean builds on all three 
architectures?

- Paul

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


[Bioc-devel] single-package build, from git trigger: new linux build report missing

2018-04-10 Thread Paul Shannon
Maybe this is already known.

As recently as April 4th, a single-package build initiated from a git push 
trigger produced reports for all three architectures: merida2 (OS X), malbec2 
(linux), and tokay2 (windows).

Since then, and still today, I only get reports from tokay2 and merida2.  The 
linux build report is not included.

Any suggestions for those of us hustling to get clean builds on all three 
architectures?

 - Paul

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


Re: [Bioc-devel] vignette problems

2018-04-10 Thread Martin Morgan

Hi --

I'm not sure what you mean; the 'devel' builld report does not include 
mac (the build system experienced problems with disk space last night, 
so the build did not complete)


  https://bioconductor.org/checkResults/devel/bioc-LATEST/STAN/

and STAN failed in Release

  https://bioconductor.org/checkResults/release/bioc-LATEST/STAN/


HOWEVER, I spent some time with your package. First, I compiled it with 
compiler flages -Wall -pedantic, which makes the compiler quite 
sensitive. I did this by creating, on my Linux, a file


$ cat ~/.R/Makevars
CFLAGS = -g -O0 -Wall -pedantic
CXXFLAGS = -g -O0 -Wall -pedantic

and then installing the package from the source directory

STAN master$ rm -f src/*o && R CMD INSTALL .

There were a number of minor issues (unused variables, incorrect printf 
formatting [and use of printf() rather than Rprintf()]) as well as 
somewhat more substantial problems (virtual destructors for polymorphic 
base classes); a few problems remain, of the form


RWrapper.cpp:950:5: warning: control reaches end of non-void 
function [-Wreturn-type]

 }

where the problem is obvious -- no return value if parallel != 0 -- but 
also innocuous, since it seems from inspection that in fact this 
function is always invoked with parallel == 0


HMM* createHMM(int parallel, int K, InitialProbability* initProb, 
TransitionMatrix* transMat, EmissionFunction** myEmissions)

{
if(parallel == 0)
{
return new HMM(K, initProb, transMat, myEmissions);
}
}

You should fix these problems, e.g., by removing the parallel argument 
from the function and body. After cleaning up as best I could, I install 
the package again and ran the vignette through valgrind


STAN master$ R CMD INSTALL .
...
STAN master$ cd vignettes
STAN/vignettes master$ R CMD Stangle STAN-knitr.Rnw
STAN/vignettes master$ R CMD Stangle STAN-knitr.Rnw
STAN/vignettes master$ R -d valgrind -f STAN-knitr.R

leading to an about mismatched new[] / delete[] -- memory allocated by 
'new x[]' must be deleted with 'delete[]', but the package code had 
simply 'delete'.


With these changes, the vignette builds without segfaulting or valgrind 
errors on my machine, and on the Mac builder; I did not check the full 
build and check of the package.


The changes are summarized in the following commits:

STAN master$ git log --oneline
a719f42 version bump
b8e2123 make destructors for polymorhpic base classes virtual
18ac6ba mismatch new[] / delete[]
985768b restore EmissionFactory::createEmissionFunctionMixed
8b749db provide return value for non-void functions
26ca36e update poor printf statements
0bb83ab clear 'unused variable' -Wall -pedantic warnings
a3b7666 remove vignette product STAN-knitr.R

You should pull these down to your local git repository, e.g., for me I have

STAN master$ git remote -v
origin  g...@git.bioconductor.org:packages/STAN (fetch)
origin  g...@git.bioconductor.org:packages/STAN (push)

So I would

STAN master$ git pull origin master

to incorporate the changes.

It would be good to port these changes to the RELEASE_3_6 branch; 
remember to bump the version of the RELEASE_3_6 branch to 2.6.1.


Unfortunately, I pushed the changes after tonight's builds started, so 
the effect of the changes will not be reported until Thursday 
mid-morning, Eastern time, if the build system does not have problems.


Martin

On 04/10/2018 02:14 PM, campos wrote:

Hi Martin,

it seems like mac is ok now. What has changed??

Thank you very much,

Rafael


On 10.04.2018 11:33, Martin Morgan wrote:



On 04/10/2018 05:27 AM, campos wrote:

Hi Martin,

Thank you very much, I am a bit concerned about the option of:


Last Changed Date: 2018-04-05 09:37:37 -0400 (Thu, 05 Apr 2018)

I did a change yesterday and push it, why isn't it visible?


Notice that at the top of the build report it says

  This page was generated on 2018-04-09 09:50:05 -0400 (Mon, 09 Apr 
2018).


  Snapshot Date: 2018-04-08 16:45:28 -0400 (Sun, 08 Apr 2018)

If you pushed after the snapshot date then your changes are not yet 
visible.


Martin



Best,

Rafa




On 09.04.2018 16:44, Martin Morgan wrote:

I'll try to provide you with a pull request addressing issues. Martin

On 04/09/2018 08:42 AM, campos wrote:

Dear devel team,

I am still puzzled with the problems with mac compiling. I am 
really lost and have no idea how to continue or how to be able to 
check about this problems with my linux machine in order to fix it 
faster. Could you please help me with that??


Best,

Rafael


On 05.04.2018 14:29, Shepherd, Lori wrote:


In order for changes to be propagated a version bump in the 
DESCRIPTION file is needed.  Please bump the version in the 
DESCRIPTION file to 2.7.2.





Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, 

[Bioc-devel] Bioconductor 3.7 release: update NEWS

2018-04-10 Thread Obenchain, Valerie
Hi,

Remember to update your NEWS files by Wednesday, April 25. Content from these 
is collated and included in the release announcement.

Valerie


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] RELEASE_3_6 branch frozen at 3:00pm EST tomorrow

2018-04-10 Thread Turaga, Nitesh
Hello Maintainers,

We are going to block pushes to the RELEASE_3_6 branch tomorrow at 15:00 EST. 
Maintainers who were planning to commit have until tomorrow 15:00 EST (3pm EST) 
to fix any outstanding issues they have. 

NOTE: Once the builds are done, the Bioconductor RELEASE_3_6 branch will be 
frozen forever.

Best regards,

Nitesh Turaga
Bioconductor Core Team

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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Bioc-devel] BiocCheck error

2018-04-10 Thread Aimin Yan
I used "R CMD check PathwaySplice_1.3.0.tar.gz", and get it passed
without errors and warnings.

However I get the following error when I use "R CMD BiocCheck
PathwaySplice_1.3.0.tar.gz"

R CMD BiocCheck PathwaySplice_1.3.0.tar.gz

This is BiocCheck version 1.15.8. BiocCheck is a work in progress.

Output and severity of issues may change. Installing package...

* Checking for version number mismatch...

* Checking if other packages can import this one...

* Checking to see if we understand object initialization...

* NOTE: Consider clarifying how 12 object(s) are initialized. Maybe

  they are part of a data set loaded with data(), or perhaps part

  of an object referenced in with() or within().

object (function)

  winMenuAddItem (.onAttach)

  ggplot (compareResults2)

  aes (compareResults2)

  random_sampling_200k (compareResults2)

  PValue (compareResults2)

  PathwaySplice (compareResults2)

  geom_point (compareResults2)

  geom_smooth (compareResults2)

  labs (compareResults2)

  scale_colour_manual (compareResults2)

  scale_shape_manual (compareResults2)

  get.col.scale (netplot)

* Checking vignette directory...

This is a software package

Error in vapply(vigdircontents, vigHelper, logical(1), builder = desc) :

  values must be length 1,

 but FUN(X[[1]]) result is length 2

Calls:  ... BiocCheck -> checkVignetteDir -> checkVigBuilder ->
vapply

Execution halted



Any idea about this?


Here is my sessionInfo()

https://gist.github.com/aiminy/764718da9b9eeedd6f5eea196ce956b4

Thank you,

Aimin

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] vignette problems

2018-04-10 Thread campos

Hi Martin,

it seems like mac is ok now. What has changed??

Thank you very much,

Rafael


On 10.04.2018 11:33, Martin Morgan wrote:



On 04/10/2018 05:27 AM, campos wrote:

Hi Martin,

Thank you very much, I am a bit concerned about the option of:


Last Changed Date: 2018-04-05 09:37:37 -0400 (Thu, 05 Apr 2018)

I did a change yesterday and push it, why isn't it visible?


Notice that at the top of the build report it says

  This page was generated on 2018-04-09 09:50:05 -0400 (Mon, 09 Apr 
2018).


  Snapshot Date: 2018-04-08 16:45:28 -0400 (Sun, 08 Apr 2018)

If you pushed after the snapshot date then your changes are not yet 
visible.


Martin



Best,

Rafa




On 09.04.2018 16:44, Martin Morgan wrote:

I'll try to provide you with a pull request addressing issues. Martin

On 04/09/2018 08:42 AM, campos wrote:

Dear devel team,

I am still puzzled with the problems with mac compiling. I am 
really lost and have no idea how to continue or how to be able to 
check about this problems with my linux machine in order to fix it 
faster. Could you please help me with that??


Best,

Rafael


On 05.04.2018 14:29, Shepherd, Lori wrote:


In order for changes to be propagated a version bump in the 
DESCRIPTION file is needed.  Please bump the version in the 
DESCRIPTION file to 2.7.2.





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 
campos 

*Sent:* Thursday, April 5, 2018 7:45:57 AM
*To:* Morgan, Martin; bioc-devel
*Subject:* Re: [Bioc-devel] vignette problems
Hey Martin,

I pushed new changes since last friday but in
https://bioconductor.org/checkResults/3.7/bioc-LATEST/STAN/ says that
the last change date was friday. Any idea what is the problem?

I have tried to fix the problems with memory and all you told me.

Best,

Rafael


On 03.04.2018 17:06, Martin Morgan wrote:
> Please use 'reply all' so that the mailing list remains engaged.
>
> Check out the release schedule
>
> http://bioconductor.org/developers/release-schedule/
>
> in particular
>
> Wednesday April 25
>
> - Deadline for packages passing ‘‘R CMD build’’ and ‘‘R CMD check’’
> without errors or warnings.
>
> so you still have time to get your package in order.
>
> Using the same techniques as before, I still see valgrind problems,
> the first being
>
> > hmm_fitted_poilog = fitHMM(trainRegions, hmm_poilog,
> sizeFactors=sizeFactors, maxIters=10)
> ==24916== Invalid write of size 4
> ==24916==    at 0x4BA93FD7:
> TransitionMatrix::updateAuxiliaries(double**, double***, double*,
> int*, int, int**, int, double, int) (TransitionMatrix.cpp:292)
> ==24916==    by 0x4BA77934: HMM::updateSampleAux(double***, 
int*, int,

> double**, double**, double**, double***, double*, int*, int*, int*,
> int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
> (HMM.cpp:771)
> ==24916==    by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
int*,

> int, int, int**, int*, int*, int*, int, int, int**, double***,
> SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
> ==24916==    by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
> ==24916==    by 0x4F2992D: R_doDotCall (dotcode.c:692)
> ==24916==    by 0x4F339D5: do_dotcall (dotcode.c:1252)
> ==24916==    by 0x4F81BA6: bcEval (eval.c:6771)
> ==24916==    by 0x4F6E963: Rf_eval (eval.c:624)
> ==24916==    by 0x4F71188: R_execClosure (eval.c:1764)
> ==24916==    by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
> ==24916==    by 0x4F6F18B: Rf_eval (eval.c:747)
> ==24916==    by 0x4F74B12: do_set (eval.c:2774)
> ==24916==  Address 0x2e73a294 is 4 bytes inside a block of size 
5 alloc'd

> ==24916==    at 0x4C2DB8F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==24916==    by 0x4BA93FA6:
> TransitionMatrix::updateAuxiliaries(double**, double***, double*,
> int*, int, int**, int, double, int) (TransitionMatrix.cpp:289)
> ==24916==    by 0x4BA77934: HMM::updateSampleAux(double***, 
int*, int,

> double**, double**, double**, double***, double*, int*, int*, int*,
> int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
> (HMM.cpp:771)
> ==24916==    by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
int*,

> int, int, int**, int*, int*, int*, int, int, int**, double***,
> SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
> ==24916==    by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
> ==24916==    by 0x4F2992D: R_doDotCall (dotcode.c:692)
> ==24916==    by 0x4F339D5: do_dotcall (dotcode.c:1252)
> ==24916==    by 0x4F81BA6: bcEval (eval.c:6771)
> ==24916==    by 0x4F6E963: Rf_eval (eval.c:624)
> ==24916==    by 0x4F71188: R_execClosure (eval.c:1764)
> ==24916==    by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
> ==24916==    by 0x4F6F18B: Rf_eval (eval.c:747)
> ==24916==
>
> This seems 

Re: [Bioc-devel] Bioc-devel changes and SummarizedExperiment class

2018-04-10 Thread Hervé Pagès

Hi Leonard,

This should be fixed in SGSeq 1.13.6 (see commit
5dc16968f7ea1a4b59595ebaabacca9a76699b80).

Cheers,
H.

On 04/04/2018 09:23 AM, Leonard Goldstein wrote:

Hi Hervé,

Some recent changes in bioc-devel are causing trouble with
SummarizedExperiment objects if the rowRanges slot inherits from
GRangesList. Please see example below.

Thanks in advance for your help.

Leonard

--

library(SGSeq)

## SGVariants object inherits from GRangesList




is(sgv_pred)

  [1] "SGVariants" "GRangesList"
  [3] "Paths"  "GenomicRangesList"
  [5] "CompressedRangesList"   "GenomicRanges_OR_GRangesList"
  [7] "RangesList" "CompressedList"
  [9] "GenomicRanges_OR_GenomicRangesList" "List"
[11] "Vector" "list_OR_List"
[13] "Annotated"


## example counts




counts <- matrix(1:2, ncol = 1)

## creating SummarizedExperiment object fails




SummarizedExperiment(assays = list(counts), rowRanges = sgv_pred)

class: RangedSummarizedExperiment
dim: 2 1
metadata(0):
assays(1): ''
Error in .local(object, ..., verbose) : unused argument (check = FALSE)


## works after coercing to GRangestList




SummarizedExperiment(assays = list(counts), rowRanges = as(sgv_pred,

"GRangesList"))
class: RangedSummarizedExperiment
dim: 2 1
metadata(0):
assays(1): ''
rownames: NULL
rowData names(20): from to ... variantType variantName
colnames: NULL
colData names(0):


sessionInfo()

R Under development (unstable) (2017-10-20 r73567)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.6 (Santiago)

Matrix products: default
BLAS:
/gnet/is2/p01/apps/R/3.5.0-20171105-devel/x86_64-linux-2.6-rhel6/lib64/R/lib/libRblas.so
LAPACK:
/gnet/is2/p01/apps/R/3.5.0-20171105-devel/x86_64-linux-2.6-rhel6/lib64/R/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
  [1] SGSeq_1.13.5SummarizedExperiment_1.9.16
  [3] DelayedArray_0.5.23 BiocParallel_1.13.3
  [5] matrixStats_0.53.1  Biobase_2.39.2
  [7] Rsamtools_1.31.3Biostrings_2.47.12
  [9] XVector_0.19.9  GenomicRanges_1.31.23
[11] GenomeInfoDb_1.15.5 IRanges_2.13.28
[13] S4Vectors_0.17.39   BiocGenerics_0.25.3

loaded via a namespace (and not attached):
  [1] Rcpp_0.12.16  compiler_3.5.0
  [3] GenomicFeatures_1.31.10   prettyunits_1.0.2
  [5] bitops_1.0-6  tools_3.5.0
  [7] zlibbioc_1.25.0   progress_1.1.2
  [9] biomaRt_2.35.13   digest_0.6.15
[11] bit_1.1-13RSQLite_2.1.0
[13] memoise_1.1.0 lattice_0.20-35
[15] pkgconfig_2.0.1   igraph_1.2.1
[17] Matrix_1.2-13 DBI_0.8
[19] GenomeInfoDbData_1.1.0rtracklayer_1.39.9
[21] httr_1.3.1stringr_1.3.0
[23] bit64_0.9-8   grid_3.5.0
[25] R6_2.2.2  AnnotationDbi_1.41.4
[27] XML_3.98-1.10 blob_1.1.1
[29] magrittr_1.5  GenomicAlignments_1.15.13
[31] RUnit_0.4.31  assertthat_0.2.0
[33] stringi_1.1.7 RCurl_1.95-4.10





[[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=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=qpgk0XNxCYLZKHMRS-PnHD2znDDwj1P-Eiu7P4aUSuI=qjwH7TgvfYKGtMDCI77_VVUw8S-5PA6ctju8Jb3erUQ=



--
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] New db0 annotation packages

2018-04-10 Thread Van Twisk, Daniel
Hello all!


The new db0 packages were recently pushed to 3.7 and will be available tomorrow.


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] new package IGV needs web browsers on the build machines to pass build & check

2018-04-10 Thread Paul Shannon
Many thanks, Vince! I will fix the printf and markdown errors.  
With release date now not far off, I propose (Bioc policymakers please weigh in 
if this is inadequate) to

- remove web browser communication from vignette, examples and unit tests
- evaluate stubs and/or "mocks" for possible use in a future release
- run full web browser tests on my own, separate from the bioc build

Any objections to this approach?

 - Paul


> On Apr 9, 2018, at 7:15 PM, Vincent Carey  wrote:
> 
> Thanks Paul.  Package works.  Browser visualizations look really nice.
> 
> I tried to run your unit tests and they
> use a function called "printf".  Setting printf = sprintf allowed the tests
> to all run to completion.
> 
> The following vignette chunk is problematic ... maybe you meant eval=FALSE, 
> echo=TRUE to show what the
> user needs to do?
> 
> ```{r createLoad, echo=TRUE, echo=FALSE, results='hide'}
> igv <- IGV()
> setBrowserWindowTitle(igv, "MEF2C")
> setGenome(igv, "hg19")
> ```
> 
> It does seem to me that you would need to avoid running
> the browser in tests and vignette and examples.  Using
> if (interactive()) can help with vignette and examples.
> The unit testing of such a package should I think focus
> on verifying that the essential data manipulations succeed,
> without requiring browser communication.  But others in the
> group will have more authoritative remarks on this.
> 
> I don't know whether the methods sketched in
> 
> https://stackoverflow.com/questions/15509231/unit-testing-node-js-and-websockets-socket-io
> 
> could be used in this task, to go beyond checking the basic
> R manipulations.
> 
> 
>> On Mon, Apr 9, 2018 at 8:15 PM, Paul Shannon  
>> wrote:
>> Hi Vince,
>> 
>> My dumb mistake, sorry.  Now fixed, version 0.99.9, 
>> https://github.com/paul-shannon/IGV
>> 
>> I’m looking forward to hearing your suggestions.
>> 
>>  - Paul
>> 
>> 
>> 
>> > On Apr 9, 2018, at 4:49 PM, Vincent Carey  
>> > wrote:
>> >
>> > Hi Paul -- I am trying to build your vignette but it has
>> >
>> > load("~/s/work/priceLab/AD/tbl.gwas.level_1.RData")
>> >
>> > I think it should be possible to get your package through
>> > check, but I would like to get the vignette built and
>> > check out the tests before commenting further.
>> >
>> >
>> > On Mon, Apr 9, 2018 at 1:52 PM, Paul Shannon 
>> >  wrote:
>> > > "Once your package builds and checks without errors or (avoidable) 
>> > > warnings, a Bioconductor team member will provide a technical review of 
>> > > your package. Other Bioconductor developers and users with domain 
>> > > expertise are encouraged to provide additional community commentary. 
>> > > Reviewers will add comments to the issue you created.”
>> >
>> > I don’t believe my submission, IGV, quite fits the mold.  As best I can 
>> > tell, no web browser can be summoned on any of the architectures by IGV 
>> > during build or check.  So the package build always times out.  And so, 
>> > according to the guideline quoted above, it will never be reviewed!
>> >
>> > IGV is a BrowserViz version >=2 subclass; BrowserViz was recently uprev’d 
>> > in devel.  Like RCyjs, IGV's raison d’être is the provision of R access to 
>> > interactive graphics in your web browser, in this case to Jim Robinson’s 
>> > igv.js.
>> >
>> > My analysis may be incorrect.  Can this matter receive a little attention, 
>> > despite the bioc submission guideline quoted above, in hopes that the 
>> > package can move forward?
>> >
>> > Thank you,
>> >
>> >  - Paul
>> > ___
>> > 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


[Bioc-devel] Unable to access repository

2018-04-10 Thread Clare Pacini
Hi all,

I am the maintainer for DrugVsDisease package and am trying to push new 
changes. However, I am getting the following error:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I have previously provided an ssh key for my GitHub account with username 
clarepacini and have been able to push changes previously. I am unsure as to 
what has changed/what else I need to do?

Thanks

Clare
[[alternative HTML version deleted]]

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


Re: [Bioc-devel] Update data in data package, pcxnData

2018-04-10 Thread Sokratis Kariotis
Everything seems to be fine and the 3_6 release is online. Thanks for the
help!

Cheers,
Sokratis

On 5 April 2018 at 18:41, Shepherd, Lori 
wrote:

> We are taking care of this on our end. Sorry for the confusion.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Sokratis Kariotis 
> *Sent:* Thursday, April 5, 2018 8:02:14 AM
> *To:* Shepherd, Lori
> *Cc:* Turaga, Nitesh; bioc-devel
>
> *Subject:* Re: [Bioc-devel] Update data in data package, pcxnData
>
> Hey all,
>
> The issues remain the same in both packages:
>
> https://bioconductor.org/checkResults/3.6/data-experiment-LATEST/pcxnData/
> malbec1-buildsrc.html
>
> https://bioconductor.org/checkResults/3.6/bioc-LATEST/
> pcxn/malbec1-buildsrc.html
>
> Regards,
> Sokratis
>
> On 30 March 2018 at 18:53, Shepherd, Lori 
> wrote:
>
> I believe this should clear up in a few days.  Because of the circular
> dependencies, it will require a few passes through the build system.
>
>
> For example:
>
>
> First pass:
>
> The pcxnData package has a force install, so it will get installed even
> if it fails the build and check. The pcxn package will also fail its first
> pass through.
>
>
> Second pass:
>
> the pcxn package will find the newly installed version of the pcxnData
> package and pass.  The pcxnData package will still fail
>
>
> Third pass:
>
> pcxnData will find the newly built software package and pass as will the
> linux version of the software package.
>
>
> Forth pass:
>
> May be needed for the mac and windows versions to find the new data
> package.
>
>
>
> The last update to the software package was on March 27 - which probably
> missed being pulled for the March 28th report so probably included for the
> March 29th build report
>
> March 29th  - both fail (but there was a force install behind the scenes)
>
> March 30th -  data package fails, but the linux version of the software
> package built and propagated
>
> http://bioconductor.org/checkResults/3.6/bioc-LATEST/pcxn/
> malbec1-buildsrc.html
>
>
> My guess is that by Sunday's or Monday's build reports everything will be
> okay.
>
> I will keep an eye on this to make sure its the case and please let us
> know if you still are seeing issues next week.
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Sokratis Kariotis 
> *Sent:* Thursday, March 29, 2018 6:49:47 AM
> *To:* Turaga, Nitesh
> *Cc:* Shepherd, Lori; bioc-devel
> *Subject:* Re: [Bioc-devel] Update data in data package, pcxnData
>
> Hey all,
>
> The packages' changes went through to the 3_6 branch, but since pcxn and
> pcxnData depend on each other, there are errors when they get built as they
> see the old version of the other package. In the current example:
> https://www.bioconductor.org/checkResults/3.6/bioc-
> LATEST/pcxn/malbec1-buildsrc.html , the 
> pathCor_pathprint_v1.2.3_unadjusted_frame
> file is now located in the new pcxnData package but during build the old
> pcxnData is being used and the error occurs since the file is not there. I
> have checked both packages locally and they work when both are in their
> updated form. How can we bypass this? Thanks.
>
> Cheers,
> Sokratis
>
> On 27 March 2018 at 14:02, Sokratis Kariotis 
> wrote:
>
> Hey all,
>
> Thanks for the advice. I managed to fix the problem of no permissions! My
> windows machine, after an update, changed the paths to my github keys and
> had to reposition them.  I have now succesfully pushed in both master and
> RELEASE_3_6 branches.
>
> Cheers,
> Sokratis
>
> On 26 March 2018 at 15:47, Turaga, Nitesh 
> wrote:
>
> Hi Sokratis,
>
> Your key(s) on file is
>
> ssh-rsa B3NzaC1yc2EDAQABAAABAQCmaqfMSKr3AtAPpMz5m4pITFaq6AVp
> +v8ABp7FfTvcirdZz834ECUsnlsvkLZL2uWtelNo7TFgaIo0Jfi21IDSZ3R0
> Oyl49vsYXqHAB9CtH3yItiaddq+nLG4s+jnlAftWyQOFa/02LyYwBvEnuacL
> xxZimveZ6VywBF9Q7pz3v+pGXZb9LDmK9khr6RvO+mRcD7dJyFt1CySEbxVZ
> j/TKHwn4Vs9lQIISxeeKo9ypxFzW8YDzmACLga7u2BVX622/UjrrXanZhmNW
> cEEgxw3B8rgzDZi2YcwbBG3RqXncE29a6gEvsjqJbUh5jIyk9cLunUjQpVwqrnlHXcRGjkLB
>
> ssh-rsa B3NzaC1yc2EDAQABAAABAQC9G4NrGqxmHJj26MBW4A2EJLCD8z+Q
> V5fRehTPiNzwHztQiJzj8Kakesk8FcfZt1Y3cPZRhwzyuwxiZQRrB1qidg6n
> FfLwjHBi24xLo9RWQBxTfgCDWyUKb5WLFZn6wQWhWp10ooRz0oGX9Syh6rw+
> rCiHiFwE+CxTWjELwlASiuDUa/599MBe7Q2mMVmtP4QXFyaOGsq46I16k80T
> a0YzM1bbIZlY+YFbmw8GhDrZ//z+2FJ241AR4nuTx8QJ6fXLMnfo8IgZtDxJ
> Yw3G24ZduP93Q47ptl4u5IElZzEceXN53VD1WQkphk4+SDr24Fm4qkYkQ2s5VaPk6Yh3oXYd
>
> ssh-rsa B3NzaC1yc2EDAQABAAABAQC7QB8rwK1n7/cD5rfDoZe/uSVGVqkB
> 

Re: [Bioc-devel] Update of miRBaseVersions.db annotation package

2018-04-10 Thread Stefan Haunsberger
Thanks very much, I appreciate!

On Mon, Apr 9, 2018 at 7:45 PM Van Twisk, Daniel <
daniel.vantw...@roswellpark.org> wrote:

> The package looks okay now.  I've moved the package onto our devel builder
> and it should propagate within a day or two.
> --
> *From:* Stefan Haunsberger 
> *Sent:* Saturday, April 7, 2018 9:36:02 AM
> *To:* Van Twisk, Daniel
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Update of miRBaseVersions.db annotation
> package
>
> Hi,
>
> thanks for your fast reply. I've fixed the issues and get no error
> messages when running BiocCheck.
> This is the updated version:
> https://drive.google.com/open?id=1rJcs2W5fcfc0Cq74QHfNfk0mu2xJ5JJ9
>
> Thanks and kind regards,
>
> Stefan
>
> On Fri, Apr 6, 2018 at 7:58 PM Van Twisk, Daniel <
> daniel.vantw...@roswellpark.org> wrote:
>
> I'd be happy to update your annotation package.  The package, however,
> appears to have multiple warnings and errors occurring on check and
> BiocCheck.  There appear to be some documentation issues and a test failure
> in check.  For BiocCheck, just be sure the BiocViews you are using are from
> one category, the other warning is fine.
>
>
> Please email once these issues are addressed and I can propagate the
> changes.
> --
> *From:* Bioc-devel  on behalf of Stefan
> Haunsberger 
> *Sent:* Thursday, April 5, 2018 1:39:21 PM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] Update of miRBaseVersions.db annotation package
>
> Hi everyone,
>
> I would like to update the miRBaseVersions.db annotation package in devel
> version.
> It now contains the most recent miRBase release version 22, from the 12th
> of March 2018, for mature miRNAs as well as precursor miRNAs.
>
> It can be downloaded from the following google drive repository:
>
> https://drive.google.com/file/d/1J7CFiJut-0ODDePa7oO1IY7L4JycLyX7/view?usp=sharing
>
> The most recently developed version is also available on GitHub:
> https://github.com/StefanHaunsberger/mirbaseversions.db
>
> Thanks,
>
> Stefan
>
> [[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.
>
>
> 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] vignette problems

2018-04-10 Thread Martin Morgan



On 04/10/2018 05:27 AM, campos wrote:

Hi Martin,

Thank you very much, I am a bit concerned about the option of:


Last Changed Date: 2018-04-05 09:37:37 -0400 (Thu, 05 Apr 2018)

I did a change yesterday and push it, why isn't it visible?


Notice that at the top of the build report it says

  This page was generated on 2018-04-09 09:50:05 -0400 (Mon, 09 Apr 2018).

  Snapshot Date: 2018-04-08 16:45:28 -0400 (Sun, 08 Apr 2018)

If you pushed after the snapshot date then your changes are not yet visible.

Martin



Best,

Rafa




On 09.04.2018 16:44, Martin Morgan wrote:

I'll try to provide you with a pull request addressing issues. Martin

On 04/09/2018 08:42 AM, campos wrote:

Dear devel team,

I am still puzzled with the problems with mac compiling. I am really 
lost and have no idea how to continue or how to be able to check 
about this problems with my linux machine in order to fix it faster. 
Could you please help me with that??


Best,

Rafael


On 05.04.2018 14:29, Shepherd, Lori wrote:


In order for changes to be propagated a version bump in the 
DESCRIPTION file is needed.  Please bump the version in the 
DESCRIPTION file to 2.7.2.





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 
campos 

*Sent:* Thursday, April 5, 2018 7:45:57 AM
*To:* Morgan, Martin; bioc-devel
*Subject:* Re: [Bioc-devel] vignette problems
Hey Martin,

I pushed new changes since last friday but in
https://bioconductor.org/checkResults/3.7/bioc-LATEST/STAN/ says that
the last change date was friday. Any idea what is the problem?

I have tried to fix the problems with memory and all you told me.

Best,

Rafael


On 03.04.2018 17:06, Martin Morgan wrote:
> Please use 'reply all' so that the mailing list remains engaged.
>
> Check out the release schedule
>
> http://bioconductor.org/developers/release-schedule/
>
> in particular
>
> Wednesday April 25
>
> - Deadline for packages passing ‘‘R CMD build’’ and ‘‘R CMD check’’
> without errors or warnings.
>
> so you still have time to get your package in order.
>
> Using the same techniques as before, I still see valgrind problems,
> the first being
>
> > hmm_fitted_poilog = fitHMM(trainRegions, hmm_poilog,
> sizeFactors=sizeFactors, maxIters=10)
> ==24916== Invalid write of size 4
> ==24916==    at 0x4BA93FD7:
> TransitionMatrix::updateAuxiliaries(double**, double***, double*,
> int*, int, int**, int, double, int) (TransitionMatrix.cpp:292)
> ==24916==    by 0x4BA77934: HMM::updateSampleAux(double***, int*, 
int,

> double**, double**, double**, double***, double*, int*, int*, int*,
> int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
> (HMM.cpp:771)
> ==24916==    by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
int*,

> int, int, int**, int*, int*, int*, int, int, int**, double***,
> SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
> ==24916==    by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
> ==24916==    by 0x4F2992D: R_doDotCall (dotcode.c:692)
> ==24916==    by 0x4F339D5: do_dotcall (dotcode.c:1252)
> ==24916==    by 0x4F81BA6: bcEval (eval.c:6771)
> ==24916==    by 0x4F6E963: Rf_eval (eval.c:624)
> ==24916==    by 0x4F71188: R_execClosure (eval.c:1764)
> ==24916==    by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
> ==24916==    by 0x4F6F18B: Rf_eval (eval.c:747)
> ==24916==    by 0x4F74B12: do_set (eval.c:2774)
> ==24916==  Address 0x2e73a294 is 4 bytes inside a block of size 5 
alloc'd

> ==24916==    at 0x4C2DB8F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==24916==    by 0x4BA93FA6:
> TransitionMatrix::updateAuxiliaries(double**, double***, double*,
> int*, int, int**, int, double, int) (TransitionMatrix.cpp:289)
> ==24916==    by 0x4BA77934: HMM::updateSampleAux(double***, int*, 
int,

> double**, double**, double**, double***, double*, int*, int*, int*,
> int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
> (HMM.cpp:771)
> ==24916==    by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
int*,

> int, int, int**, int*, int*, int*, int, int, int**, double***,
> SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
> ==24916==    by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
> ==24916==    by 0x4F2992D: R_doDotCall (dotcode.c:692)
> ==24916==    by 0x4F339D5: do_dotcall (dotcode.c:1252)
> ==24916==    by 0x4F81BA6: bcEval (eval.c:6771)
> ==24916==    by 0x4F6E963: Rf_eval (eval.c:624)
> ==24916==    by 0x4F71188: R_execClosure (eval.c:1764)
> ==24916==    by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
> ==24916==    by 0x4F6F18B: Rf_eval (eval.c:747)
> ==24916==
>
> This seems to be the exact same code as in the problem that you fixed
> at another location. Actually, I would guess that all of these
>
> grep 

Re: [Bioc-devel] vignette problems

2018-04-10 Thread campos
Hi Martin,

Thank you very much, I am a bit concerned about the option of:


Last�Changed�Date: 2018-04-05�09:37:37�-0400�(Thu,�05�Apr�2018)

I did a change yesterday and push it, why isn't it visible?

Best,

Rafa




On 09.04.2018 16:44, Martin Morgan wrote:
> I'll try to provide you with a pull request addressing issues. Martin
>
> On 04/09/2018 08:42 AM, campos wrote:
>> Dear devel team,
>>
>> I am still puzzled with the problems with mac compiling. I am really 
>> lost and have no idea how to continue or how to be able to check 
>> about this problems with my linux machine in order to fix it faster. 
>> Could you please help me with that??
>>
>> Best,
>>
>> Rafael
>>
>>
>> On 05.04.2018 14:29, Shepherd, Lori wrote:
>>>
>>> In order for changes to be propagated a version bump in the 
>>> DESCRIPTION file is needed.� Please bump the version in the 
>>> DESCRIPTION file to 2.7.2.
>>>
>>>
>>>
>>>
>>> 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 
>>> campos 
>>> *Sent:* Thursday, April 5, 2018 7:45:57 AM
>>> *To:* Morgan, Martin; bioc-devel
>>> *Subject:* Re: [Bioc-devel] vignette problems
>>> Hey Martin,
>>>
>>> I pushed new changes since last friday but in
>>> https://bioconductor.org/checkResults/3.7/bioc-LATEST/STAN/ says that
>>> the last change date was friday. Any idea what is the problem?
>>>
>>> I have tried to fix the problems with memory and all you told me.
>>>
>>> Best,
>>>
>>> Rafael
>>>
>>>
>>> On 03.04.2018 17:06, Martin Morgan wrote:
>>> > Please use 'reply all' so that the mailing list remains engaged.
>>> >
>>> > Check out the release schedule
>>> >
>>> > http://bioconductor.org/developers/release-schedule/
>>> >
>>> > in particular
>>> >
>>> > Wednesday April 25
>>> >
>>> > - Deadline for packages passing ��R CMD build�� and ��R CMD check��
>>> > without errors or warnings.
>>> >
>>> > so you still have time to get your package in order.
>>> >
>>> > Using the same techniques as before, I still see valgrind problems,
>>> > the first being
>>> >
>>> > > hmm_fitted_poilog = fitHMM(trainRegions, hmm_poilog,
>>> > sizeFactors=sizeFactors, maxIters=10)
>>> > ==24916== Invalid write of size 4
>>> > ==24916==��� at 0x4BA93FD7:
>>> > TransitionMatrix::updateAuxiliaries(double**, double***, double*,
>>> > int*, int, int**, int, double, int) (TransitionMatrix.cpp:292)
>>> > ==24916==��� by 0x4BA77934: HMM::updateSampleAux(double***, int*, 
>>> int,
>>> > double**, double**, double**, double***, double*, int*, int*, int*,
>>> > int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
>>> > (HMM.cpp:771)
>>> > ==24916==��� by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
>>> int*,
>>> > int, int, int**, int*, int*, int*, int, int, int**, double***,
>>> > SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
>>> > ==24916==��� by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
>>> > ==24916==��� by 0x4F2992D: R_doDotCall (dotcode.c:692)
>>> > ==24916==��� by 0x4F339D5: do_dotcall (dotcode.c:1252)
>>> > ==24916==��� by 0x4F81BA6: bcEval (eval.c:6771)
>>> > ==24916==��� by 0x4F6E963: Rf_eval (eval.c:624)
>>> > ==24916==��� by 0x4F71188: R_execClosure (eval.c:1764)
>>> > ==24916==��� by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
>>> > ==24916==��� by 0x4F6F18B: Rf_eval (eval.c:747)
>>> > ==24916==��� by 0x4F74B12: do_set (eval.c:2774)
>>> > ==24916==� Address 0x2e73a294 is 4 bytes inside a block of size 5 
>>> alloc'd
>>> > ==24916==��� at 0x4C2DB8F: malloc (in
>>> > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> > ==24916==��� by 0x4BA93FA6:
>>> > TransitionMatrix::updateAuxiliaries(double**, double***, double*,
>>> > int*, int, int**, int, double, int) (TransitionMatrix.cpp:289)
>>> > ==24916==��� by 0x4BA77934: HMM::updateSampleAux(double***, int*, 
>>> int,
>>> > double**, double**, double**, double***, double*, int*, int*, int*,
>>> > int**, double***, SEXPREC*, SEXPREC*, int, double, int, int, int)
>>> > (HMM.cpp:771)
>>> > ==24916==��� by 0x4BA7896D: HMM::BaumWelch[abi:cxx11](double***, 
>>> int*,
>>> > int, int, int**, int*, int*, int*, int, int, int**, double***,
>>> > SEXPREC*, SEXPREC*, int, double, double, int, int) (HMM.cpp:1076)
>>> > ==24916==��� by 0x4BA8FEFD: RHMMFit (RWrapper.cpp:1494)
>>> > ==24916==��� by 0x4F2992D: R_doDotCall (dotcode.c:692)
>>> > ==24916==��� by 0x4F339D5: do_dotcall (dotcode.c:1252)
>>> > ==24916==��� by 0x4F81BA6: bcEval (eval.c:6771)
>>> > ==24916==��� by 0x4F6E963: Rf_eval (eval.c:624)
>>> > ==24916==��� by 0x4F71188: R_execClosure (eval.c:1764)
>>> > ==24916==��� by 0x4F70E7C: Rf_applyClosure (eval.c:1692)
>>> > ==24916==��� by 0x4F6F18B: Rf_eval (eval.c:747)
>>> > ==24916==
>>> >
>>> > This seems to be the