Re: [Bioc-devel] Quick question about result of R CMD check and R CMD BiocCheck

[Jurat Shayidin]

Dear Lori :

Thanks for this useful link. I tried dplyr underscore command  separate_,
mutate_ in my implementation,but I got vignette error as follows :

vignette.Rmd' failed with diagnostics: object 'cn' not found. Execution
halted

So I tried another approach that suggested in stackoverflow, I used
utils::globalVariables() at the end of my function :

utils::globalVariables (c ("cn", "p.value", ".", "peakStringency",
"original_list", "n", "Replicate","output"))

but now I got building error as follows:

Error: processing vignette 'MSPC-User-Guide.Rmd' failed with diagnostics:
The namespace for package "MSPC" is locked; no changes in the global
variables list may be made.
Execution halted



I don't know what to do on this R CMD check NOTE. Could you give me
possible solution on this problem ? How can I avoid this issue ? Any
further solution please ? Thank you very much.

Best regards :

Jurat

On Fri, Dec 16, 2016 at 3:15 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> This might be a helpful link
>
> https://cran.r-project.org/web/packages/dplyr/vignettes/nse.html
> Standard Evaluation vs. Non-Standard Evaluation
> 
> cran.r-project.org
> Standard evaluation basics. Every function in dplyr that uses NSE also has
> a version that uses SE. The name of the SE version is always the NSE name
> with an _ on the end.
>
> and also see the help page in R:   ?globalVariables
>
>
>
> I would ignore the Rmarkdown warning for now if your output is getting
> created correctly and it does not appear in the other checks.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Jurat Shayidin 
> *Sent:* Friday, December 16, 2016 8:51:43 AM
>
> *To:* Shepherd, Lori; bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Quick question about result of R CMD check
> and R CMD BiocCheck
>
> Dear Lori :
>
> Thanks again for your prompt respond. I corrected my mistake, now
> Reference can be printed out. However, R CMD check raised one NOTE, how can
> I fix this ? I've searched related question in stackoverflow and tried
> given solution, but it cause error instead. How can I possibly get rid of
> this NOTE ? Could you give me idea to address this problem please?
>
> Plus, R markdown report warnings but that doesn't effect output of package
> vignette, even R CMD check, and R CMD BiocCheck didn't report this as a
> warning . Should I ignore this ? Thank you very much
>
> Best regards :
> Jurat
>
> On Fri, Dec 16, 2016 at 2:09 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>>
>> You should change the references in your vignette MSPC-User-Guide.Rmd not
>> in the bibliography.bib file.  In your vignette, use the tag not the title;
>> so as an example:
>>
>>  [@ Using combined evidence from replicates to evaluate ChIP-seq peaks.]
>>
>> would become [@Vahid_Jalili_MSPC_2015]
>>
>>
>>
>> Once you submit your package to Bioconductor, a reviewer will be assigned
>> to formally review your package and advise on additional changes.
>>
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Jurat Shayidin 
>> *Sent:* Friday, December 16, 2016 6:06:41 AM
>> *To:* Shepherd, Lori; bioc-devel@r-project.org
>> *Subject:* Re: [Bioc-devel] Quick question about result of R CMD check
>> and R CMD BiocCheck
>>
>> Dear Lori:
>>
>> Thanks for your respond on my question. I fixed the error from unit test.
>> I tried to edit the tag on bibliography.bib file, but Rstudio still did not
>> print that out. Why is that?
>>
>> R CMD check report only one Notes when I tried to generate stack bar plot
>> for my output set by using ggplot2 packages, this note also appeared in R
>> CMD BiocCheck. I really don't know how to get rid of this note. Any idea
>> please ? How to remove this note ? Should I suppress this? Here is note
>> that raised by R CMD check :
>>
>> Undefined global functions or variables:
>>   . Replicate cn mcols<- n original_list output p.value peakStringency
>>
>> plus, I've used tidyr package to categorize my intermediate output in
>> order to get desired result, but when I execute .Rmd files, it gaves
>> warning, that didn't appeared in R CMD check, R CMD BiocCheck. Because R
>> CMD check, R CMD BiocCheck never report this as a warning. Should I keep
>> aside this ? R markdown report this warning :
>>
>> Warning messages:
>> 1: Too many values at 158 locations: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
>> 12, 13, 14, 15, 16, 17, 18, 19, 20, ...
>>
>>
>> What possible changes I might to do on my package before issuing package
>> submission? Thank you very 

Re: [Rd] syntax difference clusterExport in parallel and snow

[Hervé Pagès]

On 12/13/2016 09:33 AM, Prof Brian Ripley wrote:

On 13/12/2016 17:05, Paul Johnson wrote:

We got some errors and eventually figured out that
parallel::clusterExport second argument is "varlist" while in
snow::clusterExport it is "list".

The user had loaded parallel first, but did something else which
inadvertently loaded snow, then clusterExport failed because we had
"varlist" and not "list".

Are these different on purpose?


Yes.

('list' is an unhelpful name for an argument that is not a list.)




Yes 'list' is a misleading name for a character vector. OTOH I guess
snow::clusterExport() was just following the lead of base::save() and
base::remove() on this.

I don't see 'varlist' as being much less confusing though: it still
suggests that the thing is a list and parallel::clusterExport() is
now inconsistent with snow::clusterExport(). So it doesn't really
address the 1st problem and introduces a new one. Sounds like using
a plural form instead of the "list" prefix would be less confusing
e.g. 'vars', 'varnames', 'objnames' or something like that.

H.

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Gábor Csárdi]

I think that this problem is actually more general than just ABI
versioning. The common definition of ABI refers to compiled code, but
with R packages similar problems might happen (and they to happen)
without any compiled code.

I think the key issue is the concept of build-time dependencies. While
R packages usually does not distinguish between build-time and
run-time dependencies, they still do exist, and I think ideally we
would need to treat them differently.

AFAIK LinkingTo is the only form of a build-time dependency, that is
completely explicit, so it is relatively easy to handle. The other
frequent of build-time dependency is a function call to the other
package, that happens at install time. E.g. with references or R6*
classes you frequently include code like this in yourpackage:

myclass <- R6::R6Class(...)

and this code is evaluated at install time. So if the R6 package is
updated, the installed version myclass in yourpackage is not affected
at all. In fact, if the new version of R6 is not compatible with the
myclass object created by the old version, then yourpackage will be
broken. (This AFAIK cannot happen with R6, so it is not the best
example, but it can happen in other similar cases.)

The key here is that R6 is a build-time dependency of yourpackage,
similarly to packages linking to (i.e. LinkingTo) Rpp.

Another possible type of build-time dependency is if you put objects
from another package in yourpackage. E.g.

myfun <- otherpkg::fun

Then a copy of otherpkg::fun will be saved in yourpackage. If you
install a new version of otherpkg, yourpackage is unaffected, and if
otherpkg::fun uses some (possibly internal) API from otherpkg, that
has changed in the new version of otherpkg, you might easily end up
with a broken yourpackage again.

I think one lesson is to avoid running code at install time. This is
not a new thing, AFAIR it is even mentioned in 'Writing R extensions'.
Instead of running code at install time, you might consider running it
in `.onLoad()`, and then these "problems" go away. But you obviously
cannot always avoid it.

Gabor

* I think the R6 package is great, and I am not speaking in any way
against it. I just needed an example, and I know R6 much better than
reference classes, or other similar packages.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Duncan Murdoch]

On 16/12/2016 12:35 PM, Karl Millar wrote:

A couple of points:
  - rebuilding dependent packages is needed if there is an ABI change,
not just an API change.  For packages like Rcpp which export inline
functions or macros that might have changed, this is potentially any
change to existing functions, but for packages like Matrix, it isn't
really an issue at all IIUC.


This is why someone else needs to do this, not me.  I know the three 
words that ABI stands for, but not what they mean in practice.




  - If we're looking into a way to check if package APIs are
compatible, then that's something that's relevant for all packages,
since they all export an R API.  I believe that CRAN only tests
package compatibility with the most recent versions of packages on
CRAN that import or depend on it.  There's no guarantee that a package
update won't contain API or behaviour changes that breaks older
versions of packages, packages not on CRAN or any scripts that use the
package, and these sorts of breakages do happen semi-regularly.


That's correct.


 - AFAICT, the only difference with packages like Rcpp is that you can
potentially have all of your CRAN packages at the latest version, but
some of them might have inlined code from an older version of Rcpp
even after running update.packages().  While that is an issue, in my
experience that's been a lot less trouble than the general case of
backwards compatibility.


I think that's an important difference.  Package authors can play nicely 
with each other and keep their sources completely compatible, and 
package users can still end up with broken libraries that aren't fixed 
by anything simpler than re-installing everything.


We do have (imperfect) processes in place to help with the general 
compatibility problem, but nothing to help with this one.


Duncan Murdoch



Karl

On Fri, Dec 16, 2016 at 8:19 AM, Dirk Eddelbuettel  wrote:


On 16 December 2016 at 11:00, Duncan Murdoch wrote:
| On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:
| > On 16 December 2016 at 10:14, Duncan Murdoch wrote:
| > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
| > | >
| > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| > | > | Perhaps the solution is to recommend that packages which export their
| > | > | C-level entry points either guarantee them not to change or offer
| > | > | (require?) version checks by user code.  So dplyr should start out by
| > | > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| > | > | with a compatible interface, it replies "that's fine".  If Rcpp has
| > | > | changed its interface, it says "Sorry, I don't support that any more."
| > | >
| > | > We try. But it's hard, and I'd argue, likely impossible.
| > | >
| > | > For example I even added a "frozen" package [1] in the sources / unit 
tests
| > | > to test for just this. In practice you just cannot hit every possible 
access
| > | > point of the (rich, in our case) API so the tests pass too often.
| > | >
| > | > Which is why we relentlessly test against reverse-depends to _at least 
ensure
| > | > buildability_ from our releases.
| >
| > I meant to also add:  "... against a large corpus of other packages."
| > The intent is to empirically answer this.
| >
| > | > As for seamless binary upgrade, I don't think in can work in practice.  
Ask
| > | > Uwe one day we he rebuilds everything every time on Windows. And for 
what it
| > | > is worth, we essentially do the same in Debian.
| > | >
| > | > Sometimes you just need to rebuild.  That may be the price of admission 
for
| > | > using the convenience of rich C++ interfaces.
| > | >
| > |
| > | Okay, so would you say that Kirill's suggestion is not overkill?  Every
| > | time package B uses LinkingTo: A, R should assume it needs to rebuild B
| > | when A is updated?
| >
| > Based on my experience is a "halting problem" -- i.e. cannot know ex ante.
| >
| > So "every time" would be overkill to me.  Sometimes you know you must
| > recompile (but try to be very prudent with public-facing API).  Many times
| > you do not. It is hard to pin down.
| >
| > At work we have a bunch of servers with Rcpp and many packages against them
| > (installed system-wide for all users). We _very really_ needs rebuild.

Edit:  "We _very rarely_ need rebuilds" is what was meant there.

| So that comes back to my suggestion:  you should provide a way for a
| dependent package to ask if your API has changed.  If you say it hasn't,
| the package is fine.  If you say it has, the package should abort,
| telling the user they need to reinstall it.  (Because it's a hard
| question to answer, you might get it wrong and say it's fine when it's
| not.  But that's easy to fix:  just make a new release that does require

Sure.

We have always increased the higher-order version number when that is needed.

One problem with your proposal is that the testing code may run after the
package load, and in the case where it matters ... that 

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Karl Millar via R-devel]

A couple of points:
  - rebuilding dependent packages is needed if there is an ABI change,
not just an API change.  For packages like Rcpp which export inline
functions or macros that might have changed, this is potentially any
change to existing functions, but for packages like Matrix, it isn't
really an issue at all IIUC.

  - If we're looking into a way to check if package APIs are
compatible, then that's something that's relevant for all packages,
since they all export an R API.  I believe that CRAN only tests
package compatibility with the most recent versions of packages on
CRAN that import or depend on it.  There's no guarantee that a package
update won't contain API or behaviour changes that breaks older
versions of packages, packages not on CRAN or any scripts that use the
package, and these sorts of breakages do happen semi-regularly.

 - AFAICT, the only difference with packages like Rcpp is that you can
potentially have all of your CRAN packages at the latest version, but
some of them might have inlined code from an older version of Rcpp
even after running update.packages().  While that is an issue, in my
experience that's been a lot less trouble than the general case of
backwards compatibility.

Karl

On Fri, Dec 16, 2016 at 8:19 AM, Dirk Eddelbuettel  wrote:
>
> On 16 December 2016 at 11:00, Duncan Murdoch wrote:
> | On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:
> | > On 16 December 2016 at 10:14, Duncan Murdoch wrote:
> | > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
> | > | >
> | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
> | > | > | Perhaps the solution is to recommend that packages which export 
> their
> | > | > | C-level entry points either guarantee them not to change or offer
> | > | > | (require?) version checks by user code.  So dplyr should start out 
> by
> | > | > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
> | > | > | with a compatible interface, it replies "that's fine".  If Rcpp has
> | > | > | changed its interface, it says "Sorry, I don't support that any 
> more."
> | > | >
> | > | > We try. But it's hard, and I'd argue, likely impossible.
> | > | >
> | > | > For example I even added a "frozen" package [1] in the sources / unit 
> tests
> | > | > to test for just this. In practice you just cannot hit every possible 
> access
> | > | > point of the (rich, in our case) API so the tests pass too often.
> | > | >
> | > | > Which is why we relentlessly test against reverse-depends to _at 
> least ensure
> | > | > buildability_ from our releases.
> | >
> | > I meant to also add:  "... against a large corpus of other packages."
> | > The intent is to empirically answer this.
> | >
> | > | > As for seamless binary upgrade, I don't think in can work in 
> practice.  Ask
> | > | > Uwe one day we he rebuilds everything every time on Windows. And for 
> what it
> | > | > is worth, we essentially do the same in Debian.
> | > | >
> | > | > Sometimes you just need to rebuild.  That may be the price of 
> admission for
> | > | > using the convenience of rich C++ interfaces.
> | > | >
> | > |
> | > | Okay, so would you say that Kirill's suggestion is not overkill?  Every
> | > | time package B uses LinkingTo: A, R should assume it needs to rebuild B
> | > | when A is updated?
> | >
> | > Based on my experience is a "halting problem" -- i.e. cannot know ex ante.
> | >
> | > So "every time" would be overkill to me.  Sometimes you know you must
> | > recompile (but try to be very prudent with public-facing API).  Many times
> | > you do not. It is hard to pin down.
> | >
> | > At work we have a bunch of servers with Rcpp and many packages against 
> them
> | > (installed system-wide for all users). We _very really_ needs rebuild.
>
> Edit:  "We _very rarely_ need rebuilds" is what was meant there.
>
> | So that comes back to my suggestion:  you should provide a way for a
> | dependent package to ask if your API has changed.  If you say it hasn't,
> | the package is fine.  If you say it has, the package should abort,
> | telling the user they need to reinstall it.  (Because it's a hard
> | question to answer, you might get it wrong and say it's fine when it's
> | not.  But that's easy to fix:  just make a new release that does require
>
> Sure.
>
> We have always increased the higher-order version number when that is needed.
>
> One problem with your proposal is that the testing code may run after the
> package load, and in the case where it matters ... that very code may not get
> reached because the package didn't load.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Kirill Müller]

Thanks for discussing this.

On 16.12.2016 17:19, Dirk Eddelbuettel wrote:

On 16 December 2016 at 11:00, Duncan Murdoch wrote:
| On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:
| > On 16 December 2016 at 10:14, Duncan Murdoch wrote:
| > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
| > | >
| > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| > | > | Perhaps the solution is to recommend that packages which export their
| > | > | C-level entry points either guarantee them not to change or offer
| > | > | (require?) version checks by user code.  So dplyr should start out by
| > | > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| > | > | with a compatible interface, it replies "that's fine".  If Rcpp has
| > | > | changed its interface, it says "Sorry, I don't support that any more."
Sounds good to me, I was considering something similar. dplyr can simply 
query Rcpp's current version in .onLoad(), compare it to the version at 
installation time and act accordingly.

| > | >
| > | > We try. But it's hard, and I'd argue, likely impossible.
| > | >
| > | > For example I even added a "frozen" package [1] in the sources / unit 
tests
| > | > to test for just this. In practice you just cannot hit every possible 
access
| > | > point of the (rich, in our case) API so the tests pass too often.
| > | >
| > | > Which is why we relentlessly test against reverse-depends to _at least 
ensure
| > | > buildability_ from our releases.
| >
| > I meant to also add:  "... against a large corpus of other packages."
| > The intent is to empirically answer this.
| >
| > | > As for seamless binary upgrade, I don't think in can work in practice.  
Ask
| > | > Uwe one day we he rebuilds everything every time on Windows. And for 
what it
| > | > is worth, we essentially do the same in Debian.
| > | >
| > | > Sometimes you just need to rebuild.  That may be the price of admission 
for
| > | > using the convenience of rich C++ interfaces.
| > | >
| > |
| > | Okay, so would you say that Kirill's suggestion is not overkill?  Every
| > | time package B uses LinkingTo: A, R should assume it needs to rebuild B
| > | when A is updated?
| >
| > Based on my experience is a "halting problem" -- i.e. cannot know ex ante.
| >
| > So "every time" would be overkill to me.  Sometimes you know you must
| > recompile (but try to be very prudent with public-facing API).  Many times
| > you do not. It is hard to pin down.
I'd argue that recompiling/reinstalling B is cheap enough and the safest 
option. So unless there is a risk, why not simply do it every time A 
updates? This could be implemented with a perhaps small change in R: 
When installing A, treat all packages that have A in both LinkingTo and 
Imports as dependencies that need to be reinstalled.



-Kirill

| >
| > At work we have a bunch of servers with Rcpp and many packages against them
| > (installed system-wide for all users). We _very really_ needs rebuild.

Edit:  "We _very rarely_ need rebuilds" is what was meant there.
  
| So that comes back to my suggestion:  you should provide a way for a

| dependent package to ask if your API has changed.  If you say it hasn't,
| the package is fine.  If you say it has, the package should abort,
| telling the user they need to reinstall it.  (Because it's a hard
| question to answer, you might get it wrong and say it's fine when it's
| not.  But that's easy to fix:  just make a new release that does require

Sure.

We have always increased the higher-order version number when that is needed.

One problem with your proposal is that the testing code may run after the
package load, and in the case where it matters ... that very code may not get
reached because the package didn't load.

Dirk



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Dirk Eddelbuettel]

On 16 December 2016 at 11:00, Duncan Murdoch wrote:
| On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:
| > On 16 December 2016 at 10:14, Duncan Murdoch wrote:
| > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
| > | >
| > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| > | > | Perhaps the solution is to recommend that packages which export their
| > | > | C-level entry points either guarantee them not to change or offer
| > | > | (require?) version checks by user code.  So dplyr should start out by
| > | > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| > | > | with a compatible interface, it replies "that's fine".  If Rcpp has
| > | > | changed its interface, it says "Sorry, I don't support that any more."
| > | >
| > | > We try. But it's hard, and I'd argue, likely impossible.
| > | >
| > | > For example I even added a "frozen" package [1] in the sources / unit 
tests
| > | > to test for just this. In practice you just cannot hit every possible 
access
| > | > point of the (rich, in our case) API so the tests pass too often.
| > | >
| > | > Which is why we relentlessly test against reverse-depends to _at least 
ensure
| > | > buildability_ from our releases.
| >
| > I meant to also add:  "... against a large corpus of other packages."
| > The intent is to empirically answer this.
| >
| > | > As for seamless binary upgrade, I don't think in can work in practice.  
Ask
| > | > Uwe one day we he rebuilds everything every time on Windows. And for 
what it
| > | > is worth, we essentially do the same in Debian.
| > | >
| > | > Sometimes you just need to rebuild.  That may be the price of admission 
for
| > | > using the convenience of rich C++ interfaces.
| > | >
| > |
| > | Okay, so would you say that Kirill's suggestion is not overkill?  Every
| > | time package B uses LinkingTo: A, R should assume it needs to rebuild B
| > | when A is updated?
| >
| > Based on my experience is a "halting problem" -- i.e. cannot know ex ante.
| >
| > So "every time" would be overkill to me.  Sometimes you know you must
| > recompile (but try to be very prudent with public-facing API).  Many times
| > you do not. It is hard to pin down.
| >
| > At work we have a bunch of servers with Rcpp and many packages against them
| > (installed system-wide for all users). We _very really_ needs rebuild.

Edit:  "We _very rarely_ need rebuilds" is what was meant there.
 
| So that comes back to my suggestion:  you should provide a way for a 
| dependent package to ask if your API has changed.  If you say it hasn't, 
| the package is fine.  If you say it has, the package should abort, 
| telling the user they need to reinstall it.  (Because it's a hard 
| question to answer, you might get it wrong and say it's fine when it's 
| not.  But that's easy to fix:  just make a new release that does require 

Sure.

We have always increased the higher-order version number when that is needed.

One problem with your proposal is that the testing code may run after the
package load, and in the case where it matters ... that very code may not get
reached because the package didn't load.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Duncan Murdoch]

On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:

On 16 December 2016 at 10:14, Duncan Murdoch wrote:
| On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
| >
| > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| > | Perhaps the solution is to recommend that packages which export their
| > | C-level entry points either guarantee them not to change or offer
| > | (require?) version checks by user code.  So dplyr should start out by
| > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| > | with a compatible interface, it replies "that's fine".  If Rcpp has
| > | changed its interface, it says "Sorry, I don't support that any more."
| >
| > We try. But it's hard, and I'd argue, likely impossible.
| >
| > For example I even added a "frozen" package [1] in the sources / unit tests
| > to test for just this. In practice you just cannot hit every possible access
| > point of the (rich, in our case) API so the tests pass too often.
| >
| > Which is why we relentlessly test against reverse-depends to _at least 
ensure
| > buildability_ from our releases.

I meant to also add:  "... against a large corpus of other packages."
The intent is to empirically answer this.

| > As for seamless binary upgrade, I don't think in can work in practice.  Ask
| > Uwe one day we he rebuilds everything every time on Windows. And for what it
| > is worth, we essentially do the same in Debian.
| >
| > Sometimes you just need to rebuild.  That may be the price of admission for
| > using the convenience of rich C++ interfaces.
| >
|
| Okay, so would you say that Kirill's suggestion is not overkill?  Every
| time package B uses LinkingTo: A, R should assume it needs to rebuild B
| when A is updated?

Based on my experience is a "halting problem" -- i.e. cannot know ex ante.

So "every time" would be overkill to me.  Sometimes you know you must
recompile (but try to be very prudent with public-facing API).  Many times
you do not. It is hard to pin down.

At work we have a bunch of servers with Rcpp and many packages against them
(installed system-wide for all users). We _very really_ needs rebuild.


So that comes back to my suggestion:  you should provide a way for a 
dependent package to ask if your API has changed.  If you say it hasn't, 
the package is fine.  If you say it has, the package should abort, 
telling the user they need to reinstall it.  (Because it's a hard 
question to answer, you might get it wrong and say it's fine when it's 
not.  But that's easy to fix:  just make a new release that does require 
a rebuild.)


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Dirk Eddelbuettel]

On 16 December 2016 at 10:14, Duncan Murdoch wrote:
| On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
| >
| > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| > | Perhaps the solution is to recommend that packages which export their
| > | C-level entry points either guarantee them not to change or offer
| > | (require?) version checks by user code.  So dplyr should start out by
| > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| > | with a compatible interface, it replies "that's fine".  If Rcpp has
| > | changed its interface, it says "Sorry, I don't support that any more."
| >
| > We try. But it's hard, and I'd argue, likely impossible.
| >
| > For example I even added a "frozen" package [1] in the sources / unit tests
| > to test for just this. In practice you just cannot hit every possible access
| > point of the (rich, in our case) API so the tests pass too often.
| >
| > Which is why we relentlessly test against reverse-depends to _at least 
ensure
| > buildability_ from our releases.

I meant to also add:  "... against a large corpus of other packages."
The intent is to empirically answer this.

| > As for seamless binary upgrade, I don't think in can work in practice.  Ask
| > Uwe one day we he rebuilds everything every time on Windows. And for what it
| > is worth, we essentially do the same in Debian.
| >
| > Sometimes you just need to rebuild.  That may be the price of admission for
| > using the convenience of rich C++ interfaces.
| >
| 
| Okay, so would you say that Kirill's suggestion is not overkill?  Every 
| time package B uses LinkingTo: A, R should assume it needs to rebuild B 
| when A is updated?

Based on my experience is a "halting problem" -- i.e. cannot know ex ante.

So "every time" would be overkill to me.  Sometimes you know you must
recompile (but try to be very prudent with public-facing API).  Many times
you do not. It is hard to pin down.

At work we have a bunch of servers with Rcpp and many packages against them
(installed system-wide for all users). We _very really_ needs rebuild.  

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Duncan Murdoch]

On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:


On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| Perhaps the solution is to recommend that packages which export their
| C-level entry points either guarantee them not to change or offer
| (require?) version checks by user code.  So dplyr should start out by
| saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
| with a compatible interface, it replies "that's fine".  If Rcpp has
| changed its interface, it says "Sorry, I don't support that any more."

We try. But it's hard, and I'd argue, likely impossible.

For example I even added a "frozen" package [1] in the sources / unit tests
to test for just this. In practice you just cannot hit every possible access
point of the (rich, in our case) API so the tests pass too often.

Which is why we relentlessly test against reverse-depends to _at least ensure
buildability_ from our releases.

As for seamless binary upgrade, I don't think in can work in practice.  Ask
Uwe one day we he rebuilds everything every time on Windows. And for what it
is worth, we essentially do the same in Debian.

Sometimes you just need to rebuild.  That may be the price of admission for
using the convenience of rich C++ interfaces.



Okay, so would you say that Kirill's suggestion is not overkill?  Every 
time package B uses LinkingTo: A, R should assume it needs to rebuild B 
when A is updated?


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Quick question about result of R CMD check and R CMD BiocCheck

[Shepherd, Lori]

This might be a helpful link

https://cran.r-project.org/web/packages/dplyr/vignettes/nse.html

Standard Evaluation vs. Non-Standard 
Evaluation
cran.r-project.org
Standard evaluation basics. Every function in dplyr that uses NSE also has a 
version that uses SE. The name of the SE version is always the NSE name with an 
_ on the end.


and also see the help page in R:   ?globalVariables



I would ignore the Rmarkdown warning for now if your output is getting created 
correctly and it does not appear in the other checks.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Jurat Shayidin 
Sent: Friday, December 16, 2016 8:51:43 AM
To: Shepherd, Lori; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Quick question about result of R CMD check and R CMD 
BiocCheck

Dear Lori :

Thanks again for your prompt respond. I corrected my mistake, now Reference can 
be printed out. However, R CMD check raised one NOTE, how can I fix this ? I've 
searched related question in stackoverflow and tried given solution, but it 
cause error instead. How can I possibly get rid of this NOTE ? Could you give 
me idea to address this problem please?

Plus, R markdown report warnings but that doesn't effect output of package 
vignette, even R CMD check, and R CMD BiocCheck didn't report this as a warning 
. Should I ignore this ? Thank you very much

Best regards :
Jurat

On Fri, Dec 16, 2016 at 2:09 PM, Shepherd, Lori 
> wrote:


You should change the references in your vignette MSPC-User-Guide.Rmd not in 
the bibliography.bib file.  In your vignette, use the tag not the title; so as 
an example:

 [@ Using combined evidence from replicates to evaluate ChIP-seq peaks.]

would become [@Vahid_Jalili_MSPC_2015]



Once you submit your package to Bioconductor, a reviewer will be assigned to 
formally review your package and advise on additional changes.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Jurat Shayidin >
Sent: Friday, December 16, 2016 6:06:41 AM
To: Shepherd, Lori; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Quick question about result of R CMD check and R CMD 
BiocCheck

Dear Lori:

Thanks for your respond on my question. I fixed the error from unit test. I 
tried to edit the tag on bibliography.bib file, but Rstudio still did not print 
that out. Why is that?

R CMD check report only one Notes when I tried to generate stack bar plot for 
my output set by using ggplot2 packages, this note also appeared in R CMD 
BiocCheck. I really don't know how to get rid of this note. Any idea please ? 
How to remove this note ? Should I suppress this? Here is note that raised by R 
CMD check :

Undefined global functions or variables:
  . Replicate cn mcols<- n original_list output p.value peakStringency

plus, I've used tidyr package to categorize my intermediate output in order to 
get desired result, but when I execute .Rmd files, it gaves warning, that 
didn't appeared in R CMD check, R CMD BiocCheck. Because R CMD check, R CMD 
BiocCheck never report this as a warning. Should I keep aside this ? R markdown 
report this warning :

Warning messages:
1: Too many values at 158 locations: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15, 16, 17, 18, 19, 20, ...

What possible changes I might to do on my package before issuing package 
submission? Thank you very much.

Best regards :

Jurat



On Thu, Dec 15, 2016 at 2:36 PM, Shepherd, Lori 
> wrote:

$error
[1] "At least 80% of man pages documenting exported objects must have
runnable examples. The following pages do not:"

This ERROR occurs when man pages are included without runnable examples.  You 
have examples in it looks like 5/12 of your man pages (~42%). We encourage 80%

$warning
[1] "Add non-empty \\value sections to the following man pages:
man/filterBycombStringency.Rd"

Most man pages encourage a \value{} section describing the output of the 
function or what would be returned.  This is asking that you add this section 
to this specific man page with information about what the function returns.


On quick glance I think you would cite the references in the bibliography with 
the tag
Vahid_Jalili_MSPC_2015  not the title "Using combined evidence from replicates 
to evaluate ChIP-seq peaks"




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

Re: [Bioc-devel] Quick question about result of R CMD check and R CMD BiocCheck

[Jurat Shayidin]

Dear Lori :

Thanks again for your prompt respond. I corrected my mistake, now Reference
can be printed out. However, R CMD check raised one NOTE, how can I fix
this ? I've searched related question in stackoverflow and tried given
solution, but it cause error instead. How can I possibly get rid of this
NOTE ? Could you give me idea to address this problem please?

Plus, R markdown report warnings but that doesn't effect output of package
vignette, even R CMD check, and R CMD BiocCheck didn't report this as a
warning . Should I ignore this ? Thank you very much

Best regards :
Jurat

On Fri, Dec 16, 2016 at 2:09 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

>
> You should change the references in your vignette MSPC-User-Guide.Rmd not
> in the bibliography.bib file.  In your vignette, use the tag not the title;
> so as an example:
>
>  [@ Using combined evidence from replicates to evaluate ChIP-seq peaks.]
>
> would become [@Vahid_Jalili_MSPC_2015]
>
>
>
> Once you submit your package to Bioconductor, a reviewer will be assigned
> to formally review your package and advise on additional changes.
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Jurat Shayidin 
> *Sent:* Friday, December 16, 2016 6:06:41 AM
> *To:* Shepherd, Lori; bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Quick question about result of R CMD check
> and R CMD BiocCheck
>
> Dear Lori:
>
> Thanks for your respond on my question. I fixed the error from unit test.
> I tried to edit the tag on bibliography.bib file, but Rstudio still did not
> print that out. Why is that?
>
> R CMD check report only one Notes when I tried to generate stack bar plot
> for my output set by using ggplot2 packages, this note also appeared in R
> CMD BiocCheck. I really don't know how to get rid of this note. Any idea
> please ? How to remove this note ? Should I suppress this? Here is note
> that raised by R CMD check :
>
> Undefined global functions or variables:
>   . Replicate cn mcols<- n original_list output p.value peakStringency
>
> plus, I've used tidyr package to categorize my intermediate output in
> order to get desired result, but when I execute .Rmd files, it gaves
> warning, that didn't appeared in R CMD check, R CMD BiocCheck. Because R
> CMD check, R CMD BiocCheck never report this as a warning. Should I keep
> aside this ? R markdown report this warning :
>
> Warning messages:
> 1: Too many values at 158 locations: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
> 12, 13, 14, 15, 16, 17, 18, 19, 20, ...
>
>
> What possible changes I might to do on my package before issuing package
> submission? Thank you very much.
>
> Best regards :
>
> Jurat
>
>
>
> On Thu, Dec 15, 2016 at 2:36 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>> $error
>> [1] "At least 80% of man pages documenting exported objects must have
>> runnable examples. The following pages do not:"
>>
>> This ERROR occurs when man pages are included without runnable examples.
>> You have examples in it looks like 5/12 of your man pages (~42%). We
>> encourage 80%
>>
>> $warning
>> [1] "Add non-empty \\value sections to the following man pages:
>> man/filterBycombStringency.Rd"
>>
>> Most man pages encourage a \value{} section describing the output of the
>> function or what would be returned.  This is asking that you add this
>> section to this specific man page with information about what the function
>> returns.
>>
>>
>> On quick glance I think you would cite the references in the bibliography
>> with the tag
>> Vahid_Jalili_MSPC_2015  not the title "Using combined evidence from
>> replicates to evaluate ChIP-seq peaks"
>>
>>
>>
>> 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 Jurat
>> Shayidin 
>> *Sent:* Thursday, December 15, 2016 7:17:42 AM
>> *To:* bioc-devel@r-project.org
>> *Subject:* [Bioc-devel] Quick question about result of R CMD check and R
>> CMD BiocCheck
>>
>> Dear BiocDevel :
>>
>> I got confused about the message from R CMD BiocCheck, and R CMD check on
>> my packages. Precisely speaking, R CMD check throws an error that my unit
>> test is failed, zero warning, 2 notes; instead R CMD BiocCheck complain
>> with one error that no runnable example found, one warning (I don't
>> undersand this warning, becuase R CMD check doesn't report this), 4 notes.
>> I don't understand the result of R CMD BiocCheck, can't figure out the
>> exact issue . However, result of R CMD check is more clear and
>> self-explanatory. I did add example for each of my function, R CMD check
>> okay with it, but R 

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Dirk Eddelbuettel]

On 16 December 2016 at 08:20, Duncan Murdoch wrote:
| Perhaps the solution is to recommend that packages which export their 
| C-level entry points either guarantee them not to change or offer 
| (require?) version checks by user code.  So dplyr should start out by 
| saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version 
| with a compatible interface, it replies "that's fine".  If Rcpp has 
| changed its interface, it says "Sorry, I don't support that any more."

We try. But it's hard, and I'd argue, likely impossible.

For example I even added a "frozen" package [1] in the sources / unit tests
to test for just this. In practice you just cannot hit every possible access
point of the (rich, in our case) API so the tests pass too often.

Which is why we relentlessly test against reverse-depends to _at least ensure
buildability_ from our releases.

As for seamless binary upgrade, I don't think in can work in practice.  Ask
Uwe one day we he rebuilds everything every time on Windows. And for what it
is worth, we essentially do the same in Debian.

Sometimes you just need to rebuild.  That may be the price of admission for
using the convenience of rich C++ interfaces.

Dirk

[1] https://github.com/RcppCore/Rcpp/tree/master/inst/unitTests/testRcppPackage


| Duncan Murdoch
| 
| >
| > Thanks.
| >
| >
| > Best regards
| >
| > Kirill
| >
| >
| > [1] https://github.com/hadley/dplyr/issues/2308#issuecomment-267495075
| > [2] https://travis-ci.org/krlmlr/pkg.upgrade.test#L589-L593
| > [3] https://travis-ci.org/krlmlr/pkg.upgrade.test#L619-L645
| > [4] https://travis-ci.org/krlmlr/pkg.upgrade.test#L671-L703
| >
| > __
| > R-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
| 
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Upgrading a package to which other packages are LinkingTo

[Duncan Murdoch]

I think there's one typo in your post which may confuse some readers; 
I've edited it inline below.  My comments on the suggestion are at the 
bottom of the message.



On 16/12/2016 5:35 AM, Kirill Müller wrote:

Hi


I'd like to suggest to make R more informative when a user updates a
package A where there's at least one package B that has "LinkingTo: A"
in its description.

To illustrate the problem, assume package A is updated so that its C/C++
header interface (in inst/include) is changed. For package B to pick up
these changes, we need to reinstall package A.


This should be "reinstall package B", I think.

> In extreme cases, if B

also imports A and uses functions from A's shared library, failure to
reinstall B may lead to all sorts of undefined behavior.

I've stumbled over this recently for A = Rcpp 0.12.8 and B = dplyr 0.5.0
[1], with a bug fix available in Rcpp 0.12.8.2. Simply upgrading Rcpp to
0.12.8.2 wasn't enough to propagate the bug fix to dplyr; we need to
reinstall dplyr 0.5.0 too.

I've prepared an example with R-devel r71799. The initial configuration
[2] is Rcpp 0.12.8 and dplyr 0.5.0. There is no warning from R after
upgrading Rcpp to 0.12.8.2 [3], and no warning when loading the (now
"broken") dplyr 0.5.0 linked against Rcpp 0.12.8 but importing Rcpp
0.12.8.2 [4].

As a remedy, I'd like to suggest that upgrading Rcpp gives a warning
about installed packages that are LinkingTo it [3], and that loading
dplyr gives a warning that it has been built against a different version
of Rcpp [4], just like the warning when packages are built against a
different version of R.


I'd call it a bug that we allow the situation to exist without some sort 
of warning or error.


Your suggestion is one remedy, but might lead to too many warnings (or 
too many unnecessary recompiles).


An argument could be made that it's a bug in package A that it has 
updated its interface in a way that breaks packages that use it.


Perhaps the solution is to recommend that packages which export their 
C-level entry points either guarantee them not to change or offer 
(require?) version checks by user code.  So dplyr should start out by 
saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version 
with a compatible interface, it replies "that's fine".  If Rcpp has 
changed its interface, it says "Sorry, I don't support that any more."


Duncan Murdoch



Thanks.


Best regards

Kirill


[1] https://github.com/hadley/dplyr/issues/2308#issuecomment-267495075
[2] https://travis-ci.org/krlmlr/pkg.upgrade.test#L589-L593
[3] https://travis-ci.org/krlmlr/pkg.upgrade.test#L619-L645
[4] https://travis-ci.org/krlmlr/pkg.upgrade.test#L671-L703

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Quick question about result of R CMD check and R CMD BiocCheck

[Shepherd, Lori]

You should change the references in your vignette MSPC-User-Guide.Rmd not in 
the bibliography.bib file.  In your vignette, use the tag not the title; so as 
an example:

 [@ Using combined evidence from replicates to evaluate ChIP-seq peaks.]

would become [@Vahid_Jalili_MSPC_2015]



Once you submit your package to Bioconductor, a reviewer will be assigned to 
formally review your package and advise on additional changes.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Jurat Shayidin 
Sent: Friday, December 16, 2016 6:06:41 AM
To: Shepherd, Lori; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Quick question about result of R CMD check and R CMD 
BiocCheck

Dear Lori:

Thanks for your respond on my question. I fixed the error from unit test. I 
tried to edit the tag on bibliography.bib file, but Rstudio still did not print 
that out. Why is that?

R CMD check report only one Notes when I tried to generate stack bar plot for 
my output set by using ggplot2 packages, this note also appeared in R CMD 
BiocCheck. I really don't know how to get rid of this note. Any idea please ? 
How to remove this note ? Should I suppress this? Here is note that raised by R 
CMD check :

Undefined global functions or variables:
  . Replicate cn mcols<- n original_list output p.value peakStringency

plus, I've used tidyr package to categorize my intermediate output in order to 
get desired result, but when I execute .Rmd files, it gaves warning, that 
didn't appeared in R CMD check, R CMD BiocCheck. Because R CMD check, R CMD 
BiocCheck never report this as a warning. Should I keep aside this ? R markdown 
report this warning :

Warning messages:
1: Too many values at 158 locations: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15, 16, 17, 18, 19, 20, ...

What possible changes I might to do on my package before issuing package 
submission? Thank you very much.

Best regards :

Jurat



On Thu, Dec 15, 2016 at 2:36 PM, Shepherd, Lori 
> wrote:

$error
[1] "At least 80% of man pages documenting exported objects must have
runnable examples. The following pages do not:"

This ERROR occurs when man pages are included without runnable examples.  You 
have examples in it looks like 5/12 of your man pages (~42%). We encourage 80%

$warning
[1] "Add non-empty \\value sections to the following man pages:
man/filterBycombStringency.Rd"

Most man pages encourage a \value{} section describing the output of the 
function or what would be returned.  This is asking that you add this section 
to this specific man page with information about what the function returns.


On quick glance I think you would cite the references in the bibliography with 
the tag
Vahid_Jalili_MSPC_2015  not the title "Using combined evidence from replicates 
to evaluate ChIP-seq peaks"




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 Jurat Shayidin >
Sent: Thursday, December 15, 2016 7:17:42 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Quick question about result of R CMD check and R CMD 
BiocCheck

Dear BiocDevel :

I got confused about the message from R CMD BiocCheck, and R CMD check on
my packages. Precisely speaking, R CMD check throws an error that my unit
test is failed, zero warning, 2 notes; instead R CMD BiocCheck complain
with one error that no runnable example found, one warning (I don't
undersand this warning, becuase R CMD check doesn't report this), 4 notes.
I don't understand the result of R CMD BiocCheck, can't figure out the
exact issue . However, result of R CMD check is more clear and
self-explanatory. I did add example for each of my function, R CMD check
okay with it, but R CMD BiocCheck complain about this, Why ? How to address
the issues raised by R CMD BiocCheck ?  R CMD BiocCheck gave me following
message :

$error
[1] "At least 80% of man pages documenting exported objects must have
runnable examples. The following pages do not:"

$warning
[1] "Add non-empty \\value sections to the following man pages:
man/filterBycombStringency.Rd"



Plus, I tried to attach bibliography.bib files on my package's vignette,
but Rstudio didn't print out the bibliography information at the end of
.Rmd file. How can I make this happen ? I did push all recent changes to
github , so everything is synchronized. Is
that possible to kindly ask Bioconductor team to briefly review my packages
and getting valuable opinion to improve my work? 

Re: [Rd] print.POSIXct doesn't seem to use tz argument, as per its example

[Dirk Eddelbuettel]

On 16 December 2016 at 10:19, Martin Maechler wrote:
| > Jennifer Lyon 
| > on Thu, 15 Dec 2016 09:33:30 -0700 writes:
| 
| > On the documentation page for DateTimeClasses, in the Examples section,
| > there are the following two lines:
| > 
| > format(.leap.seconds) # the leap seconds in your time zone
| > print(.leap.seconds, tz = "PST8PDT")  # and in Seattle's
| > 
| > The second line (using print) seems to ignore the tz argument, and prints
| > the dates in my time zone, while:
| > 
| > format(.leap.seconds, tz = "PST8PDT")
| > 
| > does print the dates in PST. The code in
| > https://github.com/wch/r-source/blob/trunk/src/library/base/R/datetime.R
| > around line 234 looks like the ... argument is passed to print, not to
| > format.
| > 
| > print.POSIXct <-
| > print.POSIXlt <- function(x, ...)
| > {
| > max.print <- getOption("max.print", L)
| > if(max.print < length(x)) {
| > print(format(x[seq_len(max.print)], usetz = TRUE), ...)
| > cat(' [ reached getOption("max.print") -- omitted',
| > length(x) - max.print, 'entries ]\n')
| > } else print(if(length(x)) format(x, usetz = TRUE)
| >  else paste(class(x)[1L], "of length 0"), ...)
| > invisible(x)
| > }
| > 
| > The documentation for print() on this page seems to be silent on tz as an
| > argument, but I do believe the example using print() does not work as
| > advertised.
| 
| > Thanks.
| > 
| > Jen
| 
| Thank you, Jen!
| Indeed,  both your observation and your diagnosis are correct:
| This has been a misleading example and needs amending (or the
| code is changed, see below).
| 
| The most simple fix would be to replace  'print('  by
| 'format('; then the example would work as advertized.
| That change has two drawbacks still:
| 
| 1) format(.) examples on the help of print.POSIXct() where
|format.POSIXct() is *not* documented 
| 
| 2) It *would* make sense that print.POSIXct() allowed for a 'tz' argument
|(and maybe 'usetz' too).  This/these would be (an) extra
|argument(s) rather than passing '...' not just to print() but
|also to format()rathere
| 
| My personal preference would tend to add both
|  tz = ""
| and  usetz = TRUE
| to the formal arguments of print.POSIXct and pass them to the
| format(.) calls.

I think that is a good idea. I have been by this a few times too.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Quick question about result of R CMD check and R CMD BiocCheck

[Jurat Shayidin]

Dear Lori:

Thanks for your respond on my question. I fixed the error from unit test. I
tried to edit the tag on bibliography.bib file, but Rstudio still did not
print that out. Why is that?

R CMD check report only one Notes when I tried to generate stack bar plot
for my output set by using ggplot2 packages, this note also appeared in R
CMD BiocCheck. I really don't know how to get rid of this note. Any idea
please ? How to remove this note ? Should I suppress this? Here is note
that raised by R CMD check :

Undefined global functions or variables:
  . Replicate cn mcols<- n original_list output p.value peakStringency

plus, I've used tidyr package to categorize my intermediate output in order
to get desired result, but when I execute .Rmd files, it gaves warning,
that didn't appeared in R CMD check, R CMD BiocCheck. Because R CMD check,
R CMD BiocCheck never report this as a warning. Should I keep aside this ?
R markdown report this warning :

Warning messages:
1: Too many values at 158 locations: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, ...


What possible changes I might to do on my package before issuing package
submission? Thank you very much.

Best regards :

Jurat



On Thu, Dec 15, 2016 at 2:36 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> $error
> [1] "At least 80% of man pages documenting exported objects must have
> runnable examples. The following pages do not:"
>
> This ERROR occurs when man pages are included without runnable examples.
> You have examples in it looks like 5/12 of your man pages (~42%). We
> encourage 80%
>
> $warning
> [1] "Add non-empty \\value sections to the following man pages:
> man/filterBycombStringency.Rd"
>
> Most man pages encourage a \value{} section describing the output of the
> function or what would be returned.  This is asking that you add this
> section to this specific man page with information about what the function
> returns.
>
>
> On quick glance I think you would cite the references in the bibliography
> with the tag
> Vahid_Jalili_MSPC_2015  not the title "Using combined evidence from
> replicates to evaluate ChIP-seq peaks"
>
>
>
> 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 Jurat
> Shayidin 
> *Sent:* Thursday, December 15, 2016 7:17:42 AM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] Quick question about result of R CMD check and R
> CMD BiocCheck
>
> Dear BiocDevel :
>
> I got confused about the message from R CMD BiocCheck, and R CMD check on
> my packages. Precisely speaking, R CMD check throws an error that my unit
> test is failed, zero warning, 2 notes; instead R CMD BiocCheck complain
> with one error that no runnable example found, one warning (I don't
> undersand this warning, becuase R CMD check doesn't report this), 4 notes.
> I don't understand the result of R CMD BiocCheck, can't figure out the
> exact issue . However, result of R CMD check is more clear and
> self-explanatory. I did add example for each of my function, R CMD check
> okay with it, but R CMD BiocCheck complain about this, Why ? How to address
> the issues raised by R CMD BiocCheck ?  R CMD BiocCheck gave me following
> message :
>
> $error
> [1] "At least 80% of man pages documenting exported objects must have
> runnable examples. The following pages do not:"
>
> $warning
> [1] "Add non-empty \\value sections to the following man pages:
> man/filterBycombStringency.Rd"
>
>
>
> Plus, I tried to attach bibliography.bib files on my package's vignette,
> but Rstudio didn't print out the bibliography information at the end of
> .Rmd file. How can I make this happen ? I did push all recent changes to
> github , so everything is synchronized.
> Is
> that possible to kindly ask Bioconductor team to briefly review my packages
> and getting valuable opinion to improve my work? I am grad students and
> very few experiences in Bioinformatics field (not in this major), so my
> very first R package might have a lot of issues, getting possible
> contribution would be highly appreciated. Many thanks to Bioconductor team.
>
> Best regards :
>
> --
> Jurat Shahidin
>
> Dipartimento di Elettronica, Informazione e Bioingegneria
> Politecnico di Milano
> Piazza Leonardo da Vinci 32 - 20133 Milano, Italy
> Mobile : +39 3279366608 <+39%20327%20936%206608> <+39%20327%20936%206608>
>
> [[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 

Re: [Rd] print.POSIXct doesn't seem to use tz argument, as per its example

[Martin Maechler]

> Jennifer Lyon 
> on Thu, 15 Dec 2016 09:33:30 -0700 writes:

> On the documentation page for DateTimeClasses, in the Examples section,
> there are the following two lines:
> 
> format(.leap.seconds) # the leap seconds in your time zone
> print(.leap.seconds, tz = "PST8PDT")  # and in Seattle's
> 
> The second line (using print) seems to ignore the tz argument, and prints
> the dates in my time zone, while:
> 
> format(.leap.seconds, tz = "PST8PDT")
> 
> does print the dates in PST. The code in
> https://github.com/wch/r-source/blob/trunk/src/library/base/R/datetime.R
> around line 234 looks like the ... argument is passed to print, not to
> format.
> 
> print.POSIXct <-
> print.POSIXlt <- function(x, ...)
> {
> max.print <- getOption("max.print", L)
> if(max.print < length(x)) {
> print(format(x[seq_len(max.print)], usetz = TRUE), ...)
> cat(' [ reached getOption("max.print") -- omitted',
> length(x) - max.print, 'entries ]\n')
> } else print(if(length(x)) format(x, usetz = TRUE)
>  else paste(class(x)[1L], "of length 0"), ...)
> invisible(x)
> }
> 
> The documentation for print() on this page seems to be silent on tz as an
> argument, but I do believe the example using print() does not work as
> advertised.

> Thanks.
> 
> Jen

Thank you, Jen!
Indeed,  both your observation and your diagnosis are correct:
This has been a misleading example and needs amending (or the
code is changed, see below).

The most simple fix would be to replace  'print('  by
'format('; then the example would work as advertized.
That change has two drawbacks still:

1) format(.) examples on the help of print.POSIXct() where
   format.POSIXct() is *not* documented 

2) It *would* make sense that print.POSIXct() allowed for a 'tz' argument
   (and maybe 'usetz' too).  This/these would be (an) extra
   argument(s) rather than passing '...' not just to print() but
   also to format()rathere

My personal preference would tend to add both
 tz = ""
and  usetz = TRUE
to the formal arguments of print.POSIXct and pass them to the
format(.) calls.

Martin


> sessionInfo()
> R version 3.3.2 (2016-10-31)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
> 
> 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] stats graphics  grDevices utils datasets  methods   base

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel