[Bioc-devel] Data hosting for workflow packages

[Joseph Lee Jing Xian]

Hi all,

We are thinking of developing a workflow package which requires large input 
files. It says here that 
data for workflow packages should ideally be from other data packages or on the 
web. Is it alright to host the data on Zenodo and load them into R directly 
using url()?

Thanks!

Joseph


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Ask for help to debug the error on riesling1

[Jianhong Ou, Ph.D.]

Hi Martin,

Thank you for going so deep. I tried

R -d "valgrind --leak-check=full --track-origins=yes" -f plotInteractionData.R

to locate the exact line where initialed the possible leak.

Is there any other possibility that killed the process and did not leave any 
error log information?

Jianhong.

From: Martin Morgan 
Sent: Wednesday, April 7, 2021 2:16 PM
To: Jianhong Ou, Ph.D. ; Hervé Pagès 
; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Ask for help to debug the error on riesling1

I followed these steps, more or less, to configure and use valgrind on the 
Bioconductor docker image.

  
https://urldefense.com/v3/__https://gist.github.com/mtmorgan/77f9d92d81830eeb7f254809b445874d__;!!OToaGQ!-g840WABoFzxZ4_VS8wWp_YSW6KeHVFxX66mQcS2nGxeHwk8XlzjCnonGt7rnWeMU0g$

For this particular use I

- added the valgrind system dependency
- installed trackViewer and it's 'Suggests' dependencies in a standard R session
- made a git clone --depth 1 
https://urldefense.com/v3/__https://git.bioconductor.org/packages/trackViewer__;!!OToaGQ!-g840WABoFzxZ4_VS8wWp_YSW6KeHVFxX66mQcS2nGxeHwk8XlzjCnonGt7rzc3RP4s$
- made an R script from the vignette via cd vignettes && R CMD Stangle...
- ran once with

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -f plotInteractionData.R

  as a sanity check, then

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -d valgrind -f 
plotInteractionData.R

This lead to a single suspicious valgrind message

> importGInteractions(file=hic, format="hic",
+ ranges=GRanges("22", IRanges(5000, 1)),
+ out = "GInteractions")
==29679== Conditional jump or move depends on uninitialised value(s)
==29679==at 0x48428EC: memset (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29679==by 0x212D08FF: memset (string_fortified.h:71)
==29679==by 0x212D08FF: select_hits (Hits_class.c:324)
==29679==by 0x4944EB3: R_doDotCall (dotcode.c:614)
==29679==by 0x4945464: do_dotcall (dotcode.c:1281)
==29679==by 0x498AC35: bcEval (eval.c:7072)
==29679==by 0x4999DA7: Rf_eval (eval.c:727)
==29679==by 0x499BBDE: R_execClosure (eval.c:1897)
==29679==by 0x499CAD1: Rf_applyClosure (eval.c:1823)
==29679==by 0x4987DBD: bcEval (eval.c:7083)
==29679==by 0x4999DA7: Rf_eval (eval.c:727)
==29679==by 0x499BBDE: R_execClosure (eval.c:1897)
==29679==by 0x499CAD1: Rf_applyClosure (eval.c:1823)
==29679==

Hits_class.c:324 is in S4Vectors

if (nodup0) {
is_used = _new_CharAE(get_nnode(nRnode, "R"));
memset(is_used->elts, 0, is_used->_buflength);
}

I re-ran under gdb

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -d valgrind -f 
plotInteractionData.R
  ...
  (gdb) break Hits_class.c:324
  (gdb) run
  ...
  (gdb) continue
  ...
  > importGInteractions(file=hic, format="hic",
  + ranges=GRanges("22", IRanges(5000, 1)),
  + out = "GInteractions")

Thread 1 "R" hit Breakpoint 1, select_hits (from=,
  to=, nLnode=, nRnode=0x56071b51d5e8,
  select=, nodup=) at Hits_class.c:327
  327   in Hits_class.c
  (gdb) p *is_used
  $2 = {_buflength = 0, _nelt = 0, elts = 0x0}

I guess the complaint is about elts = 0x0, but I'm not really sure if this is 
enough to cause a fault during package build -- it seems like the code writes 
nothing nowhere, but ...

Martin Morgan

On 4/7/21, 8:08 AM, "Bioc-devel on behalf of Jianhong Ou, Ph.D." 
 wrote:

Hi Herv�,

Thank you for the information. I will try to figure out.

Jianhong.

From: Herv� Pag�s 
Sent: Wednesday, April 7, 2021 1:54 AM
To: Jianhong Ou, Ph.D. ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Ask for help to debug the error on riesling1

Hi Jianhong,

Memory leaks and other memory errors are bugs in native code that often
exist on all platforms but typically manifest themselves in different
ways depending on the platform where it runs. Running your code thru a
tool like Valgrind should reveal these problems even if you do this on a
non-Windows machine. See

https://urldefense.com/v3/__https://bioconductor.org/developers/how-to/c-debugging/__;!!OToaGQ!6X7J1i17XSPaKkNmZMcdEY24rEjchLfeQ8YTdhLB68dZII3WDxYfoPTTpGr2AOjQ4ds$
for more information.

Best,
H.


On 4/6/21 6:46 AM, Jianhong Ou, Ph.D. wrote:
> Hi,
>
> The trackViewer package got error on Windows Server since version 1.27.4. 
I am totally lost to figure it out by myself. The current error message listed 
in building system is:
>
>
> * creating vignettes ... ERROR
> --- re-building 'changeTracksStyles.Rmd' using rmarkdown
> --- finished re-building 'changeTracksStyles.Rmd'
>
> --- re-building 'dandelionPlot.Rmd' using rmarkdown
> --- finished re-building 'dandelionPlot.Rmd'
>
> --- re-building 

Re: [Bioc-devel] Suppressing messages from Rprofile

[Henrik Bengtsson]

Correcting: the env var is R_LIBS_USER and nothing else.

/Henrik

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

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

Re: [Bioc-devel] Suppressing messages from Rprofile

[Henrik Bengtsson]

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

Side tracking ...

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

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

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

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

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

/Henrik

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

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

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

[Henrik Bengtsson]

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

Version: 0.14.0 [2019-12-05]

SIGNIFICANT CHANGES:

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

/Henrik

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

Re: [Bioc-devel] BFG repo cleanup for package under review

[Nitesh Turaga]

Hi Spencer,

I�ve fixed the issue please try now.

Best,

Nitesh

From: Nitesh Turaga 
Date: Wednesday, April 7, 2021 at 1:31 PM
To: Spencer Nystrom , bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] BFG repo cleanup for package under review
Hi Spencer,

I�ll take a look at this today and get back to you

Thanks for the reminder.

Best,

Nitesh

From: Bioc-devel  on behalf of Spencer 
Nystrom 
Date: Wednesday, April 7, 2021 at 1:24 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] BFG repo cleanup for package under review
Sorry to ping about this twice, but my guess is this got buried over the
long weekend.

I need some help getting a cleaned up repo force pushed to the bioconductor
repository ( g...@git.bioconductor.org:packages/memes ). This is for a
package under review here:
https://github.com/Bioconductor/Contributions/issues/1997.

Thanks,
   -Spencer

[[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] Ask for help to debug the error on riesling1

[Martin Morgan]

I followed these steps, more or less, to configure and use valgrind on the 
Bioconductor docker image.

  https://gist.github.com/mtmorgan/77f9d92d81830eeb7f254809b445874d

For this particular use I

- added the valgrind system dependency
- installed trackViewer and it's 'Suggests' dependencies in a standard R session
- made a git clone --depth 1 https://git.bioconductor.org/packages/trackViewer
- made an R script from the vignette via cd vignettes && R CMD Stangle...
- ran once with

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -f plotInteractionData.R

  as a sanity check, then

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -d valgrind -f 
plotInteractionData.R

This lead to a single suspicious valgrind message

> importGInteractions(file=hic, format="hic",
+ ranges=GRanges("22", IRanges(5000, 1)),
+ out = "GInteractions")
==29679== Conditional jump or move depends on uninitialised value(s)
==29679==at 0x48428EC: memset (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29679==by 0x212D08FF: memset (string_fortified.h:71)
==29679==by 0x212D08FF: select_hits (Hits_class.c:324)
==29679==by 0x4944EB3: R_doDotCall (dotcode.c:614)
==29679==by 0x4945464: do_dotcall (dotcode.c:1281)
==29679==by 0x498AC35: bcEval (eval.c:7072)
==29679==by 0x4999DA7: Rf_eval (eval.c:727)
==29679==by 0x499BBDE: R_execClosure (eval.c:1897)
==29679==by 0x499CAD1: Rf_applyClosure (eval.c:1823)
==29679==by 0x4987DBD: bcEval (eval.c:7083)
==29679==by 0x4999DA7: Rf_eval (eval.c:727)
==29679==by 0x499BBDE: R_execClosure (eval.c:1897)
==29679==by 0x499CAD1: Rf_applyClosure (eval.c:1823)
==29679==

Hits_class.c:324 is in S4Vectors

if (nodup0) {
is_used = _new_CharAE(get_nnode(nRnode, "R"));
memset(is_used->elts, 0, is_used->_buflength);
}

I re-ran under gdb

  root@8dd16a8006a1:/tmp/trackViewer/vignettes# R -d valgrind -f 
plotInteractionData.R
  ...
  (gdb) break Hits_class.c:324
  (gdb) run
  ...
  (gdb) continue
  ...
  > importGInteractions(file=hic, format="hic",
  + ranges=GRanges("22", IRanges(5000, 1)),
  + out = "GInteractions")

Thread 1 "R" hit Breakpoint 1, select_hits (from=,
  to=, nLnode=, nRnode=0x56071b51d5e8,
  select=, nodup=) at Hits_class.c:327
  327   in Hits_class.c
  (gdb) p *is_used
  $2 = {_buflength = 0, _nelt = 0, elts = 0x0}

I guess the complaint is about elts = 0x0, but I'm not really sure if this is 
enough to cause a fault during package build -- it seems like the code writes 
nothing nowhere, but ...

Martin Morgan

On 4/7/21, 8:08 AM, "Bioc-devel on behalf of Jianhong Ou, Ph.D." 
 wrote:

Hi Herv�,

Thank you for the information. I will try to figure out.

Jianhong.

From: Herv� Pag�s 
Sent: Wednesday, April 7, 2021 1:54 AM
To: Jianhong Ou, Ph.D. ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Ask for help to debug the error on riesling1

Hi Jianhong,

Memory leaks and other memory errors are bugs in native code that often
exist on all platforms but typically manifest themselves in different
ways depending on the platform where it runs. Running your code thru a
tool like Valgrind should reveal these problems even if you do this on a
non-Windows machine. See

https://urldefense.com/v3/__https://bioconductor.org/developers/how-to/c-debugging/__;!!OToaGQ!6X7J1i17XSPaKkNmZMcdEY24rEjchLfeQ8YTdhLB68dZII3WDxYfoPTTpGr2AOjQ4ds$
for more information.

Best,
H.


On 4/6/21 6:46 AM, Jianhong Ou, Ph.D. wrote:
> Hi,
>
> The trackViewer package got error on Windows Server since version 1.27.4. 
I am totally lost to figure it out by myself. The current error message listed 
in building system is:
>
>
> * creating vignettes ... ERROR
> --- re-building 'changeTracksStyles.Rmd' using rmarkdown
> --- finished re-building 'changeTracksStyles.Rmd'
>
> --- re-building 'dandelionPlot.Rmd' using rmarkdown
> --- finished re-building 'dandelionPlot.Rmd'
>
> --- re-building 'lollipopPlot.Rmd' using rmarkdown
> --- finished re-building 'lollipopPlot.Rmd'
>
> --- re-building 'plotInteractionData.Rmd' using rmarkdown
>
> I suppose this is a memory leak error. But I don't have windows server to 
repeat the error. What is the best way to fix the issue? Thank you in advance 
for your help.
>
>
> 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 ...{{dropped:12}}
>
> ___
> Bioc-devel@r-project.org mailing list
> 

Re: [Bioc-devel] BFG repo cleanup for package under review

[Nitesh Turaga]

Hi Spencer,

I�ll take a look at this today and get back to you

Thanks for the reminder.

Best,

Nitesh

From: Bioc-devel  on behalf of Spencer 
Nystrom 
Date: Wednesday, April 7, 2021 at 1:24 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] BFG repo cleanup for package under review
Sorry to ping about this twice, but my guess is this got buried over the
long weekend.

I need some help getting a cleaned up repo force pushed to the bioconductor
repository ( g...@git.bioconductor.org:packages/memes ). This is for a
package under review here:
https://github.com/Bioconductor/Contributions/issues/1997.

Thanks,
   -Spencer

[[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] BFG repo cleanup for package under review

[Spencer Nystrom]

Sorry to ping about this twice, but my guess is this got buried over the
long weekend.

I need some help getting a cleaned up repo force pushed to the bioconductor
repository ( g...@git.bioconductor.org:packages/memes ). This is for a
package under review here:
https://github.com/Bioconductor/Contributions/issues/1997.

Thanks,
   -Spencer

[[alternative HTML version deleted]]

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

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

[Aaron Lun]

> There is no guarantee we would be under the right user to have permissions to 
> move the cache automatically and would not want to leave it in a broken state.

Well, can't you try? If people follow your 4.1 instructions and they
don't have permissions, the cache will be broken anyway.

But let's say you can't move it, and your worst-case scenario comes to
pass. EVEN THEN: I would expect a deprecation warning, no error, and
BiocFileCache continuing to pull from the old cache for 6 months.

Every previous non-transparent change to BioC's core infrastructure
has come with a deprecation warning. I don't see why this is any
different. An error is particularly galling given that the package was
working fine before, it's not like you're doing some kind of critical
bugfix.

> This should not affect any cache that is explicitly stated with a different 
> name in the constructor or using environment variables;  only in the case of 
> BiocFileCache() .  Most package specific caches created their own cache in 
> the constructor so it should not cause the ERROR in that case.

If Vince's last email is any indication, and calling ExperimentHub()
or AnnotationHub() causes an error... this will be a disaster. I'm
going to get a lot of emails, unnecessary emails, from users wondering
why scRNAseq and celldex don't work anymore. It'll be like our
AWS-China problems multiplied by 10.

Why not just make a new cache and populate it? Well, I don't really
care what you do, as long as I don't get an error.

-A

> 
> From: Aaron Lun 
> Sent: Wednesday, April 7, 2021 11:41 AM
> To: Kern, Lori 
> Cc: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
> ExperimentHub
>
> Woah, I missed the part where you said that there would be an error.
>
> This does not sound good. Users are going to flip out, especially when
> EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
> It also sounds completely unnecessary for EHub and AHub given that the
> new cache can just be populated by fresh downloads. Similarly,
> BiocFileCache::bfcrpath should not be affected, and people using that
> shouldn't be getting an error.
>
> Why not just move the old default cache into the new location
> automatically? This seems like the simplest solution given that
> everyone accessing BFC resources should be doing so through the BFC
> API. And most files are not position-dependent, unless people are
> putting shared libraries in there.
>
> But even if you can't, an error is just too much. We use BiocFileCache
> a lot in our company infrastructure and the brown stuff will hit the
> fan if we have to find every old default cache and delete it. The
> package should handle this for us.
>
> -A
>
> On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori  
> wrote:
> >
> > Mostly to lighten the dependency tree using tools that is built in with R 
> > would remove one additional dependency.  Also clarity; the tools directory 
> > adds an R folder for distinction that they are used with R packages which 
> > seemed like if a user was ever investigating, they would have a better idea 
> > where those files came from.
> >
> >
> > 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 Aaron Lun 
> > 
> > Sent: Wednesday, April 7, 2021 4:10 AM
> > To: bioc-devel@r-project.org 
> > Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
> > ExperimentHub
> >
> > rebook and basilisk are also currently using rappdirs. I would be
> > interested in the motivation behind the switch for the Hubs and whether
> > that is applicable to those two packages as well.
> >
> > -A
> >
> > On 4/5/21 6:41 AM, Kern, Lori wrote:
> > > We are in process of making some major updates to the caching in 
> > > BiocFileCache, AnnotationHub, and ExperimentHub.  Namely, the default 
> > > caching location will change from using rappdirs::user_cache_dir   to 
> > > using  tools::R_user_dir  eventually relieving the dependency on 
> > > rappdirs.  To avoid conflicting default caches, if anyone used an old 
> > > default caching directory, there will be an error to decide how to deal 
> > > with the old location before proceeding and documentation in the 
> > > vignettes for how to resolve.  Currently I have update BiocFileCache, the 
> > > changes were just pushed to the devel branch and should propagate 
> > > tonight.  I plan on doing the same for both AnnotationHub and 
> > > ExperimentHub within the next few days.  We appreciate any feedback or 
> > > questions with regards to these updates.
> > >
> > > This is only relevant to using the default cache location,  if a user 
> > > manually specified a unique location, used environment variables, or 
> > > created a package 

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

[Vincent Carey]

The experience:

> ah = AnnotationHub()
Error in AnnotationHub() :
  As of AnnotationHub (>2.23.2), default caching location has changed.
  Problematic cache: /home/stvjc/.cache/AnnotationHub
  To continue with default caching location,
  See AnnotationHub vignette TroubleshootingTheCache section on 'Default
Caching Location Update'

Enter a frame number, or 0 to exit

1: AnnotationHub()

Selection: 0
> rappdirs::user_cache_dir(appname="BiocFileCache")
[1] "~/.cache/BiocFileCache"
> rappdirs::user_cache_dir(appname="AnnotationHub")
[1] "~/.cache/AnnotationHub"   # solution from vignette:  850MB moved very
quickly...
> olddir <- path.expand(rappdirs::user_cache_dir(appname="AnnotationHub"))
> newdir <- tools::R_user_dir("AnnotationHub", which="cache")
> dir.create(path=newdir, recursive=TRUE)
> files <- list.files(olddir, full.names =TRUE)
> moveres <- vapply(files,
+ FUN=function(fl){
+   filename = basename(fl)
+   newname = file.path(newdir, filename)
+   file.rename(fl, newname)
+ },
+ FUN.VALUE = logical(1))
> if(all(moveres)) unlink(olddir, recursive=TRUE)
> ah = AnnotationHub()  # try again
snapshotDate(): 2021-03-15


On Wed, Apr 7, 2021 at 12:03 PM Vincent Carey 
wrote:

> For convenience here are relevant sections of the new vignette.   Give it
> a try and let us know.  This is "devel".
>
> 4Default Caching Location Update
>
> As of BiocFileCache version > 1.15.1, the default caching location has
> changed. The default cache is now controlled by the function
> tools::R_user_dir instead of rappdirs::user_cache_dir. Users who have
> utilized the default BiocFileCache, to continue using the created cache,
> must move the cache and its files to the new default location or delete the
> old cache and have to redownload any previous files.
> 4.1Option 1: Moving Files
>
> The following steps can be used to move the files to the new location:
>
>1.
>
>Determine the old location by running the following in R
>rappdirs::user_cache_dir(appname="BiocFileCache")
>2.
>
>Determine the new location by running the following in R 
> tools::R_user_dir("BiocFileCache",
>which="cache")
>3.
>
>Move the files to the new location. You can do this manually or do the
>following steps in R. Remember if you have a lot of cached files, this may
>take awhile.
>
> olddir <- path.expand(rappdirs::user_cache_dir(appname="BiocFileCache"))
> newdir <- tools::R_user_dir("BiocFileCache", which="cache")
> dir.create(path=newdir, recursive=TRUE)
> files <- list.files(olddir, full.names =TRUE)
> moveres <- vapply(files,
> FUN=function(fl){
>   filename = basename(fl)
>   newname = file.path(newdir, filename)
>   file.rename(fl, newname)
> },
> FUN.VALUE = logical(1))
> if(all(moveres)) unlink(olddir, recursive=TRUE)
>
> 4.2Option 2: Specify a Cache Location Explicitly
>
> Users may always specify a unique caching location by providing the cache 
> argument
> to the BiocFileCache constructor; however users must always specify this
> location as it will not be recognized by default in subsequent runs.
>
> Alternatively, the default caching location may also be controlled by a
> user-wise or system-wide environment variable. Users may set the
> environment variable BFC_CACHE to the old location to continue using as
> default location.
>
> On Wed, Apr 7, 2021 at 11:51 AM Kern, Lori 
> wrote:
>
>> There is no guarantee we would be under the right user to have
>> permissions to move the cache automatically and would not want to leave it
>> in a broken state.
>>
>> We could start a fresh cache in the new location but there would be no
>> way to combined an old cache and a new cache and there would be no way to
>> warn people before starting the new cache to give them an opportunity to
>> move the old cache to the new location.
>>
>> This should not affect any cache that is explicitly stated with a
>> different name in the constructor or using environment variables;  only in
>> the case of BiocFileCache() .  Most package specific caches created their
>> own cache in the constructor so it should not cause the ERROR in that case.
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>> 
>> From: Aaron Lun 
>> Sent: Wednesday, April 7, 2021 11:41 AM
>> To: Kern, Lori 
>> Cc: bioc-devel@r-project.org 
>> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and
>> ExperimentHub
>>
>> Woah, I missed the part where you said that there would be an error.
>>
>> This does not sound good. Users are going to flip out, especially when
>> EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
>> It also sounds completely unnecessary for EHub and AHub given that the
>> new 

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

[Vincent Carey]

For convenience here are relevant sections of the new vignette.   Give it a
try and let us know.  This is "devel".

4Default Caching Location Update

As of BiocFileCache version > 1.15.1, the default caching location has
changed. The default cache is now controlled by the function
tools::R_user_dir instead of rappdirs::user_cache_dir. Users who have
utilized the default BiocFileCache, to continue using the created cache,
must move the cache and its files to the new default location or delete the
old cache and have to redownload any previous files.
4.1Option 1: Moving Files

The following steps can be used to move the files to the new location:

   1.

   Determine the old location by running the following in R
   rappdirs::user_cache_dir(appname="BiocFileCache")
   2.

   Determine the new location by running the following in R
tools::R_user_dir("BiocFileCache",
   which="cache")
   3.

   Move the files to the new location. You can do this manually or do the
   following steps in R. Remember if you have a lot of cached files, this may
   take awhile.

olddir <- path.expand(rappdirs::user_cache_dir(appname="BiocFileCache"))
newdir <- tools::R_user_dir("BiocFileCache", which="cache")
dir.create(path=newdir, recursive=TRUE)
files <- list.files(olddir, full.names =TRUE)
moveres <- vapply(files,
FUN=function(fl){
  filename = basename(fl)
  newname = file.path(newdir, filename)
  file.rename(fl, newname)
},
FUN.VALUE = logical(1))
if(all(moveres)) unlink(olddir, recursive=TRUE)

4.2Option 2: Specify a Cache Location Explicitly

Users may always specify a unique caching location by providing the
cache argument
to the BiocFileCache constructor; however users must always specify this
location as it will not be recognized by default in subsequent runs.

Alternatively, the default caching location may also be controlled by a
user-wise or system-wide environment variable. Users may set the
environment variable BFC_CACHE to the old location to continue using as
default location.

On Wed, Apr 7, 2021 at 11:51 AM Kern, Lori 
wrote:

> There is no guarantee we would be under the right user to have permissions
> to move the cache automatically and would not want to leave it in a broken
> state.
>
> We could start a fresh cache in the new location but there would be no way
> to combined an old cache and a new cache and there would be no way to warn
> people before starting the new cache to give them an opportunity to move
> the old cache to the new location.
>
> This should not affect any cache that is explicitly stated with a
> different name in the constructor or using environment variables;  only in
> the case of BiocFileCache() .  Most package specific caches created their
> own cache in the constructor so it should not cause the ERROR in that case.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Aaron Lun 
> Sent: Wednesday, April 7, 2021 11:41 AM
> To: Kern, Lori 
> Cc: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and
> ExperimentHub
>
> Woah, I missed the part where you said that there would be an error.
>
> This does not sound good. Users are going to flip out, especially when
> EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
> It also sounds completely unnecessary for EHub and AHub given that the
> new cache can just be populated by fresh downloads. Similarly,
> BiocFileCache::bfcrpath should not be affected, and people using that
> shouldn't be getting an error.
>
> Why not just move the old default cache into the new location
> automatically? This seems like the simplest solution given that
> everyone accessing BFC resources should be doing so through the BFC
> API. And most files are not position-dependent, unless people are
> putting shared libraries in there.
>
> But even if you can't, an error is just too much. We use BiocFileCache
> a lot in our company infrastructure and the brown stuff will hit the
> fan if we have to find every old default cache and delete it. The
> package should handle this for us.
>
> -A
>
> On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori 
> wrote:
> >
> > Mostly to lighten the dependency tree using tools that is built in with
> R would remove one additional dependency.  Also clarity; the tools
> directory adds an R folder for distinction that they are used with R
> packages which seemed like if a user was ever investigating, they would
> have a better idea where those files came from.
> >
> >
> > Lori Shepherd
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> > 
> > From: 

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

[Kern, Lori]

There is no guarantee we would be under the right user to have permissions to 
move the cache automatically and would not want to leave it in a broken state.

We could start a fresh cache in the new location but there would be no way to 
combined an old cache and a new cache and there would be no way to warn people 
before starting the new cache to give them an opportunity to move the old cache 
to the new location.

This should not affect any cache that is explicitly stated with a different 
name in the constructor or using environment variables;  only in the case of 
BiocFileCache() .  Most package specific caches created their own cache in the 
constructor so it should not cause the ERROR in that case.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Aaron Lun 
Sent: Wednesday, April 7, 2021 11:41 AM
To: Kern, Lori 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
ExperimentHub

Woah, I missed the part where you said that there would be an error.

This does not sound good. Users are going to flip out, especially when
EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
It also sounds completely unnecessary for EHub and AHub given that the
new cache can just be populated by fresh downloads. Similarly,
BiocFileCache::bfcrpath should not be affected, and people using that
shouldn't be getting an error.

Why not just move the old default cache into the new location
automatically? This seems like the simplest solution given that
everyone accessing BFC resources should be doing so through the BFC
API. And most files are not position-dependent, unless people are
putting shared libraries in there.

But even if you can't, an error is just too much. We use BiocFileCache
a lot in our company infrastructure and the brown stuff will hit the
fan if we have to find every old default cache and delete it. The
package should handle this for us.

-A

On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori  wrote:
>
> Mostly to lighten the dependency tree using tools that is built in with R 
> would remove one additional dependency.  Also clarity; the tools directory 
> adds an R folder for distinction that they are used with R packages which 
> seemed like if a user was ever investigating, they would have a better idea 
> where those files came from.
>
>
> 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 Aaron Lun 
> 
> Sent: Wednesday, April 7, 2021 4:10 AM
> To: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
> ExperimentHub
>
> rebook and basilisk are also currently using rappdirs. I would be
> interested in the motivation behind the switch for the Hubs and whether
> that is applicable to those two packages as well.
>
> -A
>
> On 4/5/21 6:41 AM, Kern, Lori wrote:
> > We are in process of making some major updates to the caching in 
> > BiocFileCache, AnnotationHub, and ExperimentHub.  Namely, the default 
> > caching location will change from using rappdirs::user_cache_dir   to using 
> >  tools::R_user_dir  eventually relieving the dependency on rappdirs.  To 
> > avoid conflicting default caches, if anyone used an old default caching 
> > directory, there will be an error to decide how to deal with the old 
> > location before proceeding and documentation in the vignettes for how to 
> > resolve.  Currently I have update BiocFileCache, the changes were just 
> > pushed to the devel branch and should propagate tonight.  I plan on doing 
> > the same for both AnnotationHub and ExperimentHub within the next few days. 
> >  We appreciate any feedback or questions with regards to these updates.
> >
> > This is only relevant to using the default cache location,  if a user 
> > manually specified a unique location, used environment variables, or 
> > created a package specific cache the code/location is not affected.  Anyone 
> > using package specific caching that utilizes rappdirs is encouraged also to 
> > consider changing package code to use the now available function in tools.
> >
> > Cheers,
> >
> >
> > Lori Shepherd
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> >
> > This email message may contain legally privileged and/or confidential 
> > information.  If you are not the intended recipient(s), or the employee or 
> > agent responsible for the delivery of this message to the intended 
> > recipient(s), you are hereby notified that any disclosure, copying, 
> > distribution, or use of 

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

[Aaron Lun]

Woah, I missed the part where you said that there would be an error.

This does not sound good. Users are going to flip out, especially when
EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
It also sounds completely unnecessary for EHub and AHub given that the
new cache can just be populated by fresh downloads. Similarly,
BiocFileCache::bfcrpath should not be affected, and people using that
shouldn't be getting an error.

Why not just move the old default cache into the new location
automatically? This seems like the simplest solution given that
everyone accessing BFC resources should be doing so through the BFC
API. And most files are not position-dependent, unless people are
putting shared libraries in there.

But even if you can't, an error is just too much. We use BiocFileCache
a lot in our company infrastructure and the brown stuff will hit the
fan if we have to find every old default cache and delete it. The
package should handle this for us.

-A

On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori  wrote:
>
> Mostly to lighten the dependency tree using tools that is built in with R 
> would remove one additional dependency.  Also clarity; the tools directory 
> adds an R folder for distinction that they are used with R packages which 
> seemed like if a user was ever investigating, they would have a better idea 
> where those files came from.
>
>
> 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 Aaron Lun 
> 
> Sent: Wednesday, April 7, 2021 4:10 AM
> To: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
> ExperimentHub
>
> rebook and basilisk are also currently using rappdirs. I would be
> interested in the motivation behind the switch for the Hubs and whether
> that is applicable to those two packages as well.
>
> -A
>
> On 4/5/21 6:41 AM, Kern, Lori wrote:
> > We are in process of making some major updates to the caching in 
> > BiocFileCache, AnnotationHub, and ExperimentHub.  Namely, the default 
> > caching location will change from using rappdirs::user_cache_dir   to using 
> >  tools::R_user_dir  eventually relieving the dependency on rappdirs.  To 
> > avoid conflicting default caches, if anyone used an old default caching 
> > directory, there will be an error to decide how to deal with the old 
> > location before proceeding and documentation in the vignettes for how to 
> > resolve.  Currently I have update BiocFileCache, the changes were just 
> > pushed to the devel branch and should propagate tonight.  I plan on doing 
> > the same for both AnnotationHub and ExperimentHub within the next few days. 
> >  We appreciate any feedback or questions with regards to these updates.
> >
> > This is only relevant to using the default cache location,  if a user 
> > manually specified a unique location, used environment variables, or 
> > created a package specific cache the code/location is not affected.  Anyone 
> > using package specific caching that utilizes rappdirs is encouraged also to 
> > consider changing package code to use the now available function in tools.
> >
> > Cheers,
> >
> >
> > Lori Shepherd
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> >
> > This email message may contain legally privileged and/or confidential 
> > information.  If you are not the intended recipient(s), or the employee or 
> > agent responsible for the delivery of this message to the intended 
> > recipient(s), you are hereby notified that any disclosure, copying, 
> > distribution, or use of this email message is prohibited.  If you have 
> > received this message in error, please notify the sender immediately by 
> > e-mail and delete this email message from your computer. Thank you.
> >[[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://secure-web.cisco.com/1xDKtwmD7KF6XN2PGsO5WMb8MUBuVd1_7pAaiY6x4Jc1PgpDH8GiGacn-IzghnM40n60o567y87UdWrsqKF1LJRwGTwXOP598j5D7E6SPBKpWfVoTsB78DxjOEhJN0-wwvxq-4tw3xW2W3I1DpwxlybPtN8tG2zlJiSHn9OBn0hHbo8lo81oVIOopo4mAa_ui2PcrX6zQPeh322U9G813vyhB3BsSA7YM-V70ahEdb6JUf-XZBqeY_mSavleRlfFk4-ROT8ng5D16P9XlU-qk1i64Gjc_Q0dExIV1WKOh5Sr7c05LH0vQ6eRG-IHZTN7O/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> >
>
> ___
> Bioc-devel@r-project.org mailing list
> 

[Bioc-devel] Suppressing messages from Rprofile

[Mike Smith]

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

Re: [Bioc-devel] Ask for help to debug the error on riesling1

[Jianhong Ou, Ph.D.]

Hi Herv�,

Thank you for the information. I will try to figure out.

Jianhong.

From: Herv� Pag�s 
Sent: Wednesday, April 7, 2021 1:54 AM
To: Jianhong Ou, Ph.D. ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Ask for help to debug the error on riesling1

Hi Jianhong,

Memory leaks and other memory errors are bugs in native code that often
exist on all platforms but typically manifest themselves in different
ways depending on the platform where it runs. Running your code thru a
tool like Valgrind should reveal these problems even if you do this on a
non-Windows machine. See
https://urldefense.com/v3/__https://bioconductor.org/developers/how-to/c-debugging/__;!!OToaGQ!6X7J1i17XSPaKkNmZMcdEY24rEjchLfeQ8YTdhLB68dZII3WDxYfoPTTpGr2AOjQ4ds$
for more information.

Best,
H.


On 4/6/21 6:46 AM, Jianhong Ou, Ph.D. wrote:
> Hi,
>
> The trackViewer package got error on Windows Server since version 1.27.4. I 
> am totally lost to figure it out by myself. The current error message listed 
> in building system is:
>
>
> * creating vignettes ... ERROR
> --- re-building 'changeTracksStyles.Rmd' using rmarkdown
> --- finished re-building 'changeTracksStyles.Rmd'
>
> --- re-building 'dandelionPlot.Rmd' using rmarkdown
> --- finished re-building 'dandelionPlot.Rmd'
>
> --- re-building 'lollipopPlot.Rmd' using rmarkdown
> --- finished re-building 'lollipopPlot.Rmd'
>
> --- re-building 'plotInteractionData.Rmd' using rmarkdown
>
> I suppose this is a memory leak error. But I don't have windows server to 
> repeat the error. What is the best way to fix the issue? Thank you in advance 
> for your help.
>
>
> 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 ...{{dropped:12}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!OToaGQ!6X7J1i17XSPaKkNmZMcdEY24rEjchLfeQ8YTdhLB68dZII3WDxYfoPTTpGr2_rFwouU$
>

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

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

[Kern, Lori]

Mostly to lighten the dependency tree using tools that is built in with R would 
remove one additional dependency.  Also clarity; the tools directory adds an R 
folder for distinction that they are used with R packages which seemed like if 
a user was ever investigating, they would have a better idea where those files 
came from.



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

Sent: Wednesday, April 7, 2021 4:10 AM
To: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and 
ExperimentHub

rebook and basilisk are also currently using rappdirs. I would be
interested in the motivation behind the switch for the Hubs and whether
that is applicable to those two packages as well.

-A

On 4/5/21 6:41 AM, Kern, Lori wrote:
> We are in process of making some major updates to the caching in 
> BiocFileCache, AnnotationHub, and ExperimentHub.  Namely, the default caching 
> location will change from using rappdirs::user_cache_dir   to using  
> tools::R_user_dir  eventually relieving the dependency on rappdirs.  To avoid 
> conflicting default caches, if anyone used an old default caching directory, 
> there will be an error to decide how to deal with the old location before 
> proceeding and documentation in the vignettes for how to resolve.  Currently 
> I have update BiocFileCache, the changes were just pushed to the devel branch 
> and should propagate tonight.  I plan on doing the same for both 
> AnnotationHub and ExperimentHub within the next few days.  We appreciate any 
> feedback or questions with regards to these updates.
>
> This is only relevant to using the default cache location,  if a user 
> manually specified a unique location, used environment variables, or created 
> a package specific cache the code/location is not affected.  Anyone using 
> package specific caching that utilizes rappdirs is encouraged also to 
> consider changing package code to use the now available function in tools.
>
> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
>[[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1xDKtwmD7KF6XN2PGsO5WMb8MUBuVd1_7pAaiY6x4Jc1PgpDH8GiGacn-IzghnM40n60o567y87UdWrsqKF1LJRwGTwXOP598j5D7E6SPBKpWfVoTsB78DxjOEhJN0-wwvxq-4tw3xW2W3I1DpwxlybPtN8tG2zlJiSHn9OBn0hHbo8lo81oVIOopo4mAa_ui2PcrX6zQPeh322U9G813vyhB3BsSA7YM-V70ahEdb6JUf-XZBqeY_mSavleRlfFk4-ROT8ng5D16P9XlU-qk1i64Gjc_Q0dExIV1WKOh5Sr7c05LH0vQ6eRG-IHZTN7O/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1xDKtwmD7KF6XN2PGsO5WMb8MUBuVd1_7pAaiY6x4Jc1PgpDH8GiGacn-IzghnM40n60o567y87UdWrsqKF1LJRwGTwXOP598j5D7E6SPBKpWfVoTsB78DxjOEhJN0-wwvxq-4tw3xW2W3I1DpwxlybPtN8tG2zlJiSHn9OBn0hHbo8lo81oVIOopo4mAa_ui2PcrX6zQPeh322U9G813vyhB3BsSA7YM-V70ahEdb6JUf-XZBqeY_mSavleRlfFk4-ROT8ng5D16P9XlU-qk1i64Gjc_Q0dExIV1WKOh5Sr7c05LH0vQ6eRG-IHZTN7O/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

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

[Aaron Lun]

rebook and basilisk are also currently using rappdirs. I would be 
interested in the motivation behind the switch for the Hubs and whether 
that is applicable to those two packages as well.


-A

On 4/5/21 6:41 AM, Kern, Lori wrote:

We are in process of making some major updates to the caching in BiocFileCache, 
AnnotationHub, and ExperimentHub.  Namely, the default caching location will 
change from using rappdirs::user_cache_dir   to using  tools::R_user_dir  
eventually relieving the dependency on rappdirs.  To avoid conflicting default 
caches, if anyone used an old default caching directory, there will be an error 
to decide how to deal with the old location before proceeding and documentation 
in the vignettes for how to resolve.  Currently I have update BiocFileCache, 
the changes were just pushed to the devel branch and should propagate tonight.  
I plan on doing the same for both AnnotationHub and ExperimentHub within the 
next few days.  We appreciate any feedback or questions with regards to these 
updates.

This is only relevant to using the default cache location,  if a user manually 
specified a unique location, used environment variables, or created a package 
specific cache the code/location is not affected.  Anyone using package 
specific caching that utilizes rappdirs is encouraged also to consider changing 
package code to use the now available function in tools.

Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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

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



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