Re: [R-pkg-devel] winUCRT failures

On 25 April 2021 at 12:27, Duncan Murdoch wrote: | On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: | > I last wrote about that four years ago under the title "Suggests != Depends" | > http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends | > | > Of c

Re: [R-pkg-devel] winUCRT failures

On 25 April 2021 at 11:14, Duncan Murdoch wrote: | What I haven't tried to do is check any of them if *none* of the | suggested packages is available. Packages should still build and check | without ERRORs in this case, though I'd expect NOTEs and/or WARNINGs. | | This is an old issue: what

Re: [R-sig-Debian] Unable to install some R packages in Ubuntu 20.04--internal compiler error: Segmentation fault

b by conda or miniconda. Dirk | Thanks all, | Mazin | | On Mon, Apr 19, 2021 at 11:28 AM Dirk Eddelbuettel wrote: | | > | > Hi Mazin, | > | > On 19 April 2021 at 10:24, Mazin Abdelghany wrote: | > | I recently installed R onto my Ubuntu 20.04 install using the | > instruction

Re: [R-pkg-devel] Using ggplot2 within another package

On 22 April 2021 at 16:28, Kevin R. Coombes wrote: | I'm trying to help clean up an R package for someone else to submit to | CRAN. He has used ggplot2 to implement a plotting function for the kinds | of things that his packages generates. His plotting routine basically | looks like (after

Re: [R-sig-Debian] Keep Downloading R 3.6.3 on Linux Mint 20.1

On 22 April 2021 at 00:03, David Winsemius wrote: | The ppa for Ubuntu and Debian Ubuntu, and likely useable on derivarives like Mint but *not* Debian. You cannot (generally) mix Debian and Ubuntu. (Some vendors do for things like Chrome as .deb as all dependencies are in that package; but

Re: [R-pkg-devel] Skipping tests on CRAN

You can default to have 'few tests'. That then happens at CRAN too when nothing else is set (as there simply is no variable to rely upon). You can then try to detect when you would want to run 'more tests'. Placing the tests somewhere else (as Duncan suggested) to explicitly opt in is one way

Re: [R-sig-Debian] Unable to install some R packages in Ubuntu 20.04--internal compiler error: Segmentation fault

Hi Mazin, On 19 April 2021 at 10:24, Mazin Abdelghany wrote: | I recently installed R onto my Ubuntu 20.04 install using the instructions | here: https://cran.r-project.org/bin/linux/ubuntu/. R works as expected. | | However, while some packages have installed without issue (e.g., R.matlab), |

Re: [R-sig-Debian] Installing packages

On 18 April 2021 at 17:33, Michael Rutter wrote: | On 4/18/21 5:17 PM, James Daly wrote: | > In R, I am having trouble downloading some packages (apaTables, apaStyle, | > OpenMx, MBESS, gsl). This post Some of those are not simple but complex. The devil, as always, is in the detail. | >

Re: [R-pkg-devel] Package gcc-ASAN issue

On 16 April 2021 at 10:27, Kevin Ushey wrote: | You can also try to verify locally using e.g. Docker; the rocker | images here are immensely helpful: | | https://github.com/rocker-org/r-devel-san Thanks but that container image may be stale at times. The daily rebuilds by Kevin's colleague

[ESS] Announcing ‘Introductions to Emacs Speaks Statistics'

(This is a text-only, no-links copy of what I just put onto my blog at http://dirk.eddelbuettel.com/blog/2021/04/15#announcing_ess_intros where you find it with links. The key site is https://ess-intro.github.io.) Announcing ‘Introductions to Emacs Speaks Statistics’ A new website containing

Re: [R-pkg-devel] error messages

On 14 April 2021 at 01:03, csmatyi wrote: | Debian | | * using log directory ‘/srv/hornik/tmp/CRAN/hybridogram.Rcheck’ | * using R Under development (unstable) (2021-04-12 r80161) | * using platform: x86_64-pc-linux-gnu (64-bit) | * using session charset: UTF-8 | * checking for file

Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples

On 9 April 2021 at 22:33, Andreas Beckmann wrote: | On 09/04/2021 22.19, Dirk Eddelbuettel wrote: | > That is ... quite possible. It's actually the same with line above in | > debian/rules. The actual underlying problem, though, is that a lot of | > content that once appears to have

Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples

On 6 April 2021 at 17:18, Andreas Beckmann wrote: | Package: gretl | Version: 2021a-1 | Severity: normal | User: debian...@lists.debian.org | Usertags: piuparts | | Hi, | | during a test with piuparts I noticed your package ships (or creates) | a broken symlink. | | >From the attached log

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 8 April 2021 at 11:29, Graham Inggs wrote: | Control: forwarded -1 https://deb.li/6f4z | | TMB upstream have submitted a bug report [1] to R-forge. | | > Headers need update corresponding to new SuiteSparse version 5.7.1 | > | > SuiteSparse was recently updated from version 4.2.1 to 5.7.1,

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 8 April 2021 at 11:29, Graham Inggs wrote: | Control: forwarded -1 https://deb.li/6f4z | | TMB upstream have submitted a bug report [1] to R-forge. | | > Headers need update corresponding to new SuiteSparse version 5.7.1 | > | > SuiteSparse was recently updated from version 4.2.1 to 5.7.1,

Re: [R] /usr/local/lib/R/site-library is not writable

Hi Gene, "It's complicated". (Not really, but listen for a sec...) We need to ship a default policy that makes sense for all / most situations. So - users cannot write into /usr/local/lib/R/site-library -- unless they are set up to, but adding them to the 'group' that owns that directory

Re: [Rd] [External] memory consumption of nested (un)serialize of sys.frames()

On 7 April 2021 at 16:06, Andreas Kersting wrote: | Hi Luke, | | Please see https://github.com/akersting/dumpTest for the package. | | Here a session showing my issue: | | > library(dumpTest) | > sessionInfo() | R version 4.0.5 (2021-03-31) | Platform: x86_64-pc-linux-gnu (64-bit) | Running

Re: [Rd] R extension memory leak detection question

On 5 April 2021 at 18:27, xiaoyan yu wrote: | Thank you all for your help. | We embedded R in our program and found the memory in the process | accumulated while our expectation is that the memory will go down after | each R evaluation. | I started to write a test program with only a few lines

Re: [Rcpp-devel] A clean way to handle character/strings between R and Rcpp

On 3 April 2021 at 14:28, prezzemolo wrote: | Hey. | | I am wondering if there's some general guidance on what the 'right' options are to cleanly handle character arguments passed from R to Rcpp. | | It is all rather simple: let's say I have a human-readable argument vector c("tree", "herb",

Re: [Rcpp-devel] A clean way to handle character/strings between R and Rcpp

Could you by chance send that again in __text__ format? It came into my mail client as mostly unformatted and hence unreadable word soup. Sorry for the bother, and Hi from Chicago. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: [R-pkg-devel] Using RC_fopen in a CRAN package

On 2 April 2021 at 09:45, Duncan Murdoch wrote: | On 01/04/2021 9:06 p.m., David Cortes wrote: | > Is it allowed to use such functions in packages? I see a few packages | > currently in CRAN have the same note in the checks, such as "iotools", | > and am wondering if I should just email the CRAN

Re: [R-pkg-devel] Error on Solaris 10 'memory not mapped'

On 1 April 2021 at 18:39, Zhang, Wan wrote: | Hello, | | In our package �BET� version 0.3.4 published on 2021-03-21, there is a �memory not mapped� error on Solaris 10. | | https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/BET-00check.html | | I tried to replicate this error with

Re: [R-pkg-devel] Optional system/C++ library

On 30 March 2021 at 15:19, Florian Rupprecht wrote: | I am trying to add an optional system/C++ library to my package and was | wondering if anyone could point me in the right direction on how to do this | in the R package ecosystem. | | To be concrete, I want my graphics device package httpgd

Re: [R-pkg-devel] Debugging RODBC installation problems on FreeBSD (unixodbc library path)

On 29 March 2021 at 23:29, Rasmus Liland wrote: | can someone please guide me a little in | installing RODBC[1] on FreeBSD 13? | | I believe it depends on unixodbc[2], but | the compilation stops with at not | finding unixodbc (I think): | | rasmus@iselin ~ % mkdir ~/src/RODBC |

Re: [R-pkg-devel] Debugging M1mac problems

Hi Ivan, On 27 March 2021 at 19:11, Ivan Krylov wrote: | Dirk, thank you a prompt reply! | | I see the issue you took part in solving: | https://github.com/x13org/x13binary/issues/49 Yes. Temporary files are now written to a temporary directory which I make sure to remove at end of examples

Re: [Rd] custom allocators, Valgrind and uninitialized memory

Andreas, Thanks for the clarification. On 26 March 2021 at 20:48, Andreas Kersting wrote: | Sure, let me try to explain: | | CRAN ran the tests of my package using R which was configured --with-valgrind-instrumentation > 0. Valgrind reported many errors related to the use of supposedly

Re: [R-pkg-devel] Debugging M1mac problems

On 27 March 2021 at 17:26, Ivan Krylov wrote: | Dear R-package-devel, | | My package "albatross" doesn't contain any compiled code and has been | checked on both a POSIX-compatible system and on Windows, so I wasn't | expecting any problems after seeing it pass CRAN "pretest" checks. | Imagine

Re: [Rd] custom allocators, Valgrind and uninitialized memory

Andreas, Can you briefly describe what it is you are trying to do? In general, no R package would use valgrind directly; it is an optional debugger. Also note _Writing R Extensions_ has a few things to say about how memory destined for R object can and cannot be allocated -- I presume your

Re: [R-pkg-devel] CRAN incoming submissions and winbuilder downtime Mar 19 - Mar 20

Sorry for the noise. I was (clearly) unaware of one more message in the queue for this folder. My apologies. Looking forward to a refreshed and strengthened check farm for CRAN. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: [R-pkg-devel] CRAN incoming submissions and winbuilder downtime Mar 19 - Mar 20

Dear Uwe, CRAN processing appears to have halted completely, with packages stuck in incoming. I do not recall seeing an announcement, or a note on the site so I am assuming this was unplanned. Is there an expected resolution time? Many thanks as always for keeping the CRAN machine humming,

Bug#985898: /usr/bin/r: /usr/bin/r is not stripped

On 25 March 2021 at 20:29, Rogério Theodoro de Brito wrote: | On March 25, 2021 1:31:11 PM GMT-03:00, Dirk Eddelbuettel wrote: | > | >Howdy, | > | >On 25 March 2021 at 13:12, Rogério Brito wrote: | >| I was looking into some of my executables and discovered tha

Bug#985898: /usr/bin/r: /usr/bin/r is not stripped

Howdy, On 25 March 2021 at 13:12, Rogério Brito wrote: | I was looking into some of my executables and discovered that /usr/bin/r is | not stripped and it contains debugging info on my system: | | ,[ file /usr/bin/r ] | | /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),

Bug#985898: /usr/bin/r: /usr/bin/r is not stripped

Rock, meet hard place. The last change I made for Debian was just that: https://bugs.debian.org/968531 So I may have to close your bug report instead. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

On 24 March 2021 at 10:30, Martin Maechler wrote: | For this reason I've committed to R (the trunk, i.e., R-devel, | for R 4.1.0 in a month or so) in svn rev 80110. I just saw that via the (still extremely helpful) RSS feed of SVN changes and then pulled. You may have missed that Ivan

Re: [R-sig-Debian] Failing to install R 4.0.? on Raspian

On 24 March 2021 at 14:47, Chris Evans wrote: | I have just invested very few pennies in a Raspian machine hosted by my ISP. | | The machine tells me: | | root@www:~# cat /etc/os-release | PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" | NAME="Raspbian GNU/Linux" | VERSION_ID="10" |

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

-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

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

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 v

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

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

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

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

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

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

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

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 2

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

On 22 March 2021 at 16:57, Dirk Eddelbuettel wrote: | | On 23 March 2021 at 00:01, Ivan Krylov wrote: | | The surrounding code and | | <https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html> | | proved to be enough of an example. The following patch makes it | | po

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

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

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

(Group reply to three emails at once) On 22 March 2021 at 10:27, Balasubramanian Narasimhan wrote: | Confession: haven't done this in decades. Equally green here. | Isn't the usual way to use 'xwininfo' to figure out the information | about any X window and set a specific resource in the

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

[ I hope the Subject: is arcane enough to reduce readership to a handful :) ] Running the default window manager in the Linux distribution I am running, multiple 'windows' of the same program are usually aggregated under one icon. I typically have numerous (gnome) terminals, several top-level

Re: [Rd] boneheaded BLAS questions

On 18 March 2021 at 09:15, Tomas Kalibera wrote: | This is documented in R Admin manual, section A.3, and there is also | "configure --help". | | On my Ubuntu 20.04, using "--with-blas --with-lapack" when a BLAS/LAPACK | implementation is installed via "apt" works for me: | | with libblas3,

Re: [Rd] boneheaded BLAS questions

On 17 March 2021 at 22:53, Ben Bolker wrote: |Thanks. I know it's supposed to Just Work (and I definitely | appreciate all the work that's gone into making it Just Work 99% of the | time!). And for what it is worth, the aforementioned 'switching from within' solution is using FlexiBLAS

Re: [Rd] boneheaded BLAS questions

Ben, This stuff has worked unchanged since the 1990s when we had a _really_ far sighted fellow in Debian come up with the 'switch the links' scheme which was (and is) subsequently deployed by many numerical applications within Debian, R and e.g. Octave included. And I used this ability to

Re: [Rd] Potential improvements of ave?

On 16 March 2021 at 10:50, Martin Maechler wrote: | I vaguely remember (from Luke's docs/presentation on ALTREP) | that there are some "missing parts" here. | One of them the not-existing R level functionality, another may be | the C code below R's is.unsorted() ... maybe is.unsorted() |

Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to github hosted package

On 16 March 2021 at 06:48, Duncan Murdoch wrote: | On 16/03/2021 5:58 a.m., Chris Evans wrote: | You have 5 workflows, and their current content doesn't appear to match | the results on your actions page. Pick one, run it, and I'll see if I | can spot the reason for a failure. More

[Rd] r-devel windows gcc10-UCRT machine questions

I saw two (unchanged, long-existing) tests of main fail narrowly on this new platform (relative to the tolerance argument set). Attempting to change the tolerance if .Platform$OS.type == "windows" failed (any idea why that test would evaluate to FALSE?). Could it be that

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 9 March 2021 at 14:26, Graham Inggs wrote: | Control: tags -1 - fixed-upstream + upstream | Control: notforwarded -1 | | | >From TMB upstream [1]: | | > Digging a bit deeper I found that after calling | > | > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, ) | > | > the

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 9 March 2021 at 14:26, Graham Inggs wrote: | Control: tags -1 - fixed-upstream + upstream | Control: notforwarded -1 | | | >From TMB upstream [1]: | | > Digging a bit deeper I found that after calling | > | > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, ) | > | > the

Bug#984820: jags: Wrong homepage

On 8 March 2021 at 20:05, Davide Prina wrote: | Package: jags | Version: 4.3.0-3 | Severity: normal | | I have see that the project homepage do not respond anymore: | http://www-fis.iarc.fr/~martyn/software/jags/ Good catch. Martyn Plummer no longer works there but is now at Warwick. I'll

Re: [R-pkg-devel] Vignettes from LaTeX files.

On 7 March 2021 at 12:54, Rolf Turner wrote: | Dirk Eddelbuettel wrote: | By "in base R" do you mean that one can do this *without* invoking | the R.rsp package? Exactly. Zero added dependencies. | What I understand you to be saying is that you can add four or five | lines to a

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Hi Graham and Martin, Thanks for coming back to this, I had also meant to write to Martin this weekend. On 6 March 2021 at 19:16, Graham Inggs wrote: | Is there a bug opened for this issue with Matrix upstream? Per field Bug-Reports in DESCRIPTION, the repo (and bug tracker) are (still) at

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Hi Graham and Martin, Thanks for coming back to this, I had also meant to write to Martin this weekend. On 6 March 2021 at 19:16, Graham Inggs wrote: | Is there a bug opened for this issue with Matrix upstream? Per field Bug-Reports in DESCRIPTION, the repo (and bug tracker) are (still) at

Re: [R-pkg-devel] testing for NaN in C++ code

On 5 March 2021 at 21:07, Ben Bolker wrote: |Thanks! Now I see this is in Writing R Extensions, should have | looked more carefully ... There is also a very good (and frequently linked-to) post by Kevin on SO which lists the different ways in the C API of R, and the Rcpp wrapper which

Re: [R-pkg-devel] Vignettes from LaTeX files.

On 5 March 2021 at 15:41, Duncan Murdoch wrote: | On 05/03/2021 2:40 p.m., Henrik Bengtsson wrote: | > Thank you. Glad to hear it's useful. | > | > This plain TeX/LaTeX vignette engine is implemented using base R. If | > someone is willing to drive the efforts, I think it's not too much | >

Re: [Rcpp-devel] Passing template class as argument in Rcpp function

On 5 March 2021 at 18:44, Iñaki Ucar wrote: | Excellent. Note that the clone method was required for my use case, but it | may be superfluous for yours. It's very nice to do it straight up with the XPtr class. A variant using Rcpp Modules is offerend byy RcppAnnoy -- also templated. Dirk --

Re: [R-pkg-devel] Using data.table in a package

Martin, Both questions are FAQs. Searches at e.g. StackOverflow might have lead you to a solution (and you can search there, key is to add the tag i.e. make [r] or [data.table] part of the search term). The first one is a generic package programming question. You can use Imports: in

Re: [R-sig-Debian] I cannot install any R package on Ubuntu: help, please!

On 5 March 2021 at 04:19, Johannes Ranke wrote: | Am Donnerstag, 4. März 2021, 17:52:36 CET schrieb Valerio Villani: | > I installed R and RStudio on my PC running Ubuntu 20.04. Unfortunately, I | > cannot install any package with the install.packages() function. I tried | > many things, but

Re: [Rcpp-devel] Passing template class as argument in Rcpp function

On 4 March 2021 at 14:31, Subhomoy Ghosh wrote: | @Dirk, Thanks! I am aware of the .Call(). I can go that route depending on | how it goes. I may not have been explicit enough. Everything we do goes that route, it's just that some of the code accessing it is written for you by Rcpp Attributes.

Re: [Rcpp-devel] Passing template class as argument in Rcpp function

PS And building on top of my post and what Inaki told you, you can of course have C++ fancypants __provided the fancypants have something as for example the operator SEXP() in the Rcpp::Nullable(). In short, whatever you do, it (ultimately) has to convert to a SEXP or there is no calling from R.

Re: [R-sig-Debian] I cannot install any R package on Ubuntu: help, please!

On 4 March 2021 at 16:52, Valerio Villani wrote: | I am new to this mailing list and Linux too. Welcome! You may find this post helpful: https://stackoverflow.com/help/minimal-reproducible-example as your email is currently% unactionable. Was it a source package? Was it a binary package?

Re: [Rcpp-devel] Passing template class as argument in Rcpp function

Recall that R offers us a C language interface SEXP .Call("somename", SEXP a, SEXP b, ...); which imposes constraints on what you put there. I.e. no C++ fancypants. You can write yourself a _C_ function interface and pass your desired type as a string, or enum (i.e. int), or ... and then

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Graham, Martin, So I logged back onto the s390x box we can access. Matrix 1.13-2 does fail the factorization test when doing _R_CHECK_FORCE_SUGGESTS_=false R CMD check --no-manual \ --no-vignettes Matrix_1.3-2.tar.gz and Matrix 1.2-18 passes it. So Graham was right all-along

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Graham, Martin, So I logged back onto the s390x box we can access. Matrix 1.13-2 does fail the factorization test when doing _R_CHECK_FORCE_SUGGESTS_=false R CMD check --no-manual \ --no-vignettes Matrix_1.3-2.tar.gz and Matrix 1.2-18 passes it. So Graham was right all-along

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just on s390x) and move on. I still have not been convinced by anyone that it is an issue in package Matrix causing this. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just on s390x) and move on. I still have not been convinced by anyone that it is an issue in package Matrix causing this. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: [R-pkg-devel] Two compile questions

On 21 February 2021 at 19:52, Karim Rahim wrote: | I'm in the process of incorporating some improvements that I pulled from | github. | I am getting a warning and a note. These occur when I run | | R CMD check --as-cran fftwtools_0.9-10.tar.gz | | 1. | * checking whether package ‘fftwtools’

Bug#982465: Debian bug report 982465: dyn.load not useful for system libraries

Indeed: "Should" is the operational term here. But just pointing at packages for which I am upstream author / maintainer and Debian maintainer, we already use the other approach for RcppArmadillo, RcppEigen, RcppCCTZ, RcppDate, ... and we fudged it for BH with the empty shell r-cran-bh which

Bug#982465: Bug in r-base and r-cran-rcppparallel

severity 982465 wishlist thanks I am sorry but I simply see no bug in package r-base here. The RcppParallel maintainer tried a Debian-local modification to that CRAN package. That didn't work, and now fingers are pointed at r-base. Which is simply not the right way to go about this as package

Re: [Rcpp-devel] How to properly check if a String has only ASCII characters in Rcpp?

The whole topic is such a can of worms. It is 2021, and we just wish we had utf-8 everywhere. Sadly the OS dependence underneath rears its head here. Tomas wrote well about it: https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html "One

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

Graham, Thanks for the bug tracker follow-up which made me aware of the ongoing discussion in #665 at glmmTMB. It's frustrating to have the run around but it really looks like as I argued all along: not an issue in Matrix. Now, TMB is of course a complex package too.. Appreciate you chasing

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

Graham, Thanks for the bug tracker follow-up which made me aware of the ongoing discussion in #665 at glmmTMB. It's frustrating to have the run around but it really looks like as I argued all along: not an issue in Matrix. Now, TMB is of course a complex package too.. Appreciate you chasing

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

On 17 February 2021 at 16:58, Graham Inggs wrote: | Hi Dirk | | On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote: | > Graham: What does that bigendian box say for Sys.info()[["machine"]] ? | | The other big-endian box I tested was perotto.debian.net [*], it says: |

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

On 17 February 2021 at 16:58, Graham Inggs wrote: | Hi Dirk | | On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote: | > Graham: What does that bigendian box say for Sys.info()[["machine"]] ? | | The other big-endian box I tested was perotto.debian.net [*], it says: |

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

wnloaded_packages$ (Obviously the if above could be indentented and all that.) Graham: What does that bigendian box say for Sys.info()[["machine"]] ? Should we test for endianness instead? And then maybe try to roll up to the cause of the difference? Dirk | Best, Martin |

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

wnloaded_packages$ (Obviously the if above could be indentented and all that.) Graham: What does that bigendian box say for Sys.info()[["machine"]] ? Should we test for endianness instead? And then maybe try to roll up to the cause of the difference? Dirk | Best, Martin |

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

Martin, I have this long-running bug report against Matrix, triggered by glmmTMB on s390x. Graham has been chasing this patiently and we are now at the level of checking on a shell account on the appropriate hardware. We validated that everything does in fact "still break" with CRAN-current

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

Martin, I have this long-running bug report against Matrix, triggered by glmmTMB on s390x. Graham has been chasing this patiently and we are now at the level of checking on a shell account on the appropriate hardware. We validated that everything does in fact "still break" with CRAN-current

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 14 February 2021 at 12:00, Graham Inggs wrote: | glmmTMB upstream came up with a minimal reproducer (see forwarded bug): | | stopifnot(require("testthat"), | require("glmmTMB"), | require("lme4")) | data("Orthodont", package="nlme") | fm1 <- glmmTMB(distance ~ age +

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

On 14 February 2021 at 12:00, Graham Inggs wrote: | glmmTMB upstream came up with a minimal reproducer (see forwarded bug): | | stopifnot(require("testthat"), | require("glmmTMB"), | require("lme4")) | data("Orthodont", package="nlme") | fm1 <- glmmTMB(distance ~ age +

Re: [R-pkg-devel] Subarchitectures

On 11 February 2021 at 11:30, Balasubramanian Narasimhan wrote: | If GNU make is acceptable as a system requirement, you can get any R | configuration/runtime variable in Makevars, e.g. | | R_ARCH=$(shell $(R_HOME)/bin/Rscript -e 'cat(.Platform$r_arch)') You can switch to backticks to not

Bug#982465: Bug in r-base and r-cran-rcppparallel

On 11 February 2021 at 16:06, Johannes Ranke wrote: | > | > The documentation does not list a search behaviour for bare library | > | > names on non-Windows systems. So completely ignoring the system library | > | > paths is kind of weird. | > | | > | I can see that it looks weird - but is it

Bug#982465: Bug in r-base and r-cran-rcppparallel

On 11 February 2021 at 12:50, Johannes Ranke wrote: | Am Donnerstag, 11. Februar 2021, 12:20:33 CET schrieb Bastian Blank: | > Hi Johannes | | Hello Bastian! | | > On Thu, Feb 11, 2021 at 09:26:48AM +0100, Johannes Ranke wrote: | > > dyn.load is used in base R to load compiled code from R

Bug#982465: Bug in r-base and r-cran-rcppparallel

On 10 February 2021 at 20:35, Bastian Blank wrote: | On Wed, Feb 10, 2021 at 01:30:10PM -0600, Dirk Eddelbuettel wrote: | > Thanks for the CVE. I am happy to discuss this with R Core and one fellow in | > particular. | > Before I do so can you clarify what you think the issue is? Loa

Bug#982465: Bug in r-base and r-cran-rcppparallel

Hi Bastian, On 10 February 2021 at 20:03, Bastian Blank wrote: | Hi Dirk | | On Wed, Feb 10, 2021 at 12:18:04PM -0600, Dirk Eddelbuettel wrote: | > As for your suggested patch to R's own dynload.c: that is very well tested | > and robust system code I do not have any real int

Bug#982465: Bug in r-base and r-cran-rcppparallel

Hi Bastian, Thanks for taking the time to propose a bug report. However (and please see below) I don't think this is the way forward. There have been a lot of recent changed in RcppParallel upstream (as I lurk on the GH repo which is part of our Rcpp org), and maybe some of these things will

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Hi Graham, On 2 February 2021 at 11:32, Graham Inggs wrote: | Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665 | | After another detour via #981623, r-cran-glmmtmb is now also rebuilt. | Even with the rebuilt r-cran-glmmtmb, I still see the "gradient | function must return a

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

Hi Graham, On 2 February 2021 at 11:32, Graham Inggs wrote: | Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665 | | After another detour via #981623, r-cran-glmmtmb is now also rebuilt. | Even with the rebuilt r-cran-glmmtmb, I still see the "gradient | function must return a

[Rcpp-devel] Sorry about double and triple posts from me

I am truly sorry about sending multiple posts. I did have an issue where my mail from this machine was blocked because as a Comcast host I pass mail too was a spam blacklist so I experimented sending via alternative setups, and as R-Forge email was apparently down too for a few days never got a

[Rcpp-devel] [ANN] More Micro Releases on Rcpp Drat Repo

More micro-releases on the Rcpp-core drat: And once more new micro-releases on drat: - Rcpp 1.0.6.5 now with global Rcout and Rcerr object (if enabled at compiled), thanks once again to Inaki - RcppArmadillo 0.10.2.1.0 with upstream fixes in 10.2.1 Dirk --

Re: [Rcpp-devel] [ANN] Rcpp Micro Releases on Rcpp Drat Repo

And once more new micro-releases on drat: - Rcpp 1.0.6.5 now with global Rcout and Rcerr object (if enabled at compiled), thanks once again to Inaki - RcppArmadillo 0.10.2.1.0 with upstream fixes in 10.2.1 Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: [Rcpp-devel] [ANN] Rcpp Micro Releases on Rcpp Drat Repo

Another Rcpp release candidate for your testing pleasure: - Rcpp 1.0.6.5 with the next fine PR by Inaki allow global Rcout and Rcerr instances (using a compile-time #define to enable, so opt-in) Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#982069: /usr/local/lib/R owned by group staff even if /etc/staff-group-for-usr-local not present

On 6 February 2021 at 15:17, Sébastien Villemot wrote: | Le samedi 06 février 2021 à 08:12 -0600, Dirk Eddelbuettel a écrit : | | > # edd 03 Apr 2003 cf Section 10.1.2 of Debian Policy | > # edd 06 Feb 2021 #982069, with a nod to Python's debian/PVER-minimal.posti

Bug#982069: /usr/local/lib/R owned by group staff even if /etc/staff-group-for-usr-local not present

On 6 February 2021 at 14:57, Sébastien Villemot wrote: | Le samedi 06 février 2021 à 07:49 -0600, Dirk Eddelbuettel a écrit : | > So I now have this. Or do I need to protect /usr/local/lib/R/site- | > library too? | | You need to protect both. | | In order to simplify the code, you ca

Bug#982069: /usr/local/lib/R owned by group staff even if /etc/staff-group-for-usr-local not present

So I now have this. Or do I need to protect /usr/local/lib/R/site-library too? # edd 03 Apr 2003 cf Section 10.1.2 of Debian Policy # edd 06 Feb 2021 #982069 if [ ! -e /usr/local/lib/R ]; then if [ -f /etc/staff-group-for-usr-local ]; then if mkdir /usr/local/lib/R

Bug#982069: /usr/local/lib/R owned by group staff even if /etc/staff-group-for-usr-local not present

On 6 February 2021 at 10:04, Sébastien Villemot wrote: | Package: r-base-core | Version: 3.5.2-1 That is two+ years behind (3.5.0 released April 2018, 3.6.0 in April 2019, 4.0.0 last year -- and 4.1.0 soon). | Severity: normal | | Hi Dirk, | | The /usr/local/lib/R directory (and its

<    5   6   7   8   9   10   11   12   13   14   >