date:20180409

Re: [Bioc-devel] vignette problems

2018-04-09 Thread campos

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 --color -nH -e ")\*ncores+1" *
> > HMM.cpp:784:��� int *myStateBuckets = 
> (int*)malloc(sizeof(int)*ncores+1);
> > MultivariateGaussian.cpp:295:��� int *myDimBuckets =
> > (int*)malloc(sizeof(int)*ncores+1);
> > MultivariateGaussian.cpp:475:��� int *myDimBuckets =
> > (int*)malloc(sizeof(int)*ncores+1);
> > TransitionMatrix.cpp:132:��� int *myStateBuckets =
> > (int*)malloc(sizeof(int)*ncores+1);
> > TransitionMatrix.cpp:289:��� int *myStateBuckets =
> > (int*)malloc(sizeof(int)*ncores+1);
> >
> > are the same problem. Also, usually code that has been copy/past

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

2018-04-09 Thread Ramon Diaz-Uriarte


Dear Martin,

On Fri, 06-April-2018, at 18:59:00, Martin Morgan 
 wrote:
> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>> I have recently faced a similar warning.
>> This is when a link to a help page of another package is broken (there is
>> not such help page). Although those could be false positives:
>> mclapply help page does exists in parallel package.
>> as.MAList does exists in devel limma
>
> when \link-ing to another package, from RShowDoc("R-exts") section 2.5
> the [] has to name the html help page, not the name of the function. For
> instance, `mclapply` is documented on a man page called mcdummies.Rd
> (!), so '\link[parallel:mcdummies]{nearest} would presumably not

I am confused here: as far as I can tell, there is an mclapply.html file:

http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html

In addition, when I use the \link[parallel:mcdummies] I get a warning when
testing under Linux.

On rereading section 2.5, I think \link[pkg]{foo} should work too (if there
is a foo.html file.)

Nevertheless, section 2.5 indicates that \link[pkg]{foo} and
\link[pkg:bar]{foo} are rarely needed, so I'll try to remove them (except
in those cases, covered in section 2.5, where "more than one package offers
help on a topic")



> generate the warning. Similarly \link[limma:asmalist]{as.MAList}.
>
> There are several things that still need exploration.
>
> - platform-specific (I have a vague understanding that Windows is
> special, but that might be outdated... [at least in this context...])
>

I am only getting the warnings under Windows (which lead me to think it was
windows misbehaving).


> - recent. I have to admit to changing the text of the warning with this
> commit
>
>
> https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
>
>but what I was intending to do was to change what it says, from the
> warning in release ('missing file link') to what it says, correctly, in
> devel 'file link ... does not exist and so has been treated as a topic'.
> The old text appears in release, and the new in devel, as anticipated.
> If I messed up somehow please let me know...
>
> - even with the warning, the link isn't broken in the dynamic help
> system (it might have been broken prior to my commit...).

OK, thanks.

Best,


R.


>
> Martin
>
>>
>> HTH
>>
>> On 6 April 2018 at 16:35, Vincent Carey  wrote:
>>
>>> ive seen this too apropos bigrquery on windows
>>>
>>> On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte 
>>> wrote:
>>>

 Dear All,

 Two packages I maintain are showing, in Windows, a warning during check
 with messages like

 Rd warning:
 C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/
>>> OncoSimulR/man/oncoSimulIndiv.Rd:570:
 file link 'mclapply' in package 'parallel' does not exist and so has been
 treated as a topic

 or

 Rd warning:
 C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.
>>> INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:
 file link 'as.MAList' in package 'limma' does not exist and so has been
 treated as a topic



 that I cannot reproduce under Linux and that I think are false
 positives. Is there a way to avoid this warning? As far as I can tell,
 those links really exist.

 Best,


 R.

 --
 Ramon Diaz-Uriarte
 Department of Biochemistry, Lab B-25
 Facultad de Medicina
 Universidad Autónoma de Madrid
 Arzobispo Morcillo, 4
 28029 Madrid
 Spain

 Phone: +34-91-497-2412

 Email: rdia...@gmail.com
 ramon.d...@iib.uam.es

 http://ligarto.org/rdiaz

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


--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

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

Re: [Bioc-devel] vignette problems

2018-04-09 Thread Martin Morgan


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 --color -nH -e ")\*ncores+1" *
> HMM.cpp:784:    int *myStateBuckets = 
(int*)malloc(sizeof(int)*ncores+1);

> MultivariateGaussian.cpp:295:    int *myDimBuckets =
> (int*)malloc(sizeof(int)*ncores+1);
> MultivariateGaussian.cpp:475:    int *myDimBuckets =
> (int*)malloc(sizeof(int)*ncores+1);
> TransitionMatrix.cpp:132:    int *myStateBuckets =
> (int*)malloc(sizeof(int)*ncores+1);
> TransitionMatrix.cpp:289:    int *myStateBuckets =
> (int*)malloc(sizeof(int)*ncores+1);
>
> are the same problem. Also, usually code that has been copy/pasted
> like this can instead be refactored to  a single function call, so a
> bug can be fixed in one place.

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

2018-04-09 Thread Martin Maechler

> Ramon Diaz-Uriarte 
> on Mon, 9 Apr 2018 16:51:38 +0200 writes:

> Dear Martin,

> On Fri, 06-April-2018, at 18:59:00, Martin Morgan
>  wrote:
>> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>>> I have recently faced a similar warning.  This is when a
>>> link to a help page of another package is broken (there
>>> is not such help page). Although those could be false
>>> positives: mclapply help page does exists in parallel
>>> package.  as.MAList does exists in devel limma
>> 
>> when \link-ing to another package, from
>> RShowDoc("R-exts") section 2.5 the [] has to name the
>> html help page, not the name of the function. For
>> instance, `mclapply` is documented on a man page called
>> mcdummies.Rd (!), so '\link[parallel:mcdummies]{nearest}
>> would presumably not

> I am confused here: as far as I can tell, there is an
> mclapply.html file:

> http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html

> In addition, when I use the \link[parallel:mcdummies] I
> get a warning when testing under Linux.


> On rereading section 2.5, I think \link[pkg]{foo} should
> work too (if there is a foo.html file.)

> Nevertheless, section 2.5 indicates that \link[pkg]{foo}
> and \link[pkg:bar]{foo} are rarely needed, so I'll try to
> remove them (except in those cases, covered in section
> 2.5, where "more than one package offers help on a topic")

Only on Windows, indeed,
mclapply() is just a dummy function, calling lapply() IIRC.

It is unfortunate that given the above you would be lead to use
different \link{}s if you are on Windows than on non-Win...

This would be a good question on the   R-package-devel   mailing
list.

Martin


>> generate the warning. Similarly
>> \link[limma:asmalist]{as.MAList}.
>> 
>> There are several things that still need exploration.
>> 
>> - platform-specific (I have a vague understanding that
>> Windows is special, but that might be outdated... [at
>> least in this context...])
>> 

> I am only getting the warnings under Windows (which lead
> me to think it was windows misbehaving).


>> - recent. I have to admit to changing the text of the
>> warning with this commit
>> 
>> 
>> 
https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
>> 
>> but what I was intending to do was to change what it
>> says, from the warning in release ('missing file link')
>> to what it says, correctly, in devel 'file link ... does
>> not exist and so has been treated as a topic'.  The old
>> text appears in release, and the new in devel, as
>> anticipated.  If I messed up somehow please let me
>> know...
>> 
>> - even with the warning, the link isn't broken in the
>> dynamic help system (it might have been broken prior to
>> my commit...).

> OK, thanks.

> Best,


> R.


>> 
>> Martin
>> 
>>> 
>>> HTH
>>> 
>>> On 6 April 2018 at 16:35, Vincent Carey
>>>  wrote:
>>> 
 ive seen this too apropos bigrquery on windows
 
 On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte
  wrote:
 
> 
> Dear All,
> 
> Two packages I maintain are showing, in Windows, a
> warning during check with messages like
> 
> Rd warning:
> 
C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/
 OncoSimulR/man/oncoSimulIndiv.Rd:570:
> file link 'mclapply' in package 'parallel' does not
> exist and so has been treated as a topic
> 
> or
> 
> Rd warning:
> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.
 INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:
> file link 'as.MAList' in package 'limma' does not
> exist and so has been treated as a topic
> 
> 
> 
> that I cannot reproduce under Linux and that I think
> are false positives. Is there a way to avoid this
> warning? As far as I can tell, those links really
> exist.
> 
> Best,
> 
> 
> R.
> 
> --
> Ramon Diaz-Uriarte Department of Biochemistry, Lab
> B-25 Facultad de Medicina Universidad Autónoma de
> Madrid Arzobispo Morcillo, 4 28029 Madrid Spain
> 
> Phone: +34-91-497-2412
> 
> Email: rdia...@gmail.com ramon.d...@iib.uam.es
> 
> http://ligarto.org/rdiaz
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
 
 [[alternative HTML version deleted]]
 
 ___
 Bioc-

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

2018-04-09 Thread Martin Morgan




On 04/09/2018 10:51 AM, Ramon Diaz-Uriarte wrote:


Dear Martin,

On Fri, 06-April-2018, at 18:59:00, Martin Morgan 
 wrote:

On 04/06/2018 10:44 AM, Lluís Revilla wrote:

I have recently faced a similar warning.
This is when a link to a help page of another package is broken (there is
not such help page). Although those could be false positives:
mclapply help page does exists in parallel package.
as.MAList does exists in devel limma


when \link-ing to another package, from RShowDoc("R-exts") section 2.5
the [] has to name the html help page, not the name of the function. For
instance, `mclapply` is documented on a man page called mcdummies.Rd
(!), so '\link[parallel:mcdummies]{nearest} would presumably not


I am confused here: as far as I can tell, there is an mclapply.html file:

http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html

In addition, when I use the \link[parallel:mcdummies] I get a warning when
testing under Linux.


yeah, this is a pretty good one. If you look at

  https://github.com/wch/r-source/tree/trunk/src/library/parallel/man

you'll see that there are different man pages for different operating 
systems. On windows there is mcdummies, on unix mclapply & friends. This 
seems like a bad idea (users comparing notes to work through a problem 
get different help pages!). I don't really know how to link explicitly 
to these in a conditional manner.


And in general it seems highly fragile to link to the name of the help 
page, rather than to the alias. I'd treat the 'warning' as (maybe bad) 
advice, rather than a requirement.



On rereading section 2.5, I think \link[pkg]{foo} should work too (if there
is a foo.html file.)


it does (but on windows there is no mclapply.html). But also on windows 
the '...treated as a topic' part of the warning actually indicates that 
R has figured out where it should link, so you get the warning but also 
a working link.



Nevertheless, section 2.5 indicates that \link[pkg]{foo} and
\link[pkg:bar]{foo} are rarely needed, so I'll try to remove them (except
in those cases, covered in section 2.5, where "more than one package offers
help on a topic")


yes the first pass should also be the simplest -- no fancy markup unless 
necessary.


Martin





generate the warning. Similarly \link[limma:asmalist]{as.MAList}.

There are several things that still need exploration.

- platform-specific (I have a vague understanding that Windows is
special, but that might be outdated... [at least in this context...])



I am only getting the warnings under Windows (which lead me to think it was
windows misbehaving).



- recent. I have to admit to changing the text of the warning with this
commit


https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e

but what I was intending to do was to change what it says, from the
warning in release ('missing file link') to what it says, correctly, in
devel 'file link ... does not exist and so has been treated as a topic'.
The old text appears in release, and the new in devel, as anticipated.
If I messed up somehow please let me know...

- even with the warning, the link isn't broken in the dynamic help
system (it might have been broken prior to my commit...).


OK, thanks.

Best,


R.




Martin



HTH

On 6 April 2018 at 16:35, Vincent Carey  wrote:


ive seen this too apropos bigrquery on windows

On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte 
wrote:



Dear All,

Two packages I maintain are showing, in Windows, a warning during check
with messages like

Rd warning:
C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/

OncoSimulR/man/oncoSimulIndiv.Rd:570:

file link 'mclapply' in package 'parallel' does not exist and so has been
treated as a topic

or

Rd warning:
C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.

INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:

file link 'as.MAList' in package 'limma' does not exist and so has been
treated as a topic



that I cannot reproduce under Linux and that I think are false
positives. Is there a way to avoid this warning? As far as I can tell,
those links really exist.

Best,


R.

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
 ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

___
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



[[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...{{drop

[Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

2018-04-09 Thread Paul Shannon

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

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

2018-04-09 Thread Van Twisk, Daniel

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 
mailto: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 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Stefan Haunsberger 
mailto:stefan.haunsber...@gmail.com>>
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] new package IGV needs web browsers on the build machines to pass build & check

2018-04-09 Thread Vincent Carey

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 <
paul.thurmond.shan...@gmail.com> 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

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

2018-04-09 Thread Paul Shannon

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
> 

___
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-09 Thread Vincent Carey

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 <
> paul.thurmond.shan...@gmail.com> 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

Re: [Bioc-devel] vignette problems

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

Re: [Bioc-devel] vignette problems

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

[Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

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

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

10 matches

Site Navigation

Mail list logo

Footer information