Hi Dirk,
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 uninitialized memory and the CRAN team asked me to tackle
these.
These errors are false
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
On 3/26/21 10:01 AM, Murphy, Alan E wrote:
Hi Hervé,
I bumped the version again to get a new check run but unfortunately the
first error I had on Windows has now happened on the Linux machine. I
have no idea why this is happening?
Downloading the data to the local ExperimentHub cache seems
Hi Herv�,
I bumped the version again to get a new check run but unfortunately the first
error I had on Windows has now happened on the Linux machine. I have no idea
why this is happening?
Also, the Windows run timed out again. With the two runs, has it been noted by
other developers that the
Hi Jim,
Workflow builds are back (Linux only for now):
https://bioconductor.org/checkResults/3.13/workflows-LATEST/
Cheers,
H.
On 3/24/21 12:31 PM, James Perkins wrote:
Thanks for the info Hervé,
Has the workflow build been affected? There appears to have been no
build since last
On 3/26/21 1:09 AM, Murphy, Alan E wrote:
Hey Hervé,
Bumping the version did stop the error but now I'm getting time out
errors for both Mac and Windows. This is strange considering the code
didn't change and passed the mac checks last time without a timeout
issue. Is there much variability
Another idea for the second option. Instead of including the Valgrind headers,
the following could be enough:
#if __has_include()
#include
#else
#define VALGRIND_MAKE_MEM_DEFINED(_qzz_addr,_qzz_len) \
do { \
(_qzz_addr);
Recently I contributed some changes to the pkgdown and downlit packages.
The new pkgdown changes require the new downlit changes in order to
work. These are still both only on Github, in r-lib/pkgdown and
r-lib/downlit respectively.
pkgdown lists downlit in the Imports section of
> Duncan Murdoch
> on Thu, 25 Mar 2021 10:41:46 -0400 writes:
> On 25/03/2021 9:18 a.m., Dirk Eddelbuettel wrote:
>>
>> 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
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
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,
Hey Herv�,
Bumping the version did stop the error but now I'm getting time out errors for
both Mac and Windows. This is strange considering the code didn't change and
passed the mac checks last time without a timeout issue. Is there much
variability on these machines across R CMD Check runs?
Hi,
In my package bettermc, I use a custom allocator, which hands out already
defined/initialized memory (mmap of a POSIX shared memory object).
If my code is run in R which was configured --with-valgrind-instrumentation >
0, Valgrind will (correctly) complain about uninitialized memory being
13 matches
Mail list logo
