Hi Murray,
On 4 March 2024 at 07:03, Murray Efford wrote:
| Dirk
| Thanks for a very helpful reply. I'll simplify my return values.
|
| I mentioned Intel with rhub2 in my earlier post here, but I'm sorry
| that was somewhat buried. Debugging is somewhere between painful and
| impossible when
Dirk
Thanks for a very helpful reply. I'll simplify my return values.
I mentioned Intel with rhub2 in my earlier post here, but I'm sorry
that was somewhat buried. Debugging is somewhere between painful and
impossible when my only check is submitting to CRAN!
Also, I had tried valgrind, but that
And "beauty" (ahem) of discussion scattered over two mailing lists: I now see
you have a testbed via rhub2 (good) even though it does not reproduce (hm...).
So you could still try the suggested simplication.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 3 March 2024 at 20:47, Murray Efford wrote:
| A couple of days ago I posted on R-package-devel about a mysterious
| segfault from R CMD checks of my package secrdesign (see
| https://CRAN.R-project.org/package=secrdesign, and
| https://github.com/MurrayEfford/secrdesign) The issue rises only
Hi
A couple of days ago I posted on R-package-devel about a mysterious
segfault from R CMD checks of my package secrdesign (see
https://CRAN.R-project.org/package=secrdesign, and
https://github.com/MurrayEfford/secrdesign) The issue rises only on
CRAN and only with the Intel(R) oneAPI DPC++/C++