Re: [R-pkg-devel] Matrix and Mac OS
Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon > On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel > wrote: > > Hi, > > I'm the maintainer for a few packages, one of which is currently failing CRAN > checks on Mac OS because Matrix is not available in my required version (the > latest). I had to fix a few things due to changes in the latest Matrix > package because of how qr works and I thought, given the apparent API change, > I should then require the latest version. My error is, "Package required and > available but unsuitable version: 'Matrix'" > > When I look at the NEWS in Matrix there is no mention of Mac OS issues, what > the latest stable version of Matrix is, nor when a fix is expected. What > version do MacOS version test Matrix with by default? Where is this > documented? I assumes it always tested with the latest version on CRAN, so > I'm a bit surprised. Or will this be resolved soon and I shouldn't bother > CRAN maintainers with a new version of my package? > > Best, > Paul > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Matrix and Mac OS
Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X
Thank you, Deepayan. Commit r85440 appears to solve the problem in emuR. Markus __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X
On Mon, 30 Oct 2023 at 12:48, Markus Jochim wrote: > > Hi R people, > > I am the maintainer of the emuR package and I am having a problem with > recent versions of R CMD check. > > CRAN‘s r-devel test suites [1] have started to emit a NOTE about the > HTML version of the manual: > > > Version: 2.4.1 > > Check: HTML version of manual > > Result: NOTE > > Found the following HTML validation problems: > > query.html:50:9 (query.Rd:22): Warning: anchor "query" > > already defined > > Flavors: r-devel-linux-x86_64-debian-clang, > > r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang, > > r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64 > > > This is caused by one of my package’s functions that is named query and > also has a parameter named query. > > I think I have tracked this down to SVN revision r85407 of R. With > earlier versions: > > R CMD Rdconv -t html query.Rd > > would output (line 50, as referenced by the NOTE): > > query > > But newer versions output: > > query Yes, sorry, my bad. r85440 (just committed) should have a temporary fix by omitting the id from the title. Please let me know if problems still persist. Best, -Deepayan > Notice the difference in id. The id "query" appears both here and > further up in the file, specifically in the h2 heading. This triggers > the HTML validation problem. I suppose this is a bug in the experimental > table of contents feature? As such, should I rather post this to R-devel? > > Unfortunately, this also prevents me from uploading a new version of my > package, since it does not get past CRAN’s automatic pretest. Can I > resubmit my new version and simply state in the comments that I cannot > fix the NOTE from r-devel at this point? Or should I rather wait until > this is changed upstream? (the described NOTE is the only complaint from > the pretest). Changing the function or parameter name is not an option, > they have been used in this package ever since it was released a couple > of years ago. > > This NOTE can also be reproduced with a minimal R package that has > nothing but a hello function with a parameter named hello. > > Thanks for reading this. I appreciate any help. > > Markus > > > Institute for Phonetics and Speech Processing > > Ludwig-Maximilians-Universität München > > https://www.phonetik.uni-muenchen.de > > > [1] https://cran.rstudio.com//web/checks/check_results_emuR.html > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X
Hi R people, I am the maintainer of the emuR package and I am having a problem with recent versions of R CMD check. CRAN‘s r-devel test suites [1] have started to emit a NOTE about the HTML version of the manual: Version: 2.4.1 Check: HTML version of manual Result: NOTE Found the following HTML validation problems: query.html:50:9 (query.Rd:22): Warning: anchor "query" already defined Flavors: r-devel-linux-x86_64-debian-clang, r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang, r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64 This is caused by one of my package’s functions that is named query and also has a parameter named query. I think I have tracked this down to SVN revision r85407 of R. With earlier versions: R CMD Rdconv -t html query.Rd would output (line 50, as referenced by the NOTE): query But newer versions output: query Notice the difference in id. The id "query" appears both here and further up in the file, specifically in the h2 heading. This triggers the HTML validation problem. I suppose this is a bug in the experimental table of contents feature? As such, should I rather post this to R-devel? Unfortunately, this also prevents me from uploading a new version of my package, since it does not get past CRAN’s automatic pretest. Can I resubmit my new version and simply state in the comments that I cannot fix the NOTE from r-devel at this point? Or should I rather wait until this is changed upstream? (the described NOTE is the only complaint from the pretest). Changing the function or parameter name is not an option, they have been used in this package ever since it was released a couple of years ago. This NOTE can also be reproduced with a minimal R package that has nothing but a hello function with a parameter named hello. Thanks for reading this. I appreciate any help. Markus Institute for Phonetics and Speech Processing Ludwig-Maximilians-Universität München https://www.phonetik.uni-muenchen.de [1] https://cran.rstudio.com//web/checks/check_results_emuR.html __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17
В Mon, 30 Oct 2023 15:58:31 +0100 (CET)
Romain Pierlot пишет:
> I'm sorry to disturb, I hope I send a mail at the right place.
This is exactly the right place to ask. Welcome to R-package-devel!
> It appears that I have addressed the Fortran issues, but upon
> resubmission to CRAN, the package was not accepted, and the following
> error was returned :
>
>
> ''With clang17 it still fails to install:
>
> error:
> loc("/data/gannet/ripley/R/packages/incoming/frailtypack.Rcheck/00_pkg_src/frailtypack/src/Integrale_mult_scl.f90":1811:17):
> 'omp.reduction' op must be used within an operation supporting
> reduction clause interface error: verification of lowering to FIR
> failed
>
> LLVM trunk gives the same error.
> ''
I'm not 100% sure, but I currently think that this is a compiler bug.
You have a variable, ss, declared inside a function.
If nb_procs==1, you start an OpenMP parallel region with a reduction on
that variable. The OpenMP parallel region starts and ends inside that
if clause. Outside the parallel region, in another branch, you add to
it as usual.
Flang-new complains about your use of the 'ss' variable outside the
parallel region, alleging that it's not valid for an OpenMP reduction.
There is no OpenMP reduction in sight where the error is reported. I
think that Flang-new is wrong to signal an error here.
Unfortunately, proving that this is a compiler bug might be hard. I'll
try to reproduce your problem, starting by downloading and compiling
flang from https://github.com/llvm/llvm-project.git commit
092b6c5ee3707ea10b9f10d0a674e8d12395369b (as stated at
). I hope
it will be possible to simplify Integrale_mult_scl.f90 until it looks
manageable for their bug tracker.
> Moreover, I don't know if it is normal or not, but when I check my
> package with R CMD chech --as-cran, I don't have any error or note
> message. But when I submit the package to the CRAN, they return
> errors and notes.
These errors only happen with the "flang-new" Fortran compiler that's
part of the LLVM compiler infrastructure. You're probably using
gfortran or some other, more well-polished Fortran compiler.
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)
I have some better news. While we established that 'in theory' setting the environment variable OMP_NUM_THREADS would help (and I maintain that it is a great PITA that CRAN does not do so as a general fix for this issue) it does *not help* once R is started. OpenMP only considers the variable once at startup and does not re-read it. So we cannot set from R once R has started. But OpenMP offers a setter (and a getter) for the thread count value. And using it addresses the issue. I created a demo package [1] which, when running on a system with both OpenMP and 'enough cores' (any modern machine will do) exhibits the warning from R CMD check --as-cran with timing enabled (i.e. env vars set). When an additional environment variable 'SHOWME' is set to 'yes', it successfully throttles via the exposed OpenMP setter. In our example, Armadillo uses it to calibrate its thread use, a lower setting is followed, and the warning is gone. I will add more convenient wrappers to RcppArmadillo itself. These are currently in a branch [2] and their use is illustrated in the help page and example of fastLm demo function [3]. I plan to make a new RcppArmadillo release with this change in the coming days, the setter and re-setter will work for any OpenMP threading changes. So if you use RcppArmadillo, this should help. (And of course there always was RhpcBLASctl doing this too.) Dirk [1] https://github.com/eddelbuettel/rcpparmadilloopenmpex [2] https://github.com/RcppCore/RcppArmadillo/tree/feature/thread_throttle\ [3] https://github.com/RcppCore/RcppArmadillo/blob/a8db424bd6aaeda2ceb897142d3c366d9c6591c7/man/fastLm.Rd#L72-L98 [4] https://cran.r-project.org/package=RhpcBLASctl -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)
Hi Dirk, Looking more closely earlier failures, vignettes have always worked fine but the note on tests said that the CPU time was only 2.7 times over elapsed time, so maybe I was just lucky this time and got under 2.5. ;) Or testthat does something special... Jouni From: Dirk Eddelbuettel Sent: Friday, October 27, 2023 16:28 To: Helske, Jouni Cc: Dirk Eddelbuettel ; Ivan Krylov ; r-package-devel@r-project.org ; Conrad Sanderson Subject: Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table) Hi Jouni, On 27 October 2023 at 13:02, Helske, Jouni wrote: | Actually, the OMP_NUM_THREADS worked for vignettes and testthat tests, but | didn't help with the examples. However, I just wrapped the problematic example Now I am confused. What is your understanding of why it helps in one place and not the other? | with \donttest as for some reason this issue only happened with a single | seemingly simple example (hence the "weird" in the earlier NEWS due to | frustration, I changed this to the CRAN version). | | Thanks for reminding me about the resetting the number of cores, will fix that | to the next version. I have an idea for a RcppArmadillo-based helper function. We can save the initial values of the environment variable in .onLoad and cache it. A simple helper function pair can then dial the environment variable down and reset it to the cached value. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
