date:20210323

Re: [Bioc-devel] ChIPseeker failing on r-devel on CRAN checks

2021-03-23 Thread Hervé Pagès


Hi Onur,

AFAICT ChIPseeker is currently available on all platforms in BioC devel:

  https://bioconductor.org/packages/3.13/ChIPseeker

Same for all the other Bioconductor packages that the CRAN check results 
for cinaR say are not available:


- CRAN check results:

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/cinaR-00check.html

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/cinaR-00check.html

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/cinaR-00check.html

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-gcc/cinaR-00check.html

- Packages reported as not available are available:

  pkgs_reported_as_not_available <- c(
  'ChIPseeker',
  'DESeq2',
  'TxDb.Hsapiens.UCSC.hg38.knownGene',
  'TxDb.Hsapiens.UCSC.hg19.knownGene',
  'TxDb.Mmusculus.UCSC.mm10.knownGene')

  library(BiocManager)
  # Bioconductor version 3.13 (BiocManager 1.30.11), 
?BiocManager::install for help


  available_pkgs <- 
rownames(available.packages(contrib.url(repositories(


  pkgs_reported_as_not_available %in% available_pkgs
  # [1] TRUE TRUE TRUE TRUE TRUE

So to me it looks like some hiccup in the CRAN builds.

H.


On 3/23/21 3:12 PM, Onur Karakaslar wrote:

Hi all,

I have a CRAN package called cinaR which depends on ChIPseeker. Yet, I
recently learned that ChIPseeker is actually failing on r-devel checks of
CRAN, which possibly fails my package as well. You can find the detailed
info here:

https://support.bioconductor.org/p/9135778/

Can anyone help me figure this out?

Thank you very much for your help!
Best,
Onur

[[alternative HTML version deleted]]

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



--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

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

Re: [Bioc-devel] adding maintainers to SpatialExperiment repo

2021-03-23 Thread Lukas Weber

Thanks Dario.

Could we please use my gmail address for this (this address), which is the
one I used for registering my Bioconductor account.

(Sorry for possible duplicate email - I previously tried replying from my
other address, which is not registered to the Bioc-devel list so email
possibly bounced.)

Best regards,
Lukas


On Tue, Mar 23, 2021 at 4:28 PM Dario Righelli 
wrote:

> Hi Guys,
>
> we'd like to add Helena Crowell and Lukas Weber (CC) as maintainers of
> the SpatialExperiment repo so that they can push on the upstream.
>
> Thanks,
> Dario
>
> ___
> 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] ChIPseeker failing on r-devel on CRAN checks

2021-03-23 Thread Onur Karakaslar

Hi all,

I have a CRAN package called cinaR which depends on ChIPseeker. Yet, I
recently learned that ChIPseeker is actually failing on r-devel checks of
CRAN, which possibly fails my package as well. You can find the detailed
info here:

https://support.bioconductor.org/p/9135778/

Can anyone help me figure this out?

Thank you very much for your help!
Best,
Onur

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] adding maintainers to SpatialExperiment repo

2021-03-23 Thread Lukas Weber

Thanks Dario.

Could we please use my gmail address for this (cc’d), which is the address I 
used for registering my Bioconductor account.

Best regards,
Lukas


Lukas M. Weber, Ph.D.
Postdoctoral Fellow
Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health
https://lmweber.org/

On Mar 23, 2021, at 16:27, Dario Righelli 
mailto:dario.righe...@gmail.com>> wrote:


External Email - Use Caution



Hi Guys,

we'd like to add Helena Crowell and Lukas Weber (CC) as maintainers of
the SpatialExperiment repo so that they can push on the upstream.

Thanks,
Dario



[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Hervé Pagès

On 3/23/21 1:31 PM, Murphy, Alan E wrote:

Hi Hervé,

My apologies but I don't think I follow your approach. I have put your 
code below into a utils.R script in ewceData:

.my_internal_global_variables <- new.env(parent=emptyenv())

    .get_eh <- function() get("eh", envir=.my_internal_global_variables)
    .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

    get_ExperimentHub <- function()
    {
  eh <- try(.get_eh(), silent=TRUE)
  if (inherits(eh, "try-error")) {
    eh <- ExperimentHub::ExperimentHub()
    .set_eh(eh)
  }
  eh
    }

Then in EWCE, I have made a script for each dataset containing the 
function you outlined. Note I had to use ewceData:::get_ExperimentHub to 
access the function, not sure if this is wrong by me up to this point:

## Exported.
tt_alzh <- function()
{
   eh <- ewceData:::get_ExperimentHub()
   eh[["EH5373"]]
}

Lastly to call a dataset I simply use tt_alzh(). However, now when I run 
a test script I believe the eh statement is being repeatedly called 
still as I get multiple warnings and the runtime doesn't improve any.

'eh' is a variable so I'm not sure how can it be "repeatedly called".

Also not sure why you want to move tt_alzh() from ewceData to EWCE. 
Nothing wrong in having it in the former which is actually the natural 
place for it.

I made these changes to ewceData (see full patch below, note that I 
renamed my tt_alzh -> load_tt_alzh to avoid conflict with your tt_alzh) 
and things seem to work as expected for me:

  > library(ewceData)

  > system.time(tt_alzh <- tt_alzh())
  snapshotDate(): 2021-03-23
  see ?ewceData and browseVignettes('ewceData') for documentation
  loading from cache
 user  system elapsed
2.441   0.028   4.720

  > system.time(tt_alzh <- load_tt_alzh())
  see ?ewceData and browseVignettes('ewceData') for documentation
  loading from cache
 user  system elapsed
1.215   0.012   1.727

No warning.

H.

hpages@spectre:~/sandbox/ewceData$ git diff --cached
diff --git a/NAMESPACE b/NAMESPACE
index 0144dc9..8ad9b64 100644
--- a/NAMESPACE
+++ b/NAMESPACE
@@ -6,3 +6,5 @@ import(ExperimentHubData)
 import(utils)
 importFrom(AnnotationHub,query)
 importFrom(utils,read.csv)
+
+export(load_tt_alzh)
diff --git a/R/utils.R b/R/utils.R
new file mode 100644
index 000..c295aef
--- /dev/null
+++ b/R/utils.R
@@ -0,0 +1,15 @@
+.my_internal_global_variables <- new.env(parent=emptyenv())
+
+.get_eh <- function() get("eh", envir=.my_internal_global_variables)
+.set_eh <- function(value) assign("eh", value, 
envir=.my_internal_global_variables)

+
+get_ExperimentHub <- function()
+{
+eh <- try(.get_eh(), silent=TRUE)
+if (inherits(eh, "try-error")) {
+eh <- ExperimentHub::ExperimentHub()
+.set_eh(eh)
+}
+eh
+}
+
diff --git a/R/zzz.R b/R/zzz.R
index cf0d87e..b1159b0 100644
--- a/R/zzz.R
+++ b/R/zzz.R
@@ -34,4 +34,12 @@
assign(xx, func, envir=ns)
namespaceExport(ns, xx)
  })
-}
\ No newline at end of file
+}
+
+## Exported.
+load_tt_alzh <- function()
+{
+eh <- get_ExperimentHub()
+eh[["EH5373"]]
+}

Sorry again if I have misinterpreted your approach.

Kind regards,
Alan.

*From:* Hervé Pagès 
*Sent:* 23 March 2021 19:08
*To:* Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 

*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
Doesn't really matter where you put them but
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't
need to be defined inside the .onLoad() hook, and it's actually
cleaner/easier to not define them there. You can define there anywhere
in your ewceData/R/* files.

Here is a slightly improved version of the code:

    .my_internal_global_variables <- new.env(parent=emptyenv())

    .get_eh <- function() get("eh", envir=.my_internal_global_variables)
    .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

    get_ExperimentHub <- function()
    {
  eh <- try(.get_eh(), silent=TRUE)
  if (inherits(eh, "try-error")) {
    eh <- ExperimentHub::ExperimentHub()
    .set_eh(eh)
  }
  eh
    }

In my packages I like to put this kind of low-level stuff in R/utils.R.
None of this is exported.

Then anywhere in your package when you need an ExperimentHub instance, do:

    ## Exported.
    tt_alzh <- function()
    {
  eh <- get_ExperimentHub()
  eh[["EH5373"]]
    }

H.

On 3/23/21 10:53 AM, Murphy, Alan E wrote:

HeyHervé,

Thanks for this it is very helpful and I'm very sorry but I have one 
more question, where to put option 3? I thought making an onload r 
script for it:

.onLoad <- function(libname, pkgname) {
    .my_internal_global_variables <- new.env(parent=emptyenv())
    .get_eh <- function() get("eh", envir=.my_internal_global_variables)
    .set_eh <- function(value) assign("eh", value,

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Murphy, Alan E

Hi Herv�,

My apologies but I don't think I follow your approach. I have put your code 
below into a utils.R script in ewceData:

   .my_internal_global_variables <- new.env(parent=emptyenv())

   .get_eh <- function() get("eh", envir=.my_internal_global_variables)
   .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

   get_ExperimentHub <- function()
   {
 eh <- try(.get_eh(), silent=TRUE)
 if (inherits(eh, "try-error")) {
   eh <- ExperimentHub::ExperimentHub()
   .set_eh(eh)
 }
 eh
   }

Then in EWCE, I have made a script for each dataset containing the function you 
outlined. Note I had to use ewceData:::get_ExperimentHub to access the 
function, not sure if this is wrong by me up to this point:

## Exported.
tt_alzh <- function()
{
  eh <- ewceData:::get_ExperimentHub()
  eh[["EH5373"]]
}

Lastly to call a dataset I simply use tt_alzh(). However, now when I run a test 
script I believe the eh statement is being repeatedly called still as I get 
multiple warnings and the runtime doesn't improve any.

Sorry again if I have misinterpreted your approach.

Kind regards,
Alan.

From: Herv� Pag�s 
Sent: 23 March 2021 19:08
To: Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

Doesn't really matter where you put them but
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't
need to be defined inside the .onLoad() hook, and it's actually
cleaner/easier to not define them there. You can define there anywhere
in your ewceData/R/* files.

Here is a slightly improved version of the code:

   .my_internal_global_variables <- new.env(parent=emptyenv())

   .get_eh <- function() get("eh", envir=.my_internal_global_variables)
   .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

   get_ExperimentHub <- function()
   {
 eh <- try(.get_eh(), silent=TRUE)
 if (inherits(eh, "try-error")) {
   eh <- ExperimentHub::ExperimentHub()
   .set_eh(eh)
 }
 eh
   }

In my packages I like to put this kind of low-level stuff in R/utils.R.
None of this is exported.

Then anywhere in your package when you need an ExperimentHub instance, do:

   ## Exported.
   tt_alzh <- function()
   {
 eh <- get_ExperimentHub()
 eh[["EH5373"]]
   }

H.


On 3/23/21 10:53 AM, Murphy, Alan E wrote:
> HeyHerv�,
>
> Thanks for this it is very helpful and I'm very sorry but I have one
> more question, where to put option 3? I thought making an onload r
> script for it:
>
> .onLoad <- function(libname, pkgname) {
>.my_internal_global_variables <- new.env(parent=emptyenv())
>.get_eh <- function() get("eh", envir=.my_internal_global_variables)
>.set_eh <- function(value) assign("eh", value,
>  envir=.my_internal_global_variables)
>toto <- function()
>{
>  eh <- try(.get_eh(), silent=TRUE)
>  if (inherits(eh, "try-error")) {
>eh <- ExperimentHub()
>.set_eh(eh)
>  }
>  eh
>}
>toto()
> }
>
> This seems to work in that the script runs (I can tell based on the
> output with devtools::check()) but I still get an error that eh doesn't
> exist in my test functions.
>
> Kind regards,
> Alan.
> 
> *From:* Herv� Pag�s 
> *Sent:* 23 March 2021 17:31
> *To:* Murphy, Alan E ; Martin Morgan
> ; Kern, Lori ;
> bioc-devel@r-project.org 
> *Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
> 3 ways to do this, one that doesn't work, and two that work ;-)
>
>
> 1. Simple way that doesn't work:
>
> ## Just a place holder. Will be initialized at run-time the first
> ## time it's needed.
> .some_internal_global_variable <- NULL
>
> toto <- function()
> {
>   if (is.null(.some_global_variable))
>   .some_internal_global_variable <<- 55L
> }
>
> However, if you put this in your package, you'll get the following
> error the first time toto() is called:
>
>   cannot change value of locked binding for
> '.some_internal_global_variable'
>
> 2. Simple way that works: initialize the global variable in the
>  .onLoad() hook. This works because the .onLoad() hook is executed
>  right before the package namespace gets locked.
>
> ## Just a place holder. Will be initialized at load-time.
> .some_internal_global_variable <- NULL
>
> .onLoad <- function(libname, pkgname)
> {
>   .some_internal_global_variable <<- 55L
> }
>
> However, I don't really like using this approach when initialization
> of the global variable requires access to the internet. It means that
> in case of connectivity issue your users won't be able to load the
> package and troubleshooting can become really tricky when you can't
> even load a package. So in that case I prefer the solution below.
>
>

[Bioc-devel] adding maintainers to SpatialExperiment repo

2021-03-23 Thread Dario Righelli


Hi Guys,

we'd like to add Helena Crowell and Lukas Weber (CC) as maintainers of 
the SpatialExperiment repo so that they can push on the upstream.


Thanks,
Dario

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

Re: [Rd] [Solved] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Duncan Murdoch

With that change to the .desktop file, both the existing rgl and the rgl 
with a group_leader set behave the same:  all x11() and rgl windows are 
collected together into the same R icon.


If I don't make that change, then setting the group_leader causes all 
rgl windows from one process to group together (with a bad icon).


I think I'll leave the group_leader in place.  I'll think about setting 
an icon, but I don't see it as urgent.


Duncan Murdoch

On 23/03/2021 1:36 p.m., Dirk Eddelbuettel wrote:


It all works now, thanks mostly to some very detailed reading of the specs by
Ivan.  In short, I made the following changes:

   - add the missing WM hint to the .desktop file we install
   - add the svg logo as 'scalable'
   - create a new (square) 48x48 default png logo from the new one
   - deactivate yesterday's patch

and it is all good now.  Duncan's rgl windows aggregate under the item, as do
the standard R x11 devices.  I will try to attach a small screenshot, we'll
see how mailman likes it.  Martin should still be able to get the old (and to
me, buggy) behaviour back by removing the one key line from the .desktop
file, if his Fedora environment ever updates as I plan.

For anyone on Ubuntu 20.10, updated binaries are in my PPA, see
https://launchpad.net/~edd/+archive/ubuntu/misc/+packages?field.name_filter=r-base_filter=published_filter=groovy

Changelog entries below, these have not been committed to Debian's git yet
but I think I will activate this for R 4.0.5 next week (and test it til
then). Screenshot attached below too.

-- changelog for these three test builds follows  ---

r-base (4.0.4-1.2010.3) groovy; urgency=medium

   * debian/r-base-core.dirs: Also create the directory
 usr/share/icons/hicolor/scalable/apps for the svg logo

  -- Dirk Eddelbuettel   Tue, 23 Mar 2021 11:05:17 -0500

r-base (4.0.4-1.2010.2) groovy; urgency=medium

   * icon-class-patch/R.desktop: Add 'StartupWMClass=R_x11'
   * icon-class-patch/rlogo_icon.OLD.png.mpack: Renamed old icon
   * icon-class-patch/rlogo_icon.png.mpack: New 48x48 png from svg
   * icon-class-patch/Rlogo.svg: Copy of official logo
   * debian/rules: Also install Rlogo.svg in 'scalable' icons dir

   * debian/patches/series: Deactivate unneeded grouping patch

  -- Dirk Eddelbuettel   Tue, 23 Mar 2021 10:27:43 -0500

r-base (4.0.4-1.2010.1) groovy; urgency=medium

   * PPA build on Ubuntu 20.10 "groovy"
   * src/modules/X11/devX11.c: Apply patch by Ivan Krylov (posted to r-devel
 on 2021-03-22) enabling grouping of x11 plot device windows

  -- Dirk Eddelbuettel   Mon, 22 Mar 2021 21:33:09 -0500

-


Dirk






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

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Hervé Pagès

Doesn't really matter where you put them but 
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't 
need to be defined inside the .onLoad() hook, and it's actually 
cleaner/easier to not define them there. You can define there anywhere 
in your ewceData/R/* files.


Here is a slightly improved version of the code:

  .my_internal_global_variables <- new.env(parent=emptyenv())

  .get_eh <- function() get("eh", envir=.my_internal_global_variables)
  .set_eh <- function(value) assign("eh", value, 
envir=.my_internal_global_variables)


  get_ExperimentHub <- function()
  {
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
  eh <- ExperimentHub::ExperimentHub()
  .set_eh(eh)
}
eh
  }

In my packages I like to put this kind of low-level stuff in R/utils.R. 
None of this is exported.


Then anywhere in your package when you need an ExperimentHub instance, do:

  ## Exported.
  tt_alzh <- function()
  {
eh <- get_ExperimentHub()
eh[["EH5373"]]
  }

H.


On 3/23/21 10:53 AM, Murphy, Alan E wrote:

HeyHervé,

Thanks for this it is very helpful and I'm very sorry but I have one 
more question, where to put option 3? I thought making an onload r 
script for it:


.onLoad <- function(libname, pkgname) {
   .my_internal_global_variables <- new.env(parent=emptyenv())
   .get_eh <- function() get("eh", envir=.my_internal_global_variables)
   .set_eh <- function(value) assign("eh", value,
                                     envir=.my_internal_global_variables)
   toto <- function()
   {
     eh <- try(.get_eh(), silent=TRUE)
     if (inherits(eh, "try-error")) {
       eh <- ExperimentHub()
       .set_eh(eh)
     }
     eh
   }
   toto()
}

This seems to work in that the script runs (I can tell based on the 
output with devtools::check()) but I still get an error that eh doesn't 
exist in my test functions.


Kind regards,
Alan.

*From:* Hervé Pagès 
*Sent:* 23 March 2021 17:31
*To:* Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 

*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
3 ways to do this, one that doesn't work, and two that work ;-)


1. Simple way that doesn't work:

    ## Just a place holder. Will be initialized at run-time the first
    ## time it's needed.
    .some_internal_global_variable <- NULL

    toto <- function()
    {
  if (is.null(.some_global_variable))
  .some_internal_global_variable <<- 55L
    }

    However, if you put this in your package, you'll get the following
    error the first time toto() is called:

  cannot change value of locked binding for
'.some_internal_global_variable'

2. Simple way that works: initialize the global variable in the
     .onLoad() hook. This works because the .onLoad() hook is executed
     right before the package namespace gets locked.

    ## Just a place holder. Will be initialized at load-time.
    .some_internal_global_variable <- NULL

    .onLoad <- function(libname, pkgname)
    {
  .some_internal_global_variable <<- 55L
    }

    However, I don't really like using this approach when initialization
    of the global variable requires access to the internet. It means that
    in case of connectivity issue your users won't be able to load the
    package and troubleshooting can become really tricky when you can't
    even load a package. So in that case I prefer the solution below.

3. Define the internal global variable in an environment:

    .my_internal_global_variables <- new.env(parent=emptyenv())

    .get_eh <- function() get("eh", envir=.my_internal_global_variables)
    .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

    toto <- function()
    {
  eh <- try(.get_eh(), silent=TRUE)
  if (inherits(eh, "try-error")) {
    eh <- ExperimentHub()
    .set_eh(eh)
  }
  eh
    }

Hope this helps,

H.




On 3/23/21 10:05 AM, Murphy, Alan E wrote:

Hey Hervé,

I get the idea now thanks for clarifying. Where do I place the call to 
ExperimentHub in the package?:


eh <- ExperimentHub()  # the only call to ExperimentHub() in
    # the entire R session

The package contains calls to the datasets in internal functions, 
examples, tests and the vignette so eh it would need to be available to 
all. Sorry I don't have much experience using experiment datasets.


Kind regards,
Alan.


*From:* Hervé Pagès 
*Sent:* 23 March 2021 16:46
*To:* Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 

*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check

***
This email originates from outside Imperial. Do not click on links and 
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Murphy, Alan E

Hey Herv�,

Thanks for this it is very helpful and I'm very sorry but I have one more 
question, where to put option 3? I thought making an onload r script for it:

.onLoad <- function(libname, pkgname) {
  .my_internal_global_variables <- new.env(parent=emptyenv())

  .get_eh <- function() get("eh", envir=.my_internal_global_variables)
  .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

  toto <- function()
  {
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
  eh <- ExperimentHub()
  .set_eh(eh)
}
eh
  }

  toto()
}

This seems to work in that the script runs (I can tell based on the output with 
devtools::check()) but I still get an error that eh doesn't exist in my test 
functions.

Kind regards,
Alan.

From: Herv� Pag�s 
Sent: 23 March 2021 17:31
To: Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

3 ways to do this, one that doesn't work, and two that work ;-)


1. Simple way that doesn't work:

   ## Just a place holder. Will be initialized at run-time the first
   ## time it's needed.
   .some_internal_global_variable <- NULL

   toto <- function()
   {
 if (is.null(.some_global_variable))
 .some_internal_global_variable <<- 55L
   }

   However, if you put this in your package, you'll get the following
   error the first time toto() is called:

 cannot change value of locked binding for
'.some_internal_global_variable'

2. Simple way that works: initialize the global variable in the
.onLoad() hook. This works because the .onLoad() hook is executed
right before the package namespace gets locked.

   ## Just a place holder. Will be initialized at load-time.
   .some_internal_global_variable <- NULL

   .onLoad <- function(libname, pkgname)
   {
 .some_internal_global_variable <<- 55L
   }

   However, I don't really like using this approach when initialization
   of the global variable requires access to the internet. It means that
   in case of connectivity issue your users won't be able to load the
   package and troubleshooting can become really tricky when you can't
   even load a package. So in that case I prefer the solution below.

3. Define the internal global variable in an environment:

   .my_internal_global_variables <- new.env(parent=emptyenv())

   .get_eh <- function() get("eh", envir=.my_internal_global_variables)
   .set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)

   toto <- function()
   {
 eh <- try(.get_eh(), silent=TRUE)
 if (inherits(eh, "try-error")) {
   eh <- ExperimentHub()
   .set_eh(eh)
 }
 eh
   }

Hope this helps,

H.




On 3/23/21 10:05 AM, Murphy, Alan E wrote:
> Hey Herv�,
>
> I get the idea now thanks for clarifying. Where do I place the call to
> ExperimentHub in the package?:
>
> eh <- ExperimentHub()  # the only call to ExperimentHub() in
># the entire R session
>
> The package contains calls to the datasets in internal functions,
> examples, tests and the vignette so eh it would need to be available to
> all. Sorry I don't have much experience using experiment datasets.
>
> Kind regards,
> Alan.
>
> 
> *From:* Herv� Pag�s 
> *Sent:* 23 March 2021 16:46
> *To:* Murphy, Alan E ; Martin Morgan
> ; Kern, Lori ;
> bioc-devel@r-project.org 
> *Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
>
> ***
> This email originates from outside Imperial. Do not click on links and
> attachments unless you recognise the sender.
> If you trust the sender, add them to your safe senders list
> https://spam.ic.ac.uk/SpamConsole/Senders.aspx
>  to disable email
> stamping for this address.
> ***
> On 3/23/21 4:11 AM, Murphy, Alan E wrote:
>> Hi,
>>
>> Thank you very much Martin and Herv� for your suggestions. I have reverted 
>> my zzz.R on load function to that advised by ExperimentHub and had used the 
>> ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions 
>> and unit tests. However, the check  is still taking ~18 minutes so I need to 
>> do a bit more work. Even with
> my new on load function, calling datasets by name still takes
> substantially longer, see below for the example Herv� gave on my new code:
>>
>> a<-function(){
>>eh <- query(ExperimentHub(), "ewceData")
>
> The above line is not needed. Creating an ExperimentHub instance can be
> quite expensive and with the current approach 'R CMD check' will do it
> dozens of times. My suggestion was to create an ExperimentHub instance
> once for all the first time you need it, and reuse it in all your data
> access functions:
>
> eh <- ExperimentHub()  # the only call to ExperimentHub() in
>

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Hervé Pagès


3 ways to do this, one that doesn't work, and two that work ;-)


1. Simple way that doesn't work:

  ## Just a place holder. Will be initialized at run-time the first
  ## time it's needed.
  .some_internal_global_variable <- NULL

  toto <- function()
  {
if (is.null(.some_global_variable))
.some_internal_global_variable <<- 55L
  }

  However, if you put this in your package, you'll get the following
  error the first time toto() is called:

cannot change value of locked binding for 
'.some_internal_global_variable'


2. Simple way that works: initialize the global variable in the
   .onLoad() hook. This works because the .onLoad() hook is executed
   right before the package namespace gets locked.

  ## Just a place holder. Will be initialized at load-time.
  .some_internal_global_variable <- NULL

  .onLoad <- function(libname, pkgname)
  {
.some_internal_global_variable <<- 55L
  }

  However, I don't really like using this approach when initialization
  of the global variable requires access to the internet. It means that
  in case of connectivity issue your users won't be able to load the
  package and troubleshooting can become really tricky when you can't
  even load a package. So in that case I prefer the solution below.

3. Define the internal global variable in an environment:

  .my_internal_global_variables <- new.env(parent=emptyenv())

  .get_eh <- function() get("eh", envir=.my_internal_global_variables)
  .set_eh <- function(value) assign("eh", value, 
envir=.my_internal_global_variables)


  toto <- function()
  {
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
  eh <- ExperimentHub()
  .set_eh(eh)
}
eh
  }

Hope this helps,

H.




On 3/23/21 10:05 AM, Murphy, Alan E wrote:

Hey Hervé,

I get the idea now thanks for clarifying. Where do I place the call to 
ExperimentHub in the package?:


eh <- ExperimentHub()  # the only call to ExperimentHub() in
   # the entire R session

The package contains calls to the datasets in internal functions, 
examples, tests and the vignette so eh it would need to be available to 
all. Sorry I don't have much experience using experiment datasets.


Kind regards,
Alan.


*From:* Hervé Pagès 
*Sent:* 23 March 2021 16:46
*To:* Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 

*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check

***
This email originates from outside Imperial. Do not click on links and 
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list 
https://spam.ic.ac.uk/SpamConsole/Senders.aspx 
 to disable email 
stamping for this address.

***
On 3/23/21 4:11 AM, Murphy, Alan E wrote:

Hi,

Thank you very much Martin and Hervé for your suggestions. I have reverted my zzz.R on load function to that advised by ExperimentHub and had used the ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions and unit tests. However, the check  is still taking ~18 minutes so I need to do a bit more work. Even with 
my new on load function, calling datasets by name still takes 
substantially longer, see below for the example Hervé gave on my new code:


a<-function(){
    eh <- query(ExperimentHub(), "ewceData")


The above line is not needed. Creating an ExperimentHub instance can be
quite expensive and with the current approach 'R CMD check' will do it
dozens of times. My suggestion was to create an ExperimentHub instance
once for all the first time you need it, and reuse it in all your data
access functions:

    eh <- ExperimentHub()  # the only call to ExperimentHub() in
   # the entire R session

Also there's no need to query(). Just use the EHb ID directly on the
ExperimentHub instance to load your data:

    eh[["EH5373"]]

This should reduce 'R CMD check' by a few more minutes.

H.

--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com


--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

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

Re: [Rd] [Solved] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel


It all works now, thanks mostly to some very detailed reading of the specs by
Ivan.  In short, I made the following changes:

  - add the missing WM hint to the .desktop file we install
  - add the svg logo as 'scalable'
  - create a new (square) 48x48 default png logo from the new one
  - deactivate yesterday's patch

and it is all good now.  Duncan's rgl windows aggregate under the item, as do
the standard R x11 devices.  I will try to attach a small screenshot, we'll
see how mailman likes it.  Martin should still be able to get the old (and to
me, buggy) behaviour back by removing the one key line from the .desktop
file, if his Fedora environment ever updates as I plan.

For anyone on Ubuntu 20.10, updated binaries are in my PPA, see
https://launchpad.net/~edd/+archive/ubuntu/misc/+packages?field.name_filter=r-base_filter=published_filter=groovy

Changelog entries below, these have not been committed to Debian's git yet
but I think I will activate this for R 4.0.5 next week (and test it til
then). Screenshot attached below too.

-- changelog for these three test builds follows  ---

r-base (4.0.4-1.2010.3) groovy; urgency=medium

  * debian/r-base-core.dirs: Also create the directory
usr/share/icons/hicolor/scalable/apps for the svg logo

 -- Dirk Eddelbuettel   Tue, 23 Mar 2021 11:05:17 -0500

r-base (4.0.4-1.2010.2) groovy; urgency=medium

  * icon-class-patch/R.desktop: Add 'StartupWMClass=R_x11'
  * icon-class-patch/rlogo_icon.OLD.png.mpack: Renamed old icon
  * icon-class-patch/rlogo_icon.png.mpack: New 48x48 png from svg
  * icon-class-patch/Rlogo.svg: Copy of official logo
  * debian/rules: Also install Rlogo.svg in 'scalable' icons dir

  * debian/patches/series: Deactivate unneeded grouping patch 

 -- Dirk Eddelbuettel   Tue, 23 Mar 2021 10:27:43 -0500

r-base (4.0.4-1.2010.1) groovy; urgency=medium

  * PPA build on Ubuntu 20.10 "groovy"
  * src/modules/X11/devX11.c: Apply patch by Ivan Krylov (posted to r-devel
on 2021-03-22) enabling grouping of x11 plot device windows

 -- Dirk Eddelbuettel   Mon, 22 Mar 2021 21:33:09 -0500

-


Dirk



-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Murphy, Alan E

Hey Herv�,

I get the idea now thanks for clarifying. Where do I place the call to 
ExperimentHub in the package?:

eh <- ExperimentHub()  # the only call to ExperimentHub() in
  # the entire R session

The package contains calls to the datasets in internal functions, examples, 
tests and the vignette so eh it would need to be available to all. Sorry I 
don't have much experience using experiment datasets.

Kind regards,
Alan.

From: Herv� Pag�s 
Sent: 23 March 2021 16:46
To: Murphy, Alan E ; Martin Morgan 
; Kern, Lori ; 
bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

***
This email originates from outside Imperial. Do not click on links and 
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list 
https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for 
this address.
***
On 3/23/21 4:11 AM, Murphy, Alan E wrote:
> Hi,
>
> Thank you very much Martin and Herv� for your suggestions. I have reverted my 
> zzz.R on load function to that advised by ExperimentHub and had used the ID 
> look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions and 
> unit tests. However, the check is still taking ~18 minutes so I need to do a 
> bit more work. Even with my new on load function, calling datasets by name 
> still takes substantially longer, see below for the example Herv� gave on my 
> new code:
>
> a<-function(){
>eh <- query(ExperimentHub(), "ewceData")

The above line is not needed. Creating an ExperimentHub instance can be
quite expensive and with the current approach 'R CMD check' will do it
dozens of times. My suggestion was to create an ExperimentHub instance
once for all the first time you need it, and reuse it in all your data
access functions:

   eh <- ExperimentHub()  # the only call to ExperimentHub() in
  # the entire R session

Also there's no need to query(). Just use the EHb ID directly on the
ExperimentHub instance to load your data:

   eh[["EH5373"]]

This should reduce 'R CMD check' by a few more minutes.

H.

--
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] Methods to speed up R CMD Check

2021-03-23 Thread Hervé Pagès


On 3/23/21 6:33 AM, Mike Smith wrote:
...

Finally I'll point out there's a testthat::skip_on_bioc() function that
will allow you to skip a test on the Bioc builder, but still run that test
locally/on GitHub etc.


What?!

> testthat::skip_on_bioc
function ()
{
if (identical(Sys.getenv("BBS_HOME"), "")) {
return(invisible(TRUE))
}
skip("On Bioconductor")
}



No way! I need to rename that BBS_HOME env variable ;-)


However, I think we'd all agree it'd be better to
get all the tests running universally, rather than take that route.


You bet.

Or move the long tests to the longtests/ folder and subscribe to the 
Long Tests builds:


  https://bioconductor.org/developers/how-to/long-tests/

You'll be only able to do so once your package is accepted though so it 
doesn't really help in the context of the package review.


H.



Mike

On Tue, 23 Mar 2021 at 12:11, Murphy, Alan E 
wrote:


Hi,

Thank you very much Martin and Hervé for your suggestions. I have reverted
my zzz.R on load function to that advised by ExperimentHub and had used the
ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions
and unit tests. However, the check is still taking ~18 minutes so I need to
do a bit more work. Even with my new on load function, calling datasets by
name still takes substantially longer, see below for the example Hervé gave
on my new code:

a<-function(){
   eh <- query(ExperimentHub(), "ewceData")
   tt_alzh <- eh[["EH5373"]]
}
microbenchmark::microbenchmark(a,
tt_alzh <- ewceData::tt_alzh(),
times=20L,unit="s")

Unit: seconds
expr min  lq

  mean  median  uq max neval

a  0.0003 0.00031

0.002995 0.00045 0.00684 0.0106420
t>t_alzh <- ewceData::tt_alzh() 2.71135788 2.755388420 2.9922968274
2.993737666 3.144241330 3.84242267920

My question is would it be acceptable to change my data load calls in my
examples and the vignette to reduce the runtime or is this against best
practice and should I look for improvements elsewhere? I ask because I feel
I'm running out of easy options at reducing the overall runtime.

Kind regards,
Alan.



From: Martin Morgan 
Sent: 22 March 2021 18:17
To: Kern, Lori ; Murphy, Alan E <
a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
bioc-devel@r-project.org>
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

(sticking bioc-devel back in the recipient list so others can learn /
improve / disagree with this suggestion.)

my suggestion was to memorize the function in your package, not in the
example. Examples are not run independently, but collated into a single
file (EWCR-Ex.R in the EWCR.Rcheck directory, after running R CMD check)
and sourced. And the suggestion was not to solve the problem of examples
running slowly, but avoiding repeatedly calculating the same value. For
instance, from Hervé’s email ewceData::tt_alzh could be memorized in the
package. The first call would take several seconds, but subsequent calls
would be instantaneous. But as Hervé says that function should be cleaned
up anyway so that 'tricks' like memorization might not be necessary.


From: "Murphy, Alan E" 
Date: Monday, March 22, 2021 at 12:37 PM
To: Martin Morgan 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

Hey Martin,

Thanks for the suggestion but how would I go about using this, let's say,
for the examples? If I redefine the memoise function in each example (as it
won't otherwise exist) would this not take the same amount of time?

Kind regards,
Alan.

From: Martin Morgan 
Sent: 22 March 2021 13:34
To: Kern, Lori ; Murphy, Alan E <
a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
bioc-devel@r-project.org>
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check


***
This email originates from outside Imperial. Do not click on links and
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list
https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping
for this address.
***
if your examples repeatedly calculate the same thing, and this is also
typical of how users use your package, it might make sense to 'memoise' key
functions in your package https://cran.r-project.org/package=memoise

Martin

On 3/22/21, 7:41 AM, "Bioc-devel on behalf of Kern, Lori" <
bioc-devel-boun...@r-project.org on behalf of
lori.sheph...@roswellpark.org> wrote:

 If your data is using ExperimentHub,  it should already be caching the
downloaded data.  Once it is downloaded once, it should be using the cached
download for subsequent calls to the hub.  We will investigate to ensure
that the caching mechanism is functioning properly on all of our
Bioconductor builders.



 Lori Shepherd

 Bioconductor Core Team

 Roswell

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Duncan Murdoch


On 23/03/2021 11:54 a.m., Ivan Krylov wrote:

On Tue, 23 Mar 2021 11:41:39 -0400
Duncan Murdoch  wrote:


It would probably be nice  to have rgl windows and other R graphics
windows in the same group, but I don't see a way for rgl to know the
group_leader that R is using (and it's probably not worth adding this
to the API to be able to request it).

Am I missing an easier solution?


Do you envision any problems stemming from setting the same WM_CLASS
("r_x11", "R_x11") for rgl windows as used by x11() windows? 


Since early 2013, rgl has set the WM_CLASS to ("rgl", "R_x11").  So I 
think with your suggested change to R.desktop the problem is solved, 
assuming the first component (res_name) doesn't matter as long as the 
second one (res_class) matches.


Duncan Murdoch

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

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Hervé Pagès


On 3/23/21 4:11 AM, Murphy, Alan E wrote:

Hi,

Thank you very much Martin and Hervé for your suggestions. I have reverted my zzz.R on load 
function to that advised by ExperimentHub and had used the ID look up (system.time(tt_alzh 
<- eh[["EH5373"]])) on internal functions and unit tests. However, the check is 
still taking ~18 minutes so I need to do a bit more work. Even with my new on load function, 
calling datasets by name still takes substantially longer, see below for the example Hervé 
gave on my new code:

a<-function(){
   eh <- query(ExperimentHub(), "ewceData")


The above line is not needed. Creating an ExperimentHub instance can be 
quite expensive and with the current approach 'R CMD check' will do it 
dozens of times. My suggestion was to create an ExperimentHub instance 
once for all the first time you need it, and reuse it in all your data 
access functions:


  eh <- ExperimentHub()  # the only call to ExperimentHub() in
 # the entire R session

Also there's no need to query(). Just use the EHb ID directly on the 
ExperimentHub instance to load your data:


  eh[["EH5373"]]

This should reduce 'R CMD check' by a few more minutes.

H.

--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Ivan Krylov

On Tue, 23 Mar 2021 11:41:39 -0400
Duncan Murdoch  wrote:

> It would probably be nice  to have rgl windows and other R graphics
> windows in the same group, but I don't see a way for rgl to know the
> group_leader that R is using (and it's probably not worth adding this
> to the API to be able to request it).
> 
> Am I missing an easier solution?

Do you envision any problems stemming from setting the same WM_CLASS
("r_x11", "R_x11") for rgl windows as used by x11() windows? I think
that most DEs are able to group windows by WM_CLASS in addition to
WM_HINTS.window_group (Xfce does that by default, GNOME turned out to
just need a hint in the .application file).

-- 
Best regards,
Ivan

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Duncan Murdoch


On 23/03/2021 6:18 a.m., Ivan Krylov wrote:

On Mon, 22 Mar 2021 16:57:48 -0500
Dirk Eddelbuettel  wrote:


Do you want to send a proper patch to bugzilla?


Would be glad to, especially if we manage to solve that problem you
uncovered while I was asleep.

On Mon, 22 Mar 2021 22:23:47 -0500
Dirk Eddelbuettel  wrote:


Close, close, close but no cigar yet: For a given R process, x11()
windows group for a that process. But we often run multiple R
processes.  Have you seen anything for grouping under the
"program" (in some sense) but not the concrete process from it?


Do windows from different Emacs processes group together the way you
want them to group? What other applications group together for you
despite running from different processes? Do they have the same window
id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
windows all seem to have the same _NET_WM_PID.


In Ubuntu 18.04, all terminal windows display the same _NET_WM_PID, and 
that PID corresponds to gnome-terminal-server.  So I think it's not 
going to be possible to do what Dirk wants without really major changes 
to the way different R processes create graphics windows.


On the other hand, R doesn't set the _NET_WM_PID value.

I've put a version of your code into rgl, and it does what you'd expect: 
 it groups all rgl windows from the same R process together, but 
different R processes get different groups.  It would probably be nice 
to have rgl windows and other R graphics windows in the same group, but 
I don't see a way for rgl to know the group_leader that R is using (and 
it's probably not worth adding this to the API to be able to request it).


Am I missing an easier solution?

Duncan Murdoch



I decided to copy the way GVim sets its group leader ID (because I know
the windows are different processes _and_ that they group in Xfce) and
spent a while chasing this red herring before realising that (1) on my
PC, different x11() windows are still grouped together, even from
different R processes, even without the patch (I never used the "group
windows" option in xfce4-panel before) and (2) different GVim windows
actually have different group leader XIDs in their WM_HINTS properties.
Oops.

Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
addition to WM_HINTS (as far as understand the code).

Here is what GNOME Shell does [**] besides looking at
WM_HINTS.window_group:

  - looks up the window's WM_CLASS in .desktop files known to it
  - looks up the window's _NET_WM_PID among running applications (?)
  - looks for an XDG startup notification matching the window
  - checks other things not likely applicable to R, such as sandbox IDs
and GApplication IDs

Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
part of the .deb package, I believe) should help GNOME Shell match all
x11() windows to a single application without any changes to devX11.c,
but I don't have GNOME installed to check it.

Alternatively, we can also add a _NET_WM_PID property to x11() windows
(in the hope that GNOME Shell matches the PIDs to the same binary), but
then we'd have to add the WM_CLIENT_MACHINE property too [***], which
is way more hacky than I would prefer it to be:

---8<---
Index: src/modules/X11/devX11.c
===
--- src/modules/X11/devX11.c(revision 80104)
+++ src/modules/X11/devX11.c(working copy)
@@ -52,6 +52,8 @@
  #endif
  #include 
  
+#include  /* for uname -> WM_CLIENT_MACHINE -> _NET_WM_PID */

+#include  /* getpid -> _NET_WM_PID */
  
  #define R_USE_PROTOTYPES 1

  #include 
@@ -105,7 +107,7 @@
  static Display *display;  /* Display */
  static char dspname[101]="";
  static int screen;/* Screen */
-static Window rootwin; /* Root Window */
+static Window rootwin, group_leader;   /* Root Window */
  static Visual *visual;/* Visual */
  static int depth; /* Pixmap depth */
  static int Vclass;/* Visual class */
@@ -1617,6 +1619,39 @@
  PropModeReplace,
  (const unsigned char*) rlogo_icon, 2 + 99*77);
  
+	/* set the window group leader */

+   XWMHints * hints;
+   hints = XAllocWMHints();
+   if (hints) {
+   hints->window_group = group_leader;
+   hints->flags |= WindowGroupHint;
+   XSetWMHints(display, xd->window, hints);
+   XFree(hints);
+   }
+
+   /* Provide WM_CLIENT_MACHINE to set a valid _NET_WM_PID */
+   struct utsname unm;
+   if (uname()) goto no_wm_pid;
+   char * nodename = [0];
+   XTextProperty hostname = {0}; /* initialise the value pointer */
+   if (Success != XmbTextListToTextProperty(

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel



On 23 March 2021 at 09:38, Dirk Eddelbuettel wrote:
| 
| On 23 March 2021 at 17:13, Ivan Krylov wrote:
| | В Tue, 23 Mar 2021 08:58:49 -0500
| | Dirk Eddelbuettel  пишет:
| | 
| | > I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
| | > is from the 2012 patch, and I vaguely recall the .desktop file being
| | > unhappy without it. Re-creating a 48x48 from the svg may do.
| | 
| | I think you could even link /usr/share/R/doc/html/Rlogo.svg
| | into /usr/share/icons/hicolor/scalable/apps/rlogo_icon.svg to let GNOME
| | and others draw an arbitrarily high-resolution icon if the display
| | permits that, but a 48x48 bitmap is still required:
| | 
| | 
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
| 
| Yes, had the same idea earlier and tried it, with the original Rlogo.svg
| copied in there under that name -- but I got an 'empty' icon displayed :-/
| (I had also removed the png "to be sure", your more careful suggests it is
| needed as a fallback.)
| 
| When I follow your suggestion to use both it works with new logo (yay) with
| the only minor drawback ... that the white background shows whereas all other
| logos are using transparent background.

Sorry, that was wrong: a leftover from manually installing a new png based on
the svg. So when I have both, the png wins and the svg is seemingly ignored.
So first task would be to create a new (and square !!) 48x48 png from the svg
or higher-res png.

But on a lark, I just went into setting and toggled the icon size from 48
(default) to 36 ... and _voila_ I get a new (no background !!) one drawn
seemingly from the svg.  So the solution appears to be to remove the png.
Will try that later. 

Dirk

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

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel



On 23 March 2021 at 17:13, Ivan Krylov wrote:
| В Tue, 23 Mar 2021 08:58:49 -0500
| Dirk Eddelbuettel  пишет:
| 
| > I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
| > is from the 2012 patch, and I vaguely recall the .desktop file being
| > unhappy without it. Re-creating a 48x48 from the svg may do.
| 
| I think you could even link /usr/share/R/doc/html/Rlogo.svg
| into /usr/share/icons/hicolor/scalable/apps/rlogo_icon.svg to let GNOME
| and others draw an arbitrarily high-resolution icon if the display
| permits that, but a 48x48 bitmap is still required:
| 
| 
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons

Yes, had the same idea earlier and tried it, with the original Rlogo.svg
copied in there under that name -- but I got an 'empty' icon displayed :-/
(I had also removed the png "to be sure", your more careful suggests it is
needed as a fallback.)

When I follow your suggestion to use both it works with new logo (yay) with
the only minor drawback ... that the white background shows whereas all other
logos are using transparent background.

Dirk

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

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Ivan Krylov

В Tue, 23 Mar 2021 08:58:49 -0500
Dirk Eddelbuettel  пишет:

> I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which
> is from the 2012 patch, and I vaguely recall the .desktop file being
> unhappy without it. Re-creating a 48x48 from the svg may do.

I think you could even link /usr/share/R/doc/html/Rlogo.svg
into /usr/share/icons/hicolor/scalable/apps/rlogo_icon.svg to let GNOME
and others draw an arbitrarily high-resolution icon if the display
permits that, but a 48x48 bitmap is still required:

https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons

-- 
Best regards,
Ivan

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel



On 23 March 2021 at 08:15, Dirk Eddelbuettel wrote:
| Only one small downside: the regrouped icon switches to the old R icon (which
| is probably the one we bitmapped).  Would you know how we could force the new
| one?

Could well be my fault. =:-)

I still ship /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png which is from
the 2012 patch, and I vaguely recall the .desktop file being unhappy without it.
Re-creating a 48x48 from the svg may do.

Dirk

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

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

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Mike Smith

Hi Alan,

I wonder if there are instances in your tests where you can use pseudo data
or mock the behaviour of certain functions.  For me the aim of unit testing
is to confirm the behaviour of functions under controlled conditions, but
it doesn't necessarily have to be done using 'real' data.

For example, in test_fix_bad_mgi_symbols.R you download a 40mb text file
with 300,000 lines - this takes ~20 seconds for me.  Do you really need
such a large file to test the functionality?  Perhaps you could create a
data.frame of only a few rows, where each row encapsulates something you
want to test for.  Then write this to a temporary file and use that to test
the functions.

I'll also note that for me each call to fix.bad.mgi.symbols() calls
ExperimentHub() via ewceData::all_mgi() which adds quite a bit to the
runtime of that test file.  However it sounds like maybe you're already
addressing that.  If not, I think this is something you could mock in your
tests.  You could mock the output of ewceData::all_mgi() to either be
output of eh[["EH5369"]] (so you'd only query the hub once), or mock it
manually to be a small subset of gene names that trigger the behaviour
you're testing for.

I don't think I've done a good job explaining that, so I'll point you to
the mockery package (https://github.com/r-lib/mockery) and some examples
where I've used mocking in the biomaRt package to fake results without
having to query a web server (
https://github.com/grimbough/biomaRt/blob/master/tests/testthat/test_ensembl_ssl_settings.R
)

Finally I'll point out there's a testthat::skip_on_bioc() function that
will allow you to skip a test on the Bioc builder, but still run that test
locally/on GitHub etc.  However, I think we'd all agree it'd be better to
get all the tests running universally, rather than take that route.

Mike

On Tue, 23 Mar 2021 at 12:11, Murphy, Alan E 
wrote:

> Hi,
>
> Thank you very much Martin and Hervé for your suggestions. I have reverted
> my zzz.R on load function to that advised by ExperimentHub and had used the
> ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions
> and unit tests. However, the check is still taking ~18 minutes so I need to
> do a bit more work. Even with my new on load function, calling datasets by
> name still takes substantially longer, see below for the example Hervé gave
> on my new code:
>
> a<-function(){
>   eh <- query(ExperimentHub(), "ewceData")
>   tt_alzh <- eh[["EH5373"]]
> }
> microbenchmark::microbenchmark(a,
>tt_alzh <- ewceData::tt_alzh(),
>times=20L,unit="s")
> >Unit: seconds
> >expr min  lq
>  mean  median  uq max neval
> >a  0.0003 0.00031
> 0.002995 0.00045 0.00684 0.0106420
> t>t_alzh <- ewceData::tt_alzh() 2.71135788 2.755388420 2.9922968274
> 2.993737666 3.144241330 3.84242267920
>
> My question is would it be acceptable to change my data load calls in my
> examples and the vignette to reduce the runtime or is this against best
> practice and should I look for improvements elsewhere? I ask because I feel
> I'm running out of easy options at reducing the overall runtime.
>
> Kind regards,
> Alan.
>
>
> 
> From: Martin Morgan 
> Sent: 22 March 2021 18:17
> To: Kern, Lori ; Murphy, Alan E <
> a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Methods to speed up R CMD Check
>
> (sticking bioc-devel back in the recipient list so others can learn /
> improve / disagree with this suggestion.)
>
> my suggestion was to memorize the function in your package, not in the
> example. Examples are not run independently, but collated into a single
> file (EWCR-Ex.R in the EWCR.Rcheck directory, after running R CMD check)
> and sourced. And the suggestion was not to solve the problem of examples
> running slowly, but avoiding repeatedly calculating the same value. For
> instance, from Hervé’s email ewceData::tt_alzh could be memorized in the
> package. The first call would take several seconds, but subsequent calls
> would be instantaneous. But as Hervé says that function should be cleaned
> up anyway so that 'tricks' like memorization might not be necessary.
>
>
> From: "Murphy, Alan E" 
> Date: Monday, March 22, 2021 at 12:37 PM
> To: Martin Morgan 
> Subject: Re: [Bioc-devel] Methods to speed up R CMD Check
>
> Hey Martin,
>
> Thanks for the suggestion but how would I go about using this, let's say,
> for the examples? If I redefine the memoise function in each example (as it
> won't otherwise exist) would this not take the same amount of time?
>
> Kind regards,
> Alan.
>
> From: Martin Morgan 
> Sent: 22 March 2021 13:34
> To: Kern, Lori ; Murphy, Alan E <
> a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re:

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel



On 23 March 2021 at 07:44, Dirk Eddelbuettel wrote:
| On 23 March 2021 at 13:18, Ivan Krylov wrote:
| | Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
| | addition to WM_HINTS (as far as understand the code).
| | 
| | Here is what GNOME Shell does [**] besides looking at
| | WM_HINTS.window_group:
| | 
| |  - looks up the window's WM_CLASS in .desktop files known to it
| |  - looks up the window's _NET_WM_PID among running applications (?)
| |  - looks for an XDG startup notification matching the window
| |  - checks other things not likely applicable to R, such as sandbox IDs
| |and GApplication IDs
| | 
| | Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
| | part of the .deb package, I believe) should help GNOME Shell match all
| | x11() windows to a single application without any changes to devX11.c,
| | but I don't have GNOME installed to check it.
| 
| Easy enough for me to check, but I won't get to it for a bit.

Ok, I tried. And amazingly that worked (with a small "but")!

Added the line to the (installed) /usr/share/applications/R.desktop,
asked Gnome Shell to restart (Alt-F2, then r [where r standards for restart,
not littler ;-) ]) and the (existing) two windows (from two distinct 'live'
and long-running plot/monitor sessions) are now regrouped in the 'dock',
which would for the first time be correct behaviour under Gnome (as I
understand it).

Only one small downside: the regrouped icon switches to the old R icon (which
is probably the one we bitmapped).  Would you know how we could force the new
one?

Dirk

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

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Dirk Eddelbuettel



On 23 March 2021 at 13:18, Ivan Krylov wrote:
| On Mon, 22 Mar 2021 16:57:48 -0500
| Dirk Eddelbuettel  wrote:
| 
| > Do you want to send a proper patch to bugzilla?
| 
| Would be glad to, especially if we manage to solve that problem you
| uncovered while I was asleep.
| 
| On Mon, 22 Mar 2021 22:23:47 -0500
| Dirk Eddelbuettel  wrote:
| 
| > Close, close, close but no cigar yet: For a given R process, x11()
| > windows group for a that process. But we often run multiple R
| > processes.  Have you seen anything for grouping under the
| > "program" (in some sense) but not the concrete process from it?
| 
| Do windows from different Emacs processes group together the way you
| want them to group? What other applications group together for you
| despite running from different processes? Do they have the same window
| id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
| windows all seem to have the same _NET_WM_PID.

"All of them, but R".

Right now (under unity) I have four for Gnome Terminal (clearly distinct
processes), two for Chrome (plus more temporarily), and two for emacs (two
windows from same process, I checked that launching a new one clearly
aggregates within).

But R is different, and I see this as a bug.  How "grave" it is is open for
debate, but the application behaves differently under the window manager.

The overall behaviour is consistent, yet R sticks out. I think it shouldn't.

| I decided to copy the way GVim sets its group leader ID (because I know
| the windows are different processes _and_ that they group in Xfce) and
| spent a while chasing this red herring before realising that (1) on my
| PC, different x11() windows are still grouped together, even from
| different R processes, even without the patch (I never used the "group
| windows" option in xfce4-panel before) and (2) different GVim windows
| actually have different group leader XIDs in their WM_HINTS properties.
| Oops.

Hah!
 
| Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
| addition to WM_HINTS (as far as understand the code).
| 
| Here is what GNOME Shell does [**] besides looking at
| WM_HINTS.window_group:
| 
|  - looks up the window's WM_CLASS in .desktop files known to it
|  - looks up the window's _NET_WM_PID among running applications (?)
|  - looks for an XDG startup notification matching the window
|  - checks other things not likely applicable to R, such as sandbox IDs
|and GApplication IDs
| 
| Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
| part of the .deb package, I believe) should help GNOME Shell match all
| x11() windows to a single application without any changes to devX11.c,
| but I don't have GNOME installed to check it.

Easy enough for me to check, but I won't get to it for a bit.

| Alternatively, we can also add a _NET_WM_PID property to x11() windows
| (in the hope that GNOME Shell matches the PIDs to the same binary), but
| then we'd have to add the WM_CLIENT_MACHINE property too [***], which
| is way more hacky than I would prefer it to be:

[proposed change set omitted]

Ok. You did amazing. I had poked around a little in one or two apps but not
made any progress.

Dirk

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

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

Re: [Bioc-devel] Recently accepted package not appearing in nightly builds

2021-03-23 Thread James Perkins

OK that makes sense - apologies, it stated in the issue that "Your package
will be included in the next nigthly 'devel' build" and I misinterpreted.

Thanks for clarifying!

Cheers

On Tue, 23 Mar 2021 at 11:40, Kern, Lori 
wrote:

> Your package was identified as a workflow package based you the biocViews
> you selected.  The workflow packages did not build last Friday and next run
> is today.  You should check the following page for your workflow package
> build results:
>
> http://bioconductor.org/checkResults/3.13/workflows-LATEST/
>
> Cheers,
>
> 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 James
> Perkins 
> *Sent:* Tuesday, March 23, 2021 4:56 AM
> *To:* bioc-devel@r-project.org 
> *Subject:* [Bioc-devel] Recently accepted package not appearing in
> nightly builds
>
> Dear all,
>
> I am the maintainer of the package ExpHunterSuite. This was accepted
> thursday, and on Friday (19/03) the issue raised on the
> Bioconductor/contributions github page was closed (ExpHunterSuite #1835,
>
> https://secure-web.cisco.com/1a7OEZThEU5CLG0ISAyz_rsGl1YpZjHKnXob4DK82SC1JJXcRPx9JMXNkXz1BoRbKGnTU16yAlQ5pxjB_ANH8w_aa7enwKmKs4CrPWV2DIRnf64J8C_Lhv0ugJynT40zYGYvnMURwRkKdVkl6VQUN2TV6FOEZMltNMg5KNAYlJYA-Qo5V1d8V364L_NtC7Hs3h53CQMaahEFYbnPZih0SCXCwr7dpQ1B5RgYukVSwcBhhVqp7co3pHFwSf6V0eSwpKYom_kndyBFBm0cyHnhj8_EWY2fkeezxmDUDkxKui2AspIQiJD_QH9Cmzdt23zLx7kPS8OV2mQJmaLyhQWO1rA/https%3A%2F%2Fgithub.com%2FBioconductor%2FContributions%2Fissues%2F1835
> ).
>
> The last message on the issue thread told me that the package will be
> included in the next nightly build, to keep an eye on the results and that,
> assuming it builds OK, a landing page will be produced. There was also
> information in the message related to git ssh credentials, but I believe
> that is already solved (I have submitted public key and can clone/push/pull
> the git.bioconductor.org repo without problems).
>
> I've checked the nightly build since then, and it would appear that the
> package has not been included. The latest one uses a git snapshot from
> 21/03 so I assume it should be included?
>
> I know that there have been problems with the devel build as per Hervé
> Pagès's email, I don't know if this is affecting things, or if there is
> something else I have to do, like a bump in version number to trigger
> inclusion or something like that?
>
> Thanks in advance for any help.
>
> Jim
> --
> James R Perkins PhD
> Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER)
> Department of Molecular Biology and Biochemistry
> <
> https://secure-web.cisco.com/1qJv3gjRb73fkHwItMi7qDYMMMWR_A-afmoGmIQqs68gSEM2Yj_7v-FmFl47C8LVnUGRZQk53-KIAamfJbg2MscBbFYmpJLobhN6mPNbBcaCWqvjFnObTga8eBYSGP45GeL1q0GTGkwf2BFbrDJh3w5IoFOS8dtH8icBLzc-u5pMiDV24xOmw3F0vzDpiJwE_3kQ9PeEkxfaCPqcaNR83tVHYdzT90Fi3gczR4cvs-TMLujB-g8QecNVAm2AM0EAT8wd0_Q3uRX3Ts-8YMjjOiLMnbQn9OdpTFKY_8vmJsRg3kOYpbYtQz6DYW0wco7uhuFVqjuZBxzyCggvaCoLEfA/https%3A%2F%2Fgoo.gl%2Fmaps%2FUCLQXZLR2W12
> >
> Science Faculty, University of Malaga
> 29071 Malaga, Spain
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1dc2D7WOus42RJlMrLA7GlQlM3v_6afJhgjtkh6263AllUjpStzr45nG1p1_Td2fOFZeVPkleseG4SjPdgwmKte5c9DrORtbI3iiqKEIl-9Q7pE38CV7X0QuLis08UadmZqbmAKtExo6q0NMc7cJZrjJJjdWV3LOVktb-8I2bZB7n6UgV0tXRTm2k-5hWSDXf_Y0BGyj9kGt1zwr45Q7rlne5Q2xpOT6JNE54EsvskB7wzEMoy7f7AWn43pU0dAu-5Dw6BkpKabr0cBXjqHKQsQ-oAgYUeXaM5a8i_COHzJsRiyFmmjmcMP19Ahmu4kipJ_rYeClMJopHUVOgrA3TtA/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.



-- 
James R Perkins PhD
Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER)
Department of Molecular Biology and Biochemistry

Science Faculty, University of Malaga
29071 Malaga, Spain

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Methods to speed up R CMD Check

2021-03-23 Thread Murphy, Alan E

Hi,

Thank you very much Martin and Hervé for your suggestions. I have reverted my 
zzz.R on load function to that advised by ExperimentHub and had used the ID 
look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions and unit 
tests. However, the check is still taking ~18 minutes so I need to do a bit 
more work. Even with my new on load function, calling datasets by name still 
takes substantially longer, see below for the example Hervé gave on my new code:

a<-function(){
  eh <- query(ExperimentHub(), "ewceData")
  tt_alzh <- eh[["EH5373"]]
}
microbenchmark::microbenchmark(a,
   tt_alzh <- ewceData::tt_alzh(),
   times=20L,unit="s")
>Unit: seconds
>expr min  lq mean  
>median  uq max neval
>a  0.0003 0.00031 
>0.002995 0.00045 0.00684 0.0106420
t>t_alzh <- ewceData::tt_alzh() 2.71135788 2.755388420 2.9922968274 2.993737666 
3.144241330 3.84242267920

My question is would it be acceptable to change my data load calls in my 
examples and the vignette to reduce the runtime or is this against best 
practice and should I look for improvements elsewhere? I ask because I feel I'm 
running out of easy options at reducing the overall runtime.

Kind regards,
Alan.

From: Martin Morgan 
Sent: 22 March 2021 18:17
To: Kern, Lori ; Murphy, Alan E 
; bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

(sticking bioc-devel back in the recipient list so others can learn / improve / 
disagree with this suggestion.)

my suggestion was to memorize the function in your package, not in the example. 
Examples are not run independently, but collated into a single file (EWCR-Ex.R 
in the EWCR.Rcheck directory, after running R CMD check) and sourced. And the 
suggestion was not to solve the problem of examples running slowly, but 
avoiding repeatedly calculating the same value. For instance, from Hervé’s 
email ewceData::tt_alzh could be memorized in the package. The first call would 
take several seconds, but subsequent calls would be instantaneous. But as Hervé 
says that function should be cleaned up anyway so that 'tricks' like 
memorization might not be necessary.

From: "Murphy, Alan E" 
Date: Monday, March 22, 2021 at 12:37 PM
To: Martin Morgan 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

Hey Martin,

Thanks for the suggestion but how would I go about using this, let's say, for 
the examples? If I redefine the memoise function in each example (as it won't 
otherwise exist) would this not take the same amount of time?

Kind regards,
Alan.

From: Martin Morgan 
Sent: 22 March 2021 13:34
To: Kern, Lori ; Murphy, Alan E 
; bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Methods to speed up R CMD Check

***
This email originates from outside Imperial. Do not click on links and 
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list 
https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for 
this address.
***
if your examples repeatedly calculate the same thing, and this is also typical 
of how users use your package, it might make sense to 'memoise' key functions 
in your package https://cran.r-project.org/package=memoise

Martin

On 3/22/21, 7:41 AM, "Bioc-devel on behalf of Kern, Lori" 

wrote:

If your data is using ExperimentHub,  it should already be caching the 
downloaded data.  Once it is downloaded once, it should be using the cached 
download for subsequent calls to the hub.  We will investigate to ensure that 
the caching mechanism is functioning properly on all of our Bioconductor 
builders.

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 Murphy, 
Alan E 
Sent: Monday, March 22, 2021 5:38 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Methods to speed up R CMD Check

Hi all,

I am working on the development of 
[EWCE](https://secure-web.cisco.com/1uG0LGgCjdg85VowwaeRHk2fMjXFkOtQWsgL8p2MQD2j2PZFh_tqvJWaCHJfArA8O4B2WLG1JOwn31NISgSrPW3syUdiPlWNi7cHAMCWKZUQ8d9RrlR-d81LDXXx0xtfCI5ZjjTyFS2xxM2tDea27Y51bWk4Y7jpSnC8Bx768AHBeaJAg3YAK_HTxR6hMzFW99X6Pg8bETgPYi92ccneqdgAJcDBIdfwZnd9OMaM4JS0kY9kYT3F58ho2jM_k0n6EqMzhuXl3HEM7uneL7twMxTTxSZ-vFC1U1eFSkAr0sp38AyD3g6gTbf-vUbghaGV-JBKoybZto3ZDmHhs8OE6cQ/https%3A%2F%2Fgithub.com%2FNathanSkene%2FEWCE)
 but have hit an issue with R CMD check's runtime. I have been informed this 
test needs to be completed in 15 minutes but mine is currently running in ~24 
minutes and I am looking for methods to speed this up. The main culprits

Re: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Ivan Krylov

On Mon, 22 Mar 2021 16:57:48 -0500
Dirk Eddelbuettel  wrote:

> Do you want to send a proper patch to bugzilla?

Would be glad to, especially if we manage to solve that problem you
uncovered while I was asleep.

On Mon, 22 Mar 2021 22:23:47 -0500
Dirk Eddelbuettel  wrote:

> Close, close, close but no cigar yet: For a given R process, x11()
> windows group for a that process. But we often run multiple R
> processes.  Have you seen anything for grouping under the
> "program" (in some sense) but not the concrete process from it?

Do windows from different Emacs processes group together the way you
want them to group? What other applications group together for you
despite running from different processes? Do they have the same window
id # of group leader in `xprop WM_HINTS`? I checked Firefox, but its
windows all seem to have the same _NET_WM_PID.

I decided to copy the way GVim sets its group leader ID (because I know
the windows are different processes _and_ that they group in Xfce) and
spent a while chasing this red herring before realising that (1) on my
PC, different x11() windows are still grouped together, even from
different R processes, even without the patch (I never used the "group
windows" option in xfce4-panel before) and (2) different GVim windows
actually have different group leader XIDs in their WM_HINTS properties.
Oops.

Apparently Xfce uses libwnck [*] which groups windows by WM_CLASS in
addition to WM_HINTS (as far as understand the code).

Here is what GNOME Shell does [**] besides looking at
WM_HINTS.window_group:

 - looks up the window's WM_CLASS in .desktop files known to it
 - looks up the window's _NET_WM_PID among running applications (?)
 - looks for an XDG startup notification matching the window
 - checks other things not likely applicable to R, such as sandbox IDs
   and GApplication IDs

Adding StartupWMClass=R_x11 to R.desktop (not part of R sources, but
part of the .deb package, I believe) should help GNOME Shell match all
x11() windows to a single application without any changes to devX11.c,
but I don't have GNOME installed to check it.

Alternatively, we can also add a _NET_WM_PID property to x11() windows
(in the hope that GNOME Shell matches the PIDs to the same binary), but
then we'd have to add the WM_CLIENT_MACHINE property too [***], which
is way more hacky than I would prefer it to be:

---8<---
Index: src/modules/X11/devX11.c
===
--- src/modules/X11/devX11.c(revision 80104)
+++ src/modules/X11/devX11.c(working copy)
@@ -52,6 +52,8 @@
 #endif
 #include 

+#include  /* for uname -> WM_CLIENT_MACHINE -> _NET_WM_PID */
+#include  /* getpid -> _NET_WM_PID */

 #define R_USE_PROTOTYPES 1
 #include 
@@ -105,7 +107,7 @@
 static Display *display;   /* Display */
 static char dspname[101]="";
 static int screen; /* Screen */
-static Window rootwin; /* Root Window */
+static Window rootwin, group_leader;   /* Root Window */
 static Visual *visual; /* Visual */
 static int depth;  /* Pixmap depth */
 static int Vclass; /* Visual class */
@@ -1617,6 +1619,39 @@
 PropModeReplace,
 (const unsigned char*) rlogo_icon, 2 + 99*77);

+   /* set the window group leader */
+   XWMHints * hints;
+   hints = XAllocWMHints();
+   if (hints) {
+   hints->window_group = group_leader;
+   hints->flags |= WindowGroupHint;
+   XSetWMHints(display, xd->window, hints);
+   XFree(hints);
+   }
+
+   /* Provide WM_CLIENT_MACHINE to set a valid _NET_WM_PID */
+   struct utsname unm;
+   if (uname()) goto no_wm_pid;
+   char * nodename = [0];
+   XTextProperty hostname = {0}; /* initialise the value pointer */
+   if (Success != XmbTextListToTextProperty(
+   display, , 1, XStringStyle, 
+   )) {
+   if (hostname.value) XFree(hostname.value);
+   goto no_wm_pid;
+   }
+   XSetWMClientMachine(display, xd->window, );
+   XFree(hostname.value);
+
+   /* set _NET_WM_PID */
+   uint32_t mypid = (uint32_t)getpid(); /* must be CARDINAL(32) */
+XChangeProperty(display, xd->window,
+XInternAtom(display, "_NET_WM_PID", False),
+XInternAtom(display, "CARDINAL", False), 32,
+PropModeReplace,
+(const unsigned char*) , 1);
+   no_wm_pid:
+
/* set up protocols so that window manager sends */
/* me an event when user "destroys" window */
_XA_WM_PROTOCOLS = XInternAtom(display,

Re: [Bioc-devel] Recently accepted package not appearing in nightly builds

2021-03-23 Thread Kern, Lori

Your package was identified as a workflow package based you the biocViews you 
selected.  The workflow packages did not build last Friday and next run is 
today.  You should check the following page for your workflow package build 
results:

http://bioconductor.org/checkResults/3.13/workflows-LATEST/

Cheers,


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

Sent: Tuesday, March 23, 2021 4:56 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Recently accepted package not appearing in nightly builds

Dear all,

I am the maintainer of the package ExpHunterSuite. This was accepted
thursday, and on Friday (19/03) the issue raised on the
Bioconductor/contributions github page was closed (ExpHunterSuite #1835,
https://secure-web.cisco.com/1a7OEZThEU5CLG0ISAyz_rsGl1YpZjHKnXob4DK82SC1JJXcRPx9JMXNkXz1BoRbKGnTU16yAlQ5pxjB_ANH8w_aa7enwKmKs4CrPWV2DIRnf64J8C_Lhv0ugJynT40zYGYvnMURwRkKdVkl6VQUN2TV6FOEZMltNMg5KNAYlJYA-Qo5V1d8V364L_NtC7Hs3h53CQMaahEFYbnPZih0SCXCwr7dpQ1B5RgYukVSwcBhhVqp7co3pHFwSf6V0eSwpKYom_kndyBFBm0cyHnhj8_EWY2fkeezxmDUDkxKui2AspIQiJD_QH9Cmzdt23zLx7kPS8OV2mQJmaLyhQWO1rA/https%3A%2F%2Fgithub.com%2FBioconductor%2FContributions%2Fissues%2F1835
 ).

The last message on the issue thread told me that the package will be
included in the next nightly build, to keep an eye on the results and that,
assuming it builds OK, a landing page will be produced. There was also
information in the message related to git ssh credentials, but I believe
that is already solved (I have submitted public key and can clone/push/pull
the git.bioconductor.org repo without problems).

I've checked the nightly build since then, and it would appear that the
package has not been included. The latest one uses a git snapshot from
21/03 so I assume it should be included?

I know that there have been problems with the devel build as per Herv�
Pag�s's email, I don't know if this is affecting things, or if there is
something else I have to do, like a bump in version number to trigger
inclusion or something like that?

Thanks in advance for any help.

Jim
--
James R Perkins PhD
Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER)
Department of Molecular Biology and Biochemistry

Science Faculty, University of Malaga
29071 Malaga, Spain

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1dc2D7WOus42RJlMrLA7GlQlM3v_6afJhgjtkh6263AllUjpStzr45nG1p1_Td2fOFZeVPkleseG4SjPdgwmKte5c9DrORtbI3iiqKEIl-9Q7pE38CV7X0QuLis08UadmZqbmAKtExo6q0NMc7cJZrjJJjdWV3LOVktb-8I2bZB7n6UgV0tXRTm2k-5hWSDXf_Y0BGyj9kGt1zwr45Q7rlne5Q2xpOT6JNE54EsvskB7wzEMoy7f7AWn43pU0dAu-5Dw6BkpKabr0cBXjqHKQsQ-oAgYUeXaM5a8i_COHzJsRiyFmmjmcMP19Ahmu4kipJ_rYeClMJopHUVOgrA3TtA/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: [Rd] Possible x11 window manager window aggregation under one icon?

2021-03-23 Thread Martin Maechler

> Dirk Eddelbuettel 
> on Mon, 22 Mar 2021 22:23:47 -0500 writes:

> On 22 March 2021 at 16:57, Dirk Eddelbuettel wrote:
> | 
> | On 23 March 2021 at 00:01, Ivan Krylov wrote:
> | | The surrounding code and
> | | 

> | | proved to be enough of an example. The following patch makes it
> | | possible to group x11() windows on my PC with Xfce running:
> | 
> | [...]
> | 
> | | Some very limited testing didn't seem to uncover any problems.
> | 
> | Woot woot -- works here too under Ubuntu 20.10 / Gnome / Unity.
> | 
> | I applied the adorably small patch to the usual checkout I keep of 
r-devel
> | (as an incremental build is faster than a full package build of 
r-release).
> | 
> | You are my hero. Next round of hot or cold beverages is on me. Already 
looks
> | so much better. I may put this into the next 4.0.5 (or 4.1.0 at the 
latest)
> | for Debian and Ubuntu (but will instrument a proper new r-base package 
and
> | hit it for a few days first).

> Close, close, close but no cigar yet: For a given R process, x11() windows
> group for a that process. But we often run multiple R processes.  Have you
> seen anything for grouping under the "program" (in some sense) but not the
> concrete process from it?

Hmm.. while I've been very happy with your (DE) original proposal and
the thread (with Ivan's nice small patch), I'm not sure I'd agree here.

Yes, you and I and a few handful more of people on the globe run
more than one *interactive* R process simultaneously.  But even
there, e.g., when I run  R-patched and R-devel, I'd sometimes rather keep
the two processes "separated", including their graphics windows,
because one important side condition of the workflow is to be
careful in comparing the two R versions.

And R is not firefox (where I really typically only want one
firefox running, already being a crazy process generator and
sometimes memory hog). 
The two (or more) different R processes are entirely autonomous
(in > 99.5% of cases), and I would rather have the current
proposal than a possibly quite a bit more complicated one which
I personally often would not even prefer...

With many thanks to Dirk, Naras, Ivan and Duncan for dealing
with the issue so nicely,

Martin

> ( If someone wants to play, Ubuntu binaries for groovy == 20.10 are at
> 
https://launchpad.net/~edd/+archive/ubuntu/misc/?field.series_filter=groovy )

> Dirk

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

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

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

[Bioc-devel] Recently accepted package not appearing in nightly builds

2021-03-23 Thread James Perkins

Dear all,

I am the maintainer of the package ExpHunterSuite. This was accepted
thursday, and on Friday (19/03) the issue raised on the
Bioconductor/contributions github page was closed (ExpHunterSuite #1835,
https://github.com/Bioconductor/Contributions/issues/1835 ).

The last message on the issue thread told me that the package will be
included in the next nightly build, to keep an eye on the results and that,
assuming it builds OK, a landing page will be produced. There was also
information in the message related to git ssh credentials, but I believe
that is already solved (I have submitted public key and can clone/push/pull
the git.bioconductor.org repo without problems).

I've checked the nightly build since then, and it would appear that the
package has not been included. The latest one uses a git snapshot from
21/03 so I assume it should be included?

I know that there have been problems with the devel build as per Hervé
Pagès's email, I don't know if this is affecting things, or if there is
something else I have to do, like a bump in version number to trigger
inclusion or something like that?

Thanks in advance for any help.

Jim
-- 
James R Perkins PhD
Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER)
Department of Molecular Biology and Biochemistry

Science Faculty, University of Malaga
29071 Malaga, Spain

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] EXTERNAL: Resolve mismatch between master and release branches

2021-03-23 Thread Mike Smith

Hi Sarah,

Just to reiterate Marcel's point, if these are new features or tweaks to
your package, then they shouldn't be committed to the release branch at
all.  The Bioconductor ethos is that the release version of a package
should remain stable for a 6 month window (the release cycle), and changes
to that release version should only be made for critical bugs, patches to
fix errors introduced by an update to a CRAN package you depend on, etc.
This is to try and ensure that all Bioconductor packages within a release
present a stable interface; both for users and for packages that
interoperate.  There's an expectation that things in the release branch
will "just work" and will produce consistent results during a release
cycle.  On the other hand, in the devel branch you can make more dramatic
changes, add new features, update options or defaults arguments etc.  It's
still nice to inform users if the result of a function might change between
versions, but it's fine to introduce a change like that.

Assuming your changes are bug fixes, it's also perfectly reasonable to have
a divergence like "7 commits behind master and 3 commits ahead" between the
master and release branches.  The two branches should have
different package version numbers, and that's going to require a different
commit to each branch.  As soon as you've done that you'll see a message
like this, because there's now a commit in master that doesn't appear in
release, and likewise one that's in release that doesn't appear in master.
This doesn't mean anything has gone wrong, the Bioconductor versioning
guidelines have been followed, GitHub just likes to let you know the two
branches have both diverged from their common ancestor.

Best,
Mike

On Mon, 22 Mar 2021 at 23:59, Marcel Ramos <
marcel.ramospe...@roswellpark.org> wrote:

> Hi Sarah,
>
> The release branch is meant for bug fixes that ensure the stability of
> the code.
> It does not usually include 'updates' from the devel.
>
> The way to cleanly do this is to hard reset to a previous commit. The
> commit
> where your packages version was bumped for the 3.12 release. You
> can then force push the release branch to your GitHub repository
> RELEASE_3_12 branch.
> https://bioconductor.org/developers/how-to/git/abandon-changes/
> 
>
> After emailing Nitesh and he would apply a force push to the Bioc git
> repo.
>
> You will then be able to apply your changes from the devel branch by
> cherry-picking those changes** onto the release branch.
>
> ** your changes in the devel branch should be atomic, meaning they do not
> include version bumps, so that cherry-picking is easier, if that is not
> the case
> you may have to apply a diff or manually update the version.
>
>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> <
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> >
>
> Hope that helps.
>
> Best,
>
> Marcel
>
>
>
> On 3/22/21 4:43 PM, Sarah Voisin wrote:
> > Hi,
> >
> > I have updated the master branch of my MEAT package yesterday (
> > https://github.com/sarah-voisin/MEAT), and I tried updating the release
> > branch as well (RELEASE_3_12), but I must have messed up since the
> release
> > branch is now 7 commits behind master and 3 commits ahead, and I am
> stuck.
> > How do I do this again cleanly so I can push all changes from the master
> > branch to the release branch without messing up further?
> >
> > Thank you for your help.
> >
> > Kind regards,
> >
> > *Sarah Voisin*
> > *Senior Lecturer*
> > Institute for Health and Sport (IHES)
> > Victoria University, Footscray Park Campus, VIC 3011 Australia
> > *Email*: sarah.voisin.ae...@gmail.com
> > *Office phone*: +61 3 9919 5744
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ---
> Marcel Ramos
> Bioconductor Core Team
> Roswell Park Comprehensive Cancer Center
> Dept. of Biostatistics & Bioinformatics
> Elm St. & Carlton St.
> Buffalo, New York 14263
>
>
>
> This email message may contain legally privileged and/or...{{dropped:4}}
>
> ___
> 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] ChIPseeker failing on r-devel on CRAN checks

Re: [Bioc-devel] adding maintainers to SpatialExperiment repo

[Bioc-devel] ChIPseeker failing on r-devel on CRAN checks

Re: [Bioc-devel] adding maintainers to SpatialExperiment repo

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Bioc-devel] Methods to speed up R CMD Check

[Bioc-devel] adding maintainers to SpatialExperiment repo

Re: [Rd] [Solved] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Rd] [Solved] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Recently accepted package not appearing in nightly builds

Re: [Bioc-devel] Methods to speed up R CMD Check

Re: [Rd] Possible x11 window manager window aggregation under one icon?

Re: [Bioc-devel] Recently accepted package not appearing in nightly builds

Re: [Rd] Possible x11 window manager window aggregation under one icon?

[Bioc-devel] Recently accepted package not appearing in nightly builds

Re: [Bioc-devel] EXTERNAL: Resolve mismatch between master and release branches

32 matches

Site Navigation

Mail list logo

Footer information