Bug#879248: r-cran-nmf: detecting number of cores

[Dylan Aïssi]

Hi Michael,

2018-03-12 8:44 GMT+01:00 Michael Cree :
> How about the attached patch?  Should detection of number of cores
> fail it sets the number of cores to be one.  With this patch
> r-cran-nmf builds successfully on Alpha.

Thanks for this patch. But, I think if we really want to fix this
issue in our package before than upstream releases a fixed version, we
should probably use the same way as upstream.
That is to backport these 2 commits [1-2].

Best,
Dylan

[1] https://github.com/renozao/NMF/commit/063cdcb102
[2] https://github.com/renozao/NMF/commit/6996bce01e

Bug#879248: r-cran-nmf: detecting number of cores

[Michael Cree]

How about the attached patch?  Should detection of number of cores
fail it sets the number of cores to be one.  With this patch
r-cran-nmf builds successfully on Alpha.

Cheers
Michael.
Index: r-cran-nmf-0.21.0/R/options.R
===
--- r-cran-nmf-0.21.0.orig/R/options.R	2018-02-07 02:45:56.0 +1300
+++ r-cran-nmf-0.21.0/R/options.R	2018-03-12 19:42:26.704548354 +1300
@@ -78,7 +78,7 @@
 	, gc=50
 	# define default parallel backend 
 	, parallel.backend= option_symlink('pbackend') # for backward compatibility
-	, pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
+	, pbackend= if( parallel::detectCores() > 1 && !is.na(parallel::detectCores()) ) 'par' else 'seq'
 	# toogle verbosity
 	, verbose=FALSE
 	# toogle debug mode
Index: r-cran-nmf-0.21.0/R/parallel.R
===
--- r-cran-nmf-0.21.0.orig/R/parallel.R	2018-02-19 06:39:59.0 +1300
+++ r-cran-nmf-0.21.0/R/parallel.R	2018-03-12 19:35:55.337916554 +1300
@@ -17,6 +17,7 @@
 getMaxCores <- function(limit=TRUE){
 	#ceiling(parallel::detectCores()/2)
 	nt <- n <- parallel::detectCores()
+	if( is.na(n) ) n <- 1L
 	# limit to number of cores specified in options if asked for
 	if( limit ){
 		if( !is.null(nc <- getOption('cores')) ) n <- nc # global option

Bug#879248:

[Andreas Tille]

I've asked for release tags in any case

https://github.com/renozao/NMF/issues/108

(I guess 75% of all Github issues I filed was asking for release tags :-( ) 

-- 
http://fam-tille.de

Bug#879248:

[Dylan Aïssi]

Hi Andreas,

2018-03-09 10:40 GMT+01:00 Andreas Tille :
>
> How did you guessed the version number 0.23.4?  There are no release
> tags on Github - at least I can not find any?  Somehow issue #106 is
> mentioning removal from CRAN so may be we can expect some properly
> versioned NMF with correct fix soon.  I'm not sure whether we should
> add the patch above as quilt patch meanwhile.
>

Some commits after this one, upstream updated DESCRIPTION with this
unreleased version [1].
It is unclear how they release new versions, so I will keep an eye on
#106 and maybe ask them to release something >=0.23.4.
I agree with you, probably useless to backport the patch. I mentioned
it, only to keep a trace.

Best,
Dylan

[1] https://github.com/renozao/NMF/commit/b26e3e3189

Bug#879248:

[Andreas Tille]

On Fri, Mar 09, 2018 at 10:02:41AM +0100, Dylan Aïssi wrote:
> It seems to be fixed in 0.23.4 but not yet on CRAN.
> 
> https://github.com/renozao/NMF/commit/6996bce01e

How did you guessed the version number 0.23.4?  There are no release
tags on Github - at least I can not find any?  Somehow issue #106 is
mentioning removal from CRAN so may be we can expect some properly
versioned NMF with correct fix soon.  I'm not sure whether we should
add the patch above as quilt patch meanwhile.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#879248:

[Dylan Aïssi]

It seems to be fixed in 0.23.4 but not yet on CRAN.

https://github.com/renozao/NMF/commit/6996bce01e

Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Renaud Gaujoux]

Hi,

thanks for reporting this. I will attend to it.
Need to update my maintainer email address as well.

Bests,
Renaud


On 21 October 2017 at 12:03, Andreas Tille  wrote:

> Hi Renaud,
>
> seems I was using a wrong e-mail address.  The address mentioned at
> CRAN as maintainer was bouncing.
>
> Kind regards
>
>   Andreas,
>
> control: forwarded -1 Renaud Gaujoux 
>
> On Sat, Oct 21, 2017 at 07:59:51AM +0200, Andreas Tille wrote:
> > control: tags -1 upstream
> > control: forwarded -1 Renaud Gaujoux 
> >
> >
> > Hi Renaud,
> >
> > I'm hereby forwarding an issue that was reported at the Debian
> > package.
> >
> > Kind regards
> >
> >Andreas.
> >
> >
> > On Sat, Oct 21, 2017 at 05:10:44PM +1300, Michael Cree wrote:
> > > Source: r-cran-nmf
> > > Version: 0.20.6-1
> > > Severity: wishlist
> > >
> > > r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
> > > it calls R base function parallel::detectCores() and expects the
> > > result to be an integer, however the detectCores() documentation
> > > states that the result is an integer only if the number of CPU cores
> > > is actually detected, and NA otherwise.  On the above mentioned
> > > systems detectCores() fails to detect the number of CPUs thus returns
> > > NA which leads to the failure to build in r-cran-nmf.
> > >
> > > The problem is at line 81 of R/options.R which has:
> > >
> > > , pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
> > >
> > > Presumably that code should be modified to assign detectCores() to a
> > > variable and test for NA, and if it is NA just go with one core.
> > >
> > > Use of detectCores() is also in R/parallel.R and presumably that
> > > also should be checked for an NA returned value.
> > >
> > > Cheers
> > > Michael.
> > >
> > > ___
> > > Debian-med-packaging mailing list
> > > debian-med-packag...@lists.alioth.debian.org
> > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> > >
> >
> > --
> > http://fam-tille.de
>
> --
> http://fam-tille.de
>
>

Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Andreas Tille]

Hi Renaud,

seems I was using a wrong e-mail address.  The address mentioned at
CRAN as maintainer was bouncing.

Kind regards

  Andreas,

control: forwarded -1 Renaud Gaujoux 

On Sat, Oct 21, 2017 at 07:59:51AM +0200, Andreas Tille wrote:
> control: tags -1 upstream
> control: forwarded -1 Renaud Gaujoux 
> 
> 
> Hi Renaud,
> 
> I'm hereby forwarding an issue that was reported at the Debian
> package.
> 
> Kind regards
> 
>Andreas.
> 
> 
> On Sat, Oct 21, 2017 at 05:10:44PM +1300, Michael Cree wrote:
> > Source: r-cran-nmf
> > Version: 0.20.6-1
> > Severity: wishlist
> > 
> > r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
> > it calls R base function parallel::detectCores() and expects the
> > result to be an integer, however the detectCores() documentation
> > states that the result is an integer only if the number of CPU cores
> > is actually detected, and NA otherwise.  On the above mentioned
> > systems detectCores() fails to detect the number of CPUs thus returns
> > NA which leads to the failure to build in r-cran-nmf.
> > 
> > The problem is at line 81 of R/options.R which has:
> > 
> > , pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
> > 
> > Presumably that code should be modified to assign detectCores() to a
> > variable and test for NA, and if it is NA just go with one core.
> > 
> > Use of detectCores() is also in R/parallel.R and presumably that
> > also should be checked for an NA returned value.
> > 
> > Cheers
> > Michael.
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Andreas Tille]

control: tags -1 upstream
control: forwarded -1 Renaud Gaujoux 


Hi Renaud,

I'm hereby forwarding an issue that was reported at the Debian
package.

Kind regards

   Andreas.


On Sat, Oct 21, 2017 at 05:10:44PM +1300, Michael Cree wrote:
> Source: r-cran-nmf
> Version: 0.20.6-1
> Severity: wishlist
> 
> r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
> it calls R base function parallel::detectCores() and expects the
> result to be an integer, however the detectCores() documentation
> states that the result is an integer only if the number of CPU cores
> is actually detected, and NA otherwise.  On the above mentioned
> systems detectCores() fails to detect the number of CPUs thus returns
> NA which leads to the failure to build in r-cran-nmf.
> 
> The problem is at line 81 of R/options.R which has:
> 
> , pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
> 
> Presumably that code should be modified to assign detectCores() to a
> variable and test for NA, and if it is NA just go with one core.
> 
> Use of detectCores() is also in R/parallel.R and presumably that
> also should be checked for an NA returned value.
> 
> Cheers
> Michael.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Michael Cree]

Source: r-cran-nmf
Version: 0.20.6-1
Severity: wishlist

r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
it calls R base function parallel::detectCores() and expects the
result to be an integer, however the detectCores() documentation
states that the result is an integer only if the number of CPU cores
is actually detected, and NA otherwise.  On the above mentioned
systems detectCores() fails to detect the number of CPUs thus returns
NA which leads to the failure to build in r-cran-nmf.

The problem is at line 81 of R/options.R which has:

, pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'

Presumably that code should be modified to assign detectCores() to a
variable and test for NA, and if it is NA just go with one core.

Use of detectCores() is also in R/parallel.R and presumably that
also should be checked for an NA returned value.

Cheers
Michael.