CLEANUP: Drop unused import of BiocParallel::bpiterate

[HenrikBengtsson]

I think you can drop:

GSVA/NAMESPACE

Line 64 in 57e6798

importFrom(BiocParallel,bpiterate)

It's no longer used in the code;

$ grep bpiterate -r --include="*.R"
R/utils.R:#' @importFrom BiocParallel SerialParam bpnworkers bpiterate bpprogressbar
R/GSVA-package.R:#' @importMethodsFrom BiocParallel bpiterate "bpworkers<-" bplapply "bpprogressbar<-"

$ git log -n 1
commit 57e67984a7afa2fb00299c1e014895e994c3c139 (HEAD -> devel, origin/devel, origin/HEAD)
Author: Robert Castelo <robert.castelo@upf.edu>
Date:   Fri Mar 6 10:20:00 2026 +0100

    Bump version

[rcastelo]

Yess, you're right!! I'll drop that import, which is a leftover from a previous approach I used to parallelizing certain calculation. Thanks for bringing it up!

[HenrikBengtsson]

FWIW, I spotted this when I implemented support for:

es <- gsva(param) |> futurize()

https://futurize.futureverse.org/articles/futurize-81-GSVA.html

[rcastelo]

Oh, thank you so much Henrik for implementing this support, I'm pressed at the moment by some deadlines, but I'll look at this as soon as possible, and link your documentation from the GSVA docs. I'll come back to this space once I've done it.

[rcastelo]

I have tried the following with futurize, and the current release and devel versions of GSVA in macOS and Ubuntu, and in all four combinations of that setup I obtained the same error:

library(futurize)
library(GSVA)

set.seed(42)
n_genes <- 200L
n_samples <- 120L
expr <- matrix(rnorm(n_genes * n_samples), nrow = n_genes, ncol = n_samples)
rownames(expr) <- paste0("gene", seq_len(n_genes))
colnames(expr) <- paste0("sample", seq_len(n_samples))

geneSets <- list(
  geneSet1 = paste0("gene", sample(n_genes, 30L)),
  geneSet2 = paste0("gene", sample(n_genes, 50L)),
  geneSet3 = paste0("gene", sample(n_genes, 40L))
)

param <- gsvaParam(expr, geneSets)
plan(multisession)
es <- gsva(param) |> futurize()
Error in transpilers_for_package(type = type, package = ns_name, action = "make",  : 
  There are no factory functions for creating ‘futurize::add-on’ transpilers for package ‘GSVA’

Is there any step I'm missing? I tried to follow the documentation you provided.

[HenrikBengtsson]

I suspect you're running futurize 0.1.0. I added support for GSVA in futurize 0.2.0, which is still only on GitHub (I just submitted to CRAN, so it'll be there soon). For now, you can install as:

remotes::install_github("futureverse/futurize", ref = "develop")

[rcastelo]

I see, I've updated the futurize package and when I ran it, it asked me to install from CRAN the doFuture package. I did it, and it started running but somehow it stalls and after a couple of minutes I press CTRL+C and get the following message:

es <- gsva(param) |> futurize()
ℹ GSVA version 2.4.8
ℹ Searching for rows with constant values
ℹ Splitting calculations in 23 chunks of [9, 120] and 8.438 KiB
  |                                                                      |   0%^CWarning: Caught FutureInterruptError. Canceling all iterations ...
Error in value[[3L]](cond) : 
  'DoparParam()' foreach() error occurred: '%dofuture%' interrupted at 2026-03-19T18:46:48, while running on ‘feynman’ (pid 567003) [future <unnamed>; on 5579a5b6817241c207773a120c7a2ae3@feynman<567003> at 2026-03-19 18:46:48.669941]

The size of the chunks make me think that is trying to allocate about 20 threads, right, my workstation has only 12 cores, maybe that is the problem, is there away to control how many threads are allocated?

For instance, using BiocParallel with two workers gives no problem:

library(BiocParallel)
es <- gsva(param, BPPARAM=MulticoreParam(workers=2))
ℹ GSVA version 2.4.8
ℹ Searching for rows with constant values
ℹ Splitting calculations in 2 chunks of [100, 120] and 93.750 KiB
  |======================================================================| 100%

ℹ Calculating GSVA ranks
ℹ kcdf='auto' (default)
ℹ GSVA dense (classical) algorithm
ℹ Row-wise ECDF estimation with Gaussian kernels
ℹ Calculating row ECDFs with 2 cores
ℹ Splitting calculations in 2 chunks of [100, 120] and 93.750 KiB
  |======================================================================| 100%

ℹ Calculating column ranks with 2 cores
ℹ Splitting calculations in 2 chunks of [200, 60] and 93.750 KiB
  |======================================================================| 100%

ℹ GSVA dense (classical) algorithm
ℹ Calculating GSVA scores with 2 cores
ℹ Splitting calculations in 2 chunks of [200, 60] and 46.875 KiB
  |======================================================================| 100%

✔ Calculations finished

[HenrikBengtsson]

The size of the chunks make me think that is trying to allocate about 20 threads, right, my workstation has only 12 cores, maybe that is the problem, is there away to control how many threads are allocated?

Yeah, it sounds like its running more parallel workers than your computer can handle. If it "stalls", I suspect you might be maxing out on memory. It could also be that it's shuffling a huge amount of data back and forth with the parallel workers. You can specify the number of parallel workers you like as:

plan(multisession, workers = 2)

That corresponds to BPPARAM = SnowParam(workers = 2). To get forked parallel workers like BPPARAM = MulticoreParam(workers=2), use:

plan(multicore, workers = 2)

As you know, using "multicore" workers avoid most of the data shuffling, so if you can use that, it might be the best.

--

Now, the defaults number of parallel workers when just specifying plan(multisession) and plan(multicore) is:

> parallelly::availableCores()

If you have 12 CPU cores on your machine, then that should return 12. I'm not sure why you end up with 23 chunks. If the above does not return 12, what does:

> parallelly::availableCores(which = "all")

give on your machine?

[rcastelo]

Hi, I have done a bunch of tests to help figuring out what the problem might be. If I try:

plan(multicore)

with default parameters works well, so the problem must be with the Snow backend. If I run:

es <- gsva(param, BPPARAM=SnowParam(workers=2))

it works, albeit slower than with MulticoreParam(workers=2). If I give SnowParam(workers=24) it also works, also slower than with MulticoreParam(workers=24), but it does not stall. If I run:

plan(multisession, workers=2)
es <- gsva(param) |> futurize()

it works!! if I increase the workers parameter at the call to plan() one by one, it also works, at least from 3 to 6, but I noticed that at each increasing number of workers, it takes longer, so maybe with workers=24 it would eventually do it, but it just needs more time.

Regarding the number of CPU cores, the technical specs of my workstation say that it is a HP Z4 G4 with Intel Xeon W-2265 3.5 GHz 2933MHz 12C, which I always interpreted as having 12 CPU cores, but in fact if I type this in the shell:

$ grep processor /proc/cpuinfo | wc -l
24

it seems to have 24, and the instructions you suggest point in the same direction:

parallelly::availableCores()
system 
    24 
parallelly::availableCores(which = "all")
           system /proc/self/status             nproc 
               24                24                24 

So, I'd say there must be something in the way the Snow backend is fired through the futurize package that my WS does not like, because the Snow backend seems to work well when using it via BiocParallel and the SnowParam() function.