Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

> Henrik, if Bioconductor releases weren’t tied to R releases, how could 
> Bioconductor test them? I guess like CRAN where as long as a package says it 
> depends on R >= 2.0 then you’re free to try installing on 2.0 even though the 
> combination has never been tested? Maybe I worry too much about such testing 
> since CRAN seems OK anyways, as far as we know?

TL;DR: I think Bioconductor could say: "We have only tested Bioc
release on R version x.y. There is no guarantee it will work with
another version of R."

Here is my view:

The Bioconductor Project guarantees that R packages part of the the
Bioc release version and the Bioc development version are well tested
and work well together.  That is the agreed upon objective.

Then there's the objective that Bioconductor wants to protect
end-users from shooting themselves in the foot. This is done by
preventing users from mix-and-match installing Bioc release and
development packages, which is the main role of the BiocManager
package.

Half of the year, it's easy to implement this protection, because the
Bioc release runs on R release and Bioc devel on R devel. I see that
as an obvious first approach, because R itself takes care of
everything for us and Bioc release and devel are nicely separated on
the users computer.  This model worked really well when R had two
releases per year.  However, even since R moved to one release per
year and Bioc kept two, the above model cannot be used six months of
the year.  Instead, for those months, we have to manually manage our
own R package library if we would like to swiftly move between Bioc
release and Bioc devel versions.  I'm pretty sure, few users and
developers actually bothers with that.

I would like to see a model where you can instantaneously switch
between Bioconductor versions for a given R version when you launch R,
e.g. BiocManager::use("release"), BiocManager::use("devel"), and
BiocManager::use("3.16"). Under the hood, this would just reconfigure
.libPaths() and the R 'repos' option.

Now, imagine we had the latter in place, how would we look at the
dependency between Bioc version and R version?  I suspect it's the
technical problems that keep us stuck with the above half-broken model
rather than what we ideally want.


To address "how could Bioconductor test them?": I think this question
has two parts to it.

The first one is practical/financial. If we had sufficient compute
resources, we could of course test Bioc release and Bioc devel on R
oldrel, R release, and R devel. Those are the version that CRAN
guarantees all CRAN packages support. If a CRAN package fail on one of
those, it will be archived on CRAN, unless you clearly state and argue
for a give R version requirement.

On the other hand, by promising to support multiple R versions, you
constrain what new R features an R package might use. So, if
Bioconductor wants to make life easy for package developers so that
they don't have to worry about backward compatibility, then
Bioconductor might want to be more conservation and say, we only
guarantee support for R release and R devel.  Which is basically what
we have today (or at least half of the year).

To address "I guess like CRAN where as long as a package says it
depends on R >= 2.0 then you’re free to try installing on 2.0 even
though the combination has never been tested?": Yes, CRAN only tests
on R oldrel, release, and devel version.  Anything beyond that is "Use
at your own risk". I think that's perfectly fine. Some package
managers test against old versions (e.g. via GitHub Actions) and
maintain a "Depends: R (>= 2.0)" specification. There are also lots of
packages that are no longer updated and just keep working regardless
of new R releases, meaning their code is never changes, meaning if
they passed CRAN's checks on R 2.0.0 back in the days, they will still
pass those checks.  I argue that it adds unnecessary friction to users
(and developers) by going extra miles trying to prevent them from
running a Bioc devel package on an older version of R just because
"Bioconductor hasn't tested it, so we cannot guarantee it works, so we
will not allow you to install it".  My opinion is that Bioconductor
should only use on the built-in "Depends: R (>= x.y)" feature to deal
with dependencies and rely on maintainers to keep them up-to-date. But
if they don't, it's not a big deal, because the overall expectation
should be that the Bioconductor Project only guarantees things to work
for a specific R version.

I think the biggest difference between Bioconductor and CRAN is the
decision how to deal with broken package dependencies. CRAN takes the
freedom to kick packages out within two weeks. They don't have to
think about maintaining a stable "CRAN release" bundle for six months.
In contrast, Bioconductor promises to maintain "Bioc release" for six
months. OTH, I don't know how this works in practice. I know broken
packages will not make it to the next Bioc release version if they're
not fixed, but 

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

> ... I'm on Mac OS 12.5.

I've heard good things about 'rig' (The R Installation Manager;
https://github.com/r-lib/rig). It can install multiple R versions in
parallel on macOS, Windows, and Linux, without the different versions
conflicting with each other.  I recommend trying it out, because being
able to run different versions of R is always useful, even if you're
not a package maintainer.

/Henrik

On Thu, Apr 4, 2024 at 8:08 PM Anatoly Sorokin  wrote:
>
> Hi Henrik,
>
> thank you for the prompt reply. I'm on Mac OS 12.5.
>
> And regarding the linking version of Bioconductor and R my major complaint is 
> the timing, if R 4.4 hasn't been released yet, why not postpone this 
> dependency to the October release of Bioconductor?
>
> And it is also true that we have a lot of complaints from people working on 
> centrally maintained machines or HPC clusters, that they have no access to 
> the latest R versions. So sometimes even for demonstration purposes, we had 
> to install the package from the GitHub source, rather than from BiocManager.
>
> Cheers,
> Anatoly
>
> On Fri, Apr 5, 2024 at 11:57 AM Henrik Bengtsson  
> wrote:
>>
>> Hello,
>>
>> these days, it's quite straight forward to have multiple versions of R
>> installed in parallel without them conflicting with each other. I know
>> it works out of the box on MS Windows (just install all versions you'd
>> like), and I know there are various tools to achieve the same on
>> macOS.  I'm on Linux, and I build R from source, so that solves it for
>> me.  What's platform are you working on?  If you share that, I think
>> you'll get 1-2-3 instructions for how to install R 4.4 pre-release
>> from users on that operating system.
>>
>> Regarding Bioc versions being tied to specific R versions: That is a
>> design decision that goes back to day one of the Bioconductor project.
>> It's a rather big thing to change.  That said, I've always been in the
>> camp that thinks we should move away from that model for many reasons;
>> one is the friction added to developers, another is the friction added
>> to end-users, and some people may be stuck with older versions of R
>> and in no control of updating.
>>
>> Hope this helps,
>>
>> Henrik
>>
>> On Thu, Apr 4, 2024 at 7:29 PM Anatoly Sorokin  wrote:
>> >
>> > Hi all,
>> >
>> > I'm sorry for the complaint, but do you really think it is wise to make the
>> > new release dependent on the R version which has not released yet?
>> >
>> > I have a lot of R-related projects going on apart from maintaining the
>> > Bioconductor package and I'm not comfortable installing the unreleased
>> > version of R on my machine and spending time debugging it in the case of
>> > possible problems.
>> >
>> > At the same time, I have an error, possibly caused by a new version of
>> > GO.db package, which BioNAR is dependent upon and I can not fix it
>> > until the R 4.4 release on the 24th of April when I would have less than a
>> > day to fix the possible problem and fit into R CMD build and R CMD check by
>> > the Friday April 26th. Don't you think this is a rather tight time frame?
>> >
>> >
>> > Sorry once again, for the complaint.
>> >
>> > Cheers,
>> > Anatoly
>> >
>> > On Tue, Mar 26, 2024 at 11:06 PM Kern, Lori via Bioc-devel <
>> > bioc-devel@r-project.org> wrote:
>> >
>> > > Import update:  The Bioconductor Release will be May 1 following the
>> > > release of R 4.4 on April 24.
>> > >
>> > > The Bioconductor 3.18 branch will be frozen Monday April 15th. After that
>> > > date, no changes will be permitted ever on that branch.
>> > >
>> > > The deadline for devel Bioconductor 3.19 for packages to pass R CMD build
>> > > and R CMD check is Friday April 26th. While you will still be able to 
>> > > make
>> > > commits past this date, This ensures any changes pushed to
>> > > git.bioconductor.org are reflected in at least one build report before
>> > > the devel branch will be copied to a release 3.19 branch.
>> > >
>> > > Cheers,
>> > >
>> > >
>> > >
>> > > Lori Shepherd - Kern
>> > >
>> > > Bioconductor Core Team
>> > >
>> > > Roswell Park Comprehensive Cancer Center
>> > >
>> > > Department of Biostatistics & Bioinformatics
>> > >
>> > > Elm & Carlton Streets
>> > &g

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

Hello,

these days, it's quite straight forward to have multiple versions of R
installed in parallel without them conflicting with each other. I know
it works out of the box on MS Windows (just install all versions you'd
like), and I know there are various tools to achieve the same on
macOS.  I'm on Linux, and I build R from source, so that solves it for
me.  What's platform are you working on?  If you share that, I think
you'll get 1-2-3 instructions for how to install R 4.4 pre-release
from users on that operating system.

Regarding Bioc versions being tied to specific R versions: That is a
design decision that goes back to day one of the Bioconductor project.
It's a rather big thing to change.  That said, I've always been in the
camp that thinks we should move away from that model for many reasons;
one is the friction added to developers, another is the friction added
to end-users, and some people may be stuck with older versions of R
and in no control of updating.

Hope this helps,

Henrik

On Thu, Apr 4, 2024 at 7:29 PM Anatoly Sorokin  wrote:
>
> Hi all,
>
> I'm sorry for the complaint, but do you really think it is wise to make the
> new release dependent on the R version which has not released yet?
>
> I have a lot of R-related projects going on apart from maintaining the
> Bioconductor package and I'm not comfortable installing the unreleased
> version of R on my machine and spending time debugging it in the case of
> possible problems.
>
> At the same time, I have an error, possibly caused by a new version of
> GO.db package, which BioNAR is dependent upon and I can not fix it
> until the R 4.4 release on the 24th of April when I would have less than a
> day to fix the possible problem and fit into R CMD build and R CMD check by
> the Friday April 26th. Don't you think this is a rather tight time frame?
>
>
> Sorry once again, for the complaint.
>
> Cheers,
> Anatoly
>
> On Tue, Mar 26, 2024 at 11:06 PM Kern, Lori via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > Import update:  The Bioconductor Release will be May 1 following the
> > release of R 4.4 on April 24.
> >
> > The Bioconductor 3.18 branch will be frozen Monday April 15th. After that
> > date, no changes will be permitted ever on that branch.
> >
> > The deadline for devel Bioconductor 3.19 for packages to pass R CMD build
> > and R CMD check is Friday April 26th. While you will still be able to make
> > commits past this date, This ensures any changes pushed to
> > git.bioconductor.org are reflected in at least one build report before
> > the devel branch will be copied to a release 3.19 branch.
> >
> > Cheers,
> >
> >
> >
> > Lori Shepherd - Kern
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> >
> > This email message may contain legally privileged and/or confidential
> > information.  If you are not the intended recipient(s), or the employee or
> > agent responsible for the delivery of this message to the intended
> > recipient(s), you are hereby notified that any disclosure, copying,
> > distribution, or use of this email message is prohibited.  If you have
> > received this message in error, please notify the sender immediately by
> > e-mail and delete this email message from your computer. Thank you.
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Urgent minor deployment of a release?

[Henrik Bengtsson]

On Mon, Jun 19, 2023 at 5:46 PM Vincent Carey
 wrote:
>
> Hi Adam, thanks for your note.
>
> Changes to release branch sources must be limited to bug fixes or doc
> improvement.  Any new features
> must be introduced only in the devel branch.

I know about this, but I wanted to find what the document exactly says
about this. I'm sure it's documented somewhere, but I just spend 10-15
min on the website trying, but I couldn't find it.  What I was looking
specifically for was "new features".  For instance, would one be
allowed to introduce a 100% backward compatible new features to the
Bioc release branch? For instance, assume you currently have

h <- function(x, ...) {
  sum(x)
}

in the release branch, would it be okay to add:

h <- function(x, na.rm = FALSE, ...) {
  sum(x, na.rm = na.rm)
}

?  This is how base-R itself does it in their patch releases, e.g. R
4.3.0 -> R 4.3.1.

/Henrik

> Any features to be removed
> must be indicated as
> deprecated for one release and then labeled as defunct.  See
>
> http://contributions.bioconductor.org/deprecation.html
>
> for guidan
> Changes to release branch sources must be limited to bug fixes or doc
> improvement.
> ce on feature removal.
>
>
> On Mon, Jun 19, 2023 at 10:11 AM Park, Adam Keebum 
> wrote:
>
> > Hi all,
> >
> > I wonder if there is any room for deploying a modification to a released
> > library(retrofit, 3.17), which was released last month.
> >
> > We are in a progress of a paper review, so the release schedule (twice
> > each year) does not perfectly fit our need.
> >
> > Or do you think we should have used "devel" for such purposes?
> >
> > Sincerely,
> > Adam.
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> The information in this e-mail is intended only for th...{{dropped:6}}

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

Re: [Bioc-devel] missing packages on nebbiolo1

[Henrik Bengtsson]

Hello,

those errors are because they forgot to declare those packages as dependencies;

* eiR needs to add 'RSQLite' to Suggests:
* ChemmineOB needs to add 'RUnit' to Suggests:

/Henrik

On Tue, Apr 11, 2023 at 1:26 PM Kevin Horan  wrote:
>
>
> The packages eiR and ChemmineOB are failing to build because nebbiolo1
> is missing the packages RUnit and RSQLite. Could those be installed
> please? Thank you.
>
> https://master.bioconductor.org/checkResults/3.17/bioc-LATEST/eiR/nebbiolo1-checksrc.html
>
> https://master.bioconductor.org/checkResults/3.17/bioc-LATEST/ChemmineOB/nebbiolo1-checksrc.html
>
> Kevin
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Will package version 3.99.0 bump to 4.0.0?

[Henrik Bengtsson]

Sunday drive-by comment:  I guess that means that our affxparser
package which currently has version 1.71.1 in Bioc devel, will reach
1.99.0 in 13-14 years from now because of the automatic version bumps
that are done twice a year. So, if we don't touch anything, it'll roll
over to 2.0 around 2037, or so. Just an early heads-up to our
end-users :p

/Henrik

On Sun, Apr 9, 2023 at 3:46 PM Kern, Lori  wrote:
>
> Yes. If you bump to 3.99.0 now in devel, when the release happens it should 
> be released at 4.0.0
>
>
>
> Get Outlook for iOS
> 
> From: Bioc-devel  on behalf of Gordon Smyth 
> via Bioc-devel 
> Sent: Saturday, April 8, 2023 3:47:00 AM
> To: bioc-devel@r-project.org 
> Cc: Andy Chen 
> Subject: [Bioc-devel] Will package version 3.99.0 bump to 4.0.0?
>
> I want edgeR to bump to a major new version 4.0.0 for the Bioconductor 3.17 
> release this month.
>
> If I set the edgeR version to 3.99.0 on the developmental repository now, 
> will that bump to version 4.0.0 for the Bioconductor 3.17 release?
>
> Thanks
> Gordon
>
> --
> Professor Gordon K Smyth
> Joint Head, Bioinformatics Division
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1R7vQW9lEE-wvyqAgCASzumbItUssse3KzL55r0yXrt0_Z9llDNgEwmi8TXBCM7ZE_toIUMD9iahxSewi5VTWOYcwCkS2wj3RhkdG-F8x3ynIWVR7tNm5HVrTTr1xg9NKJivCQCkuQjE2aUAbg-3l519AFd8seJkl9wNk3VJoojUrvRJmcoFYv18-_Icb1QrvE9q2McMsLbf-abFreI2H1PCFElkbjMljmPnYSPNcOihoD-wIHApdmtYpezYKRZtOd4NTJNdWTlQ1dZC0qv2UX_M2dTdDi4MwC25CIz8Mmx8f4pHN6Que75v4DFGvqJJ6/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Error building package

[Henrik Bengtsson]

Hello,

add 'BiocStyle' to Suggests: in your DESCRIPTION file to fix this.

For details, see


/Henrik

On Thu, Apr 6, 2023 at 8:12 AM ELENI ADAM  wrote:
>
> Dear all,
>
> I am the creator of the hummingbird package (
> https://bioconductor.org/packages/devel/bioc/html/hummingbird.html ) and
> suddenly today I noticed that the check is failing in nebbiolo1 for the
> devel version, even though I did not make any change to the package, it was
> building fine the previous days. I am not sure why this has happened?
>
> The error message occurring states:
> Error(s) in re-building vignettes:
>   ...
> --- re-building ‘hummingbird.Rmd’ using rmarkdown
> Error: processing vignette 'hummingbird.Rmd' failed with diagnostics:
> there is no package called ‘BiocStyle’
> --- failed re-building ‘hummingbird.Rmd’
>
> And this is only happening in the devel version of the package, which is
> identical to the release. And only happening in nebbiolo1.
>
> I am also worried because this happened now and the deadline for the new
> release is too close.
>
> Could you please help me?
>
> Thank you,
> Eleni Adam
> *PhD Candidate in CS*
> *Old Dominion University*
> *Norfolk, VA, USA*
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Missing dependency errors on nebbiolo1 (Bioc 3.17)

[Henrik Bengtsson]

On Tue, Apr 4, 2023 at 2:44 AM Oleksii Nikolaienko
 wrote:
>
> Hi,
> maybe because BiocStyle is not listed as a dependency or suggested package
> in DESCRIPTION?
> More info here: https://github.com/Bioconductor/BBS/issues/248

Yes, this is why. The package needs 'BiocStyle' to build the vignette,
and therefore it needs to be declared. Some other packages forgot to
declare 'RUnit' needed for the unit tests. We'll also see packages
that rely on non-declared annotation packages. These new checks were
introduced for Bioc devel(*) checks and aligns with how this already
works on CRAN since a long time.

(*) I'm not 100% sure, but I believe the reason you only see it on the
Linux server is that that's the only one that runs 'R CMD check' on
vignettes. Checking vignettes takes time, so the decision was to do
that only one platform. Since 'BiocStyle' is only involved for
vignettes, this is why that particular package gets flagged only
there.  Packages that forgot to add 'RUnit' to suggests, will get an
error on all platforms.

Adding 'BiocStyle' to Suggests: in the package DESCRIPTION file solves
this problem.

/Henrik


>
> Best,
> Oleksii
>
> On Tue, 4 Apr 2023 at 11:22, Rainer Johannes 
> wrote:
>
> > Dear all,
> >
> > I'm continuing to see some strange dependency problems for packages on the
> > linux build system for Bioconductor 3.17. First time I've seen them where
> > on the build report for snapshot 2023-03-31, and they are still there for
> > snapshot date 2023-04-02 (build report from 2023-04-03). What I've seen so
> > far is that most are related to `BiocStyle` missing.
> >
> > Some examples are:
> > - ROC (missing BiocStyle)
> > - SCATE (missing BiocStyle)
> > - SC3 (missing BiocStyle)
> > - scTHI (missing BiocStyle)
> >
> > Since they are only present on the linux build system - maybe that's
> > something related to the setup on that particular server? Or the R version
> > used there does not properly get all dependencies of packages?
> >
> > cheers, jo
> >
> > ---
> > Johannes Rainer, PhD
> >
> > Eurac Research
> > Institute for Biomedicine
> > Via A.-Volta 21, I-39100 Bolzano, Italy
> >
> > email: johannes.rai...@eurac.edu
> > github: jorainer
> > mastodon: jorai...@fosstodon.org
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] PeacoQC Bioc version not in line with github repo

[Henrik Bengtsson]

> Indeed, although PeacoQC version on Bioc is higher (1.8) than in github
repo (1.7.3), the latest commits have not been included.

This is explained by Bioconductor bumping versions automatically when
there's a new release cycle. So, in this case it went from something like
1.7.2 to 1.8.0 on the Bioconductor side, while your contribution in 1.7.3
is still only in the GitHub side (because it was never pushed up to
Bioconductor).

/Henrik

On Thu, Dec 15, 2022, 04:19 Kern, Lori 
wrote:

> Besides reminding them to keep both in sync there is not much more the
> Bioc Devel can do.  It is up to the maintainers to properly maintain their
> packages and push to the appropriate places to make it available to the
> community.
>
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Philippe
> Hauchamps 
> Sent: Thursday, December 15, 2022 4:09 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] PeacoQC Bioc version not in line with github repo
>
> Hi dear Bioc-devel community,
>
> I am developing a package, CytoPipeline, which depends a.o. on PeacoQC
> Bioc package. A few months ago, I contributed to PeacoQC with a PR, in
> order to solve an issue :
>
>
> https://secure-web.cisco.com/1kHaxHWvrkJ6pmvMy5l11CQpE8JgnouzBYno3I-i9g9wZ-q7AQ_bG1vGgaLMp-LdWnFUJjuNlZFQgO9JABK6ct50bePM4LthauLpL_xlbHzHAQH7cuy9RWzJ-lgUPnXBWkNCmWeDBxugF5OBSkJTUZFowlYTknhOhJxfEMyIiFUAukcq1jC8qBgdKD8P9tUZlu3ScUU-Mj9_4vH2cznII7rFPQhVqKlrqUsEG8uXKZz83XGxZZi51OkoL0FibgYpJKAoASPM0F2Odv0k5qvpjnRYISpGIwaRSEHrGVDKwEkNkeaZeYJGD43FHT96CPpmtGa0vDNFypb26tZPTZuLWzA/https%3A%2F%2Fgithub.com%2Fsaeyslab%2FPeacoQC%2Fpull%2F9
>
>
> https://secure-web.cisco.com/18j7J58SAasdW-RIw2_2x4Ap2qzc4hVoqLUkTzo1Z6tU0s2Bo1wokU4CGAIxAT5Ab2aqkUMHg2JzA4cUPORI4y5ZVgxJ3S5s_l6Y9GwtAcXp3Vo9WckqO41lnnsjzFvo9CBoj1yweLFfiZavDovFlwZt4UBlmXHPwRvs176H3Y8Kte87L-psj5Gtf1sVJUatcGs6OaD3AjsgRG5KYeH-H00ceCHAbO86U6MTobby02TO7eYSX_ZOwPjgZZHbTsVGKAWEbdt3PqmlSURhtKzNrsNwcknPunJZyyQEtf2wRHXEuMA_GincdXB-KypjzcKZDw4SB44B3ybSExbSYEYyNtQ/https%3A%2F%2Fgithub.com%2Fsaeyslab%2FPeacoQC%2Fissues%2F8
>
>
> My PR was subsequently validated by the package maintainer and integrated
> into the code base (June 2022).
>
> However, I recently noticed that the latest changes made on the PeacoQC
> github repo, have not been ported to the BioC git repository.  Indeed,
> although PeacoQC version on Bioc is higher (1.8) than in github repo
> (1.7.3), the latest commits have not been included.
>
> I already posted a message linked to the PeacoQC github issue, to request
> an update of the Bioc repo.
> However, is there possibly some action that could be done from Bioc Devel
> side to gently push for this update ?
>
> Thanks,
>
> Philippe
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/11IzcX-KI42HSp1tEYgBqRq-AGft0wfLvPlpu5CDHoCQFUSDsIXhMFc1C3nRD2yq_J1N4ohPYtZdK74Nw7qKNwk9oEuWrOn9XiYM2s2GF1PKt81NsiLynu19oaY5se0MjSbBPgBeI3VbetQKemQbPfunfK4tateHwh0myCnSR0omnIOY9qD0wX-XiG8mzjV6PZzTm-padKVvth_0wYJAJLJsGU-2IL8cwJu8m6feRLaI-CceRuHg91j5WhHEvX4l_5JRNxWm5-x-H3XRygEsavUSeNCg7N68nzMvoGTRQl5rhl7F7ELHvVbV3FCOmogVzdv6Kr1nON12ua09a7_YA7w/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Packages failing Development build due to LaTex problem in .Rnw vignette

[Henrik Bengtsson]

Yes, it was just fixed in R-devel, cf.
https://bugs.r-project.org/show_bug.cgi?id=18443.

/Henrik

On Fri, Dec 9, 2022 at 7:38 AM Lluís Revilla  wrote:
>
> Hi Rory,
>
> There was a recent change in R devel (
> https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
>  - sessionInfo() records (and by default prints) the system time zone as
> part of the locale information.
> It was reported a couple of days ago in the R-devel mailing list by Henrik
> Bengtsson, that time zones with underscores caused problems which seems to
> be your case with the New_York time zone.
> This will probably be fixed at the R core level.
>
> The other option would be to set the local time to another timezone (you or
> the Bioconductor core team).
>
> Best,
>
> Lluís
>
> On Fri, 9 Dec 2022 at 16:01, Rory Stark via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > My packages are failing in the Development build due to something going
> > wrong processing the .Rnw vignettes. Looking around I see a number of other
> > packages with similar errors.
> >
> > They mostly include this error:
> >
> > LaTeX errors:
> > ! Missing $ inserted.
> > 
> > $
> > l.4064   \item Time zone America/New_
> >  York
> > ! LaTeX Error: Command \item invalid in math mode.
> >
> >
> > although the details differ on each platform.
> >
> > Something has changed in the environment (headers?) that I can't quite
> > track down (the source documents have not changed). Is this a known issue?
> > Any suggestions on resolving it?
> >
> > Rory
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Henrik Bengtsson]

> Anyways, that's hundreds of \items that I need to fix in a dozen of packages. 
> Not fun!

A great opportunity to freshen up your 'sed' skills. (I think it's
possible to use 'sed' here, but 100% sure)

/Henrik

On Thu, Dec 1, 2022 at 12:27 PM Hervé Pagès  wrote:
>
> Itemizing brings semantics and structure. Plus, the \preformatted
> solution doesn't look good either IMO. FWIW I mostly care about what I
> see when I open the man page in a terminal with ?. I don't care so
> much about the PDF manual, never look at it.
>
> So I'm going to switch from
>
>\item{}{\code{show(x)}:
>  ...
>}
>
> to
>
>\item{\code{show(x)}:}{
>  ...
>}
>
> as suggested by Henrik.
>
> I actually tried the latter many years ago and compared with the former
> and for some reason decided to go for the former. But now I like the
> rendering of the latter better. Don't know if it has changed or if my
> taste has changed ;-)
>
> Anyways, that's hundreds of \items that I need to fix in a dozen of
> packages. Not fun! Also the thing with the exact location of the colon
> is very error prone. As Michael said, it would be nice to be able to
> achieve this with a simpler/more natural syntax.
>
> H.
>
> On 30/11/2022 10:47, Deepayan Sarkar wrote:
> > On Wed, Nov 30, 2022 at 9:51 PM Martin Morgan 
> > wrote:
> >
> >> I recently made the change Henrik suggests in the ‘devel’ but not
> >> ‘release’ branch of BiocParallel, so the manuals can be compared. Take a
> >> look at the ‘Constructor’ and ‘Accessors: Logging and results’ sections of
> >> the ‘SnowParam-class.Rd’ man page, starting on p. 53 of the PDF.
> >>
> >>
> >> https://bioconductor.org/packages/release/bioc/manuals/BiocParallel/man/BiocParallel.pdf
> >>
> >>
> >> https://bioconductor.org/packages/devel/bioc/manuals/BiocParallel/man/BiocParallel.pdf
> >>
> >> I think in \item{}{bar} the  is not wrapped, so runs off the
> >> margin in the devel ‘Constructor’ section.
> >
> > This should ideally use \preformatted{}, but R-exts says that "Due to
> > limitations in LaTeX as of this writing, this macro may not be nested
> > within other markup macros other than \dQuote and \sQuote, as errors or bad
> > formatting may result."
> >
> > Still, in this particular case, and possibly others like it, free-format
> > text (instead of itemizing) might work better:
> >
> > \section{Constructor}{
> >
> >  \preformatted{SnowParam(workers = snowWorkers(), type=c("SOCK", "MPI"),
> >tasks = 0L, stop.on.error = FALSE,
> >progressbar = FALSE, RNGseed = NULL,
> >timeout = Inf, exportglobals = TRUE,
> >exportvariables = TRUE,
> >log = FALSE, threshold = "INFO", logdir = NA_character_,
> >resultdir = NA_character_, jobname = "BPJOB",
> >manager.hostname = NA_character_,
> >manager.port = NA_integer_,
> >...)}
> >  Returns an object representing a SNOW cluster. The cluster is not
> >  created until \code{bpstart} is called. Named arguments in \code{...}
> >  are passed to \code{makeCluster}.
> >
> > }
> >
> > Even if we retain the status quo, the \item{}{\code{...}{}} version of this
> > (as in the release branch) is by no means nice-looking.
> >
> > Best,
> > -Deepayan
> >
> > The shorter items in the ‘Accessors: Logging and results’ section look
> >> almost identical, with a little extra (unnecessary) indentation under the
> >> original formatting.
> >>
> >> I changed the ‘Accessors: Back-end control’ to an itemized list, since
> >> there was no description associated with each item. This adds bullets.
> >>
> >> The commit is at
> >>
> >>
> >> https://code.bioconductor.org/browse/BiocParallel/commit/4e85b38b92f2adb68fe04ffb0476cbc47c1241a8
> >>
> >> (as well as https://github.com/Bioconductor/BiocParallel...)
> >>
> >> Martin
> >>
> >> From: Bioc-devel  on behalf of Martin
> >> Maechler 
> >> Date: Wednesday, November 30, 2022 at 6:28 AM
> >> To: Michael Lawrence (MICHAFLA) 
> >> Cc: bioc-devel@r-project.org , Kurt Hornik <
> >> kurt.hor...@wu.ac.at>
> >> Subject: Re: [Bioc-devel] S4 Methods Documentation Convention Triggers
> >> Warnings
> >>> Michael Lawrence \(MICHAFLA\) via Bioc-devel
> >>>  on Mon, 28 Nov 2022 12:11:00 -0800 writes:
> >>  > It may be worth revisiting why we arrived at this convention in the
> >> first
> >>  > place and see whether the Rd system can be enhanced somehow so that
> >> we can
> >>  > achieve the same effect with a more natural syntax.
> >>
> >>  > Michael
> >>
> >>
> >> Yes, I agree.
> >>
> >> It may be that in the distant past, Henrik's suggestion
> >> (a version of which I am using myself a lot in *.Rd -- mostly
> >>   *not* related to S4)
> >> did not work correctly, but I know it has worked for years now,
> >> as I use it "all the time".
> >> and not just I.
> >>
> >> If I grep in R's *base* package alone,
> >>
> >> inside ./R/src/library/base/man/
> >>
> >> grep --color -nH --null -e 

Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Henrik Bengtsson]

> I think in \item{}{bar} the  is not wrapped, so runs off the margin 
> in the devel ‘Constructor’ section.

Would a hack be to split up the \code{} in multiple ones, e.g.

\item{
   \code{SnowParam(workers = snowWorkers(), type=c("SOCK", "MPI"),}
 \code{tasks = 0L, stop.on.error = FALSE,}
 \code{progressbar = FALSE, RNGseed = NULL,}
 \code{timeout = Inf, exportglobals = TRUE,}
 \code{exportvariables = TRUE,}
 \code{log = FALSE, threshold = "INFO", logdir = NA_character_,}
 \code{resultdir = NA_character_, jobname = "BPJOB",}
 \code{manager.hostname = NA_character_,}
 \code{manager.port = NA_integer_,}
 \code{...)}}:}{

Does that line wrap?

/Henrik

On Wed, Nov 30, 2022 at 8:21 AM Martin Morgan  wrote:
>
> I recently made the change Henrik suggests in the ‘devel’ but not ‘release’ 
> branch of BiocParallel, so the manuals can be compared. Take a look at the 
> ‘Constructor’ and ‘Accessors: Logging and results’ sections of the 
> ‘SnowParam-class.Rd’ man page, starting on p. 53 of the PDF.
>
> https://bioconductor.org/packages/release/bioc/manuals/BiocParallel/man/BiocParallel.pdf
>
> https://bioconductor.org/packages/devel/bioc/manuals/BiocParallel/man/BiocParallel.pdf
>
> I think in \item{}{bar} the  is not wrapped, so runs off the margin 
> in the devel ‘Constructor’ section. The shorter items in the ‘Accessors: 
> Logging and results’ section look almost identical, with a little extra 
> (unnecessary) indentation under the original formatting.
>
> I changed the ‘Accessors: Back-end control’ to an itemized list, since there 
> was no description associated with each item. This adds bullets.
>
> The commit is at
>
> https://code.bioconductor.org/browse/BiocParallel/commit/4e85b38b92f2adb68fe04ffb0476cbc47c1241a8
>
> (as well as https://github.com/Bioconductor/BiocParallel...)
>
> Martin
>
> From: Bioc-devel  on behalf of Martin 
> Maechler 
> Date: Wednesday, November 30, 2022 at 6:28 AM
> To: Michael Lawrence (MICHAFLA) 
> Cc: bioc-devel@r-project.org , Kurt Hornik 
> 
> Subject: Re: [Bioc-devel] S4 Methods Documentation Convention Triggers 
> Warnings
> > Michael Lawrence \(MICHAFLA\) via Bioc-devel
> > on Mon, 28 Nov 2022 12:11:00 -0800 writes:
>
> > It may be worth revisiting why we arrived at this convention in the 
> first
> > place and see whether the Rd system can be enhanced somehow so that we 
> can
> > achieve the same effect with a more natural syntax.
>
> > Michael
>
>
> Yes, I agree.
>
> It may be that in the distant past, Henrik's suggestion
> (a version of which I am using myself a lot in *.Rd -- mostly
>  *not* related to S4)
> did not work correctly, but I know it has worked for years now,
> as I use it "all the time".
> and not just I.
>
> If I grep in R's *base* package alone,
>
> inside ./R/src/library/base/man/
>
> grep --color -nH --null -e '\\item{\\code{' *.Rd
>
> starts with
>
> agrep.Rd
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Henrik Bengtsson]

What about:

  \item{\code{show(x)}}{
  Displays the first five and last five elements.
}

?

On Sat, Nov 26, 2022, 23:00 Dario Strbenac via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Good day,
>
> For a long time, it has been a convention to document S4 methods in the
> format:
>
> \section{Displaying}{
>   In the code snippets below, \code{x} is a GRanges object.
>   \describe{
> \item{}{
>   \code{show(x)}:
>   Displays the first five and last five elements.
> }
>   }
> }
>
> In R Under Development, this is now a warning:
>
> * checking Rd files ... WARNING
> checkRd: (5) GRanges-class.Rd:115-165: \item in \describe must have
> non-empty label.
>
> This affects my own package as well as the core Bioconductor packages
> which I used as inspiration for designing my pacakge documentation seven
> years ago. What should the new convention be? Or could R developers be
> convinced to get rid of this check before this prototype is released?
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Interpreting BiocCheck output

[Henrik Bengtsson]

I'm throwing in another 1 cent.

I agree that utils::globalVariables() is risky; since it goes in the
root of the package code, it applies to *all* functions in the
package, which is a bit too broad of a stroke for my taste.  The way I
deal with false globals from non-standard evaluation (NSE), is to
declare them a as dummy variables local to the function.  In this
case, I would use:

myfcn <- function() {
  ## To please R CMD check
  mpg <- cyl <- NULL

  mtcars |> select(mpg, cyl) |> head(3)
}


ADVANCED:

To avoid those dummy assignments from taking place in every call, one
can also do:

myfcn <- local({
  ## To please R CMD check
  mpg <- cyl <- NULL

  function() {
mtcars |> select(mpg, cyl) |> head(3)
  }
})

which is also a bit cleaner, because it keeps the original function body as-is.


REALLY ADVANCED:
If you want to be fancy, you can even protect against mistakes by using:

myfcn <- local({
  ## To please R CMD check
  mpg <- cyl <- NULL

  ## Prevent developer mistakes
  lapply(names(environment()), function(name, envir) {
delayedAssign(
  name,
  stop(sprintf("INTERNAL ERROR: %s is not declared",
sQuote(name)), call. = FALSE),
  assign.env = envir
)
  }, envir = environment())

  function() {
mtcars |> select(mpg, cyl) |> head(3)
  }
})

The latter would throw an error, if you actually end up using 'mpg' or
'cyl' in a non-NSE way.

/Henrik

On Fri, Oct 7, 2022 at 12:29 PM Martin Morgan  wrote:
>
> Just my two cents, but I don’t think using `globalVariables()` is a good idea 
> in a package – it’s too easy to say that R should ignore a variable that it 
> should not.
>
> In the context of dplyr, the alternative is to `importFrom dplyr .data` or to 
> use ‘standard’ evaluation, depending on circumstance
>
>
> > mtcars |> as_tibble() |> filter(.data$mpg > 30)  # .data is imported, so 
> > known…
> # A tibble: 4 × 11
> mpg   cyl  disphp  dratwt  qsecvsam  gear  carb
> 
> 1  32.4 4  78.766  4.08  2.2   19.5 1 1 4 1
> 2  30.4 4  75.752  4.93  1.62  18.5 1 1 4 2
> 3  33.9 4  71.165  4.22  1.84  19.9 1 1 4 1
> 4  30.4 4  95.1   113  3.77  1.51  16.9 1 1 5 2
> > mtcars |> select("mpg", "cyl") |> head(3)  # `”mpg”` and `”cyl”` are 
> > character vectors, not symbols…
>mpg cyl
> Mazda RX4 21.0   6
> Mazda RX4 Wag 21.0   6
> Datsun 71022.8   4
>
> Martin
>
> From: Bioc-devel  on behalf of Marcel Ramos 
> 
> Date: Friday, October 7, 2022 at 3:07 PM
> To: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Interpreting BiocCheck output
> Hi Giulia,
>
> Thanks for sharing.
> I took a look at https://github.com/calabrialab/ISAnalytics and I'm glad
> you resolved the issue.
>
> Just a reminder, you can also use `utils::globalVariables('.')` in your
> package for functions
> that use `'.'` (and other symbols) as a variable, e.g. in `purrr::pmap`.
>
> Best regards,
>
> Marcel
>
>
> On 10/6/22 4:34 AM, Giulia Pais wrote:
> >
> > Hi, thanks for the reply. I managed to fix the first error as it was a
> > minor issue in the code, while for the second one I don’t have a
> > solution since the problem appears only locally and not on Biconductor
> > after the build.
> >
> > Just for reference the package is ISAnalytics and the BiocCheck
> > version is the latest one.
> >
> > Thanks again,
> >
> > Giulia
> >
> > *From: *Bioc-devel  on behalf of
> > Marcel Ramos 
> > *Date: *Wednesday, 2022October5 at 23:48
> > *To: *bioc-devel@r-project.org 
> > *Subject: *Re: [Bioc-devel] EXTERNAL: Interpreting BiocCheck output
> >
> > Hi Giulia,
> >
> > Are you using a recent version of BiocCheck?
> >
> > If so, check the bottom of the BiocCheck::BiocCheck():
> >
> > ---
> > See the .BiocCheck folder and run
> >  browseVignettes(package = 'BiocCheck')
> > for details.
> > ---
> >
> > Can you provide more details, e.g., the repository of the package?
> >
> > Thanks.
> >
> > Best regards,
> >
> > Marcel
> >
> > On 10/4/22 4:44 AM, Giulia Pais wrote:
> > > Hello,
> > > I�m having some issues in interpreting BiocCheck outputs, maybe
> > someone can tell me how to fix the issues.
> > >
> > > I�ve got 2 main issues that cause the check to fail after normal
> > CRAN check has passed:
> > >
> > >1.  I get this error message
> > >
> > > * Checking if other packages can import this one...
> > >
> > >  * ERROR: Packages providing 2 object(s) used in this package
> > should be imported in the NAMESPACE file, otherwise packages importing
> > >
> > >this package may fail.
> > >
> > >
> > >
> > > However it is nowhere mentioned which packages they are and where
> > those objects are instantiated so I have no clue how to solve this one
> > >
> > >1.  Since previous version of the package, which built and passed
> > checks without issues, I�ve been using a custom *.Rmd file placed in
> > inst/rmd in the vignette to recycle the same chunk of code and
> 

Re: [Bioc-devel] Use set.seed inside function

[Henrik Bengtsson]

The easiest is to use withr::with_seed(), e.g.

> withr::with_seed(seed = 42L, randomcoloR::distinctColorPalette(6))
[1] "#A0E1BC" "#B8E363" "#D686BE" "#DEA97F" "#B15CD8" "#A2B9D5"
> withr::with_seed(seed = 42L, randomcoloR::distinctColorPalette(6))
[1] "#A0E1BC" "#B8E363" "#D686BE" "#DEA97F" "#B15CD8" "#A2B9D5"

It works by undoing globalenv()$.Random.seed after the random number
generator has updated.  If you want to roll your own version of this,
you need to make sure to handle the special case when there is no
pre-existing .Random.seed in globalenv().

Regarding packages and functions changing the random seed via a
set.seed() [without undoing it]: this should *never* be done, because
it will wreak havoc on a analyses and studies that rely on random
numbers.  My rule of thumb: only the end-user should be allowed to use
set.seed(), which should typically be done at the top of their R
scripts.

/Henrik

On Mon, Nov 29, 2021 at 1:23 PM Meng Chen  wrote:
>
> Thanks. I think it may work in theory, generating "enough" distinct colors
> is fairly easy. Then the problem will be how to find a subset of colors of
> size n, and the selected colors are still most distinguishable. I think I
> will do this with my eyes if no other methods, a tedious job.
> But at least for my curiosity, I still want to know if there are other ways
> to achieve this. I feel like 80% of people who use the distinctColorPallete
> function actually don't need the "random" feature :) Thanks.
>
> On Mon, Nov 29, 2021 at 9:39 PM James W. MacDonald  wrote:
>
> > It appears that you don't actually want random colors, but instead you
> > want the same colors each time. Why not just generate the vector of 'random
> > distinct colors' one time and save the vector of colors?
> >
> > -Original Message-
> > From: Bioc-devel  On Behalf Of Meng Chen
> > Sent: Monday, November 29, 2021 3:21 PM
> > To: bioc-devel@r-project.org
> > Subject: [Bioc-devel] Use set.seed inside function
> >
> > Dear BioC team and developers,
> >
> > I am using BiocCheck to check my package, it returns a warning:
> > " Remove set.seed usage in R code"
> >
> > I am using "set.seed" inside my functions, before calling function
> > distinctColorPalette (randomcoloR package) in order to generate
> > reproducible "random distinct colors". So what would be the best practice
> > to solve this warning? I think 1. use set.seed and don't change anything.
> > 2. use the set.seed function, but include something like below inside the
> > function *gl.seed <- .Random.seed* *on.exit(assign(".Random.seed", gl.seed,
> > envir = .GlobalEnv))* 3. use some other functions for the purpose
> >
> > Any suggestions will be appreciated. Thanks.
> > --
> > Best Regards,
> > Chen
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> Best Regards,
> Chen
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Package name

[Henrik Bengtsson]

For CRAN packages it's easy. Packages on CRAN are eternal. They may be
archived, but they are never removed, so in a sense they're always
"currently on CRAN". Archived packages may still be installed, but only
with some efforts of the user. Some packages go in an out of "archived"
status depending how quick the maintainer fixes issues. Because of this, I
cannot really see how a CRAN package name can be "reused" by anyone else
without a formal handover agreement between old and new maintainers. Even
so, I think CRAN needs to approve on the "update" in order to unarchive it.

Personally, I'd argue the same should apply to Bioconductor packages.
Reusing package names for other purposes/different APIs is just asking for
troubles, e.g. when it comes to future scientists trying to reproduce
legacy results.

/Henrik

On Fri, Oct 22, 2021, 03:02 Wolfgang Huber  wrote:

> This is probably a niche concern, but  I’d find it a pity if a good
> package name (*) became unavailable forever, esp. if it refers to a
> real-world concept not owned by the authors of the original package.
> Perhaps we could allow re-using a name after a grace period (say 1 or 2
> years)?
> To be extra safe, one could also require the first version number of the
> new package be much higher than the last version of the old (dead) package.
>
> (*) One example I have in mind where we re-used the name of an extinct
> project is rhdf5.
>
> Kind regards
> Wolfgang
>
> > Il giorno 21ott2021, alle ore 13:39, Kern, Lori
>  ha scritto:
> >
> > Good point.  I'll open an issue on the github to fix.
> >
> >
> > Lori Shepherd
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> > 
> > From: Bioc-devel  on behalf of
> Laurent Gatto 
> > Sent: Thursday, October 21, 2021 12:53 AM
> > To: bioc-devel@r-project.org 
> > Subject: [Bioc-devel] Package name
> >
> > The Package Guidelines for Developers and Reviewers say that:
> >
> > A package name should be descriptive and should not already exist as a
> current package (case-insensitive) in Bioconductor nor CRAN.
> >
> > The sentences says current packages - does that imply that names of
> packages that have been archived (on CRAN) or deprecated (on Bioconductor)
> are available? This is likely to lead to serious confusion.
> >
> > Laurent
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://secure-web.cisco.com/18tLjfrOdSZ-K_8neKbEy5VWz_fgbNJthSRI3zRVyXXtc-p9kCgNhG51wWXnY7UGhy4yP_imTwLGoP4BCIicB_fqzg9U937WF_IJiOPJh7NnfQXFLeEV-SiiJJ1eCyN2vaJFacWPvahAlN135mDHZNw_peW0Yl4BOq8m2QBMh4i952Nt6oghMQpSWSjaP_2bN4VKIBT2ZP-A7pDqddlOSeCCaMEKJZp_6w1WthdY69MB6lAbsF-i9uX3JVNSCmAlXW3YMNOfVEBijto4EJaGIUJMJwGX_vec9kTf9gtFiYztotSHNfquFZ4GlaHmXeHwPaBEtazOY5fPiuzLjzDK52Q/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> >
> >
> >
> > This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Too many dependencies / MultiAssayExperiment + rtracklayer

[Henrik Bengtsson]

If you're willing to depend on R (>= 4.0.0), then tools::R_user_dir() can
replace the 'rappdirs' package.

/Henrik

On Mon, Oct 18, 2021, 09:05 Shraddha Pai  wrote:

> Hi all,
> Despite moving rarely-used packages to Suggests and eliminating some (e.g.
> TCGAutils), the number of dependencies is still listed as 200 for our
> package netDx.
> https://www.bioconductor.org/packages/devel/bioc/html/netDx.html#since
> Is there anything else we can do to cut down on dependencies?
>
> Thank you,
> Shraddha
>
> On Tue, Sep 21, 2021 at 5:35 PM Shraddha Pai 
> wrote:
>
> > Hi Michael,
> > Thanks! Looks like the package trying to load 'rtracklayer' was
> > 'TCGAutils' (see graph from Zugang above, generated using pkgndep - looks
> > to be quite useful). Turns out TCGAutils really wasn't necessary for my
> > package so I just took it out and removed all associated dependencies -
> > mercifully an easier fix.
> >
> > Thanks for your help,
> > Shraddha
> >
> > On Mon, Sep 20, 2021 at 2:57 PM Michael Lawrence <
> > lawrence.mich...@gene.com> wrote:
> >
> >> Hi Shraddha,
> >>
> >> From the rtracklayer perspective, it sounds like Rsamtools is
> >> (indirectly) bringing in those system libraries. I would have expected
> >> zlibbioc to cover the zlib dependency, and perhaps bz2 and lzma
> >> support is optional. Perhaps a core member could comment on that.
> >>
> >> In the past, I've used this package
> >> https://github.com/Bioconductor/codetoolsBioC to identify missing
> >> NAMESPACE imports. In theory, you could remove the rtracklayer import
> >> and run functions in that package to identify the symbol-level
> >> dependencies. The output is a bit noisy though.
> >>
> >> Btw, using @importFrom only allows you to be selective of symbol-level
> >> dependencies, not package-level.
> >>
> >> Michael
> >>
> >> On Mon, Sep 20, 2021 at 11:37 AM Shraddha Pai  >
> >> wrote:
> >> >
> >> > Hello again,
> >> > I'm trying to simplify the dependencies for my package "netDx", make
> it
> >> > easier to install. It's currently got over 200(!) + some Unix
> libraries
> >> > that need to be installed.
> >> >
> >> > 1. I ran pkgDepMetrics() from BiocPkgTools to find less-needed pkgs,
> and
> >> > the package with the most dependencies is MultiAssayExperiment (see
> >> below
> >> > email). I'm using MAE to construct a container - is there a way to use
> >> > @importFrom calls to reduce MAE dependencies?
> >> >
> >> > 2. Another problem package is rtracklayer which requires Rhtslib,
> which
> >> > requires some unix libraries: zlib1g-dev libbz2-dev liblzma-dev. I'm
> not
> >> > sure which functionality in the package requires rtracklayer - how
> can I
> >> > tell? Is there a way to simplify / reduce these deps so the user
> doesn't
> >> > have to install all these unix packages?
> >> >
> >> > 3. Are there other "problem packages" you can see that I can remove?
> >> Let's
> >> > assume for now ggplot2 stays because people find it useful to have
> >> plotting
> >> > functions readily available.
> >> >
> >> > Thanks very much in advance,
> >> > Shraddha
> >> > ---
> >> > "ImportedAndUsed" "Exported" "Usage" "DepOverlap" "DepGainIfExcluded"
> >> > "igraph" 1 782 0.13 0.05 0
> >> > "ggplot2" 1 520 0.19 0.19 0
> >> > "pracma" 1 448 0.22 0.03 0
> >> > "plotrix" 1 160 0.62 0.03 1
> >> > "S4Vectors" 2 283 0.71 0.03 0
> >> > "grDevices" 1 112 0.89 0.01 0
> >> > "httr" 1 91 1.1 0.05 0
> >> > "scater" 1 85 1.18 0.4 0
> >> > "utils" 3 217 1.38 0.01 0
> >> > "GenomeInfoDb" 1 60 1.67 0.06 0
> >> > "stats" 12 449 2.67 0.01 0
> >> > "bigmemory" 1 35 2.86 0.03 3
> >> > "RCy3" 12 386 3.11 0.32 18
> >> > "BiocFileCache" 1 29 3.45 0.23 3
> >> > "glmnet" 1 24 4.17 0.07 2
> >> > "parallel" 2 33 6.06 0.01 0
> >> > "combinat" 1 13 7.69 0.01 1
> >> > "MultiAssayExperiment" 4 46 8.7 0.22 1
> >> > "foreach" 2 23 8.7 0.02 0
> >> > "graphics" 8 87 9.2 0.01 0
> >> > "GenomicRanges" 15 106 14.15 0.08 0
> >> > "rappdirs" 1 7 14.29 0.01 0
> >> > "reshape2" 1 6 16.67 0.05 0
> >> > "RColorBrewer" 1 4 25 0.01 0
> >> > "netSmooth" 1 3 33.33 0.82 3
> >> > "Rtsne" 1 3 33.33 0.02 0
> >> > "doParallel" 1 2 50 0.03 0
> >> > "ROCR" 2 3 66.67 0.05 4
> >> > "clusterExperiment" NA 122 NA 0.74 0
> >> > "IRanges" NA 255 NA 0.04 0
> >> >
> >> >
> >> > --
> >> >
> >> > *Shraddha Pai, PhD*
> >> > Principal Investigator, OICR
> >> > Assistant Professor, Department of Molecular Biophysics, University of
> >> > Toronto
> >> > shraddhapai.com; @spaiglass on Twitter
> >> > https://pailab.oicr.on.ca
> >> >
> >> >
> >> > *Ontario Institute for Cancer Research*
> >> > MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario,
> Canada
> >> M5G
> >> > 0A3
> >> > *@OICR_news*  | *www.oicr.on.ca*
> >> > 
> >> >
> >> >
> >> >
> >> > *Collaborate. Translate. Change lives.*
> >> >
> >> >
> >> >
> >> > This message and any attachments may contain confidential and/or
> >> privileged
> >> > information for the sole use of the intended recipient. Any 

Re: [Bioc-devel] Strange "internal logical NA value has been modified" error

[Henrik Bengtsson]

In addition to checking with Valgrind, the ASan/UBsan and rchk
platforms on R-Hub (https://builder.r-hub.io/) can probably also be
useful;

> rhub::check(platform = "linux-x86_64-rocker-gcc-san")
> rhub::check(platform = "ubuntu-rchk")

/Henrik



On Tue, Oct 12, 2021 at 4:54 PM Martin Morgan  wrote:
>
> It is from base R
>
>   
> https://github.com/wch/r-source/blob/a984cc29b9b8d8821f8eb2a1081d9e0d1d4df56e/src/main/memory.c#L3214
>
> and likely indicates memory corruption, not necessarily in the code that 
> triggers the error (this is when the garbage collector is triggered...). 
> Probably in *your* C code :) since it's the least tested. Probably writing 
> out of bounds.
>
> This could be quite tricky to debug. I'd try to get something close to a 
> minimal reproducible example.
>
> I'd try to take devtools out of the picture, maybe running the test/testhat.R 
> script from the command line using Rscript, or worst case creating a shell 
> package that adds minimal code and can be checked with R CMD build 
> --no-build-vignettes / R CMD check.
>
> You could try inserting gc() before / after the unit test; it might make it 
> clear that the unit test isn't the problem. You could also try 
> gctorture(TRUE); this will make your code run extremely painfully slowly, 
> which puts a big premium on having a minimal reproducible example; you could 
> put this near the code chunks that are causing problems.
>
> You might have success running under valgrind, something like R -d valgrind 
> -f minimal_script.R.
>
> Hope those suggestions help!
>
> Martin
>
>
> On 10/12/21, 6:43 PM, "Bioc-devel on behalf of Pariksheet Nanda" 
>  
> wrote:
>
> Hi folks,
>
> I've been told to ask some of my more fun questions on this mailing list
> instead of Slack.  I'm climbing the ladder of submitting my first
> Bioconductor package (https://gitlab.com/coregenomics/tsshmm) and feel
> like there are gremlins that keep adding rungs to the top of the ladder.
>   The latest head scratcher from running devtools::check() is a unit
> test for a  trivial 2 line function failing with this gem of an error:
>
>
>  > test_check("tsshmm")
> ══ Failed tests
> 
> ── Error (test-tss.R:11:5): replace_unstranded splits unstranded into +
> and - ──
> Error in `tryCatchOne(expr, names, parentenv, handlers[[1L]])`: internal
> logical NA value has been modified
> Backtrace:
>   █
>1. ├─testthat::expect_equal(...) test-tss.R:11:4
>2. │ └─testthat::quasi_label(enquo(expected), expected.label, arg =
> "expected")
>3. │   └─rlang::eval_bare(expr, quo_get_env(quo))
>4. └─GenomicRanges::GRanges(c("chr:100:+", "chr:100:-"))
>5.   └─methods::as(seqnames, "GRanges")
>6. └─GenomicRanges:::asMethod(object)
>7.   └─GenomicRanges::GRanges(ans_seqnames, ans_ranges, ans_strand)
>8. └─GenomicRanges:::new_GRanges(...)
>9.   └─S4Vectors:::normarg_mcols(mcols, Class, ans_len)
>   10. └─S4Vectors::make_zero_col_DFrame(x_len)
>   11.   └─S4Vectors::new2("DFrame", nrows = nrow, check = 
> FALSE)
>   12. └─methods::new(...)
>   13.   ├─methods::initialize(value, ...)
>   14.   └─methods::initialize(value, ...)
>   15. └─methods::validObject(.Object)
>   16.   └─base::try(...)
>   17. └─base::tryCatch(...)
>   18.   └─base:::tryCatchList(expr, classes,
> parentenv, handlers)
>   19. └─base:::tryCatchOne(expr, names,
> parentenv, handlers[[1L]])
> [ FAIL 1 | WARN 0 | SKIP 0 | PASS 109 ]
>
>
> The full continuous integration log is here:
> https://gitlab.com/coregenomics/tsshmm/-/jobs/1673603868
>
> The function in question is:
>
>
> replace_unstranded <- function (gr) {
>  idx <- strand(gr) == "*"
>  if (length(idx) == 0L)
>  return(gr)
>  sort(c(
>  gr[! idx],
>  `strand<-`(gr[idx], value = "+"),
>  `strand<-`(gr[idx], value = "-")))
> }
>
>
> Also online here:
> 
> https://gitlab.com/coregenomics/tsshmm/-/blob/ef5e19a0e2f68fca93665bc417afbcfb6d437189/R/hmm.R#L170-178
>
> ... and the unit test is:
>
>
> test_that("replace_unstranded splits unstranded into + and -", {
>  expect_equal(replace_unstranded(GRanges("chr:100")),
>   GRanges(c("chr:100:+", "chr:100:-")))
>  expect_equal(replace_unstranded(GRanges(c("chr:100", "chr:200:+"))),
>   sort(GRanges(c("chr:100:+", "chr:100:-", "chr:200:+"
> })
>
>
> Also online here:
> 
> 

Re: [Bioc-devel] git: lost write access to some repos + what is my BiocCredentials email address?

[Henrik Bengtsson]

Thank you, confirming git push now works and

$ ssh -T g...@git.bioconductor.org | grep -E
"(affxparser|aroma.light|illuminaio|QDNAseq)$"
X11 forwarding request failed on channel 0
 R Wpackages/QDNAseq
 R Wpackages/affxparser
 R Wpackages/aroma.light
 R Wpackages/illuminaio

/Henrik

On Thu, Aug 19, 2021 at 2:38 PM Nitesh Turaga  wrote:
>
> Hi Henrik,
>
> You should have access to these packages again.
>
> Please try again.
>
> Best
>
> Nitesh Turaga
> Scientist II, Department of Data Science,
> Bioconductor Core Team Member
> Dana Farber Cancer Institute
>
> > On Aug 19, 2021, at 8:08 AM, Henrik Bengtsson  
> > wrote:
> >
> > Hi,
> >
> > I seem to have "lost" write access to several Bioconductor git
> > repositories that I had git push access for before;
> >
> > $ ssh -T g...@git.bioconductor.org | grep -E
> > "(affxparser|aroma.light|illuminaio|QDNAseq)$"
> > X11 forwarding request failed on channel 0
> > R  packages/QDNAseq
> > R  packages/affxparser
> > R  packages/aroma.light
> > R Wpackages/illuminaio
> >
> > Using `ssh -v ...`, I see that my git+ssh "offers" the server an RSA
> > public key (B...PwYDZ), which is accepted.  Since this gives me
> > write access to one of the repositories, I either have lost write
> > access to the others, or I somehow have ended up with different SSH
> > keys associated with different repositories (since I had write
> > permissions in the past).
> >
> > For example, with:
> >
> > $ git clone g...@git.bioconductor.org:packages/aroma.light
> > $ cd aroma.light
> > $ git remote -v
> > origing...@git.bioconductor.org:packages/aroma.light (fetch)
> > origing...@git.bioconductor.org:packages/aroma.light (push)
> >
> > I get:
> >
> > $ git push
> > X11 forwarding request failed on channel 0
> > FATAL: W any packages/aroma.light h.bengtsson DENIED by fallthru
> > (or you mis-spelled the reponame)
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights and the repository 
> > exists.
> >
> > I followed FAQ #15 to check what SSH key I have on BiocCredentials,
> > but when I try to activate the account on
> > https://git.bioconductor.org/BiocCredentials/account_activation/ using
> > the email address I have in the DESCRIPTION file, I get
> > "henr...@braju.com is not associated with a maintainer of a
> > Bioconductor package. Please check the spelling or contact
> > bioc-devel@r-project.org for help."(*) I suspect it's another email
> > address I should use, possibly one from the SVN era. How can I find
> > out which email address I should use?
> >
> > (*) FYI, the webpage hint reading "Enter the email associated with
> > your Bioconductor package" might be ambiguous; Is it really specific
> > to a particular package?  Should it say something like "Enter the
> > email associated with your Bioconductor developer account"?
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

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

[Bioc-devel] git: lost write access to some repos + what is my BiocCredentials email address?

[Henrik Bengtsson]

Hi,

I seem to have "lost" write access to several Bioconductor git
repositories that I had git push access for before;

$ ssh -T g...@git.bioconductor.org | grep -E
"(affxparser|aroma.light|illuminaio|QDNAseq)$"
X11 forwarding request failed on channel 0
 R  packages/QDNAseq
 R  packages/affxparser
 R  packages/aroma.light
 R Wpackages/illuminaio

Using `ssh -v ...`, I see that my git+ssh "offers" the server an RSA
public key (B...PwYDZ), which is accepted.  Since this gives me
write access to one of the repositories, I either have lost write
access to the others, or I somehow have ended up with different SSH
keys associated with different repositories (since I had write
permissions in the past).

For example, with:

$ git clone g...@git.bioconductor.org:packages/aroma.light
$ cd aroma.light
$ git remote -v
origing...@git.bioconductor.org:packages/aroma.light (fetch)
origing...@git.bioconductor.org:packages/aroma.light (push)

I get:

$ git push
X11 forwarding request failed on channel 0
FATAL: W any packages/aroma.light h.bengtsson DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

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

I followed FAQ #15 to check what SSH key I have on BiocCredentials,
but when I try to activate the account on
https://git.bioconductor.org/BiocCredentials/account_activation/ using
the email address I have in the DESCRIPTION file, I get
"henr...@braju.com is not associated with a maintainer of a
Bioconductor package. Please check the spelling or contact
bioc-devel@r-project.org for help."(*) I suspect it's another email
address I should use, possibly one from the SVN era. How can I find
out which email address I should use?

(*) FYI, the webpage hint reading "Enter the email associated with
your Bioconductor package" might be ambiguous; Is it really specific
to a particular package?  Should it say something like "Enter the
email associated with your Bioconductor developer account"?

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

Re: [Bioc-devel] Build error "failure: length > 1 in coercion to logical" not reproducible

[Henrik Bengtsson]

On Thu, Jun 17, 2021 at 2:32 AM  wrote:
>
> Dear colleagues,
>
> It seems to me that, starting with the latest BioC devel branch (3.14), the
> build systems have become more pedantic about logical vectors of length > 1
> in conditions. Two of the packages I am maintaining, 'kebabs' and 'procoil'
> currently fail to build. Surely I want to fix this. However, I cannot
> reproduce these errors on my local system (R 4.1.0 alpha on Ubuntu 18.04
> LTS). The discussions https://support.bioconductor.org/p/9137605/ and
> https://github.com/Bioconductor/BBS/issues/71  have pointed me to the
> setting "_R_CHECK_LENGTH_1_CONDITION_=verbose".
>
> First question: Can anybody confirm that this has been changed in the recent
> devel?

Not a Bioc maintainer, but yes, the Bioc build system added this on
May 22, 2021 in order to catch similar bugs in package vignettes, cf.
https://community-bioc.slack.com/archives/CLUJWDQF4/p1622062783020300?thread_ts=1622053611.008100=CLUJWDQF4

>
> Second question: I have tried to include
> "_R_CHECK_LENGTH_1_CONDITION_=verbose" in my .Renviron file and it seems
> that my R session respects that. However, when I run 'R CMD build' on the
> aforementioned packages, they still build fine. The suggestions in
> https://github.com/Bioconductor/BBS/issues/71 don't work for me either
> (maybe I have done something wrong). I would actually like to reproduce the
> errors in my local system, since this will help me fixing the errors and
> testing the changes. So can anybody give me advice how I can make my local
> installation to check for logical vectors of length > 1 in conditions more
> strictly?

You want to set:

_R_CHECK_LENGTH_1_LOGIC2_=verbose

That one catches bugs where x && y or x || y is called with length(x)
> 1 or length(y) > 1.

Using:

_R_CHECK_LENGTH_1_CONDITION_=verbose

catches bugs where if (x) { ... } and similar conditions are called
with length(x) > 1.

In your case, a reproducible minimal example is:

Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_"="verbose")
files <- c("a", "b")
files <- Rsubread:::.check_and_NormPath(files)
...
Error in is.na(files) || is.null(files) :

  'length(x) = 2 > 1' in coercion to 'logical(1)'

The problem is that there's a is.na(files) || is.null(files) in the code, where

> is.na(files)
[1] FALSE FALSE
> is.null(files)
[1] FALSE

so, we have an x || y case with length(x) > 1.

/Henrik




>
> Thanks a lot in advance,
> Ulrich
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] BiocCheck and version requirement

[Henrik Bengtsson]

On Thu, Apr 8, 2021 at 11:22 AM Kasper Daniel Hansen
 wrote:
>
> R CMD check sometimes wants dependency on specific R versions, for example 
> when the file format changed (forgot which version .. was it 3.6). But that 
> warning is emitted when it tests the package utilizes version-specific stuff.

Yes, serialization format v3 was introduced in R 3.5.0.  If there are
R binary files with that version, then 'R CMD build' will check and
warning about this, and automatically inject an explicit Depends: R
(>= 3.5.0) in the built tarball. Example:

$ R CMD build teeny
...
* checking for empty or unneeded directories
  NB: this package now depends on R (>= 3.5.0)
  WARNING: Added dependency on R >= 3.5.0 because serialized objects
in  serialize/load version 3 cannot be read in older versions of R.
File(s) containing such objects: ‘teeny/inst/pi.rds’
* building ‘teeny_0.1.0.tar.gz’

But that's not a *check* error.  If you'd submit to CRAN, they would
not notice because it's fixed in the source tarball.  On Bioconductor,
you'd see it in the build logs, because that builds from the package
source folder.  I don't know if there are additional checks for this
in 'R CMD check' - could be - but I guess you would have to do some
tricks to circumvent 'R CMD build' in order to get a source tarball
without the dependency.

Note that if the R binary files are in serialization version 2, then
there is no such warning.  In other words, a package developer can
very well keep their package backward compatible with R (< 3.5.0) by
not updating/resaving/regenerating binary files in version 3.  To stay
with version 2, one can use, e.g. saveRDS(x, file, version=2).

/Henrik

>
> I get that Bioc doesn't check under older versions. That is intentional. But 
> that is different from the check asking for a specific version for no 
> particular reason (as far as I can ascertain).
>
> Best,
> Kasper
>
> On Thu, Apr 8, 2021 at 8:13 PM Henrik Bengtsson  
> wrote:
>>
>> > I believe in the past we tried suggesting removing a R dependency 
>> > altogether but that R CMD check complained not having an R dependency?  
>> > Maybe someone remembers more about this.
>>
>> There are no such requirements in 'R CMD check'.  The only requirement
>> around 'Depends: R (>= x.y.z)', if specified, is with 'R CMD check
>> --as-cran' that requires z == 0. In other words, you can submit a
>> package to CRAN that depends on a specific patch version, e.g. either
>> R (>= 4.0.0) or R (>= 4.1.0) but not say R (>= 4.0.2) resulting in:
>>
>> * checking DESCRIPTION meta-information ... WARNING
>> Dependence on R version ‘4.0.2’ not with patchlevel 0
>>
>>
>> In the bigger picture: I argue that Bioconductor's dependency on R
>> version is a major, unnecessary(*) disadvantage and adds barriers
>> between the Bioconductor community and the rest of the R community
>> resulting in many lost opportunities and cross-pollination. (*) I know
>> the arguments, but I think there are better solutions already
>> available that do not enforce specific R versions on users and thereby
>> limit them, e.g. when they want to a single Bioconductor package with
>> zero dependencies in their workflow.  As a way forward, I'd suggest
>> that Bioconductor makes it a long-term target to make it possible for
>> any R user to install Bioc packages with a regular install.packages()
>> call - I think that can be achieved.
>>
>> /Henrik
>>
>> On Thu, Apr 8, 2021 at 10:39 AM Kern, Lori
>>  wrote:
>> >
>> > From a Bioconductor R perspective, we can't tell if the package would work 
>> > with a lesser version of R or lower versions of any package dependencies.  
>> > We accept packages and have requirements to ensure packages can run.
>> > You can always have another github branch
>> >
>> > I believe in the past we tried suggesting removing a R dependency 
>> > altogether but that R CMD check complained not having an R dependency?  
>> > Maybe someone remembers more about this.
>> >
>> >
>> >
>> >
>> > Lori Shepherd
>> >
>> > Bioconductor Core Team
>> >
>> > Roswell Park Comprehensive Cancer Center
>> >
>> > Department of Biostatistics & Bioinformatics
>> >
>> > Elm & Carlton Streets
>> >
>> > Buffalo, New York 14263
>> >
>> > 
>> > From: Kasper Daniel Hansen 
>> > Sent: Thursday, April 8, 2021 1:33 PM
>> > To: Kern, Lori 
>> > Cc: bioc-devel 
>> > Subject: Re: [Bioc-devel] BiocCheck and version requirement
>> >

Re: [Bioc-devel] BiocCheck and version requirement

[Henrik Bengtsson]

> I believe in the past we tried suggesting removing a R dependency altogether 
> but that R CMD check complained not having an R dependency?  Maybe someone 
> remembers more about this.

There are no such requirements in 'R CMD check'.  The only requirement
around 'Depends: R (>= x.y.z)', if specified, is with 'R CMD check
--as-cran' that requires z == 0. In other words, you can submit a
package to CRAN that depends on a specific patch version, e.g. either
R (>= 4.0.0) or R (>= 4.1.0) but not say R (>= 4.0.2) resulting in:

* checking DESCRIPTION meta-information ... WARNING
Dependence on R version ‘4.0.2’ not with patchlevel 0


In the bigger picture: I argue that Bioconductor's dependency on R
version is a major, unnecessary(*) disadvantage and adds barriers
between the Bioconductor community and the rest of the R community
resulting in many lost opportunities and cross-pollination. (*) I know
the arguments, but I think there are better solutions already
available that do not enforce specific R versions on users and thereby
limit them, e.g. when they want to a single Bioconductor package with
zero dependencies in their workflow.  As a way forward, I'd suggest
that Bioconductor makes it a long-term target to make it possible for
any R user to install Bioc packages with a regular install.packages()
call - I think that can be achieved.

/Henrik

On Thu, Apr 8, 2021 at 10:39 AM Kern, Lori
 wrote:
>
> From a Bioconductor R perspective, we can't tell if the package would work 
> with a lesser version of R or lower versions of any package dependencies.  We 
> accept packages and have requirements to ensure packages can run.
> You can always have another github branch
>
> I believe in the past we tried suggesting removing a R dependency altogether 
> but that R CMD check complained not having an R dependency?  Maybe someone 
> remembers more about this.
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Kasper Daniel Hansen 
> Sent: Thursday, April 8, 2021 1:33 PM
> To: Kern, Lori 
> Cc: bioc-devel 
> Subject: Re: [Bioc-devel] BiocCheck and version requirement
>
> But why is it even a warning? The submission policy is that warnings are 
> discouraged. This means that developers will adapt to this warning.
>
> The check is also against the policies on the website which state you don't 
> need a formal dependency.
>
> Best,
> Kasper
>
> On Thu, Apr 8, 2021 at 3:53 PM Kern, Lori 
> mailto:lori.sheph...@roswellpark.org>> wrote:
> This requirement has been around for awhile.  New package submissions are 
> checked against the devel version of Bioconductor. At the moment this is R 
> devel (R 4.1) and Bioconductor packages in devel for 3.13.  Given that 
> Bioconductor releases are closely tied to a R release,  and changes in R can 
> (and have) had great consequences for package functionality, we can not 
> guarantee a package will work on any previous version of R or with previous 
> versions of packages.
> It is why it is a warning and not an error
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel 
> mailto:bioc-devel-boun...@r-project.org>> 
> on behalf of Kasper Daniel Hansen 
> mailto:kasperdanielhan...@gmail.com>>
> Sent: Thursday, April 8, 2021 9:44 AM
> To: bioc-devel mailto:bioc-devel@r-project.org>>
> Subject: [Bioc-devel] BiocCheck and version requirement
>
> The latest BiocCheck (well, it may have been around for a bit) _requires_
> the package to have a R >= 4.1 dependency.
>
> That seems new to me. Right now it's a bit irritating, because if you're
> submitting a package that works with latest stable release, you are now
> prohibited from installing it from Github into your stable Bioc version.
>
> Traditionally, we have not enforced this I think, even though we all know
> of the implicit dependency.
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1Zqtuoo0O2aKBea_yHofM_QCv72B3JNIupD47xAVitntUD9FgXVvT4yX66u57RWFhMonvou61R_vk6u1LgIM5J8qpHXw4gXWyAxGlZFJEH--5tT-UESMe6_L4bbB6jIcOfYl0J5FI0gucNH0boaxPdv4-It-V5j3TPd2bd5Er3K7MHNVFhqgA5bs84nYYGnvBuOVns86_d2q_mkKzVTHay7GQUxlJhDGVxQbxlwyKvaVPNraVZJKI3lQzwTpavNpm7CpFuIOaDv9a9-euSOlKn3NYMdkPxNfAHv3u2sI1vZ_1ww4KU4c5TgGsp-ard5Ix/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-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 

Re: [Bioc-devel] Suppressing messages from Rprofile

[Henrik Bengtsson]

Correcting: the env var is R_LIBS_USER and nothing else.

/Henrik

On Wed, Apr 7, 2021 at 1:20 PM Henrik Bengtsson
 wrote:
>
> Can you go via a temporary file instead, i.e. output what you want to
> grab to a temporary file and pull the info from that instead?
>
> Side tracking ...
>
> > I thought about using --vanilla but I use .Rprofile to set my library path,
> > so ignoring that file completely defeats the point in my setup.
>
> I'm a proponent of customizing the library path via .Renviron instead
> of via .Rprofile.  In your case, you can have a line in ~/.Renviron
> with:
>
>   R_USER_LIBS=~/R/%p-library/%v-bioc_3.12
>
> Alternatively, you can set it elsewhere, e.g. ~/.bashrc, in a Linux
> environment module that is loaded, and so on.
>
> BTW, using Rscript --no-init-file ... would skip .Rprofile while still
> parsing .Renviron.
>
> /Henrik
>
> On Wed, Apr 7, 2021 at 8:16 AM Mike Smith  wrote:
> >
> > I have the following line in the configure.ac for rhdf5filters, which
> > returns the location of the HDF5 headers distributed with Rhdf5lib:
> >
> > RHDF5_INCLUDE=`"${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e
> > 'cat(system.file("include", package="Rhdf5lib"))'`
> >
> > For me the output is a path like
> >  /mnt/data/R-lib/4.0.3-bioc_3.12/Rhdf5lib/include, which gets inserted into
> > the package Makevars file, and the package compilation works.
> >
> > However I've had multiple reports (
> > https://github.com/grimbough/rhdf5filters/issues/11) where this doesn't
> > work, all of which seem to relate to messages printed when an Rprofile is
> > loaded.  They have well intentioned messages like below, which don't work
> > so well when passed as compiler flags
> >
> > [1] "[BMRC] You have sourced the BMRC Rprofile provided at
> > /apps/misc/R/bmrc-r-user-tools/Rprofile"
> > [1] "[BMRC] Messages coming from this file (like this one) will be
> > prefixed with [BMRC]"
> > [1] "[BMRC] You are running R on host 
> > with CPU "
> > [1] "[BMRC] While running on this host, local R packages will be
> > sourced from and installed to
> > /well/combat/users/ifl143/R/4.0/ivybridge"
> > /gpfs3/well/combat/users/ifl143/R/4.0/ivybridge/Rhdf5lib/include
> >
> > I thought about using --vanilla but I use .Rprofile to set my library path,
> > so ignoring that file completely defeats the point in my setup.  Is anyone
> > aware of either a more reliable way of getting the information I want
> > (maybe suppressing messages, different mechanism entirely, etc)?
> > Alternatively, is there anything definitive in WRE or the like that
> > suggests printing messages Rprofile is a bad idea that I can pass on to the
> > users?
> >
> > Cheers,
> > Mike
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Suppressing messages from Rprofile

[Henrik Bengtsson]

Can you go via a temporary file instead, i.e. output what you want to
grab to a temporary file and pull the info from that instead?

Side tracking ...

> I thought about using --vanilla but I use .Rprofile to set my library path,
> so ignoring that file completely defeats the point in my setup.

I'm a proponent of customizing the library path via .Renviron instead
of via .Rprofile.  In your case, you can have a line in ~/.Renviron
with:

  R_USER_LIBS=~/R/%p-library/%v-bioc_3.12

Alternatively, you can set it elsewhere, e.g. ~/.bashrc, in a Linux
environment module that is loaded, and so on.

BTW, using Rscript --no-init-file ... would skip .Rprofile while still
parsing .Renviron.

/Henrik

On Wed, Apr 7, 2021 at 8:16 AM Mike Smith  wrote:
>
> I have the following line in the configure.ac for rhdf5filters, which
> returns the location of the HDF5 headers distributed with Rhdf5lib:
>
> RHDF5_INCLUDE=`"${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e
> 'cat(system.file("include", package="Rhdf5lib"))'`
>
> For me the output is a path like
>  /mnt/data/R-lib/4.0.3-bioc_3.12/Rhdf5lib/include, which gets inserted into
> the package Makevars file, and the package compilation works.
>
> However I've had multiple reports (
> https://github.com/grimbough/rhdf5filters/issues/11) where this doesn't
> work, all of which seem to relate to messages printed when an Rprofile is
> loaded.  They have well intentioned messages like below, which don't work
> so well when passed as compiler flags
>
> [1] "[BMRC] You have sourced the BMRC Rprofile provided at
> /apps/misc/R/bmrc-r-user-tools/Rprofile"
> [1] "[BMRC] Messages coming from this file (like this one) will be
> prefixed with [BMRC]"
> [1] "[BMRC] You are running R on host 
> with CPU "
> [1] "[BMRC] While running on this host, local R packages will be
> sourced from and installed to
> /well/combat/users/ifl143/R/4.0/ivybridge"
> /gpfs3/well/combat/users/ifl143/R/4.0/ivybridge/Rhdf5lib/include
>
> I thought about using --vanilla but I use .Rprofile to set my library path,
> so ignoring that file completely defeats the point in my setup.  Is anyone
> aware of either a more reliable way of getting the information I want
> (maybe suppressing messages, different mechanism entirely, etc)?
> Alternatively, is there anything definitive in WRE or the like that
> suggests printing messages Rprofile is a bad idea that I can pass on to the
> users?
>
> Cheers,
> Mike
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

[Henrik Bengtsson]

FWIW, I ran into a similar problem when I moved R.cache
(https://cran.r-project.org/package=R.cache) from using ~/.Rcache to
~/.cache/R/R.cache (etc).  I decided on making it 100%-backward
compatible, i.e. if there's already a legacy ~/.Rcache cache folder,
it'll keep using that, otherwise the new standard.  That way nothing
breaks, and it's not a biggie if it keeps writing to the legacy cache
folder.  For now, it's silent, but I'll eventually deprecate
~/.Rcache, e.g. by producing one-time warning per session and in a
later release be more aggressive, and eventually make it defunct (but
not rushing there).  Here's what I wrote in my NEWS release:

Version: 0.14.0 [2019-12-05]

SIGNIFICANT CHANGES:

 * Now R.cache uses a default cache path that adheres to the standard cache
   location on the current operating system, whereas in previous versions it
   defaulted to ~/.Rcache.  On Unix, the 'XDG Base Directory Specification'
   is followed, which means that the R.cache folder will typically be
   ~/.cache/R/R.cache/.  On macOS, it will be ~/Library/Caches/R/R.cache/.
   On modern versions of Microsoft Windows, environment variables such
   as 'LOCALAPPDATA' will be used, which typically resolves to
   '%USERPROFILE%/AppData/Local, e.g. 'C:/Users/alice/AppData/Local'.
   If R.cache fails find a proper OS-specific cache folder, it will fall
   back to using ~/.Rcache as previously done.
   Importantly, if ~/.Rcache already exists, then that will be used by
   default.  This is done in order to not lose previously cached files.
   Users with an existing folder who wish to move to the new standard need
   to move or remove the ~/.Rcache folder manually.

/Henrik

On Wed, Apr 7, 2021 at 9:41 AM Aaron Lun
 wrote:
>
> > There is no guarantee we would be under the right user to have permissions 
> > to move the cache automatically and would not want to leave it in a broken 
> > state.
>
> Well, can't you try? If people follow your 4.1 instructions and they
> don't have permissions, the cache will be broken anyway.
>
> But let's say you can't move it, and your worst-case scenario comes to
> pass. EVEN THEN: I would expect a deprecation warning, no error, and
> BiocFileCache continuing to pull from the old cache for 6 months.
>
> Every previous non-transparent change to BioC's core infrastructure
> has come with a deprecation warning. I don't see why this is any
> different. An error is particularly galling given that the package was
> working fine before, it's not like you're doing some kind of critical
> bugfix.
>
> > This should not affect any cache that is explicitly stated with a different 
> > name in the constructor or using environment variables;  only in the case 
> > of BiocFileCache() .  Most package specific caches created their own cache 
> > in the constructor so it should not cause the ERROR in that case.
>
> If Vince's last email is any indication, and calling ExperimentHub()
> or AnnotationHub() causes an error... this will be a disaster. I'm
> going to get a lot of emails, unnecessary emails, from users wondering
> why scRNAseq and celldex don't work anymore. It'll be like our
> AWS-China problems multiplied by 10.
>
> Why not just make a new cache and populate it? Well, I don't really
> care what you do, as long as I don't get an error.
>
> -A
>
> > 
> > From: Aaron Lun 
> > Sent: Wednesday, April 7, 2021 11:41 AM
> > To: Kern, Lori 
> > Cc: bioc-devel@r-project.org 
> > Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
> > ExperimentHub
> >
> > Woah, I missed the part where you said that there would be an error.
> >
> > This does not sound good. Users are going to flip out, especially when
> > EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
> > It also sounds completely unnecessary for EHub and AHub given that the
> > new cache can just be populated by fresh downloads. Similarly,
> > BiocFileCache::bfcrpath should not be affected, and people using that
> > shouldn't be getting an error.
> >
> > Why not just move the old default cache into the new location
> > automatically? This seems like the simplest solution given that
> > everyone accessing BFC resources should be doing so through the BFC
> > API. And most files are not position-dependent, unless people are
> > putting shared libraries in there.
> >
> > But even if you can't, an error is just too much. We use BiocFileCache
> > a lot in our company infrastructure and the brown stuff will hit the
> > fan if we have to find every old default cache and delete it. The
> > package should handle this for us.
> >
> > -A
> >
> > On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori  
> > wrote:
> > >
> > > Mostly to lighten the dependency tree using tools that is built in with R 
> > > would remove one additional dependency.  Also clarity; the tools 
> > > directory adds an R folder for distinction that they are used with R 
> > > packages which seemed like if a user was ever 

Re: [Bioc-devel] Remotes in DESCRIPTION not supported for BioC?

[Henrik Bengtsson]

Related: Does Bioconductor support 'Additional_repositories'? From RWE:

The ‘Additional_repositories’ field is a comma-separated list of
repository URLs where the packages named in the other fields may be
found. It is currently used by R CMD check to check that the packages
can be found, at least as source packages (which can be installed on
any platform).

FWIW, CRAN allows/supports them (I've only used them for packages
under 'Suggests:').

/Henrik

On Tue, Mar 2, 2021 at 4:02 AM Rainer Johannes
 wrote:
>
> thanks for the quick reply Lori!
>
> OK, so we will have to submit the package to Bioc ASAP.
>
> cheers, jo
>
> > On 2 Mar 2021, at 12:51, Kern, Lori  wrote:
> >
> > Currently the builders do not allow the user of remotes and you would have 
> > to wait for it to be submitted to CRAN or Bioconductor.  All Bioconductor 
> > dependencies must be on CRAN or Bioconductor.
> >
> > Get Outlook for iOS
> > From: Bioc-devel  on behalf of Rainer 
> > Johannes 
> > Sent: Tuesday, March 2, 2021 4:36:05 AM
> > To: bioc-devel 
> > Subject: [Bioc-devel] Remotes in DESCRIPTION not supported for BioC?
> >
> > Dear All!
> >
> > in one of the xcms vignettes we are using a R package which is not yet in 
> > Bioconductor and I added
> >
> > Remotes:
> > RforMassSpectrometry/MsBackendMgf
> >
> > to the DESCRIPTION thinking that on the BioC build machines the package 
> > might get installed (from github). It does apparently not as we get ERROR 
> > for this vignette. Is there any way I can use a non-Bioconductor and 
> > non-CRAN package or do I have to wait until the package is included in 
> > Bioconductor?
> >
> > thanks for any feedback!
> >
> > cheers, jo
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://secure-web.cisco.com/1H1jWIWyghkLhLM5RAXwwfoWK4PlOlae4Pc1-a_NRbOIOuLSLHtGAyInV-z8t0fCgCfVH0nxURKnBN77cdDWaaKfCoZMnqX4XshZNWoi44Ko2dWmnDvV5BjARxeduRCCmoKigDovJkvgYgbecL-t9v9m2HGULeKeb9va8J3NlYFXnVkCDGyzsNgbeZSN2VlWCKhLL1vQqlJEiglEPQraiCYfRjZdnxkQsRcLPnIkfvjbIHJWHFz0LYJRGav4iCiARcWCn0Uo0qe8ieknAiGloqMR2HJHD6oUNCdG8v7oYy73oVejgIqxYBbvJsrztDawr/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-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

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

Re: [Bioc-devel] Rsync to Bioconductor

[Henrik Bengtsson]

FYI, I just sent an email to 'maintai...@bioconductor.org' regarding
this but it bounced with the below errors (I've truncated your
address):

From: Mail Delivery System 
Date: Thu, Feb 25, 2021 at 12:39 PM
Subject: Undelivered Mail Returned to Sender
To: ...


This is the mail system at host delivery.bioconductor.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host mx1.roswellpark.iphmx.com[68.232.137.170]
said: 550 #5.7.1 Your access to submit messages to this e-mail system has
been rejected. (in reply to DATA command)

: host mx1.roswellpark.iphmx.com[68.232.137.170]
said: 550 #5.7.1 Your access to submit messages to this e-mail system has
been rejected. (in reply to DATA command)

: host
mx1.roswellpark.iphmx.com[68.232.137.170] said: 550 #5.7.1 Your access to
submit messages to this e-mail system has been rejected. (in reply to DATA
command)

: host mx1.roswellpark.iphmx.com[68.232.137.170]
said: 550 #5.7.1 Your access to submit messages to this e-mail system has
been rejected. (in reply to DATA command)

/Henrik

On Wed, Feb 24, 2021 at 8:03 AM Kern, Lori
 wrote:
>
> In the next few weeks we will be limiting the ability to rsync to 
> Bioconductor resources.  If you currently are using rsync please reach out to 
> maintai...@bioconductor.org as we will need additional information to 
> continue to allow rsync on your machines.
>
> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Git pack file greater than 5MB

[Henrik Bengtsson]

I understood that it's a submission. Just wanted to make sure that it's
clear there might be side effects, e.g. people clone and collaborate also
before submitting to Bioc and a rewrite might surprise existing
collaborators etc.

/H

On Thu, Oct 1, 2020, 09:04 Nitesh Turaga  wrote:

> This package isn’t yet a Bioconductor package Henrik. It will break other
> forks most likely. This package hasn’t been submitted to the Contributions
> either to be reviewed. So this is the time to break what needs to be broken
> before it’s submitted to Bioconductor and gets into the Bioconductor git
> repository.
>
> Nitesh
>
> On Oct 1, 2020, at 11:57 AM, Henrik Bengtsson 
> wrote:
>
> Doesn't a git rewrite break all existing clones, forks out there? I'm
> happy to be corrected, if this is not the case.
>
> /Henrik
>
> On Thu, Oct 1, 2020, 08:16 Nitesh Turaga  wrote:
>
>> Hi,
>>
>> The BiocCheck will complain on the build system about the > 5MB package
>> size.
>>
>> The rewrite of the history with BFG cleaner (
>> https://rtyley.github.io/bfg-repo-cleaner/ <
>> https://rtyley.github.io/bfg-repo-cleaner/>) is not as severe as you
>> think it is to be honest. It is just removing these pack files which don’t
>> have a place in the tree structure. These are more often than not, orphan
>> files.
>>
>> If you are suspect of this solution, I would suggest you make a backup
>> clone of your repo and try it on that first before you touch the main repo.
>> Check the history (git log) to see if anything important is missing.
>>
>> But usually a software package has to be below 5MB. If you have some data
>> in there which is needed for the package, consider Experiment Hub.
>>
>> Best,
>>
>> Nitesh
>>
>> > On Sep 30, 2020, at 12:46 PM, McGrath, Max 
>> wrote:
>> >
>> > Hi all,
>> >
>> > We have a package that is ready for submission, but when running
>> BiocCheck a warning is generated noting that "The following files are over
>> 5MB in size: '.git/objects/pack/pack-xxx...". I've pruned, repacked, and
>> run git gc which reduced the file size from 5.2 to 5.1MB, but I have been
>> unable to reduce it further.
>> >
>> > I'm reaching out to determine if this is an issue, and if so to ask for
>> recommendations for solving it. Currently, the only solution I've come up
>> with is to rewrite the repository's history using a tool like
>> "git-filter-repo", but this is a more drastic action than I would prefer to
>> take. I would greatly appreciate any advice on the matter.
>> >
>> > Thank you,
>> > Max McGrath
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Git pack file greater than 5MB

[Henrik Bengtsson]

Doesn't a git rewrite break all existing clones, forks out there? I'm happy
to be corrected, if this is not the case.

/Henrik

On Thu, Oct 1, 2020, 08:16 Nitesh Turaga  wrote:

> Hi,
>
> The BiocCheck will complain on the build system about the > 5MB package
> size.
>
> The rewrite of the history with BFG cleaner (
> https://rtyley.github.io/bfg-repo-cleaner/ <
> https://rtyley.github.io/bfg-repo-cleaner/>) is not as severe as you
> think it is to be honest. It is just removing these pack files which don’t
> have a place in the tree structure. These are more often than not, orphan
> files.
>
> If you are suspect of this solution, I would suggest you make a backup
> clone of your repo and try it on that first before you touch the main repo.
> Check the history (git log) to see if anything important is missing.
>
> But usually a software package has to be below 5MB. If you have some data
> in there which is needed for the package, consider Experiment Hub.
>
> Best,
>
> Nitesh
>
> > On Sep 30, 2020, at 12:46 PM, McGrath, Max 
> wrote:
> >
> > Hi all,
> >
> > We have a package that is ready for submission, but when running
> BiocCheck a warning is generated noting that "The following files are over
> 5MB in size: '.git/objects/pack/pack-xxx...". I've pruned, repacked, and
> run git gc which reduced the file size from 5.2 to 5.1MB, but I have been
> unable to reduce it further.
> >
> > I'm reaching out to determine if this is an issue, and if so to ask for
> recommendations for solving it. Currently, the only solution I've come up
> with is to rewrite the repository's history using a tool like
> "git-filter-repo", but this is a more drastic action than I would prefer to
> take. I would greatly appreciate any advice on the matter.
> >
> > Thank you,
> > Max McGrath
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] sapply and vapply

[Henrik Bengtsson]

FWIW,

> sapply(X, length) - always numeric(1) (integer(1) or double(1) for vectors of 
> more than 2^31 - 1 elements)

Actually, the length of length(x) may not be 1L, e.g.

> x <- Formula::Formula(~ x)
> length(x)
[1] 0 1

>From help("length", package = "base"):

"Warning: Package authors have written methods that return a result of
length other than one (Formula) and that return a vector of type
double (Matrix), even with non-integer values (earlier versions of
sets). Where a single double value is returned that can be represented
as an integer it is returned as a length-one integer vector."

I/we recently learned this the hard way
(https://github.com/HenrikBengtsson/future/issues/395).  It's rather
unfortunate that not even length() is strictly defined here, I'd say.
I think we could move away from this if lengths() would be a generic
so lengths(x) could be used above.  But that's a discussion for
R-devel.

/Henrik


On Wed, Aug 12, 2020 at 9:33 AM Laurent Gatto
 wrote:
>
> Dear all,
>
> I have a quick question regarding the usage of vapply and sapply. The former 
> is recommended to insure that the output is always a vector of a specific 
> type. For example:
>
> > df1 <- data.frame(x = 1:3, y = LETTERS[1:3]) ## OK test
> > df2 <- data.frame(x = 1:3, y = Sys.time() + 1:3) ## Not OK test
> > sapply(df1, class) ## vector of chars, OK
>   x   y
>   "integer" "character"
> > sapply(df2, class) ## ouch, not a vector
> $x
> [1] "integer"
>
> $y
> [1] "POSIXct" "POSIXt"
>
> > vapply(df2, class, character(1)) ## prefer an error rather than a list
> Error in vapply(df2, class, character(1)) : values must be length 1,
>  but FUN(X[[2]]) result is length 2
>
> There are cases, however, were FUN ensures that the output will be of length 
> 1 and of a expected type. For example
>
> - sapply(X, all) - all() always returns logical(1)
> - sapply(X, length) - always numeric(1) (integer(1) or double(1) for vectors 
> of more than 2^31 - 1 elements)
>
> or more generally
>
> - sapply(X, slot, "myslot") - slot() will always return a character(1) 
> because @myslot is always character(1) (as defined by the class)
>
> Would you still recommend to use vapply() in such cases?
>
> Thank you in advance.
>
> Laurent
>
>
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Possible problems with BiocParallel and R cmd check on Github

[Henrik Bengtsson]

(I assume you just forgot to 'Reply All' so I've added bioc-devel back
to the cc:)

> Unfortunately what I'm mentioning only happens in Github actions, which
> are the standard ones (we used usethis::use_github_action_check_standard),

I'd say that that 'usethis' setup did not anticipate package tests
that run parallel code.  So, don't assume it's perfect and that it
covers all use cases.

> we haven't modified the action ...

That's actually my suggestion - did you try my one-line addition?  I'm
95% certain it will solve your check errors on Windows as it did for
me.

> ... It also appears same actions performed on MacOS have
> some kind of problems since they stop even before checking the package.

Yes, there seems to be some hiccups.  I also get those since a few
days back.  These are out of our control and we just have to wait for
them to resolved upstream/elsewhere.

/Henrik

On Thu, Jul 30, 2020 at 2:05 AM Giulia Pais  wrote:
>
> Thanks for the reply,
>
> Unfortunately what I'm mentioning only happens in Github actions, which
> are the standard ones (we used
> usethis::use_github_action_check_standard), we haven't modified the
> action, errors I'm mentioning do not happen in local R environments on
> windows machines. It also appears same actions performed on MacOS have
> some kind of problems since they stop even before checking the package.
>
> Is it relevant for a bioconductor reviewer the result of these Github
> action reports? We would like to submit the package for moderation soon
> but we're unsure if we can due to this problem. Thank you.
>
> Il 29/07/2020 19:25, Henrik Bengtsson ha scritto:
> >  From a very quick look at this, I think you also need to explicitly
> > install the package itself for it to be available in external R
> > session (contrary to when using forked processing as on Linux and
> > macOS).  Something like this:
> >
> > - name: Install dependencies
> >  run: |
> >remotes::install_deps(dependencies = TRUE)
> >remotes::install_cran("rcmdcheck")
> >install.packages(".", repos=NULL, type="source") ## needed by
> > parallel workers
> >shell: Rscript {0}
> >
> > That's what I had to do when testing 'future'
> > (https://github.com/HenrikBengtsson/future/blob/1835a122764bbc0196c78be6da6973c8063922b3/.github/workflows/R-CMD-check.yaml#L69).
> >
> > /Henrik
> >
> > On Wed, Jul 29, 2020 at 10:18 AM Giulia Pais  wrote:
> >> Hi bioconductor team,
> >>
> >> we are currently developing a package for future submission on
> >> bioconductor which you can find here
> >> https://github.com/calabrialab/ISAnalytics.
> >>
> >> We use Github actions to keep track of R cmd checks at every commit, and
> >> this time, surprisingly for us, we had a failure on R cmd checks for
> >> windows (which is odd, since we develop on windows and performing check
> >> on 2 different windows machines didn't raise any error or warning) and
> >> we suspect this could be tied to the use of BiocParallel. For Windows,
> >> in fact, we use SnowParam instead of MulticoreParam and as the vignette
> >> and manual of BiocParallel specifies we must ensure that every worker is
> >> loaded with the proper dependencies, but apparently this is not
> >> necessary if the function to execute in bplapply belongs to the package
> >> in question. Here is the code of the function that might raise some
> >> problems:
> >>
> >> .import_type <- function(q_type, files, workers) {
> >> files <- files %>% dplyr::filter(.data$Quantification_type == q_type)
> >> # Register backend according to platform
> >> if (.Platform$OS.type == "windows") {
> >>   p <- BiocParallel::SnowParam(workers = workers, stop.on.error = 
> >> FALSE)
> >> } else {
> >>   p <- BiocParallel::MulticoreParam(workers = workers, stop.on.error
> >> = FALSE)
> >> }
> >> # Import every file
> >> suppressMessages(suppressWarnings({
> >>   matrices <- BiocParallel::bptry(
> >> BiocParallel::bplapply(files$Files_chosen, FUN = function(x) {
> >>   matrix <- ISAnalytics::import_single_Vispa2Matrix(x)
> >> }, BPPARAM = p)
> >>   )
> >>   }))
> >> BiocParallel::bpstop(p)
> >> correct <- BiocParallel::bpok(matrices)
> >> imported_files <- files %>% dplyr::mutate(Imported = correct)
> >> matrices <- matrices[correct]
> >> # Bind rows in single tibble

Re: [Bioc-devel] Possible problems with BiocParallel and R cmd check on Github

[Henrik Bengtsson]

>From a very quick look at this, I think you also need to explicitly
install the package itself for it to be available in external R
session (contrary to when using forked processing as on Linux and
macOS).  Something like this:

- name: Install dependencies
run: |
  remotes::install_deps(dependencies = TRUE)
  remotes::install_cran("rcmdcheck")
  install.packages(".", repos=NULL, type="source") ## needed by
parallel workers
  shell: Rscript {0}

That's what I had to do when testing 'future'
(https://github.com/HenrikBengtsson/future/blob/1835a122764bbc0196c78be6da6973c8063922b3/.github/workflows/R-CMD-check.yaml#L69).

/Henrik

On Wed, Jul 29, 2020 at 10:18 AM Giulia Pais  wrote:
>
> Hi bioconductor team,
>
> we are currently developing a package for future submission on
> bioconductor which you can find here
> https://github.com/calabrialab/ISAnalytics.
>
> We use Github actions to keep track of R cmd checks at every commit, and
> this time, surprisingly for us, we had a failure on R cmd checks for
> windows (which is odd, since we develop on windows and performing check
> on 2 different windows machines didn't raise any error or warning) and
> we suspect this could be tied to the use of BiocParallel. For Windows,
> in fact, we use SnowParam instead of MulticoreParam and as the vignette
> and manual of BiocParallel specifies we must ensure that every worker is
> loaded with the proper dependencies, but apparently this is not
> necessary if the function to execute in bplapply belongs to the package
> in question. Here is the code of the function that might raise some
> problems:
>
> .import_type <- function(q_type, files, workers) {
>files <- files %>% dplyr::filter(.data$Quantification_type == q_type)
># Register backend according to platform
>if (.Platform$OS.type == "windows") {
>  p <- BiocParallel::SnowParam(workers = workers, stop.on.error = FALSE)
>} else {
>  p <- BiocParallel::MulticoreParam(workers = workers, stop.on.error
> = FALSE)
>}
># Import every file
>suppressMessages(suppressWarnings({
>  matrices <- BiocParallel::bptry(
>BiocParallel::bplapply(files$Files_chosen, FUN = function(x) {
>  matrix <- ISAnalytics::import_single_Vispa2Matrix(x)
>}, BPPARAM = p)
>  )
>  }))
>BiocParallel::bpstop(p)
>correct <- BiocParallel::bpok(matrices)
>imported_files <- files %>% dplyr::mutate(Imported = correct)
>matrices <- matrices[correct]
># Bind rows in single tibble for all files
>if (purrr::is_empty(matrices)) {
>  return(NULL)
>}
>matrices <- purrr::reduce(matrices, function(x, y) {
>  x %>% dplyr::bind_rows(y) %>% dplyr::distinct()
>})
>list(matrices, imported_files)
> }
>
> The report of the Github action can be found here:
> https://github.com/calabrialab/ISAnalytics/runs/923261561
>
> The check apparently fails with these warnings: Warning - namespace
> 'ISAnalytics' is not available and has been replaced. We tried adding
> 'library(ISAnalytics)' and 'require(ISAnalytics)' but if we do that
> BiocCheck fails with a warning, prompting for removal of this lines.
> Could this be a real issue with our package or just a problem with
> Github actions?
>
> Thanks in advance,
>
> Giulia Pais
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] How I hide non-exported function from the manual

[Henrik Bengtsson]

On Wed, Jun 3, 2020 at 10:40 PM Vincent Carey
 wrote:
>
> On Wed, Jun 3, 2020 at 11:48 PM stefano  wrote:
>
> > Hello Community,
> >
> > I am used to document function although hey are not exported
> >
> >
> I suppose you are talking about tidybulk?  I am somewhat mystified by the
> behavior
> of
>
> %vjcair> R CMD build tidybulk
>
> * checking for file ‘tidybulk/DESCRIPTION’ ... OK
>
> * preparing ‘tidybulk’:
>
> * checking DESCRIPTION meta-information ... OK
>
> * installing the package to process help pages
>
> * building the PDF package manual
>
> Hmm ... looks like a package
>
> Converting Rd files to LaTeX .
>
> Creating pdf output from LaTeX ...
>
>
> which produces a 147 page manual, and as you note many
>
> non-user-visible symbols are documented in manual.  I've
>
> never seen the "process help pages" phase in any
>)
> of my packages, and I don't know why.

This step happens iff you have \Sexpr{} macros in your man/*.Rd files
(see 
https://github.com/wch/r-source/blob/5bd6e3ce1430374105ebf02101f9d55173496cfe/src/library/tools/R/build.R#L582-L586)

/Henrik

>
>
> I don't have experience with the RdMacros setting in
>
> DESCRIPTION, and the way S3 methods are being handled
>
> in the package leads, I think, to an excess of Rd
>
> files relative to what you have as visible symbols
>
> in the package namespace.
>
>
> Perhaps some tidyverse experts can comment.
>
>
> > ```
> > #' Get differential transcription information to a tibble using edgeR.
> > #'
> > #' @import dplyr
> > #' @import tidyr
> > #' @import tibble
> > #' @importFrom magrittr set_colnames
> > #' @importFrom stats model.matrix
> > #' @importFrom utils installed.packages
> > #' @importFrom utils install.packages
> > #' @importFrom purrr when
> > #'
> > #'
> > #' @param .data A tibble
> > #' @param .formula a formula with no response variable, referring only to
> > numeric variables
> > #' @param .sample The name of the sample column
> > #' @param .transcript The name of the transcript/gene column
> > #' @param .abundance The name of the transcript/gene abundance column
> > #' @param .contrasts A character vector. See edgeR makeContrasts
> > specification for the parameter `contrasts`. If contrasts are not present
> > the first covariate is the one the model is tested against (e.g., ~
> > factor_of_interest)
> > #' @param method A string character. Either "edgeR_quasi_likelihood" (i.e.,
> > QLF), "edgeR_likelihood_ratio" (i.e., LRT)
> > #' @param significance_threshold A real between 0 and 1
> > #' @param minimum_counts A positive integer. Minimum counts required for at
> > least some samples.
> > #' @param minimum_proportion A real positive number between 0 and 1. It is
> > the threshold of proportion of samples for each transcripts/genes that have
> > to be characterised by a cmp bigger than the threshold to be included for
> > scaling procedure.
> > #' @param fill_missing_values A boolean. Whether to fill missing
> > sample/transcript values with the median of the transcript. This is rarely
> > needed.
> > #' @param scaling_method A character string. The scaling method passed to
> > the backend function (i.e., edgeR::calcNormFactors;
> > "TMM","TMMwsp","RLE","upperquartile")
> > #' @param omit_contrast_in_colnames If just one contrast is specified you
> > can choose to omit the contrast label in the colnames.
> > #'
> > #' @return A tibble with edgeR results
> > #'
> > get_differential_transcript_abundance_bulk <- function
> > [...]
> > ```
> >
> > However this leads to 2 problems
> >
> > 1) The PDF manual includes many function that are not accessible to the
> > user. How can I hide documented non-exported function from the manual
> > 2) I receive the Biocheck note. "You have  initialised objects".
> > Again how can I document an object without initialising it?
> >
> > Thanks a lot.
> >
> > Best wishes.
> >
> > *Stefano *
> >
> >
> >
> > Stefano Mangiola | Postdoctoral fellow
> >
> > Papenfuss Laboratory
> >
> > The Walter Eliza Hall Institute of Medical Research
> >
> > +61 (0)466452544
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> The information in this e-mail is intended only for th...{{dropped:6}}

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

Re: [Bioc-devel] Reducing dependencies

[Henrik Bengtsson]

RStudio provides pre-built R package for Linux and since a some weeks
now, they can be used on GitHub Actions
(https://github.com/r-lib/actions).  In addition, the run-time limit
on GitHub Actions is several hours compared to the 50 minutes you've'
got on Travis, so even if you install from source, you're less likely
to hit these limits on GitHub Actions.

Also, it could be that you could tweak/trick Travis to install above
Linux binary packages.

My $.02

/Henrik

On Tue, Jun 2, 2020 at 2:45 PM Koen Van den Berge
 wrote:
>
> Dear All,
>
> We have recently extended our Bioconductor package tradeSeq 
>  to allow 
> different input formats and accommodate extended downstream analyses, by 
> building on other R/Bioconductor packages.
> However this has resulted in a significant increase in the number of 
> dependencies due to relying on other packages that also have many 
> dependencies, for example causing very long build times on Travis 
> .
>
> We are therefore wondering about current recommendations to reduce the 
> dependency load. We have moved some larger packages from ‘Imports’ to 
> ‘Suggests’, but to no avail.
>
> Best,
> Koen
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] proper way to define an S4 method for 'plot'

[Henrik Bengtsson]

Maybe it's related to:

* The plot() S3 generic function is now in package base rather than
package graphics, as it is reasonable to have methods that do not use
the graphics package. The generic is currently re-exported from the
graphics namespace to allow packages importing it from there to
continue working, but this may change in future.

mentioned in the R 4.0.0 NEWS
(https://cran.r-project.org/doc/manuals/r-devel/NEWS.html)?

/Henrik

On Mon, Mar 16, 2020 at 3:52 PM Vincent Carey
 wrote:
>
> I just updated my R and I am getting into trouble with MLInterfaces
> maintenance.
>
> > BiocManager::install("MLInterfaces")
>
> *Bioconductor version 3.11 (BiocManager 1.30.10), R Under development
> (unstable)*
>
> *  (2020-03-15 r77975)*
>
> *Installing package(s) 'MLInterfaces'*
>
> *Warning: unable to access index for repository
> https://cran.rstudio.com/bin/macosx/el-capitan/contrib/4.0
> :*
>
> *  cannot open URL
> 'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/4.0/PACKAGES
> '*
>
>
>   There is a binary version available but the source version is later:
>
>  binary source needs_compilation
>
> MLInterfaces 1.67.2 1.67.5 FALSE
>
>
> *installing the source package ‘MLInterfaces’*
>
>
> *trying URL
> 'https://bioconductor.org/packages/3.11/bioc/src/contrib/MLInterfaces_1.67.5.tar.gz
> '*
>
> *Content type 'application/x-gzip' length 1071876 bytes (1.0 MB)*
>
> *==*
>
> *downloaded 1.0 MB*
>
>
> * installing *source* package ‘MLInterfaces’ ...
>
> ** using staged installation
>
> ** R
>
> ** inst
>
> ** byte-compile and prepare package for lazy loading
>
> Error in getGeneric(f, TRUE, envir, package) :
>
>   no generic function found for ‘plot’
>
> Calls:  ... namespaceImportFrom -> .mergeImportMethods ->
>  -> getGeneric
>
> recover called non-interactively; frames dumped, use debugger() to view
>
> ** help
>
> *** installing help indices
>
> ** building package indices
>
> ** installing vignettes
>
> ** testing if installed package can be loaded from temporary location
>
> Error: package or namespace load failed for ‘MLInterfaces’ in getGeneric(f,
> TRUE, envir, package):
>
>  no generic function found for ‘plot’
>
>
> ...
>
>
> > sessionInfo()
>
> R Under development (unstable) (2020-03-15 r77975)
>
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>
> Running under: macOS Mojave 10.14.6
>
>
> Matrix products: default
>
> BLAS:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.0.dylib
>
> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>
>
> locale:
>
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
>
> attached base packages:
>
> [1] stats graphics  grDevices utils datasets  methods   base
>
>
> other attached packages:
>
> [1] rmarkdown_2.1
>
>
> loaded via a namespace (and not attached):
>
>  [1] BiocManager_1.30.10 compiler_4.0.0  startup_0.14.0
>
>  [4] tools_4.0.0 htmltools_0.4.0 Rcpp_1.0.3
>
>  [7] codetools_0.2-16knitr_1.28  xfun_0.12
>
> [10] digest_0.6.25   rlang_0.4.5 evaluate_0.14
>
> --
> The information in this e-mail is intended only for th...{{dropped:6}}

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

Re: [Bioc-devel] Bioconductor Git: Online interface

[Henrik Bengtsson]

On Tue, Feb 11, 2020 at 2:42 PM Martin Morgan  wrote:
>
> (sending again from / to an appropriate email address, sorry for the noise)
>
> Henrik -- I appreciate the ease with which gitea can be deployed in this 
> one-off solution but cynically think that a real deployment would introduce 
> significant work, e.g., re-tooling our approach to new package addition, 
> management of user credentials, and integration of the nightly build system.

Among those examples, the only thing I see would be the workload of
adding/removing packages from Gitea so that it reflects what's on the
Git server.  Since Gitea can automatically sync with a Git server via
an URL, I don't see how things such as nightly builds etc come into
play.  User credentials should also not matter.  There should be no
backup needs other than possible one admin account with Swagger API
access.

>
> If you'd like to work on a more complete (off-line, so as not to present a 
> confusion of interfaces for the user and developer) implementation I'd be 
> happy to provide some pointers to the major challenges.

I proposed Gitea because I know it well now, it has GitHub like
features that people already knows about (e.g. linking to code
snippets 
https://gitea.com/hb/aroma.light/src/branch/master/R/iwpca.R#L147-L152),
and it has the more potentials/features if you choose to go down that
route. I know there are other Git-to-webpage tools out there, which
are purely designed for viewing. It might be that those are a safer
route to go down. Given how easy it is to set up Gitea for this, and
Gitea has much more features, I'd be surprise if it wouldn't be as
easy for those tools too.  It could be that they're zero-config, e.g.
point to the folder where the git repositories live and you're ready
to go live.

Feel free to forward discussions/ideas (better if already public
somewhere; there might be others who can pitch in too), but
unfortunately I don't have much spare cycles to work on this.

Being able to browse code and link to code when reaching out to
maintainers is something Bioconductor is really missing right now.
This would lower the friction for contributing to packages that you
don't work on on a regular basis, e.g. typos, bug fixes, etc.

Henrik

>
> Martin
>
> On 2/11/20, 5:16 PM, "Bioc-devel on behalf of Henrik Bengtsson" 
>  
> wrote:
>
> I wanna revive this old thread.
>
> I've used Gitea for internal git/issue trackers at the UCSF for quite
> a while now and it works really well.  I've also looked into how easy
> it would be to use it for pure code exposure and it's pretty
> straightforward.  Gitea even has built-in tools for automatically
> synchronize toward an existing git server *and* keep it up-to-date,
> which makes the process even easier(*).  An example what this looks
> like is:
>
>   https://gitea.com/hb/aroma.light
>
> That took me literally 15 seconds to set up.  Note how this is almost
> a bare bone *read-only* git code browser, e.g. there's no issue
> tracker.  Right now, it would require a teeny hack on the Gitea server
> to have the 'git clone' URL to map to the official Bioconductor URL
> (or to hide it completely).  It's also possible to link the 'Issue
> Tracker' to, say, GitHub issues based on what's in BugReports:, e.g.
>
>   https://gitea.com/hb/QDNAseq
>
> Note that the above read-only approach completely avoids having to map
> or maintain user accounts; it's a pure read-only online viewer of the
> Bioconductor git repositories.  (Depending on your setup, it might
> even be that you can expose the Gitea interface as
> https://git.bioconductor.org/ and have
> https://git.bioconductor.org/packages/ take you to the Gitea
> package page.)  There's a Swagger API that makes it possible to
> automate everything, e.g. creating new repositories for new Bioc
> packages.
>
> I'd classify this as a low risk and straightforward project to implement.
>
> /Henrik
>
> (*) Technical details: The most efficient approach would probably be
> to link to the existing git repositories via the file system, rather
> than going over ssh/https. Linking via the file system avoids any
> duplication.  The storage load of running such a Gitea instance would
> be very very small.  The Gitea instance don't need write permissions
> to the repositories, so there is no risk of Gitea messing up existing
> git repositories.
>
> On Thu, Oct 26, 2017 at 1:51 AM Martin Morgan
>  wrote:
> >
> > There has been previous discussion about this.
> >
> >https://stat.ethz.ch/pipermail/bioc-devel/2017-September/011455.html
> >
> > It is not in our short-term plan

Re: [Bioc-devel] Bioconductor Git: Online interface

[Henrik Bengtsson]

I wanna revive this old thread.

I've used Gitea for internal git/issue trackers at the UCSF for quite
a while now and it works really well.  I've also looked into how easy
it would be to use it for pure code exposure and it's pretty
straightforward.  Gitea even has built-in tools for automatically
synchronize toward an existing git server *and* keep it up-to-date,
which makes the process even easier(*).  An example what this looks
like is:

  https://gitea.com/hb/aroma.light

That took me literally 15 seconds to set up.  Note how this is almost
a bare bone *read-only* git code browser, e.g. there's no issue
tracker.  Right now, it would require a teeny hack on the Gitea server
to have the 'git clone' URL to map to the official Bioconductor URL
(or to hide it completely).  It's also possible to link the 'Issue
Tracker' to, say, GitHub issues based on what's in BugReports:, e.g.

  https://gitea.com/hb/QDNAseq

Note that the above read-only approach completely avoids having to map
or maintain user accounts; it's a pure read-only online viewer of the
Bioconductor git repositories.  (Depending on your setup, it might
even be that you can expose the Gitea interface as
https://git.bioconductor.org/ and have
https://git.bioconductor.org/packages/ take you to the Gitea
package page.)  There's a Swagger API that makes it possible to
automate everything, e.g. creating new repositories for new Bioc
packages.

I'd classify this as a low risk and straightforward project to implement.

/Henrik

(*) Technical details: The most efficient approach would probably be
to link to the existing git repositories via the file system, rather
than going over ssh/https. Linking via the file system avoids any
duplication.  The storage load of running such a Gitea instance would
be very very small.  The Gitea instance don't need write permissions
to the repositories, so there is no risk of Gitea messing up existing
git repositories.

On Thu, Oct 26, 2017 at 1:51 AM Martin Morgan
 wrote:
>
> There has been previous discussion about this.
>
>https://stat.ethz.ch/pipermail/bioc-devel/2017-September/011455.html
>
> It is not in our short-term plans to offer a full on-line solution, but
> not impossible in a longer context.
>
> Martin
>
> On 10/26/2017 03:01 AM, Stian Lågstad wrote:
> > I would very much appreciate this as well. Issue tracking and communicating
> > with users directly in the repository would be very nice, as well as the
> > ability to reference source code directly.
> >
> > On Thu, Oct 26, 2017 at 8:50 AM, Henrik Bengtsson <
> > henrik.bengts...@gmail.com> wrote:
> >
> >> Are there any plans for an online interface to
> >> https://git.bioconductor.org/?
> >>
> >> I've recently looked into solutions for an open-source in-house
> >> "GitHub/GitLab"-ish, and I've found https://gitea.io/ to be really
> >> nice.  It is very easy to install. It has support for various common
> >> user authentication methods, it supports organizations and user teams,
> >> repositories may have issues and wikis, sets of code lines can be
> >> referenced, commits and code diffs are annotated, and so on.  Wikis
> >> and issue trackers can be disabled (also for individual repositories).
> >> That's all I've learned thus far - I'm impressed.
> >>
> >> Just a thought
> >>
> >> Henrik
> >>
> >> ___
> >> 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] New setting on devel builders will cause some new package failures

[Henrik Bengtsson]

This is great news.  For those who wish to reproduce this locally when
running R CMD check, I suggest creating '~/.R/check.Renviron' with:

## Check for bugs like if (c(TRUE, FALSE)) ... Supported since R 3.4.0
_R_CHECK_LENGTH_1_CONDITION_=package:_R_CHECK_PACKAGE_NAME_,verbose

## Check for bugs like c(TRUE, FALSE) && TRUE. Supported since R 3.6.0
_R_CHECK_LENGTH_1_LOGIC2_=package:_R_CHECK_PACKAGE_NAME_,verbose

These environment variables will be applied only when running 'R CMD
check'.  The 'package:_R_CHECK_PACKAGE_NAME_' part makes sure these
bugs trigger check ERRORs only on the package being tested, i.e. you
can check for these bugs in your package also when one of your
dependencies have this bug.

If you want to detect these errors when you run R in general, e.g. in
your analysis, you can add:

_R_CHECK_LENGTH_1_CONDITION_=${_R_CHECK_LENGTH_1_CONDITION_-verbose}
_R_CHECK_LENGTH_1_LOGIC2_=${_R_CHECK_LENGTH_1_LOGIC2_-verbose}

to your ~/.Renviron.  This will trigger a run-time error whenever and
wherever this bug occurs.  If you prefer to get warnings instead of
errors, use 'warn,verbose' instead of 'verbose'.  If you find these
mistakes in other packages, please consider taking the time to report
the maintainer.

/Henrik

On Fri, Jan 24, 2020 at 6:07 AM Shepherd, Lori
 wrote:
>
> Hello developers,
>
> As a heads up notification,  we have enabled the check setting for 
> _R_CHECK_LENGTH_1_LOGIC2_  on the main daily builders (this setting was 
> already active for incoming submissions on the single package builder).  New 
> ERROR's relating to this setting should be seen on the daily build reports 
> either today or tomorrow.  Your packages may need adjustment to account for 
> this setting.  This setting will catch logic ERROR similar to the following:
>
> > Sys.setenv(`_R_CHECK_LENGTH_1_LOGIC2_`="true")
> > c(TRUE, TRUE) && TRUE
> Error in c(TRUE, TRUE) && TRUE :
>   'length(x) = 2 > 1' in coercion to 'logical(1)'
>
> Note:  The syntax ERROR in this case is using && which anticipates scalar 
> comparison vs a vector comparison   (similar for ||  vs | )
>
> > c(TRUE, TRUE) & TRUE
> [1] TRUE TRUE
>
>
> Also Note:
>
> The logic check for conditionals greater than length one has been implemented 
> since the beginning of the last release so the following are also caught but 
> with _R_CHECK_LENGTH_1_CONDITION_  so technically the above solution would 
> also be an ERROR if it was in a conditional.
> > Sys.setenv(`_R_CHECK_LENGTH_1_CONDITION_`="true")
> > Sys.setenv(`_R_CHECK_LENGTH_1_LOGIC2_`="true")
> > if( c(TRUE, TRUE) && TRUE ) "yes"
> Error in c(TRUE, TRUE) && TRUE :
>   'length(x) = 2 > 1' in coercion to 'logical(1)'
>
> > if( c(TRUE, TRUE) & TRUE ) "yes"
> Error in if (c(TRUE, TRUE) & TRUE) "yes" : the condition has length > 1
>
> # any and all could be useful in these cases
> > if( all(c(TRUE, TRUE)) & TRUE ) "yes"
> [1] "yes"
>
>
> We made these changes as we have been notified by the R development team that 
> the goal is to make these setting default in a near future version of 
> R-devel.  We therefore are implementing now to allow maintainers to have as 
> much notice as possible.
>
>
> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] What are the R CMD check settings (env vars) that Bioc uses?

[Henrik Bengtsson]

Thank you - sounds great. /Henrik

On Tue, Dec 3, 2019 at 9:23 AM Pages, Herve  wrote:
>
> Hi Henrik,
>
> On 12/3/19 09:13, Henrik Bengtsson wrote:
> > I'm interested in finding out what customization Bioconductor servers
> > do to R CMD check, e.g. _R_CHECK_***_ settings.  I think someone
> > pointed me to some location in the past, but I cannot locate it.
>
> The settings on the Linux/Mac builders are:
>
>https://github.com/Bioconductor/BBS/blob/master/3.11/R_env_vars.sh
>
> and on the Windows builder they are:
>
>https://github.com/Bioconductor/BBS/blob/master/3.11/R_env_vars.bat
>
> We just moved those settings to their own files yesterday (good timing)
> to make it easier to re-use them for the devel docker image (see
> https://github.com/Bioconductor/bioconductor_full/pull/20#issuecomment-560546981).
>
> >  I
> > think a natural place to document those would be on the 'Node Info'
> > pages together with the existing platform and compiler information,
> > e.g. 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_malbec2-2DNodeInfo.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=vTnT-DDbyP899v1VHljMc9jEcFqcbhXe6Dk3aTtU_YA=AFrilsJa2FP3Gk7trNjD2KuWa0WegOBq6ig8SHl0-sI=
> >  .
>
> Exactly. That's the plan.
>
> Cheers,
> H.
>
> >
> > Thanks,
> >
> > Henrik
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=vTnT-DDbyP899v1VHljMc9jEcFqcbhXe6Dk3aTtU_YA=Cc5slvLV6zlwGr9LwvWDwH44Dc5_zv-CoLF6Q83l9bE=
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

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

[Bioc-devel] What are the R CMD check settings (env vars) that Bioc uses?

[Henrik Bengtsson]

I'm interested in finding out what customization Bioconductor servers
do to R CMD check, e.g. _R_CHECK_***_ settings.  I think someone
pointed me to some location in the past, but I cannot locate it.  I
think a natural place to document those would be on the 'Node Info'
pages together with the existing platform and compiler information,
e.g. 
http://bioconductor.org/checkResults/devel/bioc-LATEST/malbec2-NodeInfo.html.

Thanks,

Henrik

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

[Bioc-devel] CRAN packages depending on broken Bioc 3.11 packages may be archived

[Henrik Bengtsson]

In case it's not known, paraphrasing from CRAN notification email,
CRAN [sic!] packages:

  TROM, demi, diffMeanVar, maGUI, metaboGSE

risk being archived on December 7 because broken Bioconductor dependencies:

  Heatplus, missMethyl, oligo, oligoClasses, topGO

prevent pdInfoBuilder from being installed.

I don't maintain any of the above - I'm just the messenger.

/Henrik

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

Re: [Bioc-devel] BiocManager::install() downgrade installed packages

[Henrik Bengtsson]

On Thu, Oct 31, 2019 at 11:52 AM James W. MacDonald  wrote:
>
> The main goal for BiocManager is to help end users ensure that their R/BioC 
> installation is consistent for the version of R that they are using. So by 
> definition, any packages that are outside the versions for a given R/BioC 
> installation should be up or down-graded to make the installation valid. 
> There are those of us who are l33t enough to mix'n'match packages and debug 
> errors that may then occur. But it's probably not a good idea to make it 
> easily hacked by naive users, allowing them to do things that might cause 
> problems.
>
> Anyway, I believe doing
>
> options("BIOCMANAGER_CRANCHECK_BEHAVIOR" = FALSE)
>
> will stop BiocManager::install from changing any installed CRAN packages. And 
> it's suitably obscure to limit that to the cool kids who can find it.

Unfortunately, this doesn't seem to make a difference.  By searching
the GitHub code base it doesn't look like this option is used
anywhere: 
https://github.com/search?q=org%3ABioconductor+BIOCMANAGER_CRANCHECK_BEHAVIOR=Code

My current workaround it to not use BiocManager and roll my own
'repos' settings;

> unname(getOption("repos"))
[1] "https://cloud.r-project.org;
[2] "https://bioconductor.org/packages/3.10/bioc;
[3] "https://bioconductor.org/packages/3.10/data/annotation;
[4] "https://bioconductor.org/packages/3.10/data/experiment;
[5] "https://bioconductor.org/packages/3.10/workflows;

and use good old update.packages().

Alternative wish: It would be handy if there was a
BiocManager::repositories(version = "3.10") for finding these,
especially since some of them come and go depending on Bioc version.

/Henrik

PS. I also tried setting ditto env var because it looked more like an
env var than R option name to me.

>
> On Thu, Oct 31, 2019 at 2:21 PM Henrik Bengtsson  
> wrote:
>>
>> (posting this here since I think it's not a support question per se)
>>
>> Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1 
>> setup:
>>
>> > BiocManager::install(version = "3.10")
>> Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y
>> Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched (2019-09-12
>>   r77183)
>> Installing package(s) 'BiocVersion'
>> ...
>> Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv',
>>   'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck', 'scales',
>>   'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate',
>>   'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase', 'BiocCheck',
>>   'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion', 'biocViews',
>>   'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib', 'DelayedArray',
>>   'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter', 'GenomeInfoDb',
>>   'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db', 'graph',
>>   'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges',
>>   'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db',
>>   'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19', 
>> 'QDNAseq.mm10',
>>   'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib', 'Rsamtools',
>>   'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4', 'SummarizedExperiment',
>>   'XVector', 'zlibbioc'
>> trying URL 'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz'
>> Content type 'application/x-gzip' length 7833 bytes
>> ==
>> downloaded 7833 bytes
>>
>> trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz'
>> Content type 'application/x-gzip' length 294967 bytes (288 KB)
>> ==
>> downloaded 288 KB
>> ...
>>
>> It surprised me that BiocManager::install() will _downgrade_ to CRAN(*)
>> package versions, even if you have newer versions installed.  For
>> instance, I've got base64enc 0.1.4 from
>> http://www.rforge.net/base64enc/, my own development version of future
>> 1.14.0-9000, and so on.  Note that the prompt says nothing about
>> downgrading. Is this really wanted and is there a way to avoid this?
>>
>> (*) Will this also downgrade Bioc developers' Bioc packages?
>>
>> Thanks,
>>
>> Henrik
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099

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

[Bioc-devel] BiocManager::install() downgrade installed packages

[Henrik Bengtsson]

(posting this here since I think it's not a support question per se)

Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1 setup:

> BiocManager::install(version = "3.10")
Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y
Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched (2019-09-12
  r77183)
Installing package(s) 'BiocVersion'
...
Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv',
  'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck', 'scales',
  'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate',
  'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase', 'BiocCheck',
  'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion', 'biocViews',
  'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib', 'DelayedArray',
  'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter', 'GenomeInfoDb',
  'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db', 'graph',
  'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges',
  'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db',
  'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19', 'QDNAseq.mm10',
  'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib', 'Rsamtools',
  'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4', 'SummarizedExperiment',
  'XVector', 'zlibbioc'
trying URL 'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz'
Content type 'application/x-gzip' length 7833 bytes
==
downloaded 7833 bytes

trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz'
Content type 'application/x-gzip' length 294967 bytes (288 KB)
==
downloaded 288 KB
...

It surprised me that BiocManager::install() will _downgrade_ to CRAN(*)
package versions, even if you have newer versions installed.  For
instance, I've got base64enc 0.1.4 from
http://www.rforge.net/base64enc/, my own development version of future
1.14.0-9000, and so on.  Note that the prompt says nothing about
downgrading. Is this really wanted and is there a way to avoid this?

(*) Will this also downgrade Bioc developers' Bioc packages?

Thanks,

Henrik

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

Re: [Bioc-devel] Reference manual as HTML

[Henrik Bengtsson]

On Wed, Sep 25, 2019 at 2:28 PM Stuart Lee  wrote:
>
> Chiming in to say +1 to this. I also use pkgdown for the same purpose as 
> Laurent. With some kind of CI service you can automate the build of the 
> website after a successful R CMD CHECK. Not sure how tricky this would be to 
> integrate with Bioconductor's build system.

FYI, 'pkgdown' only supports vignettes that are written in the
Rmarkdown format (https://github.com/r-lib/pkgdown/issues/781).

/Henrik

> 
> From: Bioc-devel  on behalf of Martin 
> Morgan 
> Sent: Thursday, 26 September 2019 7:10 AM
> To: Laurent Gatto ; Ludwig Geistlinger 
> ; bioc-devel@r-project.org 
> 
> Subject: Re: [Bioc-devel] Reference manual as HTML
>
> Our recollection is that there is no 'flag' in R CMD build to create HTML 
> rather than PDF vignettes; without that it would be non-trivial to create 
> html output, e.g., links across pages. (I *think* the installed package html 
> help pages are generated on the fly...)
>
> What is your experience with pkgdown?
>
> Martin
>
> On 9/25/19, 9:44 AM, "Bioc-devel on behalf of Laurent Gatto" 
>  
> wrote:
>
> I think this would be very useful. This is one of the reasons I create 
> pkgdown sites for my packages: manual pages, news and html vignettes are 
> readily available for all (including me) to browse.
>
> Best wishes,
>
> Laurent
>
> 
> From: Bioc-devel  on behalf of Ludwig 
> Geistlinger 
> Sent: 25 September 2019 13:31
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Reference manual as HTML
>
> Dear Bioc-Team,
>
>
> I repeatedly wondered whether it would be possible to display the 
> reference manual
> as HTML instead of PDF on a package's landing page. This is already 
> possible for vignettes.
>
> HTML reference manuals have at least two advantages:
>
> 1. links to functions of other package in the man pages of my package 
> would
> actually work. Links to functions / classes of other packages of the form
>
> \code{\link{p.adjust}}
>
> or
>
> \code{\linkS4class{SummarizedExperiment}}
>
> within the pdf reference manual currently point nowhere (bring me back to 
> the
> first page of the pdf). Within the html reference manual
>
> help(package="myPackage", help_type="html")
>
> these links work as expected, ie bring me to the help pages of functions 
> / classes
> of other packages.
>
> 2. I could easily refer users to the documentation link of a specific 
> function
> (without them having to search through the pdf) such as "check the 
> documentation of
> the DESeq function here: https://rdrr.io/bioc/DESeq2/man/DESeq.html;.
>
> (where the link would be preferably: 
> bioconductor.org/packages/DESeq2/man/DESeq.html).
>
>
> Thank you,
>
> Ludwig
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
>
> The information in this email is confidential and intended solely for the 
> addressee.
> You must not disclose, forward, print or use it without the permission of the 
> sender.
>
> The Walter and Eliza Hall Institute acknowledges the Wurundjeri people of the 
> Kulin
> Nation as the traditional owners of the land where our campuses are located 
> and
> the continuing connection to country and community.
> ___
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Duplicated method names in purrr and GenomicRanges

[Henrik Bengtsson]

Just an FYI, *if* all you're doing is rbind():ing those data frames,
then you're better of doing:

  df <- do.call(rbind, dfs)

than

  df <- Reduce(rbind, dfs)

because the former is faster and more memory efficient:

> dfs <- rep(list(iris), times=100)
> bench::mark(df <- Reduce(rbind, dfs))[,1:7]
# A tibble: 1 x 7
  expressionmin   median `itr/sec` mem_alloc `gc/sec` n_itr
 
1 df <- Reduce(rbind, dfs)   65.5ms   68.6ms  13.6 108MB 30.7 8
Warning message:
Some expressions had a GC in every iteration; so filtering is disabled.

> bench::mark(df <- do.call(rbind, dfs))[,1:7]
# A tibble: 1 x 7
  expression min   median `itr/sec` mem_alloc `gc/sec` n_itr
  
1 df <- do.call(rbind, dfs)   8.67ms   9.47ms  105.  14MB 49.534

/Henrik

On Fri, Sep 13, 2019 at 5:39 AM  wrote:
>
> Thank you for all of your answers. Michaels solution works fine for me.
> I had to merge a list of data.frames. Used the solution in this thread here:
>
> https://stackoverflow.com/questions/8091303/simultaneously-merge-multiple-data-frames-in-a-list
>
> Am 12.09.19 um 13:05 schrieb Michael Lawrence via Bioc-devel:
> > Third option: use Reduce() from base instead of purr::reduce().
> >
> > On Thu, Sep 12, 2019 at 2:54 AM O'CALLAGHAN Alan
> >  wrote:
> >> Hi,
> >>
> >> Two options.
> >>
> >> First option: import either purrr::reduce or GenomicRanges::reduce, and
> >> call the other with [pkg]::reduce.
> >>
> >> Second option: remove the import for both of these. Use purrr::reduce
> >> and GenomicRanges::reduce to call both functions.
> >>
> >> I think the second option leads to clearer code and would be my definite
> >> preference.
> >>
> >>
> >> On 12/09/2019 10:07, bio...@posteo.de wrote:
> >>> Dear all,
> >>>
> >>> I am developing a Bioconductor package and have a problem with two
> >>> methods which have the same name. I am using the reduce() function
> >>> from the R packages GenomicRanges and purrr. All methods from other
> >>> packages are imported with @importFrom in all of my functions.
> >>>
> >>>
> >>> During devtools::document() I get the following Warning:
> >>>
> >>> ...
> >>>
> >>> replacing previous import ‘GenomicRanges::reduce’ by ‘purrr::reduce’
> >>> when loading ‘testPackage’
> >>>
> >>> ...
> >>>
> >>>
> >>> Here are my NAMESPACE entries:
> >>>
> >>> # Generated by roxygen2: do not edit by hand
> >>>
> >>> export(mergeDataFrameList)
> >>> export(reduceDummy)
> >>> importFrom(GenomicRanges,GRanges)
> >>> importFrom(GenomicRanges,reduce)
> >>> importFrom(IRanges,IRanges)
> >>> importFrom(dplyr,"%>%")
> >>> importFrom(dplyr,left_join)
> >>> importFrom(dplyr,mutate)
> >>> importFrom(dplyr,pull)
> >>> importFrom(magrittr,"%<>%")
> >>> importFrom(purrr,reduce)
> >>> importFrom(tibble,tibble)
> >>>
> >>>
> >>> I am not using both reduce functions in the same function. To use the
> >>> GenomicRanges reduce function, I have to call this function like this:
> >>> GenomicRanges::reduce().
> >>>
> >>> I understand the warning and why I have to call the reduce function
> >>> like this. Is there a solution for this problem? Compiling a R package
> >>> with warnings and calling functions like this is not the best way I
> >>> guess.
> >>>
> >>> I am using R version 3.6.1 (2019-07-05)
> >>>
> >>> Thanks for help!
> >>>
> >>> Best,
> >>>
> >>> Tobias
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >> The University of Edinburgh is a charitable body, registered in Scotland, 
> >> with registration number SC005336.
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Using SerialParam() as the registered back-end for all platforms

[Henrik Bengtsson]

On Mon, Jan 7, 2019 at 4:09 AM Martin Morgan  wrote:
>
> I hope for 1. to have a 'local socket' (i.e., not using ports) implementation 
> shortly.
>
> I committed a patch in 1.17.6 for the wrong-seeming behavior of 2. We now have
>
> > library(BiocParallel)
> > set.seed(1); p = bpparam(); rnorm(1)
> [1] -0.6264538
> > set.seed(1); p = bpparam(); rnorm(1)
> [1] -0.6264538
>
> at the expensive of using the generator when the package is loaded.
>
> > set.seed(1); rnorm(1)
> [1] -0.6264538
> > set.seed(1); library(BiocParallel); rnorm(1)
> [1] 0.1836433
>
> Is that bad? It will be consistent across platforms.

Contrary to resampling methods etc., the RNG for generating random
ports does _not_ have to be statistically sound.  Because of this, you
should be able to generate a random port while *preserving the RNG
state*, i.e. undoing .GlobalEnv$.Random.seed (including removing if in
a fresh R session).   I decided to add this approach for
future::makeClusterPSOCK()
[https://github.com/HenrikBengtsson/future/blob/073e1d1/R/makeClusterPSOCK.R#L76-L82].

BTW, here's a useful development tool for detecting when the
.Random.seed has been updated in an interactive session:

addTaskCallback(local({
  last <- .GlobalEnv$.Random.seed
  function(...) {
curr <- .GlobalEnv$.Random.seed
if (!identical(curr, last)) {
  warning(".Random.seed changed", call. = FALSE, immediate. = TRUE)
  last <<- curr
}
TRUE
  }
}), name = "RNG tracker")

>
> This behavior
>
> > set.seed(1); unlist(bplapply(1:2, function(i) rnorm(1)))
> [1] 0.9624337 0.8925947
> > set.seed(1); unlist(bplapply(1:2, function(i) rnorm(1)))
> [1] -0.5703597  0.1102093
>
> seems wrong, but is consistent with mclapply
>
> > set.seed(1); unlist(mclapply(1:2, function(i) rnorm(1)))
> [1] -0.02704527  0.40721777
> > set.seed(1); unlist(mclapply(1:2, function(i) rnorm(1)))
> [1] -0.8239765  1.2957928

FWIW, without having invested much time tracking down why the design
is what it is, I'm getting concerned about how parallel::mclapply()
does parallel RNG out of the box when RNGkind("L'Ecuyer-CMRG") is in
use.  For example:

> library(parallel)
> RNGkind("L'Ecuyer-CMRG")
> unlist(mclapply(1:2, function(i) rnorm(1)))  ## mc.set.seed = TRUE
[1] -0.71727  0.56171
> unlist(mclapply(1:2, function(i) rnorm(1)))
[1] -0.71727  0.56171
> unlist(mclapply(1:2, function(i) rnorm(1)))
[1] -0.71727  0.56171

I wonder how many resampling/bootstrap studies are bitten by this
behavior.  Same if you use mc.set.seed = FALSE;

> unlist(mclapply(1:2, function(i) rnorm(1), mc.set.seed = FALSE))
[1] -0.8518311 -0.8518311
> unlist(mclapply(1:2, function(i) rnorm(1), mc.set.seed = FALSE))
[1] -0.8518311 -0.8518311
> unlist(mclapply(1:2, function(i) rnorm(1), mc.set.seed = FALSE))
[1] -0.8518311 -0.8518311


Here is how I think about parallel RNG right now:

1. To achieve fully numerically reproducible RNGs in way that is
*invariant to the number of workers* (amount of chunking), I think the
only solution is to pregenerated RNG seeds (using
parallel::nextRNGStream()) for each individual iteration (element).
In other words, if a worker will process K elements, then the main R
process needs to generate K RNG seeds and pass those along to the
work.  I use this approach for future.apply::future_lapply(...,
future.seed = TRUE/), which then produce identical RNG
results regardless of backend and amount of chunking.  In the past, I
think I've seen Martin suggesting something similar as a manual
approach to some users.

2. The above approach is obviously expensive, especially when there
are a large number of elements to iterate over.  Because of this I'm
thinking providing an option to use only one RNG seed per worker
(which is the common approach used elsewhere)
[https://github.com/HenrikBengtsson/future.apply/issues/20].  This
won't be invariant to the number of workers, but it "should" still be
statistically sound.  This approach will give reproducible RNG results
given the same initial seed and the same amount of chunking.

3. For algorithms which do not rely on RNG, we can ignore both of the
above.  The problem is that it's not always known to the
user/developer which methods depend on RNG or not.  The above 'RNG
tracker' helps to identify some, but things might also change over
time.  I believe there's room for automating this in one way or the
other.  For instance, having a way to declare a function being
dependent on RNG or not could help.  Static code inspection could also
do it, e.g. when an R package is built and it could be part of the R
CMD checks to validate.

4. Are there other approaches?

/Henrik

>
> The documented behavior is to us the RNGseed= argument to *Param, but I think 
> it could be made consistent (by default, obey the global random number seed 
> on workers) at least on a single machine (where the default number of cores 
> is constant).
>
> I have not (yet?) changed the default behavior to SerialParam. I guess the 
> cost of SerialParam is from the 

Re: [Bioc-devel] Controlling vignette compilation order

[Henrik Bengtsson]

On Sat, Dec 22, 2018 at 10:56 AM Michael Lawrence
 wrote:
>
> Anything that eventually lands in inst/doc is a vignette, I think, so
> there might be a hack around that.

Just so this is not misread - it's *not* possible to just hack your
vignette "product" files (PDF or HTML) into inst/doc and thinking
you're good.  R keeps track of package vignettes in a "vignette
index", e.g.

> readRDS(system.file(package = "utils", "Meta", "vignette.rds"))
File  TitlePDFR Depends Keywords
1 Sweave.Rnw Sweave User Manual Sweave.pdf Sweave.R   tools

which is created during 'R CMD build' by parsing and compiling the
vignettes 
(https://github.com/wch/r-source/blob/tags/R-3-5-2/src/library/tools/R/build.R#L283-L393).
This vignette index is used to find package vignettes (e.g.
utils::vignette()) and build the HTML vignette index.

Also, one vignette source (e.g. Rnw, Rmd, ...) can only produce one
vignette product (PDF or HTML) in the vignette index.  You can output
other files (e.g. image files) in a relative folder that the vignette
references, which is why for instance non-self-contained HTML files
work.  Thus, one ad-hoc, not-so-nice hack that OP could do is to have
a single main vignette that produces and links to all child vignettes.
However, personally, I'd aim for using memoization/caching (to file)
such that each vignette can be compiled independently of the others
(and in any order), while still reusing intermediate
results/calculations produced by earlier vignettes.

/Henrik

>
> On Fri, Dec 21, 2018 at 11:26 PM Aaron Lun
>  wrote:
> >
> > I gave it a shot:
> >
> > https://github.com/LTLA/DrakeTest 
> >
> > This uses a single “controller” Rmd file to trigger Drake::make. Running 
> > this file will instruct Drake to compile all of the other vignettes 
> > following the desired dependency structure.
> >
> > The current sticking point is that I need to move the Drake-controlled Rmd 
> > files out of “vignettes/“, otherwise they’ll just be compiled as usual 
> > without consideration of their dependencies. This causes problems as R CMD 
> > BUILD only recognizes the controller Rmd file as the sole vignette, and 
> > doesn’t retain or index the HTML files produced from the other Rmd files as 
> > side-effects of running the controller.
> >
> > Are there any better ways to subvert the vignette building procedure to get 
> > the desired effect of running drake::make() and recognition of the 
> > resulting HTMLs as vignettes?
> >
> > -A
> >
> > > On 18 Dec 2018, at 17:41, Michael Lawrence  
> > > wrote:
> > >
> > > Sounds like a use case for drake...
> > >
> > > On Tue, Dec 18, 2018 at 6:58 AM Aaron Lun 
> > >  > > > wrote:
> > > @Michael In this case, the resource produced by vignette X is a 
> > > SingleCellExperiment object containing the results of various processing 
> > > steps (normalization, clustering, etc.) described in that vignette.
> > >
> > > I can imagine a lazy evaluation model for this, but it wouldn’t be 
> > > pretty. If I had another vignette Y that depended on the SCE produced by 
> > > vignette X, I would need Y to execute all of the steps in X if X hadn’t 
> > > already been run before Y. This gets us into the territory of 
> > > Makefile-like dependencies, which seems even more complicated than simply 
> > > specifying a compilation order.
> > >
> > > You might ask why X and Y are split into two separate vignettes. The use 
> > > of different vignettes is motivated by the complexity of the workflows:
> > >
> > > - Vignette 1 demonstrates core processing steps for one read-based 
> > > single-cell RNAseq dataset.
> > > - Vignette 2 demonstrates (slightly different) core steps for a UMI-based 
> > > dataset.
> > > - … so on for a bunch of other core steps for different types of data.
> > > - Vignette 6 demonstrates extra optional steps for the two SCEs produced 
> > > by vignettes 1 & 3.
> > > - … and so on for a bunch of other optional steps.
> > >
> > > The separation between core and optional steps into separate documents is 
> > > desirable. From a pedagogical perspective, I would very much like to get 
> > > the reader through all the core steps before even considering the extra 
> > > steps, which would just be confusing if presented so early on. 
> > > Previously, everything was in a single document, which was difficult to 
> > > read (for users) and to debug (for me), especially because I had to use 
> > > contrived variable names to avoid clashes between different sections of 
> > > the workflow that did similar things.
> > >
> > > @Martin I’ve been using BiocFileCache for all of the online resources 
> > > that are used in the workflow. However, this is only for my (and the 
> > > reader’s) convenience. I use a local cache rather than the system 
> > > default, to ensure that the downloaded files are removed after package 
> > > build. This is intentional as it forces 

Re: [Bioc-devel] choosing R version dependency for existing packages

[Henrik Bengtsson]

I'm using

Depends: R (>= 2.12.0)

to communicate that I've tested/verified that the package works as far
back as R 2.12.0.


Also, since R (>= 3.5.1) and R (>= 3.5.0) has been mentioned here, in
'Writing R Extensions' there is:

"It is inadvisable to use a dependence on R with patchlevel (the third
digit) other than zero. Doing so with packages which others depend on
will cause the other packages to become unusable under earlier
versions in the series, and e.g. versions 3.x.1 are widely used
throughout the Northern Hemisphere academic year."

which suggests one should aim for R (>= x.y.0).  This is also tested
by `R CMD check --as-cran` or `_R_CHECK_R_DEPENDS_=warn R CMD check`,
e.g.

* checking package directory ... OK
* checking DESCRIPTION meta-information ... WARNING
Dependence on R version ‘3.5.1’ not with patchlevel 0
* checking top-level files ... OK

The source code comments
(https://github.com/wch/r-source/blob/R-3-5-branch/src/library/tools/R/check.R#L982-L1008)
give more motivation behind this check:

## Dependence on say R >= 3.4.3 when 3.4 is current can
## cause problems with revdeps (and did for 3.2.x).
## We only check recent ones: maybe previous two
## (R-release and R-old-release) while this is R-devel

I believe this is written from the perspective of CRAN and their tests.

/Henrik
On Sat, Nov 3, 2018 at 12:27 PM Paul Shannon
 wrote:
>
> Thanks, Martin.
>
> I have backed off MotifDB’s R requirement to 3.5.0.  I will experiment with 
> removing the requirement entirely in the new devel branch.
>
>  - Paul
>
> > On Nov 3, 2018, at 1:37 AM, Martin Morgan  wrote:
> >
> > If users are 'playing by the books' and using BiocManager::install(), the 
> > version of R is coupled with the version of Bioconductor / your package, so 
> > specifying an R version is irrelevant. In addition, saying your package has 
> > a dependency R >=... implies that there will be no breaking changes in some 
> > future R, which requires a certain amount of foresight. And using R itself 
> > would seem to be a requirement for an R package. So in principle my feeling 
> > is that it doesn't make sense to include R or an R version as a dependency.
> >
> > In a more practical setting it might be that your package depends on a 
> > specific feature of R, or that you yourself are only confident that a 
> > particular version of R will provide the needs of your package. It might 
> > then be appropriate to specify that R version. Again in the domain of the 
> > ideal, new R features would be introduced in R-devel, with bug fixes only 
> > in the point releases. So a dependency like R >= 3.5.0 would seem 
> > appropriate.
> >
> > I'm not sure whether these comments are helpful or not... __
> >
> > Martin
> >
> > On 11/2/18, 3:19 PM, "Bioc-devel on behalf of Paul Shannon" 
> >  > paul.thurmond.shan...@gmail.com> wrote:
> >
> >A user of MotifDb requests - sensibly, I think - that I loosen the 
> > requirement
> >
> >  Depends: R (>= 3.5.1)
> >
> >which I added before the release.   This seems sensible and supported 
> > by, for example, R (>= 2.10) in GenomicRanges.
> >
> >Is this, then, the heuristic?
> >
> >  - new packages should depend on the lastest release of R
> >
> >  - older existing packages should depend on earlier
> >versions of R, possibly sticking with the version of R in
> >which they originally appeared, as long as they have not
> >been subsequently modified to use new R features.
> >
> >- Paul
> >
> >
> >
> >
> >
> >
> >
> >___
> >Bioc-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] NEWS.md

[Henrik Bengtsson]

Forgot to mention that here's how news() select which file to parse if
there are several:

## Look for new-style inst/NEWS.Rd installed as NEWS.Rd
## If not found, look for NEWS.md.
## If not found, look at old-style
## NEWS inst/NEWS
## installed as NEWS (and ignore ChangeLog files).

Source: 
https://github.com/wch/r-source/blob/d20943d71407f9209cb6c7581ac0fce3b3517419/src/library/tools/R/news.R#L62-L66

/Henrik
On Tue, Sep 25, 2018 at 3:58 PM Henrik Bengtsson
 wrote:
>
> Note that in R-devel, we have that
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
>
> * news() gains support for ‘NEWS.md’ files.
>
> That is, news(package = pkg) not only finds NEWS.md (as before) but
> also parses it (into sections etc.) analogously to how it parses
> NEWS.Rd and NEWS.
>
> Because of this, I'd say a package should use only one of the NEWS,
> NEWS.Rd, and NEWS.md files.
>
> Also, I believe CRAN has parsed NEWS.md files for quite a while now
> and rendered them as HTML.  I think Bioconductor should do the same
> thing (sounds like this is what Lluís argued for), especially with the
> new NEWS.md support by news().
>
> /Henrik
> On Tue, Sep 25, 2018 at 2:08 PM Laurent Gatto  wrote:
> >
> >
> > Dear all,
> >
> > My experience (and things may have changed since I set this up) is that
> > NEWS and NEWS.md serve different purposes despite a very similar
> > syntax. The former is used by news() and displayed on the Bioconductor
> > page (would NEWS.md be used if NEWS was absent?), while the one with the
> > md extension displays nicely (including links) on github and in pkgdown
> > sites.
> >
> > My solution is a Makefile recipe [1] (contributed by Sebastian Gibb)
> > that converts NEWS.md into NEWS while updating the syntax and removing
> > markdown links (typically to github issues, that are automatically
> > expanded from #123 to a full URL via a github hook).
> >
> > NEWS: #' create plain text NEWS from NEWS.md if available
> > test -f ${PKGDIR}/NEWS.md && sed '/^# .*$$/d; /^## .*$$/{s/^## //g; 
> > p; s/./-/g}; /^###\+/{s/./\u&/g}; s/^##\+ //g; 1,2{/^[[:space:]]*$$/d}; 
> > s/\[\(#[0-9]\+\)\]([^)]\+)/\1/g' ${PKGDIR}/NEWS.md > ${PKGDIR}/NEWS
> >
> > (where ${PKGDIR} is the package directory)
> >
> > Unsure whether this helps or adds further to the confusion.
> >
> > Best wishes,
> >
> > Laurent
> >
> > [1] https://github.com/ComputationalProteomicsUnit/maker
> >
> >
> > On 25 September 2018 13:55, Shepherd, Lori wrote:
> >
> > > It can be used currently.  If you remove the .md extension but keep the 
> > > format in should be recognized.  As described in the ?news help page
> > >
> > >
> > >
> > >  If 'package' is '"R"' (default), a news db is built with the news
> > >  since the 3.0.0 release of R (corresponding to R's top-level
> > >  'NEWS' file).  Otherwise, if the given add-on package can be found
> > >  in the given libraries, it is attempted to read its news in
> > >  structured form from files 'inst/NEWS.Rd', 'NEWS' or 'inst/NEWS'
> > >  (in that order).
> > >
> > >
> > >
> > > Please also note your news file is formatted incorrectly.  from the ?news
> > >
> > >
> > >  The plain text 'NEWS' files in add-on packages use a variety of
> > >  different formats; the default news reader should be capable to
> > >  extract individual news entries from a majority of packages from
> > >  the standard repositories, which use (slight variations of) the
> > >  following format:
> > >
> > > • Entries are grouped according to version, with version header
> > >   "Changes in version" at the beginning of a line, followed by
> > >   a version number, optionally followed by an ISO 8601 format
> > >   date, possibly parenthesized.
> > >
> > > • Entries may be grouped according to category, with a category
> > >   header (different from a version header) starting at the
> > >   beginning of a line.
> > >
> > > • Entries are written as itemize-type lists, using one of 'o',
> > >   '*', '-' or '+' as item tag.  Entries must be indented, and
> > >   ideally use a common indentation for the item texts.
> > >
> > >
> > >
> > >
> > > Please remove the pound sign (# ) from the header entry -  and use 
> > > "Changes in version"

Re: [Bioc-devel] NEWS.md

[Henrik Bengtsson]

Note that in R-devel, we have that
(https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):

* news() gains support for ‘NEWS.md’ files.

That is, news(package = pkg) not only finds NEWS.md (as before) but
also parses it (into sections etc.) analogously to how it parses
NEWS.Rd and NEWS.

Because of this, I'd say a package should use only one of the NEWS,
NEWS.Rd, and NEWS.md files.

Also, I believe CRAN has parsed NEWS.md files for quite a while now
and rendered them as HTML.  I think Bioconductor should do the same
thing (sounds like this is what Lluís argued for), especially with the
new NEWS.md support by news().

/Henrik
On Tue, Sep 25, 2018 at 2:08 PM Laurent Gatto  wrote:
>
>
> Dear all,
>
> My experience (and things may have changed since I set this up) is that
> NEWS and NEWS.md serve different purposes despite a very similar
> syntax. The former is used by news() and displayed on the Bioconductor
> page (would NEWS.md be used if NEWS was absent?), while the one with the
> md extension displays nicely (including links) on github and in pkgdown
> sites.
>
> My solution is a Makefile recipe [1] (contributed by Sebastian Gibb)
> that converts NEWS.md into NEWS while updating the syntax and removing
> markdown links (typically to github issues, that are automatically
> expanded from #123 to a full URL via a github hook).
>
> NEWS: #' create plain text NEWS from NEWS.md if available
> test -f ${PKGDIR}/NEWS.md && sed '/^# .*$$/d; /^## .*$$/{s/^## //g; 
> p; s/./-/g}; /^###\+/{s/./\u&/g}; s/^##\+ //g; 1,2{/^[[:space:]]*$$/d}; 
> s/\[\(#[0-9]\+\)\]([^)]\+)/\1/g' ${PKGDIR}/NEWS.md > ${PKGDIR}/NEWS
>
> (where ${PKGDIR} is the package directory)
>
> Unsure whether this helps or adds further to the confusion.
>
> Best wishes,
>
> Laurent
>
> [1] https://github.com/ComputationalProteomicsUnit/maker
>
>
> On 25 September 2018 13:55, Shepherd, Lori wrote:
>
> > It can be used currently.  If you remove the .md extension but keep the 
> > format in should be recognized.  As described in the ?news help page
> >
> >
> >
> >  If 'package' is '"R"' (default), a news db is built with the news
> >  since the 3.0.0 release of R (corresponding to R's top-level
> >  'NEWS' file).  Otherwise, if the given add-on package can be found
> >  in the given libraries, it is attempted to read its news in
> >  structured form from files 'inst/NEWS.Rd', 'NEWS' or 'inst/NEWS'
> >  (in that order).
> >
> >
> >
> > Please also note your news file is formatted incorrectly.  from the ?news
> >
> >
> >  The plain text 'NEWS' files in add-on packages use a variety of
> >  different formats; the default news reader should be capable to
> >  extract individual news entries from a majority of packages from
> >  the standard repositories, which use (slight variations of) the
> >  following format:
> >
> > • Entries are grouped according to version, with version header
> >   "Changes in version" at the beginning of a line, followed by
> >   a version number, optionally followed by an ISO 8601 format
> >   date, possibly parenthesized.
> >
> > • Entries may be grouped according to category, with a category
> >   header (different from a version header) starting at the
> >   beginning of a line.
> >
> > • Entries are written as itemize-type lists, using one of 'o',
> >   '*', '-' or '+' as item tag.  Entries must be indented, and
> >   ideally use a common indentation for the item texts.
> >
> >
> >
> >
> > Please remove the pound sign (# ) from the header entry -  and use "Changes 
> > in version"  not "BioCor"
> >
> >
> > so for example:
> >
> >
> >
> > # BioCor 0.99.25
> >
> > * Update Vignette to just output html
> >
> > # BioCor 0.99.24
> >
> > * Submit the package to the Bioconductor project
> >
> > # BioCor 0.99.23
> >
> > * Add the Bioconductor webhook
> >
> >
> > Would become
> >
> >
> > Changes in version 0.99.25
> >
> > * Update Vignette to just output html
> >
> > Changes in version 0.99.24
> >
> > * Submit the package to the Bioconductor project
> >
> > Changes in version 0.99.23
> >
> > * Add the Bioconductor webhook
> >
> >
> >
> >
> > 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 Lluís 
> > Revilla 
> > Sent: Tuesday, September 25, 2018 3:20:39 AM
> > To: bioc-devel
> > Subject: [Bioc-devel] NEWS.md
> >
> > Dear Bioconductor team,
> >
> > I found that the new R version 3.5.1, to be used with the new release of
> > Bioconductor, supports the ‘NEWS.md' files.
> >
> > I updated my package (BioCor) to use `NEWS.md`. However, on the devel
> > landing page of the package stills shows the old file NEWS file. This is
> > consistent with the developer page (
> > 

Re: [Bioc-devel] BiocInstaller: next generation

[Henrik Bengtsson]

On Thu, May 10, 2018, 00:29 Martin Morgan 
wrote:

> Developers --
>
> A preliminary heads-up and request for comments.
>
> Almost since project inception, we've used the commands
>
>source("https://bioconductor.org/biocLite.R;)
>biocLite(pkgs)
>
> to install packages. This poses security risks (e.g., typos in the url)
> and deviates from standard R package installation procedures.
>
>
> We'd like to move to a different system where a base package, call it
> 'BiocManager', is installed from CRAN and used to install Bioconductor
> packages
>
>if (!"BiocManager" %in% rownames(installed.packages()))
>install.packages("BiocManager")
>BiocManager::install(pkgs)
>
> This establishes a secure chain from user R session to Bioconductor
> package installation. It is also more consistent with base R package
> installation procedures.
>
> BiocManager exposes four functions
>
>- install() or update packages
>
>- version() version of Bioconductor in use
>
>- valid() are all Bioconductor packages from the same Bioconductor
> version?
>
>- repositories() url location for Bioconductor version-specific
> repositories
>
> install() behaves like biocLite(), using the most current version of
> Bioconductor for the version of R in use. It stores this state using a
> Bioconductor package 'BiocVersion', which is nothing more than a
> sentinel for the version in use. One can also 'use devel' or a
> particular version of Bioconductor (consistent with the version of R) with
>
>BiocManager::install(version = "3.8")   # or the synonym "devel"
>
>
> We intend to phase this in over several release cycles, and to continue
> to support the traditional biocLite() route for versions before
> BiocManager becomes available.
>
> We also intend to change the overall versioning of 'Bioconductor'
> itself, where releases are always even (3.8, 3.10, 3.12, ...) and
> 'devel' always odd.
>
> Obviously this is a large change, eventually requiring updates to many
> locations on our web site and individual vignettes.
>
>
> Of course the key question is the name of the 'BiocManager' package. It
> cannot easily be 'BiocInstaller', because of the differences in way CRAN
> and Bioconductor version packages. Some possible names are
> '
> BiocInstall::install()
> BiocPackages::install()
> BiocManager
> BiocMaestro


May I suggest the package name:

* Bioconductor

The potential downside would be possible confusions between the version of
this package versus the actual Bioconductor repository.  Could the
Bioconductor *package* have a version  x.y.z that reflects the *repository*
x.y version?

/Henrik



>
> Your comments are welcome...
>
> Martin
>
>
> 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

Re: [Bioc-devel] BiocFileCache for developers

[Henrik Bengtsson]

R.cache (>= 0.6.0) does the following to acquire a persistent cache
(root) folder.  This behavior was introduced after getting prompted by
CRAN not to write to disk by default (because they found "funny"
folders on their check servers) and a following email conversation
with CRAN (2011-12-29), and getting an "ok with me" from Uwe@CRAN:

1. When loaded (not only attached) it checks for the existence of a
cache folder (defaults to ~/.Rcache unless neither an R option nor an
env var is set).  If it is exists, then we're good to go.

2. If the cache folder does not exist, and in a non-interactive
session, then a temporary cache folder specific to that R session is
used.

3. If the cache folder does not exist, and in an interactive session,
then the user will be queried whether they'd like to create ~/.Rcache
(the default choice) or whether they like to use a temporary folder
(just as in the non-interactive case).  If accepting ~/.Rcache, then
that will be available across sessions (Step 1 above).

The gist is: Make sure to get the user's approval before storing
anything permanently and don't doing anything that surprises the user,
risk overwriting their files, etc.

Here is a real-world user example on a "fresh" user account:

# Non-interactive sessions or user does not approve

$ Rscript -e "R.cache::getCacheRootPath()"
[1] "/tmp/RtmpzIZT4o/.Rcache"

$ R --vanilla
> dummy <- loadNamespace("R.cache")
The R.cache package needs to create a directory that will hold cache
files. It is convenient to use one in the user's home directory,
because it remains also after restarting R. Do you wish to create the
'~/.Rcache/' directory? If not, a temporary directory
(/tmp/RtmpMA4LTF/.Rcache) that is specific to this R session will be
used. [Y/n]: n
> R.cache::getCacheRootPath()
[1] "/tmp/Rtmp0Ic5zQ/.Rcache"
> quit("no")

$ R --vanilla
> R.cache::getCacheRootPath()
The R.cache package needs to create a directory that will hold cache
files. It is convenient to use one in the user's home directory,
because it remains also after restarting R. Do you wish to create the
'~/.Rcache/' directory? If not, a temporary directory
(/tmp/RtmpzSJd3d/.Rcache) that is specific to this R session will be
used. [Y/n]: n
[1] "/tmp/RtmpzSJd3d/.Rcache"
> quit("no")

$ Rscript -e "R.cache::getCacheRootPath()"
[1] "/tmp/Rtmpq1nx0H/.Rcache"


# User approves or already approved

$ R --vanilla
> dummy <- loadNamespace("R.cache")
The R.cache package needs to create a directory that will hold cache
files. It is convenient to use one in the user's home directory,
because it remains also after restarting R. Do you wish to create the
'~/.Rcache/' directory? If not, a temporary directory
(/tmp/RtmpMA4LTF/.Rcache) that is specific to this R session will be
used. [Y/n]: Y
> R.cache::getCacheRootPath()
[1] "~/.Rcache/"
> quit("no")

$ Rscript -e "R.cache::getCacheRootPath()"
[1] "~/.Rcache/"

$ R --vanilla
> dummy <- loadNamespace("R.cache")
> R.cache::getCacheRootPath()
[1] "~/.Rcache/"

The same applies when using library("R.cache") as well as when the
R.cache namespace is imported by another package.

This behavior also plays well with 'R CMD check' and 'R CMD check
--as-cran' where the cache folder will default to a temporary folder.
It will also prevent run-time errors since there will always be a
cache folder available (although it'll only survive the current
session).  R.cache works the same on all OSes.  To further lower the
risk for "what is this ~/.Rcache folder doing here?", R.cache also
adds a ~/.Rcache/README.txt file explaining what that folder is and
what created it.

About what the default location should be:

On Fri, Dec 1, 2017 at 8:06 AM, Sean Davis  wrote:
[...]
> On some systems, the user home directory is not large (such as on HPC
> systems) or has strong quotas. The default user_cache_dir may not be the
> best choice there.

I agree with this but it's hard to find a solid simple alternative to
the user's home folder.  However, and on my todo list to investigate,
https://cran.r-project.org/package=rappdirs may provide a better
approach because it follows OS-specific recommendations.  Back to
writing to user's home folder: in HPC environments with limited home
quota, I simply do things like ln -s /scratch/$USER/.Rcache ~/.Rcache.

/Henrik

On Fri, Dec 1, 2017 at 8:32 AM, Michael Love
 wrote:
> One solution if a developer really wants to make sure the user knows
> that the function will store a cache somewhere would be to leave the
> BiocFileCache location argument without a default value.
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Query bioconductor.org for what the current release version is?

[Henrik Bengtsson]

Awesome - got even more than I wished for. Thxs /Henrik

On Thu, Nov 16, 2017 at 5:52 PM, Turaga, Nitesh
<nitesh.tur...@roswellpark.org> wrote:
> Hi Henrik,
>
> Try https://www.bioconductor.org/config.yaml
>
> You should have the essential information in there—
>
>  release_version: "3.6"
>
> Hope this is what you are looking for.
>
> Nitesh
>
>> On Nov 16, 2017, at 8:09 PM, Henrik Bengtsson <henrik.bengts...@gmail.com> 
>> wrote:
>>
>> Hi.  Is there a way, without using R, to query bioconductor.org (or
>> any other reliable/maintained resources) for what the current release
>> version of Bioconductor is?  Something like:
>>
>> $ curl https://bioconductor.org/api/version
>> 3.6
>>
>> or possibly something fancy like:
>>
>> $ curl https://bioconductor.org/api/version.json
>> {"version":["3.6"],"date":["2017-10-31"],"depends":["R (>= 3.4.2)"]}
>>
>> Thanks.
>>
>> Henrik
>>
>> ___
>> 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

[Bioc-devel] Query bioconductor.org for what the current release version is?

[Henrik Bengtsson]

Hi.  Is there a way, without using R, to query bioconductor.org (or
any other reliable/maintained resources) for what the current release
version of Bioconductor is?  Something like:

$ curl https://bioconductor.org/api/version
3.6

or possibly something fancy like:

$ curl https://bioconductor.org/api/version.json
{"version":["3.6"],"date":["2017-10-31"],"depends":["R (>= 3.4.2)"]}

Thanks.

Henrik

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

[Bioc-devel] Bioconductor Git: Online interface

[Henrik Bengtsson]

Are there any plans for an online interface to https://git.bioconductor.org/?

I've recently looked into solutions for an open-source in-house
"GitHub/GitLab"-ish, and I've found https://gitea.io/ to be really
nice.  It is very easy to install. It has support for various common
user authentication methods, it supports organizations and user teams,
repositories may have issues and wikis, sets of code lines can be
referenced, commits and code diffs are annotated, and so on.  Wikis
and issue trackers can be disabled (also for individual repositories).
That's all I've learned thus far - I'm impressed.

Just a thought

Henrik

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

Re: [Bioc-devel] EXTERNAL: R version dependence of a new package

[Henrik Bengtsson]

I lean to agree with Yaoyong, because I find it helpful to specify (or read):

Depends: R (>= 3.0.0)

which sends a message that "the code is relying on features in R that
was not available prior to R 3.0.0".  Also, if that's the only
dependency you have, then if it passed R CMD check on R 3.0.0 in the
past, it will keep doing so in the future.  On the other hand, if the
package depends on other packages, which it's likely to do, then that
"R (>= 3.0.0)" sends a message about what the lower bound is - it does
not necessarily guarantee that it will work with R 3.0.0.  I think
that is a valid specification (for R and packages) because otherwise,
what is the "(>= x.y.z)" specification meant to be used for otherwise?

The alternative is to, as Stephanie proposes, to not specify "R (>=
x.y.z)" or just "R", which is an unfortunate workaround.

Somewhat related to this, couldn't there be a place-holder R package
called 'Bioconductor' whose version corresponds to the Bioconductor
release/devel version?  Then a package could specify "Imports:
Bioconductor (>= 3.6)" to clarify/specify that the package "depends
on/is for" a particular version of the Bioconductor.  The Bioconductor
3.6 package could in turn specify "R (>= 3.4.0)".  BTW, unfortunately,
R does not support specify a lower and an upper range, e.g. neither "R
(>= 3.4.0 & < 3.5.0)" nor "R (>= 3.4.0), R (< 3.5.0)" is accepted
which also means it's not possible to depend on "Bioconductor (==
3.6.*)".

Henrik


On Tue, Oct 24, 2017 at 10:27 AM, Stephanie M. Gogarten  wrote:
> Dear Yaoyong,
>
> Can you remove the R version dependency from your DESCRIPTION file entirely?
> That will eliminate the warning, but will also not suggest to users that
> they need a newer version of R than is necessary. R 2.3.0 was released in
> 2006, so it seems highly unlikely that anyone would be currently trying to
> use an R version older than that.
>
> Lori's answer seems to be more about the R version you should be using to
> test your package, which should indeed be current, but that is different
> than the minimum R version required to run the package at all. I know
> Bioconductor encourages users to stay up-to-date with R versions and does
> not guarantee that older versions will work with all packages, but I think
> there is still some utility in letting users know which packages depend on
> recent versions of R, and which packages can be expected to work with older
> versions.
>
> Stephanie
>
>
> On 10/23/17 4:36 AM, Yaoyong Li wrote:
>>
>> Dear Lori,
>>
>> many thanks for your detailed explanations. I think that it makes sense
>> from Bioconductor maintenance's point of view to require that the R
>> version
>> of a package should be the same of the R version in a Bioconductor release
>> which includes the package, because it's the safest option. On the other
>> hand, I still think that this requirement put some unnecessary limit on
>> the
>> scope of the R version which a package can be used with. For example, as
>> the package creator I know that my package can work with R from 2.3.0 and
>> upward, including the version 3.4 that the current Bioconductor used, then
>> why should I have to restrict the R version to 3.4 and upward. I guess
>> that
>> it's the package creator's responsibility to determine which R version(s)
>> their packages depend on? It seems to me that there is a R version problem
>> between the package and the Biocondonctor only when the R versions that a
>> package specifies does not include the R version of a Bioconductor release
>> which the package is supposed to be included in.
>>
>> I think that it probably makes no much difference in practice between what
>> I think it should be and the current practice in Bioconductor, as one can
>> easily upgrade the R to the latest version with no cost. But I hope you
>> can
>> see the difference in theory.
>>
>> Best regards,
>>
>> Yaoyong
>>
>> On Fri, Oct 20, 2017 at 1:02 PM, Shepherd, Lori <
>> lori.sheph...@roswellpark.org> wrote:
>>
>>> We strongly recommend the version of R that is used on our builders when
>>> building and checking your package.  This is also to ensure that the
>>> package dependencies are also in a version that is compatible with a new
>>> package.  We can't guarantee that a package will work with a previous
>>> version of a dependency so the best practice is to use the current
>>> version
>>> of R as we check against the most recent and current versions of packages
>>> for the version of R and Bioconductor.  This is also why we have
>>> biocValid
>>> and biocLite to make sure packages are up-to-date and valid for a
>>> particular version of R and Bioconductor.  Package can change over time
>>> and
>>> cause compatibility issues that are unforseen; R also can change from
>>> version to version and cause unforseen problems.
>>>
>>>
>>> Lori Shepherd
>>>
>>> Bioconductor Core Team
>>>
>>> Roswell Park Cancer Institute
>>>
>>> Department of Biostatistics & Bioinformatics

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

[Henrik Bengtsson]

I haven't tried (= had to do it) myself, so I don't know exactly what
it takes, but you can configure this "ulimit" of number of open files,
e.g. instructions in https://stackoverflow.com/a/34645/1072091.  I
suspect it requires admin rights, but I'm not sure - maybe this is
what goes on when you run it in different types terminals.

About this open file/DLL limit: in src/main/Rdynload.c
(https://github.com/wch/r-source/blob/tags/R-3-4-2/src/main/Rdynload.c#L173-L180)
there's the following comment/clarification:

/* Note that it is likely that dlopen will use up at least one file
descriptor for each DLL loaded (it may load further dynamically
linked libraries), so we do not want to get close to the fd limit
(which may be as low as 256). By default, the maximum number of DLLs
that can be loaded is 100. When the fd limit is known, we allow
increasing the maximum number of DLLs via environment variable up to
60% of the limit on open files, but to no more than 1000. g
*/

I always thought that "as low as 256" was for some archaic system,
but, as Wolfgang points out, it's a relevant limit.  Since 0.6*256 =
153, this explains that the choice of the current default of a maximum
100 DLLs is reasonable and requests to bump it up much higher may not
be feasible (not cross-platform).


Related to this - "Garbage collection of DLLs":

I've implemented R.utils::gcDLLs() that "Identifies and removes
["stray"] DLLs of packages already unloaded".  This function will free
up DLL slots otherwise occupied by unloaded packages.  I've used is
successfully in many places, e.g. trying to load and unload all my
installed packages in a single R session (don't ask why ;)).

However, as argued by Karl Millar
(https://stat.ethz.ch/pipermail/r-devel/2016-December/073528.html),
there is a risk that unregistering such DLLs may render the state of R
unstable because we cannot know for sure whether there are some
registered finalizers that rely on such DLLs that yet haven't been
called.  R.utils::gcDLLs() forces the garbage collector to run prior
to unregistering DLLs, which should eliminate the risk for this
problem.  As far as I understand the current R implementation, this
should be enough.  On the other hand, I've been wrong before, I don't
know about future version of R, and it has only been tested so much.
Guaranteeing reentrancy of finalizers is really tricky.

/Henrik

On Fri, Oct 6, 2017 at 10:16 AM, Wolfgang Huber <wolfgang.hu...@embl.de> wrote:
> Interesting! In iTerm2, I get
> $ ulimit -Sn
> 4864
>
> and
> env R_MAX_NUM_DLLS=1000 R
>
> works, which means that on Mac it IS possible to have many more DLLs open
> than 100 if R is started in the right way.
>
> Wolfgang
>
> PS I meant OS X 10.12.6, too. SOrry for the typo.
>
>
> 6.10.17 14:50, Kasper Daniel Hansen scripsit:
>>
>> On OS X 10.12.6 (I don't think 10.12.16 exists), I get
>>
>> $ ulimit -Sn
>> 7168
>>
>> Interestingly, this is because I use iTerm2 for my command line prompt.
>> If I do the same command in Terminal I get 256.  If I start R inside of
>> Emacs I get 256 as well.  I don't know anything about ulimit and how it is
>> set, but that is a pretty start difference.
>>
>> Best,
>> Kasper
>>
>>
>>
>> On Fri, Oct 6, 2017 at 3:12 AM, Wolfgang Huber <wolfgang.hu...@embl.de
>> <mailto:wolfgang.hu...@embl.de>> wrote:
>>
>> On Mac OSX 10.12.16:
>> $ ulimit -Sn
>> 256
>>
>> so the maximum value of R_MAX_NUM_DLLS is 153 ...
>>
>>  Wolfgang
>>
>> 5.10.17 23:02, Henrik Bengtsson scripsit:
>>
>> About the DLL limit:
>>
>> Just wanna make sure you're aware of "new" environment variable
>> R_MAX_NUM_DLLS available in R (>= 3.4.0).  It allows you to push
>> the
>> current default limit of 100 open DLLs a bit higher.  It can be
>> set in
>> .Renviron or before, e.g.
>>
>> $ R_MAX_NUM_DLLS=500 R
>>
>> This, of course, assumes that you can set it, which you might not
>> be
>> able to do on build servers.  Also, there is an upper limit
>> min(0.6*fd_limit,1000) that depends on the number of files you can
>> have open at the same time (fd_limit), e.g. on my Ubuntu 16.04
>> I've
>> got:
>>
>> $ ulimit -Sn
>> 1024
>>
>> so R_MAX_NUM_DLLS=614 is the maximum for me.
>>
>> /Henrik
>>
>> On Thu, Oct 5, 2017 at 11:22 AM, Wolfgang Huber
>> <wolfgang.hu...@embl.de <mailto:wolfgang.hu...@embl.de>> wrote:
>>
>>
>> Brea

Re: [Bioc-devel] Old package versions / Bioc archive of package's *.tar.gz releases?

[Henrik Bengtsson]

That's really nice; I didn't know it could do all that.  For my
clarification, when using PkgManifest(..., type = "bioc") it'll search
(i) the CRAN archives, (ii) the Bioconductor repos(es), and then (iii)
the Bioconductor Git repos - is that a correct observation? (I
installed from https://github.com/gmbecker/switchr)

/Henrik




On Thu, Oct 5, 2017 at 4:15 PM, Gabe Becker <becker.g...@gene.com> wrote:
> In point of fact, it looks like IRanges 2.6.0 is an instance of that
> weakness, so was probably a bad example. 2.6.1 installs correctly, or would
> in it's native R/base bioc environment... (it fails for me in the library I
> have...)
>
> Also, the version on CRAN uses the bioc SVN, so may not work for recent
> versions.
>
> On Thu, Oct 5, 2017 at 3:58 PM, Gabe Becker <becke...@gene.com> wrote:
>>
>> Henrik et al.,
>>
>> My switchr package (on CRAN, github at:
>> http://github.com/gmbecker/switchr,  preprint of the paper here:
>> https://arxiv.org/abs/1501.02284) can do this.
>>
>> In fact, installing (cohorts of) old versions of packages is one of it's
>> primary purposes. Specifically, it can install old source versions of
>> packages from CRAN, Bioconductor, and general Git and SVN repos you tell it
>> about.
>>
>> With the caveat that it's a bad idea in the general case to specify an old
>> version of one package without specifying versions of its dependencies
>> (switchr allows you to do this via a manifest, which can be constructed from
>> sessionInfo output or guessed in the case of a CRAN package), you can just
>> do
>>
>> > man = PkgManifest(name="IRanges", type="bioc")
>>
>> > install_packages("IRanges", man, versions = c(IRanges = "2.6.0"))
>>
>>
>> And you will successfully completely break your Bioc installation by
>> installing IRanges 2.6.0 into it. ;-)
>>
>> Switchr also gives you tools to more easilly maintain multiple libraries
>> which contain, for example, different bioc versions in them.
>>
>> NB: switchr is subject to the caveat Martin pointed out and will fail to
>> retrieve a buildable version of the package if said buildable version is not
>> the first commit in SCM bearing that version in its DESCRIPTION file.
>>
>> Hope that helps.
>>
>> Best,
>> ~G
>>
>> On Thu, Oct 5, 2017 at 2:21 PM, Martin Morgan
>> <martin.mor...@roswellpark.org> wrote:
>>>
>>> On 10/05/2017 05:14 PM, Henrik Bengtsson wrote:
>>>>
>>>> On Thu, Oct 5, 2017 at 1:46 PM, Martin Morgan
>>>> <martin.mor...@roswellpark.org> wrote:
>>>>>
>>>>> On 10/05/2017 01:50 PM, Henrik Bengtsson wrote:
>>>>>>
>>>>>>
>>>>>> Is there an easily accessible archive for Bioconductor packages
>>>>>> similar to what is provided on CRAN where you can find all released
>>>>>> versions of a package, e.g.
>>>>>> https://cran.r-project.org/src/contrib/Archive/PSCBS/?
>>>>>>
>>>>>> Say I want to access the source code for affy 1.18.0.  Here are the
>>>>>> two approaches I'm aware of and none of them are particularly
>>>>>> appealing to me.  Does anyone know of a better approach?
>>>>>
>>>>>
>>>>>
>>>>> The only option is to scrape, and that's approximate. One could build
>>>>> an
>>>>> archive
>>>>>
>>>>> pkg,version,branch,from_svn_rev,to_svn_rev
>>>>>
>>>>> and then consult that. Packages are supposed to increment the 'z' of
>>>>> x.y.z,
>>>>> but I'm sure there are many exceptions. I believe Jim Hester has an svn
>>>>> script for this, but I wasn't able to locate it; it would be fast in
>>>>> git.
>>>>
>>>>
>>>> Thanks.  About 'z' not being increased.  Does the Bioc build servers
>>>> release (a) continuously or (b) only when it detects a version change
>>>> x.y.z -> x.y.z+1?  If it does it continuously, then what x.y.z is
>>>> installed does matter on when it was downloaded/installed, correct?
>>>> On the other hand, if it only builds in when a version bump is
>>>> detected, then one can at least narrow it down to a much narrow set of
>>>> x.y.z submits (if multiple exists).
>>>
>>>
>>> The builder only pushes for upward increments, so a commit without a
>>>

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

[Henrik Bengtsson]

About the DLL limit:

Just wanna make sure you're aware of "new" environment variable
R_MAX_NUM_DLLS available in R (>= 3.4.0).  It allows you to push the
current default limit of 100 open DLLs a bit higher.  It can be set in
.Renviron or before, e.g.

$ R_MAX_NUM_DLLS=500 R

This, of course, assumes that you can set it, which you might not be
able to do on build servers.  Also, there is an upper limit
min(0.6*fd_limit,1000) that depends on the number of files you can
have open at the same time (fd_limit), e.g. on my Ubuntu 16.04 I've
got:

$ ulimit -Sn
1024

so R_MAX_NUM_DLLS=614 is the maximum for me.

/Henrik

On Thu, Oct 5, 2017 at 11:22 AM, Wolfgang Huber  wrote:
>
> Breaking up long workflows into several smaller "modules" each with a
> clearly defined input and output is a good idea, certainly for didactic &
> maintenance reasons.
>
> It doesn't "solve" the DLL issue though, it only avoids it (for now)...
>
> I believe you can use a Makefile for your vignettes
> (https://cran.r-project.org/doc/manuals/R-exts.html#Writing-package-vignettes),
> and this might be a good way of managing which depends on which. For passing
> along output/input, perhaps local .RData files are good enough, perhaps some
> wheel-reinventing can also be avoided by using
> https://bioconductor.org/packages/release/bioc/html/BiocFileCache.html
> (haven't actually used it yet, though).
>
> Wolfgang
>
>
>
> 5.10.17 20:02, Aaron Lun scripsit:
>>
>> This may relate to what I was thinking with respect to solving the DLL
>> problem, by breaking up large workflows into modules that can be executed in
>> separate R sessions. The same approach would also make it easier to
>> associate package dependencies with specific parts of the workflow.
>>
>>
>> In my particular situation, it is easy to break up the workflow into
>> sections that can be executed completely independently. However, I can also
>> imagine situations where dependencies on previous objects, etc. make it
>> difficult to break up the workflow. If multiple files are present in
>> vignettes/, can they be directed to execute in a specific order, and would
>> output files from one vignette persist during the execution of another?
>>
>>
>> -Aaron
>>
>> 
>> *From:* Wolfgang Huber 
>> *Sent:* Thursday, 5 October 2017 6:23:47 PM
>> *To:* Laurent Gatto; Aaron Lun
>> *Cc:* bioc-devel@r-project.org
>> *Subject:* Re: [Bioc-devel] library() calls removed in simpleSingleCell
>> workflow
>>
>>
>> I agree it is nice to be able to only load the packages needed for a
>> certain section of a vignette and not the whole thing. And that too many
>> `::` can make code look unwieldy (though some may actually increase
>> readability).
>>
>> But relying on manually sprinkled in `library` calls seems like a hack
>> prone to error. And there are always bound to be dependencies that are
>> non-local, e.g. on general infrastructure like SummarizedExperiment,
>> ggplot2, dplyr.
>>
>> So: do we need a way to computationally determine the dependencies of a
>> vignette section, including highlighting/eliminating potential name
>> clashes (b/c the warnings about masking emitted at package loading are
>> easily ignored)? This seems like a straightforward engineering task.
>>
>> Eventually with such code analysis we could get rid of explicit
>> `library` calls altogether :)
>>
>>  Wolfgang
>>
>>
>>
>>
>>
>> 5.10.17 08:53, Laurent Gatto scripsit:
>>>
>>>
>>> On  5 October 2017 00:11, Aaron Lun wrote:
>>>
 Here's another two cents from me:

 The explicit library() calls allow for easy copy-pasting if people
 only want to use/adapt a section of the workflow. In such cases,
 calling "library(simpleSingleCell)" could drag in a lot of unnecessary
 packages (e.g., which could hit the DLL limit). Reading through the
 text to figure out the requirements for each code chunk seems like a
 pain, and lots of "::" are unwieldy.

 More generally, the removal of individual library() calls seems to
 encourage the use of a single "library(simpleSingleCell)" call at the
 top of any user-developed custom analysis scripts based on the
 workflow. This seems conceptually odd to me - the simpleSingleCell
 package is simply a vehicle for the compiled workflow, it shouldn't be
 involved in analyses of other data.
>>>
>>>
>>> I can confirm that this is a possibility.
>>>
>>> Before workflows became available, I created the RforProteomics package
>>> that essentially provided one relatively large vignette to demonstrate a
>>> variety of applications of R/Bioconductor for mass spectrometry and
>>> proteomics. I think this has been a useful way to disseminate R and
>>> Bioconductor in these respective communities, but also lead to the
>>> confusion that it was that package that "did all the stuff", i.e. people
>>> saying that they were using 

[Bioc-devel] Old package versions / Bioc archive of package's *.tar.gz releases?

[Henrik Bengtsson]

Is there an easily accessible archive for Bioconductor packages
similar to what is provided on CRAN where you can find all released
versions of a package, e.g.
https://cran.r-project.org/src/contrib/Archive/PSCBS/?

Say I want to access the source code for affy 1.18.0.  Here are the
two approaches I'm aware of and none of them are particularly
appealing to me.  Does anyone know of a better approach?


# APPROACH 1: Download from http://bioconductor.org

The best approach I know now is to try to guess the date when this was
released in order to identify the Bioconductor release version.
Something like this:

1. Guess around 2010.

2. Go to http://bioconductor.org/about/release-announcements/ and see
what R versions were in use during 2010.  I find R 2.6.x and R 2.7.x.
The Bioc version for those R versions (same URL) are Bioc 2.1 and Bioc
2.2.  Let's focus on Bioc 2.2 (because I happen to know that is the
one)

3. Following the Bioc 2.2 link on above URL to get to
http://bioconductor.org/packages/2.2/BiocViews.html.

4. Click through, one eventually gets to
http://bioconductor.org/packages/2.2/bioc/html/affy.html

5. The "Source" link points to
http://bioconductor.org/packages/2.2/bioc/src/contrib/affy_1.18.2.tar.gz

Say I wanted affy 1.16.0 instead and I made the wrong guess in Step 2,
I can extrapolate from (Bioc 2.2, affy 1.18.x) finding that I should
go to Bioc 2.1 to find affy 1.16.x (because releases have even minor
version numbers).   It works, but is a bit tedious if you need to do
this more than once.

Also, I'm pretty sure I read somewhere that Bioc on archive the most
recent package version under each release, which means there is no
affy_1.18.0.tar.gz available for download.  Is that correct?


# APPROACH 2: Version control

$ git clone https://git.bioconductor.org/packages/affy
$ cd affy

# Package releases/versions are not tagged
$ git tag
[empty]

# Check Bioc release branches
$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/RELEASE_1_0
  remotes/origin/RELEASE_1_0_branch
  remotes/origin/RELEASE_1_4
  remotes/origin/RELEASE_1_4_branch
  remotes/origin/RELEASE_1_5
[...]
  remotes/origin/RELEASE_3_5
  remotes/origin/master

That's back to above game of trying to narrow down which Bioc release
I should look at.  A similar approach is to look at the commit log:

$ git log DESCRIPTION

commit 35573048255b398f99ff1d3560906b2121912248
Author: Herve Pages 
Date:   Mon Apr 24 19:50:57 2017 +

bump x.y.z versions to odd y after creation of 3_5 branch

git-svn-id:
file:///home/git/hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/affy@129129
bc3139a8-67e5-0310-9ffc-ced21a209358

commit aa4c2d648658e8c2cca2baf651aea92df55a4392
Author: Herve Pages 
Date:   Mon Apr 24 19:25:24 2017 +

bump x.y.z versions to even y prior to creation of 3_5 branch

git-svn-id:
file:///home/git/hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/affy@129126
bc3139a8-67e5-0310-9ffc-ced21a209358

[...]

and try to locate affy 1.18.0 by peeking at the DESCRIPTION file history.

Does anyone know of a better/more automated approach?

Thanks,

Henrik

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

Re: [Bioc-devel] NEWS, inst/NEWS, NEWS.md

[Henrik Bengtsson]

Note that NEWS.md (Markdown) is only partially supported, e.g. news()
does _not_ pick it up, cf.
https://github.com/HenrikBengtsson/Wishlist-for-R/issues/40

/Henrik

On Sat, Sep 9, 2017 at 4:43 PM, Martin Morgan
 wrote:
> On 09/09/2017 06:11 PM, Levi Waldron wrote:
>>
>> What's the currently recommended location for package NEWS?  At
>> https://www.bioconductor.org/developers/package-submission/ it says
>> inst/NEWS, and I feel like I heard somewhere that NEWS.md was supported.
>> But in a scan of the first page of https://github.com/bioconductor, all
>> use
>> NEWS in the base package directory, and that is the only option I was able
>> to make show up on
>>
>> https://bioconductor.org/packages/devel/data/experiment/news/curatedMetagenomicData/NEWS
>> when I played with it a couple months ago. Just want to get it straight.
>
>
> Writing R extensions points to ?news, which says
>
>  in the given libraries, it is attempted to read its news in
>  structured form from files 'inst/NEWS.Rd', 'NEWS' or 'inst/NEWS'
>  (in that order).
>
> All three are supported on the web site (I verified this with annotate
> [inst/NEWS.Rd], zinbwave [inst/NEWS], and KEGGREST [NEWS]) and all are
> installed at the root of system.file(package=.).
>
> Martin
>
>>
>> -Levi
>>
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Git Transition Plan

[Henrik Bengtsson]

Thanks.  I have a few thoughts and questions in order to plan ahead:

> - Our plan is to make a 'clean' transition from SVN to git, approximately one 
> month after the next Bioconductor release. Developers or users will not have 
> access to the SVN system after the date of transition.

In order to preserve commit authorship, what's your plan for mapping
SVN username to Git 'user.email' and 'user.name'?  The 'user.email' is
what GitHub uses to associate commits and contributions to GitHub
accounts.

BTW, using obsolete email addresses may prevent people from being
associated with those email addresses on GitHub and other online
services that require authentication of authorship claims (which go
out via those email addresses).

When I SVN-to-Git exported my Bioconductor packages a few years ago, I
could handle manually because there were not too many contributors in
the SVN logs and I reached out to each of them and asked what email
addresses they would prefer to have in the Git commits.  That approach
is obviously not feasible to automate for all Bioconductor packages.
Maybe this can be handled optionally by each package maintainers by
adding a .gitauthors file to the package root (or possibly via a
global Bioc one that everyone can commit to), e.g.
```r
hb = Henrik Bengtsson <henr...@braju.com>
j...@foo.com = John Doe <j...@someone.org>
```
and then Bioc can use this mapping when exporting to Git?

Finally, will people like me who already done the SVN-to-Git migration
be able to use that instead of the Bioc generated one? (I assume not,
but worth asking)

Thanks,

Henrik

On Wed, Mar 29, 2017 at 9:51 AM, Turaga, Nitesh
<nitesh.tur...@roswellpark.org> wrote:
> Dear Bioconductor Developers,
>
> More news about the Git transition plan. We are coming close to our 
> transition date and have made significant progress in getting our new server 
> ready for the Bioconductor community.
>
> 1. Overall plan:
>
> - Bioconductor hosts each package as a distinct repository at 
> git.bioconductor.org<http://git.bioconductor.org/>. From Bioconductor's 
> perspective, this is the canonical location. Nightly builds will be based on 
> these repositories, release branches will be created in these repositories, 
> etc. The naming convention for branches remains the same.
>
> - Developers clone or otherwise sync their code base to these repositories. 
> Each developer will be able to push to and pull from (e.g., during branching 
> and version bumps at package release) their 
> git.bioconductor.org<http://git.bioconductor.org/> repository. Version bumps 
> and new branches(during Bioconductor release) will be handled by the core 
> team.
>
> - Developers are encouraged to host and develop their source code on Github 
> or other git-based social platforms. This promotes community involvement, and 
> empowers developers to adopt best practices related to issue tracking, 
> continuous integration, bug fixes, pull requests from their community, etc.
>
> - All bioconductor infrastructure code will also be available on Github, 
> through our organization page(https://github.com/Bioconductor). Community 
> members are encouraged to send us pull requests for all our public 
> repositories.
>
> 2. Timing:
>
> - Our plan is to make a 'clean' transition from SVN to git, approximately one 
> month after the next Bioconductor release. Developers or users will not have 
> access to the SVN system after the date of transition.
>
> 3. Repositories:
>
> - The git repositories will be derived from a 'snapshot' of the latest SVN 
> repository at the time of the transition. After the date of transition, 
> further commits to SVN will not be reflected in the new git repositories.
>
> - Each repository will capture the full SVN commit history of the package. 
> Releases will be included as branches in the repository.
>
> - We anticipate that software and experiment data packages will be hosted at 
> git.bioconductor.org<http://git.bioconductor.org/>. Experiment data packages 
> will use git-lfs to manage large data.
>
> - The Github Bioconductor-mirror repository will be removed.
>
> 4. Test phases:
>
> - We anticipate two test periods.
>
> - A private 'alpha' test phase is starting shortly. Alpha testers will 
> initially have pull access to their repository, and will follow tentative 
> work flows for gaining push access, for maintaining clones of their packages, 
> for committing to the git.bioconductor.org<http://git.bioconductor.org/> 
> repositories, and for pulling from (e.g., version bumps and release branches) 
> the repositories.
>
> - A public 'beta' test phase will start after the next Bioconductor release, 
> and last for approximately four weeks. Beta testers will have pull access

Re: [Bioc-devel] Bioconductor and R 3.3.3: Error in c(x, values) : could not find symbol "recursive" in environment of the generic function

[Henrik Bengtsson]

Thanks Hervé.  I can confirm that reinstalling packages from R 3.3.2
to R 3.3.3 solved the problem:

https://github.com/HenrikBengtsson/globals/commit/f9ff3a092d1712258aab2d01277665abec7dfa32

/Henrik

On Thu, Mar 9, 2017 at 5:52 PM, Hervé Pagès <hpa...@fredhutch.org> wrote:
> Hi Henrik,
>
> See here for similar problems reported earlier on our support site:
>
>   https://support.bioconductor.org/p/93347/#93373
>   https://support.bioconductor.org/p/93590/#93595
>
> I think you need to reinstall your packages after updating to R 3.3.
>
> API compatibility across minor R releases is a myth :-/
>
> H.
>
>
> On 03/09/2017 05:38 PM, Henrik Bengtsson wrote:
>>
>> Hi. FYI / Is anyone else experiencing:
>>
>> Error in c(x, values) :
>>   could not find symbol "recursive" in environment of the generic function
>>
>> errors for some Bioconductor packages when running under R 3.3.3 while
>> they don't occur with R 3.3.2?  This seems realted to the following R
>> 3.3.3 NEWS entry:
>>
>> c()'s argument use.names is documented now, as belonging to the (C
>> internal) default method. In “parallel”, argument recursive is also
>> moved from the generic to the default method, such that the formal
>> argument list of base generic c() is just (...).
>>
>> One quick example is:
>>
>> $ R --vanilla
>>>
>>> example("callLOH", package = "PureCN")
>>
>> [...]
>>>
>>> head(callLOH(purecn.example.output))
>>
>> Error in c(x, values) :
>>   could not find symbol "recursive" in environment of the generic function
>>
>>> traceback()
>>
>> 24: c(x, values)
>> 23: append(mcols(gr), slot(x, "fixed"))
>> 22: append(mcols(gr), slot(x, "fixed"))
>> 21: .local(x, ...)
>> 20: rowRanges(x)
>> 19: rowRanges(x)
>> 18: (function (x, ...)
>> standardGeneric("start"))(x = rowRanges(x), ... = ...)
>> 17: do.call(start, list(x = rowRanges(x), ... = ...))
>> 16: do.call(start, list(x = rowRanges(x), ... = ...))
>> 15: start(res$input$vcf)
>> 14: start(res$input$vcf)
>> 13: split(start(res$input$vcf), as.character(seqnames(res$input$vcf)))
>> 12: vapply(split(start(res$input$vcf),
>> as.character(seqnames(res$input$vcf))),
>> function(x) c(min(x), max(x)), c(min = double(1), max =
>> double(1)))
>> 11: t(vapply(split(start(res$input$vcf),
>> as.character(seqnames(res$input$vcf))),
>> function(x) c(min(x), max(x)), c(min = double(1), max =
>> double(1
>> 10: withCallingHandlers(expr, warning = function(w)
>> invokeRestart("muffleWarning"))
>> 9: suppressWarnings(t(vapply(split(start(res$input$vcf),
>> as.character(seqnames(res$input$vcf))),
>>function(x) c(min(x), max(x)), c(min = double(1), max =
>> double(1)
>> 8: .getArmLocations(res)
>> 7: callLOH(purecn.example.output)
>> 6: head(callLOH(purecn.example.output)) at Rex657e3e41cba7#8
>> 5: eval(expr, envir, enclos)
>> 4: eval(ei, envir)
>> 3: withVisible(eval(ei, envir))
>> 2: source(tf, local, echo = echo, prompt.echo = paste0(prompt.prefix,
>>getOption("prompt")), continue.echo = paste0(prompt.prefix,
>>getOption("continue")), verbose = verbose, max.deparse.length =
>> Inf,
>>encoding = "UTF-8", skip.echo = skips, keep.source = TRUE)
>> 1: example("callLOH", package = "PureCN")
>>
>>> sessionInfo()
>>
>> R version 3.3.3 (2017-03-06)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 16.04.2 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] stats4parallel  stats graphics  grDevices utils datasets
>> [8] methods   base
>>
>> other attached packages:
>>  [1] PureCN_1.2.3   VariantAnnotation_1.20.2
>>  [3] Rsamtools_1.26.1   Biostrings_2.42.1
>>  [5] XVector_0.14.0 SummarizedExperiment_1.4.0
>>  [7] Biobase_2.34.0 GenomicRanges_1.26.3
>>  [9] GenomeInfoDb_1.10.3IRanges_2.8.1
>> [11] S4Vectors_0.12.1   BiocGenerics_0.20.0
>> [13] DNAcopy_1.48.0
>>
>> loaded via a na

[Bioc-devel] Bioconductor and R 3.3.3: Error in c(x, values) : could not find symbol "recursive" in environment of the generic function

[Henrik Bengtsson]

Hi. FYI / Is anyone else experiencing:

Error in c(x, values) :
  could not find symbol "recursive" in environment of the generic function

errors for some Bioconductor packages when running under R 3.3.3 while
they don't occur with R 3.3.2?  This seems realted to the following R
3.3.3 NEWS entry:

c()'s argument use.names is documented now, as belonging to the (C
internal) default method. In “parallel”, argument recursive is also
moved from the generic to the default method, such that the formal
argument list of base generic c() is just (...).

One quick example is:

$ R --vanilla
> example("callLOH", package = "PureCN")
[...]
> head(callLOH(purecn.example.output))
Error in c(x, values) :
  could not find symbol "recursive" in environment of the generic function

> traceback()
24: c(x, values)
23: append(mcols(gr), slot(x, "fixed"))
22: append(mcols(gr), slot(x, "fixed"))
21: .local(x, ...)
20: rowRanges(x)
19: rowRanges(x)
18: (function (x, ...)
standardGeneric("start"))(x = rowRanges(x), ... = ...)
17: do.call(start, list(x = rowRanges(x), ... = ...))
16: do.call(start, list(x = rowRanges(x), ... = ...))
15: start(res$input$vcf)
14: start(res$input$vcf)
13: split(start(res$input$vcf), as.character(seqnames(res$input$vcf)))
12: vapply(split(start(res$input$vcf), as.character(seqnames(res$input$vcf))),
function(x) c(min(x), max(x)), c(min = double(1), max = double(1)))
11: t(vapply(split(start(res$input$vcf), as.character(seqnames(res$input$vcf))),
function(x) c(min(x), max(x)), c(min = double(1), max = double(1
10: withCallingHandlers(expr, warning = function(w)
invokeRestart("muffleWarning"))
9: suppressWarnings(t(vapply(split(start(res$input$vcf),
as.character(seqnames(res$input$vcf))),
   function(x) c(min(x), max(x)), c(min = double(1), max = double(1)
8: .getArmLocations(res)
7: callLOH(purecn.example.output)
6: head(callLOH(purecn.example.output)) at Rex657e3e41cba7#8
5: eval(expr, envir, enclos)
4: eval(ei, envir)
3: withVisible(eval(ei, envir))
2: source(tf, local, echo = echo, prompt.echo = paste0(prompt.prefix,
   getOption("prompt")), continue.echo = paste0(prompt.prefix,
   getOption("continue")), verbose = verbose, max.deparse.length = Inf,
   encoding = "UTF-8", skip.echo = skips, keep.source = TRUE)
1: example("callLOH", package = "PureCN")

> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 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] stats4parallel  stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
 [1] PureCN_1.2.3   VariantAnnotation_1.20.2
 [3] Rsamtools_1.26.1   Biostrings_2.42.1
 [5] XVector_0.14.0 SummarizedExperiment_1.4.0
 [7] Biobase_2.34.0 GenomicRanges_1.26.3
 [9] GenomeInfoDb_1.10.3IRanges_2.8.1
[11] S4Vectors_0.12.1   BiocGenerics_0.20.0
[13] DNAcopy_1.48.0

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.9  AnnotationDbi_1.36.2 GenomicAlignments_1.10.0
 [4] zlibbioc_1.20.0  BiocParallel_1.8.1   BSgenome_1.42.0
 [7] lattice_0.20-34  tools_3.3.3  grid_3.3.3
[10] data.table_1.10.4DBI_0.6  digest_0.6.12
[13] Matrix_1.2-8 RColorBrewer_1.1-2   rtracklayer_1.34.2
[16] bitops_1.0-6 biomaRt_2.30.0   RCurl_1.95-4.8
[19] memoise_1.0.0RSQLite_1.1-2GenomicFeatures_1.26.3
[22] XML_3.98-1.5


Exact same call works with:

> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)

I see this type of error message running R CMD check on:

* PureCN_1.2.3.tar.gz
* Repitools_1.20.0.tar.gz

I probably have installed most of the dep packages on R 3.3.2 and then
upgraded to R 3.3.3.

Over and out,

Henrik

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

Re: [Bioc-devel] Naming and namespace collisions for commonly-named functions

[Henrik Bengtsson]

A few times I'd wish there was a way to support:

  pkg::fun()

while _not_ "exposing" fun() on the search() path when attaching pkg.
Although it would be part of the public / exported API, the only way
to call the function would be via pkg::fun().  This would cover Sean's
use case.  It would also help cluttering up what's on the search()
path, especially for rarely used functions, while still making them
publicly available.

/Henrik


On Tue, Jan 24, 2017 at 7:31 AM, Martin Morgan
 wrote:
> On 01/24/2017 10:19 AM, Sean Davis wrote:
>>
>> Hi, all.
>>
>> I am curious about what folks think about naming conventions for commonly
>> named functions, some of which are so common that even establishing a
>> generic would be difficult because of different use cases.  Examples
>> include things like “filter”.  One possibility is to use the Google Sheets
>> approach and prefix function names with ‘gs_’.  The alternative approach
>> is
>> to use the more common names and rely on folks to disambiguate if more
>> than
>> one package that shares the name is loaded.  The former has the advantage
>> of being more novice-friendly, but the latter is likely to sit nicely with
>> developers and regular R/Bioc users since the functions will be commonly
>> used.  Any thoughts one way or the other?
>
>
> I think that if functions have semantic differences either in argument or
> return values then one should choose a different name, definitely.
>
> Even if functions have similar semantics, it's often valuable to emphasize
> the unique features being offered by your version, e.g., bplapply() points
> the user to the help page where BPPARAM is a explicit argument.
>
> And a prefix means that the script works always, not just when one remembers
> to disambiguate in the session where the conflicting package was not loaded
> (hence no reminder that disambiguation was necessary).
>
> Martin
>
>>
>> Thanks,
>> Sean
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] GitHub and svn

[Henrik Bengtsson]

Hi folks, I'm a person who prefers to use Git as my main source for my
Bioc packages.  These Git repositories are then synced online to
GitHub for each collaboration yada yada.  This also means that these
days I also tend to think of the Bioconductor SVN repository mostly as
a communication channel for submitting new versions (very much as you
FTP package updates to CRAN).

That's my setup.  Now, I constantly failed to remember the git svn
commands to synchronizing between local Git repository and the Bioc
SVN repository - to be honest - it was lots of trial and error
whenever I had to do it.  This caused me to hold back on committing
updates or sometimes I committed directly to the Bioc SVN and manually
copied it over to the Git repository.  Things didn't work smoothly
because I constantly ran into those dreaded `git svn` errors that I
think is due to a non-linear Git history or whatever.

So, I wrote the git-bioc tools: https://github.com/HenrikBengtsson/git-bioc

Now, when I've done updates to my Git repository and feel they're
ready to go live on Bioc devel (after first having pushed to GitHub
and verified that Travis CI and Appveyor CI reports all OK), I
basically do:

1. git bioc pull
2. git bioc import (and solve any conflicts, iff needed)
3. git bioc export (and solve any conflicts, iff needed)
4. git bioc push

The first two won't do anything unless there have been updates
directly to the SVN repos.

Feel free to try it out, improve on it and so on.  I don't have any
plans to maintain this for everyone, but maybe it's a good enough stub
for someone else to build something more general.  Things that can be
improved is how commit messages are compiled / generated and how
conflicts are solved.

Before using it, please read the big WARNING in the README file.

/Henrik

On Sat, Oct 15, 2016 at 6:05 PM, Nathan Sheffield
 wrote:
> Hi Kevin, Mani --
>
> Isn't the git-svn bridge deprecated?
>
> http://bioconductor.org/developers/how-to/git-svn/
> And this message:
>
> - Forwarded Message -
> From: "Dan Tenenbaum"
> To: "bioc-devel"
> Sent: Monday, December 28, 2015 11:08:29 AM
> Subject: [Bioc-devel] Git-Svn bridge will be removed permanently on January
> 29, 2016
>
> Attention Bioconductor developers,
>
> The deprecated Git-SVN bridge will be removed permanently on Friday, January
> 29th, 2016.
>
> But anyway, Mani, I at least agree with you that the current system is
> "unnecessarily complicated" (git-svn, cherry-picking, credentials, mirrors
> and so forth) and I hope it will become much better after, as Kasper put it,
> "the (long) process of changing this" gets finished, which I hope means a
> system that is git-centered, since that seems to be the way the world has
> moved.
>
> I, for one at least, have several ideas for new packages and maintenance of
> old ones that I continue to put off on the hopes that one day soon the
> update system will be as easy for an official Bioconductor repo as it is to
> simply push a git commit to my own repository on GitHub. But alas, it is not
> yet the case -- but I think when this gets "fixed" it will be a glorious
> future indeed.
>
> -Nathan
>
>
> On 10/15/2016 06:41 PM, Kevin RUE wrote:
>>
>> Dear Mani,
>>
>> That's actually where I think the git-svn bridge becomes useful.
>> If you take the time once to synchronise the devel branch of your package
>> from the Bioconductor-mirror to one of the branch on your GitHub
>> repository
>> (for me the master branch), you could then:
>> 1) commit changes to your own repository first (does not affect the BioC
>> code)
>> 2) follow the BioC git-svn instructions that you mentioned to selectively
>> push the changes to either or both the devel and release branche(s) of
>> Bioconductor.
>>
>> I personally don't think that the current system is "unnecessarily
>> complicated". That handful of commands is probably as simple as a system
>> can be, to handle version control selectively applied to multiple branches
>> (devel, 3.3, 3.2, master, ...) of multiple repositories (BioC, GitHub,
>> ...)
>> using multiple version control software (git, svn).
>>
>> The learning curve for version control can be quite steep beyond the basic
>> commands, but one has to bear in mind that RStudio is not a version
>> control
>> software in itself. The GUI only provides buttons for the most common
>> version controls commands (pull/push/update). For more advanced commands,
>> you will have to open a shell anyway (the little wheel icon).
>> I must admit that I was a bit scared/frustrated at first with the system,
>> but after a few attempts to get it right, this little process to control
>> the branches to synchronise can almost become enjoyable when proudly
>> releasing new code :)
>>
>> All the best,
>> Kevin
>>
>>
>> On Sat, Oct 15, 2016 at 10:21 PM, S Manimaran 
>> wrote:
>>
>>> Thanks, Gabe and Kasper, for the info.
>>>
>>>
>>>
>>> 

[Bioc-devel] Package pages: Link to NEWS gone?

[Henrik Bengtsson]

I've noticed this for a while and thought it was a temporary glitch,
or maybe I missed some announcement about it, but it appears that NEWS
files are no longed listed on the Bioc package pages, e.g.
https://bioconductor.org/packages/devel/bioc/html/Biobase.html.  A
mistake?

/Henrik

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

Re: [Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?

[Henrik Bengtsson]

On Thu, Aug 18, 2016 at 4:45 PM, Wolfgang Huber <whu...@embl.de> wrote:
>
>
>> On 17 Aug 2016, at 13:02, Henrik Bengtsson <henrik.bengts...@gmail.com> 
>> wrote:
>>
>> R CMD build, which is what triggers vignette  building, only supports one
>> output file (HTML or PDF) per vignette. It will basically ignore duplicate
>> output formats. This is by design / legacy reasons. Technically it wouldn't
>> be hard to add support for multiple output formats, but that would require
>> changes to R itself - I think it could be a useful feature.
>
> Henrik, I’m sure you have more experience and insight with this than I, but I 
> wonder when (at what stage) and what for R needs to be changed? It seems 
> there are several issues:
> (a) having both the PDF and HTML be built by the build system and be shipped 
> with the package
> (b) making them discoverable on the Bioc package landing page, and on the 
> index page of the R-help system.
> (c) making (a) and (b) easy and standardized for package authors
>
> Re (a), on first sight, it seems that simply adding the YAML lines Ramon 
> mentioned to the vignette will NOT achieve this (it looks like only whatever 
> is the first output format stated, is produced), but  according to
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-package-vignettes
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dSweave-vignettes
> I expect that with sufficient cleverness with (i) a Makefile and/or (ii) 
> registering your own VignetteBuilder (some wrapper around knitr::render that 
> makes sure both outputs are built, with only one run of the R code) it should 
> be possible to achieve (a).
>
> For something almost as good as (b) [or better?], you could have the HTML 
> indexed, and in it e.g. at the top have a button with a link to the PDF file, 
> for those who want to print it.
>

> For (c), I suppose changing R would be handy. Or BiocStyle?

Just a quick background: I was the one adjusting a large chunk of the
vignette code for R 3.0.0 (Feb-March 2013) in order to add support for
generic vignette engines after Yihui Xie and Duncan Murdoch had laid
the groundwork adding support for knitr.  When doing this I did think
about supporting multiple weave output formats (and also keeping
intermediate TeX / Markdown / ... files). What I can recall from this
is that it shouldn't be too hard to do this.  The reason why it wasn't
done was mostly due to the fact that it would require an agreement by
others / R core and time was very short (just before the R 3.0.0
release) so updates were kept at a minimum.

Wolfgang, to answer you question: In my previous reply, I was focusing
on the R CMD build process itself because that's where most of the
action is happening when it comes to building vignettes, but there're
other parts that need to be updated as well.  But the core of the
issue here is that R, or more precisely the tools package, assumes
there should be exactly one output product per vignette.  For
instance, in tools:::find_vignette_product
() 
[https://github.com/wch/r-source/blob/trunk/src/library/tools/R/Vignettes.R#L80-L84]
we have checks like:

if (length(output) > 2L || (final && length(output) > 1L))
stop(gettextf("Located more than one %s output file (by engine %s)
for vignette with name %s: %s", sQuote(by),
sQuote(sprintf("%s::%s", engine$package, engine$name)),
sQuote(name), paste(sQuote(output), collapse=", ")),
domain = NA)

where 'output' holds any matching *.pdf and *.html file (and final =
TRUE).  (In my previous comment I said duplicated outputs would be
ignored, but it seems that there'll be an error instead).

There is also an internal vignette "meta data" data frame holding the
vignette name, title, weave and tangle output files (or something like
that).  The weave output field is a character vector of one element
per vignette.  This data frame is used in several places.  This has to
be updated such that it can hold more than one weave output file per
vignette, i.e. something like meta$weave[[idx]] should be able to hold
one or more strings.  Then functions / mechanisms that make use of
this meta data need to be adjusted, e.g. vignettes(), vignette(),
functions to build the vignette index HTML page etc.  There's probably
needs to be new features added, e.g. what format should be opened by
default when calling vignette()?

So, again, I think this is fairly straightforward to implement, but
the first step is to convince R core that this should be done.  I
think one strong argument is that PDF alone is a rather bad format for
screen readers while HTML is a much better in this sense.  One could
also imagine vignette engines that are designed to provide highly
screen-reader friendly output files / formats in addition to the
standard HTML / PDF 

Re: [Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?

[Henrik Bengtsson]

R CMD build, which is what triggers vignette  building, only supports one
output file (HTML or PDF) per vignette. It will basically ignore duplicate
output formats. This is by design / legacy reasons. Technically it wouldn't
be hard to add support for multiple output formats, but that would require
changes to R itself - I think it could be a useful feature.

A related question is where some prefer to have access to also the
intermediate plain Markdown / TeX rather than the final HTML / PDF product,
e.g. because they work better with screen readers.

The only way I see you can have a PDF and a HTML version at the same time
is to create to identical vignettes each outputting a specific format.

Henrik

On Aug 17, 2016 12:17, "Ramon Diaz-Uriarte"  wrote:

>
> Dear All,
>
> I am considering rewriting the vignette of one BioC package I maintain as
> Rmd (it is currently Rnw). But I would like that the entry under
> "Documentation" contain a PDF of the vignette; it can ideally also contain
> the HTML version too, but I do not want it to not have the PDF[1].
>
>
> I know I can add entries to the document header such as
>
> output:
>   BiocStyle::pdf_document:
> toc: true
>   BiocStyle::html_document:
> toc: true
>
>
> that will, when run locally via "render('file.Rmd', output_format =
> 'all')", produce both formats.
>
>
>
> I've googled around, but I am not sure about:
>
> 1. If I have both output formats specified in the document header, will the
> BioC page of the package actually show both the PDF and the HTML of the
> vignette?
>
>
> 2. Is it OK (in conforming with BioC policies, sensible[1], whatever) to
> even try/want this? My reading of the doc for the BiocStyle
> (https://www.bioconductor.org/packages/devel/bioc/vignettes/
> BiocStyle/inst/doc/HtmlStyle.html)
> seems to suggest that the "natural" thing for Rmd vignettes is to be
> rendered as HTML, but I have not seen that producing PDF is discouraged
> explicitly.
>
>
> Best,
>
>
> R.
>
>
> [1] Why do I want to get a PDF if I am using Rmd? I want a PDF because this
> is a fairly long document that some users want to be able to print. I want
> HTML because some users prefer HTML and because I'd like to also place the
> vignette as HTML in Github Pages. I think that the only way to accomplish
> both is to use Rmd (not Rnw, even if I really, really, prefer LaTeX :-).
>
>
>
>
>
>
>
> --
> Ramon Diaz-Uriarte
> Department of Biochemistry, Lab B-25
> Facultad de Medicina
> Universidad Autónoma de Madrid
> Arzobispo Morcillo, 4
> 28029 Madrid
> Spain
>
> Phone: +34-91-497-2412
>
> Email: rdia...@gmail.com
>ramon.d...@iib.uam.es
>
> http://ligarto.org/rdiaz
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] moscato2 Windows build error reading IDAT file

[Henrik Bengtsson]

No worries. Glad to hear it WS just a hiccup.

Henrik
On Apr 11, 2016 4:53 PM, "Dan Tenenbaum" <dtene...@fredhutch.org> wrote:

> I upgraded to r70462 and I cannot reproduce it now either. I guess it was
> an issue in R-alpha, since fixed.
> Sorry for the trouble.
>
> Dan
>
>
> - Original Message -
> > From: "Henrik Bengtsson" <henrik.bengts...@gmail.com>
> > To: "Dan Tenenbaum" <dtene...@fredhutch.org>
> > Cc: "Maarten van Iterson" <mviter...@gmail.com>, "bioc-devel" <
> bioc-devel@r-project.org>
> > Sent: Monday, April 11, 2016 4:01:05 PM
> > Subject: Re: [Bioc-devel] moscato2 Windows build error reading IDAT file
>
> > I *cannot* reproduce this:
> >
> > % R --vanilla
> > ## The IDAT file
> >> pathname <- system.file(package="minfiData", "extdata", "5723646053",
> >> "5723646053_R05C02_Grn.idat")
> >> file.info(pathname)$size
> > [1] 8091452
> >> unname(tools::md5sum(pathname))
> > [1] "dfc33fdaf3e91d872be896643a0c837f"
> >> packageVersion("minfiData")
> > [1] '0.13.0'
> >
> > ## Parsing it
> >> data <- illuminaio:::readIDAT_nonenc(pathname)
> >> str(data)
> > List of 12
> > $ fileSize : num 8091452
> > $ versionNumber: int 3
> > $ nFields  : int 19
> > $ fields   : num [1:19, 1:3] 1000 102 103 104 107 200 300 400 401
> 402 ...
> >  ..- attr(*, "dimnames")=List of 2
> >  .. ..$ : chr [1:19] "nSNPsRead" "IlluminaID" "SD" "Mean" ...
> >  .. ..$ : chr [1:3] "fieldCode" "byteOffset" "Bytes"
> > $ nSNPsRead: int 622399
> > $ Quants   : int [1:622399, 1:3] 455 12883 2451 7650 4579 4955
> > 1665 1953 5689 264 ...
> >  ..- attr(*, "dimnames")=List of 2
> >  .. ..$ : chr [1:622399] "10600313" "10600322" "10600328" "10600336" ...
> >  .. ..$ : chr [1:3] "Mean" "SD" "NBeads"
> > $ MidBlock : int [1:622399] 10600313 10600322 10600328 10600336
> > 10600345 10600353 10600357 10600364 10600366 10600369 ...
> > $ RedGreen : int 0
> > $ Barcode  : chr "5723646053"
> > $ ChipType : chr "BeadChip 12x8"
> > $ RunInfo  : chr[0 , 1:5]
> >  ..- attr(*, "dimnames")=List of 2
> >  .. ..$ : NULL
> >  .. ..$ : chr [1:5] "RunTime" "BlockType" "BlockPars" "BlockCode" ...
> > $ Unknowns :List of 7
> >  ..$ MostlyNull: chr ""
> >  ..$ MostlyA   : chr "R05C02"
> >  ..$ Unknown.1 : chr ""
> >  ..$ Unknown.2 : chr ""
> >  ..$ Unknown.3 : chr ""
> >  ..$ Unknown.4 : chr ""
> >  ..$ Unknown.5 : chr ""
> >
> >> sessionInfo()
> > R version 3.3.0 beta (2016-04-08 r70447)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > Running under: Windows 7 x64 (build 7601) Service Pack 1
> >
> > locale:
> > [1] LC_COLLATE=English_United States.1252
> > [2] LC_CTYPE=English_United States.1252
> > [3] LC_MONETARY=English_United States.1252
> > [4] LC_NUMERIC=C
> > [5] LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] base64_1.1illuminaio_0.13.1
> >
> > % R CMD config COMPILED_BY
> > gcc-4.9.3
> >
> > /Henrik
> >
> > On Mon, Apr 11, 2016 at 9:21 AM, Dan Tenenbaum <dtene...@fredhutch.org>
> wrote:
> >> The problem seems to have to do with illuminaio and possibly minfiData;
> it can
> >> be reduced to / reproduced by the following:
> >>
> >> library(illuminaio)
> >> file <-
> >>
> "e:/biocbld/bbs-3.3-bioc/R/library/minfiData/extdata/5723646053/5723646053_R05C02_Grn.idat"
> >> illuminaio:::readIDAT_nonenc(file)
> >>
> >> Specifically the error occurs on line 59 of
> illuminaio/R/readIDAT_nonenc.R, in
> >> the readString() function inside readIDAT_nonenc().
> >>
> >> I'll leave it to the maintainer(s) of those packages to trobuleshoot
> further
> >> what the problem is.
> >>
> >>> traceback()
> >> 5: readString(con = con)
> >> 4: readField(con = con, field = xx)
> >> 3: FUN(X[[i]], ...)
> >> 2: lapply

Re: [Bioc-devel] moscato2 Windows build error reading IDAT file

[Henrik Bengtsson]

I *cannot* reproduce this:

% R --vanilla
## The IDAT file
> pathname <- system.file(package="minfiData", "extdata", "5723646053", 
> "5723646053_R05C02_Grn.idat")
> file.info(pathname)$size
[1] 8091452
> unname(tools::md5sum(pathname))
[1] "dfc33fdaf3e91d872be896643a0c837f"
> packageVersion("minfiData")
[1] '0.13.0'

## Parsing it
> data <- illuminaio:::readIDAT_nonenc(pathname)
> str(data)
List of 12
 $ fileSize : num 8091452
 $ versionNumber: int 3
 $ nFields  : int 19
 $ fields   : num [1:19, 1:3] 1000 102 103 104 107 200 300 400 401 402 ...
  ..- attr(*, "dimnames")=List of 2
  .. ..$ : chr [1:19] "nSNPsRead" "IlluminaID" "SD" "Mean" ...
  .. ..$ : chr [1:3] "fieldCode" "byteOffset" "Bytes"
 $ nSNPsRead: int 622399
 $ Quants   : int [1:622399, 1:3] 455 12883 2451 7650 4579 4955
1665 1953 5689 264 ...
  ..- attr(*, "dimnames")=List of 2
  .. ..$ : chr [1:622399] "10600313" "10600322" "10600328" "10600336" ...
  .. ..$ : chr [1:3] "Mean" "SD" "NBeads"
 $ MidBlock : int [1:622399] 10600313 10600322 10600328 10600336
10600345 10600353 10600357 10600364 10600366 10600369 ...
 $ RedGreen : int 0
 $ Barcode  : chr "5723646053"
 $ ChipType : chr "BeadChip 12x8"
 $ RunInfo  : chr[0 , 1:5]
  ..- attr(*, "dimnames")=List of 2
  .. ..$ : NULL
  .. ..$ : chr [1:5] "RunTime" "BlockType" "BlockPars" "BlockCode" ...
 $ Unknowns :List of 7
  ..$ MostlyNull: chr ""
  ..$ MostlyA   : chr "R05C02"
  ..$ Unknown.1 : chr ""
  ..$ Unknown.2 : chr ""
  ..$ Unknown.3 : chr ""
  ..$ Unknown.4 : chr ""
  ..$ Unknown.5 : chr ""

> sessionInfo()
R version 3.3.0 beta (2016-04-08 r70447)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] base64_1.1illuminaio_0.13.1

% R CMD config COMPILED_BY
gcc-4.9.3

/Henrik

On Mon, Apr 11, 2016 at 9:21 AM, Dan Tenenbaum  wrote:
> The problem seems to have to do with illuminaio and possibly minfiData; it 
> can be reduced to / reproduced by the following:
>
> library(illuminaio)
> file <- 
> "e:/biocbld/bbs-3.3-bioc/R/library/minfiData/extdata/5723646053/5723646053_R05C02_Grn.idat"
> illuminaio:::readIDAT_nonenc(file)
>
> Specifically the error occurs on line 59 of illuminaio/R/readIDAT_nonenc.R, 
> in the readString() function inside readIDAT_nonenc().
>
> I'll leave it to the maintainer(s) of those packages to trobuleshoot further 
> what the problem is.
>
>> traceback()
> 5: readString(con = con)
> 4: readField(con = con, field = xx)
> 3: FUN(X[[i]], ...)
> 2: lapply(res, function(xx) {
>where <- fields[xx, "byteOffset"]
>seek(con, where = where, origin = "start")
>readField(con = con, field = xx)
>})
> 1: illuminaio:::readIDAT_nonenc(file)
>
>
>> sessionInfo()
> R version 3.3.0 alpha (2016-03-28 r70390)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows Server 2008 R2 x64 (build 7601) Service Pack 1
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
>  [1] illuminaio_0.13.1
>  [2] minfiData_0.13.0
>  [3] IlluminaHumanMethylation450kanno.ilmn12.hg19_0.2.1
>  [4] IlluminaHumanMethylation450kmanifest_0.4.0
>  [5] minfi_1.17.10
>  [6] bumphunter_1.11.5
>  [7] locfit_1.5-9.1
>  [8] iterators_1.0.8
>  [9] foreach_1.4.3
> [10] Biostrings_2.39.12
> [11] XVector_0.11.8
> [12] SummarizedExperiment_1.1.24
> [13] GenomicRanges_1.23.26
> [14] GenomeInfoDb_1.7.6
> [15] IRanges_2.5.43
> [16] S4Vectors_0.9.46
> [17] lattice_0.20-33
> [18] Biobase_2.31.3
> [19] BiocGenerics_0.17.5
> [20] MethylAid_1.5.4
>
> loaded via a namespace (and not attached):
>  [1] mclust_5.2   base64_1.1   Rcpp_0.12.4
>  [4] Rsamtools_1.23.8 digest_0.6.9 gridBase_0.4-7
>  [7] mime_0.4 R6_2.1.2 plyr_1.8.3
> [10] chron_2.3-47 RSQLite_1.0.0ggplot2_2.1.0
> [13] zlibbioc_1.17.1  GenomicFeatures_1.23.29  data.table_1.9.6
> [16] annotate_1.49.1  hexbin_1.27.1preprocessCore_1.33.0
> [19] splines_3.3.0BiocParallel_1.5.21  stringr_1.0.0
> [22] RCurl_1.95-4.8   biomaRt_2.27.2   munsell_0.4.3
> [25] shiny_0.13.2 httpuv_1.3.3 rtracklayer_1.31.10
> [28] multtest_2.27.0  pkgmaker_0.22htmltools_0.3.5
> [31] GEOquery_2.37.0  quadprog_1.5-5  

Re: [Bioc-devel] Odd behavior by R CMD check

[Henrik Bengtsson]

If you have R-devel you can get those NOTEs using:

R CMD check --as-cran *.tar.gz

(It's been reported by --as-cran since Oct 2015 or so).

/Henrik

On Fri, Mar 11, 2016 at 2:45 PM, Hartley, Stephen (NIH/NHGRI) [F]
 wrote:
> Thanks.  I'll try that. I'm surprised, as my local R-Devel install isn't that 
> old.
>
> I used to have a few specific imports like this, but I was told to remove 
> them because BiocCheck did not like them (because these packages were not 
> declared in the "imports" line of the DESCRIPTION). I don't know if the 
> newest version of BiocCheck still complains about them now.
>
> -Steve
>
> -Original Message-
> From: Martin Morgan [mailto:martin.mor...@roswellpark.org]
> Sent: Friday, March 11, 2016 2:24 PM
> To: Hartley, Stephen (NIH/NHGRI) [F]; bioc-devel
> Subject: Re: [Bioc-devel] Odd behavior by R CMD check
>
>
>
> On 03/11/2016 02:17 PM, Hartley, Stephen (NIH/NHGRI) [F] wrote:
>> I'm seeing some odd behavior by the R CMD check command for my package, 
>> JunctionSeq.
>>
>> http://bioconductor.org/checkResults/3.3/bioc-LATEST/JunctionSeq/zin2-
>> checksrc.html
>>
>> It's not technically throwing warnings (just a "NOTE"), but it is claiming 
>> that there's no global definition for functions belonging to the default R 
>> packages (grDevices, utils, stats, and graphics).
>>
>> So I get lines like this:
>> drawGene: no visible global function definition for 'plot.new'
>>
>> drawGene: no visible global function definition for 'plot.window'
>>
>> drawGene: no visible global function definition for 'par'
>>
>> drawGene: no visible global function definition for 'strwidth'
>>
>> drawGene: no visible global function definition for 'lines'
>>
>> drawGene: no visible global function definition for 'rect'
>>
>> drawGene: no visible global function definition for 'segments'
>>
>> drawGene: no visible global function definition for 'strheight'
>>
>> Since it's still able to compile the vignette and everything it's clearly 
>> not actually having a problem finding these functions at runtime, but I 
>> can't figure out what would cause it to throw these notes. I don't get these 
>> notes when I run R CMD check locally on any of my test machines (windows, 
>> CentOS5 linux and scientific linux 6). And I've had it build with no issues 
>> before. I can't see how my recent changes could possibly have caused this ...
>>
>> Has anyone ever seen this before?
>
> This is the behavior with a recent version of R-devel; likely you are using 
> an older version or R-3.2.*. Things 'work' because the relevant packages are 
> on the search path, but would fail if for instance the user or another 
> package were to define a 'strheight' function that did something different 
> from graphics::strheight.
>
> The solution is to import the relevant functions, as indicated in the build 
> report.
>
>importFrom("grDevices", "cairo_ps", "col2rgb", "colorRamp", "dev.off",
>   "png", "rgb", "svg", "tiff", "x11")
>importFrom("graphics", "abline", "axis", "box", "hist", "layout",
>   "legend", "lines", "par", "plot", "plot.new", "plot.window",
>   "points", "rect", "segments", "smoothScatter", "strheight",
>   "strwidth", "text", "title")
>importFrom("stats", "Gamma", "as.formula", "coef", "coefficients",
>   "deviance", "dnbinom", "fitted.values", "formula", "glm",
>   "loess", "model.matrix", "optimize", "p.adjust", "pchisq",
>   "predict", "qf", "rchisq", "rnorm", "runif", "terms",
>   "weighted.mean")
>importFrom("utils", "object.size", "packageVersion", "read.delim",
>   "read.table", "write.table")
>
> Martin
>
>>
>> Regards,
>> Steve Hartley
>>
>>   [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Troubles using R/Bioc-devel with Mac OS X El Capitan 10.11.1

[Henrik Bengtsson]

For your Linux problem:

You might have build R differently from what you had in the past, e.g.
static vs dynamic.

Try to explicitly re-install those failed dependences and see if you any
further.  If so, you might wanna remove all your installed packages and
start over with a fresh package library setup.

Just an idea

Henrik
On Nov 18, 2015 05:47, "Ludwig Geistlinger" <
ludwig.geistlin...@bio.ifi.lmu.de> wrote:

> While I am following Jo's suggestions on installing gcc via homebrew on my
> mac laptop (is it normal that the "make bootstrap" command takes >20 min
> already?), I am in parallel trying to make R/Bioc-devel working on our
> institutional linux machines.
>
> I was able to configure/make R-devel here, however when running biocLite()
> I am encountering (I wonder whether this should be a new thread!?):
>
> > source("http://bioconductor.org/biocLite.R;)
> Bioconductor version 3.3 (BiocInstaller 1.21.1), ?biocLite for help
> > biocLite()
> BioC_mirror: https://bioconductor.org
> Using Bioconductor 3.3 (BiocInstaller 1.21.1), R Under development
> (unstable)
>   (2015-11-16 r69640).
> Installing package(s) ‘Biobase’, ‘IRanges’, ‘AnnotationDbi’
> also installing the dependencies ‘BiocGenerics’, ‘S4Vectors’
>
> trying URL
> '
> https://bioconductor.org/packages/3.3/bioc/src/contrib/BiocGenerics_0.17.1.tar.gz
> '
> Content type 'unknown' length 38319 bytes (37 KB)
> ==
> downloaded 37 KB
>
> trying URL
> '
> https://bioconductor.org/packages/3.3/bioc/src/contrib/S4Vectors_0.9.9.tar.gz
> '
> Content type 'unknown' length 204430 bytes (199 KB)
> ==
> downloaded 199 KB
>
> trying URL
> '
> https://bioconductor.org/packages/3.3/bioc/src/contrib/Biobase_2.31.0.tar.gz
> '
> Content type 'unknown' length 1671264 bytes (1.6 MB)
> ==
> downloaded 1.6 MB
>
> trying URL
> '
> https://bioconductor.org/packages/3.3/bioc/src/contrib/IRanges_2.5.5.tar.gz
> '
> Content type 'unknown' length 490192 bytes (478 KB)
> ==
> downloaded 478 KB
>
> trying URL
> '
> https://bioconductor.org/packages/3.3/bioc/src/contrib/AnnotationDbi_1.33.1.tar.gz
> '
> Content type 'unknown' length 4268223 bytes (4.1 MB)
> ==
> downloaded 4.1 MB
>
> * installing *source* package ‘BiocGenerics’ ...
> ** R
> ** inst
> ** preparing package for lazy loading
> Creating a new generic function for ‘append’ in package ‘BiocGenerics’
> Creating a new generic function for ‘as.data.frame’ in package
> ‘BiocGenerics’
> Error in setGeneric("as.vector", signature = "x") :
>   ‘as.vector’ dispatches internally;  methods can be defined, but the
> generic function is implicit, and cannot be changed.
> Error : unable to load R code in package ‘BiocGenerics’
> ERROR: lazy loading failed for package ‘BiocGenerics’
> * removing ‘/home/users/geistlinger/R/R-devel/library/BiocGenerics’
> ERROR: dependency ‘BiocGenerics’ is not available for package ‘S4Vectors’
> * removing ‘/home/users/geistlinger/R/R-devel/library/S4Vectors’
> ERROR: dependency ‘BiocGenerics’ is not available for package ‘Biobase’
> * removing ‘/home/users/geistlinger/R/R-devel/library/Biobase’
> ERROR: dependencies ‘BiocGenerics’, ‘S4Vectors’ are not available for
> package ‘IRanges’
> * removing ‘/home/users/geistlinger/R/R-devel/library/IRanges’
> ERROR: dependencies ‘BiocGenerics’, ‘Biobase’, ‘IRanges’, ‘S4Vectors’ are
> not available for package ‘AnnotationDbi’
> * removing ‘/home/users/geistlinger/R/R-devel/library/AnnotationDbi’
>
> The downloaded source packages are in
> ‘/tmp/Rtmpx7szqQ/downloaded_packages’
> Updating HTML index of packages in '.Library'
> Making 'packages.html' ... done
> Warning messages:
> 1: In install.packages(pkgs = doing, lib = lib, ...) :
>   installation of package ‘BiocGenerics’ had non-zero exit status
> 2: In install.packages(pkgs = doing, lib = lib, ...) :
>   installation of package ‘S4Vectors’ had non-zero exit status
> 3: In install.packages(pkgs = doing, lib = lib, ...) :
>   installation of package ‘Biobase’ had non-zero exit status
> 4: In install.packages(pkgs = doing, lib = lib, ...) :
>   installation of package ‘IRanges’ had non-zero exit status
> 5: In install.packages(pkgs = doing, lib = lib, ...) :
>   installation of package ‘AnnotationDbi’ had non-zero exit status
>
>
> Any suggestions here as well? Thanks!
>
>
> > sessionInfo()
> R Under development (unstable) (2015-11-16 r69640)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: SUSE Linux Enterprise Desktop 12
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=C  LC_COLLATE=C
>  [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 

Re: [Bioc-devel] Make codetoolsBioC available on GitHub?

[Henrik Bengtsson]

Thanks for the quick reply and for looking into this. /Henrik

On Fri, Jul 24, 2015 at 5:28 PM, Jim Hester james.f.hes...@gmail.com wrote:
 Henrik,

 We currently only mirror packages which are in the latest manifest file
 (https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/bioc_3.2.manifest)
 for Release 3.2 for example.

 We could possibly have another file to special case non-manifest directories
 we would also want to mirror however. I know Dan wanted to do this with the
 https://hedgehog.fhcrc.org/bioconductor/trunk/bioconductor.org/ for example,
 so this would be another use case motivating that change.

 I will bring it up with the rest of the devteam today.

 Jim


 On Fri, Jul 24, 2015 at 11:12 AM, Henrik Bengtsson
 henrik.bengts...@ucsf.edu wrote:

 Currently, the codetoolsBioC package is available via:


 https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC

 Can codetoolsBioC be mirrored on GitHub like the other BioC packages,
 or is that only possible for built and distributed BioC package?

 Thanks,

 Henrik

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



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

[Bioc-devel] Make codetoolsBioC available on GitHub?

[Henrik Bengtsson]

Currently, the codetoolsBioC package is available via:

  https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC

Can codetoolsBioC be mirrored on GitHub like the other BioC packages,
or is that only possible for built and distributed BioC package?

Thanks,

Henrik

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

Re: [Bioc-devel] Announcing newtest coverage shields

[Henrik Bengtsson]

On Wed, Jun 24, 2015 at 5:42 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
 Hello Bioconductors,

 We're pleased to announce a new shield to join the ones we rolled out in May.

 The new shield measures test coverage of a package, as determined by Jim 
 Hester's covr package.

 Coverage is a measure of the degree to which package code is tested by your 
 unit tests (https://en.wikipedia.org/wiki/Code_coverage). If you don't know 
 what unit tests are, read our guidelines at 
 http://bioconductor.org/developers/how-to/unitTesting-guidelines/ .

 These shields are on all package landing pages for software packages in 
 release and devel. An example shield can be seen at

 http://bioconductor.org/packages//Biobase/

 It links to a detailed coverage report at https://codecov.io/ .

 If package coverage cannot be determined (shield value is 'unknown'), the 
 shield links to a section of
 http://bioconductor.org/developers/how-to/unitTesting-guidelines/#coverage 
 explaining why
 this might be.

 Note that the coverage calculation happens on our linux build machines only 
 and is not run as part of the nightly builds, but it is run several times a 
 week. Only packages whose code has changed since the last calculation are run 
 through covr.

 We hope this shield motivates package developers to add unit tests (if they 
 don't have them already) and improve their package's unit test coverage. 
 Refer to the covr
 documentation (http://cran.r-project.org/web/packages/covr/README.html) for 
 more
 information on how to do this.

 Questions and comments are welcome as always on the bioc-devel list.

[snare drums] ... hi-hat!

Thank you very much for adding this.  For folks who yet haven't looked
into code coverage - it's extremely useful:

* You get line-by-line coverage estimates for your R code, e.g.
  https://codecov.io/github/Bioconductor-mirror/DNAcopy/R/segment.R

* Also for your native code, e.g.
  
https://codecov.io/github/Bioconductor-mirror/DNAcopy/src/changepoints.f?ref=master

* The line-to-line reports makes it very easy to design new tests.

My experience from turning uncovered (red) code lines into covered
(green) is that you are quite likely to discover a few more bugs
along the way.  I'd say it's one of the most efficient ways to find
unknown bugs that I ever used.  A useful rule of thumb is to always
make sure that the code coverage never decreases whenever a new
version is released.

/Henrik


 Thanks,
 Dan

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

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

Re: [Bioc-devel] upcoming changes - maintainer integration with support site

[Henrik Bengtsson]

Just got the email asking me to sign up.  The thing is that I've
already signed up, but using a different email address that the one
listed as the maintainer of my package(s).  Is there a way to have
multiple associated email addresses on
https://support.bioconductor.org/?  I cannot find such an option.

/Henrik

On Fri, May 22, 2015 at 5:10 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
 Hi all,

 There's now a script that makes sure that all package maintainers who are on 
 the support site (https://support.bioconductor.org) have all the packages 
 they maintain in their watched tags field, meaning they will get an email 
 every time someone posts a question tagged with their (lowercase) package 
 name.

 This script will run regularly so that this step is automated.

 The next step is a script that will regularly nag those maintainers who do 
 NOT have logins on the support site. Just wanted to warn you that this is 
 coming up! You can avoid it by registering for the support site using the 
 same email address that's in the Maintainer field of the package(s) you 
 maintain.

 Finally, BiocCheck will be modified to make sure the package's maintainer is 
 on the support site and it will fail if this is not the case, so for new 
 packages (which are required to pass BiocCheck) this will be a requirement.

 Thanks for your contributions to Bioconductor and for contributing your 
 expertise by answering questions on the support site!

 Let us know if you have questions.
 Dan

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

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

Re: [Bioc-devel] Use and Usability metrics / shields

[Henrik Bengtsson]

So, lots of things are happening in a few months: Jim Hester starts
working at Bioconductor, we get Bioc shields/badges, Jim's covr
package is released on CRAN, snare drum, ...  am I to eager if I
already now start wishing for a hi-hat as well?

/Henrik

On Tue, May 19, 2015 at 12:47 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:


 - Original Message -
 From: Leonardo Collado Torres lcoll...@jhu.edu
 To: Dan Tenenbaum dtene...@fredhutch.org
 Cc: Jim Hester james.f.hes...@gmail.com, bioc-devel@r-project.org
 Sent: Tuesday, May 19, 2015 12:37:18 PM
 Subject: Re: [Bioc-devel] Use and Usability metrics / shields

 Regarding the 'posts' tag, I can see that it includes a closed
 questions component. For example,
 http://www.bioconductor.org/packages/release/bioc/html/derfinder.html
 is 3/1/9/0 right now meaning that 0 questions are closed. From
 https://support.bioconductor.org/info/faq/, only moderators can close
 questions. That seems like quite a bit of work for the moderators. So
 maybe it would be best to drop the closed questions component. Or
 alternatively, can the author of a package moderate the posts that
 have a tag corresponding to their package?


 Perhaps the wording is wrong; what 'closed' is supposed to mean is that the 
 original poster has accepted an answer. I'll change 'closed' to 'accepted'.


 As for 'build: warnings', it seems like it will show for some devel
 packages all the time. For example,
 http://www.bioconductor.org/packages/devel/bioc/html/regionReport.html
 always has a warning in the Windows build machine due to a mismatch
 in
 the version of Rtools installed.

 This is a bug in devtools and may have already been fixed (but not yet 
 propagated to CRAN).
 IMO this should be reflected in the build shield.

 Dan



 I do like these changes and the addition of shields =)


 On Thu, May 14, 2015 at 10:56 AM, Dan Tenenbaum
 dtene...@fredhutch.org wrote:
 
  - Original Message -
  From: Jim Hester james.f.hes...@gmail.com
  To: Martin Morgan mtmor...@fredhutch.org
  Cc: bioc-devel@r-project.org
  Sent: Thursday, May 14, 2015 7:53:03 AM
  Subject: Re: [Bioc-devel] Use and Usability metrics / shields
 
  The common shield convention is to use blue or orange when the
  information
  is not qualitatively good or bad, but the color choice is just
  subjective
  in the end.
 
  It does seem though that we should indicate the non-changing nature
  of these shields with some kind of color change. Perhaps we can
  come up with one that works with the other design elements on the
  page.
 
  BTW, the 'posts' tag does change color; if there are 0 posts tagged
  with a package name, the shield is yellow; otherwise it's green.
 
  Dan
 
 
 
  On Thu, May 14, 2015 at 10:47 AM, Martin Morgan
  mtmor...@fredhutch.org
  wrote:
 
   On 05/10/2015 11:39 AM, COMMO Frederic wrote:
  
   Dear Martin,
  
   All of these suggestions sound good.
  
   Wolfgang's suggestion regarding possible associated papers
   might
   be also
   great.
  
   Another useful information would be to point to other
   publications
   where
   a given package was used, and cited.
   I don't know if it's technically possible, but it would be
   greatly
   informative to know how frequently a package is used, and how
   it
   performs,
   in real contexts.
  
   Frederic Commo
   Bioinformatics, U981
   Gustave Roussy
  
   
   De : Bioc-devel [bioc-devel-boun...@r-project.org] de la part
   de
   Wolfgang Huber [whu...@embl.de]
   Date d'envoi : samedi 9 mai 2015 19:57
   À : Martin Morgan
   Cc: bioc-devel@r-project.org
   Objet : Re: [Bioc-devel] Use and Usability metrics / shields
  
   Dear Martin
  
   great idea.
   Current build status” could perhaps be wrapped with
   Cross-platform
   availability” into some sort of “Availability / Accessibility”?
  
   I wonder how informative it would be to make metrics such as
   (i) citations of the associated paper
   (ii) full-text mentions e.g. in PubmedCentral
   actually useful. (i) could be flawed if package and paper are
   diverged;
   (ii) would require good disambiguation, e.g. like bioNerDS
   http://www.biomedcentral.com/1471-2105/14/194 (or other tools?
   not
   my
   expertise). Do we have someone with capabilities in this area
   on
   this list?
  
  
   Thanks for these suggestions.
  
   I like the idea of linking into the scientific literature,
   initially as
   part of the 'Citation' section on each landing page rather than
   as
   a shield
   (maybe a shield in the long term). As Wolfgang mentions it is a
   little more
   challenging than a one-liner to match the information available
   from a
   CITATION file (or automatically generated) to an appropriate
   search
   in
   PubMed, and because citations are an important formal metric it
   seems
   important to get this more-or-less right.
  
   For what it's worth the more-or-less continuous stream of papers
   citing
   'Biocondcutor' are listed 

Re: [Bioc-devel] Use and Usability metrics / shields

[Henrik Bengtsson]

Sweet; you went live with the badges/shields, e.g.

  http://bioconductor.org/packages/release/bioc/html/affxparser.html

A positive side effect is that now there's a link from the package
page to to the package's check results, which I always wanted :)

Thanks for adding this

/Henrik


On Sun, May 10, 2015 at 11:39 AM, COMMO Frederic
frederic.co...@gustaveroussy.fr wrote:
 Dear Martin,

 All of these suggestions sound good.

 Wolfgang's suggestion regarding possible associated papers might be also 
 great.

 Another useful information would be to point to other publications where a 
 given package was used, and cited.
 I don't know if it's technically possible, but it would be greatly 
 informative to know how frequently a package is used, and how it performs, in 
 real contexts.

 Frederic Commo
 Bioinformatics, U981
 Gustave Roussy

 
 De : Bioc-devel [bioc-devel-boun...@r-project.org] de la part de Wolfgang 
 Huber [whu...@embl.de]
 Date d'envoi : samedi 9 mai 2015 19:57
 À : Martin Morgan
 Cc: bioc-devel@r-project.org
 Objet : Re: [Bioc-devel] Use and Usability metrics / shields

 Dear Martin

 great idea.
 Current build status” could perhaps be wrapped with Cross-platform 
 availability” into some sort of “Availability / Accessibility”?

 I wonder how informative it would be to make metrics such as
 (i) citations of the associated paper
 (ii) full-text mentions e.g. in PubmedCentral
 actually useful. (i) could be flawed if package and paper are diverged; (ii) 
 would require good disambiguation, e.g. like bioNerDS 
 http://www.biomedcentral.com/1471-2105/14/194 (or other tools? not my 
 expertise). Do we have someone with capabilities in this area on this list?

 PS  Martin you’ll like Fig. 2 of their paper.

 Wolfgang





 On May 9, 2015, at 19:15 GMT+2, Martin Morgan mtmor...@fredhutch.org wrote:

 Bioc developers!

 It's important that our users be able to identify packages that are suitable 
 for their research question. Obviously a first step is to identify packages 
 in the appropriate research domain, for instance through biocViews.

  http://bioconductor.org/packages/release/

 We'd like to help users further prioritize their efforts by summarizing use 
 and usability. Metrics include:

 - Cross-platform availability -- biocLite()-able from all or only some 
 platforms
 - Support forum activity -- questions and comments / responses, 6 month 
 window
 - Download percentile -- top 5, 20, 50%, or 'available'
 - Current build status -- errors or warnings on some or all platforms
 - Developer activity -- commits in the last 6 months
 - Historical presence -- years in Bioconductor

 Obviously the metrics are imperfect, so constructive feedback welcome -- we 
 think the above capture in a more-or-less objective and computable way the 
 major axes influencing use and usability.

 We initially intend to prominently display 'shields' (small graphical icons) 
 on package landing pages.

 Thanks in advance for your comments,

 Martin Morgan
 Bioconductor
 --
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109

 Location: Arnold Building M1 B861
 Phone: (206) 667-2793

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

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

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

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

Re: [Bioc-devel] Biobase: Imports repeats Depends

[Henrik Bengtsson]

On Mon, Apr 27, 2015 at 6:45 PM, Hervé Pagès hpa...@fredhutch.org wrote:

 Hi Henrik,

 I know it's not necessary and I know that the WRE manual and
 'R CMD check' don't like this but I like to list in Imports what
 I import and to list in Depends what I want to see attached to
 the search() path. For the same reason that I like to explicitly
 export the generic functions that I define in my packages even
 if exporting the methods defined on these generics is enough
 (because it has the side effect to automatically export the
 generic).

 More generally it's about expressing intentions directly versus
 expressing them in an indirect manner (e.g. by relying on side
 effects). I think the latter is wrong. Hope that makes sense.

Thanks for clarifying.  I simply thought it was a mistake/cut'n'paste typo.

H..


 Cheers,
 H.



 On 04/25/2015 01:12 PM, Henrik Bengtsson wrote:

 It seems unnecessary that BiocGenerics have the same package under
 Imports as under Depends.  The former can be dropped.

 packageDescription(BiocGenerics)

 Package: BiocGenerics
 Title: S4 generic functions for Bioconductor
 Description: S4 generic functions needed by many Bioconductor packages.
 Version: 0.14.0
 Author: The Bioconductor Dev Team
 Maintainer: Bioconductor Package Maintainer
  maintai...@bioconductor.org
 biocViews: Infrastructure
 Depends: methods, utils, graphics, stats, parallel
 Imports: methods, utils, graphics, stats, parallel
 Suggests: Biobase, S4Vectors, IRanges, GenomicRanges, AnnotationDbi,
  oligoClasses, oligo, affyPLM, flowClust, affy, DESeq2, MSnbase,
  annotate, RUnit
 License: Artistic-2.0
 Collate: S3-classes-as-S4-classes.R normarg-utils.R update-utils.R
  .
 NeedsCompilation: no
 Packaged: 2015-04-17 03:42:27 UTC; biocbuild
 Built: R 3.3.0; ; 2015-04-25 20:08:25 UTC; windows

 /Henrik

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


 --
 Hervé Pagès

 Program in Computational Biology
 Division of Public Health Sciences
 Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N, M1-B514
 P.O. Box 19024
 Seattle, WA 98109-1024

 E-mail: hpa...@fredhutch.org
 Phone:  (206) 667-5791
 Fax:(206) 667-1319

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

Re: [Bioc-devel] Bioc package pages: List also BugReports for a package?

[Henrik Bengtsson]

Beautiful. Thxs Henrik

On Mon, Apr 27, 2015 at 6:47 PM, Dan Tenenbaum dtene...@fredhutch.org
wrote:



 - Original Message -
  From: Henrik Bengtsson henrik.bengts...@ucsf.edu
  To: bioC-devel bioc-de...@stat.math.ethz.ch
  Sent: Sunday, April 26, 2015 7:14:20 PM
  Subject: [Bioc-devel] Bioc package pages: List also BugReports for a
 package?
 
  For affxparser, we've got the following in DESCRIPTION:
 
  URL: https://github.com/HenrikBengtsson/affxparser
  BugReports: https://github.com/HenrikBengtsson/affxparser/issues
 
  But t's only the URL field that is listed on the package page(s):
 
  http://www.bioconductor.org/packages/release/bioc/html/affxparser.html
  http://www.bioconductor.org/packages/devel/bioc/html/affxparser.html
 
  May I suggest to also have BugReports listed on package pages?
 

 Done (only added if the package DESCRIPTION contains a BugReports field).

 Dan



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


[[alternative HTML version deleted]]

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

[Bioc-devel] Bioc package pages: List also BugReports for a package?

[Henrik Bengtsson]

For affxparser, we've got the following in DESCRIPTION:

URL: https://github.com/HenrikBengtsson/affxparser
BugReports: https://github.com/HenrikBengtsson/affxparser/issues

But t's only the URL field that is listed on the package page(s):

http://www.bioconductor.org/packages/release/bioc/html/affxparser.html
http://www.bioconductor.org/packages/devel/bioc/html/affxparser.html

May I suggest to also have BugReports listed on package pages?

Thanks,

Henrik

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

[Bioc-devel] Biobase: Imports repeats Depends

[Henrik Bengtsson]

It seems unnecessary that BiocGenerics have the same package under
Imports as under Depends.  The former can be dropped.

 packageDescription(BiocGenerics)
Package: BiocGenerics
Title: S4 generic functions for Bioconductor
Description: S4 generic functions needed by many Bioconductor packages.
Version: 0.14.0
Author: The Bioconductor Dev Team
Maintainer: Bioconductor Package Maintainer
maintai...@bioconductor.org
biocViews: Infrastructure
Depends: methods, utils, graphics, stats, parallel
Imports: methods, utils, graphics, stats, parallel
Suggests: Biobase, S4Vectors, IRanges, GenomicRanges, AnnotationDbi,
oligoClasses, oligo, affyPLM, flowClust, affy, DESeq2, MSnbase,
annotate, RUnit
License: Artistic-2.0
Collate: S3-classes-as-S4-classes.R normarg-utils.R update-utils.R
.
NeedsCompilation: no
Packaged: 2015-04-17 03:42:27 UTC; biocbuild
Built: R 3.3.0; ; 2015-04-25 20:08:25 UTC; windows

/Henrik

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

Re: [Bioc-devel] Dependency issue

[Henrik Bengtsson]

It's a new Bioc package, correct? Then it just got into the Bioc release
branch yday. That Bioc branch requires R 3.2.0 (the new recommended R
version everyone should run) regardless what your package declares. Your
package does not install on R  3.2.0 using the Bioc installers, even if
your package technically was designed for R 2.0.0, say.
(Manual installation would probably do, but that's not recommended since it
may break the Bioc ecosystem.)

Henrik
On Apr 17, 2015 11:30 PM, t.kuil...@nki.nl wrote:

 Hello everyone,

 I have tested whether our new package CopywriteR could be installed, but
 surprisingly got the message that it could not be installed under R 3.1.2:

 Warning message:
 package ‘CopywriteR’ is not available (for R version 3.1.2)

 All the dependencies of CopywriteR have R = 3.1.0 or these depend on
 earlier versions of R. Can anyone tell me whether this dependency is
 imposed by Bioconductor or what would be the explanation for this? (I did
 note that during the BiocCheck checks I got the recommendation to update
 the R version dependency to 3.2 but I would rather have it backward
 compatible with older versions of R too)

 Thanks,

 Thomas





 R version 3.1.2 (2014-10-31)
 Platform: x86_64-pc-linux-gnu (64-bit)

 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

 other attached packages:
 [1] BiocInstaller_1.16.2

 loaded via a namespace (and not attached):
 [1] tools_3.1.2



 --
 Thomas Kuilman, PhD
 Department of Molecular Oncology
 Netherlands Cancer Institute
 1066 CX Amsterdam
 The Netherlands

 Phone: +31-20-5121841

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


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Dependency issue

[Henrik Bengtsson]

It's a new Bioc package, correct? Then it just got into the Bioc release
branch yday. That Bioc branch requires R 3.2.0 (the new recommended R
version everyone should run) regardless what your package declares. Your
package does not install on R  3.2.0 using the Bioc installers, even if
your package technically was designed for R 2.0.0, say.
(Manual installation would probably do, but that's not recommended since it
may break the Bioc ecosystem.)

Henrik
On Apr 17, 2015 11:30 PM, t.kuil...@nki.nl wrote:

 Hello everyone,

 I have tested whether our new package CopywriteR could be installed, but
 surprisingly got the message that it could not be installed under R 3.1.2:

 Warning message:
 package ‘CopywriteR’ is not available (for R version 3.1.2)

 All the dependencies of CopywriteR have R = 3.1.0 or these depend on
 earlier versions of R. Can anyone tell me whether this dependency is
 imposed by Bioconductor or what would be the explanation for this? (I did
 note that during the BiocCheck checks I got the recommendation to update
 the R version dependency to 3.2 but I would rather have it backward
 compatible with older versions of R too)

 Thanks,

 Thomas





 R version 3.1.2 (2014-10-31)
 Platform: x86_64-pc-linux-gnu (64-bit)

 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

 other attached packages:
 [1] BiocInstaller_1.16.2

 loaded via a namespace (and not attached):
 [1] tools_3.1.2



 --
 Thomas Kuilman, PhD
 Department of Molecular Oncology
 Netherlands Cancer Institute
 1066 CX Amsterdam
 The Netherlands

 Phone: +31-20-5121841

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


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 3.1 branch created

[Henrik Bengtsson]

On Apr 16, 2015 9:44 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:



 - Original Message -
  From: Henrik Bengtsson henrik.bengts...@ucsf.edu
  To: Dan Tenenbaum dtene...@fredhutch.org
  Cc: bioc-devel bioc-devel@r-project.org
  Sent: Thursday, April 16, 2015 6:57:45 PM
  Subject: Re: [Bioc-devel] BioC 3.1 branch created
 
  On Thu, Apr 16, 2015 at 1:23 PM, Dan Tenenbaum
  dtene...@fredhutch.org wrote:
   The BioC 3.1 branch is now ready.
  
   Remember, you always have access to 2 versions of your package:
   the release and the devel versions.
  
   Right now the release version of your package (which is not
   officially released yet but will be tomorrow if
   everything goes well) is in the 3.1 branch and accessible at:
  
  
https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/
PKGNAME
  
   Only bug fixes and documentation improvements should go here.
  
   As always the devel version of your package is at:
  
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/PKGNAME
  
   Similarly for experiment packages, where your package is available
   in devel at
  
   https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/PKGNAME
  
   The release branch of it is in:
  
  
https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_1/experiment/pkgs/
PKGNAME
  
  
   Normal development of your package can now resume here.
  
   Please let us know if you have any questions.
 
  Was the wrong version bump done for the GitHub-SVN bridges, because
  the 'bioc-sync' commits show release version numbers and not devel
  ones?!
 

 Not the wrong version bump, but it seems like the second one didn't come
through.

 Should be sorted now. Sorry for the inconvenience.

Confirmed. And no worries. Thanks for your great work.

Henrik


 Dan



  For instance, the aroma.light GitHub repository (master branch),
  which
  should reflect the Bioc devel version, 'bioc-sync' made a commit
  bumping the version from 1.39.5 to 1.40.0.  Note that this version is
  the version for the Bioc release - not Bioc devel.  I would expect it
  to be a bump to 1.41.0. Details:
 
 
https://github.com/HenrikBengtsson/affxparser/commit/ef10d93df696d018de3e426bc6c2c1b8256a9b06
  (1.40.0)
 
https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/affxparser/DESCRIPTION
  (1.40.0)
 
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/affxparser/DESCRIPTION
  (1.41.0)
 
  I've verified that the bridge is still to the Bioc devel SVN
  (trunk/madman), because when I tweaked the Date in DESCRIPTION (with
  the wrong Version field) and pushed to GitHub, that was reflected on
  Bioc devel SVN  (trunk/madman).
 
  I see the same for aroma.light as well:
 
 
https://github.com/HenrikBengtsson/aroma.light/commit/64b2bbef5b81baebc5da548110a0bf1c25d208e2
  (2.4.0)
 
https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/aroma.light/DESCRIPTION
  (2.4.0)
 
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/aroma.light/DESCRIPTION
  (2.5.0)
 
  Holding back with pushes via GitHub until I resolved. Let me know if
  this is a FAQ.
 
  Thanks,
 
  Henrik
 
  
  
   Thanks!
  
   Dan
  
   ___
   Bioc-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/bioc-devel
 

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 3.1 branch created

[Henrik Bengtsson]

On Thu, Apr 16, 2015 at 1:23 PM, Dan Tenenbaum dtene...@fredhutch.org wrote:
 The BioC 3.1 branch is now ready.

 Remember, you always have access to 2 versions of your package:
 the release and the devel versions.

 Right now the release version of your package (which is not
 officially released yet but will be tomorrow if
 everything goes well) is in the 3.1 branch and accessible at:

 https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/PKGNAME

 Only bug fixes and documentation improvements should go here.

 As always the devel version of your package is at:

  https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/PKGNAME

 Similarly for experiment packages, where your package is available in devel at

 https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/PKGNAME

 The release branch of it is in:

 https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_1/experiment/pkgs/PKGNAME


 Normal development of your package can now resume here.

 Please let us know if you have any questions.

Was the wrong version bump done for the GitHub-SVN bridges, because
the 'bioc-sync' commits show release version numbers and not devel
ones?!

For instance, the aroma.light GitHub repository (master branch), which
should reflect the Bioc devel version, 'bioc-sync' made a commit
bumping the version from 1.39.5 to 1.40.0.  Note that this version is
the version for the Bioc release - not Bioc devel.  I would expect it
to be a bump to 1.41.0. Details:

https://github.com/HenrikBengtsson/affxparser/commit/ef10d93df696d018de3e426bc6c2c1b8256a9b06
(1.40.0)
https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/affxparser/DESCRIPTION
(1.40.0)
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/affxparser/DESCRIPTION
(1.41.0)

I've verified that the bridge is still to the Bioc devel SVN
(trunk/madman), because when I tweaked the Date in DESCRIPTION (with
the wrong Version field) and pushed to GitHub, that was reflected on
Bioc devel SVN  (trunk/madman).

I see the same for aroma.light as well:

https://github.com/HenrikBengtsson/aroma.light/commit/64b2bbef5b81baebc5da548110a0bf1c25d208e2
(2.4.0)
https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_1/madman/Rpacks/aroma.light/DESCRIPTION
(2.4.0)
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/aroma.light/DESCRIPTION
(2.5.0)

Holding back with pushes via GitHub until I resolved. Let me know if
this is a FAQ.

Thanks,

Henrik



 Thanks!

 Dan

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

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

Re: [Bioc-devel] using devel bug

[Henrik Bengtsson]

On Tue, Mar 10, 2015 at 12:30 PM, Martin Morgan mtmor...@fredhutch.org wrote:
 On 03/10/2015 11:08 AM, Kasper Daniel Hansen wrote:

 Ok, I had to manually remove the BiocInstaller package, restart R and then
 run biocLite and I am now on BiocInstaller 1.17.5 ~ Bioconductor 3.0


 any idea how BiocInstaller 1.16.x was installed in the R-3.2 library? I
 think install.packages() will actually currently do the wrong thing...

I think *when* could also be an important lead. See my troubleshooting
on this in Bioc devel thread '[Bioc-devel] Can't seem to use
useDevel(); biocLite() for BioC 3.1' on Nov 17, 2014:

  https://stat.ethz.ch/pipermail/bioc-devel/2014-November/006670.html

Maybe related?

/Henrik




 Clearly, there is some issue with the IS_UPGRADEABLE variable which (I
 guess) is initialized at install time.

 On Tue, Mar 10, 2015 at 2:01 PM, Kasper Daniel Hansen 
 kasperdanielhan...@gmail.com wrote:

 Using R-devel, I get

 R-devel

 R Under development (unstable) (2015-03-09 r67969) -- Unsuffered
 Consequences
 Copyright (C) 2015 The R Foundation for Statistical Computing
 Platform: x86_64-unknown-linux-gnu (64-bit)

 R is free software and comes with ABSOLUTELY NO WARRANTY.
 You are welcome to redistribute it under certain conditions.
 Type 'license()' or 'licence()' for distribution details.

Natural language support but running in an English locale

 R is a collaborative project with many contributors.
 Type 'contributors()' for more information and
 'citation()' on how to cite R or R packages in publications.

 Type 'demo()' for some demos, 'help()' for on-line help, or
 'help.start()' for an HTML browser interface to help.
 Type 'q()' to quit R.

 
 ** Hopkins NEWS and Notes **
 

 News and updates for the R installation will be sent to bit-help, so
 consider subscribing

 An automatic user library has been created (in case it did not already
 exist) as
  ~/R/x86_64-unknown-linux-gnu-library/3.2
 install.packages and R CMD INSTALL will automatically install to this
 directory, so there is no need for a -l or a lib argument to these
 functions.

 Loading required package: utils
none

 source(http://www.bioconductor.org/biocLite.R;)

 Bioconductor version 3.0 (BiocInstaller 1.16.1), ?biocLite for help


 Why?  In the past it would auto-detect my R version and automatically use
 Bioc devel.  Also, I get

 useDevel(TRUE)

 Error: 'devel' version requires a more recent R

 Enter a frame number, or 0 to exit

 1: useDevel(TRUE)
 2: .stop('devel' version requires a more recent R)

 Best,
 Kasper



 [[alternative HTML version deleted]]

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



 --
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109

 Location: Arnold Building M1 B861
 Phone: (206) 667-2793


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

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

Re: [Bioc-devel] New(ish!) Seattle Bioconductor team member

[Henrik Bengtsson]

On Wed, Mar 4, 2015 at 2:29 PM, Michael Lawrence
lawrence.mich...@gene.com wrote:
 Welcome.

 For those who don't know, Jim is also the author of the neat lintr
 package, which checks your R code as you type, across multiple editors.

 https://github.com/jimhester/lintr

Not to mention https://github.com/jimhester/covr - It only took me one
round of 'covr' to become a test-coverage-oholic.

Jim, great to have you on board.

/Henrik


 Michael

 On Wed, Mar 4, 2015 at 2:20 PM, Martin Morgan mtmor...@fredhutch.org
 wrote:

 Let me take this belated opportunity to introduce Jim Hester 
 jhes...@fredhutch.org to the Bioconductor developer community.

 Jim is working in the short term on SummarizedExperiment, including the
 refactoring efforts he introduced yesterday as well as coercion methods to
 and from ExpressionSet (an initial version from ExpressionSet to
 SummarizedExperiment is available in the development version GenomicRanges;
 iterations will include coercion in the reverse direction as well as
 perhaps more 'clever' mapping between the probeset or gene names of
 ExpressionSet and relevant range-based notation). Jim will also contribute
 to ongoing project activities like new package reviews, package
 maintenance, and upcoming release activities.

 Jim brings a lot of interesting biological and software development
 experience to the project. Say hi when you have a chance!

 Martin
 --
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109

 Location: Arnold Building M1 B861
 Phone: (206) 667-2793

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


 [[alternative HTML version deleted]]

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

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

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

[Henrik Bengtsson]

Not that long ago DESCRIPTION field 'Additional_repositories' was
introduced which the purpose of providing references to non-mainstream
package repositories, e.g. R-Forge.  Interestingly, by mainstream
they mean CRAN and Bioconductor.  The 'Additional_repositories' field
is also enforced for CRAN depending on non-mainstream packages, where
depending on can be any package under Depends, Imports,
Suggests and (I guess), LinkingTo and Enhances.

I bet that in a, hopefully, not too far future, we'll find that
install.packages() will install from not only CRAN by default, but
also Bioconductor and whatever Additional_repositories suggests.  As
usual, the bet is about food and drinks in person whenever/whenever
feasible.


BTW, I have a few feature requests related to Bioc releases/versions:

1. Add release date to online announcement pages online, e.g.
http://bioconductor.org/news/bioc_2_14_release/


2. A data.frame listing Bioc versions and their release dates (maybe
even time stamps), e.g.

 biocVersions()
1.0 2002-04-29
...
2.14 2014-10-14
3.0 2014-04-14
3.1 2015-04-17


3. As far as I understand it, the recommended Bioc version to use
depends on R version and the date (in the past only R version).  I
would like to have a function that returns the Bioc version as a
function of R version and date.  Maybe BiocInstaller::biocVersion()
could be extended with this feature, e.g.

biocVersion - function(date, rversion) {
  ## Current?
  if (missing(date)  missing(rversion)) return(BIOC_VERSION)

  if (missing(date) date - Sys.date()
  date - as.Date(date)
  if (missing(rversion)) rversion - getRversion()

  ## Lookup by (rversion, date) from known releases
  ## and make best guesses for the future (with a warning)
  ...
}

If such a function could be available as a light-weight script online,
then the proper Bioc repos could be downloaded by
tools:::.BioC_version_associated_with_R_version(), cf. Martin's reply
on lagging Bioc versions.  This would bring us one step closer to
installing Bioc packages using install.packages(), cf. Laurent's
original post. Because it may not be clear to an R user that they need
to go to Bioconductor because a CRAN package depends on a Bioc
package. That user might not even have heard of Bioconductor. Not
suggesting biocLite() should be replaced, but the gap for using
install.packages() could be made smaller.  ... and maybe one day we'll
have an omnibus package installer/updater available in a fresh R
installation.

The above biocVersion() function would also be useful for figuring out
what R/BioC version was in use at a certain year in the past (e.g.
reproducing old work) and for finding out versions of Bioc
release/devel packages back in time (e.g. if you try to be backward
compatible).

Thxs,

Henrik

On Mon, Mar 2, 2015 at 3:41 PM, Laurent Gatto lg...@cam.ac.uk wrote:

 Thank you all for your answers.

 Laurent

 On  2 March 2015 23:27, Martin Morgan wrote:

 On 03/02/2015 03:18 PM, Laurent Gatto wrote:

 Dear all,


 I had never realised that CRAN packages that depended on Bioc packages
 could actually not be installed with install.packages without setting a
 repo or using BiocInstaller::bioLite. Here is an example using a fresh R
 installation

http://cran.r-project.org/web/packages/MSeasy/index.html
Depends: amap, clValid, cluster, fpc, mzR, xcms

 $ docker run --rm -ti rocker/r-base R

 R version 3.1.2 (2014-10-31) -- Pumpkin Helmet
 Copyright (C) 2014 The R Foundation for Statistical Computing
 Platform: x86_64-pc-linux-gnu (64-bit)

 R is free software and comes with ABSOLUTELY NO WARRANTY.
 You are welcome to redistribute it under certain conditions.
 Type 'license()' or 'licence()' for distribution details.

Natural language support but running in an English locale

 R is a collaborative project with many contributors.
 Type 'contributors()' for more information and
 'citation()' on how to cite R or R packages in publications.

 Type 'demo()' for some demos, 'help()' for on-line help, or
 'help.start()' for an HTML browser interface to help.
 Type 'q()' to quit R.

 install.packages(MSeasy)
 Installing package into ‘/usr/local/lib/R/site-library’
 (as ‘lib’ is unspecified)
 Warning: dependencies ‘mzR’, ‘xcms’ are not available
 also installing the dependencies ‘modeltools’, ‘DEoptimR’, ‘mclust’, 
 ‘flexmix’, ‘prabclus’, ‘diptest’, ‘mvtnorm’, ‘robustbase’, ‘kernlab’, 
 ‘trimcluster’, ‘amap’, ‘clValid’, ‘fpc’

 [...]

 ERROR: dependencies ‘mzR’, ‘xcms’ are not available for package ‘MSeasy’
 * removing ‘/usr/local/lib/R/site-library/MSeasy’

 The downloaded source packages are in
  ‘/tmp/Rtmp4T40ub/downloaded_packages’
 Warning message:
 In install.packages(MSeasy) :
installation of package ‘MSeasy’ had non-zero exit status

 This does sound really counter-intuitive. Am I missing anything?

 biocLite(MSeasy) is easy and works.

 Otherwise yes, to install a Bioconductor package using install.packages()
 requires that you've selected (via 

Re: [Bioc-devel] BiocGenerics fails to install from source on R-devel (aka there is no package called '2015-01-30 09:23:26')

[Henrik Bengtsson]

Thanks for the quick fix. No need to be sorry. /Henrik

On Fri, Jan 30, 2015 at 9:36 AM, Michael Lawrence
lawrence.mich...@gene.com wrote:
 Just checked in the fix to R-devel. No more error, and the warning is also
 fixed.

 Sorry,
 Michael

 On Fri, Jan 30, 2015 at 9:29 AM, Henrik Bengtsson h...@biostat.ucsf.edu
 wrote:

 I'm posting to bioc-devel, but I suspect it would end up on R-devel.
 Feel free to continue the thread there at any time.


 PROBLEM:
 $ Rscript --vanilla -e
 source('http://bioconductor.org/biocLite.R');biocLite('BiocGenerics',
 type='source')

 Bioconductor version 3.1 (BiocInstaller 1.17.5), ?biocLite for help
 BioC_mirror: http://bioconductor.org
 Using Bioconductor version 3.1 (BiocInstaller 1.17.5), R version 3.2.0.
 Installing package(s) 'BiocGenerics'
 trying URL
 'http://bioconductor.org/packages/3.1/bioc/src/contrib/BiocGenerics_0.13.4.tar.gz'
 Content type 'application/x-gzip' length 34031 bytes (33 KB)
 opened URL
 ==
 downloaded 33 KB

 * installing *source* package âBiocGenericsâ ...
 ** R
 ** inst
 ** preparing package for lazy loading
 Creating a new generic function for âappendâ in package âBiocGenericsâ
 Creating a new generic function for âas.data.frameâ in package
 âBiocGenericsâ
 Creating a new generic function for âas.vectorâ in package âBiocGenericsâ
 Creating a new generic function for âcbindâ in package âBiocGenericsâ
 Creating a new generic function for ârbindâ in package âBiocGenericsâ
 Creating a new generic function for âdo.callâ in package âBiocGenericsâ
 Creating a new generic function for âduplicatedâ in package âBiocGenericsâ
 Creating a new generic function for âanyDuplicatedâ in package
 âBiocGenericsâ
 Creating a new generic function for âevalâ in package âBiocGenericsâ
 Creating a new generic function for âpmaxâ in package âBiocGenericsâ
 Creating a new generic function for âpminâ in package âBiocGenericsâ
 Creating a new generic function for âpmax.intâ in package âBiocGenericsâ
 Creating a new generic function for âpmin.intâ in package âBiocGenericsâ
 Creating a new generic function for âReduceâ in package âBiocGenericsâ
 Creating a new generic function for âFilterâ in package âBiocGenericsâ
 Creating a new generic function for âFindâ in package âBiocGenericsâ
 Creating a new generic function for âMapâ in package âBiocGenericsâ
 Creating a new generic function for âPositionâ in package âBiocGenericsâ
 Creating a new generic function for âgetâ in package âBiocGenericsâ
 Creating a new generic function for âmgetâ in package âBiocGenericsâ
 Creating a new generic function for âis.unsortedâ in package
 âBiocGenericsâ
 Creating a new generic function for âlapplyâ in package âBiocGenericsâ
 Creating a new generic function for âsapplyâ in package âBiocGenericsâ
 Creating a new generic function for âmapplyâ in package âBiocGenericsâ
 Creating a new generic function for âmatchâ in package âBiocGenericsâ
 Creating a new generic function for âorderâ in package âBiocGenericsâ
 Creating a new generic function for âpasteâ in package âBiocGenericsâ
 Creating a new generic function for ârankâ in package âBiocGenericsâ
 Creating a new generic function for ârep.intâ in package âBiocGenericsâ
 Creating a new generic function for ârownamesâ in package âBiocGenericsâ
 Creating a new generic function for âcolnamesâ in package âBiocGenericsâ
 Creating a new generic function for âunionâ in package âBiocGenericsâ
 Creating a new generic function for âintersectâ in package âBiocGenericsâ
 Creating a new generic function for âsetdiffâ in package âBiocGenericsâ
 Creating a new generic function for âsortâ in package âBiocGenericsâ
 Creating a new generic function for âtableâ in package âBiocGenericsâ
 Creating a new generic function for âtapplyâ in package âBiocGenericsâ
 Creating a new generic function for âuniqueâ in package âBiocGenericsâ
 Creating a new generic function for âunlistâ in package âBiocGenericsâ
 Creating a new generic function for âunsplitâ in package âBiocGenericsâ
 Creating a new generic function for âxtabsâ in package âBiocGenericsâ
 Creating a new generic function for âclusterCallâ in package
 âBiocGenericsâ
 Creating a new generic function for âclusterApplyâ in package
 âBiocGenericsâ
 Creating a new generic function for âclusterApplyLBâ in package
 âBiocGenericsâ
 Creating a new generic function for âclusterEvalQâ in package
 âBiocGenericsâ
 Warning in getPackageName(environment(fdef)) :
   Created a package name, â2015-01-30 09:28:06â, when none found
 Error in loadNamespace(name) :
   there is no package called â2015-01-30 09:28:06â
 Error : unable to load R code in package âBiocGenericsâ
 ERROR: lazy loading failed for package âBiocGenericsâ
 * removing
 â/compbio/henrik/R/x86_64-unknown-linux-gnu-library/3.2/BiocGenericsâ
 * restoring previous
 â/compbio/henrik/R/x86_64-unknown-linux-gnu-library/3.2/BiocGenericsâ


 I can reproduce this on R-devel (2015-01-30 r67664) on both Linux and
 Windows (haven't

Re: [Bioc-devel] Can't seem to use useDevel(); biocLite() for BioC 3.1

[Henrik Bengtsson]

[Re-posting since messages send to ...@r-project.org bounced for a
period of ~12-14h on Monday Nov 17]

Hi, I've experiences the exact same thing on both a Windows and a
Linux installation.  It actually took me a while to realize I didn't
get Bioc devel updates, because I run those in the background.  If it
helps, here is my troubleshooting report:

My best guess right now is that at some point in time (around Nov 5;
see below), ***Bioconductor build BiocInstaller v1.16.1 on 3.1.2 and
distributed under BioC devel***, i.e. when I installed under R devel
(aka 3.2.0) I got:

WINDOWS:
 packageDescription(BiocInstaller)
Package: BiocInstaller
Title: Install/Update Bioconductor and CRAN Packages
Description: Installs/updates Bioconductor and CRAN packages
Version: 1.16.1
...
Packaged: 2014-11-05 04:01:38 UTC; biocbuild
Built: R 3.1.2; ; 2014-11-05 06:56:09 UTC; windows
-- File: C:/Users/hb/R/win-library/3.2/BiocInstaller/Meta/package.rds

Note the **biocbuild** tag here on Windows, i.e. it wasn't me that
built it on the wrong system by mistake.

LINUX:
 packageDescription(BiocInstaller)
Package: BiocInstaller
Title: Install/Update Bioconductor and CRAN Packages
Description: Installs/updates Bioconductor and CRAN packages
Version: 1.16.1
...
Packaged: 2014-11-05 02:46:39 UTC; biocbuild
Built: R 3.2.0; ; 2014-11-17 06:11:17 UTC; unix
-- File: 
/compbio/henrik/R/x86_64-unknown-linux-gnu-library/3.2/BiocInstaller/Meta/package.rds

Note also the installation path, which is the default one used by R
devel/3.2.0 on Windows (and similarly on Linux), so I haven't done
anything there either.  ( BTW, maybe it's possible to BiocInstaller to
detect and warn/err on inconsistencies by comparing
packageDescription(BiocInstaller)$Built and getRversion()?!? )  On
top of this, source(http://bioconductor.org/biocLite.R;) in a fresh
session failed to detect that BiocInstaller needs/can be updated.
Also, useDevel(TRUE) incorrectly says 'devel' version requires a more
recent R on R devel.

More details below.


SOLUTION:
The solution is I found on both systems was (also) to uninstall
BiocInstaller, i.e.

 remove.packages(BiocInstaller)



COMPLETE TROUBLESHOOTING:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
WINDOWS
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ R --vanilla

R Under development (unstable) (2014-10-30 r66907) -- Unsuffered Consequences
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

[...]

 source(http://bioconductor.org/biocLite.R;)
Bioconductor version 3.0 (BiocInstaller 1.16.1), ?biocLite for help

 biocLite()
BioC_mirror: http://bioconductor.org
Using Bioconductor version 3.0 (BiocInstaller 1.16.1), R version 3.2.0.
Warning: unable to access index for repository
http://bioconductor.org/packages/3.0/data/annotation/bin/windows/contrib/3.2

[Ctrl-C here]

 useDevel(TRUE)
Error: 'devel' version requires a more recent R

 sessionInfo()
R Under development (unstable) (2014-10-30 r66907)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] BiocInstaller_1.16.1

loaded via a namespace (and not attached):
[1] tools_3.2.0

 packageDescription(BiocInstaller)
Package: BiocInstaller
Title: Install/Update Bioconductor and CRAN Packages
Description: Installs/updates Bioconductor and CRAN packages
Version: 1.16.1
Author: Dan Tenenbaum and Biocore Team
Maintainer: Bioconductor Package Maintainer
maintai...@bioconductor.org
biocViews: Software
Depends: R (= 3.1.0)
Suggests: RUnit, BiocGenerics
License: Artistic-2.0
Packaged: 2014-11-05 04:01:38 UTC; biocbuild
Built: R 3.1.2; ; 2014-11-05 06:56:09 UTC; windows
-- File: C:/Users/hb/R/win-library/3.2/BiocInstaller/Meta/package.rds

 biocLite(BiocInstaller)
BioC_mirror: http://bioconductor.org
Using Bioconductor version 3.0 (BiocInstaller 1.16.1), R version 3.2.0.
Installing package(s) 'BiocInstaller'
Warning: unable to access index for repository
http://bioconductor.org/packages/3.0/data/annotation/bin/windows/contrib/3.2
Warning: package 'BiocInstaller' is in use and will not be installed
Warning: unable to access index for repository
http://bioconductor.org/packages/3.0/data/annotation/bin/windows/contrib/3.2


$ R --vanilla
[...]
 remove.packages(BiocInstaller)
Removing package from 'C:/Users/hb/R/win-library/3.2'
(as 'lib' is unspecified)


 source(http://bioconductor.org/biocLite.R;)
Installing package into 'C:/Users/hb/R/win-library/3.2'
(as 'lib' is unspecified)
trying URL 
'http://www.bioconductor.org/packages/3.1/bioc/bin/windows/contrib/3.2/BiocInstaller_1.17.1.zip'
Content type 'application/zip' length 53397 bytes (52 KB)
opened URL
downloaded 52 

Re: [Bioc-devel] depends on packages providing classes

[Henrik Bengtsson]

On Wed, Oct 29, 2014 at 1:07 PM, Vincent Carey
st...@channing.harvard.edu wrote:
 On Wed, Oct 29, 2014 at 2:15 PM, Hervé Pagès hpa...@fredhutch.org wrote:

 Hi,

 On 10/28/2014 08:51 PM, Vincent Carey wrote:



 On Tue, Oct 28, 2014 at 5:48 PM, Hervé Pagès hpa...@fredhutch.org
 mailto:hpa...@fredhutch.org wrote:



 On 10/28/2014 12:42 PM, Vincent Carey wrote:



 On Tue, Oct 28, 2014 at 2:29 PM, Hervé Pagès
 hpa...@fredhutch.org mailto:hpa...@fredhutch.org
 mailto:hpa...@fredhutch.org mailto:hpa...@fredhutch.org
 wrote:

  Hi,

  On 10/28/2014 08:48 AM, Vincent Carey wrote:

  On Tue, Oct 28, 2014 at 11:23 AM, Kasper Daniel Hansen 
 kasperdanielhan...@gmail.com mailto:kasperdanielhan...@gmail.com
 
  mailto:kasperdanielhansen@__gmail.com

 mailto:kasperdanielhan...@gmail.com wrote:

  Well, first I want to make sure that there is not
 something
  special
  regarding S4 methods and classes. I have a feeling
 that they
  are a special
  case.

  Second, while I agree with Jim's general opinion,
 it is a
  little bit
  different when I have return objects which are
 defined in
  other packages.
  If I don't depend on this other package, the user
 is hosed
  wrt. the return
  object, unless I manually export all classes from
 this other


  In what sense?  If you return an instance of GRanges,
 certain
  things can be
  done
  even if GenomicRanges is not attached.


  Yes certain things maybe, but it's hard to predict which
 ones.

You can get values of slots, for
  example.

  With the following little package

  %vjcair cat foo/NAMESPACE

  importFrom(IRanges, IRanges)

  importClassesFrom(GenomicRanges, GRanges)

  importFrom(GenomicRanges, GRanges)

  export(myfun)



  %vjcair cat foo/DESCRIPTION

  Package: foo

  Title: foo

  Version: 0.0.0

  Author: VJ Carey st...@channing.harvard.edu
 mailto:st...@channing.harvard.edu
  mailto:stvjc@channing.__harvard.edu
 mailto:st...@channing.harvard.edu

  Description:

  Suggests:

  Depends:

  Imports: GenomicRanges

  Maintainer: VJ Carey st...@channing.harvard.edu
 mailto:st...@channing.harvard.edu
  mailto:stvjc@channing.__harvard.edu

 mailto:st...@channing.harvard.edu


  License: Private

  LazyLoad: yes



  %vjcair cat foo/R/*

  myfun = function(seqnames=1, ranges=IRanges(1,2), ...)

   GRanges(seqnames=seqnames, ranges=ranges, ...)


  The following works:


  library(foo)


  x = myfun()


  x


  GRanges object with 1 range and 0 metadata columns:

  seqnamesranges strand

 Rle IRanges  Rle

  [1]1[1, 2]  *

  ---

  seqinfo: 1 sequence from an unspecified genome; no
 seqlengths


  So the show method works, even though I have not
 touched it.  (I
  did not

  expect it to work, in fact.)


  Exactly. Let's call it luck ;-)

Additionally, I can get access to slots.


  The end user should never try to access slots directly but
 use getters
  and setters instead. And most getters and setters for
 GRanges objects
  are defined and documented in the GenomicRanges package.
 Those that are
  not are defined in packages that GenomicRanges depends on.

But
  ranges()

  fails.  If I, the user, want to use it, I need to
 arrange for that.


  IMO if your package returns a GRanges object to the user,
 then the user
  should be able to access the man page for GRanges objects
 with ?GRanges.


 Oddly enough, that seems to be incorrect.  I added a man page to
 foo
 that has
 a \link[GenomicRanges]{GRanges-__class}.  I ran help.start and
 the cross
 reference
 from my man page succeeds.  Furthermore with the sessionInfo
   

[Bioc-devel] Documentation on how to update a BioC experimental package?

[Henrik Bengtsson]

It's been a while since I worked with experimental packages.  Where
can I find documentation on how to (Subversion) update our
AffymetrixDataTestFiles package with additional data files?  All I
know is that the SVN repository only contains a stub of the package
and http://www.bioconductor.org/developers/package-guidelines/#package-types
provides little information and basically only point to the devel
mailing list.

Thanks,

Henrik

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

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[Henrik Bengtsson]

On Wed, Oct 8, 2014 at 12:20 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 10/08/2014 11:41 AM, Henrik Bengtsson wrote:

 You may want to make those function local to latex().  I haven't
 verified it works (won't have time), but I bet a beer that it will
 work.


 I'll take you up on the bet, at least for some definition of 'work'. For
 instance when debugging a vignette or writing a complicated Makefile for
 courses I commonly do the equivalent of

   R CMD Sweave foo.Rnw
   R CMD texi2dvi --pdf foo.tex

 Any environment variables set running Sweave are not available running
 texi2dvi.

Easy,

Rscript -e R.rsp::rfile foo.Rnw

would Sweave + texi2dvi --pdf in one go.  Putting that aside, I'm
happy to buy you a beer :)

Another solution along along lines of using TEXINPUTS would be to do:

R CMD Sweave foo.Rnw
export TEXINPUTS=`Rscript -e BiocStyle::texinputs()`
R CMD texi2dvi --pdf foo.tex


A third different (and obvious) solution, is to copy the files to
the current directory, i.e.

$ svn diff -x --ignore-all-space R/latex.R
Index: R/latex.R
===
--- R/latex.R   (revision 95224)
+++ R/latex.R   (working copy)
@@ -3,12 +3,14 @@
  error=FALSE, use.unsrturl=TRUE)
 {
 options(..., width=width)
-cat(sprintf(\\RequirePackage{%s}\n\n,
-sub(.sty$, , .bioconductor.sty)))
+sty - .bioconductor.sty
+file.copy(sty, basename(sty), overwrite=TRUE)
+cat(\\RequirePackage{Bioconductor}\n\n)

 if (use.unsrturl) {
 bst - file.path(system.file(package=BiocStyle, resources,
  latex), unsrturl)
+file.copy(bst, basename(bst), overwrite=TRUE)
 cat(sprintf(\\AtBeginDocument{\\bibliographystyle{%s}}\n, bst))
 }

This works also in your use case and those local copies are
automagically cleaned out by R CMD build.  This passes R CMD check
--as-cran on BiocStyle etc.  Now one can argue that it will clutter up
your local directory.  For the original problem of \usepackage{} et
al. does not support spaces in paths one can also copy to a temporary
directory and use that path instead.  (Personally I favor not
specifying paths at all to make even the intermediate *.tex file
portable.)

/Henrik



 Martin


 --
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109

 Location: Arnold Building M1 B861
 Phone: (206) 667-2793

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

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[Henrik Bengtsson]

On Mon, Oct 6, 2014 at 7:03 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
 On Mon, Oct 6, 2014 at 6:48 PM, Henrik Bengtsson h...@biostat.ucsf.edu 
 wrote:
 On Mon, Oct 6, 2014 at 5:33 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 10/06/2014 04:52 PM, Henrik Bengtsson wrote:

 Maybe you could use

 \RequirePackage{Bioconductor}

 and then set the TEXINPUTS environment variable via Sys.setenv().
 Internally tools::texi2dvi() is used that that listens to TEXINPUTS.


 Thanks; I think that would require 'us' to run texi2dvi (otherwise the
 environment variable isn't seen by texi2dvi) and that sounds like writing a
 Sweave driver, or worse. latex() could be modified to be passed a flag or
 path indicating a TEXINPUTS directory where bioconductor.sty could be found,
 but that doesn't sound like a robust strategy (e.g., because the
 specially-installed sty file becomes out of sync with the version in the
 package). Hopefully there is a simpler solution.

 I haven't tried, but it's possible that if you do
 Sys.setenv(TEXINPUTS=...) when the BiocStyle is loaded/attached that
 it will stick/survive until the vignette is built.

 It works to set environment variables in either .onLoad() or
 .onAttach().  I verified with:

 .onLoad - function(libname, pkgname) {
   Sys.setenv(FOO=hello)
 }

 .onAttach - function(libname, pkgname) {
   Sys.setenv(BAR=world)
 }

 that both environment variables 'FOO' and 'BAR' are available to the
 vignette itself and have their values set as expected.  I've tried
 with vignette engines knitr::Rmd and R.rsp::rsp and in both cases the
 build and installed vignettes show FOO=hello and BAR=world.

 Given that this works, I would be surprised if you cannot set
 TEXINPUTS such that texi2dvi() et al. won't see it.

See attached latex.R (adopted from
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/BiocStyle/R/latex.R).
A diff -C 3 (also attached) is:

*** latex_org.R 2014-10-08 11:34:15.949845400 -0700
--- latex.R 2014-10-08 11:33:31.932327700 -0700
***
*** 1,15 
  latex -
  function(..., width=90, short.fignames=FALSE, fig.path,
   error=FALSE, use.unsrturl=TRUE)
  {
  options(..., width=width)
! cat(sprintf(\\RequirePackage{%s}\n\n,
! sub(.sty$, , .bioconductor.sty)))

  if (use.unsrturl) {
! bst - file.path(system.file(package=BiocStyle, resources,
!  latex), unsrturl)
! cat(sprintf(\\AtBeginDocument{\\bibliographystyle{%s}}\n, bst))
  }

  setPrefix = function(x) {
--- 1,43 
+ unique_path -
+   function(path, sep=.Platform$path.sep, collapse=sep)
+ {
+ n - length(path)
+ has_tail_sep - (substring(path[n], nchar(path[n])) == sep)
+ path - unlist(strsplit(path, split=sep, fixed=TRUE))
+ path - unique(path)
+ path - path[nchar(path)  0L]
+ path - path[sapply(path, function(.) file_test(-d, .))]
+ if (has_tail_sep) path - c(path, )
+ paste(path, collapse=collapse)
+ }
+
+ texinputs -
+   function(new=NULL, name=TEXINPUTS)
+ {
+ current - Sys.getenv(name)
+ if (length(new)  0L) {
+ new - normalizePath(new)
+ args - list(unique_path(c(new, current)))
+ names(args) -name
+ do.call(Sys.setenv, args)
+ current - Sys.getenv(name)
+ }
+ invisible(current)
+ }
+
  latex -
  function(..., width=90, short.fignames=FALSE, fig.path,
   error=FALSE, use.unsrturl=TRUE)
  {
  options(..., width=width)
!
! texinputs(new=dirname(.bioconductor.sty))
! cat(\\RequirePackage{Bioconductor}\n\n)

  if (use.unsrturl) {
! bst_path - system.file(package=BiocStyle, resources, latex)
! texinputs(new=bst_path, name=BSTINPUTS)
! cat(\\AtBeginDocument{\\bibliographystyle{unsrturl}}\n)
  }

  setPrefix = function(x) {

You may want to make those function local to latex().  I haven't
verified it works (won't have time), but I bet a beer that it will
work.

/Henrik



 /Henrik


 /Henrik


 Martin



 Just FYI: I use this trick in
 https://github.com/HenrikBengtsson/R.rsp/blob/master/R/compileLaTeX.R
 to set/fix/update TEXINPUTS temporarily, but for somewhat different
 reasons.  There you also see take extra precautions to drop duplicates
 etc.

 /Henrik

 On Mon, Oct 6, 2014 at 3:21 PM, Martin Morgan mtmor...@fhcrc.org wrote:

 On 10/6/2014 2:44 PM, James W. MacDonald wrote:


 Hi Steffen,

 It looks like you are running R as an administrator, rather than as a
 regular user (or you are on something really old like XP). By default R
 should try to create a user-level library directory in your Documents
 folder. It is probably not such a good idea to run R as administrator if
 you are on a more modern version of Windows.

 Note that system.file (which BiocStyle::latex()  calls to find the
 package
 path) will in the case of base packages use .Library to construct the
 path:

 system.file()


 [1] C:/PROGRA~1/R/R-31~1.0/library/base

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[Henrik Bengtsson]

Maybe you could use

\RequirePackage{Bioconductor}

and then set the TEXINPUTS environment variable via Sys.setenv().
Internally tools::texi2dvi() is used that that listens to TEXINPUTS.

Just FYI: I use this trick in
https://github.com/HenrikBengtsson/R.rsp/blob/master/R/compileLaTeX.R
to set/fix/update TEXINPUTS temporarily, but for somewhat different
reasons.  There you also see take extra precautions to drop duplicates
etc.

/Henrik

On Mon, Oct 6, 2014 at 3:21 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 10/6/2014 2:44 PM, James W. MacDonald wrote:

 Hi Steffen,

 It looks like you are running R as an administrator, rather than as a
 regular user (or you are on something really old like XP). By default R
 should try to create a user-level library directory in your Documents
 folder. It is probably not such a good idea to run R as administrator if
 you are on a more modern version of Windows.

 Note that system.file (which BiocStyle::latex()  calls to find the package
 path) will in the case of base packages use .Library to construct the
 path:

 system.file()

 [1] C:/PROGRA~1/R/R-31~1.0/library/base

 Which being an 8.1 path, will work for MikTex. But if I run as an


 It would be great for BiocStyle to return a functional path under all
 circumstances.

 I'm not sure that MikTex handles ~ in paths? or at least not the way
 BiocStyle currently uses this, as

 \RequirePackage{C:/PROGRA~1/R/R-31~1.0/library/BiocStyle/sty/Bioconductor}

 When I try to mock this up it looks like the ~ are being processed as latex
 -- there is a latex file not found error with the ~ replaced by
 \unhbox\voidb@x \penalty \@m \{}.

 I thought there might be some hints with the Sweave sty file use by all
 vignettes. This is found with

 styfile - file.path(R.home(share), texmf, tex, latex,
 Sweave)
 if (.Platform$OS.type == windows)
 styfile - chartr(\\, /, styfile)
 if (length(grep( , styfile)))
 warning(gettextf(path to %s contains spaces,\n,
 sQuote(styfile)),
 gettext(this may cause problems when running LaTeX),
 domain = NA)

 but R.home() (eventually find.package()) uses .Library for the special case
 when the path to a single package from the base distribution is being sought

 find.package(stats)
 [1] C:/PROGRA~1/R/R-31~1.1/library/stats
 find.package(c(stats, stats))[1]
 [1] C:/Program Files/R/R-3.1.1/library/stats

 So I'm not sure how to get at a working path to Bioconductor.sty in the face
 of spaces in the installed path name (the warning hints that R has similar
 problems).


 administrator and put BiocStyle in my Program Files library, I get

 latex()

 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 \AtBeginDocument{\bibliographystyle{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/unsrturl}}

 Which of course will fail. So the best option is to stop running R as an
 administrator, and install packages in your Documents folder in a path
 with
 no spaces.

 Best,

 Jim



 On Mon, Oct 6, 2014 at 4:34 PM, Neumann, Steffen sneum...@ipb-halle.de
 wrote:

 Hi,

 sometimes I am forced to R CMD check packages on windows,
 and my problem is that both the system-wide library and
 the personal library with BiocStyle contain spaces, so that
 BiocStyle::latex() results in:
 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 which causes MiKTeX to fail with
 ! LaTeX Error: File
 `C:/ProgramFiles/R/R-3.1.0/library/BiocStyle/sty/Bioconductor.sty' not
 found.
 (This is with BiocStyles-1.3.15)

 What is the recommended solution here ? Installing R to a non-standard
 location ?
 Use texlive instead of miktex (does that make a difference ?) Or
 something
 else ?

 Yours,
 Steffen





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






 --
 Dr. Martin Morgan, PhD
 Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109


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

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

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[Henrik Bengtsson]

On Mon, Oct 6, 2014 at 5:33 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 10/06/2014 04:52 PM, Henrik Bengtsson wrote:

 Maybe you could use

 \RequirePackage{Bioconductor}

 and then set the TEXINPUTS environment variable via Sys.setenv().
 Internally tools::texi2dvi() is used that that listens to TEXINPUTS.


 Thanks; I think that would require 'us' to run texi2dvi (otherwise the
 environment variable isn't seen by texi2dvi) and that sounds like writing a
 Sweave driver, or worse. latex() could be modified to be passed a flag or
 path indicating a TEXINPUTS directory where bioconductor.sty could be found,
 but that doesn't sound like a robust strategy (e.g., because the
 specially-installed sty file becomes out of sync with the version in the
 package). Hopefully there is a simpler solution.

I haven't tried, but it's possible that if you do
Sys.setenv(TEXINPUTS=...) when the BiocStyle is loaded/attached that
it will stick/survive until the vignette is built.

/Henrik


 Martin



 Just FYI: I use this trick in
 https://github.com/HenrikBengtsson/R.rsp/blob/master/R/compileLaTeX.R
 to set/fix/update TEXINPUTS temporarily, but for somewhat different
 reasons.  There you also see take extra precautions to drop duplicates
 etc.

 /Henrik

 On Mon, Oct 6, 2014 at 3:21 PM, Martin Morgan mtmor...@fhcrc.org wrote:

 On 10/6/2014 2:44 PM, James W. MacDonald wrote:


 Hi Steffen,

 It looks like you are running R as an administrator, rather than as a
 regular user (or you are on something really old like XP). By default R
 should try to create a user-level library directory in your Documents
 folder. It is probably not such a good idea to run R as administrator if
 you are on a more modern version of Windows.

 Note that system.file (which BiocStyle::latex()  calls to find the
 package
 path) will in the case of base packages use .Library to construct the
 path:

 system.file()


 [1] C:/PROGRA~1/R/R-31~1.0/library/base

 Which being an 8.1 path, will work for MikTex. But if I run as an



 It would be great for BiocStyle to return a functional path under all
 circumstances.

 I'm not sure that MikTex handles ~ in paths? or at least not the way
 BiocStyle currently uses this, as


 \RequirePackage{C:/PROGRA~1/R/R-31~1.0/library/BiocStyle/sty/Bioconductor}

 When I try to mock this up it looks like the ~ are being processed as
 latex
 -- there is a latex file not found error with the ~ replaced by
 \unhbox\voidb@x \penalty \@m \{}.

 I thought there might be some hints with the Sweave sty file use by all
 vignettes. This is found with

  styfile - file.path(R.home(share), texmf, tex, latex,
 Sweave)
  if (.Platform$OS.type == windows)
  styfile - chartr(\\, /, styfile)
  if (length(grep( , styfile)))
  warning(gettextf(path to %s contains spaces,\n,
 sQuote(styfile)),
  gettext(this may cause problems when running
 LaTeX),
  domain = NA)

 but R.home() (eventually find.package()) uses .Library for the special
 case
 when the path to a single package from the base distribution is being
 sought

 find.package(stats)

 [1] C:/PROGRA~1/R/R-31~1.1/library/stats

 find.package(c(stats, stats))[1]

 [1] C:/Program Files/R/R-3.1.1/library/stats

 So I'm not sure how to get at a working path to Bioconductor.sty in the
 face
 of spaces in the installed path name (the warning hints that R has
 similar
 problems).


 administrator and put BiocStyle in my Program Files library, I get

 latex()


 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 \AtBeginDocument{\bibliographystyle{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/unsrturl}}

 Which of course will fail. So the best option is to stop running R as an
 administrator, and install packages in your Documents folder in a path
 with
 no spaces.

 Best,

 Jim



 On Mon, Oct 6, 2014 at 4:34 PM, Neumann, Steffen sneum...@ipb-halle.de
 wrote:

 Hi,

 sometimes I am forced to R CMD check packages on windows,
 and my problem is that both the system-wide library and
 the personal library with BiocStyle contain spaces, so that
 BiocStyle::latex() results in:
 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 which causes MiKTeX to fail with
 ! LaTeX Error: File
 `C:/ProgramFiles/R/R-3.1.0/library/BiocStyle/sty/Bioconductor.sty' not
 found.
 (This is with BiocStyles-1.3.15)

 What is the recommended solution here ? Installing R to a non-standard
 location ?
 Use texlive instead of miktex (does that make a difference ?) Or
 something
 else ?

 Yours,
 Steffen





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






 --
 Dr. Martin Morgan, PhD
 Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109


 ___
 Bioc-devel@r-project.org mailing list
 https

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[Henrik Bengtsson]

On Mon, Oct 6, 2014 at 6:48 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
 On Mon, Oct 6, 2014 at 5:33 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 10/06/2014 04:52 PM, Henrik Bengtsson wrote:

 Maybe you could use

 \RequirePackage{Bioconductor}

 and then set the TEXINPUTS environment variable via Sys.setenv().
 Internally tools::texi2dvi() is used that that listens to TEXINPUTS.


 Thanks; I think that would require 'us' to run texi2dvi (otherwise the
 environment variable isn't seen by texi2dvi) and that sounds like writing a
 Sweave driver, or worse. latex() could be modified to be passed a flag or
 path indicating a TEXINPUTS directory where bioconductor.sty could be found,
 but that doesn't sound like a robust strategy (e.g., because the
 specially-installed sty file becomes out of sync with the version in the
 package). Hopefully there is a simpler solution.

 I haven't tried, but it's possible that if you do
 Sys.setenv(TEXINPUTS=...) when the BiocStyle is loaded/attached that
 it will stick/survive until the vignette is built.

It works to set environment variables in either .onLoad() or
.onAttach().  I verified with:

.onLoad - function(libname, pkgname) {
  Sys.setenv(FOO=hello)
}

.onAttach - function(libname, pkgname) {
  Sys.setenv(BAR=world)
}

that both environment variables 'FOO' and 'BAR' are available to the
vignette itself and have their values set as expected.  I've tried
with vignette engines knitr::Rmd and R.rsp::rsp and in both cases the
build and installed vignettes show FOO=hello and BAR=world.

Given that this works, I would be surprised if you cannot set
TEXINPUTS such that texi2dvi() et al. won't see it.

/Henrik


 /Henrik


 Martin



 Just FYI: I use this trick in
 https://github.com/HenrikBengtsson/R.rsp/blob/master/R/compileLaTeX.R
 to set/fix/update TEXINPUTS temporarily, but for somewhat different
 reasons.  There you also see take extra precautions to drop duplicates
 etc.

 /Henrik

 On Mon, Oct 6, 2014 at 3:21 PM, Martin Morgan mtmor...@fhcrc.org wrote:

 On 10/6/2014 2:44 PM, James W. MacDonald wrote:


 Hi Steffen,

 It looks like you are running R as an administrator, rather than as a
 regular user (or you are on something really old like XP). By default R
 should try to create a user-level library directory in your Documents
 folder. It is probably not such a good idea to run R as administrator if
 you are on a more modern version of Windows.

 Note that system.file (which BiocStyle::latex()  calls to find the
 package
 path) will in the case of base packages use .Library to construct the
 path:

 system.file()


 [1] C:/PROGRA~1/R/R-31~1.0/library/base

 Which being an 8.1 path, will work for MikTex. But if I run as an



 It would be great for BiocStyle to return a functional path under all
 circumstances.

 I'm not sure that MikTex handles ~ in paths? or at least not the way
 BiocStyle currently uses this, as


 \RequirePackage{C:/PROGRA~1/R/R-31~1.0/library/BiocStyle/sty/Bioconductor}

 When I try to mock this up it looks like the ~ are being processed as
 latex
 -- there is a latex file not found error with the ~ replaced by
 \unhbox\voidb@x \penalty \@m \{}.

 I thought there might be some hints with the Sweave sty file use by all
 vignettes. This is found with

  styfile - file.path(R.home(share), texmf, tex, latex,
 Sweave)
  if (.Platform$OS.type == windows)
  styfile - chartr(\\, /, styfile)
  if (length(grep( , styfile)))
  warning(gettextf(path to %s contains spaces,\n,
 sQuote(styfile)),
  gettext(this may cause problems when running
 LaTeX),
  domain = NA)

 but R.home() (eventually find.package()) uses .Library for the special
 case
 when the path to a single package from the base distribution is being
 sought

 find.package(stats)

 [1] C:/PROGRA~1/R/R-31~1.1/library/stats

 find.package(c(stats, stats))[1]

 [1] C:/Program Files/R/R-3.1.1/library/stats

 So I'm not sure how to get at a working path to Bioconductor.sty in the
 face
 of spaces in the installed path name (the warning hints that R has
 similar
 problems).


 administrator and put BiocStyle in my Program Files library, I get

 latex()


 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 \AtBeginDocument{\bibliographystyle{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/unsrturl}}

 Which of course will fail. So the best option is to stop running R as an
 administrator, and install packages in your Documents folder in a path
 with
 no spaces.

 Best,

 Jim



 On Mon, Oct 6, 2014 at 4:34 PM, Neumann, Steffen sneum...@ipb-halle.de
 wrote:

 Hi,

 sometimes I am forced to R CMD check packages on windows,
 and my problem is that both the system-wide library and
 the personal library with BiocStyle contain spaces, so that
 BiocStyle::latex() results in:
 \RequirePackage{C:/Program
 Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

 which causes MiKTeX to fail