Re: [R-pkg-devel] Package submission to CRAN not passing incoming checks

[Kasper Daniel Hansen]

1. The version number complaint is the use of 0.1.2-9033. It is complaining
about 9033. Personally, I would not use the - style, but that is a
personal choice I guess. R-exts says
  "The mandatory ‘Version’ field gives the version of the package. This is
a sequence of at least *two* (and usually three) non-negative integers
separated by single ‘.’ or ‘-’ characters. The canonical form is as shown
in the example, and a version such as ‘0.01’ or ‘0.01.0’ will be handled as
if it were ‘0.1-0’. It is *not* a decimal number, so for example 0.9 < 0.75
since 9 < 75."
2. Those are not URLs, they are DOIs. The Rd format has a \doi{} command
you should use
3. If your examples generate files, I would use the tempfile() command from
base R.

On Mon, Apr 22, 2024 at 8:25 PM Petersen, Isaac T <
isaac-t-peter...@uiowa.edu> wrote:

> Dear R-package-devel,
>
> This my first post--I read the posting guidelines, but my apologies in
> advance if I make a mistake.
>
> I am trying to post my R package to CRAN. I just submitted it to CRAN but
> received a note that the package "does not pass the incoming checks
> automatically".
>
> Here are the results from win-builder:
> https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/
>
> As far as I can tell, there are 3 notes to address. However, I'm not sure
> how to address them.
>
> 1) The first note appears to be "Version contains large components", which
> includes the contents of the LICENSE file (CC BY 4.0). I'm not sure if this
> is a problem that needs to be addressed (or how to address it).
>
> 2) The second note says:
>
> "Found the following (possibly) invalid file URIs:
>   URI: 10.1177/0146621613475471
> From: man/itemInformation.Rd
>   URI: 10.1177/0146621613475471
> From: man/standardErrorIRT.Rd"
>
> However, I verified that those DOIs resolve correctly, so I'm not sure how
> to address this note.
>
> 3) The third note (in the Debian but not Windows version) says:
>
> "* checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>   ‘encryptionKey.RData’ ‘encrypytedCredentials.txt’"
>
> These files are generated in the examples for one of the functions to
> demonstrate how to read data using an encryption key:
> https://github.com/DevPsyLab/petersenlab/blob/9ece9d7dc32727c1315a03bc2810cc9c957971d1/R/readEncryptedData.R#L24.
> I'm not sure if this is a problem that needs to be addressed (or how to
> address it).
>
> The source code for my R package (petersenlab) is here:
> https://github.com/DevPsyLab/petersenlab
>
> Thanks very much in advance,
> Isaac
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Kasper Daniel Hansen]

It's a bit late, but I'll point out that the use of R-devel dates back 20y
to the inception of the Bioconductor project. So this is the way it has
always been. Of course, this is an argument of conservatism which is always
dangerous, But at least it illustrates that this is not a small change to
make.

Rig looks pretty sweet. I have been using
  https://rud.is/rswitch/
together with manual installs of snapshots from
  https://mac.r-project.org

Best,
Kasper


On Thu, Apr 18, 2024 at 12:55 AM Anatoly Sorokin  wrote:

> Dear Henrik,
>
> thank you very much for pointing me to the rig project. It works fine and I
> have two independent R versions on my machine at the moment.
>
> Thank you,
> Anatoly
>
> On Tue, Apr 9, 2024 at 4:19 AM Henrik Bengtsson <
> henrik.bengts...@gmail.com>
> wrote:
>
> > > ... 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 <
> > henrik.bengts...@gmail.com> 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 

Re: [Bioc-devel] Check time on macOS (MIRit)

[Kasper Daniel Hansen]

To be a bit more clear and vague at the same time: currently, some of our
macOS builders exhibit weird slowdowns when the build system is run
automatically compared to running builds "by hand". This is pretty weird,
and hopefully we can figure out the cause and fix it. Specifically, builds
on kjohnson3 is (at the moment) weirdly slow.

Best,
Kasper

On Wed, Feb 7, 2024 at 7:24 AM Jacopo Ronchi 
wrote:

> Ok, understood. Thanks
>
> Il mer 7 feb 2024, 12:46 Vincent Carey  ha
> scritto:
>
> > We need a bit of internal discussion before committing to this notion.  I
> > will get back to the list on this.
> >
> > On Wed, Feb 7, 2024 at 6:34 AM Jacopo Ronchi 
> > wrote:
> >
> >> Dear Vincent, thanks for your answer. So, at least for now, can I ignore
> >> the warning on macOS for the submission of MIRit?
> >>
> >> Il mer 7 feb 2024, 12:26 Vincent Carey  ha
> >> scritto:
> >>
> >>> Thanks Jacopo.  You shouldn't have to struggle.  We are aware of
> >>> disparities of platform
> >>> performance and are working to improve the build process.  It will take
> >>> time.  I believe that
> >>> achievement of acceptable timings on the linux platform should be the
> >>> key goal at
> >>> this time.
> >>>
> >>> On Wed, Feb 7, 2024 at 5:18 AM Jacopo Ronchi 
> >>> wrote:
> >>>
>  Dear developers,
> 
>  I am struggling to reduce R CMD check times for my package, MIRit, on
>  macOS. The check on linux takes 4 minutes, while on macOS it needs
> 9/10
>  minutes. I have severely reduced the size of examples and tests, which
>  now
>  use smaller datasets and cached resources.
> 
>  On linux, unit tests require 30 seconds more or less, and examples 40
>  seconds. On the other hand, macOS tests take 100 seconds, and 75 for
> the
>  examples. The issue is that sometimes the check runs in less than 10
>  minutes, sometimes it needs a little bit more.
> 
>  However I am out of ideas on how to further reduce examples and
> tests...
>  The vignette is really extensive, but since SPB uses the
> "--no-vignette"
>  option this should not influence heavily on this behavior, at least to
>  my
>  understanding.
> 
>  Sorry for bothering you,
>  Best regards,
>  Jacopo
> 
>  [[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 the person to whom
> >>> it is
> >>> addressed. If you believe this e-mail was sent to you in error and the
> >>> e-mail
> >>> contains patient information, please contact the Partners Compliance
> HelpLine
> >>> at
> >>> http://www.partners.org/complianceline . If the e-mail was sent to you
> >>> in error
> >>> but does not contain patient information, please contact the sender and
> >>> properly
> >>> dispose of the e-mail.
> >>
> >>
> > The information in this e-mail is intended only for th...{{dropped:16}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] build reports for apple silicon

[Kasper Daniel Hansen]

Oh. That's confusing, but now I at least know what is going on.

On Wed, Jan 24, 2024 at 10:58 AM Kern, Lori 
wrote:

> They are linked off the check result main page:
> https://bioconductor.org/checkResults/
>
> Because we can not run them daily they are not in the main report.
>
>
> 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 Kasper
> Daniel Hansen 
> *Sent:* Wednesday, January 24, 2024 10:54 AM
> *To:* bioc-devel 
> *Subject:* [Bioc-devel] build reports for apple silicon
>
> We're clearly producing binary builds for Apple Silicon. Why do we not have
> a build report for this platform?
>
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/10d-5mk0YI5dQT_fEZqPy7xqkP0rwp9L82EqR7rf2dQY6_1RrnVOKOvPQh7BnKWxTDr_s2sMecRRxcsmmVnizb9OIJYtnlExaP8MKiEsD5oF8Fhk-bU5E1H28OQEtZLp9lr-Mr7o1qi6aHutWx5F1-KoS99i2IK0QDzGC8VHeT_kj5_4BBK1GULkfkSj9Z3P_vIX4XSyFcU7vAn0gLO8Lnu3_JVLuzBeg9RN_dEEAVLiu7qvYNIvo6ojdAZ9mqXbEHIYiPlCRbf0986CwQGjC-TIqqIi0nT_1NG2519M_VJMxu1ZWVnnQzjJE1zf6eP__/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.
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[Bioc-devel] build reports for apple silicon

[Kasper Daniel Hansen]

We're clearly producing binary builds for Apple Silicon. Why do we not have
a build report for this platform?

Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] How to declare optional system requirement for package

[Kasper Daniel Hansen]

To me, whether or not this is a good idea depends a bit on the degree to
which these functions are generally useful.

Best,
Kasper

On Wed, Nov 29, 2023 at 5:41 PM Hervé Pagès 
wrote:

> Hi Alex,
>
> On 11/28/23 22:47, Alex Wong via Bioc-devel wrote:
>
> > Hi there,
> >
> > I am the author of SpliceWiz. My package contains several wrapper
> functions
> > that run the STAR aligner on systems where it is installed. If STAR is
> not
> > found, these functions do nothing other than return a helpful message
> that
> > says STAR is not available. The vast majority of the functions in the
> > package does not depend on STAR, thus STAR is a highly optional
> requirement
> > for my package.
> >
> > What is the best way to convey this in the DESCRIPTION file? Is it
> > acceptable to add the following line?
> >
> >> SystemRequirements: STAR (optional)
>
> That works but it's hard to know what functionality is lost by not
> having STAR on the machine.
>
> Would it make sense to put all the STAR-related stuff in their own
> package and have SpliceWiz suggest that package?
>
> STAR would now be a hard requirement for the package that contains the
> STAR-related stuff.
>
> This kind of separation might help with maintenance and quality control.
> It might also help making things less confusing for the end user.
>
> Best,
>
> H.
>
> > Kind Regards,
> >
> > Alex
> >
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Is my package suitable for Bioconductor?

[Kasper Daniel Hansen]

I am happy to talk on Zoom about this, since I have some interest in this
work.

Best,
Kasper

On Tue, Oct 24, 2023 at 9:21 AM Vincent Carey 
wrote:

> agreedthis discussion is best discussed in the open
>
> On Tue, Oct 24, 2023 at 8:57 AM Lluís Revilla 
> wrote:
>
> > Hi Tim,
> >
> > I think there is a mentorship program for cases like this (I am not sure
> if
> > it still accepts mentees):
> > https://www.bioconductor.org/developers/new-developer-program/
> > I also recommend the book the Bioconductor community wrote to help with
> > submissions: https://contributions.bioconductor.org/index.html
> >
> > Questions are usually posted here, which will not only help you but
> future
> > users/potential contributors with the same doubts/questions.
> > So I would recommend that if the previous resources do not help to just
> > list your questions here for anyone to chime in.
> >
> > If you want more feedback, you  may address the question to someone you
> > know from the community or using the slack to ask some questions are also
> > good options.
> >
> > Looking forward to seeing the package in Bioconductor.
> >
> > I hope this helps,
> >
> > Lluís
> >
> > On Tue, 24 Oct 2023 at 12:46, Timothy Barry 
> > wrote:
> >
> > > Hello,
> > >
> > > My collaborators and I are considering submitting our R package for
> > > single-cell CRISPR screen data analysis to Bioconductor (package
> website
> > <
> > > https://katsevich-lab.github.io/sceptre/> and e-book <
> > > https://timothy-barry.github.io/sceptre-book/>). We have several
> > > questions about the suitability of our package for Bioconductor and
> > changes
> > > that we might need to implement to make our package more consistent
> with
> > > Bioconductor package guidelines. Would a member of the Bioconductor
> team
> > be
> > > available for a brief (30-60 minute) Zoom call to discuss these issues?
> > We
> > > would very much appreciate the help.
> > >
> > > Thank you greatly,
> > > Tim Barry
> > >
> > > Timothy Barry, PhD
> > > University of Pennsylvania
> > > Department of Statistics and Data Science
> > > Postdoctoral researcher
> > >
> > >
> > > [[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
> >
>
> --
> The information in this e-mail is intended only for th...{{dropped:15}}

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

Re: [Bioc-devel] Python module "tensorflow_probability" not found

[Kasper Daniel Hansen]

This sounds excellent Kim!

Here you can get 2.10 for Windows: https://anaconda.org/anaconda/tensorflow
although my experience is that I hate mixing channels on conda. It is also
quite interesting that this conda package also has Windows at an older
version (but just 2.10 vs. 2.12)

This really speaks to a potential need for having basilisk dependencies
being platform specific. This would also come in handy for macOS. But
AFAIK, this is not supported by basilisk currently. Might be something we
need to address.

Best,
Kasper



On Thu, Jul 6, 2023 at 5:38 PM Kim Philipp Jablonski <
kim.philipp.jablon...@gmail.com> wrote:

> Thank you all so much for your input and the references!
>
> @Kasper: I mostly rely on tensorflow and tensorflow-probability, so I might
> somehow get rid of the keras dependency but it would require some work.
>
> After being inspired by the lovely orthos package (thanks Charlotte!), I
> decided to play around further in the basilisk direction and updated my
> project (https://github.com/cbg-ethz/pareg/tree/feature-basilisk).
> The hardest part was figuring out a set of package versions which satisfy
> conda's package manager (@Vincent, I feel you!).
> But then it just magically worked on my local machine.
>
> When testing with GitHub Actions, the windows runner crashes with
> PackagesNotFoundError: The following packages are not available from
> current channels:
>   - tensorflow=2.11.1
> A look at conda-forge (https://anaconda.org/conda-forge/tensorflow)
> reveals
> that for win-64, there's only v1.14.0 available... I guess ignoring the
> windows build is not an option for my bioc package?
>
> For the ubuntu runner, my vignettes were created successfully ("* creating
> vignettes ... OK"). My tests still fail, but that is expected because I
> have not wrapped them with basiliskRun. Do I have to do this manually for
> every function call which may interact with tensorflow (so much
> boilerplate), or can I somehow implicitly use the created conda env for
> every function in my package?
>
> On Thu, Jul 6, 2023 at 2:08 PM Vincent Carey 
> wrote:
>
> > That's great news.  FWIW I am finding that the advice at
> > https://rstudio.github.io/reticulate/articles/python_dependencies.html
> > can work to produce properly resolved python dependencies.  Just don't
> > follow the example literally; the requested
> > scipy version may not exist.  Version 1.11.1 does. Stay tuned.
> >
> > On Thu, Jul 6, 2023 at 7:43 AM Charlotte Soneson <
> > charlottesone...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > in case it's useful: we have a package (orthos) in review (
> > > https://github.com/Bioconductor/Contributions/issues/3042) which uses
> > > basilisk to set up a conda environment with tensorflow and keras. It
> > builds
> > > and runs fine both on GitHub Actions (GitHub repo here:
> > > https://github.com/fmicompbio/orthos) and on the Single Package
> Builder.
> > > We have also tested (locally) that it will use GPUs if available, and
> > that
> > > the GPU configuration can be controlled from the R session (outside of
> > the
> > > package), e.g. by setting the CUDA_VISIBLE_DEVICES environment
> variable.
> > >
> > > Charlotte
> > >
> > > > On 5 Jul 2023, at 23:12, Kasper Daniel Hansen <
> > > kasperdanielhan...@gmail.com> wrote:
> > > >
> > > > So I think Kim is interfacing to tensorflow by using the keras
> package
> > > from
> > > > CRAN (partly authored by the Rstudio people). This package leaves it
> to
> > > the
> > > > user to install tensorflow, which is a highly non-trivial
> installation
> > > > task. There is some partly helpful instructions for using conda
> > together
> > > > with reticulate (see the macOS tab on
> > > > https://tensorflow.rstudio.com/install/local_gpu.html). This is the
> > job
> > > > that basilisk handles for you. In essence, basilisk allows the
> > developer
> > > to
> > > > specify an R-package-specific conda. Tensorflow can be run on a
> CPUor a
> > > > GPU. Getting it to run on a user-GPU is extra complicated and I am
> not
> > > sure
> > > > basilisk can handle this.
> > > >
> > > > Going forward, we (Bioc) want to decide if we want to support keras
> on
> > > our
> > > > build system. This will require some work, because it is definitely
> not
> > > > trivial to get to work (but much more possible if we limit ourselves
> to
> > > > running on CPU).

Re: [Bioc-devel] Python module "tensorflow_probability" not found

[Kasper Daniel Hansen]

So I think Kim is interfacing to tensorflow by using the keras package from
CRAN (partly authored by the Rstudio people). This package leaves it to the
user to install tensorflow, which is a highly non-trivial installation
task. There is some partly helpful instructions for using conda together
with reticulate (see the macOS tab on
https://tensorflow.rstudio.com/install/local_gpu.html). This is the job
that basilisk handles for you. In essence, basilisk allows the developer to
specify an R-package-specific conda. Tensorflow can be run on a CPUor a
GPU. Getting it to run on a user-GPU is extra complicated and I am not sure
basilisk can handle this.

Going forward, we (Bioc) want to decide if we want to support keras on our
build system. This will require some work, because it is definitely not
trivial to get to work (but much more possible if we limit ourselves to
running on CPU). If we decide to support keras, we should try to figure out
how to wrap keras into a basilisk container; perhaps something like
creating a keras-basilisk R package, because IF we decide to support keras,
this is going to be a major headache (to add to the frustration, tensorflow
often rearranges everything so I future issues keeping it operational).

For Kim: I think you should consider if there are any alternatives to
keras. Even if we get it to work on our build system, users will have major
headache getting this to work (I think). If there are no alternatives to
keras, you should perhaps think about doing the keras-basilisk option I
outline above (assuming that is feasible; I don't know how keras interfaces
with tensorflow. You might also have major headaches in your future: I have
found quite big differences in convergence and optimizers over time in TF
and you're basically saying it should work with every version of tensorflow
>= 2.2. That's a  strong promise considering also the difference
between GPU and CPU.

In the meantime, in case the core build team wants some input, I have some
experience with tensorflow, although so far my experience is mostly
frustration.

Best,
Kasper


On Wed, Jul 5, 2023 at 3:12 PM Vincent Carey 
wrote:

> I'll try to get clearer on the basilisk situation; I forked your repo
> and will plunge in soon.
> It may take a while.  In the mean time I hope the BBS python stack can
> be looked at
> to see what the issue might be.  @Jennifer Wokaty is it possible with
> the recent R upgrades that
> tensorflow and tensorflow-probability might need to be installed/updated?
>
> On Wed, Jul 5, 2023 at 3:01 PM Kim Philipp Jablonski
>  wrote:
> >
> > Thanks a lot for your response!
> >
> > The Config/reticulate approach in DESCRIPTION looks very neat. I hope we
> can use it at some point.
> >
> > Could the issue you are facing with the conda install be, that the
> package is called "tensorflow-probability" instead of
> "tensorflow_probability" (
> https://anaconda.org/conda-forge/tensorflow-probability)?
> >
> > I have followed the basilisk advice and incorporated it into my package
> here: https://github.com/cbg-ethz/pareg/tree/feature-basilisk.
> > The basilisk docs say "Any R functions that use Python code should do so
> via basiliskRun()".
> > This does not seem possible in my case as I am using
> tensorflow(probability) wrappers instead of calling them directly.
> > Building the vignettes with Github Actions fails because tensorflow
> could not be found:
> https://github.com/cbg-ethz/pareg/actions/runs/5466980003/jobs/9952690137#step:15:39
> (I might have to activate basilisk somehow, but using basiliskStart seems
> to only make sense with basiliskRun). I could also not find any advice on
> this elsewhere.
> > Do you have a suggestion how to best handle this (or should it *just*
> work)?
> >
> >
> > On Tue, Jul 4, 2023 at 1:04 PM Vincent Carey 
> wrote:
> >>
> >> Sorry to hear about this.  Our informal outlook on python
> >> interoperation in Bioconductor packages is that
> >> the basilisk discipline should be used.  This allows you to pin
> >> specific versions of all python dependencies
> >> and use python for your R functions from an insulated conda environment.
> >>
> >> There is also information about specifying python dependencies in the
> >> DESCRIPTION file at
> >> https://rstudio.github.io/reticulate/articles/python_dependencies.html
> >>  I do not know if our build
> >> system or R CMD install take effective advantage of that approach at
> this time.
> >>
> >> I was surprised to see that my attempt to use reticulate::py_install()
> >> to install tensorflow_probabiliity
> >> on my laptop failed:
> >>
> >> '/home/stvjc/.local/share/r-miniconda/bin/conda' 'install' '--yes'
> >> '--prefix' '/home/stvjc/.local/share/r-miniconda/envs/r-reticulate'
> >> '-c' 'conda-forge' 'tensorflow_probability'
> >> Retrieving notices: ...working... done
> >> Collecting package metadata (current_repodata.json): done
> >> Solving environment: unsuccessful initial attempt using frozen solve.
> >> Retrying with 

Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods

[Kasper Daniel Hansen]

On Sat, Jun 3, 2023 at 11:51 AM Mikael Jagan  wrote:

> The formals of the newly generic 'qr.X' are inherited from the non-generic
> function in the base namespace.  Notably, the inherited default value of
> formal argument 'ncol' relies on lazy evaluation:
>
>  > formals(qr.X)[["ncol"]]
>  if (complete) nrow(R) else min(dim(R))
>
> where 'R' must be defined in the body of any method that might evaluate
> 'ncol'.
>

Perhaps I am misunderstanding something, but I think Mikael's expectations
about the scoping rules of R are wrong.  The enclosing environment of ncol
is where it was _defined_ not where it is _called_ (apologies if I am
messing up the computer science terminology here).

This suggests to me that codetools is right.  But a more extended example
would be useful. Perhaps there is something special with setOldClass()
which I am no aware of.

Also, Bioconductor has 100s of packages with S4 where codetools works well.

Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocManager::install

[Kasper Daniel Hansen]

It seems totally sensible to be able to use BiocManager to install either
bioc-release or bioc-devel at any time, provided you're running R-devel.
First, by definition, R-devel is always >= the R used for release / devel
and Second, it is reasonable to assume users of R-devel to know what they
are doing.

I am unsure if you're arguing for anything else.

Best,
Kasper

On Thu, May 11, 2023 at 10:25 AM Wolfgang Huber 
wrote:

> Hi Kasper
>
> My use case is simple: anyone who works with R-devel and wants to use a
> package on Bioconductor from April to October.
> Many of the 2230 packages in our repository are useful outside of the
> BiocGenerics, IRanges, SummarizedExperiment core world.
> E.g., to name a few, BiocParallel, illuminaio, rhdf5, EBImage, ggtree,
> edgeR, limma, qvalue, sparseMatrixStats, … and I do not think “we” should
> recommend people who want to use these which version of R they must use.
> Btw these examples are all “highly downloaded”.
>
> I fully understand the wish to make people use coherent versions of
> packages and R for situations where lots of interdependent packages,
> classes, methods etc. are imported.
> But sometimes, people just need one or two packages, and then R’s built-in
> dependency management works just fine and the current BiocManager approach
> is needlessly intrusive.
>
> It’s as bad as having made me wonder whether to recommend authors of
> packages that do not directly build upon BiocGenerics, IRanges etc. to
> submit them to CRAN, to increase potential user base (b/c installation from
> Bioconductor can be such a pain). And that’s really not the place I want to
> be.
>
> Thanks and best wishes
> Wolfgang
>
>
>
>
>
> > Il giorno 10.05.2023, alle ore 17:12, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> ha scritto:
> >
> > Could we get a list of use cases from Wolfgang? I am confused about what
> > the issue is. Is the issue that it is painful to work with R-devel in the
> > "off" 6-months? If so, I agree that it should be easier (even if we don't
> > recommend it). But I am having a hard time parsing the email.
> >
> > I can recognize Martin M's wish: a way to run Bioc-release on R-devel;
> that
> > seems sensible to me.
> >
> > Best,
> > Kasper
> >
> > On Tue, May 9, 2023 at 3:46 AM Martin Maechler <
> maech...@stat.math.ethz.ch>
> > wrote:
> >
> >>>>>>> Wolfgang Huber
> >>>>>>>on Sun, 7 May 2023 14:29:37 +0200 writes:
> >>
> >>> Hi Martin As you correctly point out, Bioconductor package
> >>> developers are probably not those with the most relevant
> >>> use cases. I think there are use cases for everyone
> >>> else—anyone who decides to write code on R-devel, for
> >>> whatever reason, and just wants to use a Bioconductor
> >>> package between mid-April to mid-October (they could
> >>> develop for CRAN, or just be a user and write scripts and
> >>> packages for a private project). There are many useful
> >>> packages on Bioconductor that are of general interest,
> >>> even for people whose work does not center around
> >>> Bioconductor or biology (say, ggtree, rhdf5,
> >>> sparseMatrixStats, EBImage, …)
> >>
> >>> I added these ponderings also to
> >>> https://github.com/Bioconductor/pkgrevdocs/issues/108
> >>
> >>> Thanks and best wishes Wolfgang
> >>
> >> As the older ones among you know, I've been a BioC developer
> >> only many years ago ('hexbin' e.g.), but as an R package
> >> maintainer and co-maintainer and R Core team member,
> >> I really like to chime in here, declaring that it *has* been
> >> quite painful for me over the years to test CRAN packages which
> >> depend on BioC packages - with R-devel -- which is my primary R
> >> version for testing, notably also for testing potential changes in R
> >> across many packages, etc.
> >> Notably during this half of the year where there is no
> >> "official" way how to correctly install current Bioconductor packages
> >> (in their own package library, as I always do) under R-devel.
> >>
> >> If I'd be able to sum up the time lost over this issue for the last say
> 10
> >> years, it would add to a full working day at least. ...
> >>
> >> (and I have added a comment also in the above issue #108)
> >>
> >>
> >>> (PS in my particular case yesterday, it was just that my
> >>> R-devel is better maintained (built from so

Re: [Bioc-devel] BiocManager::install

[Kasper Daniel Hansen]

Could we get a list of use cases from Wolfgang? I am confused about what
the issue is. Is the issue that it is painful to work with R-devel in the
"off" 6-months? If so, I agree that it should be easier (even if we don't
recommend it). But I am having a hard time parsing the email.

I can recognize Martin M's wish: a way to run Bioc-release on R-devel; that
seems sensible to me.

Best,
Kasper

On Tue, May 9, 2023 at 3:46 AM Martin Maechler 
wrote:

> > Wolfgang Huber
> > on Sun, 7 May 2023 14:29:37 +0200 writes:
>
> > Hi Martin As you correctly point out, Bioconductor package
> > developers are probably not those with the most relevant
> > use cases. I think there are use cases for everyone
> > else—anyone who decides to write code on R-devel, for
> > whatever reason, and just wants to use a Bioconductor
> > package between mid-April to mid-October (they could
> > develop for CRAN, or just be a user and write scripts and
> > packages for a private project). There are many useful
> > packages on Bioconductor that are of general interest,
> > even for people whose work does not center around
> > Bioconductor or biology (say, ggtree, rhdf5,
> > sparseMatrixStats, EBImage, …)
>
> > I added these ponderings also to
> > https://github.com/Bioconductor/pkgrevdocs/issues/108
>
> > Thanks and best wishes Wolfgang
>
> As the older ones among you know, I've been a BioC developer
> only many years ago ('hexbin' e.g.), but as an R package
> maintainer and co-maintainer and R Core team member,
> I really like to chime in here, declaring that it *has* been
> quite painful for me over the years to test CRAN packages which
> depend on BioC packages - with R-devel -- which is my primary R
> version for testing, notably also for testing potential changes in R
> across many packages, etc.
> Notably during this half of the year where there is no
> "official" way how to correctly install current Bioconductor packages
> (in their own package library, as I always do) under R-devel.
>
> If I'd be able to sum up the time lost over this issue for the last say 10
> years, it would add to a full working day at least. ...
>
> (and I have added a comment also in the above issue #108)
>
>
> > (PS in my particular case yesterday, it was just that my
> > R-devel is better maintained (built from source etc) and
> > has in its library some (non-BioC) packages with complex
> > systems dependencies that I need for a workflow I am
> > working on, packages that currently elude me on my binary
> > installation of R4.3. And then in addition I just wanted
> > to *use* a package from Bioconductor and didn’t like how
> > clumsy that experience was.)
>
> My other experience is that I always have to help people in my
> group to install our pcalg CRAN package because it depends
> e.g. on Bioc packages 'graph' and 'Rgraphviz' .. and on their
> laptops they somehow don't have the correct  getOption("repos")
> or there are other reasons why install.packages('pcalg')
> does not find its Bioc dependencies.
> On our Linux desktop+server environment, I do setup
> options(repos = )
> such that everything works .. but alas, also *not* when in
> R-devel but when you develop a package for CRAN / or only just
> follow the more wide recommendation to also check your package
> with current R-devel, then non-expert package developers need a
> lot of stamina if their package depends (directly or
> recursively) on a Bioc package
> which is really unfortunate and tends to put the Bioconductor
> project in a shady light it really has not deserved at all!
>
> Martin
>
> --
> Martin Maechler
> ETH Zurich  and  R Core team
>
>
>
> >> Il giorno 06.05.2023, alle ore 16:45, Martin Morgan
> >>  ha scritto:
> >>
> >> I opened two issues for further discussion of the
> >> technical aspects.
> >> https://github.com/Bioconductor/BiocManager/issues/165
> >> https://github.com/Bioconductor/pkgrevdocs/issues/108
> >> Just to be clear, as noted at the end of the second issue
> >> and on the web page you mention, a Bioconductor package
> >> developer wishing to use 'Bioc-devel' should, during the
> >> mid-April to mid-October release cycle, be using the
> >> **release** version of R. This combination of R and
> >> Bioconductor is supported by BiocManager. Similarly, in
> >> the mid-October to mid-April release cycle, the
> >> Bioconductor developer should be R-devel, and BoicManager
> >> supports this, too.  There are scenarios where a
> >> developer might wish to combine R-devel and Bioc-devel in
> >> the mid-May, to mid-October time frame, e.g., when
> >> developing a CRAN package with Bioconductor dependencies,
> >> or when conscientiously testing CRAN packages that depend
> >> on Bioconductor packages. One may also just want to be on
> >> the bleeding edge, so using R-devel and 

Re: [Bioc-devel] Changing Maintainer Email Addresses

[Kasper Daniel Hansen]

You should change the maintainer email in the DESCRIPTION file and commit
it to Bioconductor git. Make sure you're subscribed to the devel email list
on the new email.

Best,
Kasper

On Mon, May 1, 2023 at 11:02 AM Augustin Luna  wrote:

> I am currently the maintainer of
>
> https://bioconductor.org/packages/release/bioc/html/paxtoolsr.html
>
> I have been using an email from a previous institute, but it seems I
> am no longer receiving emails through it. I tend to verify my
> institute emails via ORCID as confirmation that they all represent me:
> https://orcid.org/-0001-5709-371X
>
> Now I do not have access to
>
> https://git.bioconductor.org/BiocCredentials
>
> How can I change the email to a current working institute address?
>
> Thank you,
> Augustin Luna
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Question on tasks after successfully building a package

[Kasper Daniel Hansen]

You need to increase your package version number to trigger a new build on
the submission package.

On Tue, Mar 29, 2022 at 7:03 AM Kern, Lori 
wrote:

> You can modify your package at any time.  Please remember to push to
> git.bioconductor.org with any updates and fix any ERROR or Warnings that
> may occur in the newly generated build report.
>
> Cheers,
>
>
> 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 Keita
> Iida 
> Sent: Monday, March 28, 2022 10:54 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Question on tasks after successfully building a
> package
>
> Dear Bioc-devel,
>
> I am Keita Iida from Osaka University, Japan.
> I appreciate your supports for developing our package ASURAT, which is
> under process in Bioconductor issue #2524.
> Our package was successfully built by Bioconductor Single Package Builder
> 24 days ago, and we have been waiting for your next instruction.
> However, I would like to fix some R functions.
> Could you tell me if we can modify our package at any time or is it better
> to wait for your next instruction?
> Many thanks again.
>
> Best regards,
> Keita Iida
>
> --
> Keita Iida, PhD
> Email 1: ki...@protein.osaka-u.ac.jp
> Email 2: kiida1...@med.tohoku.ac.jp
> Email 3: kiida1...@gmail.com
> Tel: (+81) 6-6879-8618 (ext. 8618)
> Fax: (+81) 6-6879-8619
> Institute for Protein Research, Osaka University
> Room612, 3-2 Yamadaoka, Suita, Osaka, 565-0871, JAPAN
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1M2CLk-zav6jsAFfKS0Y2KoBIFOAhfE0D8n4U2kKGg8QQp5xdoFZW2xMVGV0b-qNH4IlntULiHkCAeHwfJxwVQDOu_rSRodz2IKGyftskFPsTEyL7A6tg2entt4Op4hTd5NLnEYOIpUK00M5q8te0GBog1FpMCbI90hVeaK15pLJyMlRMhnCxceB9sVJsleIrDdzmle7BHl82wjUeMtSVtcAc1jYq-FnYhFxn07J841j2WNlVlbmqqXLh6LbKC5JEiFuntzMIX6FOeFUcb_cy5MQ6WjJvdV9VSBF5jwm9ZIpxpEvWJMBacJ6WbhYnwFgV/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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] MAGMA executable

[Kasper Daniel Hansen]

Ignoring the license issues (which may be significant), I strongly dislike
this installation strategy. It (IMO) unreasonable that you potentially
write in system locations on package load. You're looking in
  /usr/local/bin
  R.home/bin <- this makes not sense, this is the R home location, why
should anything else but R be here?
  $HOME
  working directory

In my opinion, if you want to do something like this, you need to do it at
installation time and you should install MAGMA in the package location.



On Thu, Dec 9, 2021 at 8:30 AM Vincent Carey 
wrote:

> I didn't find an obvious licensing statement at the magma site.  I did see
>
> note that standard copyright applies; the MAGMA binaries and source code
> may not be distributed or modified)
>
> the licensing situation would affect my advice on this process, but others
> may have other more
> specific advice
>
> On Thu, Dec 9, 2021 at 7:37 AM Brian Schilder <
> brian_schil...@alumni.brown.edu> wrote:
>
> > Hi everyone,
> >
> > I’m a developer for the R package MAGMA.Celltyping <
> > https://github.com/neurogenomics/MAGMA_Celltyping/tree/bschilder_dev>
> (on
> > the bschilder_dev branch). It’s currently only distributed via GitHub but
> > I’m trying to get it on Bioc if possible. The dilemma is, it relies on
> > MAGMA , which is only available as a
> > CLI program.
> >
> > I have everything passing CRAN/Bioc checks on my local machine, but the
> > final hurdle is installing MAGMA  on
> > other machines (e.g. via GitHub Actions checks) such that it can be
> called
> > from within R.
> >
> > Here’s the steps I’ve taken:
> > Upon .onLoad <
> >
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/zzz.R
> >
> > of MAGMA.Celltyping, magma_installed_version() <
> >
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_installed_version.R
> >
> > will check whether MAGMA is installed. If not, it proceeds to try and
> > install it via magma_install() <
> >
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_install.R
> >
> > .
> > magma_install() finds the latest version of MAGMA in their archives <
> > https://ctg.cncr.nl/software/MAGMA/prog/>, installs it wherever the user
> > has permissions (from a list of possible installation locations <
> >
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/find_install_dir.R
> >),
> > and sets up the symlink.
> > Checks that MAGMA is indeed installed and callable from within R using
> > functions like system(“magma ….”).
> > This all seems to work fine locally, but when I launch to GitHub actions,
> > MAGMA.Celltyping can’t seems to install/find MAGMA. it doesn’t seem to be
> > able to find it.
> >
> > Does anyone know of any solutions to this that are Bioc (or at least
> CRAN)
> > -compatible?
> >
> > Many thanks in advance,
> > Brian
> > ___
> > Brian Schilder
> > PhD Candidate
> > UK Dementia Research Institute at Imperial College London
> > Faculty of Medicine, Department of Brain Sciences, Neurogenomics Lab
> > Profile | bit.ly/imperial_profile 
> > LinkedIn | linkedin.com/in/brian-schilder <
> > https://www.linkedin.com/in/brian-schilder/>
> > Twitter | twitter.com/BMSchilder 
> > Lab | neurogenomics.co.uk 
> > UK DRI | www.ukdri.ac.uk 
> > [[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:15}}

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

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

[Kasper Daniel Hansen]

Martin's suggestion is the way to go. For display purposes, you basically
never want random colors, you almost always want to select distinct colors
and there are principled ways of doing that.

Best,
Kasper

On Tue, Nov 30, 2021 at 6:59 AM Martin Morgan 
wrote:

> Check out grDevices::hcl.pals (also
> https://www.zeileis.org/papers/Zeileis+Hornik+Murrell-2009.pdf) or the
> RColorBrewer package (also https://colorbrewer2.org) for principled
> selection of colors. Sounds like you're interested in 'qualitative' color
> palletes.
>
> Martin Morgan
>
> On 11/29/21, 4:23 PM, "Bioc-devel on behalf of Meng Chen" <
> bioc-devel-boun...@r-project.org on behalf of mengche...@gmail.com> 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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] bpparam Non-deterministic Default

[Kasper Daniel Hansen]

This should be solved by the vignette appropriately calling set.seed and
explaining why they set the seed and why it is not done automatically. In a
visible code chunk.

On Sat, Nov 27, 2021 at 7:31 AM Spencer Nystrom 
wrote:

> This GitHub issue, although lengthy, discusses some of the technical
> difficulties associated with pulling from the random stream. I've linked to
> a comment from Martin that discusses this in particular, but there's other
> good stuff in the rest of the issue.
>
>
> https://github.com/Bioconductor/BiocParallel/pull/140#issuecomment-921627153
>
>-Spencer
>
>
> On Fri, Nov 26, 2021, 10:41 PM Ellis Patrick 
> wrote:
>
> > Hi All,
> >
> > Sorry I'm not an advanced user. What is the disadvantage of pulling the
> > default from .Random.seed? As a non-advanced user it took me way too long
> > to figure out that set.seed() doesn't work.
> >
> > Thanks,
> > Ellis
> >
> > -Original Message-
> > From: Bioc-devel  On Behalf Of Spencer
> > Nystrom
> > Sent: Saturday, 27 November 2021 2:15 PM
> > To: Dario Strbenac 
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] bpparam Non-deterministic Default
> >
> > I agree with Martin. I think it is worse for beginners to falsely believe
> > their results are deterministic when they are not. This sounds like a
> > problem that should be solved with documentation and maybe even examples
> of
> > setting the RNG seed manually.
> >
> > I also worry about advanced users and pollution of RNG seed global state
> > by having packages assign their own seed. Just sounds like a mess for
> > little gain.
> >
> >   -Spencer
> >
> >
> > On Fri, Nov 26, 2021, 7:00 PM Dario Strbenac via Bioc-devel <
> > bioc-devel@r-project.org> wrote:
> >
> > > Hello,
> > >
> > > Might it instead made possible to set an RNGseed value by specifying
> > > one to bpparam but still get the automated back-end selection, so that
> > > it could easily be set to a particular value in an R package?
> > >
> > > --
> > > Dario Strbenac
> > > University of Sydney
> > > Camperdown NSW 2050
> > > Australia
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel.
> > > ethz.ch
> > >
> >
> > [[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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Issue with change in random sampling

[Kasper Daniel Hansen]

The random number generator is tracked by a global state, which is a
violation of functional programming. This is unavoidable. This is why we
really don't want packages to EVER touch the random number state for
example by setting the seed. You can also be affected by this if any
function you depend on decides to add a call to the random number generator.

For the example you describe here, a more robust approach would be to call
set.seed() just prior to calling sample().

While different, I have been bitten by these kinds of test failures when
packages I depend upon have decided to change certain numerical routines.
In theory, I think that's a good feature since it alerts the developer who
can make a decision whether the dependency should change (I have once
dropped a package from a dependency list because of this). In practice
however, such tests can become EXTREMELY irritating when you get a failure
out of the blue without any idea why. I don't have any good solutions to
this.

In this case, I think Martin alerted the community to the changes, it is
just easy to miss. A potential improved mechanism would be to have the
option to have "message-of-the-day" attached to build reports to alert
developers to possible changes. This could include messages such as "we
know windows is failing right now because we are maintaining the build
servers". If anyone entertains this, we would want the ability to update
the message in real time and not just when the build system runs. It might
not be too hard to just have a link to common text file though.

Best,
Kasper


On Fri, Sep 24, 2021 at 2:16 PM Martin Morgan 
wrote:

> This does sound like a BiocParallel side effect, and I would suggest
> holding off for another week so for the BiocParallel changes to be
> finalized.
> On 9/24/21, 2:05 PM, "Bioc-devel" 
> wrote:
>
> Hello,
>
> My package `clusterExperiment` has not changed but is hitting errors on the
> devel branch. I’ve pinpointed it to the fact that a small dataset I am
> running the tests on is randomly subsetted from a larger subset and is no
> longer choosing the same observations. I have already in previous version
> corrected the tests for the change in random number generation in R.4.0.x.
> I am wondering if it is related to the changes in BiocParallel (
>
> https://community-bioc.slack.com/archives/CEQ04GKEC/p1631903391030800?thread_ts=1631881095.027600=CEQ04GKEC
> <
>
> https://community-bioc.slack.com/archives/CEQ04GKEC/p1631903391030800?thread_ts=1631881095.027600=CEQ04GKEC
> >
> ).
>
> It was unexpected for me that this would affect these results. My package
> doesn’t use BiocParallel or depend on it. But it turns out the code in
> question does make a call to BiocSingular to run a PCA, and BiocSingular
> does make calls to BiocParallel. What is strange to me is that even if I
> don’t directly use the results of runPCA, but simply make the call to
> runPCA before running the code in question, the output of that code is
> changed. So this seems to me to indicate that the sequence of random
> numbers is being globally affected by the change, and not just internally
> to the results of calls to BiocParallel. I didn’t realize this was the case
> from the above discussion — I thought it would only affect output that
> directly relied on calls to BiocParallel — and I was hoping someone could
> confirm that this is what is happening and/or give me explicit way to check
> this is the source of my errors.
>
> Here’s the basic setup. I have a setup file that sets up a lot of objects
> for my tests (setup_create_objects.R). The relevant parts look something
> like this (I’ve simplified it from what’s actually in the file so it more
> clearly shows the progression):
>
> data(simData)
> suppressWarnings(RNGversion("3.5.0"))
> set.seed(23)
>
> … # bunch of code
>
> clusterIds<- … # code that internally calls BiocSingular::runPCA
>
> … # bunch of code
>
> ### sample 3 observations from each cluster:
>
> whSamp<-unlist(tapply(1:ncol(simData),clusterIds,function(x){sample(x=x,size=3)}))
> smSimData<-simData[1:20,whSamp]
>
> This results in different values of clusterIds and thus different whSamp on
> the release and the devel version.
>
> The unexpected part was even if I add a line that manually overwrites
> clusterIds to be the values of the vector `clusterIds` from the release
> version (copied manually from running on a different computer that is not
> the devel version) I don’t get the same result of whSamp (I still run the
> code for `clusterIds`, so BiocSingular::runPCA is still being called). If,
> however, when I manually feed the correct clusterIds on the devel version,
> I ALSO put in a new call to `set.seed` in the line before calling whSamp
> then both the devel and the release version give the same result, as I
> would expect. This makes me think that that the random seed has been
> affected globally. Further, the second entry of .Random.seed is not the
> same after running setup_create_objects.R on the 

[Bioc-devel] lessons learned: negative experiences with git log

[Kasper Daniel Hansen]

Here are my experiences as a novice in git.

Yesterday I was working on fixing a condition length error in Rgraphviz, a
package which has not been touched in years. After I fixed this, I got a
segmentation fault in examples / tests / vignettes; all over the place.

This could have been related to a small git snafu I had on my laptop
because I had not synchronized  laptop / Github / bioc git for a _long_
time (read: years).

No matter, I thought, git history will easily reveal this, and since there
has been no changes to the package in years, it should be really easy to
just list which file had changed. However, running
  git log --name-status
I got this

 START git log ==
commit 955e30b3ae316265b4f5f130ab6f12c33081da54
Author: Kasper Daniel Hansen 
Date:   Wed Aug 11 08:52:11 2021 -0400

Fixing length condition error

:100644 100644 25e24de 3aee690 MDESCRIPTION
:100644 100644 f8e077f b73b052 Mman/agopenSimple.Rd

commit 15204d879d974de8d40b0342b2f853c88f4bf9a3
Merge: 7c1433d b01ad95
Author: Kasper Daniel Hansen 
Date:   Wed Aug 11 08:26:09 2021 -0400

Merge remote-tracking branch 'upstream/master'

commit b01ad9552737978b3b7db6815323a078ceafe041
Author: Nitesh Turaga 
Date:   Wed May 19 15:33:11 2021 +

bump x.y.z version to odd y following creation of RELEASE_3_13 branch

:100644 100644 78243eb 25e24de MDESCRIPTION
== END git log ==

This suggests that no files apart from DESCRIPTION and a man page were
touched recently (it looks the same if I go back longer). Look at the
second message with "Merge remote-tracking". No files are listed!

It turns out that files were indeed touched as part of the "Merge
remote-tracking ..." commit. I can see this by a
  git diff b01ad9552737978b3b7db6815323a078ceafe041
but in reality I had given up on git and did a standard recursive diff on
the stable release tarball and my codebase.

I have not been able to figure out what options I need to give git log to
display which files changed as part of that commit, and I find that
perplexing and -- frankly -- pretty worrying.

Anyway, just some scary lessons on git log and merge.

Best

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocCheck and version requirement

[Kasper Daniel Hansen]

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.

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
> >
> > 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  bioc-devel-boun...@r-project.org>> on behalf of Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com<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
> >
> >

Re: [Bioc-devel] BiocCheck and version requirement

[Kasper Daniel Hansen]

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 
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  on behalf of Kasper
> Daniel Hansen 
> *Sent:* Thursday, April 8, 2021 9:44 AM
> *To:* bioc-devel 
> *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 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.



-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Suppressing messages from Rprofile

[Kasper Daniel Hansen]

You could also preprend your cat so it outputs something like
  INCLUDE_DIR=..
and then use grep and sed to trim it. Of course that can also end up being
brittle.

On Wed, Apr 7, 2021 at 10:48 PM Henrik Bengtsson 
wrote:

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


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[Bioc-devel] BiocCheck and version requirement

[Kasper Daniel Hansen]

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://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] custom allocators, Valgrind and uninitialized memory

[Kasper Daniel Hansen]

On Tue, Mar 30, 2021 at 9:39 AM Tomas Kalibera 
wrote:



> appropriate to tell valgrind about it. As this is becoming rather too
> technical and specific to the internals, feel free to take this offline
> with Simon and me.
>

Respectfully, this seems to me to be exactly the kind of exchange R-devel
is meant for.
-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Moving minfi classes definition to a lighter package

[Kasper Daniel Hansen]

I am happy to engage in a discussion about this, although I'm not sure that
I am ultimately interested in having two packages.

But first I would like to look at some dependency graphs. I am wondering
what makes the dependency tree this big (and my tree is smaller than yours,
but still big: library(minfi) gives me 16 attached packages and 89 loaded
packages for the current release). This includes some part of the tidyverse
which we don't really use much though (and which could probably get removed
from the package with almost no work).

What's the current best tool for dependency graphs in Bioconductor?
pkgDepTools?

Best,
Kasper

On Mon, Mar 1, 2021 at 6:24 PM Carlos Ruiz  wrote:

> Dear Bioc developers,
>
> I have been developing different packages to analyze DNA methylation. In
> all of them, I have used minfi's class GenomicRatioSet to manage DNA
> methylation data, in order to take profit of the features of
> RangedSummarizedExperiment.
>
> Although I am very happy with the potential of the class, importing its
> definition from minfi, makes me add the package to imports. As minfi has a
> high number of dependencies (129 in the current release), my packages end
> up having hundreds of dependencies too. This is particularly problematic as
> I do not use any of the other functions of minfi.
>
> I am wondering whether it could be possible to move minfi's class (or at
> least GenomicRatioSet) to a lighter package, so people developing packages
> on DNA methylation could rely on this class without having to import the
> whole minfi package and its dependencies.
>
> Thank you very much,
> --
>
> Carlos Ruiz
>
> --
>
>
> This message is intended exclusively for its addressee and may contain
> information that is CONFIDENTIAL and protected by professional privilege.
> If
> you are not the intended recipient you are hereby notified that any
> dissemination, copy or disclosure of this communication is strictly
> prohibited
> by law. If this message has been received in error, please
> immediately notify
> us via e-mail and delete it.
>
>
>
> DATA PROTECTION. We
> inform you that your personal data, including your
> e-mail address and data
> included in your email correspondence, are included in
> the ISGlobal
> Foundation files. Your personal data will be used for the purpose
> of
> contacting you and sending information on the activities of the above
> foundations. You can exercise your rights of access, rectification,
> cancellation and opposition by contacting the following address:
> l...@isglobal.org . ISGlobal
> Privacy Policy at
> www.isglobal.org .
>
>
>
>
> -
>
> CONFIDENCIALIDAD. Este mensaje y sus anexos se dirigen exclusivamente a
> su
> destinatario y puede contener información confidencial, por lo que la
> utilización,
> divulgación y/o copia sin autorización está prohibida por la
> legislación
> vigente. Si ha recibido este mensaje por error, le rogamos lo
> comunique
> inmediatamente por esta misma vía y proceda a su destrucción.
>
>
>
>
>
>
>
>
>
> PROTECCIÓN DE DATOS. Sus datos de carácter personal utilizados en este
> envío, incluida su dirección de e-mail, forman parte de ficheros de
> titularidad
> de la Fundación ISGlobal  para cualquier
> finalidades de
> contacto, relación institucional y/o envío de información sobre
> sus
> actividades. Los datos que usted nos pueda facilitar contestando este
> correo quedarán incorporados en los correspondientes ficheros, autorizando
> el
> uso de su dirección de e-mail para las finalidades citadas. Puede
> ejercer los
> derechos de acceso, rectificación, cancelación y oposición
> dirigiéndose a l...@isglobal.org * *. Política
> de
> privacidad
> en www.isglobal.org .
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] How to integrate code from a package not available on bioconductor

[Kasper Daniel Hansen]

This question is actually pretty complicated and involves matters of
copyright and academic credit, which are two different things. In general
you cannot take code from the internet and republish it under your own name.

It sounds like you want to include something substantial (as opposed to say
a minor convenience function), making these matters even more important.

Copyright/license-wise: the package is released under GPL (see License
field in the DESCRIPTION) which is somewhat unspecific, but possible to
work with (these days there are numbered versions of the GPL). You might
want to read up on what this means (and there will be different
interpretations because there have been zero-to-few court cases
establishing the interpretation of the GPL). Whatever license the package
operates under, you can almost always get an exception from the authors to
do something else, so if you contact the authors and work something out you
don't need to know the details. So to be specific
  - if you copy code from the github repository you're bound by the
requirements of the license (which may prohibit this)
  - if you contact the authors they can agree to whatever they want to
(assuming they hold copyright)

Some people strongly advocate that when you do this, you add the authors of
the old code to your package, which you certainly can't do without talking
with them.

It is entirely possible that the authors are unresponsive or will be making
requirements you don't want to fulfil, in which case you can't do what you
propose.

Best,
Kasper



On Wed, Feb 10, 2021 at 6:59 PM Ana Carolina Leote <
anacarolinale...@gmail.com> wrote:

> This is the repository: https://github.com/Vivianstats/scImpute
>
> *Ana Carolina Leote*
> *MSc. Biological Engineering*
> *PhD student at the Cologne Graduate School for Ageing Research*
> *Cellular networks and systems biology (Beyer group), **CECAD Research
> Center*
> https://www.linkedin.com/in/anacarolinaleote/
>
>
> On Wed, Feb 10, 2021 at 6:44 PM Vincent Carey 
> wrote:
>
> > It is wise to be careful here.  If we don't know the provenance of the
> > code in github it might actually be someone else's.
> > It reminds me of the Numerical Recipes events, in which folks
> > redistributed proprietary code without permission.
> > What repo are we talking about anyway?
> >
> > On Wed, Feb 10, 2021 at 12:38 PM Martin Morgan 
> > wrote:
> >
> >> I don’t know what the legal requirement is.
> >>
> >> As a human if I hadn’t given explicit consent I’d like to be asked. And
> >> if I had used someone else’s code I’d like it to be transparent that my
> use
> >> was legitimate, and a private exchange of email between me and the other
> >> individual consenting to use their code wouldn’t be transparent enough.
> >> Hopefully I’m not being hypocritical here.
> >>
> >> Martin
> >>
> >> From: Ana Carolina Leote 
> >> Date: Wednesday, February 10, 2021 at 10:24 AM
> >> To: "Kern, Lori" 
> >> Cc: Martin Morgan , Wolfgang Huber <
> >> wolfgang.hu...@embl.org>, "bioc-devel@r-project.org" <
> >> bioc-devel@r-project.org>
> >> Subject: Re: [Bioc-devel] How to integrate code from a package not
> >> available on bioconductor
> >>
> >> My motivation to include this package is that my own package includes,
> >> but is not limited to, an ensemble of different packages that attempt to
> >> solve the same problem, besides my own solution, since I did some work
> >> showing they all have their pros and cons. At the moment my package does
> >> not include this one, because of all the problems here raised, but
> since it
> >> is arguably more popular than all other "alternative" packages, I felt I
> >> should include it. This is why using an alternative package
> unfortunately
> >> does not solve my problem. I also looked in the page Lori shared but
> this
> >> package is not there. However you do raise very valid points. I think I
> >> need to weigh the cost of changing the code against the additional
> >> usefulness my package can gain more carefully than I did so far.
> >>
> >> I do have one additional question, though. Martin mentioned the license
> >> compatibility. There is no license at all in the GitHub repository of
> this
> >> package. I did some searching but I'm not sure what the default GitHub
> >> copyright means for bioconductor distribution. Does it mean I am not
> >> allowed to include this code in case I do wish to go forward with taking
> >> the code "as is"?
> >>
> >> Thanks again for all your helpful responses. It's great as a new
> >> developer to have such support.
> >>
> >> Best,
> >> Carolina
> >>
> >> Ana Carolina Leote
> >> MSc. Biological Engineering
> >> PhD student at the Cologne Graduate School for Ageing Research
> >> Cellular networks and systems biology (Beyer group), CECAD Research
> Center
> >> https://www.linkedin.com/in/anacarolinaleote/
> >>
> >>
> >> On Wed, Feb 10, 2021 at 3:50 PM Kern, Lori <
> lori.sheph...@roswellpark.org
> >> > wrote:
> 

Re: [Bioc-devel] Compiling a cpp source code while installing package

[Kasper Daniel Hansen]

Alexandra,

What you're proposing is possible, but it is definitely a non-trivial task,
because you (as the package author) are now responsible for getting MAGMA
compiled on Linux / Windows and OS X. If MAGMA is not designed as a
library, that might be hard. Not impossible but hard.

Best,
Kasper

On Sun, Nov 8, 2020 at 2:33 PM Martin Morgan 
wrote:

> At the link
>
>   https://ctg.cncr.nl/software/magma
>
> it says " The MAGMA source code can also be downloaded below, which can be
> used to compile the program on the target system if this is not supported
> by the provided binaries (note that standard copyright applies; the MAGMA
> binaries and source code may not be distributed or modified)."
>
> So it sounds like you are not able to do what you want anyway?
>
> Generally, I do not think bundling large software projects that are not
> specifically designed as libraries is a good strategy for R / Bioconductor.
> And while you might ask us to install the software on our build systems so
> that your package can use the program, I'd offer up the cost of doing that,
> both for us and for your potential users --  perhaps a better strategy is
> simply to offer your package to the MAGMA maintainers as an improvement to
> the R scripts they already provide and distribute from the link above?
>
> Martin
>
> On 11/8/20, 7:40 AM, "Bioc-devel on behalf of Alexandru Voda" <
> bioc-devel-boun...@r-project.org on behalf of alexandru.v...@seh.ox.ac.uk>
> wrote:
>
> Thanks for the reply, Martin!
>
> Unfortunately, the C++ software is large (
> https://ctg.cncr.nl/software/magma), not just some feature that can be
> used from R base, CRAN or Bioconductor.
>
> Also, I wouldn't make a separate library for the C++ software because
> the *main* purpose of my package is to wrap them up for R. Other functions
> are just a secondary aim of the package.
>
> Thank you for the recommended packages! I was wondering if there's any
> standard guidance/vignette for how Rhtslib & Rhdf5lib approached this?
> There are numerous Rcpp vignettes that I could find, but couldn't find for
> pure C compiled by R?
> 
> From: Martin Morgan 
> Sent: Saturday, November 7, 2020 3:30 PM
> To: Alexandru Voda ;
> bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Compiling a cpp source code while installing
> package
>
> It would probably help to provide additional detail here; there are
> several examples of packages that build C / C++ libraries from source, a
> common pattern is to have a package dedicated to providing the library,
> e.g., Rhtslib or Rhdf5lib, or of building the library as part of the
> software package itself.
>
> It's worth assessing whether the functionality is worth it (e.g., why
> use a random number generator from another package, when one can use the R
> random number generator) or already implemented (e.g., linear algebra in
> RcppArmadillo).
>
> Martin
>
> On 11/7/20, 10:25 AM, "Bioc-devel on behalf of Alexandru Voda" <
> bioc-devel-boun...@r-project.org on behalf of alexandru.v...@seh.ox.ac.uk>
> wrote:
>
> Hi! I tried to look this up in the FAQ & best practices but
> couldn't find it.
>
> My in-the-works package needs to call a legacy C++ software from
> time to time.
>
> Since that C++ software is open-source, is there a way to make my
> package compile the source (during R package installation) I'm going to
> include? That'd make my package's dependency localized and well-controlled,
> but any other alternative is welcome (except Rcpp, which would take too
> many months to rewrite into the legacy C++ software).
>
> Best wishes,
> Alexandru
>
>  [[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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocManager and R-devel

[Kasper Daniel Hansen]

Im happy to hear this has been addressed in git.


On Fri, Oct 30, 2020 at 12:22 PM Martin Morgan 
wrote:

> Thanks; the version of BiocManager in git has
>
> > library(BiocManager)
> Bioconductor version '3.11' is out-of-date; the current release version
> '3.12'
>   is available with R version '4.0'; see https://bioconductor.org/install
>
> and will be released in the next month. The rationale for telling you
> about the current release version rather than how to make 'devel' work is
> that BiocManager is a user-oriented rather than developer convenience.
>
> If you'd then tried to update to devel
>
> > BiocManager::install(version="devel")
> Upgrade 3 packages to Bioconductor version '3.13'? [y/n]:
>
> you'd have been set.
>
> The BiocManager vignette describes what is going on -- a 'sentinel'
> package BiocVersion is carried over from your previous library. It's
> necessary to distinguish between Bioconductor versions during the parts of
> the release cycle when two versions of Bioconductor are compatible with a
> single version of R. Addressing the symptom is to remove the BiocVersion
> package. I'd recommend the one-library-one-Bioconductor version approach to
> for managing multiple versions outlined in the vignette. Your solution
> means that you cannot switch back to your previously working version, which
> might have been important for reproducibility or sanity.
>
> Martin
>
> On 10/30/20, 4:45 AM, "Bioc-devel on behalf of Kasper Daniel Hansen" <
> bioc-devel-boun...@r-project.org on behalf of kasperdanielhan...@gmail.com>
> wrote:
>
> Installed R-devel as of today. I have a previous version of
> Bioconductor
> installed in site-library. I then do
>   install.packages("BiocManager")
> # installs version 1.30.10
>
> > library(BiocManager)
> Bioconductor version '3.11' is out-of-date; the current release version
> '3.12'
>   is available with R version '4.0'; see
> https://bioconductor.org/install
>
> I would have expected a message about devel version 3.13. I cannot run
>   BiocManager::install(useDevel = TRUE)
> as it complains about needing R 4.0 for Bioc 3.11. So it detects my
> current
> version of Bioc (3.11) and refuses to run install since it thinks
> there is
> a version mismatch.
>
> I then deleted everything in site-library, installed BiocManager and
> everything works as expected (giving me Bioc version 3.13)
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[Rd] bug report for make check

[Kasper Daniel Hansen]

I would like to request access to bugzilla to file a bug report on make
check for R-devel.

Following changes to all.equal.POSIXt,
  make check
now reports an error if the environment variable TZ is set to
  TZ="US/Eastern"
(and likely other values). This can be addressed by using the argument
check.tzone=FALSE in the call to all.equal.POSIXt in reg-tests-2.R. A patch
has been posted by Sebastian Meyer in the R-devel thread "timezone tests
and R-devel".

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

On Fri, Oct 23, 2020 at 11:10 AM Sebastian Meyer  wrote:

> Yes, you are absolutely right and I'm pretty sure this will be fixed in
> one way or another.
>
> IMO, the failing test should simply use all.equal.POSIXt's new argument
> check.tzone=FALSE.
>

I agree that this is a simple fix and I am wondering why it hasn't been
implemented. I will request access to bugzilla so I can file a bug report.

Best,
Kasper

[[alternative HTML version deleted]]

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

[Bioc-devel] BiocManager and R-devel

[Kasper Daniel Hansen]

Installed R-devel as of today. I have a previous version of Bioconductor
installed in site-library. I then do
  install.packages("BiocManager")
# installs version 1.30.10

> library(BiocManager)
Bioconductor version '3.11' is out-of-date; the current release version
'3.12'
  is available with R version '4.0'; see https://bioconductor.org/install

I would have expected a message about devel version 3.13. I cannot run
  BiocManager::install(useDevel = TRUE)
as it complains about needing R 4.0 for Bioc 3.11. So it detects my current
version of Bioc (3.11) and refuses to run install since it thinks there is
a version mismatch.

I then deleted everything in site-library, installed BiocManager and
everything works as expected (giving me Bioc version 3.13)

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Package update before october 23rd deadline and build errors [duplicated, wrong email address previous]

[Kasper Daniel Hansen]

Giula,

Provided your package has been accepted by a reviewer, it will be released
as part of Bioconductor 3.12, as long as it satisfies the other
requirements, which includes some deadlines for when it is supposed to pass
check without errors.

In general, around release, there are a lot of changes to a lot of
packages. When you get an error from the build system, I suggest looking
closely at the error and also see if other packages are affected.
Unfortunately, sometimes things break on the build system which leads to
100s or 1000s of packages failing at the same time. For this reason, it is
sometimes useful to look at the Dashboard:
  http://www.bioconductor.org/dashboard/
Today you can see ~20 packages failing build, ~70 failing installation and
~70 failing check (rough numbers across platforms). Nothing seems to be
amiss with windows.

Today you have a warning on one windows platform which suggests there is
something wrong with IRanges on that platform,

If you see occasional failures (errors), there could be many reasons
including internet access, memory overflow and failure to write to disk.
Its hard to know what you're suffering from without knowing your package.

On Sun, Oct 25, 2020 at 9:57 PM Giulia Pais  wrote:

> Hello,
>
> we keep getting weird warning messages for check on windows, it's also
> even more odd since we got yesterday a build report with no errors or
> warnings but the build report for today gives an error on Windows Server
> 2012 R2 Standard / x64 only. We can't understand what the warning is,
> why does it happen only for tests and also why it doesn't happen
> consistently (same lines of codes are run in examples in the
> documentation).
>
> Could you give us further insight on the meaning of this warning? We are
> not able to reproduce it.
>
> Also will our package be released for bioconductor 3.12?
>
> Thank you
>
> Il 21/10/2020 19:08, Pages, Herve ha scritto:
> > Hi Giulia,
> >
> > Today's report is available. Unfortunately ISAnalytics tests are still
> > failing on Windows:
> >
> >
> >
> https://bioconductor.org/checkResults/devel/bioc-LATEST/ISAnalytics/tokay1-checksrc.html
> >
> > Note that you have this warning at the beginning of the tests:
> >
> > > test_check("ISAnalytics")
> > Warning message:
> > In file(file, "rt") :
> >   file("") only supports open = "w+" and open = "w+b": using the
> former
> >
> > Maybe it's relevant?
> >
> > In any case, that warning should not be ignored as it is most likely
> > reporting a real problem.
> >
> > Best,
> > H.
> >
> >
> > On 10/21/20 02:58, Giulia Pais wrote:
> >> Hello, bioconductor team,
> >>
> >> I'm one of the contributors for the package ISAnalytics. We pushed some
> >> changes we would like to be included in the release for bioconductor
> >> 3.12 a couple of days ago but the build report still refers to the older
> >> version, did we miss the deadline for updates or is it normal? Moreover,
> >> by taking a look at the build report for the older version we noticed it
> >> had failed on Windows, which is to us very odd, since we develop and
> >> check the package on windows locally and we also have github automated
> >> actions that perform the same checks on other machines and there were no
> >> errors or warnings. From what we can see from the report it seems a
> >> BiocParallel problem, could you give us feedback on this please? The
> >> link to the build report:
> >>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ISAnalytics_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=CHJeB1qsdWS04WzhReQyXwYrMCo0ZFIzgm8KFXf0dSU=gGAt_tpoNlVhB63K8IusN9oxHe9SQzGi6T3Drsx4jxU=
> >>
> >> Thank you in advance,
> >>
> >> Giulia Pais
> >>
> >> ___
> >> 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=CHJeB1qsdWS04WzhReQyXwYrMCo0ZFIzgm8KFXf0dSU=9yNBZH8vQVM9oEPd9kEepBSAQH0XcokumxvYXW_bYxA=
> >>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

So let me try to raise this issue once more, and perhaps be more clear
about what I think the issue is..

In my opinion there is now a bug in
  make check
in R-development (tested today with r79361). As I see it, I specify a
reasonable TZ environment variable and this leads to make check emitting an
error.

Best,
Kasper

On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> Yes, the potential issue I see is that
>   make check
> fails when I explicitly set TZ. However, I set it to be the same as what
> the system reports when I login.
>
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
>
>
>
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  wrote:
>
>> Thank you for the report. In R-devel, all.equal.POSIXt() by default
>> reports inconsistent time zones. Previously,
>>
>> > x <- Sys.time()
>> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
>>
>> would return TRUE. To ignore the time zone attributes in R-devel, the
>> argument 'check.tzone = FALSE' needs to be used.
>>
>> That said, I can reproduce the 'make check' failure in R-devel on Ubuntu
>> Linux when TZ is set, even if it is set to the system time zone:
>>
>> $ export TZ=Europe/Berlin
>> $ make check
>> [...]
>> > running code in '../../tests/reg-tests-2.R' ... OK
>> >   comparing 'reg-tests-2.Rout' to '../../tests/reg-tests-2.Rout.save'
>> ...7335c7335
>> > < [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>> > ---
>> >> [1] TRUE
>>
>>
>> Compare the following two sessions:
>>
>> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- Sys.time();
>> all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] TRUE
>>
>> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
>> Sys.time(); all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>>
>>
>> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
>> behaviour is not new. Even with old R 3.6.3, I see
>>
>> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "" "CET"  "CEST"
>>
>> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
>> 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "Europe/Berlin" "CET"   "CEST"
>>
>> This might be system-specific.
>>
>> I suggest to modify the test as attached for make check to pass in this
>> setting.
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
>> > The return value of Sys.time() today with a timezone of US/Eastern is
>> > unchanged between 4.0.3-patched and devel, but on devel the following
>> test
>> > fails
>> >   all.equal(x, as.POSIXlt(x))
>> > with
>> >   x = Sys.time()
>> >
>> > This means that devel does not complete make tests (failure on
>> > tests/reg-tests-2.R)
>> >
>> > It is entirely possible that it is an error on my end, I use
>> >   export TZ="US/Eastern"
>> > but I have been using this for a while, and R-4.0.3-patched built today
>> > passes make tests.
>> >
>> > Details below, and I am happy to provide more information.
>> >
>> > Build platform: inside a conda environment on linux. I have been doing
>> this
>> > for a while, but it is certainly a non-standard setup. GCC 7.3
>> >
>> > Best,
>> > Kasper
>> >
>> > On R version 4.0.3 beta (2020-10-01 r79286) I get
>> >
>> >> x = Sys.time()
>> >> attributes(x)
>> > $class
>> > [1] "POSIXct" "POSIXt"
>> >
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] TRUE
>> >
>> > On R Under development (unstable) (2020-10-01 r79286) I get
>> >> x = Sys.time()
>> >> all.equal(x,x)
>> > [1] TRUE
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> --
> Best,
> Kasper
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] VERSO issue #1689

[Kasper Daniel Hansen]

I can't speak for the reviewer, but the package currently has 2 WARNINGS.
If I were you, I would fix those warnings and push the fixes to Github, at
which point the package will be re-built and re-checked. You're not
supposed to have any ERRORS / WARNINGS when you submit. I would also look
at the NOTES, at least the following should be fixed

* checking for hidden files and directories ... NOTE
Found the following hidden files and directories:
  .github
These were most likely included in error. See section Package
structure in the Writing R Extensions manual.

* Checking coding practice...
  *NOTE: Avoid 1:...; use seq_len() or seq_along()


Best,
Kasper


On Mon, Oct 19, 2020 at 11:14 AM Davide Maspero 
wrote:

> Dear Bioconductor Staff,
>
> We have submitted a new package VERSO, by opening a new issue (
> https://github.com/Bioconductor/Contributions/issues/1689) and a moderator
> (CCed) was assigned 17 days ago. Since that, we did not receive any
> feedback. As the submission deadline is approaching we are wondering if you
> can help us to complete the submission procedure.
>
> Thank you very much for your help.
>
> Best regards,
> Davide Maspero
>
> --
> __
> Davide Maspero
> Ph.D student
>
> Dept. of Informatics, Systems and Communication, University of Milan –
> Bicocca.
> Institute of Molecular Bioimaging and Physiology, Consiglio Nazionale delle
> Ricerche (IBFM-CNR)
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

Yes, the potential issue I see is that
  make check
fails when I explicitly set TZ. However, I set it to be the same as what
the system reports when I login.

Details: The system (RHEL) I am working on has
$ strings /etc/localtime | tail -n 1
EST5EDT,M3.2.0,M11.1.0
$ date +%Z
EDT
$ echo $TZ
US/Eastern



On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  wrote:

> Thank you for the report. In R-devel, all.equal.POSIXt() by default
> reports inconsistent time zones. Previously,
>
> > x <- Sys.time()
> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
>
> would return TRUE. To ignore the time zone attributes in R-devel, the
> argument 'check.tzone = FALSE' needs to be used.
>
> That said, I can reproduce the 'make check' failure in R-devel on Ubuntu
> Linux when TZ is set, even if it is set to the system time zone:
>
> $ export TZ=Europe/Berlin
> $ make check
> [...]
> > running code in '../../tests/reg-tests-2.R' ... OK
> >   comparing 'reg-tests-2.Rout' to '../../tests/reg-tests-2.Rout.save'
> ...7335c7335
> > < [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
> > ---
> >> [1] TRUE
>
>
> Compare the following two sessions:
>
> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- Sys.time();
> all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] TRUE
>
> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
> Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>
>
> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
> behaviour is not new. Even with old R 3.6.3, I see
>
> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), "tzone")'
> [1] "" "CET"  "CEST"
>
> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
> 'attr(as.POSIXlt(Sys.time()), "tzone")'
> [1] "Europe/Berlin" "CET"   "CEST"
>
> This might be system-specific.
>
> I suggest to modify the test as attached for make check to pass in this
> setting.
>
> Best regards,
>
> Sebastian
>
>
> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
> > The return value of Sys.time() today with a timezone of US/Eastern is
> > unchanged between 4.0.3-patched and devel, but on devel the following
> test
> > fails
> >   all.equal(x, as.POSIXlt(x))
> > with
> >   x = Sys.time()
> >
> > This means that devel does not complete make tests (failure on
> > tests/reg-tests-2.R)
> >
> > It is entirely possible that it is an error on my end, I use
> >   export TZ="US/Eastern"
> > but I have been using this for a while, and R-4.0.3-patched built today
> > passes make tests.
> >
> > Details below, and I am happy to provide more information.
> >
> > Build platform: inside a conda environment on linux. I have been doing
> this
> > for a while, but it is certainly a non-standard setup. GCC 7.3
> >
> > Best,
> > Kasper
> >
> > On R version 4.0.3 beta (2020-10-01 r79286) I get
> >
> >> x = Sys.time()
> >> attributes(x)
> > $class
> > [1] "POSIXct" "POSIXt"
> >
> >> attributes(as.POSIXlt(x))
> > $names
> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>  "yday"
> >  [9] "isdst"  "zone"   "gmtoff"
> >
> > $class
> > [1] "POSIXlt" "POSIXt"
> >
> > $tzone
> > [1] "US/Eastern" "EST""EDT"
> >
> >> all.equal(x, as.POSIXlt(x))
> > [1] TRUE
> >
> > On R Under development (unstable) (2020-10-01 r79286) I get
> >> x = Sys.time()
> >> all.equal(x,x)
> > [1] TRUE
> >> attributes(as.POSIXlt(x))
> > $names
> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>  "yday"
> >  [9] "isdst"  "zone"   "gmtoff"
> >
> > $class
> > [1] "POSIXlt" "POSIXt"
> >
> > $tzone
> > [1] "US/Eastern" "EST""EDT"
> >
> >> all.equal(x, as.POSIXlt(x))
> > [1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

The return value of Sys.time() today with a timezone of US/Eastern is
unchanged between 4.0.3-patched and devel, but on devel the following test
fails
  all.equal(x, as.POSIXlt(x))
with
  x = Sys.time()

This means that devel does not complete make tests (failure on
tests/reg-tests-2.R)

It is entirely possible that it is an error on my end, I use
  export TZ="US/Eastern"
but I have been using this for a while, and R-4.0.3-patched built today
passes make tests.

Details below, and I am happy to provide more information.

Build platform: inside a conda environment on linux. I have been doing this
for a while, but it is certainly a non-standard setup. GCC 7.3

Best,
Kasper

On R version 4.0.3 beta (2020-10-01 r79286) I get

> x = Sys.time()
> attributes(x)
$class
[1] "POSIXct" "POSIXt"

> attributes(as.POSIXlt(x))
$names
 [1] "sec""min""hour"   "mday"   "mon""year"   "wday"   "yday"
 [9] "isdst"  "zone"   "gmtoff"

$class
[1] "POSIXlt" "POSIXt"

$tzone
[1] "US/Eastern" "EST""EDT"

> all.equal(x, as.POSIXlt(x))
[1] TRUE

On R Under development (unstable) (2020-10-01 r79286) I get
> x = Sys.time()
> all.equal(x,x)
[1] TRUE
> attributes(as.POSIXlt(x))
$names
 [1] "sec""min""hour"   "mday"   "mon""year"   "wday"   "yday"
 [9] "isdst"  "zone"   "gmtoff"

$class
[1] "POSIXlt" "POSIXt"

$tzone
[1] "US/Eastern" "EST""EDT"

> all.equal(x, as.POSIXlt(x))
[1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BSgenome changes

[Kasper Daniel Hansen]

Well, the presence of two mitochondrial genomes is to fix a mistake by
UCSC. I can appreciate the importance of representing this mistake when you
build off UCSC. But it strikes me as not actually representing the h37
version of the genome, and it seems to me that we want such a
representation in the project - not everything comes through UCSC. But
perhaps I have not given this sufficient thought, this is just my immediate
reaction.

On Tue, Aug 18, 2020 at 8:18 PM Leonard Goldstein <
goldstein.leon...@gene.com> wrote:

> Thanks for the explanation Hervé.
>
> Best wishes
>
> Leonard
>
>
> On Tue, Aug 18, 2020 at 10:06 AM Hervé Pagès  wrote:
>
>> On 8/18/20 01:40, Kasper Daniel Hansen wrote:
>> > In light of this, could we get a version of GRCh37 with only a single
>> > mitochondrial genome?
>>
>> You mean a BSgenome.Hsapiens.NCBI.GRCh37.p13 package? So it would
>> contain the same sequences as BSgenome.Hsapiens.UCSC.hg19 but without
>> the hg19:chrM sequence?
>>
>> Certainly doable but note that by using BSgenome.Hsapiens.UCSC.hg38 you
>> stay away from this mess. I'm not sure that adding yet another BSgenome
>> package would make the situation less confusing.
>>
>> >
>> > On Fri, Aug 14, 2020 at 6:17 PM Hervé Pagès > > <mailto:hpa...@fredhutch.org>> wrote:
>> >
>> > Hi Felix,
>> >
>> > On 8/13/20 21:43, Felix Ernst wrote:
>> >  > Hi Leonard, Hi Herve,
>> >  >
>> >  > I followed your conversation, since I have noticed the same
>> > problem. Thanks, Herve, for the explanation of the recent changes on
>> > hg19.
>> >  >
>> >  > The GRCh37.P13 report states in its last line:
>> >  >
>> >  > MTassembled-molecule  MT  Mitochondrion   J01415.2
>> >  =   NC_012920.1 non-nuclear 16569   chrM
>> >  >
>> >  > Since the last name is called "UCSC-style-name", wouldn't that
>> > mean that chrM has to be renamed to MT and not chrMT?
>> >
>> > This is a mistake in the sequence report for GRCh37.p13.
>> GRCh37.p13:MT
>> > is the same as hg19:chrMT, not hg19:chrM.
>> >
>> > hg19:chrM and hg19:chrMT are **not** the same sequences. The former
>> is
>> > NC_001807 and has length 16571 and the latter is NC_012920.1 and has
>> > length 16569.
>> >
>> > Yes, seqlevelsStyle() is sorting out all this mess for you ;-)
>> >
>> > Cheers,
>> > H.
>> >
>> >  >
>> >  > Thanks again for the explanation.
>> >  >
>> >  > Cheers,
>> >  > Felix
>> >  >
>> >  > -Ursprüngliche Nachricht-
>> >  > Von: Bioc-devel > > <mailto:bioc-devel-boun...@r-project.org>> Im Auftrag von Hervé
>> Pagès
>> >  > Gesendet: Freitag, 14. August 2020 01:08
>> >  > An: Leonard Goldstein > > <mailto:goldstein.leon...@gene.com>>; bioc-devel@r-project.org
>> > <mailto:bioc-devel@r-project.org>
>> >  > Cc: charlotte.sone...@fmi.ch <mailto:charlotte.sone...@fmi.ch>
>> >  > Betreff: Re: [Bioc-devel] BSgenome changes
>> >  >
>> >  > Hi Leonard,
>> >  >
>> >  > On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote:
>> >  >> Dear Bioc team,
>> >  >>
>> >  >> I'm following up on this recent GitHub issue
>> >  >>
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ldg21
>> >  >>
>> >
>>  
>> _SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE=
>> >  >. Please see the issue for more details and code examples.
>> >  >>
>> >  >> It looks like changes in Bioc devel result in two copies of the
>> >  >> mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one
>> > named
>> >  >> chrM like in previous package versions (length 16571) and one
>> named
>> >  >> chrMT (length 16569).
>> >  >>
>> >  >> When using seqlevelsStyle() to change chromosome names from
>> UCSC to
>> >  >> NCBI format, this results 

Re: [Bioc-devel] BSgenome changes

[Kasper Daniel Hansen]

In light of this, could we get a version of GRCh37 with only a single
mitochondrial genome?

On Fri, Aug 14, 2020 at 6:17 PM Hervé Pagès  wrote:

> Hi Felix,
>
> On 8/13/20 21:43, Felix Ernst wrote:
> > Hi Leonard, Hi Herve,
> >
> > I followed your conversation, since I have noticed the same problem.
> Thanks, Herve, for the explanation of the recent changes on hg19.
> >
> > The GRCh37.P13 report states in its last line:
> >
> > MTassembled-molecule  MT  Mitochondrion   J01415.2=
>  NC_012920.1 non-nuclear 16569   chrM
> >
> > Since the last name is called "UCSC-style-name", wouldn't that mean that
> chrM has to be renamed to MT and not chrMT?
>
> This is a mistake in the sequence report for GRCh37.p13. GRCh37.p13:MT
> is the same as hg19:chrMT, not hg19:chrM.
>
> hg19:chrM and hg19:chrMT are **not** the same sequences. The former is
> NC_001807 and has length 16571 and the latter is NC_012920.1 and has
> length 16569.
>
> Yes, seqlevelsStyle() is sorting out all this mess for you ;-)
>
> Cheers,
> H.
>
> >
> > Thanks again for the explanation.
> >
> > Cheers,
> > Felix
> >
> > -Ursprüngliche Nachricht-
> > Von: Bioc-devel  Im Auftrag von Hervé
> Pagès
> > Gesendet: Freitag, 14. August 2020 01:08
> > An: Leonard Goldstein ;
> bioc-devel@r-project.org
> > Cc: charlotte.sone...@fmi.ch
> > Betreff: Re: [Bioc-devel] BSgenome changes
> >
> > Hi Leonard,
> >
> > On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote:
> >> Dear Bioc team,
> >>
> >> I'm following up on this recent GitHub issue
> >>  >>
> _SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE=
> >. Please see the issue for more details and code examples.
> >>
> >> It looks like changes in Bioc devel result in two copies of the
> >> mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one named
> >> chrM like in previous package versions (length 16571) and one named
> >> chrMT (length 16569).
> >>
> >> When using seqlevelsStyle() to change chromosome names from UCSC to
> >> NCBI format, this results in new behavior -- in the past chrM was
> >> simply renamed MT, now the different sequence chrMT is used. Is this
> intended?
> >
> > Absolutely intended.
> >
> > There is a long story behind the unfortunate fate of the mitochondrial
> chromosome in hg19. I'll try to keep it short.
> >
> > When the UCSC folks released the hg19 browser more than 10 years ago,
> they based it on assembly GRCh37:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.13=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=jWtgKVQGC-SQp6i4prhKBiD5cBh2kEc8R1gL2uPlzy0=
> >
> > See sequence report for GRCh37:
> >
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.ncbi.nlm.nih.gov_genomes_all_GCF_000_001_405_GCF-5F01405.13-5FGRCh37_GCF-5F01405.13-5FGRCh37-5Fassembly-5Freport.txt=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=2mzBk6ksCERabHcDIy7tR6p1aQvFGkLM8lZNrsWrA18=
> >
> > For some mysterious reason GRCh37 didn't include the mitochondrial
> chromosome so the UCSC folks decided to use mitochondrial sequence
> > NC_001807 and called it chrM.
> >
> > However, UCSC has recently decided to base hg19 on GRCh37.p13 instead of
> GRCh37. A rather surprising move after many years of hg19 being based on
> the latter.
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.25_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=gxOOdwtmHjZfz-EAFblY0cm-7upZ9useI3sEgDD87o8=
> >
> > See sequence report for GRCh37.p13:
> >
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.ncbi.nlm.nih.gov_genomes_all_GCF_000_001_405_GCF-5F01405.25-5FGRCh37.p13_GCF-5F01405.25-5FGRCh37.p13-5Fassembly-5Freport.txt=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=epUg7bSfwCEF_WUOPlT5hPmLXHY7V51Mau09UaQNB5o=
> >
> > Note that GRCh37.p13 does include the mitochondrial chromosome. It's
> called MT in the official sequence report above and chrMT in hg19.
> >
> > At the same time the UCSC folks decided to keep chrM so now hg19
> contains 2 mitochondrial sequences: chrM and chrMT. Previously it has only
> one: chrM.
> >
> > So what you see in BioC devel in BSgenome.Hsapiens.UCSC.hg19 and with
> > seqlevelsStyle(genome) is only reflecting this. In particular
> > seqlevelsStyle(genome) <- "NCBI" now does the following:
> >
> > - Rename chrMT -> MT.
> >
> > - chrM does NOT get renamed. There is no point in renaming this
> sequence because it has no 

Re: [Bioc-devel] LazyData in DESCRIPTION file

[Kasper Daniel Hansen]

Your diagnose sounds reasonable to me. I don't use roxygen2 myself, so I
can't really help here (and this is one of several reasons: it adds another
layer of potential problems to the documentation process). Perhaps someone
who uses roxygen2 can comment? Or perhaps they (roxygen2 developers) have a
GitHub or email list?

Best,
Kasper

On Fri, May 1, 2020 at 5:51 AM Vinh Tran  wrote:

> Dear Kasper,
>
> I think the issue was not with the loading data in the examples of the
> functions, but with the Rd documents of the datasets themselves, where it
> says “usage{data_name}” instead of “usage{data(data_name)}”. These Rd
> documents are however automatically created using roxygen2. I still cannot
> find any other solutions yet except using "LazyData: true”.
>
> Best regards,
> Vinh
>
> 
> Dr. Vinh Tran
>
> Dept. for Applied Bioinformatics
> Inst. for Cell Biology and Neuroscience
> Goethe University Frankfurt
>
> Biologicum, Room 3.209
> Phone +49 (0)69/798-42118
>
> On 30. Apr 2020, at 16:02, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> This seems really weird, and I don't think you should be using lazyData to
> get a message to disappear.  Is there a GitHub page where we can browse the
> code and do you have the full output of R CMD check somewhere?
>
> On Thu, Apr 30, 2020 at 9:05 AM Vinh Tran 
> wrote:
>
>> Dear Kasper,
>>
>> Many thanks for your reply. Yes, I am using data() to load the data.
>> However, the problem is, when I checked my package using CMD Check, it
>> threw me the warning that I am using that data only in the example but not
>> in code. I see the disadvantages of LazyData, but I just want to know in
>> this case, how can I solve that issue by not using LazyData. If you have
>> any solutions, I am very appreciated!
>>
>> Btw, I added “LazyData: true” to the DESCRIPTION and the warning went
>> away. So, I am not sure if it must always be uppercase.
>>
>> Best regards,
>> Vinh
>>
>> 
>> Dr. Vinh Tran
>>
>> Dept. for Applied Bioinformatics
>> Inst. for Cell Biology and Neuroscience
>> Goethe University Frankfurt
>>
>> Biologicum, Room 3.209
>> Phone +49 (0)69/798-42118
>>
>> On 30. Apr 2020, at 14:55, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> If you don't have lazy data on, you should be able to load the data by
>> using data().  Let us say you example data is called expData.
>>
>> With lazy data
>>   print(expData)
>>
>> Without lazy data you need explicit loading
>>   data(expData)
>>   print(expData)
>>
>> For the purpose of examples, there is also a user-level advantage of
>> using an explicit data() statement: the user can see that the data comes
>> from somewhere, instead of appearing out of nowhere. For examples, I
>> actually only see advantages of not using lazyData, because of these
>> explicit statements.
>>
>> My historical impression: I would say that when lazyData was introduced,
>> it seems to me that the intention was widespread use. It seems to me that
>> the tides have turned against lazy data and the official recommendation is
>> to not use it unless you have good reasons.  One disadvantage with
>> widespread use of lazyData is that the names of these objects have to be
>> accessible somewhere.
>>
>> Note: one thing I have realized very belatedly is that the lazyData field
>> is a boolean, the right statements are one of
>>   lazyData: TRUE
>>   lazyData: FALSE
>> For example, I think it has to be all uppercase.
>>
>> Best,
>> Kasper
>>
>> On Wed, Apr 29, 2020 at 6:05 PM Vincent Carey 
>> wrote:
>>
>>> I see this is guideline 7 at
>>> https://bioconductor.org/developers/package-guidelines/
>>>
>>> I have used LazyData: TRUE so that [pkgname]::[entity] can be used
>>> instead
>>> of data().  The
>>> claim that it is "rarely a good thing" and slows down package loading can
>>> be weighed against
>>> convenience.  I am not sure you should use LazyData to avoid a
>>> documentation warning
>>> however.  Can you give more details on what package is generating the
>>> warning?
>>>
>>> On Wed, Apr 29, 2020 at 5:34 PM Vinh Tran 
>>> wrote:
>>>
>>> > Dear Bioc members,
>>> >
>>> > I have just encountered a warning during the CHECK that some data
>>> objects
>>> > are used in the do

Re: [Bioc-devel] LazyData in DESCRIPTION file

[Kasper Daniel Hansen]

This seems really weird, and I don't think you should be using lazyData to
get a message to disappear.  Is there a GitHub page where we can browse the
code and do you have the full output of R CMD check somewhere?

On Thu, Apr 30, 2020 at 9:05 AM Vinh Tran  wrote:

> Dear Kasper,
>
> Many thanks for your reply. Yes, I am using data() to load the data.
> However, the problem is, when I checked my package using CMD Check, it
> threw me the warning that I am using that data only in the example but not
> in code. I see the disadvantages of LazyData, but I just want to know in
> this case, how can I solve that issue by not using LazyData. If you have
> any solutions, I am very appreciated!
>
> Btw, I added “LazyData: true” to the DESCRIPTION and the warning went
> away. So, I am not sure if it must always be uppercase.
>
> Best regards,
> Vinh
>
> 
> Dr. Vinh Tran
>
> Dept. for Applied Bioinformatics
> Inst. for Cell Biology and Neuroscience
> Goethe University Frankfurt
>
> Biologicum, Room 3.209
> Phone +49 (0)69/798-42118
>
> On 30. Apr 2020, at 14:55, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> If you don't have lazy data on, you should be able to load the data by
> using data().  Let us say you example data is called expData.
>
> With lazy data
>   print(expData)
>
> Without lazy data you need explicit loading
>   data(expData)
>   print(expData)
>
> For the purpose of examples, there is also a user-level advantage of using
> an explicit data() statement: the user can see that the data comes from
> somewhere, instead of appearing out of nowhere. For examples, I actually
> only see advantages of not using lazyData, because of these explicit
> statements.
>
> My historical impression: I would say that when lazyData was introduced,
> it seems to me that the intention was widespread use. It seems to me that
> the tides have turned against lazy data and the official recommendation is
> to not use it unless you have good reasons.  One disadvantage with
> widespread use of lazyData is that the names of these objects have to be
> accessible somewhere.
>
> Note: one thing I have realized very belatedly is that the lazyData field
> is a boolean, the right statements are one of
>   lazyData: TRUE
>   lazyData: FALSE
> For example, I think it has to be all uppercase.
>
> Best,
> Kasper
>
> On Wed, Apr 29, 2020 at 6:05 PM Vincent Carey 
> wrote:
>
>> I see this is guideline 7 at
>> https://bioconductor.org/developers/package-guidelines/
>>
>> I have used LazyData: TRUE so that [pkgname]::[entity] can be used instead
>> of data().  The
>> claim that it is "rarely a good thing" and slows down package loading can
>> be weighed against
>> convenience.  I am not sure you should use LazyData to avoid a
>> documentation warning
>> however.  Can you give more details on what package is generating the
>> warning?
>>
>> On Wed, Apr 29, 2020 at 5:34 PM Vinh Tran 
>> wrote:
>>
>> > Dear Bioc members,
>> >
>> > I have just encountered a warning during the CHECK that some data
>> objects
>> > are used in the documents but not in code (e.g. “Variables with usage in
>> > documentation object ‘ppTree’ but not in code"). They are the demo data,
>> > that I am using only in the examples for demonstrate the usage of some
>> > functions. Adding LazyData: True to the DESCRIPTION can solve that
>> issue,
>> > but according to the package guidelines it is not recommended. Could you
>> > please show me what should I do in this case? The demo data is only
>> about
>> > 15 KB at max.
>> >
>> > Many thanks for your advices!
>> >
>> > Best regards,
>> > Vinh
>> >
>> > 
>> > Dr. Vinh Tran
>> >
>> > Dept. for Applied Bioinformatics
>> > Inst. for Cell Biology and Neuroscience
>> > Goethe University Frankfurt
>> >
>> > Biologicum, Room 3.209
>> > Phone +49 (0)69/798-42118
>> >
>> >
>> > [[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 the ...{{dropped:18}}
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> --
> Best,
> Kasper
>
>
>

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] LazyData in DESCRIPTION file

[Kasper Daniel Hansen]

If you don't have lazy data on, you should be able to load the data by
using data().  Let us say you example data is called expData.

With lazy data
  print(expData)

Without lazy data you need explicit loading
  data(expData)
  print(expData)

For the purpose of examples, there is also a user-level advantage of using
an explicit data() statement: the user can see that the data comes from
somewhere, instead of appearing out of nowhere. For examples, I actually
only see advantages of not using lazyData, because of these explicit
statements.

My historical impression: I would say that when lazyData was introduced, it
seems to me that the intention was widespread use. It seems to me that the
tides have turned against lazy data and the official recommendation is to
not use it unless you have good reasons.  One disadvantage with widespread
use of lazyData is that the names of these objects have to be accessible
somewhere.

Note: one thing I have realized very belatedly is that the lazyData field
is a boolean, the right statements are one of
  lazyData: TRUE
  lazyData: FALSE
For example, I think it has to be all uppercase.

Best,
Kasper

On Wed, Apr 29, 2020 at 6:05 PM Vincent Carey 
wrote:

> I see this is guideline 7 at
> https://bioconductor.org/developers/package-guidelines/
>
> I have used LazyData: TRUE so that [pkgname]::[entity] can be used instead
> of data().  The
> claim that it is "rarely a good thing" and slows down package loading can
> be weighed against
> convenience.  I am not sure you should use LazyData to avoid a
> documentation warning
> however.  Can you give more details on what package is generating the
> warning?
>
> On Wed, Apr 29, 2020 at 5:34 PM Vinh Tran 
> wrote:
>
> > Dear Bioc members,
> >
> > I have just encountered a warning during the CHECK that some data objects
> > are used in the documents but not in code (e.g. “Variables with usage in
> > documentation object ‘ppTree’ but not in code"). They are the demo data,
> > that I am using only in the examples for demonstrate the usage of some
> > functions. Adding LazyData: True to the DESCRIPTION can solve that issue,
> > but according to the package guidelines it is not recommended. Could you
> > please show me what should I do in this case? The demo data is only about
> > 15 KB at max.
> >
> > Many thanks for your advices!
> >
> > Best regards,
> > Vinh
> >
> > 
> > Dr. Vinh Tran
> >
> > Dept. for Applied Bioinformatics
> > Inst. for Cell Biology and Neuroscience
> > Goethe University Frankfurt
> >
> > Biologicum, Room 3.209
> > Phone +49 (0)69/798-42118
> >
> >
> > [[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:15}}

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

Re: [Bioc-devel] HDF5Array failure on windows

[Kasper Daniel Hansen]

Thanks for the two pointers.

Herve: we are using a number of unexpected functions from HDF5Array:
  ‘HDF5Array:::.create_dir’, ‘HDF5Array:::.replace_dir’,
‘HDF5Array:::.shorten_assay2h5_links’
That might be relevant in light of that specific test error.


On Mon, Apr 6, 2020 at 1:13 PM Hervé Pagès  wrote:

> Hi Kasper, Martin,
>
> About bsseq's timeout: An important recent change to
> DelayedArray/HDF5Array is that, starting with DelayedArray 0.13.8,
> nothing in these packages uses parallel evaluation **by default**.
> Concretely this means that getAutoBPPARAM() now returns NULL on a fresh
> session instead of one of the parallelization backends defined in
> BiocParallel (e.g. MulticoreParam on Linux/Mac, SnowParam on Windows).
> This could slow down some code in bsseq or other packages that were
> benefiting from the automatic parallel evaluation. Now it's the
> responsibility of the user to set the parallelization backend (with
> setAutoBPPARAM) if they wish things like matrix multiplication, rowsum()
> or rowSums() use parallel evaluation again.
>
> Also BiocParallel has been moved from Depends to Suggests.
>
> About bsseq error on Windows: That seems indeed to be related to the
> HDF5Array error on the same platform. The unit tests in bsseq and
> HDF5Array both fail with the same error ("HDF5 dataset
> './.HDF5ArrayAUTO00014_dimnames/2' does not exist"). I'll take a look.
> What's puzzling is that we see this error on both Windows archs for
> bsseq (i.e. on 64-bit and 32-bit) while we only see it on 64-bit Windows
> for HDF5Array. This suggests something nasty and hard to troubleshoot..
> sigh!
>
> Cheers,
> H.
>
>
> On 4/6/20 06:59, Martin Morgan wrote:
> > Timeouts are often related to parallel evaluation, either competing for
> resources or underlying limitations in the robustness of the (parallel)
> code. Something close to best practice is to limit or eliminate parallel
> evaluation in examples, vignettes, and tests.
> >
> > Documentation issues are usually related to the use of [] in \link[]{},
> as described at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_doc_manuals_r-2Drelease_R-2Dexts.html-23Cross-5F002dreferences=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=2r59fOKiJQ_AJBSaOXUDB1j3dD1txuMA-cJzCnnIE9k=
> . The important point is that the [] information is the NAME OF THE HTML
> FILE of the documentation module, not the 'name' of the documentation
> module. The solution (from my perspective) is usually to simply omit the []
> and let the R help system resolve the link dynamically (sometimes prompting
> the user to choose, if there multiple man pages).
> >
> > Martin Morgan
> >
> >
> > On 4/6/20, 9:55 AM, "Bioc-devel on behalf of Kasper Daniel Hansen" <
> bioc-devel-boun...@r-project.org on behalf of kasperdanielhan...@gmail.com>
> wrote:
> >
> >  We currently (and for a while) have had various errors in bsseq
> that seems
> >  to have come and go. We now have a failure on Windows which is
> related to
> >  HDF5. I see that HDF5Array also fails on Windows, which makes me
> believe
> >  the error could be upstream. There is also a warning about hep page
> links
> >  which HDF5Array has as well. Any comments on this is appreciated.
> >
> >  Perhaps relatedly: we are getting a timeout on linux. On my own OS
> X setup,
> >  it completes in a timely fashion. Do we sometimes have unexplained
> timeouts
> >  related to HDF5?
> >
> >  --
> >  Best,
> >  Kasper
> >
> >   [[alternative HTML version deleted]]
> >
> >  ___
> >  Bioc-devel@r-project.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=28DlcVps0EVU-QaF8utnvHUFuj1DpJIZrrXrlPqIb28=
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=28DlcVps0EVU-QaF8utnvHUFuj1DpJIZrrXrlPqIb28=
> >
>
> --
> 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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

[Bioc-devel] HDF5Array failure on windows

[Kasper Daniel Hansen]

We currently (and for a while) have had various errors in bsseq that seems
to have come and go. We now have a failure on Windows which is related to
HDF5. I see that HDF5Array also fails on Windows, which makes me believe
the error could be upstream. There is also a warning about hep page links
which HDF5Array has as well. Any comments on this is appreciated.

Perhaps relatedly: we are getting a timeout on linux. On my own OS X setup,
it completes in a timely fashion. Do we sometimes have unexplained timeouts
related to HDF5?

-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Updates to SingleCellExperiment class structure - no action required

[Kasper Daniel Hansen]

It sounds to me that the class definition / structure is updated. You
should also have an associated updateObject() method to deal with this;
that's tradition. Of course, you may already have addressed this and just
not written about it in your email.

On Sun, Feb 16, 2020 at 3:51 AM Aaron Lun <
infinite.monkeys.with.keyboa...@gmail.com> wrote:

> Dear list,
>
> As of version 1.9.2, the SingleCellExperiment class structure has been
> updated so that "sizeFactors()<-" will store values in a "sizeFactor"
> field in the "colData()", rather than the internal metadata. This aims
> to improve interoperability of the SCE size factors with functions that
> retrieve information from the column metadata; see GitHub for details.
>
> This change occurs under the hood in the "sizeFactors()" getter and
> setter functions, so no action should be required from users who were
> already using those functions to manipulate the SCE size factors.
> Nonetheless, downstream developers should keep an eye on their unit
> tests as some of the more fragile checks may fail, e.g., if they
> hard-coded the expected column names of the "colData" of an SCE.
>
> Version 1.9.2. also removes a bunch of deprecated functionality from the
> package, which may cause unrelated failures; though this was pretty
> esoteric stuff that didn't see a lot of use in the first place.
>
> Best,
>
> -A
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] How to use RData files in Bioconductor data and software packages

[Kasper Daniel Hansen]

Tobias,

When you use the data() command on the data package, you need to do
  library(dummyData)
first (and you therefore need to Suggest: dummyData)

Here is an example from minfi/minfiData

if (require(minfiData)) {
  dat <- preprocessIllumina(RGsetEx, bg.correct=FALSE, normalize="controls")
}

Note how I use require to load the package. For clarity you could argue I
should also have
  data(RGsetEx)
but it is technically not necessary because of lazy loading.





On Thu, Jan 9, 2020 at 4:40 PM Pages, Herve  wrote:

> On 1/9/20 13:00, web working wrote:
> > Hi Herve,
> >
> > thank you for your detailed answer. I guess I have expressed myself
> > unclear. The BED files were just examples for data I store in the
> > inst/extdata folder. Based on the description for ExperimentHubData I
> > have decided to create a software and a data package (no
> > ExperimentHubData software package). In my RData files I store software
> > package objects. These objects are bigger than 5 MB. Using a helper
> > function is no option, because the object calculation takes to much
> > time. For this reason I want to load this objects for my example
> > functions. My question is if the storage of my RData files in the
> > inst/extdata directory is correct or not.
>
> It's technically correct but it's not as convenient as putting them in
> data/ because they can not longer be listed and/or loaded with data().
> So if you're storing them in inst/extdata only because the data()
> solution gave you a BiocCheck warning then I'd say that you're giving up
> too easily ;-)
>
> IMO it is important to try to understand why the data() solution gave
> you a BiocCheck warning in the first place. Unfortunately you're not
> providing enough information for us to be able to tell. What does the
> warning say? How can we reproduce the warning? Ideally we would need to
> see a transcript of your session and links to your packages.
>
> Thanks,
> H.
>
>
> >
> > Best,
> >
> > Tobias
> >
> > Am 09.01.20 um 17:59 schrieb Pages, Herve:
> >> Hi Tobias,
> >>
> >> If the original data is in BED files, there should be no need to
> >> serialize the objects obtained by importing the files. It is **much**
> >> better to provide a small helper function that creates an object from a
> >> BED file and to use that function each time you need to load an object.
> >>
> >> This has at least 2 advantages:
> >> 1. It avoids redundant storage of the data.
> >> 2. By avoiding serialization of high-level S4 objects, it makes the
> >> package easier to maintain in the long run.
> >>
> >> Note that the helper function could also implement a cache mechanism
> >> (easy to do with an environment) so the BED file is only loaded and the
> >> object created the 1st time the function is called. On subsequent calls,
> >> the object is retrieved from the cache.
> >>
> >> However, if the BED files are really big (e.g. > 50 Mb), we require them
> >> to be stored on ExperimentHub instead of inside dummyData. Note that you
> >> still need to provide the dummyData package (which becomes what we call
> >> an ExperimentHub-based data package). See the "Creating An ExperimentHub
> >> Package" vignette in the ExperimentHubData package for more information
> >> about this.
> >>
> >> Hope this helps,
> >>
> >> H.
> >>
> >> On 1/9/20 04:45, web working wrote:
> >>> Dear all,
> >>>
> >>> I am currently developing a software package (dummySoftware) and a data
> >>> package (dummyData) and I am a bit confused in where to store my RData
> >>> files in the data package. Here my situation:
> >>>
> >>> I want to store some software package objects (new class objects of the
> >>> software package) in the data package. This objects are example objects
> >>> and a to big for software packages. As I have read here
> >>> (
> https://urldefense.proofpoint.com/v2/url?u=http-3A__r-2Dpkgs.had.co.nz_data.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GaTKqVd_WDqMRk0dW7SYkjVlgCzt0I0bACHfb1iIOVc=0ajhWDlJfLxXxzJpreO1Nh4qnu3aJ8gQkRb9qThsi1o=
> >>>
> >>> ) all RData objects should be stored in the data directory of a
> package.
> >>> BED files of the data package are stored in inst/extdata.
> >>> The data of the data packaged will be addressed in the software package
> >>> like this: system.file('extdata', 'subset.bed', package = 'dummyData').
> >>> And here the problem occurs. After building the data package
> >>> (devtools::build(args = c('--resave-data'))), all data in data/ are
> >>> stored in a datalist, Rdata.rdb, Rdata.rds and Rdata.rdx and can not
> >>> addressed with system.file. Addressing this data with the data()
> >>> function results in a warning during BiocCheck::BiocCheck().
> >>>
> >>> My solution is to store the RData files in the inst/extdata directory
> >>> and address them with system.file. Something similar is mentioned here,
> >>> but in the context of a vignette
> >>> (r-pkgs.had.co.nz/data.html#other-data). Is this the way how to do it?
> >>>
> >>> Best,
> 

Re: [Bioc-devel] proposal for additional seqlevelsStyle

[Kasper Daniel Hansen]

If the chromosome name depends on the assembly, that makes GenomeInfoDb
even more useful and necessary.  Provided it is supported of course.

On Fri, Dec 13, 2019 at 11:45 AM Vincent Carey 
wrote:

> I tried an inline png but I think it was rejected by bioc-devel.  Here's
> another try.
>
> On Fri, Dec 13, 2019 at 11:40 AM Vincent Carey  >
> wrote:
>
> > Thanks -- It is good to know more about the complications of adding
> > seqlevelsStyle elements.
> > I am not sure how pervasive this will be in SNP annotation in the future.
> > The "new API" for dbSNP
> > references SPDI annotation conventions.
> >
> > https://api.ncbi.nlm.nih.gov/variation/v0/
> >
> > at least one dbsnp build 152 resource uses this nomenclature.  The one
> >
> > referenced below is the "go-to" resource for current rsid-coordinate
> >
> > correspondence, as far as I know.
> >
> >
> > > library(VariantAnnotation)
> >
> > *0/0 packages newly attached/loaded, see sessionInfo() for details.*
> >
> > > mypar = GRanges("NC_01.11", IRanges(10,12)) # note seqnames
> >
> >
> > > nn = readVcf("
> >
> ftp://ftp.ncbi.nih.gov/snp/redesign/latest_release/VCF/GCF_01405.38.gz
> > ",
> >
> > +   genome="GRCh38", param=mypar)
> >
> >
> > > head(rowRanges(nn), 3)
> >
> > GRanges object with 3 ranges and 5 metadata columns:
> >
> >seqnamesranges strand | paramRangeID
> REF
> >
> >   | 
> 
> >
> >   rs1331956057 NC_01.1110  * | 
> C
> >
> >   rs1252351580 NC_01.11100036  * | 
> T
> >
> >   rs1238523913 NC_01.11100051  * | 
> T
> >
> >   ALT  QUAL  FILTER
> >
> >  
> >
> >   rs1331956057  T .
> >
> >   rs1252351580  G .
> >
> >   rs1238523913  C .
> >
> >   ---
> >
> >   seqinfo: 1 sequence from GRCh38 genome; no seqlengths
> >
> >
> > On Fri, Dec 13, 2019 at 11:01 AM Robert Castelo 
> > wrote:
> >
> >> hi Hervé,
> >>
> >> i didn't know about this new sequence style until Vince posted his
> >> message and we briefly talked about it at the European BioC meeting this
> >> week in Brussels. however, i didn't know that the style was specific to
> >> a particular assembly. i have no use case of this at the mome moment,
> >> i.e., i have not encountered myself any annotation or BAM file with
> >> chromosome names written that way, so i don't know how pressing this
> >> issue is, maybe Vince can tell us how spread such chromosome naming
> >> style may become in the near future.
> >>
> >> naively, i'd think that it would be matter of adding a
> >> reference-specific column, i.e., 'GRCh38.p13', 'GRCh37.p13', etc., but i
> >> can imagine that maybe the "reference style" concept might not be the
> >> appropriate placeholder to map all different chromosome names of all
> >> different individual human genomes uploaded to NCBI. maybe we should
> >> wait until we have a specific use case .. Vince?
> >>
> >> robert.
> >>
> >> On 12/11/19 10:06 PM, Pages, Herve wrote:
> >> > Hi Vince, Robert,
> >> >
> >> > Looks like Vince wants the RefSeq accession e.g. NC_17.11 for
> chrom
> >> > 17 in the GRCh38.
> >> >
> >> > @Robert: Is this what you're also interested in?
> >> >
> >> > The problem is that the RefSeq accessions are specific to a particular
> >> > assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but NC_17.10
> for
> >> > the same chrom in GRCh37).
> >> >
> >> > Currently seqlevelsStyle() doesn't know how to distinguish between
> >> > different assemblies of the same organism. Not saying it couldn't but
> it
> >> > would require some thinking and some significant refactoring. It
> >> > wouldn't be just a matter of adding a column to
> >> > genomeStyles()$Homo_sapiens.
> >> >
> >> > H.
> >> >
> >> >
> >> > On 12/10/19 14:19, Robert Castelo wrote:
> >> >> I second this, and would suggest to name the style as 'GRC' for
> "Genome
> >> >> Reference Consortium".
> >> >>
> >> >> thanks Vince for bringing this up, being able to easily switch
> between
> >> >> genome styles is great.
> >> >>
> >> >> if 'paste0()' in R is one of the most influential contributions to
> >> >> statistical computing
> >> >>
> >> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__simplystatistics.org_2013_01_31_paste0-2Dis-2Dstatistical-2Dcomputings-2Dmost-2Dinfluential-2Dcontribution-2Dof-2Dthe-2D21st-2Dcentury=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=b0_SIu8orJ7ZcCS3TIodFvGTPibt9R8vFL5Y40YSx3Q=
> >> >>
> >> >> i think that 'seqlevelsStyle()' from the GenomeInfoDb package is one
> of
> >> >> the most influential contributions to human genetics, if you think
> >> about
> >> >> the time invested by researchers in parsing and changing between
> >> >> different styles of chromosome names :)
> >> >>
> >> >> robert.
> >> >>
> >> >> 

Re: [Bioc-devel] -fopenmp switch issue on mac

[Kasper Daniel Hansen]

Are you using the clang 6 (R 3.5) / 7 (R 3.6) / 8 (R 4.0) which Simon
supplies?

This is for clang 6 with full path

/usr/local/clang6/bin/clang --version
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /usr/local/clang6/bin

On Wed, Dec 4, 2019 at 11:03 AM Vincent Carey 
wrote:

> When installing packages from source,
>
> I frequently run into this error with
>
>
> %vjcair> clang --version
>
> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>
> Target: x86_64-apple-darwin16.7.0
>
> Thread model: posix
>
> InstalledDir:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
>
> I am still running macos Sierra ... is there a solution within this
> platform?  I have been getting around this by modifying Makevars when
> needed
>
>
>
> * installing *source* package ‘sitmo’ ...
>
> ** package ‘sitmo’ successfully unpacked and MD5 sums checked
>
> ** using staged installation
>
> ** libs
>
> clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I../inst/include/
>
> -I'/Library/Frameworks/R.framework/Versions/4.0/Resources/library/Rcpp/include'
> -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> -I/usr/local/include  -fopenmp -fPIC  -Wall -g -O2  -c RcppExports.cpp -o
> RcppExports.o
>
> clang: *error: *unsupported option '-fopenmp'
>
> make: *** [RcppExports.o] Error 1
>
> ERROR: compilation failed for package ‘sitmo’
>
> --
> The information in this e-mail is intended only for th...{{dropped:15}}

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

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

[Kasper Daniel Hansen]

Or remove the graph dependency

On Tue, Nov 26, 2019 at 3:16 PM James W. MacDonald  wrote:

> Hi Lori,
>
> Let me know if you don't hear from Benilton. It shouldn't be much work to
> fix oligo - we could convert to using Gviz for the graphic that is
> currently using GenomeGraphs. I can make the change next week if necessary.
>
> Best,
>
> Jim
>
>
>
> On Tue, Nov 26, 2019 at 12:57 PM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
> > typo -  heatplus and topGO have responded directly.
> >
> >
> > 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
> > Shepherd, Lori 
> > Sent: Tuesday, November 26, 2019 12:54 PM
> > To: Henrik Bengtsson ;
> > bioc-devel@r-project.org 
> > Subject: Re: [Bioc-devel] CRAN packages depending on broken Bioc 3.11
> > packages may be archived
> >
> > All of these package have been notified from the Bioconductor side as
> > well.  We hope the maintainers will respond shortly.
> > heatmap and topGO  have responded directly and are working on fixes.  I
> > hope the others are too.
> >
> >
> >
> > 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 Henrik
> > Bengtsson 
> > Sent: Tuesday, November 26, 2019 12:47 PM
> > To: bioc-devel@r-project.org 
> > Subject: [Bioc-devel] CRAN packages depending on broken Bioc 3.11
> packages
> > may be archived
> >
> > 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
> >
> >
> > 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
> >
> >
> > 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
> >
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] How to move package from workflow to software

[Kasper Daniel Hansen]

Without commenting on whether the move is appropriate, it should trigger a
new review process.

Best,
Kasper

On Fri, Nov 15, 2019 at 9:31 AM Julien Wollbrett 
wrote:

> Hello Nitesh,
>
> Thank you for your answer.
>
> I added some functionalities to the BgeeCall package that are not
> compatible to a workflow approach.
> It is now possible to run some steps outside of the initial workflow, to
> download files from different locations, to reuse data generated by the
> user or already processed by the Bgee team, etc.
>
> Furthermore BgeeCall does not only reuse already existing bioconductor
> packages and combine them to create a workflow. It corresponds to a new
> approach allowing to generate present/absent gene expression calls from
> RNA-Seq libraries without using an arbitrary cutoff.
>
> I would be very happy if you can help me moving it to the software section.
>
> Best,
>
> Julien
>
> Le 15.11.19 à 11:59, Turaga, Nitesh a écrit :
> > Hi,
> >
> > Changing the BiocViews section in the DESCRIPTION file doesn't change
> your package from a workflow package to a software package.
> >
> > There are fundamental differences between workflow packages and software
> packages in the way we handle them within Bioconductor. Could you tell us
> why you'd like to change it from a workflow to a software package?
> >
> > The Bioc team, would have to assist in moving it to the software section.
> >
> > Best,
> >
> > Nitesh
> >
> > On 11/15/19, 4:46 AM, "Bioc-devel on behalf of Julien Wollbrett" <
> bioc-devel-boun...@r-project.org on behalf of julien.wollbr...@unil.ch>
> wrote:
> >
> >  Hello,
> >
> >  I am the maintainer of the BgeeCall R package.
> >
> >  In bioconductor 3.9 my package was registered as a workflow package.
> >  I modified my DESCRIPTION file before the release 3.10 in order to
> move
> >  the package to the software section hopping for it to automatically
> move
> >  after the new release. Unfortunately it did not work.
> >
> >  Could you please tell me how to do to move BgeeCall to the software
> section?
> >
> >  Thank you,
> >
> >  Julien
> >
> >  ___
> >  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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Opinions on a meta-annotation package

[Kasper Daniel Hansen]

>From your description it very much sounds like creating a new package is
the way to go.

On Thu, Oct 24, 2019 at 3:03 PM Pages, Herve  wrote:

> Hi Panagiotis,
>
> Avoiding code repetition is always a good idea. An alternative to the
> creation of a 3rd package would be to have one of the 2 packages depend
> on the other. If that is not a good option (and there might be some
> valid reasons for that) then yes, factorizing out the repeated stuff and
> putting it in a 3rd package is a good option.
>
> Note that your subject line is confusing: You're asking opinions on a
> meta-annotation package but IIUC this is about the creation of a
> **software** package that would provide tools for building and/or
> querying a certain type of annotations right? I think of a
> meta-annotation package as a data package that would contain searchable
> meta data about existing biological annotations but that is not what we
> are talking about here is it?
>
> Also I wonder how much overlap there would be between this new package
> and packages like AnnotationDbi, AnnotationForge, GenomicFeatures,
> ensembldb which also provide functionalities for creating and querying
> annotations. For example AnnotationForge and AnnotationDbi are used to
> create and query the hundreds of "classic" *db packages.
>
> Best,
> H.
>
> On 10/20/19 19:56, Panagiotis Moulos wrote:
> > Dear developers,
> >
> > I maintain two packages (metaseqR, recoup) and about to submit an
> enhanced
> > (but different in many points, thus a new package) version of the 1st
> > (metaseqR2). During their course of development, maintenance and usage,
> > these packages have somehow come to use a common underlying annotation
> > system for the genomic regions they operate on, which of course makes use
> > of Bioconductor facilities and of course structures (GenomicRanges,
> > GenomicAlignments, BSgenome, GenomicFeatures etc.)
> >
> > This annotation system:
> > - Builds a local SQLite database
> > - Supports certain "custom" genomic features which are required for the
> > modeling made by these packages
> > - Is currently embedded to each package
> > - Has almost evolved to a package of its own with respect to independent
> > functionalities
> >
> > The reason for this mail/question is that I would like to ask your
> opinion
> > whether it is worthy to create a new package to host  the annotation
> > functions and detach from the other two. Some points to support this
> idea:
> >
> > 1. It's used in the same manner by two other packages, thus there is a
> lot
> > of code  repetition
> > 2. Users (including myself) often load one of these packages just to use
> it
> > to fetch genomic region annotations for other purposes outside the scope
> of
> > each package (metaseqR - RNA-Seq data analysis, recoup - NGS signal
> > visualization).
> > 3. It automatically constructs the required annotation regions to analyze
> > Lexogen Quant-Seq data (a protocol we are using a lot), a function which
> > may be useful to many others
> > 4. The database created can be expanded with custom user annotations
> using
> > a GTF file to create it (making use of makeTxDbFromGFF)
> > 5. Supports various annotation sources (Ensembl, UCSC, RefSeq, custom) in
> > one place
> > 6. Has a versioning system, allowing transparency and reproducibility
> when
> > required
> >
> > Some (maybe obvious) points against this idea:
> >
> > 1. Bioconductor has already a robust and rich genomic annotation system
> > which can be used and re-used as necessary
> > 2. Maybe there is no need for yet another annotation-related package
> > 3. There is possibly no wide acceptance for such a package, other than my
> > usage in the other two, and maybe a few more users that make use of the
> > annotation functionalities
> > 4. Does not follow standard Bioconductor guidelines for creating
> annotation
> > packages (on the other hand it's not an annotation package in the strict
> > sense, but more a meta-annotation package).
> >
> > Do you have any thoughts or opinions on the best way of action?
> >
> > Best regards,
> >
> > Panagiotis
> >
>
> --
> 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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] check fails on arch 'i386'

[Kasper Daniel Hansen]

I see these packages may have something to do with mini. There is a a (very
old, nothing new) issue with the annotation objects in minfi where loading
them uses a _lot_ of ram. For a long time I couldn't understand it, but now
I get it. I should really fix this, and probably _very_soon. It won't have
any real user-visible changes (unless you're using the SNP functionality
which is very nice but not used by many people I think), but it will
require a new set of annotation packages.

Best,
Kasper

On Thu, Oct 17, 2019 at 4:08 AM Tim Peters  wrote:

> Hi Hervé (and Reka),
>
> I am having much the same problem on tokay1 with DMRcate
> (
> https://bioconductor.org/checkResults/3.10/bioc-LATEST/DMRcate/tokay1-checksrc.html
> ).
>
>
> I've gone through a number of iterations trying to minimise the amount
> of memory run by the examples (including your suggestions such as using
> GRanges as a container for everything in a CpGannotated object, and
> restricting analysis to 100 CpG sites) but the memory allocation error
> is persistent, failing to allocate a quite modest ~500Mb.
>
> I suspect it's being caused by minfi::makeGenomicRatioSetFromMatrix()
> which is called by cpg.annotate() and DMR.plot() - I started a thread
> here around the time of the April release concerning the problem but it
> wasn't responded to:
>
> https://stat.ethz.ch/pipermail/bioc-devel/2019-April/015012.html
>
> This leaves me in a bind as minfi::makeGenomicRatioSetFromMatrix() has
> exactly the functionality cpg.annotate() and DMR.plot() needs, plus it
> provides minimal code and I don't really want to reinvent the wheel here!
>
> Would it be possible to waive the 32-bit Windows build for DMRcate?
>
> Best,
>
> Tim
>
> On 15/10/19 4:34 am, Pages, Herve wrote:
> > Hi Toth,
> >
> > Not clear to me what's going on but I kind of suspect this might have
> > something to do with the use of data.table.
> >
> > A few things to keep in mind:
> >
> > - 'R CMD check' runs all the example in the same R session. This means
> > that the outcome of the examples of a given man page can be affected by
> > the examples from other man pages.
> >
> > - A process cannot allocate more than 3 Gb of memory on 32-bit Windows.
> > There is no such limit on 64-bit Windows or on the other platforms we
> > support (Linux and Mac). On these platforms the maximum amount of memory
> > a process can allocate only depends on what's available on the system.
> >
> > - Generally speaking, sticking to the Bioconductor way of doing things
> > (e.g use of GRanges objects instead of data.table objects, use of
> > findOverlaps() instead of data.table::foverlaps()) will lead to faster
> > code and reduced memory usage. Therefore I would strongly encourage you
> > to consider switching to GRanges/findOverlaps() and to avoid the use of
> > data.table in methrix.
> >
> > Best,
> > H.
> >
> >
> > On 10/11/19 09:36, Toth, Reka wrote:
> >> Dear BioC developers,
> >>
> >> The most recent build of methrix fails on Tokay1 server:
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_spb-5Freports_methrix-5Fbuildreport-5F20191009174210.html=DwIF-g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=doO3ej8vD58ZBQWVxkHTaCLk-xipbskav8uofJL2syI=zs3uDnFqyAl-hr_7StB3Yr-tGZW8VPfclbPY_JKtSt8=
> >> The error message is the following:
> >>
> >> ** running examples for arch 'i386' ... ERROR
> >> Running examples in 'methrix-Ex.R' failed
> >> The error most likely occurred in:
> >>
> >>> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> >>> ### Name: get_region_summary
> >>> ### Title: Extract and summarize methylation or coverage info by
> regions of
> >>> ###   interest
> >>> ### Aliases: get_region_summary
> >>>
> >>> ### ** Examples
> >>>
> >>> data("methrix_data")
> >>> get_region_summary(m = methrix_data, regions = data.table(chr =
> "chr21", start = 27867971, end =  27868103), type = "M", how = "mean")
> >> -Checking for overlaps..
> >> Error: cannot allocate vector of size 1.4 Gb
> >> Execution halted
> >>
> >> I am a bit puzzled what the reasons could be, since it passed this step
> during the previous builds and I didn’t change any of the functions in my
> last commit.
> >> When I run the check on our local Windows, I don’t get any error. We
> use a very small dataset as example, it definitely should not use a vector
> of size 1.4 Gb.
> >>
> >> I would appreciate every input or idea on how to tackle this error.
> >> Thanks a lot!
> >>
> >> Best,
> >> Reka
> >>
> >> Dr. Reka Toth
> >> Computational Epigenomics Group
> >> Division of Epigenomics and Cancer Risk Factors /C010
> >> Postdoctoral Fellow
> >>
> >> German Cancer Research Center (DKFZ)
> >> Foundation under Public Law
> >> Im Neuenheimer Feld 280
> >> 69120 Heidelberg
> >> Germany
> >>
> >> r.t...@dkfz-heidelberg.de
> >>
> 

Re: [Bioc-devel] new package for accessing some chemical and biological databases

[Kasper Daniel Hansen]

We used to have (? or at least discussed the possibility of) occasional
extensive checking so we could have
  tests
  long_tests
(names made up).

On Fri, Sep 13, 2019 at 9:50 AM Martin Morgan 
wrote:

> Putting bioc-devel back in the loop.
>
> I think that the straight-forward answer to your original query is 'no,
> git modules are not supported'.
>
> I think we'd carry on and say 'packages should be self-contained and
> conform to the Bioconductor size and time constraints', so you cannot have
> a very large package or a package that takes a long time to check, and you
> can't download part of the package from some alternative source (except
> perhaps AnnotationHub or ExperimentHub). I agree that the hubs are not
> suitable for regularly updated files, and that they are meant for
> biologically motivated rather than purely test-related data resources.
>
> While we 'could' make special accommodations on the build systems to
> support your package, we have found that this is not a fruitful endeavor.
>
> A natural place to put files used in tests would be in the /tests
> directory; these are not included in the installed package. But it seems
> likely that including your tests would violate the time and / or space
> limitations we place on packages.
>
> It seems likely that this leads to the question you pose below, which is
> how do you know that you're running on the build system so that you can
> perform more modest computations? This is similar to here, where special
> resources are normally required
>
>   https://stat.ethz.ch/pipermail/bioc-devel/2019-September/015518.html
>
> Herve seems not willing to commit to an easy answer, perhaps because this
> opens the door to people circumventing even minimal tests of their
> package...
>
> Martin
>
> On 9/13/19, 7:49 AM, "Shepherd, Lori" 
> wrote:
>
>
> I'm including Martin and Herve for their opinions and to chime in too
> since you took this conversation off the mailing list...
>
>
> Could you please describe what you mean by works transparently?
>
>
> We realize there isn't a function to call -  we were suggesting you
> make a function to call that could be utilized
>
>
> How does your caching system work?  I would also advise looking into
> BiocFileCache - the Bioconductor suggested package for data caching of
> files.
>
>
>
>
> The relevant files to look at for the environment calls can be found
> https://github.com/Bioconductor/Contributions
>
> esp.
> https://github.com/Bioconductor/Contributions#r-cmd-check-environment
>
>
>
> Please also be mindful of:
>
> Submission Guidelines
> https://bioconductor.org/developers/package-submission/
>
> Package Guidelines
> https://bioconductor.org/developers/package-guidelines/
>
>
>
>
> More specifically on the single package builder we use:
> R CMD BiocCheckGitClone 
> R CMD build --keep-empty-dirs --no-resave-data  
>
> R CMD check --no-vignettes --timings 
>
> R CMD BiocCheck --build-output-file= --new-package
> 
>
>
>
> With the environment variables set up as described in the above link
>
>
> special files are not encouraged and as far as I am aware not
> allowed.  Herve who has more experience with the builders may be able to
> chime in further here.
>
>
>
>
>
>
>
> Lori Shepherd
> Bioconductor Core Team
> Roswell Park Cancer Institute
> Department of Biostatistics & Bioinformatics
> Elm & Carlton Streets
> Buffalo, New York 14263
>
>
> 
> From: Pierrick Roger 
> Sent: Friday, September 13, 2019 2:48 AM
> To: Shepherd, Lori 
> Subject: Re: [Bioc-devel] new package for accessing some chemical and
> biological databases
>
> Thank you for the example. However I do not think it is relevant. This
> package has no examples, no tests and just one vignette. The `get`
> function is part of the interface, so it makes sens to use it inside
> the vignette. But for my package biodb, there is no function to call,
> the cache works transparently.
>
> Could you please give me more details about the build process of
> packages in
> Bioconductor? Are there some environment variables set during the build
> so a package can now it is being built or checked by Bioconductor? If
> this is the case, maybe I could write a tweak in my code in order to
> download the cache when needed.
> If not, would it be possible to have them defined or to have to have a
> special file `bioc.yml` defined at the root of the package in which I
> could write a `prebuild_step` command for retrieving the cache from my
> public GitHub repos `biodb-cache`?
>
> On Thu 12 Sep 19 17:12, Shepherd, Lori wrote:
> > Please look at  SRAdb  for an example of how we would recommend
> keeping the data.
> >
> > Summary:
> > On github or wherever you would like to host and keep the data
> current, please make sure it is 

Re: [Bioc-devel] RGL warning

[Kasper Daniel Hansen]

GLX is a module for X11. You need that module installed in whatever X11
installation you have. My understanding (which is weak) is that GLX is a
standard module so it is weird it is missing.

On Tue, Sep 10, 2019 at 12:39 PM Zhezhen Wang  wrote:

> Hi
>
> I am having the following warnings and not sure what to update.
>
> Warning in rgl.init(initValue, onlyNULL) :
>   RGL: GLX extension missing on server
> Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE
>
> The package github link is here : https://github.com/xyang2uchicago/BioTIP
>
> Zhezhen
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Kasper Daniel Hansen]

Yeah, does this imply that the render operation uses (or tries to use)
ImageMagick? That's news to me, but I am not following this closely.

On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve  wrote:

> On 9/11/19 00:50, Vincent Carey wrote:
> > I seem to be running into a similar problem with BiocOncoTK on windows
> >
> > The build report for tokay1 shows:
> >
> > Loading required package: ontologyIndex
> > Invalid Parameter - /figure-html
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
> > "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
> > error code 4
> > Invalid Parameter - /figure-html
> >
> > The figure code is introduced with ```{r lkgbm,fig=TRUE,message=FALSE}
> > ... the 'convert' process is not requested by me
> >
> > Is the fig=TRUE problematic for windows?  It seems unnecessary.
>
> Not sure what's going on. A few observations:
>
> a) About 500 software packages use fig=TRUE.
>
> b) The convert warning is just a warning. The actual error in the case
> of BiocOncoTK is:
>
>Error: processing vignette 'BiocOncoTK.Rmd' failed with diagnostics:
> argument is of length zero
>
>Note that the ndexr vignette also fails with this error on tokay1
> only but it doesn't have the convert warning (this vignette does not use
> 'fig' at all). So it's not clear to me that the "argument is of length
> zero" error is related to the convert warning.
>
> c) The devel build report shows the convert warning for 4 other packages
> (CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually
> fails with a different error message:
>
>CAGEfightR:
>  colData(object1) not identical to colData(object2)
>
>CATALYST:
>  no slot of name "reducedDims" for this object of class "daFrame"
>
>CTDquerier:
>  bfcadd() failed; see warnings()
>
>specL:
>  pandoc.exe: Out of memory
>
>These errors don't seem related to the convert warning either.
>
> So I'm wondering: could it be that the convert warning is actually
> common but we generally don't see it because 'R CMD build' doesn't
> report warnings? And that we just happen to see the warning when 'R CMD
> build' fails to build a vignette.
>
> We'll investigate more.
>
> H.
>
>
> >
> > On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes 
> wrote:
> >
> >> Thanks a lot for the info! So from my understanding we dont use any
> >> trimming or editing function from ImageMagick directly. I think this is
> >> rather knitr based since we just include png files in the vignette.
> >>
> >> I guess it was an hickup since now the error is gone over night.
> >>
> >> Best regards,
> >>
> >> Christian
> >>
> >> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
> >>> You don't declare any systems requirements for ImageMagick (doing so
> >>> will probably not solve your problem, but you really should).
> >>>
> >>> Alternatively you could look into using the tools provided by the
> >>> magick package, which wraps ImageMagick.
> >>>
> >>> But it looks like you're editing PNG files for your vignette. I would
> >>> really recommend not doing so. It introduces a system dependency which
> >>> is just going to increase headaches on your end, for (perhaps) no real
> >>> tangible benefits. If you're trimming PNGs, you should be able to
> >>> achieve the same effect when using the png device(s) in R, and that
> >>> will make everything more portable anyway.
> >>>
> >>> On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes  >>> <mailto:mer...@in.tum.de>> wrote:
> >>>
> >>>  Dear BioC team,
> >>>
> >>>  I just noticed that our package is failing on the bioconductor
> build
> >>>  system during the build of the vignette on Windows and on MacOS
> >>>  platforms.
> >>>
> >>>  From the error I would guess its a problem with the installation
> >>>  of the
> >>>  ImageMagick package. Please correct me if Im wrong.
> >>>
> >>>  It goes through on travis and appveyor. Any suggestions?
> >>>
> >>>  Here are some links to the build logs:
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.riken.jp_checkResults_3.9_bioc-2DLATEST_OUTRIDER_=DwICAg=eR

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Kasper Daniel Hansen]

You don't declare any systems requirements for ImageMagick (doing so will
probably not solve your problem, but you really should).

Alternatively you could look into using the tools provided by the magick
package, which wraps ImageMagick.

But it looks like you're editing PNG files for your vignette. I would
really recommend not doing so. It introduces a system dependency which is
just going to increase headaches on your end, for (perhaps) no real
tangible benefits. If you're trimming PNGs, you should be able to achieve
the same effect when using the png device(s) in R, and that will make
everything more portable anyway.

On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes  wrote:

> Dear BioC team,
>
> I just noticed that our package is failing on the bioconductor build
> system during the build of the vignette on Windows and on MacOS platforms.
>
> From the error I would guess its a problem with the installation of the
> ImageMagick package. Please correct me if Im wrong.
>
> It goes through on travis and appveyor. Any suggestions?
>
> Here are some links to the build logs:
>
> http://bioconductor.riken.jp/checkResults/3.9/bioc-LATEST/OUTRIDER/
> https://travis-ci.org/gagneurlab/OUTRIDER
> https://ci.appveyor.com/project/c-mertes/OUTRIDER
>
> Best,
>
> Christian
>
> PS: the error message on the bioc build system:
>
>
> ##
>
> ##
> ###
> ### Running command:
> ###
> ###   chmod a+r OUTRIDER -R && C:\Users\biocbuild\bbs-3.9-bioc\R\bin\R.exe
> CMD build --keep-empty-dirs --no-resave-data OUTRIDER
> ###
>
> ##
>
> ##
>
>
> * checking for file 'OUTRIDER/DESCRIPTION' ... OK
> * preparing 'OUTRIDER':
> * checking DESCRIPTION meta-information ... OK
> * cleaning src
> * installing the package to build vignettes
> * creating vignettes ... ERROR
> --- re-building 'OUTRIDER.Rnw' using knitr
> Invalid Parameter - /deVsOutlier-1.png"
> Warning in shell(paste(c(cmd, args), collapse = " ")) :
>   'convert "figure/deVsOutlier-1.png" -trim "figure/deVsOutlier-1.png"'
> execution failed with error code 4
> 229 genes did not passed the filter due to zero counts. This is 22.9% of
> the genes.
> Sat Sep 07 01:16:53 2019: SizeFactor estimation ...
> Sat Sep 07 01:16:53 2019: Controlling for confounders ...
> Using estimated q with: 23
> Sat Sep 07 01:16:53 2019: Using the autoencoder implementation for
> controlling.
> Sat Sep 07 01:17:52 2019: Used the autoencoder implementation for
> controlling.
> Sat Sep 07 01:17:52 2019: P-value calculation ...
> Sat Sep 07 01:17:52 2019: Zscore calculation ...
> Invalid Parameter - /quick_guide-1.png"
> Warning in shell(paste(c(cmd, args), collapse = " ")) :
>   'convert "figure/quick_guide-1.png" -trim "figure/quick_guide-1.png"'
> execution failed with error code 4
> Quitting from lines 222-232 (OUTRIDER.Rnw)
> Error: processing vignette 'OUTRIDER.Rnw' failed with diagnostics:
> no lines available in input
> --- failed re-building 'OUTRIDER.Rnw'
>
> SUMMARY: processing the following file failed:
>   'OUTRIDER.Rnw'
>
> Error: Vignette re-building failed.
> Execution halted
>
> --
>
> Christian Mertes
> PhD Student / Lab Administrator
> Gagneur lab
>
> Computational Genomics
> I12 - Bioinformatics Department
> Technical University Munich
> Boltzmannstr. 3
> 85748 Garching, Germany
>
> Mail: mer...@in.tum.de
> Phone: +49-89-289-19416
> http://gagneurlab.in.tum.de
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Kasper Daniel Hansen]

There are
  importMethodsFrom(PACKAGE, NAME_OF_METHODS)
  importClassesFrom(PACKAGE, NAME_OF_METHODS)
to help with selective importing S4 methods/classes.  See section 1.5.6 of
WRE.

On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of
> the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer
> :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no
> definition for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to
> loading all these dependencies.
> > I guess because these dependencies are needed to provide for all
> required S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class
> definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's no way to define method signatures using
> > anything other than simple class names.
> >
> > It would be interesting to explore alternative ways of specifying
> > method signatures. One way would be if every package exported a "class
> > reference" (class name with package attribute, at least) for each of
> > its classes. Those could be treated like any other exported object,
> > and referenced via namespace qualification. It would require major
> > changes to the methods package but that should probably happen anyway
> > to support disambiguation when two packages define a class of the same
> > name. It would be nice to get away from the exportClasses() and
> > importClasses() stuff. File that under the "rainy year" category.
> >
> > Michael
> >
> > On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
> >  wrote:
> > >
> > > Dear Bioc devel,
> > >
> > > Is it possible to import the BSgenome class without attaching
> BiocGenerics (to keep a clean namespace during the development of
> multicrispr).
> > >
> > > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> > >
> > > (Posted earlier on BioC support<
> https://support.bioconductor.org/p/124442/> and redirected here following
> Martin's suggestion)
> > >
> > > Thankyou :-)
> > >
> > > Aditya
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
> >
> > --
> > Michael Lawrence
> > Scientist, Bioinformatics and Computational Biology
> > Genentech, A Member of the Roche Group
> > Office +1 (650) 225-7760
> > micha...@gene.com
> >
> > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Fwd: Re: Build error due to TensorFlow installation

[Kasper Daniel Hansen]

It might be true that the code is much easier on your end, but it comes
with the complexity of using TensorFlow, which is a huge dependency. And
that library can be easy or impossible to install depending on your box.  I
am not saying people shouldn't use TensorFlow, but I am saying it brings a
lot of complexities with it.

And (trying to) installing TensorFlow as part of .onLoad seems ... not the
right way to deal with this.

On Thu, Sep 5, 2019 at 6:27 AM Simon Dirmeier  wrote:

>
> Hi Herve,
>
> > All this means that if you replace some old C++ code with TensorFlow
> > then we will need to mark your package as unavailable on Windows and
> > Mac, at least for now. Sorry. I wonder if there was something wrong
> > with this old C++ code. I would recommend that you stick to it if you
> can.
> >
> The code is fine, but still an impractical complexity that doesn't need
> to exist:
>
> 1) It's hard to extend and read for others.
>
> 2) It needs a custom configure.ac.
>
> 3) Extending the package to other models/families is a huge pain, as one
> needs to derive custom coordinate descents (or other optimizers for that
> matter) for each.
>
> On the other side:
>
> 1) TF allowed me to replace like 5000 lines of source code with 100
> lines of R.
>
> 2) TF allows to easily extend with other models with just a few lines.
>
> 3) I don't need a huge test suite.
>
> 4) On GPUs it's a huge speedup.
>
> So, I'll revert the changes back on Bioc devel for now and continue
> development on another branch.
>
> Cheers,
>
> Simon
>
>
> Am 04.09.19 um 16:53 schrieb Pages, Herve:
> >
> > Hi Simon,
> >
> > On 9/3/19 09:11, Simon Dirmeier wrote:
> >> ...
> >> Do you think it would be possible to install TensorFlow and
> >> TensorFlow-Probability on the builders? I'd assume that many would
> >> profit from that.
> >>
> > As Lori mentioned at the end of her email (see below), we can't make
> > the tensorflow Python module available on our Windows builders at the
> > moment because we need to update Python to Python 3 on these machines
> > first (AFAIK tensorflow is only available for Python 3 on Windows).
> > This is something that we are currently working on.
> >
> > As for the Mac builders, we have tensorflow there but unfortunately
> > it's an old version because recent versions of are broken on El
> > Capitan (this is the Mac OS version that, for various reasons, we are
> > stuck with at the moment). This prevents us from installing the
> > tensorflow_probability module which requires a recent version of
> > tensorflow.
> >
> > The tensorflow and tensorflow_probability modules are available on our
> > Linux builders.
> >
> > All this means that if you replace some old C++ code with TensorFlow
> > then we will need to mark your package as unavailable on Windows and
> > Mac, at least for now. Sorry. I wonder if there was something wrong
> > with this old C++ code. I would recommend that you stick to it if you
> can.
> >
> > Best,
> >
> > H.
> >
> >
> >>> Right now tensorflow is unavailable on our windows server (tokay1)�as
> >>> we have not updated to python 3 (but will be in the near future)� The
> >>> windows error can be ignored for now.
> >>>
> >>>
> >>>
> >>> 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
> >>> Simon Dirmeier
> >>> *Sent:* Monday, September 2, 2019 6:08:45 AM
> >>> *To:*bioc-devel@r-project.org  
> >>> *Subject:* [Bioc-devel] Build error due to TensorFlow installation
> >>> Dear all,
> >>>
> >>> since I replaced some old C++ code with TensorFlow I am getting some
> >>> build errors on merida1 and tokay1 regarding installation (even though
> I
> >>> install TF and TF Probability during /.onLoad/)
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_netReg_merida1-2Dbuildsrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=wjC8b2uCm0PJgQ1LRO_CTrqNvfGKpEKN0N6QN23Sbd0=
> >>>
> >>> Does anyone know how I can fix this or did anyone use TF with
> >>> Bioconductor so far?
> >>>
> >>> Many thanks in advance.
> >>>
> >>> Best,
> >>>
> >>> Simon
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ��� [[alternative HTML version deleted]]
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org  mailing list
> >>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=98vYdk5e2ryxlWN99O68ty2dUHnoE23VPU9TwSF8rPc=
> >>>
> >>> This email message may contain legally privileged and/or confidential
> >>> information. If 

Re: [Bioc-devel] 'tokay1' error but passed other OS

[Kasper Daniel Hansen]

Venu, you should really follow Herve's suggestion and use R CMD check
--force-multiarch and report back the result.

On Wed, Sep 4, 2019 at 3:32 PM Shepherd, Lori 
wrote:

> Venu,
> If you can produce a minimal example that can reproduce it and open the
> issue on rtracklayer github that would be great.  Please tag me when you do
> so I can keep track of it also @lshep on GitHub
> Cheers
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* Venu Thatikonda 
> *Sent:* Wednesday, September 4, 2019 3:11:56 PM
> *To:* Kasper Daniel Hansen 
> *Cc:* Shepherd, Lori ; bioc-devel <
> bioc-devel@r-project.org>
> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>
> @Daniel, I guess using libBigWig cause even more problems while build,
> check commands as this is an non R library. But I'm not sure if this works
> out.
>
> @Lori, Thanks a lot for looking into the error. Interesting to see what's
> missing from win32. I will add the .BBSoptions file and bump the version as
> suggested. I can create a small example to reproduce the error(?), to open
> an issue at rtracklayer, please let me know if that's okay.
>
> Thank you.
>
> On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> Thanks
>>
>> My experience with rtracklayer, bigwig and windows is indeed on some
>> windows machines it works, and others it don't. Not sure what the deciding
>> factor is, but if it is truly 32 vs 64 bit, that's interesiting
>>
>> On Wed, Sep 4, 2019 at 1:51 PM Shepherd, Lori <
>> lori.sheph...@roswellpark.org> wrote:
>>
>>> I looked into this more on our builders.  The examples run fine on 64
>>> bit.  This seems to be caused by a 32-bit Windows specific ERROR from
>>> the rtracklayer summary() function for BigWigFile objects.
>>>
>>> I will open an issue with rtracklayer (when I can come up with a minimal
>>> reproducible example) and will post the issue link in your open issue on
>>> the Contributions tracker to also monitor.
>>>
>>>
>>> In the meantime you could add a file  .BBSoptions that contains the line
>>> UnsupportedPlatforms: win32  to get an accurate build report and avoid
>>> building on the 32 bit window until the issue is resolved.
>>>
>>>
>>> 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
>>> Kasper Daniel Hansen 
>>> *Sent:* Wednesday, September 4, 2019 1:41:28 PM
>>> *To:* Venu Thatikonda 
>>> *Cc:* bioc-devel 
>>> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>>>
>>> Well, yes, its the status on the build system which matters.
>>>
>>> In your case it looks like you're doing BigWig parsing. Unfortunately,
>>> some
>>> of the tools we have for reading BigWig (tracklayer) does not work
>>> reliably
>>> on Windows - sometimes it works, sometimes it doesn't. My _guess_ is that
>>> you're running into this.
>>>
>>> It would be great to get this fixed, although that is not your package's
>>> issue.  One possible alternative is
>>> https://github.com/dpryan79/libBigWig
>>> which Brent Peterson recommends. I don't know if that works on Windows,
>>> but
>>> at least its not Kent tools.
>>>
>>> Best,
>>> Kasper
>>>
>>> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > One of my packages during the review is giving an error in bioc windows
>>> > system. When I build and check from my side in a windows system, there
>>> is
>>> > no error.
>>> >
>>> > It's been over a week, not sure what's happening? Should I do something
>>> > from my side?
>>> >
>>> > Bioc issue: https://github.com/Bioconductor/Contributions/issues/1215
>>> >
>>> > Build report:
>>> >
>>> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>>> >
>>> > Any update/suggestions would be helpful.
>>> >
>>> > Thank you.
>>> >
>>> > --
>>> > Best regards
>>&g

Re: [Bioc-devel] 'tokay1' error but passed other OS

[Kasper Daniel Hansen]

Thanks

My experience with rtracklayer, bigwig and windows is indeed on some
windows machines it works, and others it don't. Not sure what the deciding
factor is, but if it is truly 32 vs 64 bit, that's interesiting

On Wed, Sep 4, 2019 at 1:51 PM Shepherd, Lori 
wrote:

> I looked into this more on our builders.  The examples run fine on 64
> bit.  This seems to be caused by a 32-bit Windows specific ERROR from the
> rtracklayer summary() function for BigWigFile objects.
>
> I will open an issue with rtracklayer (when I can come up with a minimal
> reproducible example) and will post the issue link in your open issue on
> the Contributions tracker to also monitor.
>
>
> In the meantime you could add a file  .BBSoptions that contains the line
> UnsupportedPlatforms: win32  to get an accurate build report and avoid
> building on the 32 bit window until the issue is resolved.
>
>
> 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 Kasper
> Daniel Hansen 
> *Sent:* Wednesday, September 4, 2019 1:41:28 PM
> *To:* Venu Thatikonda 
> *Cc:* bioc-devel 
> *Subject:* Re: [Bioc-devel] 'tokay1' error but passed other OS
>
> Well, yes, its the status on the build system which matters.
>
> In your case it looks like you're doing BigWig parsing. Unfortunately, some
> of the tools we have for reading BigWig (tracklayer) does not work reliably
> on Windows - sometimes it works, sometimes it doesn't. My _guess_ is that
> you're running into this.
>
> It would be great to get this fixed, although that is not your package's
> issue.  One possible alternative is https://github.com/dpryan79/libBigWig
> which Brent Peterson recommends. I don't know if that works on Windows, but
> at least its not Kent tools.
>
> Best,
> Kasper
>
> On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
> wrote:
>
> > Hi,
> >
> > One of my packages during the review is giving an error in bioc windows
> > system. When I build and check from my side in a windows system, there is
> > no error.
> >
> > It's been over a week, not sure what's happening? Should I do something
> > from my side?
> >
> > Bioc issue: https://github.com/Bioconductor/Contributions/issues/1215
> >
> > Build report:
> > http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
> >
> > Any update/suggestions would be helpful.
> >
> > Thank you.
> >
> > --
> > Best regards
> > Venu Thatikonda
> > https://itsvenu.github.io/
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> Best,
> Kasper
>
> [[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.



-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] 'tokay1' error but passed other OS

[Kasper Daniel Hansen]

Well, yes, its the status on the build system which matters.

In your case it looks like you're doing BigWig parsing. Unfortunately, some
of the tools we have for reading BigWig (tracklayer) does not work reliably
on Windows - sometimes it works, sometimes it doesn't. My _guess_ is that
you're running into this.

It would be great to get this fixed, although that is not your package's
issue.  One possible alternative is https://github.com/dpryan79/libBigWig
which Brent Peterson recommends. I don't know if that works on Windows, but
at least its not Kent tools.

Best,
Kasper

On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda 
wrote:

> Hi,
>
> One of my packages during the review is giving an error in bioc windows
> system. When I build and check from my side in a windows system, there is
> no error.
>
> It's been over a week, not sure what's happening? Should I do something
> from my side?
>
> Bioc issue: https://github.com/Bioconductor/Contributions/issues/1215
>
> Build report:
> http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html
>
> Any update/suggestions would be helpful.
>
> Thank you.
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] possible bug in R's configure check for C++11 features

[Kasper Daniel Hansen]

I'm sorry, I'm an idiot for not noticing this. That's what happens when you
have been stuck in configure/make hell for a while.

Best,
Kasper

On Tue, Sep 3, 2019 at 10:54 PM Simon Urbanek 
wrote:

> Kasper,
>
> I haven’t checked in depth, so just to clarify: you *are* setting
> CXX11=g++ so it is doing what you asked it to. Since the settings are
> inherited upwards, this implies that you are setting both CXX14 and CXX17
> to g++. So I’m not quite sure I understand your concern.
>
> Cheers,
> Simon
>
>
>
> > On Sep 3, 2019, at 9:02 PM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > I am trying to compile R under a new setup, and frankly, I have had a lot
> > of problems, but I think the stuff below points to a possible bug in R's
> > (custom) configure checks for C++11/14/17, but not for C++98.
> >
> > This is a report about R from the R-3-6 branch, with a svn checkout from
> > today, revision r77135.
> >
> > In my case the compiler name is x86_64-conda_cos6-linux-gnu-g++, not
> g++. I
> > denote this in my configure call, using the CC variable. A snippet of the
> > full configure is
> >
> > ../${SRCDIR}/configure SHELL='/bin/bash' \
> >   --prefix="${CONDA_PREFIX}/R/${R_VERSION}" \
> >   CC="x86_64-conda_cos6-linux-gnu-gcc" \
> >   CXX="x86_64-conda_cos6-linux-gnu-g++" \
> >   F77="x86_64-conda_cos6-linux-gnu-gfortran" \
> >   FC="$F77" \
> >   CFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include"\
> >   CXXFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> >   F77FLAGS="-Wall -g -O2 -mtune=amdfam10 -I${CONDA_PREFIX}/include" \
> >   CXX11="g++" \
> >   CXX11STD="-std=c++11" \
> >   CXX11FLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> >   CXX11PICFLAGS="-fPIC" \
> >
> > Where $CONDA_PREFIX is given in my script.
> >
> > The output in config.log is given below. Note that in the test for c++98,
> > it uses the "right" CC, but in the test for c++11 it uses g++. This looks
> > wrong to me:
> >
> > configure:28111: checking whether x86_64-conda_cos6-linux-gnu-g++
> supports
> > C++98 features with -std=gnu++98
> > configure:28130: x86_64-conda_cos6-linux-gnu-g++  -std=gnu++98 -c -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fpic -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cp
> > p >&5
> > configure:28130: $? = 0
> > configure:28139: result: yes
> > configure:28315: checking whether g++ -std=c++11 supports C++11 features
> > configure:28607: g++ -std=c++11 -c -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fPIC -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cpp >&5
> > ../R-3.6-src/configure: line 2355: g++: command not found
> > configure:28607: $? = 127
> > configure: failed program was:
> >
> > I have similar issues (wrong CC using when compiling the test program)
> with
> > the test for c++14, whereas the test for c++17 has empty space where the
> CC
> > variable should be?
> >
> > I can fix this issue by adding a soft link in my PATH from g++ to my
> > compiler of choice. In this case configure finishes and reports that I
> have
> > full C++17 capabilities. Weirdly, in the output, note that the C++
> compiler
> > is "wrong" again, despite my configure call:
> >
> >  Source directory:../R-3.6-src
> >  Installation directory:
> > /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/R/3.6
> >
> >  C compiler:  x86_64-conda_cos6-linux-gnu-gcc  -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  Fortran fixed-form compiler:
> >
> /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
> > -fno-optimize-sibling-calls -fopenmp -march=nocona -mtune=haswell
> > -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> > -ffunction-sections -pipe
> >
> >  Default C++ compiler:g++ -std=c++11   -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> >  C++98 compiler:  x86_64-conda_cos6-linux-gnu-g++
> -std=gnu++98
> > -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svn

[Rd] possible bug in R's configure check for C++11 features

[Kasper Daniel Hansen]

I am trying to compile R under a new setup, and frankly, I have had a lot
of problems, but I think the stuff below points to a possible bug in R's
(custom) configure checks for C++11/14/17, but not for C++98.

This is a report about R from the R-3-6 branch, with a svn checkout from
today, revision r77135.

In my case the compiler name is x86_64-conda_cos6-linux-gnu-g++, not g++. I
denote this in my configure call, using the CC variable. A snippet of the
full configure is

../${SRCDIR}/configure SHELL='/bin/bash' \
   --prefix="${CONDA_PREFIX}/R/${R_VERSION}" \
   CC="x86_64-conda_cos6-linux-gnu-gcc" \
   CXX="x86_64-conda_cos6-linux-gnu-g++" \
   F77="x86_64-conda_cos6-linux-gnu-gfortran" \
   FC="$F77" \
   CFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include"\
   CXXFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
   F77FLAGS="-Wall -g -O2 -mtune=amdfam10 -I${CONDA_PREFIX}/include" \
   CXX11="g++" \
   CXX11STD="-std=c++11" \
   CXX11FLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
   CXX11PICFLAGS="-fPIC" \

Where $CONDA_PREFIX is given in my script.

The output in config.log is given below. Note that in the test for c++98,
it uses the "right" CC, but in the test for c++11 it uses g++. This looks
wrong to me:

configure:28111: checking whether x86_64-conda_cos6-linux-gnu-g++  supports
C++98 features with -std=gnu++98
configure:28130: x86_64-conda_cos6-linux-gnu-g++  -std=gnu++98 -c -Wall
-mtune=amdfam10 -g -O2
-I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
-fpic -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cp
p >&5
configure:28130: $? = 0
configure:28139: result: yes
configure:28315: checking whether g++ -std=c++11 supports C++11 features
configure:28607: g++ -std=c++11 -c -Wall -mtune=amdfam10 -g -O2
-I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
-fPIC -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cpp >&5
../R-3.6-src/configure: line 2355: g++: command not found
configure:28607: $? = 127
configure: failed program was:

I have similar issues (wrong CC using when compiling the test program) with
the test for c++14, whereas the test for c++17 has empty space where the CC
variable should be?

I can fix this issue by adding a soft link in my PATH from g++ to my
compiler of choice. In this case configure finishes and reports that I have
full C++17 capabilities. Weirdly, in the output, note that the C++ compiler
is "wrong" again, despite my configure call:

  Source directory:../R-3.6-src
  Installation directory:
 /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/R/3.6

  C compiler:  x86_64-conda_cos6-linux-gnu-gcc  -Wall
-mtune=amdfam10 -g -O2
-I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  Fortran fixed-form compiler:
/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
-fno-optimize-sibling-calls -fopenmp -march=nocona -mtune=haswell
-ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
-ffunction-sections -pipe

  Default C++ compiler:g++ -std=c++11   -Wall -mtune=amdfam10 -g
-O2 -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  C++98 compiler:  x86_64-conda_cos6-linux-gnu-g++ -std=gnu++98
 -Wall -mtune=amdfam10 -g -O2
-I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  C++11 compiler:  g++ -std=c++11   -Wall -mtune=amdfam10 -g
-O2 -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  C++14 compiler:  g++ -std=gnu++14   -Wall -mtune=amdfam10 -g
-O2 -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  C++17 compiler:  g++ -std=gnu++17  -Wall -mtune=amdfam10 -g
-O2 -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
  Fortran free-form compiler:
 
/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
-fno-optimize-sibling-calls
  Obj-C compiler:



-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

Yes, it will build the most recent version

If the previous build failed it will even build the most recent code, even
if the code is not bumped. The exception is the following
  you update package A to version X, build succeeds
  you commit code to package A, but does not bump the version
This will not trigger.a rebuild and your latest commits will not be
reflected in the tarballs available to the community. This is why you -- in
general -- need to bump versions when you commit code.

Pro-tip: In general, you will be well served not to get too attached to
version numbers. Bump it frequently even without new functionality or bug
fixes and just live with the frequent bumping.

On Wed, Aug 14, 2019 at 12:43 PM Mike Smith  wrote:

> Yes, the Bioconductor build system will only try to build the most recent
> version in the git repository.  If it never managed to successfully build a
> particular version then that version should not appear anywhere on the Bioc
> site.  For example biomaRt is now on release 2.40.3, but version 2.40.2
> never passed all the checks, and so is absent from the archive at
> https://bioconductor.org/packages/3.9/bioc/src/contrib/Archive/biomaRt/
> In
> theory someone could get hold of it via git, anyone doing so it probably
> experienced enough to look after themselves.
>
> Best,
> Mike
>
> On Wed, 14 Aug 2019 at 18:12, Erik Fasterius 
> wrote:
>
> > Thank you for the prompt response! I will just add more versions on top
> of
> > what I have already added. Would it be correct to assume that
> Bioconductor
> > will try to build the most recent version available, even though it
> failed
> > builds for previous versions?
> >
> > Regarding the change, it was indeed a breaking change, and I thus
> believed
> > that it would have been counted as a bug-fix for the release branch.
> >
> > All the best,
> > Erik
> >
> > On 14 Aug 2019, at 17:15, Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com<mailto:kasperdanielhan...@gmail.com>>
> wrote:
> >
> > Also, it is not clear to me if this qualifies for a update to the release
> > branch. Updates to release should be restricted to critical bug fixes
> > (although if tidyr updates will break your package, that sounds like a
> > critical bug fix to me)
> >
> > Note to others: this (again) emphasizes that we may need to "copy" a
> > snapshot of CRAN into release.
> >
> > Best,
> > Kasper
> >
> > On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com<mailto:kasperdanielhan...@gmail.com>>
> wrote:
> > You cannot revert. By pushing those updates, you released a version into
> > the wild. It is true that as long as it doesn't build on the build
> servers,
> > it would have been hard to obtain for anyone, but it is still possible
> > through git. You need to update the version.
> >
> > Best,
> > Kasper
> >
> > On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> > erik.faster...@outlook.com<mailto:erik.faster...@outlook.com>> wrote:
> > I made some changes to my seqCAT package the last few days in order to
> > prepare for version 1.0.0 of tidyr, which was apparently harder than I
> > initially thought. I was also a bit too quick with pushing to
> Bioconductor
> > (both the release and devel branches), and now I’ve got several updates
> and
> > versions that don’t work - very stupid of me, I know. I do seem to have a
> > working version now, though, and I finally learnt my lesson and have NOT
> > pushed this to Bioconductor yet. Now I want to reset to the previously
> > working versions of my package (1.6.0 for release and 1.7.2 for devel)
> >
> > I did try to make (temporary) hard resets and force push these to
> > Bioconductor (as per the “reset to a previous commit” in the “abandon
> > changes” developer section), but these did not work: all I got was errors
> > say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> > (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have
> to
> > make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> > those, leaving several non-functional versions at Bioconductor? If at all
> > possible I’d like to avoid this.
> >
> > Again, I realise these problems are because of errors on my part, and
> > would like to know if I can solve them somehow or if I’ll just have to
> live
> > with them.
> > ___
> > Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
> > https://stat.ethz.c

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

You cannot revert. By pushing those updates, you released a version into
the wild. It is true that as long as it doesn't build on the build servers,
it would have been hard to obtain for anyone, but it is still possible
through git. You need to update the version.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius 
wrote:

> I made some changes to my seqCAT package the last few days in order to
> prepare for version 1.0.0 of tidyr, which was apparently harder than I
> initially thought. I was also a bit too quick with pushing to Bioconductor
> (both the release and devel branches), and now I’ve got several updates and
> versions that don’t work - very stupid of me, I know. I do seem to have a
> working version now, though, and I finally learnt my lesson and have NOT
> pushed this to Bioconductor yet. Now I want to reset to the previously
> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>
> I did try to make (temporary) hard resets and force push these to
> Bioconductor (as per the “reset to a previous commit” in the “abandon
> changes” developer section), but these did not work: all I got was errors
> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> those, leaving several non-functional versions at Bioconductor? If at all
> possible I’d like to avoid this.
>
> Again, I realise these problems are because of errors on my part, and
> would like to know if I can solve them somehow or if I’ll just have to live
> with them.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

Also, it is not clear to me if this qualifies for a update to the release
branch. Updates to release should be restricted to critical bug fixes
(although if tidyr updates will break your package, that sounds like a
critical bug fix to me)

Note to others: this (again) emphasizes that we may need to "copy" a
snapshot of CRAN into release.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> You cannot revert. By pushing those updates, you released a version into
> the wild. It is true that as long as it doesn't build on the build servers,
> it would have been hard to obtain for anyone, but it is still possible
> through git. You need to update the version.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> erik.faster...@outlook.com> wrote:
>
>> I made some changes to my seqCAT package the last few days in order to
>> prepare for version 1.0.0 of tidyr, which was apparently harder than I
>> initially thought. I was also a bit too quick with pushing to Bioconductor
>> (both the release and devel branches), and now I’ve got several updates and
>> versions that don’t work - very stupid of me, I know. I do seem to have a
>> working version now, though, and I finally learnt my lesson and have NOT
>> pushed this to Bioconductor yet. Now I want to reset to the previously
>> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>>
>> I did try to make (temporary) hard resets and force push these to
>> Bioconductor (as per the “reset to a previous commit” in the “abandon
>> changes” developer section), but these did not work: all I got was errors
>> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
>> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
>> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
>> those, leaving several non-functional versions at Bioconductor? If at all
>> possible I’d like to avoid this.
>>
>> Again, I realise these problems are because of errors on my part, and
>> would like to know if I can solve them somehow or if I’ll just have to live
>> with them.
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> --
> Best,
> Kasper
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] gfortran 9 quantreg bug

[Kasper Daniel Hansen]

Dirk,

Thanks for the blog post on this, and the pointers in this email.

I have a question: it seems to me that you end up using a different
compiler for the package (quantreg) than was used to build R itself. As I
understand ABI changes, this is considered unsupported (ok, that depends on
what version of gcc/gfortran was used to build R, but there has been a lot
of ABI changes in GCC). Is that correct? I understand that this shortcut
makes it much easier to use different compilers, and might work for Roger's
usecase, but I was wondering about this issue of using a different compiler
for packages. Is this something I should worry about?

Best,
Kasper

On Sun, Aug 4, 2019 at 10:41 AM Dirk Eddelbuettel  wrote:

>
> Roger,
>
> On 4 August 2019 at 06:48, Koenker, Roger W wrote:
> | I’d like to solicit some advice on a debugging problem I have in the
> quantreg package.
> | Kurt and Brian have reported to me that on Debian machines with gfortran
> 9
> |
> | library(quantreg)
> | f = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5))
> | plot(f)
> |
> | fails because summary() produces bogus estimates of the coefficient
> bounds.
> | This example has been around in my R package from the earliest days of
> R, and
> | before that in various incarnations of S.  The culprit is apparently
> rqbr.f which is
> | even more ancient, but must have something that gfortran 9 doesn’t
> approve of.
> |
> | I note that in R-devel there have been some other issues with gfortran
> 9, but these seem
> | unrelated to my problem.  Not having access to a machine with an
> R/gfortran9
> | configuration, I can’t  apply my rudimentary debugging methods.  I’ve
> considered
> | trying to build gfortran on my mac air and then building R from source,
> but before
> | going down this road, I wondered whether others had other suggestions, or
> | advice about  my proposed route.  As far as I can see there are not yet
> | binaries for gfortran 9 for osx.
>
> Maybe installing and running Docker on your mac is an alternative?
>
> Minimally viable example using
>
>   a) docker (on Linux, but it is portable) and
>
>   b) the current official 'r-base' container (an alias to our Rocker
> r-base container)
>
> r-base is begged to Debian testing, and also allows you to get Debian
> unstable.  Below I fire up the container, tell it to use bash (not R) and
> update
>
>   edd@rob:~/git$ docker run --rm -ti r-base bash
>   root@1307193fadf4:/#
>   root@1307193fadf4:/# apt-get update
>   Get:1 http://cdn-fastly.deb.debian.org/debian sid InRelease [149 kB]
>   Get:2 http://cdn-fastly.deb.debian.org/debian testing InRelease [117 kB]
>   Get:3 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages
> [8,385 kB]
>   Get:4 http://cdn-fastly.deb.debian.org/debian testing/main amd64
> Packages [7,918 kB]
>   Fetched 16.6 MB in 4s (4,649 kB/s)
>   Reading package lists... Done
>   root@1307193fadf4:/# apt-cache policy gcc-9
>   gcc-9:
> Installed: (none)
> Candidate: 9.1.0-10
> Version table:
>9.1.0-10 990
>   990 http://deb.debian.org/debian testing/main amd64 Packages
>   500 http://http.debian.net/debian sid/main amd64 Packages
>   root@1307193fadf4:/# apt-cache policy gfortran-9
>   gfortran-9:
> Installed: (none)
> Candidate: 9.1.0-10
> Version table:
>9.1.0-10 990
>   990 http://deb.debian.org/debian testing/main amd64 Packages
>   500 http://http.debian.net/debian sid/main amd64 Packages
>   root@1307193fadf4:/#
>
> At this point it just a matter of actually installing gcc-9 and gfortran-9
> (via apt-get install ...), and setting CC, FC, F77 and whichever other
> environment variables the R build reflect to build quantreg.
>
> That said, this will be Debian's standard gfortran-9.  What is at times a
> little frustrating is that some of the builds used by some of the CRAN
> tests
> use local modifications which make their behaviour a little harder to
> reproduce.  I have an open issue with my (also old and stable) digest
> package
> which goes belly-up on a clang-on-Fedora build and nowhere else -- and I
> have
> been unable to reproduce this too.
>
> For such cases, having Docker container would be one possible way of
> giving access to the test environment to make it accessible to more users.
>
> Best,  Dirk
>
>
> |
> | Thanks,
> | Roger
> |
> | Roger Koenker
> | r.koen...@ucl.ac.uk
> | Department of Economics, UCL
> | London  WC1H 0AX.
> |
> |
> |
> |   [[alternative HTML version deleted]]
> |
> | __
> | R-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

Re: [Bioc-devel] tokay1 C++14 compiler

[Kasper Daniel Hansen]

Well, that's pretty clear. The compiler apparently doesn't support C++14
(perhaps ask about this on the Stan support - it suggests that Stan doesn't
run on Windows with default Rtools). When you delay compiling the models to
runtime, of course the package builds - it just won't work for any user.

Best,
Kasper

On Mon, Jul 29, 2019 at 1:54 PM Simo Kitanovski 
wrote:

> Surprisingly, if I design the package such that the stan models are
> compiled only at run-time I get no issues -> all servers build the package
> correctly. (https://github.com/Bioconductor/Contributions/issues/1187)
>
> On the other hand, if I follow the rstan instructions on how to design an
> R package that depends on rstan, based on which the stan models are
> compiled only once during the build, then I get the previously mentioned
> failure only on the windows-based server.
>
> BTW: Recent updates from stan community suggest that the new rstan version
> 2.20 will reduce the model compilation time from ~35sec to ~7sec, which
> makes the decision of sticking with the run-time compilation setup not so
> bad.
> On 29.07.19 8:37 nachm., Kasper Daniel Hansen wrote:
>
> My understanding - and I could be wrong - is that Stan compiles a model,
> so the compiler needs to be available at run time and not just at build
> time.
>
> On Thu, Jul 25, 2019 at 4:02 PM Simo Kitanovski <
> simo.kitanov...@uni-due.de> wrote:
>
>> Thanks!
>>
>> I will try to revise the code to avoid CXX14 if this is that case.
>>
>> Best
>>
>>
>> On 25.07.19 11:52 nachm., Martin Morgan wrote:
>> > Windows (and macOS) CRAN packages are installed as binaries (as
>> experienced by the typical user), so don't need compilation-- Rstan is
>> built by CRAN through whatever magic / agreement.
>> >
>> > The paragraph at the very end of
>> >
>> >
>> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-C_002b_002b14-code
>> >
>> > suggests
>> >
>> > Note that g++ 4.9.x (as used for R on Windows at the time of writing)
>> has only partial C++14 support, and the flag to obtain that support is not
>> included in the default Windows build of R
>> >
>> > so my understanding of this is that CXX14 is not supported on Windows.
>> The options are either to revise your code to avoid CXX14 or to anticipate
>> that your package will be 'Unsupported on Windows' (thereby losing 1/2 your
>> user base).
>> >
>> > The expert on this (Hervé) will not be back for several days.
>> >
>> > Martin
>> >
>> > On 7/25/19, 6:33 PM, "Bioc-devel on behalf of Kasper Daniel Hansen" <
>> bioc-devel-boun...@r-project.org on behalf of
>> kasperdanielhan...@gmail.com> wrote:
>> >
>> >  What's weird here is that you supposedly depend on rstan which also
>> >  requires a C++14. How can the build system have that package
>> installed
>> >  without having a compliant compiler?
>> >
>> >
>> >  On Thu, Jul 25, 2019 at 12:05 PM Simo Kitanovski <
>> simo.kitanov...@uni-due.de>
>> >  wrote:
>> >
>> >  > Hello Bioconductor community,
>> >  >
>> >  > I maintain the Bioconductor package genphen which depends on
>> rstan for
>> >  > MCMC sampling. To build the package one needs a C++14 compiler.
>> >  >
>> >  > I have no problem building the package on malbec1 and merida1,
>> but not
>> >  > on tokay1. Any idea of what might have gone wrong on this server
>> and how
>> >  > to use C++14? I have submitted a new package (IgGeneUsage) which
>> also
>> >  > uses rstan and have the same problem (see build report below).
>> >  >
>> >  > BTW: why do we see this under the C++14 compiler box for tokay1:
>> >  > Compiler version (' --version' output):
>> >  > '--version' is not recognized as an internal or external command,
>> >  > operable program or batch file.
>> >  >
>> >  > Any ideas?
>> >  >
>> >  > Best
>> >  >
>> >  > ===
>> >  >
>> >  >   R CMD BUILD
>> >  >
>> >  > ===
>> >  > * checking for file 'IgGeneUsage/DESCRIPTION' ... OK
>> >  > * preparing 'IgGeneUsage':
>> >  > * checking DESCRIPTION meta-information ... OK
>> >  > * cleanin

Re: [Bioc-devel] tokay1 C++14 compiler

[Kasper Daniel Hansen]

My understanding - and I could be wrong - is that Stan compiles a model, so
the compiler needs to be available at run time and not just at build time.

On Thu, Jul 25, 2019 at 4:02 PM Simo Kitanovski 
wrote:

> Thanks!
>
> I will try to revise the code to avoid CXX14 if this is that case.
>
> Best
>
>
> On 25.07.19 11:52 nachm., Martin Morgan wrote:
> > Windows (and macOS) CRAN packages are installed as binaries (as
> experienced by the typical user), so don't need compilation-- Rstan is
> built by CRAN through whatever magic / agreement.
> >
> > The paragraph at the very end of
> >
> >
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-C_002b_002b14-code
> >
> > suggests
> >
> > Note that g++ 4.9.x (as used for R on Windows at the time of writing)
> has only partial C++14 support, and the flag to obtain that support is not
> included in the default Windows build of R
> >
> > so my understanding of this is that CXX14 is not supported on Windows.
> The options are either to revise your code to avoid CXX14 or to anticipate
> that your package will be 'Unsupported on Windows' (thereby losing 1/2 your
> user base).
> >
> > The expert on this (Hervé) will not be back for several days.
> >
> > Martin
> >
> > On 7/25/19, 6:33 PM, "Bioc-devel on behalf of Kasper Daniel Hansen" <
> bioc-devel-boun...@r-project.org on behalf of kasperdanielhan...@gmail.com>
> wrote:
> >
> >  What's weird here is that you supposedly depend on rstan which also
> >  requires a C++14. How can the build system have that package
> installed
> >  without having a compliant compiler?
> >
> >
> >  On Thu, Jul 25, 2019 at 12:05 PM Simo Kitanovski <
> simo.kitanov...@uni-due.de>
> >  wrote:
> >
> >  > Hello Bioconductor community,
> >  >
> >  > I maintain the Bioconductor package genphen which depends on
> rstan for
> >  > MCMC sampling. To build the package one needs a C++14 compiler.
> >  >
> >  > I have no problem building the package on malbec1 and merida1,
> but not
> >  > on tokay1. Any idea of what might have gone wrong on this server
> and how
> >  > to use C++14? I have submitted a new package (IgGeneUsage) which
> also
> >  > uses rstan and have the same problem (see build report below).
> >  >
> >  > BTW: why do we see this under the C++14 compiler box for tokay1:
> >  > Compiler version (' --version' output):
> >  > '--version' is not recognized as an internal or external command,
> >  > operable program or batch file.
> >  >
> >  > Any ideas?
> >  >
> >  > Best
> >  >
> >  > ===
> >  >
> >  >   R CMD BUILD
> >  >
> >  > ===
> >  > * checking for file 'IgGeneUsage/DESCRIPTION' ... OK
> >  > * preparing 'IgGeneUsage':
> >  > * checking DESCRIPTION meta-information ... OK
> >  > * cleaning src
> >  > * installing the package to build vignettes
> >  >---
> >  > * installing *source* package 'IgGeneUsage' ...
> >  > ** using staged installation
> >  > ** libs
> >  > Error in .shlib_internal(args) :
> >  >C++14 standard requested but CXX14 is not defined
> >  > * removing
> >  >
> >  >
> 'C:/Users/pkgbuild/AppData/Local/Temp/RtmpUDyHnY/Rinst315c22dc5ac/IgGeneUsage'
> >  >---
> >  > ERROR: package installation failed
> >  >
> >  > ___
> >  > Bioc-devel@r-project.org mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >  >
> >
> >
> >  --
> >  Best,
> >  Kasper
> >
> >   [[alternative HTML version deleted]]
> >
> >  ___
> >  Bioc-devel@r-project.org mailing list
> >  https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] tokay1 C++14 compiler

[Kasper Daniel Hansen]

What's weird here is that you supposedly depend on rstan which also
requires a C++14. How can the build system have that package installed
without having a compliant compiler?


On Thu, Jul 25, 2019 at 12:05 PM Simo Kitanovski 
wrote:

> Hello Bioconductor community,
>
> I maintain the Bioconductor package genphen which depends on rstan for
> MCMC sampling. To build the package one needs a C++14 compiler.
>
> I have no problem building the package on malbec1 and merida1, but not
> on tokay1. Any idea of what might have gone wrong on this server and how
> to use C++14? I have submitted a new package (IgGeneUsage) which also
> uses rstan and have the same problem (see build report below).
>
> BTW: why do we see this under the C++14 compiler box for tokay1:
> Compiler version (' --version' output):
> '--version' is not recognized as an internal or external command,
> operable program or batch file.
>
> Any ideas?
>
> Best
>
> ===
>
>   R CMD BUILD
>
> ===
> * checking for file 'IgGeneUsage/DESCRIPTION' ... OK
> * preparing 'IgGeneUsage':
> * checking DESCRIPTION meta-information ... OK
> * cleaning src
> * installing the package to build vignettes
>---
> * installing *source* package 'IgGeneUsage' ...
> ** using staged installation
> ** libs
> Error in .shlib_internal(args) :
>C++14 standard requested but CXX14 is not defined
> * removing
>
> 'C:/Users/pkgbuild/AppData/Local/Temp/RtmpUDyHnY/Rinst315c22dc5ac/IgGeneUsage'
>---
> ERROR: package installation failed
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] use -Wa, -mbig-obj -O3 when building package under Windows

[Kasper Daniel Hansen]

[ This is a crazy bug where you have to increase optimization. ]

I some to add here. I am involved in at least two packages which requires
overriding the optimization switch to downgrade optimization. You have an
additional problem where you need to add additional flags.

The solution in affxparser (see the source) is a custom compiler call where
we place -O0 before the system/package compiler flags. This is not a great
solution as it assumes that the compiler knows about -O notation (which is
true for GCC but not a true assumption everywhere).

In Rgraphviz I have the same problem (but not solved yet because of ...
time). The issue here is that recent GCCs (v8 and higher) cannot be used
with -O3 but needs -O2. I have started to think about a better solution
than affxparser, to be used by the community, but have been a bit stumped.
Preferably I would like to use autoconf macro for detecting GCC, but when
we compile a package we are using the compiler encoded in R (aka $CC). So
somehow I want to run autoconf "detect which compiler is used" but for a
specific compiler. This is probably possible, but I don't know how right
now.

Then, conditional on GCC I plan to do a regex which replaces -O3 with -O2.
This is not perfect either because the different -O3 optimizations can be
supplied as individual flags, and I don't know which flag it is which
breaks GCC. But it is must closer to the right solution. I don't know if
regex/sed'ing is better than overriding by changing the order as in
affxparser, but having the ability to do a conditional in Makevars would be
good. Of course, the autoconf route does not address Windows, but I think
we can assume / count on the fact that the RTools pipeline is used (aka, it
is always GCC).

I would be happy to communicate more on this, to get this sorted out. It
has been a todo list item for me, for a while, and I should really try to
resolve it.

But for a quick fix, look at affxparser.

Best,
Kasper

On Fri, May 24, 2019 at 10:16 AM Ramon Diaz-Uriarte 
wrote:

>
> Dear All,
>
> For a package we develop, OncoSimulR
> (https://bioconductor.org/packages/release/bioc/html/OncoSimulR.html), we
> have added new functionality
> (https://github.com/rdiaz02/OncoSimul/tree/freq-dep-fitness) that uses the
> ExprTk library[1] for parsing and evaluation of mathematical
> expressions. This works fine under Linux. But it is known[2] that ExprTk
> can fail when using MinGW with the "too many sections" error.
>
>
> A solution that has been suggested is to use -Wa,-mbig-obj with -O3 [3].
> But I am unable to have R compile the package with -O3; -O3 is never
> placed at the right of the default -O2 no matter what I set in
> Makevars.win[4].
>
>
>
> Any suggestions?
>
> Thanks,
>
>
> R.
>
>
>
> [1] http://www.partow.net/programming/exprtk/index.html
> [2] https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/
> .
> [3] https://github.com/MrKepzie/Natron/blob/master/Engine/ExprTk.cpp
> "// exprtk requires -Wa,-mbig-obj on mingw, but there is a bug that
> prevents linking if not using -O3"
>
> See also, for example,
> https://discourse.mc-stan.org/t/too-many-sections/6261
>
> [4]
>
> https://stackoverflow.com/questions/23414448/r-makevars-file-to-overwrite-r-cmds-default-g-options
>
> Our package has
>
> CXX_STD = CXX11
>
>
> And I've tried:
>
>
> ## To the left of -O2
> PKG_CXXFLAGS = -Wa,-mbig-obj -O3
>
> ## To the left of -O2
> PKG_CXXFLAGS += -Wa,-mbig-obj -O3
>
>
> ## Also to the left of -O2
> PKG_CPPFLAGS = -Wa,-mbig-obj -O3
>
> ## Also to the left of -O2
> PKG_CPPFLAGS += -Wa,-mbig-obj -O3
>
> ## Ignored
> PKG_CXX11FLAGS = -Wa,-mbig-obj -O3
> ## Ignored
> PKG_CXX11FLAGS += -Wa,-mbig-obj -O3
>
>
>
>
> --
> 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
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] loading database package changes random number

[Kasper Daniel Hansen]

It seems to me that BiocParallel should not touch the parallel stream at
load. I don't see why that is necessary, but ok, I just have a vague
understanding of why its doing it, so perhaps I am wrong.

On Thu, May 23, 2019 at 4:29 AM Steffi Grote 
wrote:

> Thank you Martin, that's exactly the problem.
> So for now I will just leave it like it is without setting a seed inside a
> function,
> and hope that the behaviour of DelayedArray might be updated. Anyway, I
> don't think it is a big problem.
>
> Best,
> Steffi
>
> > On May 22, 2019 at 5:02 PM Martin Morgan 
> wrote:
> >
> >
> > I think the problem is that, even if the user were to set.seed(), it
> will have different consequences depending on whether DelayedArray is
> already loaded, or not yet loaded. DelayedArray gets loaded in some way
> that is not transparent to the user, as a dependency-of-a-dependency-of-an
> annotation package.
> >
> > I guess an acceptable solution would be for DelayedArray to remember and
> restore the random number seed before creating a BiocParallel param, with
> an edge case being that .Random.seed is NULL in a new R session.
> >
> > Martin
> >
> > On 5/22/19, 9:57 AM, "Kasper Daniel Hansen" <
> kasperdanielhan...@gmail.com> wrote:
> >
> > Why don't you let this be under the user's control and not do this
> at all. People should know that reproducibility of random numbers requires
> setting the seed, but that is best done by the user and not a package
> author.
> >
> > On Wed, May 22, 2019 at 9:30 AM Steffi Grote <
> steffi_gr...@eva.mpg.de> wrote:
> >
> >
> > Hi all,
> >
> > I tried to circumvent the problem by adding an optional seed as
> parameter like this:
> >
> > my_fun = function(..., seed = NULL){
> >
> > code that might change the RNG
> >
> > if (!is.null(seed)){
> > set.seed(seed)
> > }
> >
> > code that runs permutations
> > }
> >
> > which solves the reproducibility issue, but gives me a Warning in
> BiocCheck:
> > * WARNING: Remove set.seed usage in R code
> >   Found in R/ directory functions:
> > my_fun()
> >
> > What is the best way to deal with this?
> >
> > Thanks in advance,
> > Steffi
> >
> >
> > > On April 12, 2019 at 1:10 AM Martin Morgan <
> mtmorgan.b...@gmail.com> wrote:
> > >
> > >
> > > That easy strategy wouldn't work, for instance two successive
> calls to MulticoreParam() would get the same port assigned, rather than the
> contract of a 'random' port in a specific range; the port can be assigned
> by the manager.port= argument if the user wants
> >  to avoid random assignment. I could maintain a separate random
> number stream in BiocParallel for what amounts to a pretty trivial and
> probably dubious strategy [choosing random ports in hopes that one is not
> in use], but that starts to sound like a more substantial
> >  feature.
> > >
> > > Martin
> > >
> > > On 4/11/19, 7:06 PM, "Pages, Herve"  wrote:
> > >
> > > Hi Steffi,
> > >
> > > Any code that gets called between your calls to set.seed() and
> runif()
> > > could potentially use the random number generator. So the
> sequence
> > > set.seed(123); runif(1) is only guaranteed to be deterministic
> if no
> > > other code is called in between, or if the code called in
> between does
> > > not use the random number generator (but if that code is not
> under your
> > > control it could do anything).
> > >
> > > @Martin: I'll look at your suggestion for DelayedArray. An
> easy
> > > workaround would be to avoid changing the RNG state in
> BiocParallel by
> > > having .snowPort() make a copy of .Random.seed (if it exists)
> before
> > > calling runif() and restoring it on exit.
> > >
> > > H.
> > >
> > > On 4/11/19 15:25, Martin Morgan wrote:
> > > > This is actually from a dependency DelayedArray which, on
> load, calls DelayedArray::setAutoBPPARAM, which calls
> BiocParallel::MulticoreParam(), which uses the random number generator to
> select a random port for connection.
> > > >
> > > > A different approach would be for DelayedArray to respect
> the user

Re: [Bioc-devel] loading database package changes random number

[Kasper Daniel Hansen]

Why don't you let this be under the user's control and not do this at all.
People should know that reproducibility of random numbers requires setting
the seed, but that is best done by the user and not a package author.

On Wed, May 22, 2019 at 9:30 AM Steffi Grote 
wrote:

> Hi all,
>
> I tried to circumvent the problem by adding an optional seed as parameter
> like this:
>
> my_fun = function(..., seed = NULL){
>
> code that might change the RNG
>
> if (!is.null(seed)){
> set.seed(seed)
> }
>
> code that runs permutations
> }
>
> which solves the reproducibility issue, but gives me a Warning in
> BiocCheck:
> * WARNING: Remove set.seed usage in R code
>   Found in R/ directory functions:
> my_fun()
>
> What is the best way to deal with this?
>
> Thanks in advance,
> Steffi
>
>
> > On April 12, 2019 at 1:10 AM Martin Morgan 
> wrote:
> >
> >
> > That easy strategy wouldn't work, for instance two successive calls to
> MulticoreParam() would get the same port assigned, rather than the contract
> of a 'random' port in a specific range; the port can be assigned by the
> manager.port= argument if the user wants to avoid random assignment. I
> could maintain a separate random number stream in BiocParallel for what
> amounts to a pretty trivial and probably dubious strategy [choosing random
> ports in hopes that one is not in use], but that starts to sound like a
> more substantial feature.
> >
> > Martin
> >
> > On 4/11/19, 7:06 PM, "Pages, Herve"  wrote:
> >
> > Hi Steffi,
> >
> > Any code that gets called between your calls to set.seed() and
> runif()
> > could potentially use the random number generator. So the sequence
> > set.seed(123); runif(1) is only guaranteed to be deterministic if no
> > other code is called in between, or if the code called in between
> does
> > not use the random number generator (but if that code is not under
> your
> > control it could do anything).
> >
> > @Martin: I'll look at your suggestion for DelayedArray. An easy
> > workaround would be to avoid changing the RNG state in BiocParallel
> by
> > having .snowPort() make a copy of .Random.seed (if it exists) before
> > calling runif() and restoring it on exit.
> >
> > H.
> >
> > On 4/11/19 15:25, Martin Morgan wrote:
> > > This is actually from a dependency DelayedArray which, on load,
> calls DelayedArray::setAutoBPPARAM, which calls
> BiocParallel::MulticoreParam(), which uses the random number generator to
> select a random port for connection.
> > >
> > > A different approach would be for DelayedArray to respect the
> user's configuration and use bpparam(), or perhaps look at the class of
> bpparam() and tell the user they should, e.g.,
> BiocParallel::register(SerialParam()) if that's appropriate, or use
> registered("MulticoreParam") or registered("SerialParam") if available
> (they are by default) rather than creating an ad-hoc instance.
> > >
> > > Martin
> > >
> > > On 4/11/19, 10:17 AM, "Bioc-devel on behalf of Steffi Grote" <
> bioc-devel-boun...@r-project.org on behalf of steffi_gr...@eva.mpg.de>
> wrote:
> > >
> > >  Hi all,
> > >  I found out that example code for my package GOfuncR yields a
> different result the first time it's executed, despite setting a seed. All
> the following executions are identical.
> > >  It turned out that loading the database package
> 'Homo.sapiens' changed the random numbers:
> > >
> > >  set.seed(123)
> > >  runif(1)
> > >  # [1] 0.2875775
> > >
> > >  set.seed(123)
> > >  suppressWarnings(suppressMessages(require(Homo.sapiens)))
> > >  runif(1)
> > >  # [1] 0.7883051
> > >
> > >  set.seed(123)
> > >  runif(1)
> > >  # [1] 0.2875775
> > >
> > >  Is that known or expected behaviour?
> > >  Should I not load a package inside a function that later uses
> random numbers?
> > >
> > >  Thanks in advance,
> > >  Steffi
> > >
> > >  ___
> > >  Bioc-devel@r-project.org mailing list
> > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8XXamcpEeef966i7IGk_3aE9GMJodKAzXwWW4fL_hrI=KoHGLM0HbP4whRZLG4ol66_q1qkg9E0LjFHObDqgNuo=
> > >
> >
> > --
> > 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
> 

Re: [Bioc-devel] InteractionSet for structural variants

[Kasper Daniel Hansen]

This is confusing the SV calling with the issue of moving between
coordinate systems which exists even with great/perfect genomes. Good point
on deletions and the new system, but it is nevertheless important

People do this for example for some of the new mouse genomes using modmap.

On Tue, May 21, 2019 at 10:25 AM Daniel Cameron 
wrote:

> We're never going to have great support for genome coordinate systems for
> SV due to the intrinsic complexity involved. Even something as simple as a
> deletion is problematic if the coordinate system change results in
> additional sequence in the deleted region (is that also deleted or not?),
> or some of the spanned/end-point sequence gets moved to a different
> chromosome. Sure, you can make approximations but it's never going to be a
> good/great results. To get a good result you'd need to rerun your SV
> calling pipeline in your new coordinate system. A lot more effort, but I'd
> have at least some confidence in the results.
>
> On Wed, May 22, 2019 at 12:07 AM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> I know little about SV and the associated software, but it is clear to me
>> that we will see a lot of "personal" genomes in the future and having the
>> ability to move between different reference genomes (coordinate systems)
>> will be something I think we should think about having good/great support
>> for.
>>
>> On Tue, May 21, 2019 at 9:37 AM Michael Lawrence via Bioc-devel <
>> bioc-devel@r-project.org> wrote:
>>
>> > The new package StructuralVariantAnnotation is worth mentioning. It
>> > operates on the general "breakend" notation so should be able to
>> represent
>> > any type of structural variant.
>> >
>> > On Tue, May 21, 2019 at 3:22 AM Sean Davis  wrote:
>> >
>> > > On Tue, May 21, 2019 at 2:54 AM Aaron Lun <
>> > > infinite.monkeys.with.keyboa...@gmail.com> wrote:
>> > >
>> > > > > Thanks for your response. So far my intention is to to plot them
>> and
>> > I
>> > > > > do not intend on performing any other operation. The first step
>> would
>> > > be
>> > > > > read in the VCF file and transform it into a meaningful object
>> and I
>> > > was
>> > > > > hoping there was a core package already taking care of that, but I
>> > get
>> > > > > from your answer that there's no such functionality implemented.
>> > > >
>> > > > Not to my knowledge... but if you're planning on writing some
>> relevant
>> > > > functions, I'm sure we could find a home for it somewhere.
>> > > >
>> > >
>> > > I do have a couple of simple functions in VCFWrenchR (not in Bioc),
>> but
>> > > like much VCF code, it probably misses a bunch of edge cases. The
>> > functions
>> > > target VRanges, not interactionsets.
>> > >
>> > > https://github.com/seandavi/VCFWrenchR
>> > >
>> > > Sean
>> > >
>> > >
>> > > > -A
>> > > >
>> > > > > El 5/18/19 a las 4:47 AM, Aaron Lun escribió:
>> > > > >> I would say that it depends on what operations you intend to
>> perform
>> > > > >> on them. You can _store_ things any way you like, but the trick
>> is
>> > to
>> > > > >> ensure that operations and manipulations on those things are
>> > > > >> consistent and meaningful. It is not obvious that there are
>> > meaningful
>> > > > >> common operations that one might want to apply to all structural
>> > > > >> variants.
>> > > > >>
>> > > > >> For example, translocations involve two genomic regions (i.e.,
>> the
>> > two
>> > > > >> bits that get stuck together) and so are inherently
>> > two-dimensional. A
>> > > > >> lot of useful operations will be truly translocation-specific,
>> e.g.,
>> > > > >> calculation of distances between anchor regions, identification
>> of
>> > > > >> bounding boxes in two-dimensional space. These operations will be
>> > > > >> meaningless to 1-dimensional variants on the linear genome, e.g.,
>> > > > >> CNVs, inversions. The converse also applies where operations on
>> the
>> > > > >> linear genome have no single equivale

Re: [Bioc-devel] InteractionSet for structural variants

[Kasper Daniel Hansen]

I know little about SV and the associated software, but it is clear to me
that we will see a lot of "personal" genomes in the future and having the
ability to move between different reference genomes (coordinate systems)
will be something I think we should think about having good/great support
for.

On Tue, May 21, 2019 at 9:37 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> The new package StructuralVariantAnnotation is worth mentioning. It
> operates on the general "breakend" notation so should be able to represent
> any type of structural variant.
>
> On Tue, May 21, 2019 at 3:22 AM Sean Davis  wrote:
>
> > On Tue, May 21, 2019 at 2:54 AM Aaron Lun <
> > infinite.monkeys.with.keyboa...@gmail.com> wrote:
> >
> > > > Thanks for your response. So far my intention is to to plot them and
> I
> > > > do not intend on performing any other operation. The first step would
> > be
> > > > read in the VCF file and transform it into a meaningful object and I
> > was
> > > > hoping there was a core package already taking care of that, but I
> get
> > > > from your answer that there's no such functionality implemented.
> > >
> > > Not to my knowledge... but if you're planning on writing some relevant
> > > functions, I'm sure we could find a home for it somewhere.
> > >
> >
> > I do have a couple of simple functions in VCFWrenchR (not in Bioc), but
> > like much VCF code, it probably misses a bunch of edge cases. The
> functions
> > target VRanges, not interactionsets.
> >
> > https://github.com/seandavi/VCFWrenchR
> >
> > Sean
> >
> >
> > > -A
> > >
> > > > El 5/18/19 a las 4:47 AM, Aaron Lun escribió:
> > > >> I would say that it depends on what operations you intend to perform
> > > >> on them. You can _store_ things any way you like, but the trick is
> to
> > > >> ensure that operations and manipulations on those things are
> > > >> consistent and meaningful. It is not obvious that there are
> meaningful
> > > >> common operations that one might want to apply to all structural
> > > >> variants.
> > > >>
> > > >> For example, translocations involve two genomic regions (i.e., the
> two
> > > >> bits that get stuck together) and so are inherently
> two-dimensional. A
> > > >> lot of useful operations will be truly translocation-specific, e.g.,
> > > >> calculation of distances between anchor regions, identification of
> > > >> bounding boxes in two-dimensional space. These operations will be
> > > >> meaningless to 1-dimensional variants on the linear genome, e.g.,
> > > >> CNVs, inversions. The converse also applies where operations on the
> > > >> linear genome have no single equivalent in the two-dimensional case.
> > > >>
> > > >> So, I would be inclined to store them separately. If you must keep
> > > >> them in one object, just lump them into a List with "translocation"
> > > >> (GInteractions), "cnv" (GRanges) and "inversion" (another GRanges)
> > > >> elements, and people/programs can pull out bits and pieces as
> needed.
> > > >>
> > > >> -A
> > > >>
> > > >>
> > > >> On 5/17/19 4:38 AM, Bernat Gel Moreno wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> Is there any standard recommended container for genomic structural
> > > >>> variants? I think InteractionSet would work fine for translocation
> > and
> > > >>> GRanges for inversions and copy number changes, but I don't know
> what
> > > >>> would be the recommended way to store them all together using
> > standard
> > > >>> Bioconductor objects.
> > > >>>
> > > >>> And actually, is there any package that would load a SV VCF by
> lumpy
> > or
> > > >>> delly and build that object?
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> Bernat
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
>
> Michael Lawrence
>
> Scientist, Bioinformatics and Computational Biology
>
> Genentech , A Member of the Roche Group
>
> Office +1 (650) 225-7760
>
> micha...@gene.com 
>
>
> Join Genentech on LinkedIn  |
> Twitter
> <
> https://twitter.com/genentech?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
> >
> | Facebook  | Instagram
>  | YouTube
> 
>
> [[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] SummarizedExperiments not equal after serialisation

[Kasper Daniel Hansen]

Interesting detective work. This is nasty.

Best,
Kasper

On Thu, May 16, 2019 at 2:19 AM Pages, Herve  wrote:

> Let's try to go to the bottom of this. But let's leave
> SummarizedExperiment objects out of the picture for now and focus on what
> happens with a very simple reference object.
>
> When you create 2 instances of a reference class with the same content:
>
>   A <- setRefClass("A", fields=c(stuff="ANY"))
>   a0 <- A(stuff=letters)
>   a1 <- A(stuff=letters)
>
>
> the .xData slot (which is an environment) is "different" between the 2
> instances in the sense that the 2 environments live at different addresses
> in memory:
>
>   a0@.xData#  0x3812150>
>   a1@.xData#  0x381c7e0>
>   identical(a0@.xData, a1@.xData)  #
> FALSE
>
>
> However their **content** is the same:
>
>   all.equal(a0@.xData, a1@.xData)  #
> TRUE
>
>
> and the 2 objects are considered equal:
>
>   all.equal(a0, a1)# TRUE
>
>
> When the **content** of the 2 objects differ, all.equal() sees 2
> environments with different contents:
>
>   b <- A(stuff=LETTERS)
>   isTRUE(all.equal(a0@.xData, b@.xData))
> # FALSE
>
> and no longer considers the 2 objects equal:
>
>   all.equal(a0, b) # "Component “stuff”: 26 string
> mismatches"
>
>
> So far so good.
>
> When an object goes thru a serialization/deserialization cycle:
>
>   saveRDS(a0, "a0.rds")
>   a2 <- readRDS("a0.rds")
>
>
> the .xData slot of the restored object also lives at a different address:
>
>   a2@.xData#  0x3944668>
>   identical(a0@.xData, a2@.xData)  #
> FALSE
>
>
> (This is what serialization/deserialization does on environments so is
> expected.)
>
> So in that aspect 'a2' is no different from 'a1'. However for 'a2' now we
> have:
>
>   all.equal(a0, a2)# "Class definitions are not identical"
>
>
> So why is 'all.equal(a0, a2)' doing this? This cannot be explained only by
> the fact that 'a0@.xData' and 'a2@.xData'
> are non-identical environments.
>
> Looking at the source code for all.equal.envRefClass(), we see something
> like this (slightly simplified here):
>
>   ...
>   if (!identical(target$getClass(), current$getClass())) {
>   ...
>   return(sprintf("Class definitions are not identical%s", ...)
>   }
>   ...
>
>
> So let's try this:
>
>   identical(a0$getClass(), a1$getClass())  # TRUE
>   identical(a0$getClass(), a2$getClass())  # FALSE
>
> Note that 'x$getClass()' is not the same as 'class(x)'. The latter returns
> the **class name** while the former returns the **class definition** (which
> is represented by a complicated object of class refClassRepresentation).
>
> 'a0' and 'a2' have identical class names:
>
>   class(a0)
>   # [1] "A"
>   # attr(,"package")
>   # [1] ".GlobalEnv"
>
>   class(a2)
>   # [1] "A"
>   # attr(,"package")
>   # [1] ".GlobalEnv"
>
>   identical(class(a0), class(a2))
>   # [1] TRUE
>
>
> So now the question is: even though 'a0' and 'a2' have identical **class
> names**, how come they do NOT have identical **class definitions**?
>
> The big surprise (at least to me) is that reference objects, unlike
> traditional S4 objects, CARRY THEIR OWN COPY OF THE CLASS DEFINITION! This
> copy is stored in the '.refClassDef' variable stored in the .xData
> environment of the object:
>
>   ls(a0@.xData, all=TRUE)
>   # [1] ".refClassDef" ".self""getClass" "stuff"
>
>   ls(a2@.xData, all=TRUE)
>   # [1] ".refClassDef" ".self""getClass" "stuff"
>
> This private copy of the class definition is actually what 'x$getClass()'
> returns:
>
>   identical(a0$getClass(), get(".refClassDef", envir=a0@.xData envir=a0@.xData>))  # TRUE
>   identical(a2$getClass(), get(".refClassDef", envir=a2@.xData envir=a2@.xData>))  # TRUE
>
>
> Problem is that for 'a2' this copy of the class definition is not
> identical to the **original class** definition:
>
>   identical(getClass("A"), a0$getClass())  # TRUE
>   identical(getClass("A"), a2$getClass())  # FALSE
>
>
> And this in turn is because the complicated object that represents the
> class definition also contains environments (e.g.
> 'getClass("A")@refMethods' is an environment) so going thru a
> serialization/deserialization cycle is not a **strict no-op** on it (from
> an identical() perspective).
>
> Replacing the copy of the class definition stored in 'a2' with the
> original class definition makes the problem go away:
>
>   rm(".refClassDef", envir=a2@.xData)
>   assign(".refClassDef", getClass("A"), envir=a2@.xData .xData>)
>   all.equal(a0, a2)  # TRUE
>
>
> Bottom line: the test 'identical(target$getClass(), current$getClass())'
> performed by 

Re: [Bioc-devel] When to use generics?

[Kasper Daniel Hansen]

This is a common situation. Most packages might have a need for something
that looks like a generic, but it really only has a usage inside your own
package(s).

In many ways, the pseudo-generic you define using if() statements is often
easier to work with, debugging wise and code-reading wise. However, there
is a certain beauty to generics. IME many newcomers to S4 overdo it with
generics. My rule of thumb is don't do a generic unless you have at least 3
different classes you're doing dispatch on. Well, you have 3 classes, so I
would start thinking about it. For better or worse, this is unlikely to
make much difference so you should choose the one that makes the most sense
to you as a writer.

If you go down the generic route, think hard about the name.


On Mon, Apr 29, 2019 at 10:38 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> On Mon, Apr 29, 2019 at 6:55 AM Pages Gallego, M. <
> m.pagesgall...@umcutrecht.nl> wrote:
>
> > Dear all,
> >
> > I am currently developing a package and I am a bit confused in when one
> > should define a generic. Let me propose an example:
> > Suppose I have defined 3 classes: one for proteomics data, one for
> > metabolomics data and one for transcriptomics data. I have a function
> > “foo(x)” that will do the same to any of the 3 classes, but requires a
> > slightly different implementation for each one. I could do something like
> > that:
> >
> > ```
> > foo <- function(x) {
> > if (is(x, ‘proteomics’)) {
> >   foo.protein(x)
> > } else if (is(x, ‘metabolomics’)) {
> >   foo.metabo(x)
> > } else if (is(x, ‘transcriptomics’)) {
> >   foo.trans(x)
> > }
> > }
> > ```
> >
> > And then define foo.protein, foo.metabo and foo.trans.
> > But this is basically the same as defining the generic “foo” and then
> > defining a method for each of the classes.
> >
> > The problem is that “foo” is not generic “enough” in terms that outside
> > the package it has no use. Therefore, defining the generic seems like a
> big
> > responsibility in that it should have a use outside the package. Would
> you
> > still define “foo” as generic in this case?
>
>
> Not exactly sure what you mean, but if a function has no use outside of a
> package, just avoid exporting it.
>
> Are there any guidelines in when one should or should not define a generic?
> >
> > From:
> >
> https://www.bioconductor.org/help/course-materials/2017/Zurich/S4-classes-and-methods.html#extending-a-class-without-adding-any-slot
> > in section 2.2.2 it recommends to reuse existing generics (which makes a
> > lot of sense), but then it also says that you can define new generics for
> > specialized operations, what if the operation is very specialized?
> >
>
> One recommendation is that if an operation is very specialized it should
> have a very special name. In the context of generics, that helps avoid
> conflicts.
>
> From:
> >
> https://www.bioconductor.org/help/course-materials/2011/AdvancedRFeb2011Seattle/ImplementingS4Objects-lab.pdf
> > in section 2.3 it says that the recommended way to implement accessors is
> > through methods (which require generics if none exist), is this always
> the
> > case for all S4 classes?
> > I apologize in advance if these are very naïve questions.
> >
> >
> At the very least you'll want some level of abstraction around the object
> representation, even for internal classes. You could take a lazy approach,
> first making ordinary functions, then transforming them into generics later
> when it becomes necessary. For public accessors, it's hard to predict when
> it will become necessary, since generics are meant to be reused by others,
> thus it is often best to make them generic initially. It is OK for APIs to
> evolve over time though. In practice, once generics become generally
> adopted, they need to move to a more general package.
>
> Best,
> > Marc
> >
> >
> >
> >
> --
> >
> > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> > uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> > ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> > direct
> > te informeren door het bericht te retourneren. Het Universitair Medisch
> > Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
> > W.H.W.
> > (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat
> geregistreerd
> > bij
> > de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
> >
> > Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
> >
> >
> >
> --
> >
> > This message may contain confidential information and ...{{dropped:22}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Kasper Daniel Hansen]

On Wed, Mar 27, 2019 at 1:06 AM Aaron Lun <
infinite.monkeys.with.keyboa...@gmail.com> wrote:

> > well, we can't fix this in old branches of Bioc.
>
> Sure, but one could say that about breaking changes to any CRAN package.
> Nothing particularly special about BH on that point.
>

Indeed, and this has been my position for a number of years. Having said
that, dynamic linking / headers in my experience increase the chance of
breaking and it is usually a kind of breakage which requires substantial
insight to fix (as opposed to say changing the order / naming of arguments
in an R function, which is really easy to diagnose even if you know nothing
about the package).

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Kasper Daniel Hansen]

I am out of date on this, but when I looked into it last time (years ago)
BH only included headers and it used to be that the graph part of boost
went beyond headers only. If it's headers-only perhaps the danger is
reduced.

On Mon, Mar 25, 2019 at 11:39 AM Vincent Carey 
wrote:

>
>
> On Mon, Mar 25, 2019 at 10:57 AM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> There are no issues with depending on CRAN packages.
>>
>> But I would advise caution. On one hand it is great that boost gets
>> updated regularly. On the other hand, it could lead to incompatibilities
>> with RBGL and then you have to update that package rapidly. Also - and this
>> is something we could consider addressing - the CRAN imports of Bioc are
>> not locked down. By which I mean, you release RBGL in Bioconductor X. After
>> release (or perhaps even after next Bioc release) BH is updated in a
>> non-backwards compatible way and now the old code is hosed. Having said
>> that, so far we have been ignoring it (I think) and the same issue arises
>> with Rcpp.
>>
>> Do you have any idea how often Boost breaks compatibility?  I would
>> strongly advise to download the last couple of BH releases and test with
>> RBGL. While kind of irrelevant in some sense, it will give you an idea of
>> how fast Boost / BH evolves.
>>
>
> These are good points.  In this particular case I believe that Boost Graph
> Library evolves very slowly and
> backwards compatibility is not endangered.  It is an early component of
> Boost.  On the other hand, BH has
> no obligation to provide the graph (BGL) headers, and I believe that in
> early incarnations of BH, some headers
> needed for RBGL were not there.  So there are maintenance vulnerabilities
> to this approach, but I think it is better
> if we stick with the maintained BH as long as this works.  Should this
> approach fail (and your scenario of
> CRAN package changes breaking bioc must be kept in mind) we can go back to
> tarball distribution if necessary.
>
>
>>
>> On Mon, Mar 25, 2019 at 8:03 AM Martin Morgan 
>> wrote:
>>
>>> ...also Bioconductor knows all about CRAN -- see the repositories
>>> returned by
>>>
>>> > BiocManager::repositories()
>>>BioCsoft
>>>"https://bioconductor.org/packages/3.9/bioc;
>>> BioCann
>>> "https://bioconductor.org/packages/3.9/data/annotation;
>>> BioCexp
>>> "https://bioconductor.org/packages/3.9/data/experiment;
>>>   BioCworkflows
>>>   "https://bioconductor.org/packages/3.9/workflows;
>>>CRAN
>>>  "https://cran.rstudio.com;
>>> >
>>>
>>> On 3/25/19, 7:42 AM, "Martin Morgan"  wrote:
>>>
>>> I think the usual incantation in configure files is ${R_HOME}/bin/R
>>> ... R_HOME is the path to R set by the command that starts to build or
>>> install the package, whereas Rscript is found on the search path.
>>>
>>> Martin
>>>
>>> On 3/25/19, 7:33 AM, "Bioc-devel on behalf of Vincent Carey" <
>>> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
>>> wrote:
>>>
>>> The error on linux for 3.9:
>>>
>>>
>>> ##
>>>
>>> ##
>>> ###
>>> ### Running command:
>>> ###
>>> ###   /home/biocbuild/bbs-3.9-bioc/R/bin/R CMD INSTALL RBGL
>>> ###
>>>
>>> ##
>>>
>>> ##
>>>
>>>
>>> * installing to library ‘/home/biocbuild/bbs-3.9-bioc/R/library’
>>> * installing *source* package ‘RBGL’ ...
>>> ** using staged installation
>>> checking R package BH ... no
>>> configure: error: R package BH not found.
>>> ERROR: configuration failed for package ‘RBGL’
>>> * removing ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
>>> * restoring previous
>

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Kasper Daniel Hansen]

There are no issues with depending on CRAN packages.

But I would advise caution. On one hand it is great that boost gets updated
regularly. On the other hand, it could lead to incompatibilities with RBGL
and then you have to update that package rapidly. Also - and this is
something we could consider addressing - the CRAN imports of Bioc are not
locked down. By which I mean, you release RBGL in Bioconductor X. After
release (or perhaps even after next Bioc release) BH is updated in a
non-backwards compatible way and now the old code is hosed. Having said
that, so far we have been ignoring it (I think) and the same issue arises
with Rcpp.

Do you have any idea how often Boost breaks compatibility?  I would
strongly advise to download the last couple of BH releases and test with
RBGL. While kind of irrelevant in some sense, it will give you an idea of
how fast Boost / BH evolves.

On Mon, Mar 25, 2019 at 8:03 AM Martin Morgan 
wrote:

> ...also Bioconductor knows all about CRAN -- see the repositories returned
> by
>
> > BiocManager::repositories()
>BioCsoft
>"https://bioconductor.org/packages/3.9/bioc;
> BioCann
> "https://bioconductor.org/packages/3.9/data/annotation;
> BioCexp
> "https://bioconductor.org/packages/3.9/data/experiment;
>   BioCworkflows
>   "https://bioconductor.org/packages/3.9/workflows;
>CRAN
>  "https://cran.rstudio.com;
> >
>
> On 3/25/19, 7:42 AM, "Martin Morgan"  wrote:
>
> I think the usual incantation in configure files is ${R_HOME}/bin/R
> ... R_HOME is the path to R set by the command that starts to build or
> install the package, whereas Rscript is found on the search path.
>
> Martin
>
> On 3/25/19, 7:33 AM, "Bioc-devel on behalf of Vincent Carey" <
> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
> wrote:
>
> The error on linux for 3.9:
>
>
> ##
>
> ##
> ###
> ### Running command:
> ###
> ###   /home/biocbuild/bbs-3.9-bioc/R/bin/R CMD INSTALL RBGL
> ###
>
> ##
>
> ##
>
>
> * installing to library ‘/home/biocbuild/bbs-3.9-bioc/R/library’
> * installing *source* package ‘RBGL’ ...
> ** using staged installation
> checking R package BH ... no
> configure: error: R package BH not found.
> ERROR: configuration failed for package ‘RBGL’
> * removing ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
> * restoring previous ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
>
> Note that BiocParallel also uses BH and succeeds
>
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> g++ -std=gnu++11 -I"/home/biocbuild/bbs-3.9-bioc/R/include"
> -DNDEBUG
> -I"/home/biocbuild/bbs-3.9-bioc/R/library/BH/include"
> -I/usr/local/include  -fpic  -g -O2  -Wall -c ipcmutex.cpp -o
> ipcmutex.o
> In file included from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/integer_log2.hpp:19:0,
>  from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/large_arithmetic.hpp:19,
>  from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/const_mod.hpp:23,
>  from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/seed_impl.hpp:26,
>  from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/mersenne_twister.hpp:30,
>  from
>
> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/uuid/random_generator.hpp:17,
>
> So could it be an issue with the configure script?
>
>
> On Mon, Mar 25, 2019 at 7:22 AM Samuela Pollack <
> spoll...@jimmy.harvard.edu>
> wrote:
>
> > Dear Bioconductor,
> >
> > The devel version of package RBGL is flunking build.
> >
> > This package has been modified to include header files in the
> CRAN
> > package 'BH' instead of using a local tarball of the header
> files. We
> > consider this an improvement because the 'BH' maintainers update
> their
> > package every time a new version of boost is released, but
> rebuilding
> > the included tarball is unreliable.
> >
> > Is it possible to request inclusion of a CRAN package dependency
> 

Re: [Bioc-devel] Call for collaborators/advice

[Kasper Daniel Hansen]

Why is this not "just" a function which transforms one GI into another GI?
Thats what it seems to me.

On Fri, Mar 22, 2019 at 12:31 PM Luke Klein  wrote:

> I am writing a package that will extend the GenomicInteractions class.  I
> am a statistician, so I may not know best practices when it comes to
> extending existing classes (eg. should I make a new slot or simply add a
> column to the `elementMetadata`?  Are there existing functions that already
> do what I am attempting?).
>
> I am not familiar with Bioc-Devel decorum, so if asking this here is
> inappropriate, kindly let me know.
>
> About my project:
>
> In the first step, I am hoping to implement a HiC binning function on HiC
> data contained in a GenomicInteractions set.  I aim to:
>
> - Reorder the anchor pairs (I will explain in more detail to
> anyone that wants to help)
> - Collapse the regions to the desires bin width
> - Sum the counts within each bin
> - Update the anchors to agree with the new/updated regions
>
> This will set the stage for the new class that I hope to create for HiC
> domain calling, but I need to achieve the above tasks first.
>
> All the best to everyone!
>
> — Luke Klein
> PhD Student
> Department of Statistics
> University of California, Riverside
> lklei...@ucr.edu
>
>
>
>
>
>
>
> [[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] set.seed and BiocParallel

[Kasper Daniel Hansen]

But why do you want the same seed for the different features? That is not
the right way to use stochastic methods.

Best,
Kasper

On Tue, Mar 12, 2019 at 5:20 PM Bemis, Kylie 
wrote:

> Hi all,
>
> I remember similar questions coming up before, but couldn’t track any down
> that directly pertain to my situation.
>
> Suppose I want to use bplapply() in a function to fit models to many
> features, and I am applying over features. The models are stochastic, and I
> want the results to be reproducible, and preferably use the same RNG seed
> for each feature. So I could do:
>
> fitModels <- function(object, seed=1, BPPARAM=bpparam()) {
> bplapply(object, function(x) {
> set.seed(seed)
> fitModel(x)
> }, BPPARAM=BPPARAM)
> }
>
> But the BioC guidelines say not to use set.seed() inside function code,
> and I’ve seen other questions answered saying not to use “seed” as a
> function parameter in this way.
>
> Is it preferable to check and modify .Random.seed directly, or is there
> some other standard way of doing this?
>
> Thanks,
> Kylie
>
> ~~~
> Kylie Ariel Bemis
> Khoury College of Computer Sciences
> Northeastern University
> kuwisdelu.github.io
>
>
>
>
>
>
>
>
>
> [[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] How critical is package style for bioconductor?

[Kasper Daniel Hansen]

lintr can be configured to use camelCase.

On Tue, Feb 26, 2019 at 11:12 AM Turaga, Nitesh <
nitesh.tur...@roswellpark.org> wrote:

> As long as it’s consistent, you can use another style. Consistency helps
> reviewers read the code easily.
>
> Most people generally use “camelCase" or “snake_case" for variable names
> and function names.  But keep in mind that class names need to be
> “CamelCase" as that is the R style of doing things.
>
> You should follow the other set of rules as given (such as Indentation,
> File names, Class names, use of space, comments, Namespaces, end user
> messages, Misc section)
> http://bioconductor.org/developers/how-to/coding-style/.
>
> Best,
>
> Nitesh
>
>
> On Feb 26, 2019, at 11:00 AM, Aaron Chevalier  a...@bu.edu>> wrote:
>
> Hi all,
>
> I'm developing a package that to submit to Bioconductor and I've noticed
> that the style guide suggests camelCasealternatingWords which I find hard
> to read and is different from other style guides and automated
> style-checking I've seen (lintr, Hadley Wickam).
>
> Is this an optional requirement that can be done with another consistent
> style, or if not are there packages that enforce this style guide in an
> automated fashion? I tried BiocCheck and it said nothing about the naming
> conventions.
>
> Thanks!
>
> [[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.
> [[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] Error package build

[Kasper Daniel Hansen]

According to the GitHub repos, the current maintainer is
  Valentin Dinu 
Which is not the email you have sent this message from. Do you have
multiple email addresses and this is causing this?

On Mon, Feb 25, 2019 at 8:44 PM margaret linan 
wrote:

> Hi -
>
> I have submitted my package PoTRA using the Bioconductor Issues page and
> the build results keep stating two errors:
>
> 1. That I am not a subscriber to the bioc-devel mailing list.
>
> 2. That I am not registered at the support site.
>
> I am a subscriber and have registered, so I am confused about why these
> are coming up as errors.
>
> Thanks.
>
> ML
>
> Sent from my iPhone
> ___
> 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: [Rd] pmax and long vector

[Kasper Daniel Hansen]

Gabe, I don't (yet) know much about long vectors at the C level. So feel
free to address this.

Duncan, I'll see what I can do regarding systematically compiling a list of
functions without long vector support. These days I frequently work with
big enough matrices that I need it.

On Mon, Jan 21, 2019 at 3:09 PM Gabriel Becker 
wrote:

> Kasper,
>
> If you're not interested or dont have time to create said patch yourself
> let me know and i can do it.
>
> Best,
> ~G
>
> On Mon, Jan 21, 2019, 11:36 AM Duncan Murdoch  wrote:
>
>> On 21/01/2019 12:35 p.m., Kasper Daniel Hansen wrote:
>> > I see that base::pmax() does not support long vectors.
>> >
>> > Is R-devel interested in reports like this; ie. is there a goal of full
>> > support for long vectors in "basic" functions, something I at least
>> would
>> > greatly appreciate?
>> >
>> > MRE:
>> >
>> >> pmax(rep(1L, 3*10^9), 0)
>> >
>> > Error in pmax(rep(1L, 3 * 10^9), 0) :
>> >long vectors not supported yet:
>> > ../../../R-devel-src/src/include/Rinlinedfuns.h:522
>>
>>
>> I think a carefully tested patch that fixes pmax (it would need to
>> change this call from length() to xlength(), and make some other
>> necessary changes that follow from this), would probably be useful to R
>> Core, and could be posted to bugs.r-project.org.
>>
>> It might also be useful on R-devel to post a list of all known commonly
>> used functions that don't support long vectors; this could be updated on
>> a regular basis.  This might encourage people to produce patches as above.
>>
>> I'm not so sure a report about a single function won't just get lost.
>>
>> Duncan Murdoch
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

[[alternative HTML version deleted]]

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

[Rd] pmax and long vector

[Kasper Daniel Hansen]

I see that base::pmax() does not support long vectors.

Is R-devel interested in reports like this; ie. is there a goal of full
support for long vectors in "basic" functions, something I at least would
greatly appreciate?

MRE:

> pmax(rep(1L, 3*10^9), 0)

Error in pmax(rep(1L, 3 * 10^9), 0) :
  long vectors not supported yet:
../../../R-devel-src/src/include/Rinlinedfuns.h:522

Best,
Kasper

[[alternative HTML version deleted]]

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

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

[Kasper Daniel Hansen]

To add to Henrik's comments, it is also worthwhile to recognize that
mclapply() does not deliver statistically sound random numbers even within
the apply "loop" unless you use RNGkind("L'Ecuyer-CMRG") which is not set
as default. This is because mclapply will initialize random streams with
different seeds and most RNGs does not guarantee that different seeds leads
to independent streams (but L'Ecuyer does).

Reproducibility is nice, but so is statistical correctness.

Best,
Kasper


On Mon, Jan 7, 2019 at 6:26 PM Henrik Bengtsson 
wrote:

> 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 

Re: [Bioc-devel] Questions about some checks in the latest BiocCheck

[Kasper Daniel Hansen]

First, the issue with using class() is that the return is a vector possibly
with >1 element. This _does_ happen.  This is why is() etc is much better,.

Second, why do you need case insensitivity when testing for class. That
makes NO sense to me. You should be testing for a specific (collection) of
class(es).  Not just anything with a random name.


On Wed, Nov 28, 2018 at 10:44 AM Vincent Carey 
wrote:

> Can you provide the repo for your package in development?  These BiocCheck
> issues are important and
> should be resolved at your end.  We can give some advice on how to get
> better results with BiocCheck.
>
> On Wed, Nov 28, 2018 at 10:34 AM Casper Peters  wrote:
>
> > So in the package I'm developing, I have a few specific use cases that
> > make BiocCheck not so happy.
> >
> >
> >
> > 1:
> >
> >
> > ```
> >
> > * WARNING: Avoid class()== or class()!= ; use is() or !is()
> >
> > ```
> >
> > So my first problem arises with checking the classes of objects. I want
> > the interface to be such that I can allow for case insensitivity and/or
> > allow the object to be NULL in some specific cases. This is easier with
> > using `class()` explicitly (especially in the case of case sensitivity).
> >
> >
> >
> > 2:
> >
> >
> > ```
> >
> >  * ERROR: At least 80% of man pages documenting exported objects
> >   must have runnable examples. The following pages do not:
> > ```
> >
> > The second problem arises because of some of my exported functions. I
> made
> > parser+download functions for the Fantom5 data, as this was not available
> > anywhere inside a package yet. Because of the download being big/taking
> too
> > long, I want to avoid running the checks in R CMD check. For this I added
> > \dontrun{} at the examples, resulting in BiocCheck not liking this.
> >
> >
> > Other than that I just have some small notes that I still need to take
> > care of, but with these I am not sure what to do.
> >
> > Thanks in advance,
> >
> > -Casper
> >
> > [[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:10}}

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

Re: [Bioc-devel] Error : object 'lengths' is not exported by 'namespace:BiocGenerics'

[Kasper Daniel Hansen]

It seems the short answer is:
  yes, base::lengths() works and should be fast
If it either doesn't work or is slow, you should report it.

On Tue, Nov 13, 2018 at 3:33 PM Pages, Herve  wrote:

> I'm going to try to provide some details, at the risk to confuse you even
> more.
>
>
> In BioC 3.8 / R 3.5 base::lengths() was not just slow on some Bioconductor
> objects like IRanges or GRanges, it didn't work:
>
>
>   > ir <- IRanges(1:21, 20)
>   > base::lengths(ir)
>   Error in getListElement(x, i, ...) :
> IRanges objects don't support [[, as.list(), lapply(), or unlist() at
> the moment
>
>
> Now it works (in BioC 3.9 / R 3.6):
>
>
>   > ir <- IRanges(1:21, 20)
>   > base::lengths(ir)
>[1] 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
>
>
> The change I announced in my original post is about base::lengths() being
> now an S4 generic. A standard S4 generic like BiocGenerics::lengths() or
> base::lengths() doesn't do any work beyond dispatching to the right method.
> What happened in R 3.6 is that base::lengths() is now an S4 generic. This
> means that it knows how to take care of dispatching to the right method.
> The various "lengths" methods defined in Bioconductor are the ones doing
> the real work and they are fast. They have not changed and their speed
> should not be affected by this change in base::lengths().
>
>
> Furthermore: in R 3.6, even though you can't see it, there is a default
> "lengths" method defined in base (it's used as a fallback when no other
> method applies). In my 1st code chunk above (i.e. when base::lengths() was
> not a generic), I'm calling directly this default method (note that this
> was the default method of the BiocGenerics::lengths() generic). This
> default method is indeed slow or doesn't work on Bioconductor objects. By
> calling BiocGenerics::lengths() (in BioC 3.8) or base::lengths() (in BioC
> 3.9), dispatch selects the fast method so nothing has changed from that
> perspective.
>
>
> Hope this helps,
>
> H.
>
>
> On 11/13/18 08:59, Håkon Tjeldnes wrote:
> Just to be sure, you are saying that now base::lengths is as fast as
> BiocGenerics::lengths was ? Else we would still need the Bioc version.
> Because the old base implementation was terrible, I will try to verify this
> if you are unsure.
> 
> Fra: Michael Lawrence  lawrence.mich...@gene.com>
> Sendt: fredag 2. november 2018 23.50
> Til: hauken_hey...@hotmail.com
> Kopi: bioc-devel; Hervé Pagès
> Emne: Re: [Bioc-devel] Error : object 'lengths' is not exported by
> 'namespace:BiocGenerics'
>
> Yes, please follow Hervé's instructions.
>
> On Fri, Nov 2, 2018 at 3:41 PM Håkon Tjeldnes  > wrote:
> Just a quick question, in 3.8 we used biogenerics::lengths for ORFik,
> since it was much faster than base, for our dataset 1 second vs 30 minutes.
> We should change to S4 version of lengths now ?
>
> Get Outlook for Android https://urldefense.proofpoint.com/v2/url?u=https-3A__eur02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Faka.ms-252Fghei36-26data-3D02-257C01-257C-257Ce617c34c45584b70cf7008d6411590f9-257C84df9e7fe9f640afb435-257C1-257C0-257C636767958210704172-26sdata-3DUl3jkwHfZdrwQjkzzBQTKrXdQ5NXQ1vWRrx7vojZEAw-253D-26reserved-3D0=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VkR31AqDi_FLujiTJm39v-jaLNkPJov4_ZlFjFit9UI=C8hC46CIc0bUw9WUxrvaekaCsN1NAlLcyxiuFKgRjCs=
> >>
>
> 
> From: Bioc-devel  bioc-devel-boun...@r-project.org>> on behalf of Pages, Herve <
> hpa...@fredhutch.org>
> Sent: Friday, November 2, 2018 6:08:13 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Error : object 'lengths' is not exported by
> 'namespace:BiocGenerics'
>
> Hi developers,
>
> Starting with R 3.6, base::lengths() can now be treated as an S4 generic
> function (like base::length() or base::names()) so there is no need for
> us to define our own lengths() generic function in BiocGenerics.
> Therefore we've removed the lengths() generic from BiocGenerics (in
> version 0.29.1). Note that you can see the S4 generic associated with
> base::lengths() by calling getGeneric("lengths") in a fresh R session:
>
>> getGeneric("lengths")
>standardGeneric for "lengths" defined from package "base"
>
>function (x, use.names = TRUE)
>standardGeneric("lengths")
>
>
>Methods may be defined for arguments: x
>Use  showMethods("lengths")  for currently available ones.
>
> This used to return NULL in R < 3.6.
>
> Because of these changes, packages that currently explicitly import
> lengths or a lengths method in their NAMESPACE are failing to install
> with an error that looks like this:
>
>** byte-compile and prepare package for lazy loading
>Error : object 'lengths' is not exported by 'namespace:BiocGenerics'

Re: [Bioc-devel] A little confuse about how to update accepted package

[Kasper Daniel Hansen]

Wenhao,

The night before the release your package was at 0.99.x in the devel branch

At release, two things happened:
  the package was added to the release branch with version 1.0.0
  the package in the devel branch was updated to version 1.1.0

So basically version 0.99.19 == 1.0.0 == 1.1.0. And basically after release
all packages gets bumped two version numbers.  Note that in x.y.z, "y" is
odd = devel, "y" is even = release.

Usually you should not update the release branch (version 1.0.0) unless
there are critical bug fixes.  Any update in the release branch should be
associated with an email to bioc-devel according to project policies
(although this is unfortunately often not done).

Most likely you should just continue working on version 1.1.0

Best,
Kasper

On Sat, Nov 10, 2018 at 6:10 AM Martin Morgan 
wrote:

> The steps below are correct, but perhaps not sufficient for what you want
> to do.
>
> Bioconductor packages consist of release branches, which are meant to be
> stable for the end user, and the 'devel' branch where new features can be
> introduced.
>
> There is a version numbering scheme, outlined at
>
>   http://bioconductor.org/developers/how-to/version-numbering/
>
> to ensure that each published version of the package has a different
> version, that versions in release always increase, and that the devel
> version is always ahead of the release version. For your package, the
> release version is 1.0.0, and the devel version is 1.1.0.
>
> If you intended to make a change to the devel version of your package,
> because you were introducing a new feature or perhaps testing a bug fix,
> then you have been successful; you have pushed your changes to the devel
> ('master') branch, and incremented the version to 1.1.1.
>
> If you intend to make this change also in the release, then the extra
> steps in
>
>
> http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>
> are required -- check out the RELEASE_3_8 branch, port your changes from
> master, increment the release version to 1.0.1, and push.
>
> During the submission process packages are built immediately, but in the
> devel and release branches they are built nightly, approximately (I think
> that last night in particular there were issues with network connectivity
> that might severely limit the success of the build). The build reports are
> available from
>
>   http://bioconductor.org/checkResults/
>
> note the 'snapshot' time stamps and commit information for the overall
> build and for your individual package to see whether your commit was
> included in the nightly build.
>
> Martin
>
> On 11/10/18, 5:53 AM, "Bioc-devel on behalf of Tang, Wenhao" <
> bioc-devel-boun...@r-project.org on behalf of wenhao.tan...@imperial.ac.uk>
> wrote:
>
> Dear Bioconductor team,
>
>
> My package bayNorm has recently been accepted, it now has version
> 1.0.0. Currently I would like to make some changes to it. I look through
> the tutorials online but I am still very confused. Below is what I have
> done:
>
>
> My local repository has version 0.99.19. So I  did the following in my
> local repository:
>
>   1.  git remote add upstream g...@git.bioconductor.org:
> packages/bayNorm
>   2.  git fetch --all
>   3.  git checkout master
>   4.  git merge origin/master
>   5.  git merge upstream/master
>
> Now the local version is 1.1.0 rather than 0.99.19.
>
>
> Then I just did a small change (in addition, I bump the version to
> 1.1.1) and then run the following command under the local repository:
>
>   1.  git push upstream master
>   2.  git push origin master
>
> Is the above procedure correct? Will I see the package building report
> like what I have received during the submission process?
>
> Your tutorials are very clear, and I am sorry if my question is too
> trivial.
>
> Thank you very much!
>
> Best wishes,
> Wenhao
>
> [[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] About the reproducibility of BioC server environment

[Kasper Daniel Hansen]

In my experience, if I aggressively update my development installation of
Bioconductor (including occasional updates of R-devel when appropriate) I
can usually replicate most-all failures on the build server which has the
same OS as my local machine.  It does require aggressive updating though.

On Tue, Nov 6, 2018 at 9:17 AM Martin Morgan 
wrote:

> Thanks for the comments.
>
> A docker image doesn't help with differences between operating systems.
>
> A docker image wouldn't be practical for the build system, where there are
> 1000's of packages installed.
>
> A docker image would need to be updated daily, since that is what the
> build system does; you would need to pull the docker image.
>
> A docker image with appropriate R and base packages is available; see
> https://bioconductor.org/help/docker/ but note that these require that
> your own dependencies be installed and kept current.
>
> Windows builds and tests on 32 and 64 bit platforms, so can take a lot
> more time; it is difficult to differentiate between this sort of problem
> and timeouts caused by OS-specific or package issues.
>
> Usually avoidable problems come about because the wrong version of
> Bioconductor is in use, or because packages are not current. These can be
> checked with
>
>   BiocManager::version() == "3.9" # alternate: BiocManager:::isDevel()
>   BiocManager::valid()
>
> In the big picture I hope that we can arrive at a more continuous version
> of the builders, but that will not happen soon.
>
> Martin
>
> On 11/6/18, 8:37 AM, "Bioc-devel on behalf of 露崎 弘毅" <
> bioc-devel-boun...@r-project.org on behalf of k.t.the-ans...@hotmail.co.jp>
> wrote:
>
> Dear Bioc Core Team
>
> I have created many Bioconductor packages, but it is always hard to
> pass the R CMD CHECK/BiocCheck.
>
> Especially, it is still difficult to construct the identical
> environment of single/daily package builder in the local machine.
>
> Sometimes the error is caused by the difference of the OS (e.g.
> Windows ↔︎ Linux, Max), but it is very difficult to trace the reason in the
> local machine.
>
> In the "daily" package builder case, the code can be tested only one
> time per day, and it will slow down the package development speed.
>
> I have often experienced that the BiocCheck in tokay1 (Windows) is
> failed due to the CheckTime, but it is difficult to distinguish whether the
> error is caused by my source-code or the machine is just busy for the task
> of other packages.
>
>
> Why don't you create the docker containers for the single/daily
> package builder?
> https://www.bioconductor.org/help/docker/
>
> I think that it will be very helpful for many BioC developers.
>
> I want to use the system like below.
>
>
> docker run bioconductor/single_windows
> docker run bioconductor/single_linux
> docker run bioconductor/single_mac
> docker run bioconductor/daily_windows
> docker run bioconductor/daily_linux
> docker run bioconductor/daily_mac
>
>
> Koki Tsuyuzaki
>
> [[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] macOS Mojave and R 3.6: issue with building some packages from source

[Kasper Daniel Hansen]

You seem to install the Beta version of the Command Line tools.  That's not
right.  Look at the top of
  apple.com/developer/downloads
(First try with xcode-select --install on the command line, which I could
not get to work).

Following installation of these tools you need to run the following command
which can be found in the R-admin manual (devel version of R, not the
rebased version)
  https://cran.r-project.org/doc/manuals/r-devel/R-admin.html
in section C.3:

sudo installer -pkg \
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
\
-target /

On Fri, Nov 2, 2018 at 4:05 PM Leonardo Collado Torres 
wrote:

> Hi,
>
> I was about to send the email below, but eventually I got it to work.
> I'm sharing it anyway since others might run into similar issues.
>
> Basically, I needed the latest macOS command line tools installed, but
> getting them installed was tricky. I installed Xcode 10.1 (10B61) from
> the Mac App Store, then installed a version of the command line tools
> via
> https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_macOS_10.14_for_Xcode_10.1_Beta_2/Command_Line_Tools_macOS_10.14_for_Xcode_10.1_Beta_2.dmg
> ,
> rebooted, then under "settings", "software update" detected that there
> was a newer version. Finally, I was then able to install the backports
> R package.
>
> Best,
> Leo
>
>
>
> ## Successful install:
>
> > install.packages('backports')
> Warning: unable to access index for repository
> https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.6:
>   cannot open URL
> 'https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.6/PACKAGES'
> Package which is only available in source form, and may need
>   compilation of C/C++/Fortran: ‘backports’
> Do you want to attempt to install these from sources? (Yes/no/cancel) y
> installing the source package ‘backports’
>
> trying URL 'https://cloud.r-project.org/src/contrib/backports_1.1.2.tar.gz
> '
> Content type 'application/x-gzip' length 10900 bytes (10 KB)
> ==
> downloaded 10 KB
>
> * installing *source* package ‘backports’ ...
> ** package ‘backports’ successfully unpacked and MD5 sums checked
> ** libs
> /usr/local/clang4/bin/clang
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I/usr/local/include   -fPIC  -Wall -g -O2  -c dotsElt.c -o dotsElt.o
> /usr/local/clang4/bin/clang
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I/usr/local/include   -fPIC  -Wall -g -O2  -c dotsLength.c -o
> dotsLength.o
> /usr/local/clang4/bin/clang
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I/usr/local/include   -fPIC  -Wall -g -O2  -c init.c -o init.o
> /usr/local/clang4/bin/clang++ -dynamiclib
> -Wl,-headerpad_max_install_names -undefined dynamic_lookup
> -single_module -multiply_defined suppress
> -L/Library/Frameworks/R.framework/Resources/lib
> -L/usr/local/clang4/lib -o backports.so dotsElt.o dotsLength.o init.o
> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
> -Wl,CoreFoundation
> ld: warning: text-based stub file
> /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd
> and library file
> /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation
> are out of sync. Falling back to library file for linking.
> installing to
> /Library/Frameworks/R.framework/Versions/3.6/Resources/library/backports/libs
> ** R
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> Loading required package: colorout
> devtools::install_github("jalvesaq/colorout")
> Warning message:
> In library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return = TRUE,  :
>   there is no package called ‘colorout’
> * DONE (backports)
>
> The downloaded source packages are in
>
> ‘/private/var/folders/cx/n9s558kx6fb7jf5z_pgszgb8gn/T/RtmpBZUipc/downloaded_packages’
> >
> > sessionInfo()
> R Under development (unstable) (2018-04-05 r74542)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS  10.14.1
>
> Matrix products: default
> BLAS:
> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.6/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
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0 tools_3.6.0tcltk_3.6.0
>
>
>
>
>
>
>
> ## Older email:
>
>
>
>
> Hi,
>
> With Bioconductor 3.9 now being live, I got a few emails about some of
> my packages which I wanted to look into. For that I tried installing R
> 3.6 with all my current R 3.5 packages. I quickly ran into problems
> trying to install devtools. Basically, the backports package is not
> available as a 

Re: [Bioc-devel] GenomicFeatures

[Kasper Daniel Hansen]

Lates BiocManager

It is not flagging GenomicFeatures as out of date, presumably because it
doesn't exists in the repos. So in some sense it is all internally
consistent.  I was just surprised to not see it flagged as being out of
date.

I guess I am also confused about what happens at release.  Is the repos
wiped?  Because at some time pre-release GenomicFeatures existed in the
Bioc 3.8 repos, and (usually) that would mean it would fall back to this
previous version (seemingly 1.33.6 based on
  https://bioconductor.org/packages/release/bioc/html/GenomicFeatures.html
yet this package does not seem to exists (despite the URL)).

Ok, this is all a rather unfortunate and special case which I am not sure
how should be handled. I was just surprised at what I am seeing, but I am
also quite confident that when the package is fixed, it'll all work fine.

Best,
Kasper


On Fri, Nov 2, 2018 at 10:05 AM Martin Morgan 
wrote:

> For which BiocManager::version() is this? BiocManager::valid() checks
> within versions, and if there's no GenomicFeatures to reference, then there
> is no way to flag it as out-of-date, sort of like a package you'd installed
> that was in neither CRAN nor Bioconductor.
>
> Though of course we'd like GenomicFeatures to be available in 3.8
>
> Martin
>
> On 11/2/18, 1:05 PM, "Bioc-devel on behalf of Kasper Daniel Hansen" <
> bioc-devel-boun...@r-project.org on behalf of kasperdanielhan...@gmail.com>
> wrote:
>
> Seem broken in release.
>
> And btw., because it is broken, when I run
>   BiocManager::valid()
> it doesn't report GenomicFeatures as out of date, despite the fact
> that I
> have version 1.33.2 installed, and there are newer versions in the
> 1.33.x
> hierarchy and the "right" (but broken) version in Bioc 3.8 is 1.34.0.
>
> Best,
> Kasper
>
> [[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] GenomicFeatures

[Kasper Daniel Hansen]

Seem broken in release.

And btw., because it is broken, when I run
  BiocManager::valid()
it doesn't report GenomicFeatures as out of date, despite the fact that I
have version 1.33.2 installed, and there are newer versions in the 1.33.x
hierarchy and the "right" (but broken) version in Bioc 3.8 is 1.34.0.

Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Ask help to install gs tokay2 build/check

[Kasper Daniel Hansen]

Perhaps explain why

On Fri, Nov 2, 2018 at 8:19 AM Jianhong Ou, Ph.D. 
wrote:

> Hi,
>
> Is it possible to install ghostscript in tokay2 for development package
> build?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> Email: jianhong...@duke.edu
> Bioinformatician II
> Department of Cell Biology
> Duke University School of Medicine
> Durham, NC, 27710
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for...{{dropped:17}}

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

Re: [Bioc-devel] Dependency to PEER

[Kasper Daniel Hansen]

It is a major weakness of PEER that it has not been submitted to a standard
repository. Of course, that is up to the PEER developers, but the community
should put pressure on them.

On Tue, Sep 25, 2018 at 12:40 PM Christian Mertes  wrote:

> Hi all,
>
> Im the developer of OUTRIDER. Our package normalises RNA-seq count data
> and finds expression outliers within the population.
> During the development we compared our approach against PCA and PEER. The
> later one is a well established method to normalise RNA-seq data.
>
> https://github.com/gagneurlab/OUTRIDER <
> https://github.com/gagneurlab/OUTRIDER>
> https://github.com/PMBio/peer 
>
> For PEER, an R package exists on GitHub, but it is not in CRAN nor
> Bioconductor, even it would fit really well with Bioconductor.
>
> We would like to leave the user the option to switch between the different
> normalisation methods within our package (auto encoder, peer, pca, sea, …).
> But since the Bioconductor requirements are that all loaded libraries need
> to be within CRAN or BioC, my question is how we should implement this.
>
> Is there a best practice for this? Does we have to ask the developer of
> PEER to push it on CRAN or do we get around this? Or can we flag one
> function to be not checked by Bioconductor for dependencies and use
> require(peer) within the function?
>
> Thanks for any advices in advance!
>
> Best,
> Christian
>
>
>
>
> [[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] package c++ optimization flag

[Kasper Daniel Hansen]

This should be done extremely sparingly, but it is sometimes necessary if
you know that higher optimization breaks the code. But that is the only use
case. Otherwise you should trust the setting of the user who compiles R,
ie. you should for example never force a higher optimization level IMO.

We do this override in affxparser.  The issue with the approach in
affxparser is that it is non-portable, since we just overwrite the users
-O* setting. However, a flag like -O* is complier dependent, so this is
actually not a great solution (although it has worked for 10 years).  The
"right" way to do this - which I think we should have example code for - is
to use autoconfigure to detect that the compiler is GCC or clang and _then_
override.

https://github.com/HenrikBengtsson/affxparser/blob/master/src/Makevars

the relevant part is essentially

MYCXXFLAGS = -Wno-sign-compare -O0

%.o: %.cpp
 $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< -o $@

(remember you need TABS in Makefiles)

On Wed, Sep 19, 2018 at 5:12 AM Håkon Tjeldnes 
wrote:

> When I put this line in makevars:
>
>
> PKG_CXXFLAGS = -O3
>
>
> This is the output of the cpp precompiler:
>
>  -O3 -fpic  -g -O2
>
>
> I read the cpp doc, and it states:
>
> "If you use multiple -O options, with or without level numbers, the last
> such option is the one that is effective."
>
> Since, system wide R optimization -O2 always comes last, how can I make my
> package overwrite the system wide optimization ?
> And should I do this at all, since debugging could get more difficult ?
>
> [[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] Block bootstrap for GenomicRanges

[Kasper Daniel Hansen]

I agree this is super important.  I think there may be multiple ways of
thinking about a decent bootstrapping or permutation of ranges, in
genomics. I am quite interested in the topic. I think it might belong in a
new package. I would be interesting in extending the conversation and have
a couple of different approaches (theoretical) that we could work on being
efficient.

Best,
Kasper

On Tue, Aug 14, 2018 at 8:27 AM Michael Love 
wrote:

> dear Hervé,
>
> Thanks again for the quick and useful reply!
>
> I think that the theory behind the block bootstrap [Kunsch (1989), Liu
> and Singh (1992), Politis and Romano (1994)], needs that the blocks be
> drawn with replacement (you can get some features twice) and that the
> blocks can be overlapping. In a hand-waving way, I think, it's "good"
> for the variance estimation on any statistic of interest that y' may
> have more or less features than y.
>
> I will explore a bit using the solutions you've laid out.
>
> Now that I think about it, the start-position based solution that I
> was thinking about will break if two features in y share the same
> start position, so that's not good.
>
> On Mon, Aug 13, 2018 at 11:58 PM, Hervé Pagès 
> wrote:
> > That helps. I think I start to understand what you are after.
> >
> > See below...
> >
> >
> > On 08/13/2018 06:07 PM, Michael Love wrote:
> >>
> >> dear Hervé,
> >>
> >> Thanks for the quick reply about directions to take this.
> >>
> >> I'm sorry for not providing sufficient detail about the goal of block
> >> bootstrapping in my initial post. Let me try again. For a moment, let
> >> me ignore multiple chromosomes/seqs and just focus on a single set of
> >> IRanges.
> >>
> >> The point of the block bootstrap is: Let's say we want to find the
> >> number of overlaps of x and y, and then assess how surprised we are at
> >> how large that overlap is. Both of them may have features that tend to
> >> cluster together along the genome (independently). One method would
> >> just be to move the features in y around to random start sites, making
> >> y', say B times, and then calculate each of the B times the number of
> >> overlaps between x and y'. Or we might make this better by having
> >> blacklisted sites where the randomly shuffled features in y cannot go.
> >>
> >> The block bootstrap is an alternative to randomly moving the start
> >> sites, where instead we create random data, by taking big "blocks" of
> >> features in y. Each block is a lot like a View. And the ultimate goal
> >> is to make B versions of the data y where the features have been
> >> shuffled around, but by taking blocks, we preserve the clumpiness of
> >> the features in y.
> >>
> >> Let me give some numbers to make this more concrete, so say we're
> >> making a single block bootstrap sample of a chromosome that is 1000 bp
> >> long. Here is the original y:
> >>
> >> y <- IRanges(c(51,61,71,111,121,131,501,511,521,921,931,941),width=5)
> >>
> >> If I go with my coverage approach, I should extend it all the way to
> >> the end of the chromosome. Here I lose information if there are
> >> overlaps of features in y, and I'm thinking of a fix I'll describe
> >> below.
> >>
> >> cov <- c(coverage(y), Rle(rep(0,55)))
> >>
> >> I could make one block bootstrap sample of y (this is 1 out of B in
> >> the ultimate procedure) by taking 10 blocks of width 100. The blocks
> >> have random start positions from 1 to 901.
> >>
> >> y.boot.1 <- unlist(Views(cov, start=round(runif(10,1,901)), width=100))
> >
> >
> > Choosing blocks that can overlap with each others could make y' appear
> > to have more features than y (by repeating some of the original
> > features). Also choosing blocks that can leave big gaps in the
> > chromosome could make y' appear to have less features than y
> > (by dropping some of the original ranges). Isn't that a problem?
> >
> > Have you considered choosing a set of blocks that represent a
> > partitioning of the chromosome? This would make y' look more like y
> > by preserving the number of original ranges.
> >
> > In other words, if you can assign each range in y to one block and
> > one block only, then you could generate y' by just shifting the
> > ranges in y. The exact amount of shifting (positive or negative)
> > would only depend on the block that the range belongs to. This would
> > give you an y' that is parallel to y (i.e. same number of ranges
> > and y'[i] corresponds to y[i]).
> >
> > Something like this:
> >
> > 1) Define the blocks (must be a partitioning of the chromosome):
> >
> >   blocks <- successiveIRanges(rep(100, 10))
> >
> > 2) Assign each range in y to the block it belongs to:
> >
> >   mcols(y)$block <- findOverlaps(y, blocks, select="first")
> >
> > 1) and 2) are preliminary steps that you only need to do once,
> > before you generate B versions of the shuffled data (what you
> > call y'). The next steps are for generating one version of the
> > shuffled data so would need to be repeated B times.
> >
> > 3) 

Re: [Bioc-devel] updating maintainer

[Kasper Daniel Hansen]

You update the maintainer field in devel.  I don't know what to do about
release.

I don't understand the question about github.  There is no "github email",
there is a github username. And that username does not have to be the same
as a maintainer email, because they really have nothing to do with each
other. In the DESCRIPTION field the github address is given as a URL not as
an email, like
  URL: https://github.com/hansenlab/minfi
  BugReports: https://github.com/hansenlab/minfi/issues



On Tue, Jun 26, 2018 at 4:18 PM, Samuel E Zimmerman <
sezim...@einstein.yu.edu> wrote:

> Dear bioc-devs,
>
> I will no longer be working at my current university in about a week, and
> the email address associated with the bioconductor packages I maintain will
> be removed. How should I go about updating my email address to keep
> maintaining the packages?
>
> Also, my PI would like to have the github account, where the repos for the
> bioconductor packages live, be under her email address instead of mine.
> Would it be a problem if the maintainer's email address and the github
> email address are different?
>
> Thank you very much.
>
> Best,
> Sam
>
> [[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] Including a submodule in the main package repository

[Kasper Daniel Hansen]

My opinion: maintain two repos and pull/push between them. You would want
the ability to have them out of sync anyway.

Best,
Kasper

On Thu, Jun 14, 2018 at 1:16 AM, Thomas Sherman  wrote:

> Hi all,
>
> I'm a developer for the CoGAPS package (https://github.com/FertigLab/
> CoGAPS). I'm looking into ways to build our core C++ code as a standalone
> application and I would like to be able to maintain a single repository for
> the C++ code and pull that into both repositories for the R package and
> standalone application. It seems the easiest way to do this would be to
> have a git submodule in the R package repository that refers to the C++
> code. However, based on this comment (https://github.com/
> Bioconductor/Contributions/issues/459#issuecomment-376671397) it seems
> that is not the desired configuration.
>
> The best alternative I can think of would be to provide a separate library
> for our core algorithm and then link against that in both the R package and
> standalone version. In this case, we would have to provide instructions for
> downloading and building the library - which seems like more work for the
> end user than if everything was included with a submodule.
>
> I'm wondering if the first approach using a submodule would be possible,
> and if not, has anyone ran into this issue before and found a nice solution.
>
> Thanks,
> Tom
>
>
> [[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] Package size note

[Kasper Daniel Hansen]

Kenneth,

You should _always_ run R CMD check (and R CMD BiocCheck) on the tarball
generated by R CMD build.  The build step essentially cleans the code.  If
your vignette takes a bit to generate (the vignette gets generated with R
CMD build), just do R CMD build --no-build-vignettes

Best,
Kasper

On Tue, May 15, 2018 at 9:41 AM, Kenneth Condon 
wrote:

> Hi Lori,
>
>
> Thanks for the reply. The actual tar.gz built by R CMD build is only 3Mb so
> maybe I should ignore the note and submit? The note may actually be
> referring to large .git objects in the git history - not sure.
>
> Regards,
> Kenneth
>
> On Mon, May 14, 2018 at 12:15 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
> >
> > Please review the package guidelines -
> >
> >
> > http://bioconductor.org/developers/package-guidelines/
> >
> >
> > Generally, Bioconductor will insist that the R CMD built package tar.gz
> be
> > less than 4MB for software packages (There are some exceptions for data
> > experiment or annotation packages).
> >
> >
> > If this is a software packages,  there are a few options
> >
> >
> > With large data files:
> >
> > 1.  Reduce the size of the data.  A full data set is often not needed to
> > display the functionality and utility of a package.  A reduced smaller
> > subset of data is recommended
> >
> > 2.  See if there is already existing data available in one of the data
> > experiment packages or experimenthub that can be used instead of
> providing
> > new data.
> >
> > 3. separate out the data files into a separate associate data
> > experiment package or use the experimenthub to store data.
> >
> >
> >
> > Are you generating or providing a lot of static image files for the
> > vignette?  There might also be some opportunity to reduce the size but
> have
> > images generated automatically if this is the case.
> >
> >
> >
> >
> >
> > 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
> > Kenneth Condon 
> > *Sent:* Saturday, May 12, 2018 6:23:02 PM
> > *To:* bioc-devel
> > *Subject:* [Bioc-devel] Package size note
> >
> > Hi all,
> >
> > I almost have a clean R CMD check.
> >
> > R CMD check results0 errors | 0 warnings | 1 note checking installed
> > package size ... NOTE
> >   installed size is  6.1Mb
> >   sub-directories of 1Mb or more:
> > data   3.0Mb
> > doc2.9Mb
> >
> >
> > Firstly, do I need to get this below 5Mb?
> >
> > Secondly, I don't have a sub-directory called 'doc' - what is this?
> >
> > Regards,
> > Kenneth
> >
> > [[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.
>
> [[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