Re: [Rd] Coping with non-standard evaluation in R program analysis

[Benjamin Tyner]

Evan,

The pryr package provides some utilities which may be handy here. In 
particular see the function: is_promise.


Also, next time please post in plaintext.

Regards
Ben

Hello R experts,


I plan to develop a tool for dynamic analysis of R programs. I would like to 
trace function calls at runtime, capturing argument and return values. 
Following a suggestion made some time ago on this list, my high-level 
implementation strategy is to rewrite the AST, augmenting call expressions with 
pre-call and post-call shims to capture the arguments and return value, 
respectively.


I can think of only one fundamental conceptual obstacle to this approach: R functions are not 
necessarily referentially transparent. The arguments received by a function are not values but 
promises. They can be evaluated directly ("standard evaluation"), after applying 
arbitrary syntactic transformations ("non-standard evaluation", aka NSE), or not at all. 
Therefore, if you peek at the values of function arguments before evaluating the function, you risk 
altering the semantics of the program, possibly fatally.


I'm looking for general advice about how to cope with NSE in this context. I 
also have some specific questions:


1) Is it possible to determine whether a given function (primitive, in R, or 
external) uses NSE on some or all of its arguments?


2) Is it possible to inspect the promise objects received by functions, say to 
determine whether they have been evaluated, without actually evaluating them? 
The R manual is not encouraging in this area:


https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Promise-objects


Thank you,


Evan


[[alternative HTML version deleted]]



--

Subject: Digest Footer

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

--

End of R-devel Digest, Vol 179, Issue 1
***


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

Re: [R-pkg-devel] Annoying "missing file link" messages when rebuilding

[Duncan Murdoch]

On 03/01/2018 8:35 PM, Lenth, Russell V wrote:

Developers:

Lately (the past month or so), I have been getting a ton of messages like the 
following whenever I rebuild my package:

 Rd warning: H:/progs/R/devel/EMMEANS/emmeans/man/xtable.emmGrid.Rd:57: 
missing file link 'print.xtableList'

The flagged line 57 in xtable.emmGrid.Rd looks like this:

 The \code{print} method uses \code{\link[xtable]{print.xtableList}}, ...

It seems like this warning occurs for every single instance of the form 
\link[pkg]{fcn} in my .Rd files.


I don't see a help file named print.xtableList.Rd in xtable.  That kind 
of link is to a filename, not to a help alias.  I believe the alias is 
in xtableList.Rd, so your link should be


\link[xtable:xtableList]{print.xtableList}



The warnings seems to be false, as the actual help files generated have the 
links I specified, and they work correctly. So the warnings are only an 
annoyance -- but a considerable annoyance nonetheless.


When R is running the dynamic help system and it finds a link to a file 
that doesn't exist, it tries using its database of aliases.  However, R 
still supports static help, and in those systems the links wouldn't work.




I didn't used to get these warnings, even though many of the .Rd files 
(including the example shown) have been in place for some time. Does anybody 
know where these come from, or how they can be suppressed? Is it in the latest 
R version, or in RStudio?


They should be suppressed if you code the link as I show above.

Duncan Murdoch



Thanks for any help.

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science
The University of Iowa  -  Iowa City, IA 52242  USA
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

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



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

[R-pkg-devel] Annoying "missing file link" messages when rebuilding

[Lenth, Russell V]

Developers:

Lately (the past month or so), I have been getting a ton of messages like the 
following whenever I rebuild my package:

Rd warning: H:/progs/R/devel/EMMEANS/emmeans/man/xtable.emmGrid.Rd:57: 
missing file link 'print.xtableList'

The flagged line 57 in xtable.emmGrid.Rd looks like this:

The \code{print} method uses \code{\link[xtable]{print.xtableList}}, ...

It seems like this warning occurs for every single instance of the form 
\link[pkg]{fcn} in my .Rd files.

The warnings seems to be false, as the actual help files generated have the 
links I specified, and they work correctly. So the warnings are only an 
annoyance -- but a considerable annoyance nonetheless. 

I didn't used to get these warnings, even though many of the .Rd files 
(including the example shown) have been in place for some time. Does anybody 
know where these come from, or how they can be suppressed? Is it in the latest 
R version, or in RStudio?

Thanks for any help.

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science   
The University of Iowa  -  Iowa City, IA 52242  USA   
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

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

Re: [Rd] Coping with non-standard evaluation in R program analysis

[Peter Meilstrup]

For 2), it is not exposed in R's standard library but it is exposed in
the Rinternals API. A promise that is forced in normal evaluation will
have PRENV set to NULL.

Peter

On Tue, Jan 2, 2018 at 4:19 PM, Evan James Patterson
 wrote:
> Hello R experts,
>
>
> I plan to develop a tool for dynamic analysis of R programs. I would like to 
> trace function calls at runtime, capturing argument and return values. 
> Following a suggestion made some time ago on this list, my high-level 
> implementation strategy is to rewrite the AST, augmenting call expressions 
> with pre-call and post-call shims to capture the arguments and return value, 
> respectively.
>
>
> I can think of only one fundamental conceptual obstacle to this approach: R 
> functions are not necessarily referentially transparent. The arguments 
> received by a function are not values but promises. They can be evaluated 
> directly ("standard evaluation"), after applying arbitrary syntactic 
> transformations ("non-standard evaluation", aka NSE), or not at all. 
> Therefore, if you peek at the values of function arguments before evaluating 
> the function, you risk altering the semantics of the program, possibly 
> fatally.
>
>
> I'm looking for general advice about how to cope with NSE in this context. I 
> also have some specific questions:
>
>
> 1) Is it possible to determine whether a given function (primitive, in R, or 
> external) uses NSE on some or all of its arguments?
>
>
> 2) Is it possible to inspect the promise objects received by functions, say 
> to determine whether they have been evaluated, without actually evaluating 
> them? The R manual is not encouraging in this area:
>
>
> https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Promise-objects
>
>
> Thank you,
>
>
> Evan
>
>
> [[alternative HTML version deleted]]
>
> __
> 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

[Rd] Community Feedback: Git Repository for R-Devel

[Juan Telleria]

UNBIASED FACTS:
• Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as
Ticketing platforms for bug pull requests on the R-devel Git Repository.

•  Git Repository Options:
A) Github (Cloud with Automated backups from GitHub to CRAN Server):
https://github.com
B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com
C) Phabricator (Selfhosted on CRAN): https://www.phacility.com
D) Microsoft Codeplex: https://www.codeplex.com
E) Others: Unknown

GOOGLE TRENDS:
https://trends.google.com/trends/explore?date=all=Git,Svn,Github,Gitlab

EXAMPLE
Git Repository on Core Python: https://github.com/python

PERSONAL OPINION / MOTIVATION:
I think that moving efforts in this direction is important because it would
allow a true Open Source Innovation & Open Collaboration in R between:
* R Community.
* And R-Core.
For:
* R Bug Fixes.
* And Core Feature Wishlist.
As anyone would be able to:
* Check the unassigned bugs in Bugzilla (apart from R-Core).
* And propose bugs fixes by themselves as Pull requests (by mentioning the
Bug ID of Bugzilla or the Mailing Lists).

This would allow that _individuals_ either from Universities or Companies
interested in the Development of R:
* apart of donating economical resources to the R Foundation.
* could help to maintain core R Code by themselves.
Which aligns with the true spirit of R, which shall be done from
contributing individuals, for individuals themselves.

It would also allow to put the focus on the precise lines of code changed
with each Commit, and revert changes in an easy way, without verbose
E-mails: Tidy, Clean, Maintainable, and Fast.

At last, I noticed R-devel Archives do not have an E-mail Id (Unique
Unsigned Integer), so it would be a good idea to add one for pull requests
if Git was adopted.

Juan

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] git help

[Kevin Horan]

Nitesh,

That sounds great, thanks.

Kevin


On 01/03/2018 01:53 PM, Turaga, Nitesh wrote:

Hi Kevin,

I can help you with this. I can take you back to a state before August 18th and 
put that repository up on our Git server.

 From that point onwards you’d have to reapply all the changes on that repository from 
"commit ae93b1e9bcc574b5c8e9fc13b914286464ff4389" and onwards.

commit ae93b1e9bcc574b5c8e9fc13b914286464ff4389
Merge: 643e470 f1785fb
Author: tgirke 
Date:   Sat Aug 19 16:32:35 2017 -0700

 resolved conflicts

I can do this tomorrow and send you an email.


Best,

Nitesh





On Jan 3, 2018, at 4:28 PM, Kevin Horan  wrote:

Nitesh,

I tried to re-construct the repo starting from what is left in the SVN 
repository, but I couldn't get all the branches to come over and it just 
generally looks too different to easily replace the bioc repo.

I was thinking though, if its easy for you to clobber the current bioc repo 
for ChemmineR and re-create it from the old SVN repo (ie, because you might 
have scripts from having done it the first time), then that might be an easier 
fix. Then I can check it out, apply the recent changes and push it back.

But if you don't think that's a good idea, then I'll take your offer of 
help and we can try to figure out how to get rid of the duplicate commits. 
Thanks.


Kevin


On 01/03/2018 11:55 AM, Turaga, Nitesh wrote:

Hi Kevin,

I’ll try to help you. I’ll take a look at your package and get back to you. 
Please forward this message to bioc-devel so that it’s public and other 
maintainers/users know that there is an issue with your package.

Best,

Nitesh


On Jan 3, 2018, at 2:31 PM, Kevin Horan  wrote:

Nitesh,

I am one of the maintainers for the ChemmineR package on bioconductor. I 
have a bad duplicate commit problem I was wondering if you could help me with. 
Basically, it seems one string of 1000 or so commits has been duplicated twice 
in the repository, so that there are now 3 copies of each of these commits. 
This mess is already in the bioconductor repository because in order to allow 
me to get some last minute changes in for the last release, someone at boic 
disabled the duplicate commit check for me. That was before I understood the 
extend of the problem.

I'm not sure if its really your job to help with this sort of thing, as I 
understand that it's not a bioconductor problem. So if not that is fine. I've 
spent 6 hours trying to fix it myself ( and I am generally good with  GIT), but 
I've only succeeded in make more duplicates. So I think I'd need to toss all 
the history up to the last release, which I image I'd need your help to reset 
the repo on the bioc side as well.

If you can help, there are more specifics I can give you, just let me know.

Thanks.


Kevin Horan



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.


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

Re: [Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

On 03/01/2018 6:11 PM, Uwe Ligges wrote:



On 26.12.2017 00:45, Juan Telleria wrote:

However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)

By putting the focus on version control, the line of changes made with each
commit (With the possibility to reverse changes), and not verbose e-mails.


That works well with svn, and we have the sequential labels which are
e.g. important for bisecting changes.
I do not see how I can find this out with git easily.


I think git supports bisection, but I don't see how switching to git 
would make anything easier for R Core.  Perhaps Juan can tell us which R 
Core tasks would be easier in git.


Duncan Murdoch

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

Re: [R-pkg-devel] Portable method of stripping debug symbols

[Thibault Vatter]

Hi,

We faced a problem when we tried Dirk's solution for our package
rvinecopulib: there is a strip binary on OS X but it doesn't work as the
linux one.

As such, to avoid calling OS X's strip which doesn't work, we use:

strippedLib: $(SHLIB)
if test -e "/usr/bin/strip" & test -e "/bin/uname" & [[ `uname` == "Linux"
]] ; then /usr/bin/strip --strip-debug $(SHLIB); fi
.phony: strippedLib

Hope this helps,
Thibault

On Wed, Jan 3, 2018 at 11:13 PM, Dirk Eddelbuettel  wrote:

>
> Christopher,
>
> On 3 January 2018 at 21:59, Christopher Lalansingh wrote:
> | I'm running into troubles with the total size of my package and I've
> found that when using Rcpp, one can reduce the size of shared objects by
> stripping out debug symbols by including `-Wl,-S' in PKG_LIBS.
> Unfortunately this is not portable with Solaris, and using ifeq in my
> Makevars file to check for SunOS isn't portable either.
> |
> | I came across an Issue on github (https://github.com/RcppCore/
> Rcpp/issues/522) which addresses possible ways to do this portably, but I
> can't find reference to // [[Rcpp::plugins(strip)]] in any other
> documentation. If anyone has run into this before and has any suggestions
> it would be much appreciated.
>
> I have two writeups on this in my r^4 series:
>
> http://dirk.eddelbuettel.com/blog/2017/08/20#010_stripping_
> shared_libraries
> http://dirk.eddelbuettel.com/blog/2017/08/14#009_compact_shared_libraries
>
> The earlier one has this snippet you can add to src/Makevars, and you could
> even do this conditionally (ie do it on Linux, don't do it on Solaris, or
> the
> other way, or ...)
>
>   strippedLib: $(SHLIB)
>   if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-debug
> $(SHLIB); fi
>
>   .phony: strippedLib
>
> This will strip if and only if there is a strip binary. May work for yuo.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] R CMD check warning about compiler warning flags

[Uwe Ligges]

On 26.12.2017 00:45, Juan Telleria wrote:

However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)

By putting the focus on version control, the line of changes made with each
commit (With the possibility to reverse changes), and not verbose e-mails.


That works well with svn, and we have the sequential labels which are 
e.g. important for bisecting changes.

I do not see how I can find this out with git easily.

Best,
Uwe Ligges




Juan

I strongly disagree. Are you aware that github is a commercial

company, github inc. [1] ?
What about gitlab? or Microsoft's codeplex? There are other services
similar to github, why github?
What happens if github goes out of business?

R-project should be maintained in the academic network and under
auspices of universities.


  [*]  GitHub, Inc.
https://en.wikipedia.org/wiki/GitHub






[[alternative HTML version deleted]]

__
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: [R-pkg-devel] Portable method of stripping debug symbols

[Dirk Eddelbuettel]

Christopher,

On 3 January 2018 at 21:59, Christopher Lalansingh wrote:
| I'm running into troubles with the total size of my package and I've found 
that when using Rcpp, one can reduce the size of shared objects by stripping 
out debug symbols by including `-Wl,-S' in PKG_LIBS. Unfortunately this is not 
portable with Solaris, and using ifeq in my Makevars file to check for SunOS 
isn't portable either.
| 
| I came across an Issue on github 
(https://github.com/RcppCore/Rcpp/issues/522) which addresses possible ways to 
do this portably, but I can't find reference to // [[Rcpp::plugins(strip)]] in 
any other documentation. If anyone has run into this before and has any 
suggestions it would be much appreciated.

I have two writeups on this in my r^4 series:

http://dirk.eddelbuettel.com/blog/2017/08/20#010_stripping_shared_libraries
http://dirk.eddelbuettel.com/blog/2017/08/14#009_compact_shared_libraries

The earlier one has this snippet you can add to src/Makevars, and you could
even do this conditionally (ie do it on Linux, don't do it on Solaris, or the
other way, or ...)

  strippedLib: $(SHLIB)
  if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-debug 
$(SHLIB); fi

  .phony: strippedLib

This will strip if and only if there is a strip binary. May work for yuo.

Dirk

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

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

[R-pkg-devel] Portable method of stripping debug symbols

[Christopher Lalansingh]

Hello all,


I'm running into troubles with the total size of my package and I've found that 
when using Rcpp, one can reduce the size of shared objects by stripping out 
debug symbols by including `-Wl,-S' in PKG_LIBS. Unfortunately this is not 
portable with Solaris, and using ifeq in my Makevars file to check for SunOS 
isn't portable either.


I came across an Issue on github (https://github.com/RcppCore/Rcpp/issues/522) 
which addresses possible ways to do this portably, but I can't find reference 
to // [[Rcpp::plugins(strip)]] in any other documentation. If anyone has run 
into this before and has any suggestions it would be much appreciated.


Thanks,


Christopher Lalansingh
Software Engineer

Direct: 647-258-4313


Ontario Institute for Cancer Research
MaRS Centre, West Tower
661 University Ave, Suite 510
Toronto, Ontario, Canada M5G 0A3



This message and any attachments may contain confidentia...{{dropped:12}}

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

Re: [Bioc-devel] git help

[Kevin Horan]

Nitesh,

I tried to re-construct the repo starting from what is left in the 
SVN repository, but I couldn't get all the branches to come over and it 
just generally looks too different to easily replace the bioc repo.


I was thinking though, if its easy for you to clobber the current 
bioc repo for ChemmineR and re-create it from the old SVN repo (ie, 
because you might have scripts from having done it the first time), then 
that might be an easier fix. Then I can check it out, apply the recent 
changes and push it back.


But if you don't think that's a good idea, then I'll take your 
offer of help and we can try to figure out how to get rid of the 
duplicate commits. Thanks.



Kevin


On 01/03/2018 11:55 AM, Turaga, Nitesh wrote:

Hi Kevin,

I’ll try to help you. I’ll take a look at your package and get back to you. 
Please forward this message to bioc-devel so that it’s public and other 
maintainers/users know that there is an issue with your package.

Best,

Nitesh


On Jan 3, 2018, at 2:31 PM, Kevin Horan  wrote:

Nitesh,

I am one of the maintainers for the ChemmineR package on bioconductor. I 
have a bad duplicate commit problem I was wondering if you could help me with. 
Basically, it seems one string of 1000 or so commits has been duplicated twice 
in the repository, so that there are now 3 copies of each of these commits. 
This mess is already in the bioconductor repository because in order to allow 
me to get some last minute changes in for the last release, someone at boic 
disabled the duplicate commit check for me. That was before I understood the 
extend of the problem.

I'm not sure if its really your job to help with this sort of thing, as I 
understand that it's not a bioconductor problem. So if not that is fine. I've 
spent 6 hours trying to fix it myself ( and I am generally good with  GIT), but 
I've only succeeded in make more duplicates. So I think I'd need to toss all 
the history up to the last release, which I image I'd need your help to reset 
the repo on the bioc side as well.

If you can help, there are more specifics I can give you, just let me know.

Thanks.


Kevin Horan




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


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

[Bioc-devel] Issue with dependencies on Windows (tokay2)

[Hoffman, Gabriel]

Hi,
I am getting a dependency error in the development branch of my package 
variancePartition when Bioconductor builds my package.

ERROR: dependencies 'pbkrtest', 'lme4' are not available for package 
'variancePartition'

These are standard enough dependencies, especially lme4.  There is no issue on 
OS X or Ubuntu.  My R code has not changed since the Release branch, and that 
builds with no error.

Here is the devel page:
http://bioconductor.org/checkResults/3.7/bioc-LATEST/variancePartition/tokay2-buildsrc.html

Is anyone else having issues on the Windows machine?

Thanks,
- Gabriel

 --

Gabriel Hoffman, Ph.D.



Assistant Professor

Icahn Institute for Genomics and Multiscale Biology

Department of Genetics and Genomic Sciences

Icahn School of Medicine at Mount Sinai



gabriel.hoff...@mssm.edu



1425 Madison Avenue

New York, NY 10029

Icahn Building L3-70B

212-659-1635


http://gabrielhoffman.github.io

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] RSS feed on bioconductor.org/developers/gitlog

[Turaga, Nitesh]

Hi,

The links on each feed point back to the bioconductor home page. There is no 
log file for each package separately. This was a design choice.

Best,

Nitesh 

> On Jan 3, 2018, at 9:39 AM, Lluís Revilla  wrote:
> 
> Great work and happy new year!!
> 
> I checked both RSS feeds and the random links I tried all point to the home 
> page of Bioconductor. 
> I am unsure if the links in the feed should point to a section on the gitlog 
> page or to any other page (or is an issue on my end). 
> 
> Thanks,
> 
> Lluís
> 
> 
> On 2 January 2018 at 21:38, Turaga, Nitesh  
> wrote:
> Hello Maintainers,
> 
> Happy new year!
> 
> The GIT logs are available as RSS feeds, or as markdown on the website at
> 
> http://bioconductor.org/developers/gitlog/
> 
> This is across all the packages on the bioconductor git server. It allows 
> developers to keep track of their package development, and for the community 
> to keep track of their favorite packages. The website shows only the most 
> recent 200 commits.
> 
> Please note that the website rebuilds every 20 mins, so it will take 20 mins 
> for your commit to show up on the website.
> 
> 
> Best,
> 
> 
> Nitesh Turaga
> Bioconductor Core Team
> 
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RSS feed on bioconductor.org/developers/gitlog

[Lluís Revilla]

Great work and happy new year!!

I checked both RSS feeds and the random links I tried all point to the home
page of Bioconductor.
I am unsure if the links in the feed should point to a section on the
gitlog page or to any other page (or is an issue on my end).

Thanks,

Lluís


On 2 January 2018 at 21:38, Turaga, Nitesh 
wrote:

> Hello Maintainers,
>
> Happy new year!
>
> The GIT logs are available as RSS feeds, or as markdown on the website at
>
> http://bioconductor.org/developers/gitlog/
>
> This is across all the packages on the bioconductor git server. It allows
> developers to keep track of their package development, and for the
> community to keep track of their favorite packages. The website shows only
> the most recent 200 commits.
>
> Please note that the website rebuilds every 20 mins, so it will take 20
> mins for your commit to show up on the website.
>
>
> Best,
>
>
> Nitesh Turaga
> Bioconductor Core Team
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Warning "Dependence on R version '3.3.3' not with patchlevel 0"

[peter dalgaard]

Yep. Bear in mind that many system-wide installation, e.g. in universities, are 
of .0 or .1 releases and upgraded yearly. If we end up with packages depending 
on packages depending on a later version, bad things can happen (and _did_ 
happen in the 3.2.* series). For the same reason, we have become very careful 
not to add features into R-patched,so it should be rather unlikely that 
packages that work with x.y.z do not also work with x.y.0.

-pd

> On 3 Jan 2018, at 14:33 , Uwe Ligges  wrote:
> 
> 
> 
> On 03.01.2018 13:59, Hockemeyer, Cord (cord.hockeme...@uni-graz.at) wrote:
>> Hi everybody,
>> on submitting a new package I got a rejection because of the above warning 
>> in the CRAN-check. I guess it is because of the "Depends" entry "R (>= 
>> 3.3.3)" in the DESCRIPTION file but I have no idea how to do this otherwise. 
>> Any hel�p would be highly appreciated.
> 
> If sufficient, use R (>= 3.3.0), otherwise R (>= 3.4.0): If you rely on a 
> specific patchlevel, binary repositories are inconsistant on CRAN and 
> typically you should be able to rely on a x.y.0 release.
> 
> Best,
> Uwe Ligges
> 
> 
>> Best regards,
>>Cord
>> Cord Hockemeyer
>> Institut f�r Psychologie, Universit�t Graz
>> Tel.: +43 316 380 8531
>> https://psychologie.uni-graz.at/allgemeine/hockemeyer
>>  [[alternative HTML version deleted]]
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Warning "Dependence on R version '3.3.3' not with patchlevel 0"

[Uwe Ligges]

On 03.01.2018 13:59, Hockemeyer, Cord (cord.hockeme...@uni-graz.at) wrote:

Hi everybody,

on submitting a new package I got a rejection because of the above warning in the CRAN-check. I guess 
it is because of the "Depends" entry "R (>= 3.3.3)" in the DESCRIPTION file but 
I have no idea how to do this otherwise. Any hel�p would be highly appreciated.


If sufficient, use R (>= 3.3.0), otherwise R (>= 3.4.0): If you rely on 
a specific patchlevel, binary repositories are inconsistant on CRAN and 
typically you should be able to rely on a x.y.0 release.


Best,
Uwe Ligges




Best regards,
Cord


Cord Hockemeyer
Institut f�r Psychologie, Universit�t Graz
Tel.: +43 316 380 8531
https://psychologie.uni-graz.at/allgemeine/hockemeyer


[[alternative HTML version deleted]]



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



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

[R-pkg-devel] Warning "Dependence on R version '3.3.3' not with patchlevel 0"

[Hockemeyer, Cord (cord.hockeme...@uni-graz.at)]

Hi everybody,

on submitting a new package I got a rejection because of the above warning in 
the CRAN-check. I guess it is because of the "Depends" entry "R (>= 3.3.3)" in 
the DESCRIPTION file but I have no idea how to do this otherwise. Any hel�p 
would be highly appreciated.

Best regards,
   Cord


Cord Hockemeyer
Institut f�r Psychologie, Universit�t Graz
Tel.: +43 316 380 8531
https://psychologie.uni-graz.at/allgemeine/hockemeyer


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] mzR build failure on Windows: missing HDF5 libraries

[Mike Smith]

Rhdf5lib is in the release branch too.  I'm happy to help try and get mzR
working with it.

On 2 January 2018 at 21:31, Martin Morgan 
wrote:

> On 01/02/2018 03:16 PM, Neumann, Steffen wrote:
>
>> Dear BioC team,
>>
>> a happy new year to you as well ;-)
>>
>> for a while we have a build error for mzR on windows
>> due to missing HDF5 libs:
>> https://github.com/sneumann/mzR/issues/143
>>
>> I am looking for some hints how to fix this.
>> The https://bioconductor.org/packages/release/bioc/html/rhdf5.html
>> package has embedded rhdf5/src/libwin/x64/libhdf5ForBioC-7.dll
>> which we could try to use (It does not yet contain H5Cpp.h,
>> and we'd have to ask Bernd Fischer et al to include it.
>>
>
> Not a comprehensive answer or solution to release, but in devel there is
> Rhdf5lib which contains both the C and C++ headers. (I believe that rhdf5
> will move to using this library in the near future) Martin
>
>
>> ALternatively, it might already be present on the build machines,
>> but we didn't have the include path set up:
>> https://github.com/r-hub/rhub/issues/91
>> "... the location of the hdf5 libraries is defined as
>> ${LIB_HDF5}/lib${R_ARCH}. "
>>
>> So, any hints which way to go for a fix ?
>>
>> Yours,
>> Steffen
>>
>>
>
> 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
>

[[alternative HTML version deleted]]

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