I see the problem when I compile the C++ code on Ubuntu 20.04 and the
latest R-devel with
C++ compiler: ‘g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
If I change all the unadorned 'abs' calls in src/nn_matchC_vec.cpp with the
prefix 'std::' the problem goes away.
-Bill
On Thu, May 11, 2023 at 11:
checking whether package ‘epanet2toolkit’ can be installed ... WARNING
Found the following significant warnings:
report.c:1466:37: warning: argument to ‘sizeof’ in ‘snprintf’ call is the
same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]
Even Microsoft added snprintf to Visual C++ in 2015 (not that that matters
for R).
-Bill
On Sat, Jan 21, 2023 at 2:47 AM Duncan Murdoch
wrote:
> On 21/01/2023 5:33 a.m., Holger Hoefling wrote:
> > Hi,
> >
> > thanks for the tip! Is that available everywhere or do I need to set
> > compiler requ
Setting the locale to "C" (or perhaps some other non-UTF-8 locale) will
show the BOM bytes. E.g., on Windows I get:
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.utf8;LC_CTYPE=English_United
States.utf8;LC_MONETARY=English_United
States.utf8;LC_NUMERIC=C;LC_TIME=English_United States.ut
You could add an 'envir' argument to parse_args() and do your eval(...,
envir=envir) stuff inside parse_args(). Then change
call[[1]] <- quote(pense:::parse_args)
args <- eval.parent(call)
to
call[[1]] <- quote(parse_args)
call$envir <- parent.frame()
args <- eval(call)
[That code is
> Yes, set.seed() cannot accept .Random.Seed as an input; it can only take
a single integer.
If I recall correctly, S-plus's set.seed() would accept a .Random.seed
value as an input. It did some basic validation checks on it and set it as
the current .Random.seed. I don't recall the name of the
Have you tried changing the \x's in that file with \u's?
> qx <- c("\xf6", "\xf8", "\xdf", "\xfc")
> Encoding(qx) <- "latin1"
> qu <- c("\uf6", "\uf8", "\udf", "\ufc")
> Encoding(qu)
[1] "UTF-8" "UTF-8" "UTF-8" "UTF-8"
> qx == qu
[1] TRUE TRUE TRUE TRUE
(charToRaw shows that qu and qx are not byt
The byte code attached to each function in a package can be surprisingly
large. E.g., the byte code for the c. 300 line function Matrix:::replTmat
seems to be c. 4.5 times the size of the raw code:
> object.size(Matrix:::replTmat) /
object.size(as.function(as.list(Matrix:::replTmat)))
5.5 bytes
Can you tell if the failure to download was due to a Solaris-specific issue
or due to the Solaris test machine not being fully connected to the
internet?
-Bill
On Fri, Sep 24, 2021 at 7:50 AM Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
> Hi All:
>
> I am getting dinged again on CR
EXIT_FAILURE );
>
> }
>
> s->data[0]='\0';
>
> s->dim=size;
>
> s->len=0;
>
>
>
> My comment is indeed sloppy but the first byte is initialised to zero and
> the rest is used for writing only
&
I ran the tests of rbibutils-2.2.2, using the latest devel version of R
configured to use valgrind, with
R --debugger=valgrind --debugger-args=--track-origins=yes --quiet -e
'testthat::test_package("rbibutils")'
I saw a lot of 'conditional jump depends on uninitialized value' errors:
==27280== C
I think the problem with RPostgreSQL/sec/RS-DBI.c comes from some changes
to Defn.h and Rinternals.h in RHOME/include that Luke made recently
(2021-07-20, svn 80647). Since then the line
#define s_object SEXPREC
in Rdefines.h causes problems. Should it now be 'struct SEXPREC'?
-Bill
On Thu,
I think the stack trace is omitting the initial underscore in the symbol
name:
> c++filt
_ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Rcpp::CppClass::CppClass(Rcpp::Module*, Rcpp::class_Base*,
std::__cxx11::basic_string,
std::allocator >&)
un 4, 2021 at 8:41 AM Bill Dunlap wrote:
> The offending line in path_coeff seems to be
>betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
> where i is a single integer, nvar is 15, and the right hand side is a 14
> by 14 matrix. What is this line trying to do? Did it ever give t
The offending line in path_coeff seems to be
betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
where i is a single integer, nvar is 15, and the right hand side is a 14 by
14 matrix. What is this line trying to do? Did it ever give the correct
result?
-Bill
On Fri, Jun 4, 2021 at 7:39 AM B
That log file includes the line
using R Under development (unstable) (2021-05-30 r80413)
and later says
The error most likely occurred in:
> ### Name: path_coeff
> ### Title: Path coefficients with minimal multicollinearity
> ### Aliases: path_coeff path_coeff_mat
>
> ### ** Examples
>
> ## N
cli does export col_red - did you omit the 'r' when calling it from your
package or vignette?
On Thu, Apr 29, 2021 at 9:29 AM Danielle Maeser wrote:
> Hi Duncan,
>
> I really appreciate your response. Unfortunately, I am still receiving the
> error below.
>
> If anyone has ideas, I'd appreciate
Has there been any thought given to an alternative to globalVariables that
would flag certain arguments to certain functions as being evaluated in a
non-standard way. E.g.,
usesNSE(FUN="with.default", ARGUMENTS="expr")
usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
usesNSE
Have you run the offending examples under valgrind on Linux with
gctorture(TRUE)?
-Bill
On Thu, Apr 1, 2021 at 11:51 AM 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.or
I haven't followed all the code branches in tools:::.check_packages(),
but some of them use --vanilla when running the R subprocess that does
the checking. I think that would mean that libraries in ~/R would not
be in the search path.
-BIll
On Mon, Mar 8, 2021 at 8:45 AM Thierry Onkelinx
wrote:
the F77_CALL
> and declare the subroutines' respective variables as
> integer(kind=c_int)... Was that your suggestion? Or is there an easier way?
>
> Thanks
>
> Paul
>
> On 2/17/21 9:48 PM, Bill Dunlap wrote:
> > I suspect your problem is that, at least with the rec
I suspect your problem is that, at least with the recent gnu
compilers, the Fortran 'c_logical' maps to the C _Bool, not the C int.
-Bill
On Wed, Feb 17, 2021 at 11:38 AM Paul Schmidt-Walter
wrote:
>
> Dear Team,
>
> My package 'LWFBrook90R' (https://github.com/pschmidtwalter/LWFBrook90R)
> was
Try using their official names, Rf_ScalarReal, Rf_eval, Rf_install, etc.
You may have #defined R_NO_REMAP in code that you did not show us.
-Bill
On Tue, Jan 5, 2021 at 1:42 PM Oliver Madsen
wrote:
> This is maybe better suited for Rcpp-devel or another mailing list. If so,
> I apologize. :-)
>
23 matches
Mail list logo
