Re: [Bioc-devel] Incorrect warning about failing package built
Hi,
Here is the issue - https://github.com/TomKellyGenetics/leiden/issues/26
I realized that we have discussed it a few months back!
Martin
On Sun, Feb 4, 2024 at 10:27 PM Martin Grigorov
wrote:
> Hi ,
>
> ReactomeGSA.data package fails to install because it depends on leiden and
> Seurat
>
> > BiocManager::install("ReactomeGSA.data", force = TRUE)
> Bioconductor version 3.19 (BiocManager 1.30.22), R Under development
> (unstable)
> (2024-01-16 r85812)
> Installing package(s) 'ReactomeGSA.data'
> also installing the dependencies ‘leiden’, ‘Seurat’
>
> trying URL 'https://cloud.r-project.org/src/contrib/leiden_0.4.3.1.tar.gz'
> Content type 'application/x-gzip' length 2864241 bytes (2.7 MB)
> ==
> downloaded 2.7 MB
>
> trying URL 'https://cloud.r-project.org/src/contrib/Seurat_5.0.1.tar.gz'
> Content type 'application/x-gzip' length 2225638 bytes (2.1 MB)
> ==
> downloaded 2.1 MB
>
> trying URL '
> https://bioconductor.org/packages/3.19/data/experiment/src/contrib/ReactomeGSA.data_1.17.1.tar.gz
> '
> Content type 'application/x-gzip' length 24200519 bytes (23.1 MB)
> ==
> downloaded 23.1 MB
>
> * installing *source* package ‘leiden’ ...
> ** package ‘leiden’ successfully unpacked and MD5 sums checked
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded from temporary location
>
> *** caught segfault ***
> address 0x90, cause 'memory not mapped'
>
> Traceback:
> 1: py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)
> 2: (function() {Sys.setenv(PYTHONPATH = newpythonpath)
> on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
> py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)})()
> 3: doTryCatch(return(expr), name, parentenv, handler)
> 4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 5: tryCatchList(expr, classes, parentenv, handlers)
> 6: tryCatch({oldpythonpath <- Sys.getenv("PYTHONPATH")
> newpythonpath <- Sys.getenv("RETICULATE_PYTHONPATH", unset =
> paste(config$pythonpath, system.file("python", package =
> "reticulate"), sep = .Platform$path.sep))local({
> Sys.setenv(PYTHONPATH = newpythonpath)
> on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
> py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0",
> interactive(), numpy_load_error)})}, error = function(e) {
> Sys.setenv(PATH = oldpath)if (is.na(curr_session_env)) {
> Sys.unsetenv("R_SESSION_INITIALIZED")}else {
> Sys.setenv(R_SESSION_INITIALIZED = curr_session_env)}stop(e)})
> 7: initialize_python()
> 8: ensure_python_initialized(required_module = module)
> 9: import(module)
> 10: doTryCatch(return(expr), name, parentenv, handler)
> 11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 12: tryCatchList(expr, classes, parentenv, handlers)
> 13: tryCatch({import(module)TRUE}, error =
> clear_error_handler(FALSE))
> 14: reticulate::py_module_available("pandas")
> 15: fun(libname, pkgname)
> 16: doTryCatch(return(expr), name, parentenv, handler)
> 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 18: tryCatchList(expr, classes, parentenv, handlers)
> 19: tryCatch(fun(libname, pkgname), error = identity)
> 20: runHook(".onAttach", ns, dirname(nspath), nsname)
> 21: attachNamespace(ns, pos = pos, deps, exclude, include.only)
> 22: doTryCatch(return(expr), name, parentenv, handler)
> 23: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 24: tryCatchList(expr, classes, parentenv, handlers)
> 25: tryCatch({attr(package, "LibPath") <- which.lib.locns <-
> loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos,
> deps, exclude, include.only)}, error = function(e) {P <- if
> (!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L])
> else ""msg <- gettextf("package or namespace load failed for %s%s:\n
> %s", sQuote(package), P, conditionMessage(e))if (logical.return
> && !quietly) message(paste("Error:", msg), domain = NA)else
> stop(msg, call. = FALSE, domain = NA)})
> 26: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return
> = TRUE)
> 27: withCallingHandlers(expr, packageStartupMessage = function(c)
> tryInvokeRestart("muffleMessage"))
> 28: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib,
> character.only = TRUE, logical.return = TRUE))
> 29: doTryCatch(return(expr), name, parentenv, handler)
> 30: tryCatchOne(expr,
Re: [Rd] Advice debugging M1Mac check errors
Simon's comments add another viewpoint to mine. My own knowledge of the impact of "disable-long-double" does not include an understanding of exactly what effect this has. One needs to spend a lot of time and effort with excruciating details. Fortunately, we can usually get away with 64 bit FP arithmetic for almost all applications. I suspect applications that need really long precision are likely best handled with special hardware. JN On 2024-02-04 16:46, Simon Urbanek wrote: On Feb 5, 2024, at 12:26 PM, Duncan Murdoch wrote: Hi John. I don't think the 80 bit format was part of IEEE 754; I think it was an Intel invention for the 8087 chip (which I believe preceded that standard), and didn't make it into the standard. The standard does talk about 64 bit and 128 bit floating point formats, but not 80 bit. Yes, the 80 bit was Intel-specific (motivated by internal operations, not as external format), but as it used to be most popular architecture, people didn't quite realize that tests relying on Intel results will be Intel-specific (PowerPC Macs had 128-bit floating point, but they were not popular enough to cause trouble in the same way). The IEEE standard allows "extended precision" formats, but doesn't prescribe their format or precision - and they are optional. Arm64 CPUs only support 64-bit double precision in hardware (true both on macOS and Windows), so only what is in the basic standard. There are 128-bit floating point solutions in software, but, obviously, they are a lot slower (several orders of magnitude). Apple has been asking for priorities in the scientific community and 128-bit floating number support was not something high on people's priority list. It is far from trivial, because there is a long list of operations (all variations of the math functions) so I wouldn't expect this to change anytime soon - in fact once Microsoft's glacial move is done we'll be likely seeing only 64-bit everywhere. That said even if you don't have a arm64 CPU, you can build R with --disable-long-double to get closer to the arm64 results if that is your worry. Cheers, Simon On 04/02/2024 4:47 p.m., J C Nash wrote: Slightly tangential: I had some woes with some vignettes in my optimx and nlsr packages (actually in examples comparing to OTHER packages) because the M? processors don't have 80 bit registers of the old IEEE 754 arithmetic, so some existing "tolerances" are too small when looking to see if is small enough to "converge", and one gets "did not converge" type errors. There are workarounds, but the discussion is beyond this post. However, worth awareness that the code may be mostly correct except for appropriate tests of smallness for these processors. JN On 2024-02-04 11:51, Dirk Eddelbuettel wrote: On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don´t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk __ 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 __ 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
Re: [Rd] Advice debugging M1Mac check errors
> On Feb 5, 2024, at 12:26 PM, Duncan Murdoch wrote: > > Hi John. > > I don't think the 80 bit format was part of IEEE 754; I think it was an Intel > invention for the 8087 chip (which I believe preceded that standard), and > didn't make it into the standard. > > The standard does talk about 64 bit and 128 bit floating point formats, but > not 80 bit. > Yes, the 80 bit was Intel-specific (motivated by internal operations, not as external format), but as it used to be most popular architecture, people didn't quite realize that tests relying on Intel results will be Intel-specific (PowerPC Macs had 128-bit floating point, but they were not popular enough to cause trouble in the same way). The IEEE standard allows "extended precision" formats, but doesn't prescribe their format or precision - and they are optional. Arm64 CPUs only support 64-bit double precision in hardware (true both on macOS and Windows), so only what is in the basic standard. There are 128-bit floating point solutions in software, but, obviously, they are a lot slower (several orders of magnitude). Apple has been asking for priorities in the scientific community and 128-bit floating number support was not something high on people's priority list. It is far from trivial, because there is a long list of operations (all variations of the math functions) so I wouldn't expect this to change anytime soon - in fact once Microsoft's glacial move is done we'll be likely seeing only 64-bit everywhere. That said even if you don't have a arm64 CPU, you can build R with --disable-long-double to get closer to the arm64 results if that is your worry. Cheers, Simon > > On 04/02/2024 4:47 p.m., J C Nash wrote: >> Slightly tangential: I had some woes with some vignettes in my >> optimx and nlsr packages (actually in examples comparing to OTHER >> packages) because the M? processors don't have 80 bit registers of >> the old IEEE 754 arithmetic, so some existing "tolerances" are too >> small when looking to see if is small enough to "converge", and one >> gets "did not converge" type errors. There are workarounds, >> but the discussion is beyond this post. However, worth awareness that >> the code may be mostly correct except for appropriate tests of >> smallness for these processors. >> JN >> On 2024-02-04 11:51, Dirk Eddelbuettel wrote: >>> >>> On 4 February 2024 at 20:41, Holger Hoefling wrote: >>> | I wanted to ask if people have good advice on how to debug M1Mac package >>> | check errors when you don´t have a Mac? Is a cloud machine the best option >>> | or is there something else? >>> >>> a) Use the 'mac builder' CRAN offers: >>> https://mac.r-project.org/macbuilder/submit.html >>> >>> b) Use the newly added M1 runners at GitHub Actions, >>> >>> https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ >>> >>> Option a) is pretty good as the machine is set up for CRAN and builds >>> fast. Option b) gives you more control should you need it. >>> >>> Dirk >>> >> __ >> 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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice debugging M1Mac check errors
80 bit registers (I don't have my original docs with me here in Victoria) seem to have been part of the 1985 standard to which I was one of the 31 named contributors. See https://stackoverflow.com/questions/612507/what-are-the-applications-benefits-of-an-80-bit-extended-precision-data-type or the Wikipedia item on IEEE 754. It appears to have been omitted from 2008 and 2020 versions, but is still (I believe) part of many processors. It's an internal precision for handling multiplications and accumulation, and not one of the storage modes. Most of the time this makes very little difference in results for R, since it is only some operations where the extended precision gets activated. If we store quantities, we get the regular precision. Thus very few situations using the M? chips give differences, but when they do, it is a nuisance. There is plenty of scope for debating the pros and cons of extended precision internally. Not having it likely contributes to speed / bang for the buck of the M? chips. But we do now have occasional differences in outcomes which will lead to confusion and extra work. JN On 2024-02-04 15:26, Duncan Murdoch wrote: Hi John. I don't think the 80 bit format was part of IEEE 754; I think it was an Intel invention for the 8087 chip (which I believe preceded that standard), and didn't make it into the standard. The standard does talk about 64 bit and 128 bit floating point formats, but not 80 bit. Duncan Murdoch On 04/02/2024 4:47 p.m., J C Nash wrote: Slightly tangential: I had some woes with some vignettes in my optimx and nlsr packages (actually in examples comparing to OTHER packages) because the M? processors don't have 80 bit registers of the old IEEE 754 arithmetic, so some existing "tolerances" are too small when looking to see if is small enough to "converge", and one gets "did not converge" type errors. There are workarounds, but the discussion is beyond this post. However, worth awareness that the code may be mostly correct except for appropriate tests of smallness for these processors. JN On 2024-02-04 11:51, Dirk Eddelbuettel wrote: On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don´t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk __ 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
Re: [Rd] [Feature Request] Hide API Key in download.file() / R's libcurl
For cases like these, I think it would be more useful to have some
mechanism for associating URLs / hosts with credentials, and have R use
those credentials by default whenever accessing those URLs. Since
download.file() now supports custom headers, this could be a mechanism for
setting headers to be used by default when downloading files from
particular URLs. Then, users could do something like:
options(download.file.headers = list(
example.org = c(Authorization = "<...>")
))
And those headers would be used automatically by download.file() whenever
talking to that server.
All of that to say -- I think the better way forward would be to make it
easier to safely use authentication credentials in download.file(), rather
than just tooling in support for suppressing specific types of output.
Best,
Kevin
On Sat, Feb 3, 2024 at 1:33 PM Simon Urbanek
wrote:
>
> Any reason why you didn't use quiet=TRUE to suppress that output?
>
> There is no official API structure for credentials in R repositories, so
R has no way of knowing which part of the URL are credentials as it is not
under R's purview - it could be part of the path or anything, so there is
no way R can reliably mask it. Hence it makes more sense for the user to
suppress the output if they think it may contain sensitive information -
and R supports that.
>
> If that's still not enough, then please make a concrete proposal that
defines exactly what kind processing you'd like to see under what
conditions - and how you think that will solve the problem.
>
> Cheers,
> Simon
>
>
>
> > On Feb 2, 2024, at 5:28 AM, Xinyi wrote:
> >
> > Hi all,
> >
> > When trying to install a package from R using install.packages(), it
will
> > print out the full url address (of the remote repository) it was trying
to
> > access. A bit further digging shows it is from the in_do_curlDownload
> > method from R's libcurl
> > <
https://github.com/wch/r-source/blob/trunk/src/modules/internet/libcurl.c>:
> > install.packages() calls download.packages(), and download.packages()
calls
> > download.file(), which uses "libcurl" as its default method.
> >
> > This line from R mirror
> > <
https://github.com/wch/r-source/blob/trunk/src/modules/internet/libcurl.c#L772
>
> > ("if (!quiet) REprintf(_("trying URL '%s'\n"), url);") prints the full
url
> > it is trying to access.
> >
> > This is totally fine for public urls without credentials, but in the
case
> > that a given url contains an API key, it poses security issues. For
> > example, if the getOption("repos") has been overridden to a
> > customized repository (protected by API keys), then
> >> install.packages("zoo")
> > Installing packages into '--removed local directory path--'
> > trying URL 'https://--removed userid--:--removed
> > api-ke...@repository-addresss.com:4443/.../src/contrib/zoo_1.8-12.tar.gz
'
> > Content type 'application/x-gzip' length 782344 bytes (764 KB)
> > ===
> > downloaded 764 KB
> >
> > * installing *source* package 'zoo' ...
> > -- further logs removed --
> >>
> >
> > I also tried several other options:
> >
> > 1. quite=1
> >> install.packages("zoo", quite=1)
> > It did hide the url, but it also hid all other useful information.
> > 2. method="curl"
> >> install.packages("zoo", method="curl")
> > This does not print the url when the download is successful, but if
there
> > were any errors, it still prints the url with API key in it.
> > 3. method="wget"
> >> install.packages("zoo", method="wget")
> > This hides API key by *password*, but I wasn't able to install packages
> > with this method even with public repos, with the error "Warning:
unable to
> > access index for repository https://cloud.r-project.org/src/contrib/4.3:
> > 'wget' call had nonzero exit status"
> >
> >
> > In other dynamic languages' package managers like Python's pip, API keys
> > are hidden by default since pip 18.x in 2018, and masked by "" from
pip
> > 19.x in 2019, see below examples. Can we get a similar default
behaviour in
> > R?
> >
> > 1. with pip 10.x
> > $ pip install numpy -v # API key was not hided
> > Looking in indexes: https://--removed userid--:--removed
> > api-ke...@repository-addresss.com:4443/.../pypi/simple
> > 2. with pip 18.x # All credentials are removed by pip
> > $ pip install numpy -v
> > Looking in indexes: https://repository-addresss.com:4443/
> > .../pypi/simple
> > 3. with pip 19.x onwards # userid is kept, API key is replaced by
> > $ pip install numpy -v
> > Looking in indexes: https://userid:@
> > repository-addresss.com:4443/.../pypi/simple
> >
> >
> > I was instructed by https://www.r-project.org/bugs.html that I should
get
> > some discussion on r-devel before filing a feature request. So looking
> > forward to comments/suggestions.
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
Re: [Rd] Advice debugging M1Mac check errors
Hi John. I don't think the 80 bit format was part of IEEE 754; I think it was an Intel invention for the 8087 chip (which I believe preceded that standard), and didn't make it into the standard. The standard does talk about 64 bit and 128 bit floating point formats, but not 80 bit. Duncan Murdoch On 04/02/2024 4:47 p.m., J C Nash wrote: Slightly tangential: I had some woes with some vignettes in my optimx and nlsr packages (actually in examples comparing to OTHER packages) because the M? processors don't have 80 bit registers of the old IEEE 754 arithmetic, so some existing "tolerances" are too small when looking to see if is small enough to "converge", and one gets "did not converge" type errors. There are workarounds, but the discussion is beyond this post. However, worth awareness that the code may be mostly correct except for appropriate tests of smallness for these processors. JN On 2024-02-04 11:51, Dirk Eddelbuettel wrote: On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don´t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk __ 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
Re: [Rd] Advice debugging M1Mac check errors
I think I had that problem with the minimaxApprox package as well. Avi Sent from my iPhone > On Feb 4, 2024, at 4:47 PM, J C Nash wrote: > > Slightly tangential: I had some woes with some vignettes in my > optimx and nlsr packages (actually in examples comparing to OTHER > packages) because the M? processors don't have 80 bit registers of > the old IEEE 754 arithmetic, so some existing "tolerances" are too > small when looking to see if is small enough to "converge", and one > gets "did not converge" type errors. There are workarounds, > but the discussion is beyond this post. However, worth awareness that > the code may be mostly correct except for appropriate tests of > smallness for these processors. > > JN > > > > >> On 2024-02-04 11:51, Dirk Eddelbuettel wrote: >> On 4 February 2024 at 20:41, Holger Hoefling wrote: >> | I wanted to ask if people have good advice on how to debug M1Mac package >> | check errors when you don´t have a Mac? Is a cloud machine the best option >> | or is there something else? >> a) Use the 'mac builder' CRAN offers: >>https://mac.r-project.org/macbuilder/submit.html >> b) Use the newly added M1 runners at GitHub Actions, >> >> https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ >> Option a) is pretty good as the machine is set up for CRAN and builds >> fast. Option b) gives you more control should you need it. >> Dirk >> > > __ > 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
Re: [Rd] Advice debugging M1Mac check errors
Slightly tangential: I had some woes with some vignettes in my optimx and nlsr packages (actually in examples comparing to OTHER packages) because the M? processors don't have 80 bit registers of the old IEEE 754 arithmetic, so some existing "tolerances" are too small when looking to see if is small enough to "converge", and one gets "did not converge" type errors. There are workarounds, but the discussion is beyond this post. However, worth awareness that the code may be mostly correct except for appropriate tests of smallness for these processors. JN On 2024-02-04 11:51, Dirk Eddelbuettel wrote: On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don´t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Incorrect warning about failing package built
Hi ,
ReactomeGSA.data package fails to install because it depends on leiden and
Seurat
> BiocManager::install("ReactomeGSA.data", force = TRUE)
Bioconductor version 3.19 (BiocManager 1.30.22), R Under development
(unstable)
(2024-01-16 r85812)
Installing package(s) 'ReactomeGSA.data'
also installing the dependencies ‘leiden’, ‘Seurat’
trying URL 'https://cloud.r-project.org/src/contrib/leiden_0.4.3.1.tar.gz'
Content type 'application/x-gzip' length 2864241 bytes (2.7 MB)
==
downloaded 2.7 MB
trying URL 'https://cloud.r-project.org/src/contrib/Seurat_5.0.1.tar.gz'
Content type 'application/x-gzip' length 2225638 bytes (2.1 MB)
==
downloaded 2.1 MB
trying URL '
https://bioconductor.org/packages/3.19/data/experiment/src/contrib/ReactomeGSA.data_1.17.1.tar.gz
'
Content type 'application/x-gzip' length 24200519 bytes (23.1 MB)
==
downloaded 23.1 MB
* installing *source* package ‘leiden’ ...
** package ‘leiden’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
*** caught segfault ***
address 0x90, cause 'memory not mapped'
Traceback:
1: py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0", interactive(),
numpy_load_error)
2: (function() {Sys.setenv(PYTHONPATH = newpythonpath)
on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0", interactive(),
numpy_load_error)})()
3: doTryCatch(return(expr), name, parentenv, handler)
4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatch({oldpythonpath <- Sys.getenv("PYTHONPATH")
newpythonpath <- Sys.getenv("RETICULATE_PYTHONPATH", unset =
paste(config$pythonpath, system.file("python", package =
"reticulate"), sep = .Platform$path.sep))local({
Sys.setenv(PYTHONPATH = newpythonpath)
on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0",
interactive(), numpy_load_error)})}, error = function(e) {
Sys.setenv(PATH = oldpath)if (is.na(curr_session_env)) {
Sys.unsetenv("R_SESSION_INITIALIZED")}else {
Sys.setenv(R_SESSION_INITIALIZED = curr_session_env)}stop(e)})
7: initialize_python()
8: ensure_python_initialized(required_module = module)
9: import(module)
10: doTryCatch(return(expr), name, parentenv, handler)
11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
12: tryCatchList(expr, classes, parentenv, handlers)
13: tryCatch({import(module)TRUE}, error =
clear_error_handler(FALSE))
14: reticulate::py_module_available("pandas")
15: fun(libname, pkgname)
16: doTryCatch(return(expr), name, parentenv, handler)
17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
18: tryCatchList(expr, classes, parentenv, handlers)
19: tryCatch(fun(libname, pkgname), error = identity)
20: runHook(".onAttach", ns, dirname(nspath), nsname)
21: attachNamespace(ns, pos = pos, deps, exclude, include.only)
22: doTryCatch(return(expr), name, parentenv, handler)
23: tryCatchOne(expr, names, parentenv, handlers[[1L]])
24: tryCatchList(expr, classes, parentenv, handlers)
25: tryCatch({attr(package, "LibPath") <- which.lib.locns <-
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos,
deps, exclude, include.only)}, error = function(e) {P <- if
(!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L])
else ""msg <- gettextf("package or namespace load failed for %s%s:\n
%s", sQuote(package), P, conditionMessage(e))if (logical.return
&& !quietly) message(paste("Error:", msg), domain = NA)else
stop(msg, call. = FALSE, domain = NA)})
26: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return
= TRUE)
27: withCallingHandlers(expr, packageStartupMessage = function(c)
tryInvokeRestart("muffleMessage"))
28: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib,
character.only = TRUE, logical.return = TRUE))
29: doTryCatch(return(expr), name, parentenv, handler)
30: tryCatchOne(expr, names, parentenv, handlers[[1L]])
31: tryCatchList(expr, classes, parentenv, handlers)
32: tryCatch(expr, error = function(e) {call <- conditionCall(e)if
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))
call <- sys.call(-4L)dcall <- deparse(call, nlines = 1L)
prefix <- paste("Error in", dcall, ": ")LONG <- 75Lsm
<-
Re: [Rd] Advice debugging M1Mac check errors
On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don´t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Advice debugging M1Mac check errors
Hi, I wanted to ask if people have good advice on how to debug M1Mac package check errors when you don´t have a Mac? Is a cloud machine the best option or is there something else? Thanks Holger [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Warnings from upstream C library in CRAN submission
Thank you Jeff and Simon for your feedback. I have filed your feedback as an issue to the SUNDIALS developers at - https://github.com/LLNL/sundials/issues/409 Thank you. On Sat, Feb 3, 2024 at 10:38 AM Satyaprakash Nayak wrote: > Hi > > I had a package 'sundialr' which was archived from CRAN. It is an interface > to some of the solvers in SUNDIALS ODE Solving library. I have fixed the > issue which was related to emails being forwarded from the maintainer's > email address. > > The repository code can be found at - https://github.com/sn248/sundialr > > I have updated the upstream library and now I am getting the following > warnings from CRAN which are all related to the upstream library. The > package compiles without any other issues and can be used. > > Flavor: r-devel-windows-x86_64 > Check: whether package can be installed, Result: WARNING > Found the following significant warnings: > ./sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '14695981039346656037' to '2216829733' [-Woverflow] > ./sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '1099511628211' to '435' [-Woverflow] > sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '14695981039346656037' to '2216829733' [-Woverflow] > sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '1099511628211' to '435' [-Woverflow] > sundials/sundials/sundials_profiler.c:71:24: warning: function > declaration isn't a prototype [-Wstrict-prototypes] > See 'd:/RCompile/CRANincoming/R-devel/sundialr.Rcheck/00install.out' for > details. > Used C++ compiler: 'g++.exe (GCC) 12.3.0' > > Flavor: r-devel-linux-x86_64-debian-gcc > Check: whether package can be installed, Result: WARNING > Found the following significant warnings: > sundials/sundials/sundials_profiler.c:71:41: warning: a function > declaration without a prototype is deprecated in all versions of C > [-Wstrict-prototypes] > See '/srv/hornik/tmp/CRAN/sundialr.Rcheck/00install.out' for details. > Used C++ compiler: 'Debian clang version 17.0.6 (5)' > > I am hesitant to change anything in the SUNDIALS library C code because I > don't understand the consequences of changing anything there. > > Any help will be kindly appreciated. > > Thank you. > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] NOTE: multiple local function definitions for ?fun? with different formal arguments
On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel wrote:
Well you can see that yeast is exactly weekday you have. The way out is to
just not name the result
I think something happened to your explanation...
toto <- function(mode)
{
ifelse(mode == 1,
function(a,b) a*b,
function(u, v, w) (u + v) / w)
}
It's a bad idea to use ifelse() when you really want if() ... else ... .
In this case it works, but it doesn't always. So the workaround should be
toto <- function(mode)
{
if(mode == 1)
function(a,b) a*b
else
function(u, v, w) (u + v) / w
}
From: Grant Izmirlian
Date: Sun, Feb 4, 2024, 10:44 AM
To: "Izmirlian, Grant (NIH/NCI) [E]"
Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2
Hi,
I just ran into this 'R CMD check' NOTE for the first time:
* checking R code for possible problems ... NOTE
toto: multiple local function definitions for �fun� with different
formal arguments
The "offending" code is something like this (simplified from the real code):
toto <- function(mode)
{
if (mode == 1)
fun <- function(a, b) a*b
else
fun <- function(u, v, w) (u + v) / w
fun
}
Is that NOTE really intended? Hard to see why this code would be
considered "wrong".
I know it's just a NOTE but still...
I agree it's a false positive, but the issue is that you have a function
object in your function which can't be called unconditionally. The
workaround doesn't create such an object.
Recognizing that your function never tries to call fun requires global
inspection of toto(), and most of the checks are based on local inspection.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NOTE: multiple local function definitions for ?fun? with different formal arguments
Well you can see that yeast is exactly weekday you have. The way out is to
just not name the result
toto <- function(mode)
{
ifelse(mode == 1,
function(a,b) a*b,
function(u, v, w) (u + v) / w)
}
From: Grant Izmirlian
Date: Sun, Feb 4, 2024, 10:44 AM
To: "Izmirlian, Grant (NIH/NCI) [E]"
Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2
Hi,
I just ran into this 'R CMD check' NOTE for the first time:
* checking R code for possible problems ... NOTE
toto: multiple local function definitions for �fun� with different
formal arguments
The "offending" code is something like this (simplified from the real code):
toto <- function(mode)
{
if (mode == 1)
fun <- function(a, b) a*b
else
fun <- function(u, v, w) (u + v) / w
fun
}
Is that NOTE really intended? Hard to see why this code would be
considered "wrong".
I know it's just a NOTE but still...
Thanks,
H.
--
Herv� Pag�s
Bioconductor Core Team
hpages.on.git...@gmail.com
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and are confident the
content is safe.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
