Re: [R-pkg-devel] visible binding for '<<-' assignment

[William Dunlap]

> Is there a reason that this slightly more explicit
> version [assign(envir=.GlobalEnv)] wouldn't work?

https://cran.r-project.org/web/packages/policies.html
- Packages should not modify the global environment (user’s workspace).

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Sep 3, 2020 at 2:36 PM Ben Bolker  wrote:
>
>   Is there a reason that this slightly more explicit version wouldn't work?
>
> pali_string_fix <- function() {
>  assign("pali_alphabet", stringi::stri_unescape_unicode(pali_alphabet),
> .GlobalEnv)
> }
>
>
> On 9/3/20 5:25 PM, Dan Zigmond wrote:
> > Thanks, Gabor. I want these to be easily available to package users though
> > – that's why they are in the package. So I would rather not "hide" them in
> > a local environment. This is fundamentally a data package, so access to
> > this data is the primary point of installing it.
> >
> > Is there any other solution?
> >
> >   Dan
> >
> > .
> > --
> > Dan Zigmond
> > d...@shmonk.com
> >
> >
> >
> > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  wrote:
> >
> >> Store the cached data in an environment within the package:
> >>
> >> pali_data <- new.env(parent = emptyenv())
> >>
> >> pali_string_fix <- function() {
> >>pali_data$alphabet <-
> >>   stringi::stri_unescape_unicode(pali_alphabet)
> >> ...
> >> }
> >>
> >> Gabor
> >>
> >> On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond  wrote:
> >>>
> >>> Hi, all. I am developing a package that includes some global variables.
> >>> Because these are non-ASCII, I have escaped them. But then because these
> >>> are difficult to read, I want to provide an easy way for users to
> >> unescape
> >>> all of them up front. Thus I have code like to create and save the data
> >> in
> >>> global variables in one file:
> >>>
> >>> pali_vowels <-
> >>>c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
> >>> pali_consonants <-
> >>>c("k", "kh", "g", "gh", "\u1e45",
> >>>  "c", "ch", "j", "jh", "\u00f1",
> >>>  "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
> >>>  "t", "th", "d", "dh", "n",
> >>>  "p", "ph", "b", "bh", "m",
> >>>  "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43")
> >>> pali_alphabet <-c(pali_vowels, pali_consonants)
> >>> use_data(pali_alphabet, overwrite = TRUE)
> >>>
> >>> and then I try to export a function like this in another file:
> >>>
> >>> pali_string_fix <- function() {
> >>>pali_alphabet <<-
> >>>   stringi::stri_unescape_unicode(pali_alphabet)
> >>># Several more of these...
> >>>}
> >>>
> >>> The idea is that users can run pali_string_fix() once when they load the
> >>> package and then they won't need to deal with all the Unicode escape
> >>> sequences after that.
> >>>
> >>> However, this is getting rejected by the CRAN checks with the message:
> >>>
> >>> * checking R code for possible problems ... [4s] NOTE
> >>> pali_string_fix: no visible binding for '<<-' assignment to
> >>>'pali_alphabet'
> >>>
> >>> I'm guessing this is because the data and the function are defined in
> >>> different files, so even though those globals are defined by my package,
> >>> that isn't obvious when the check is run on this code.
> >>>
> >>> Does anyone have advice for how to fix this?
> >>>
> >>>   Dan
> >>>
> >>> .
> >>> -
> >>> Dan Zigmond
> >>> d...@shmonk.com
> >>>
> >>>  [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Formatting .Rbuildignore

[William Dunlap]

I just tried this out with R-4.0.2 on Linux and it looks like
.Rbuildignore does not treat lines with '#'s as comments.  E.g.,

% mkdir test test/inst
% touch 'test/inst/#octothorp.txt' 'test/inst/normal.txt'
% echo > test/DESCRIPTION 'Package: test\nVersion: 0.1\nTitle:
test\nDescription: A test of .Rbuildignore'
% touch test/NAMESPACE
% R CMD build test > /dev/null

% tar ztf test_0.1.tar.gz | grep '\.txt$'
test/inst/#octothorp.txt
test/inst/normal.txt
% echo '#.*[.]txt' > test/.Rbuildignore
% R CMD build test > /dev/null

% tar ztf test_0.1.tar.gz | grep '\.txt$'
test/inst/normal.txt

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Mon, Aug 17, 2020 at 9:47 AM Ivan Krylov  wrote:
>
> On Mon, 17 Aug 2020 15:56:07 +0200
> Thierry Onkelinx  wrote:
>
> > Can we add blank lines in .Rbuildignore? Or lines with only comments
> > (line starting with #)?
>
> .Rbuildignore is not documented [1] to allow comments, but the
> current implementation does skip empty lines [2] since 2010 [3]
> (otherwise empty regular expressions would match all file names).
>
> It could be possible to get away with comment lines, since the
> resulting regular expressions are unlikely to ever match anything, but
> it would cost CPU cycles to match every file name against every
> regular expression, and some regular expressions may turn out to be
> really expensive on some inputs [4].
>
> I think that it's best not to try to add comments to .Rbuildignore, and
> to avoid blank lines unless not having them becomes really inconvenient.
>
> --
> Best regards,
> Ivan
>
> [1]
> https://cran.r-project.org/doc/manuals/R-exts.html#Building-package-tarballs
>
> [2]
> https://github.com/wch/r-source/blob/9d13622f41cfa0f36db2595bd6a5bf93e2010e21/src/library/tools/R/build.R#L85
>
> [3]
> https://github.com/wch/r-source/commit/b2065b2c36235b876977e405f567afec6ab644b3
>
> [4] https://en.wikipedia.org/wiki/ReDoS
>
> __
> 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

Re: [R-pkg-devel] Package can't be imported with Suggests

[William Dunlap]

You might make a second package that depends only on nimble and your
main package can then suggest that second package and JAGS.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Aug 5, 2020 at 3:36 PM Simon Bonner  wrote:
>
> Hi all,
>
> I’m wondering if someone an offer advice on a problem I’m facing in 
> developing a package.
>
> My package essentially generates code and formats data for one of two MCMC 
> sampling engines, JAGS accessed via rjags or nimble (a native R package), 
> calls the engines, and then provides functions to access the results. Since 
> only one of the engines is needed I would like to include rjags and nimble in 
> Suggests in the DESCRIPTION and use requireNamespace() to load the 
> appropriate package when its functionality is needed.
>
> Unfortunately, nimble will not work with this mechanism. It relies on a 
> complex mechanism to compile C++ code to run the sampler, and some of the 
> functions cannot be found when the package is loaded in this way. I’ve been 
> in touch with the maintainers and they are aware of the issue but the current 
> fix is to include the package under Depends. However, this forces a user to 
> install nimble (which itself requires compiling lengthy C++ code) even if the 
> user intends to run the sampler in JAGS.
>
> I thought I’d solved the problem by including nimble in Suggests and then 
> loading it via library() so that all of its functions are attached. This 
> works, but produces a note during the check:
> ❯ checking dependencies in R code ... NOTE
>   'library' or 'require' call to ‘nimble’ in package code.
> Please use :: or requireNamespace() instead.
> See section 'Suggested packages' in the 'Writing R Extensions' manual
>
> What is the recommendation?
>
> I see two options:
>
>
>   1.  Include nimble in Depends and force user to install it.
>   2.  Ignore the note and explain the problem when I resubmit to CRAN.
>
> Am I missing anything?
>
> Thanks in advance!
>
> Simon
>
>
>
>
>
> Simon Bonner
> Assistant Professor of Environmetrics
> Department of Statistical and Actuarial Sciences
> University of Western Ontario
>
> Office: Western Science Centre rm 276
>
> Email: sbonn...@uwo.ca | Telephone: 519-661-2111 
> x88205 | Fax: 519-661-3813
> Twitter: @bonnerstatslab | Website: http://simon.bonners.ca/bonner-lab/wpblog/
>
>
> [[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

Re: [R-pkg-devel] Error in CHECK caused by dev.off()

[William Dunlap]

R-4.0 introduced a new function, tools::R_user_dir(package, which),
where which is one of "data", "config", and "cache".  It gives
standard directory names in which to place package-and-user-specific
files which you want to last longer than one R session.

I suppose you will still have to ask the user if it is ok to use those
directories, but you might want to put your log files in one of them
instead of in ~/ itself.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Jul 23, 2020 at 2:15 PM Helmut Schütz  wrote:
>
> Hi Dirk,
>
> Dirk Eddelbuettel wrote on 2020-07-23 15:16:
> > Helmut,
> >
> > For previous uploads you affirmed that you read the CRAN Repository Policy
> > which states
> >
> >   [...]
> >
> > Your package appears to violate that requirement.
>
> As I wrote previously the statement continues with
> "Limited exceptions may be allowed in interactive sessions if the
> package obtains confirmation from the user."
>
> I'm not a native speaker of English but for me "should not write" !=
> "must not write".
>
> >   I would fix the package.
>
> I removed the automatic switch to "~/" if no path is given. As before I
> recommend in the man-pages to give the full path. However, I _still_
> state that "~/" _can_ be used for convenience.
> The package is used in a regulated environment. The output file contains
> an entire audit-trail (name of the user and system, version and date of
> the OS, R, all packages, functions used, time of execution, blablah). If
> the package would write to tempdir() I would have to add a warning in
> bold font of every man-page like "Execute the command tempdir() to find
> out where your result files reside. Copy the files to a safe location
> before you quit the R-session. If you fail to do so, your results will
> be lost."
>
> Off topic: I don't like it that on Windows tempdir is located at
> "C:/Users/{Username}/AppData/Local/Temp/Rtmp..." I strictly separate my
> OSes (on C), software (on D), data (on E), backups (on F). Writing to
> the system disk is not what I prefer. However, in my installation "~/"
> resolves to "E:/Users/{Username}/Documents/"...
>
> --
> Ing. Helmut Schütz
> BEBAC – Consultancy Services for
> Bioequivalence and Bioavailability Studies
> Neubaugasse 36/11
> 1070 Vienna, Austria
> T +43 1 2311746
> M +43 699 10792458
> E helmut.schu...@bebac.at
> W https://bebac.at/
> C https://bebac.at/Contact.htm
> F https://forum.bebac.at/
> GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209
> GDPR https://bebac.at/Data-Protection.htm
>
> __
> 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

Re: [R-pkg-devel] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

[William Dunlap]

With gcc 8.3.0, gfortran 8.3.0, and ld 2.33.1 from the mingw64 part of
rtools40 on Windows, if I misdefine the typedef FC_LEN_T and use the
-flto flag I get the sort of error messages that you report.

c:\tmp\fortran>cat main.c
#include 
#include 

#ifdef USE_INT
typedef int FC_LEN_T;
#endif
#ifdef USE_LONG
typedef long int FC_LEN_T;
#endif
#ifdef USE_LONG_LONG
typedef long long int FC_LEN_T;
#endif

extern void sub_(char* word, double *ret, FC_LEN_T word_len);

int main(int argc, char* argv[])
{
if (argc == 2) {
double ret = 3. ;
FC_LEN_T word_len = strlen(argv[1]);
sub_(argv[1], , word_len);
printf("sizeof(FC_LEN_T)=%d, ret=%g\n", (int)(sizeof(FC_LEN_T)), ret);
return 0;
} else {
return -1;
}
}

c:\tmp\fortran>gcc  -flto -DUSE_INT main.c sub.f -lgfortran
main.c:14:13: warning: type of 'sub_' does not match original
declaration [-Wlto-type-mismatch]
 extern void sub_(char* word, double *ret, FC_LEN_T word_len);
 ^
sub.f:1:1: note: type mismatch in parameter 3
   subroutine sub(word, ret)
 ^
sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
sub.f:1:1: note: 'sub' was previously declared here
sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used

c:\tmp\fortran>gcc  -flto -DUSE_LONG main.c sub.f -lgfortran
main.c:14:13: warning: type of 'sub_' does not match original
declaration [-Wlto-type-mismatch]
 extern void sub_(char* word, double *ret, FC_LEN_T word_len);
 ^
sub.f:1:1: note: type mismatch in parameter 3
   subroutine sub(word, ret)
 ^
sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
sub.f:1:1: note: 'sub' was previously declared here
sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used

c:\tmp\fortran>gcc  -flto -DUSE_LONG_LONG main.c sub.f -lgfortran


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Mon, Jul 6, 2020 at 4:39 PM Pierre Lafaye de Micheaux
 wrote:
>
> Hello Bill,
>
> Thank you for your insight.
>
> First, my impression, is that the problem comes from how I declare the type 
> of the function itself (and not its parameters), since the first (and only 
> warning they seen on the CRAN) message is:
>
> 
> myzhpevx.cpp:13:16: warning: type of ‘zhpevx_’ does not match original 
> declaration [-Wlto-type-mismatch]
>void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
> 
>
> What I did is the following:
>
> 
> void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
>   const int *n, Rcomplex *ap, const double *vl,
>   const double *vu, const int *il, const int *iu,
>   const double *abstol, int *m, double *w,
>   Rcomplex *z, const int *ldz, Rcomplex *work, double *rwork,
>   int *iwork, int *ifail, int *info,
>   FC_LEN_T jobz_len,  FC_LEN_T range_len,  FC_LEN_T uplo_len);
>
>  char cjobz[2];
>  strncpy(cjobz, jobz[0], 1);
>  cjobz[1] = '\0';
>  char crange[2];
>  strncpy(crange, range[0], 1);
>  crange[1] = '\0';
>  char cuplo[2];
>  strncpy(cuplo, uplo[0], 1);
>  cuplo[1] = '\0';
>
>  F77_CALL(zhpevx)(cjobz, crange, cuplo, [0], ap, [0], [0], [0], 
> [0], [0], [0],
>   w, z, [0], work, rwork, iwork, ifail, [0], strlen(cjobz), 
> strlen(crange), strlen(cuplo));
> 
>
> Do you see anything wrong with the above?
>
> Thank you
>
> Best
> Pierre
>
> 
> From: William Dunlap 
> Sent: Tuesday, 7 July 2020 08:36
> To: Pierre Lafaye de Micheaux 
> Cc: Ivan Krylov ; r-package-devel@r-project.org 
> 
> Subject: Re: [R-pkg-devel] warning: type of ‘zhpevx_’ does not match original 
> declaration [-Wlto-type-mismatch]
>
> Have you tried what is recommended in
> https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
> ?
>
> 
> For arguments of CHARACTER type, the character length is passed as a
> hidden argument at the end of the argument list. For deferred-length
> strings, the value is passed by reference, otherwise by value. The
> character length has the C type size_t (or INTEGER(kind=C_SIZE_T) in
> Fortran). Note that this is different to older versions of the GNU
> Fortran compiler, where the type of the hidden character length
> argument was a C int. In order to retain compatibility with older
> versions, one can e.g. for the following Fortran procedure
>
> subroutine fstrlen (s, a)
>character(len=*) :: s
>integer :: a
>print*, len(s)
> end subroutine fstrlen
>
> define the corresponding C prototype as follows:
>
> #if __GNUC__ > 7
> typedef size_t fortran_charlen_t;
> #else
> typedef int fortran_charlen_t;
> #endif
>
> void fstrlen_ (char*, int*, fortran_charlen_t);
>
> In order to avoid such compiler-specific details, for new code it

Re: [R-pkg-devel] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

[William Dunlap]

Have you tried what is recommended in
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
?


For arguments of CHARACTER type, the character length is passed as a
hidden argument at the end of the argument list. For deferred-length
strings, the value is passed by reference, otherwise by value. The
character length has the C type size_t (or INTEGER(kind=C_SIZE_T) in
Fortran). Note that this is different to older versions of the GNU
Fortran compiler, where the type of the hidden character length
argument was a C int. In order to retain compatibility with older
versions, one can e.g. for the following Fortran procedure

subroutine fstrlen (s, a)
   character(len=*) :: s
   integer :: a
   print*, len(s)
end subroutine fstrlen

define the corresponding C prototype as follows:

#if __GNUC__ > 7
typedef size_t fortran_charlen_t;
#else
typedef int fortran_charlen_t;
#endif

void fstrlen_ (char*, int*, fortran_charlen_t);

In order to avoid such compiler-specific details, for new code it is
instead recommended to use the ISO_C_BINDING feature.

Note with C binding, CHARACTER(len=1) result variables are returned
according to the platform ABI and no hidden length argument is used
for dummy arguments; with VALUE, those variables are passed by value.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jul 6, 2020 at 3:13 PM Pierre Lafaye de Micheaux
 wrote:
>
> Dear Ivan,
>
> Thank you very much for your response.
>
> I do not have more information than the one I gave in my previous email. (And 
> on top of that, the computer I was using with Debian SID, a recent version of 
> gfortran and the last version of R-devel, just broke.)
>
> My problem is that the CRAN team won't accept to publish my package until 
> this WARNING problem is solved. And because I am unable to observe the 
> warning on my side (I could not with the desktop that just broke, and I still 
> can't with my current laptop with Debian 10), I have no clue on how to 
> suppress this warning.
>
> Thank you in advance for any other advice.
>
> Best regards,
> Pierre
> 
> From: Ivan Krylov 
> Sent: Tuesday, 7 July 2020 06:11
> To: Pierre Lafaye de Micheaux 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] warning: type of ‘zhpevx_’ does not match original 
> declaration [-Wlto-type-mismatch]
>
> On Fri, 3 Jul 2020 00:15:27 +
> Pierre Lafaye de Micheaux  wrote:
>
> >Found the following significant warnings:
> >myzhpevx.cpp:13:23: warning: type of _zhpevx__ does not match
> > original declaration [-Wlto-type-mismatch]
>
> I managed to reproduce the warning on R-devel r78607 built with
> --enable-lto using gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1):
>
> myzhpevx.cpp:13:16: warning: type of ‘zhpevx_’ does not match original 
> declaration [-Wlto-type-mismatch]
>void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
> ^
> zhpevx.f:232:7: note: type mismatch in parameter 20
>SUBROUTINE zhpevx( JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU,
>^
> zhpevx.f:232:7: note: type ‘int’ should match type ‘size_t’
> /usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h:216:23: note: the 
> incompatible type is defined here
>  typedef __SIZE_TYPE__ size_t;
>^
> zhpevx.f:232:7: note: ‘zhpevx’ was previously declared here
>SUBROUTINE zhpevx( JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU,
>^
>
> Do you have access to the notes produced by the compiler in addition
> to the warnings? Do they spell the same difference?
>
> If yes, the warning is likely to be safe to ignore. m4/R.m4 notes that,
> while gfortran < 8 uses int instead of size_t for hidden size arguments,
> it doesn't make a practical difference.
>
> --
> Best regards,
> Ivan
>
> [[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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[William Dunlap]

On Linux you can use 'ltrace' to get a list of all the environment
variables that R looks up.  E.g., do the following in 'script' so all the
output is stored in a file ('typescript') and later look around in it for
the getenv calls.

$ R-devel --debugger=ltrace --debugger-args="-f -e getenv"
...
[pid 25055] libR.so->getenv("R_HOME")
 = "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("R_TRANSLATIONS")
 = nil
[pid 25055] libR.so->getenv("R_PLATFORM")
 = nil
...
> tools:::.check_packages(c("testFixup_0.1.tar.gz", "--as-cran"))[pid
25055] libR.so->getenv("_R_NS_LOAD_")   =
nil
[pid 25055] libR.so->getenv("_R_CHECK_ELAPSED_TIMEOUT_")
  = nil
[pid 25055] libR.so->getenv("R_CHECK_ENVIRON")
  = nil
[pid 25055] libreadline.so.6->getenv("HOME")
  = "/homes/bill"
[pid 25055] libR.so->getenv("_R_CHECK_TIMINGS_")
  = nil
[pid 25055] libR.so->getenv("R_ENABLE_JIT")
 = nil
[pid 25055] libR.so->getenv("R_HOME")
 = "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("_R_CHECK_USE_INSTALL_LOG_")
  = nil
[pid 25055] libR.so->getenv("_R_CHECK_SUBDIRS_NOCASE_")
 = nil
[pid 25055] libR.so->getenv("_R_CHECK_ALL_NON_ISO_C_")
  = nil
... hundreds more lines ...
> q("no")


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Jul 2, 2020 at 7:24 AM Jan Gorecki  wrote:

> Thank you Gabor
>
> On Thu, Jul 2, 2020 at 10:20 AM Gábor Csárdi 
> wrote:
> >
> > You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
> > use R-devel.
> >
> > Alternatively, and you don't need R-devel for this, you can run R CMD
> > --html INSTALL on your package, and then look for messages that
> > contain "treated as a topic", e.g.
> >
> > curl_fdshtml
> > Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
> > link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
> > treated as a topic
> >
> > Gabor
> >
> >
> > On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki 
> wrote:
> > >
> > > Hi,
> > > What is the recommended way to test for those issues locally?
> > > If it is tested during cran submission, then seems reasonable to be
> enabled just by --as-cran switch. Is it?
> > > Thanks
> > >
> > > On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, 
> wrote:
> > >>
> > >> Thank you!
> > >>
> > >> -Original Message-
> > >> From: Gábor Csárdi 
> > >> Date: Tuesday, June 16, 2020 at 4:32 PM
> > >> To: Wayne Oldford 
> > >> Cc: List r-package-devel 
> > >> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
> > >>
> > >> This is how to look up the filename. The first "sp" is the topic
> name,
> > >> the second is the package name.
> > >>
> > >> > help("sp", "sp")[[1]]
> > >> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
> > >>
> > >> So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}
> > >>
> > >> Gabor
> > >>
> > >> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <
> rwoldf...@uwaterloo.ca> wrote:
> > >> >
> > >> > Hi
> > >> >
> > >> > I got caught by this new test this week in trying to push an
> updated release of the loon package to CRAN.
> > >> >
> > >> > By following this thread, I corrected my cross-references to
> external packages but I got stymied by
> > >> > the one I hoped to give to the  "sp" package for Spatial data
> > >> >
> > >> > _
> > >> >
> > >> > Here is the history:
> > >> >
> > >> > I tried
> > >> >\link[sp:sp]{sp}
> > >> > which failed here:
> > >> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log
> >
> > >> > Status: 1 WARNING
> > >> >
> > >> >
> > >> > That was meant to correct an earlier attempt (it did for other
> links to "scales" for example) where I had tried
> > >> >   \link[sp]{sp}
> > >> > and  failed here:
> > >> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log
> >
> > >> > Status: 1 WARNING
> > >> >
> > >> >
> > >> > So to complete the possibilities as I understand them,  I just
> now tried
> > >> >\link{sp}
> > >> > which, as might be expected, failed here:
> > >> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log
> >
> > >> > Status: 1 WARNING
> > >> > As expected, error here was different:  "Missing  link"  as
> opposed to "Non-file package-anchored link"
> > >> >
> > >> > _
> > >> >
> > >> >
> > >> > I am not sure whether I have missed a subtlety in WRE or that
> the peculiar circumstance
> > >> > where the package, the topic, and the file name are all
> identical (sp) is some weird boundary case.
> > >> >
> > >> > Without further advice, I think I am just going to remove the
> link to "sp".
> > >> > It really is just a courtesy link to the package description
> 

Re: [R-pkg-devel] Forward function call

[William Dunlap]

Use
   Call[[1]] <- quote(survival::coxph)

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jun 8, 2020 at 12:12 PM Göran Broström 
wrote:

> Hello,
>
> the function 'coxreg' in my package 'eha' is often just a wrapper for
> 'coxph' in survival, so I have code like
>
>  if (cox.ph){
>  Call <- match.call()
>  Call[[1]] <- as.name("coxph")
>  fit <- eval.parent(Call)
>  return(fit)
>  }
>
> which works since eha depends on survival. Now I am thinking of changing
> Depends to Imports, and I would like to change the code to
>
>  if (cox.ph){
>  Call <- match.call()
>  Call[[1]] <- as.name("survival::coxph")
>  fit <- eval.parent(Call)
>  return(fit)
>  }
>
> but this doesn't work, because the function name is turned into
> `survival::coxph` (with the backticks) and the evaluation fails.
>
> How can I solve this?
>
> Thanks, G,
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Error creating union class: object ‘.__C__compMatrix’ not found

[William Dunlap]

% R-devel --vanilla --quiet
> library(Matrix)
> setClassUnion("mMatrix", c("Matrix", "matrix"))
Error in get(cname, envir = cwhere, inherits = FALSE) :
  object '.__C__compMatrix' not found
Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
  unable to create union class:  could not set members "Matrix"
> sessionInfo()
R Under development (unstable) (2020-04-07 r78175)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.6 LTS

Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblasp-r0.2.18.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] Matrix_1.2-18

loaded via a namespace (and not attached):
[1] compiler_4.1.0  grid_4.1.0  lattice_0.20-41

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Apr 8, 2020 at 7:35 AM Martin Maechler 
wrote:

> > renozao
> > on Mon, 30 Mar 2020 21:20:43 + writes:
>
> > Hi,
> > when R CMD check is run under R-devel (2020-03-29 r78108) I get the
> following error at installation:
>
> > Error in get(cname, envir = cwhere, inherits = FALSE) :
> > object ‘.__C__compMatrix’ not found
> > Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
> > unable to create union class:  could not set members "Matrix"
>
> > This does not happen on R 3.6.3.
>
> > I tried with Matrix listed in Depends but I still get the same error.
>
> > Is this linked to some changes in union classes or the Matrix
> package?
>
> > Thank you.
>
> > Bests,
> > Renaud
>
> Hi Renaud,
> One reason you got no response here, is because we don't even
> know about which package you are talking.
>
> So there's nothing, anybody can reproduce from your posting.
>
> There have been changes in R's dealing with class unions etc,
> notably even *relating* to an earlier bug report on class unions
> exactly for such a case which was *triggered* when people built
> on such Matrix classes.
>
> But we would really want to be able to reproduce what you are seeing..
>
> Best regards,
> Martin Maechler
>
> ETH Zurich, R Core Team *and* maintainer("Matrix")
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Error creating union class: object ‘.__C__compMatrix’ not found

[William Dunlap]

Use trace() to get a bit more detail - .__C_compMatrix is looked for in the
wrong environment with inherits=FALSE.

> setClassUnion("mMatrix", c("Matrix", "matrix"))
Tracing get(name, envir = env) on entry
x=".AllMTable", envir="", topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".MTable", envir="", topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".AllMTable", envir="", topenv="", inherits=TRUE
Tracing get("#HAS_DUPLICATE_CLASS_NAMES", envir = .classTable) on entry
x="#HAS_DUPLICATE_CLASS_NAMES", envir="",
topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".AllMTable", envir="", topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".MTable", envir="", topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".MTable", envir="", topenv="", inherits=TRUE
Tracing get(".SigLength", envir = env) on entry
x=".SigLength", envir="", topenv="", inherits=TRUE
Tracing get(".SigLength", envir = env) on entry
x=".SigLength", envir="", topenv="", inherits=TRUE
Tracing get(name, envir = env) on entry
x=".MTable", envir="", topenv="", inherits=TRUE
Tracing get(".SigLength", envir = env) on entry
x=".SigLength", envir="", topenv="", inherits=TRUE
Tracing get(".SigLength", envir = env) on entry
x=".SigLength", envir="", topenv="", inherits=TRUE
Tracing get(cname, envir = cwhere, inherits = FALSE) on entry
x=".__C__compMatrix", envir="",
topenv="", inherits=FALSE
Error in get(cname, envir = cwhere, inherits = FALSE) :
  object '.__C__compMatrix' not found
...

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Apr 8, 2020 at 7:52 AM William Dunlap  wrote:

> % R-devel --vanilla --quiet
> > library(Matrix)
> > setClassUnion("mMatrix", c("Matrix", "matrix"))
> Error in get(cname, envir = cwhere, inherits = FALSE) :
>   object '.__C__compMatrix' not found
> Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
>   unable to create union class:  could not set members "Matrix"
> > sessionInfo()
> R Under development (unstable) (2020-04-07 r78175)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 16.04.6 LTS
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib/libopenblasp-r0.2.18.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] Matrix_1.2-18
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0  grid_4.1.0  lattice_0.20-41
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Wed, Apr 8, 2020 at 7:35 AM Martin Maechler 
> wrote:
>
>> >>>>> renozao
>> >>>>> on Mon, 30 Mar 2020 21:20:43 + writes:
>>
>> > Hi,
>> > when R CMD check is run under R-devel (2020-03-29 r78108) I get the
>> following error at installation:
>>
>> > Error in get(cname, envir = cwhere, inherits = FALSE) :
>> > object ‘.__C__compMatrix’ not found
>> > Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
>> > unable to create union class:  could not set members "Matrix"
>>
>> > This does not happen on R 3.6.3.
>>
>> > I tried with Matrix listed in Depends but I still get the same
>> error.
>>
>> > Is this linked to some changes in union classes or the Matrix
>> package?
>>
>> > Thank you.
>>
>> > Bests,
>> > Renaud
>>
>> Hi Renaud,
>> One reason you got no response here, is because we don't even
>> know about which package you are talking.
>>
>> So there's nothing, anybody can reproduce from your posting.
>>
>> There have been changes in R's dealing with class unions etc,
>> notably even *relating* to an earlier bug report on class unions
>> exactly for such a case which was *triggered* when people built
>> on such Matrix classes.
>>
>> But we would really want to be able to reproduce what you are seeing..
>>
>> Best regards,
>> Martin Maechler
>>
>> ETH Zurich, R Core Team *and* maintainer("Matrix")
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

[[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] Question regarding R package development, how to resolve "Warning: no source files found"

[William Dunlap]

INSTALL will give that warning if you have a pkg/src directory that
contains no files that look like C, C++, or Fortran files.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Feb 11, 2020 at 11:58 AM Mohsen Nabian 
wrote:

> Greetings!
>
> How to resolve the following warning for my R package after running test
> :system2("R", paste0("CMD INSTALL -l ",Sys.getenv('R_HOME'),"/library ",
> pkg), stdout = "install1.txt", stderr = "install2.txt")
>
>
> Warning result :
>
> "Warning: no source files found"
>
>
> Thanks alot!
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] r-hub status

[William Dunlap]

CRAN's check gives a warning

checking Rd \usage sections ... WARNING
Documented arguments not in \usage in documentation object 'Process chromR
objects':
  ‘...’


and man/proc_chromR.Rd on github does list '...' in the \arguments section
but no function listed in the \usage section uses '...'.

The question is why you don't always get that warning.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Feb 4, 2020 at 8:47 AM brian knaus  wrote:

> Does anyone know the current status of r-hub? My package (
> https://github.com/knausb/vcfR) is throwing warnings on R-devel (
> https://cran.r-project.org/web/checks/check_results_vcfR.html) and CRAN
> has
> asked me to fix it. Tried r-hub but it failed.
>
>
> https://builder.r-hub.io/status/vcfR_1.9.0.9000.tar.gz-ad6bc014056941a58d94765de3134c4e
>
>
> https://builder.r-hub.io/status/vcfR_1.9.0.9000.tar.gz-f673df2011864365ae5f7f66b4d16bf3
>
> My interpretation is that this is not due to my package. Is anyone else
> having issues with r-hub?
>
> Thanks!
> Brian
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] error in sample(), invalid 'size' argument

[William Dunlap]

If mss$member is not a matrix you will get that error because setsiz will
be NULL.

  > setsiz <- ncol( 33 )
  > sample(1:3, setsiz)
  Error in sample.int(length(x), size, replace, prob) :
invalid 'size' argument


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Jan 15, 2020 at 4:58 AM Roberts, David  wrote:

> Colleagues,
>
> I have a function (maxsimset) in package optpart that has worked for
> at least a decade, passes check --as-cran on my ubuntu-based system, and
> builds without errors at win-builder and CRAN windows, but fails at CRAN
> debian (unstable) with the error
>
>  > mss.test(mss.10,shoshsite$elevation)
> Error in sample.int(length(x), size, replace, prob) :
>invalid 'size' argument
> Calls: mss.test -> sample -> sample.int
>
> an excerpt of the function is below
>
>   1  mss.test <- function(mss,env,panel='all',
>   2  main=deparse(substitute(env)),...)
>   3  {
>   4  if (class(mss) != "mss") {
>   5  stop("You must pass an object of class mss ...")
>   6  }
>   7  if (!is.numeric(env)) {
>   8  stop("You must pass only numeric vectors ... ")
>   9  }
> 10  setsiz <- ncol(mss$member)
> 11  nset <- mss$numset
> 12  null <- rep(0,nset)
> 13  for (i in 1:nset) {
> 14  tmp <- sample(1:length(env),setsiz)
> 15  nullmin <- min(env[tmp])
> 16  nullmax <- max(env[tmp])
> 17  null[i] <- nullmax - nullmin
> 18  }
> 19 . .  .
> 20 . .  .
> 21 . .  .
> 22  }
>
> The error occurs at line 14 in the excerpt above.  As you can see, the
> 'size' argument is setsiz, taken at line 10 as the ncol(mss$member); mss
> has already been checked for conformance and does indeed have a list
> object matrix called $member.  In my tests, setsiz has mode numeric,
> class integer, and size 1 as expected.  The specific error message I
> receive can be generated from sample() if size is a list object or
> data.frame, but not a vector or matrix.
>
> Since I cannot replicate the error on any machines I have access to, I
> am at a loss for the reason behind the error.  If this should go to
> R-devel with respect to r77656 ( 2020-01-12) please advise.
>
> Thanks in advance for any help, Dave
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Bug in checks in R-devel (was: Data docs)

[William Dunlap]

The Matrix package explicitly sets LazyData to "no" with a note saying that
it is necessary.

LazyData: no
LazyDataNote: not possible, since we use data/*.R *and* our classes


My notes on implementing install.packages() in TERR include

When R's install.packages() processes *.R files in the package's data
directory, they may use functions defined in the package's R directory,
whether or not LazyData is yes or no.

If LazyData is no (but not if yes), then the *.R files in data can refer to
files copied from pkg/inst/blah to pkg/blah.

TERR must be able to do this to install the Matrix package from source.


Hence changing the default to "yes" may break the installation of some
packages.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Sun, Oct 27, 2019 at 12:35 PM Duncan Murdoch 
wrote:

> On 27/10/2019 6:04 a.m., Luis-Miguel Rodríguez Rojas wrote:
> > Thanks a lot Xavier!
> > This solved my issue.
>
> This seems like a simple workaround for the bug.  Perhaps "LazyData:
> yes" should become the default.  I don't know what are the advantages of
> the current "LazyData: no" default.
>
> BTW, another issue is that the environment variable controlling this
> test,  "_R_CHECK_CODOC_VARIABLES_IN_USAGES_", doesn't appear to be
> documented.  I did a fairly rough search through the sources for other
> undocumented check variables, and found this list:
>
>   [1] "_R_CHECK_CODOC_VARIABLES_IN_USAGES_"
>   [2] "_R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_MAYBE_"
>   [3] "_R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_START_"
>   [4] "_R_CHECK_CRAN_INCOMING_CHECK_FILE_URIS_"
>   [5] "_R_CHECK_CRAN_INCOMING_DESCR_BAD_START_RECHECK_MAYBE_"
>   [6] "_R_CHECK_CRAN_INCOMING_DESCR_BAD_START_RECHECK_START_"
>   [7] "_R_CHECK_CRAN_INCOMING_GNU_MAKE_RECHECK_MAYBE_"
>   [8] "_R_CHECK_CRAN_INCOMING_GNU_MAKE_RECHECK_START_"
>   [9] "_R_CHECK_CRAN_INCOMING_NOTE_GNU_MAKE_"
> [10] "_R_CHECK_CRAN_INCOMING_SKIP_DATES_"
> [11] "_R_CHECK_CRAN_INCOMING_SKIP_DOI_CHECKS_"
> [12] "_R_CHECK_CRAN_INCOMING_SKIP_URL_CHECKS_IF_REMOTE_"
> [13] "_R_CHECK_CRAN_INCOMING_SKIP_VERSIONS_"
> [14] "_R_CHECK_CRAN_INCOMING_TITLE_CASE_RECHECK_MAYBE_"
> [15] "_R_CHECK_CRAN_INCOMING_TITLE_CASE_RECHECK_START_"
> [16] "_R_CHECK_CRAN_INCOMING_TITLE_INCLUDES_NAME_RECHECK_MAYBE_"
> [17] "_R_CHECK_CRAN_INCOMING_TITLE_INCLUDES_NAME_RECHECK_START_"
> [18] "_R_CHECK_CRAN_INCOMING_USE_ASPELL_"
> [19] "_R_CHECK_CRAN_STATUS_SUMMARY_"
> [20] "_R_CHECK_FF_AS_CRAN_"
> [21] "_R_CHECK_FILE_TIMES_TOL_"
> [22] "_R_CHECK_FUTURE_FILE_TIMESTAMPS_LEEWAY_"
> [23] "_R_CHECK_MAINTAINER_ADDRESS_"
> [24] "_R_CHECK_PACKAGE_DATASETS_SUPPRESS_NOTES_"
> [25] "_R_CHECK_PACKAGE_DEPENDS_IGNORE_MISSING_ENHANCES_"
> [26] "_R_CHECK_PACKAGES_USED_CRAN_INCOMING_NOTES_"
> [27] "_R_CHECK_PACKAGES_USED_IGNORE_UNUSED_IMPORTS_"
> [28] "_R_CHECK_RD_CONTENTS_KEYWORDS_"
> [29] "_R_CHECK_SIZE_OF_TARBALL_"
> [30] "_R_CHECK_SRC_MINUS_W_SOMETIMES_UNINITIALIZED_"
> [31] "_R_CHECK_STANGLE_WARNINGS_"
> [32] "_R_CHECK_SUPPRESS_RANDR_MESSAGE_"
> [33] "_R_CHECK_UNLOAD_NAMESPACES_"
> [34] "_R_CHECK_URLS_USE_CURL_"
> [35] "_R_CHECK_VIGNETTE_TITLES_"
> [36] "_R_CHECK_VIGNETTES_SKIP_RUN_MAYBE_"
>
> Some of these (including _R_CHECK_CODOC_VARIABLES_IN_USAGES_) may be
> intended for internal use only; I'm not even certain the others are used
> in the checks.  All I was looking for were patterns in the source using
>
>grep -r _R_CHECK_ *
>
> and within those lines I assumed ones with the pattern Sys.getenv("...")
> were actually environment variables being used, and ones in files in the
> doc directory were documented.  The ones listed above appear to be used
> but not documented.
>
> Duncan Murdoch
>
> >
> > Best,
> > Miguel.
> >
> > --
> > Luis M. Rodriguez-R, Ph.D.
> > [ https://rodriguez-r.com  ]
> > -
> > Research Engineer
> > Georgia Institute of Technology
> > 311 Ferst Drive, ES, Room 3324
> > Atlanta, GA 30332, USA
> > [ http://enve-omics.gatech.edu/ ]
> >
> >
> >
> > On Sun, Oct 27, 2019 at 3:09 AM Xavier Robin 
> wrote:
> >
> > Hi,
> >
> > It seems you have LazyLoad in your DESCRIPTION:
> >
> > LazyLoad: yes
> >
> > I ran into the same warning a few months ago and realized that
> > LazyLoad has been ignored since R 2.14.0. As a consequence your
> > dataset is not actually loaded lazily, which triggers the warning.
> >
> > Apparently the new way to lazy load a dataset is to use LazyData in
> > the DESCRIPTION:
> >
> > LazyData: yes
> >
> > I don't know in which R version LazyData was introduced, but I
> > expect around the same time.
> >
> >
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file
> >
> > I ended up making the following change, and the warning disappeared:
> >
> >
> https://github.com/xrobin/pROC/commit/77bbb151412643628f2549868700325c8e47cad4
> >
> > I hope it helps.
> > Xavier
> >
> >
> > On 27.10.19 02:14, Duncan Murdoch wrote:
> >> I think this is a bug.  

Re: [R-pkg-devel] Building fails with 'mypackage/DESCRIPTION' does not exist

[William Dunlap]

Will the package build if you back out the "minor changes"?  If so, what
were the minor changes (show diff output)?

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Sep 30, 2019 at 12:24 PM Steve Gutreuter 
wrote:

> I have a package which will no longer build after minor changes.  The
> problem occurs under both Windows 10 and Linux Mint.  For example, from a
> Windows terminal I do:
>
> C:\Users\xyz\OneDrive - ORG\Computing\Devel> R CMD build screenr
>
> and I get:
>
> * checking for file 'mypackage/DESCRIPTION' ... OK
> * preparing 'mypackage':
> * checking DESCRIPTION meta-information ... OK
> * installing the package to process help pages
> * saving partial Rd database
>  Error in .read_description(ldpath) :
>file 'mypackage/DESCRIPTION' does not exist
>  Execution halted
>
> So the first and third lines of output contradict the error message, and of
> course mypackage/DESCRIPTION does exist.  I suspect the problem has nothing
> to do with the DESCRIPTION file, but have not found way to identify the
> actual problem in searches on StackOverflow and elsewhere. My .R files in
> mypackage/R contain Roxygen comments, and curiously devtools::document()
> adds nothing to mypackage/man.
>
> Any suggestions about how to debug or solve this problem?
>
> Thanks!
> Steve
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Problems installing dependences of my package

[William Dunlap]

> And now, I have another problem because the versions are usually
indicated using “>=”, for example:
> forecast (>=8.7) but I need to use exactly the versión 8.7 because
sometimes when packages are updated,
> they lost some functions. But if I use <= or == and the package is update
to versión 8.8, my package installation fail.

In my experience, it is rare that version<= is required.  What function in
in forecast-8.7 was dropped in -8.8?
I didn't see any, but perhaps I missed something.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Sep 9, 2019 at 7:58 AM Andrea Vilar Alvarez <
andreavilaralva...@hotmail.com> wrote:

>
>
> Hi,
>
> I am writting because I am doing a package in R and I have some problems
> installing dependences which appear at DESCRIPTION file.
>
> First of all, I am not sure about the difference between Depends and
> Imports, but I only use Depends.
> My problem is that my package is going to be used at different computers
> and for different persons so I want that when other person use my package,
> it can be able to check  if the necesary packages are installed and if they
> are not installed, the package must be able to install  them.
> I supposed that this problem was solved including the necesary packages
> and their versions at “Depends”. And now, I have another problem because
> the versions are usually indicated using “>=”, for example: forecast
> (>=8.7) but I need to use exactly the versión 8.7 because sometimes when
> packages are updated, they lost some functions. But if I use <= or == and
> the package is update to versión 8.8, my package installation fail.
> How can I solve this? If I use R normaly (outside my package), I can
> install older versions of other packages using devtools::install_version()
> so why when I indicate  forecast (<=8.7) at Depends on the DESCRIPTION
> file, R is not able to install an older version if a new one is avaliable?
>
> Thanks in advance for your attention.
>
> Best regards,
>
> Andrea.
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] R CMD build: "Error in if (any(update))"

[William Dunlap]

You might be able to find where the error occurred by putting the following
lines in ~/.Rprofile

cat("~/.Rprofile: setting alternate error handler\n")
options(
error=quote({
dump.frames()
writeLines(c("Stack trace", paste0("  ",names(last.dump}))

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jun 10, 2019 at 6:38 AM Rob Foxall  wrote:

> Hi,
>
> (Re-posting here as per advice from r-help)
>
> I've got an R package that I periodically create in what I assume is
> an old-fashioned way:
>
> Within R: use "package.skeleton"
> Outside of R: update e.g. .rd files as appropriate
> Command window: run the following commands
> R CMD build packageName
> R CMD check packageName
> R CMD INSTALL --build packageName
>
> I am now getting an error on the R CMD build stage. Initially I had
> wanted to remove a package dependency (by not passing some functions
> to package.skeleton and editing my NAMESPACE and DESCRIPTION file
> appropriately), but on getting the error I tried to revert everything
> back to my last successful build (Feb 2019), however, the error
> persisted:
> R CMD build packageName
> * checking for file 'packageName/DESCRIPTION' ... OK
> * preparing 'packageName' :
> * checking DESCRIPTION meta-information ... OK
> * checking for LF line-endings in source and make files
> * checking for empty or unneeded directories
> * looking to see if a 'data/datalist' file should be added
> Error in if (any(update)) { : missing value where TRUE/FALSE needed
> Execution halted
>
> I am guessing that the error could be due to any of the last three
> lines that don't have an "OK", but I am completely stuck as to how to
> narrow it down further, and Dr. Google has already failed me.
>
> Using R version 3.6.0, R tools version 3.5.0.4 (I don't recall if had
> different versions previous time I built this package in Feb 2019).
> Attempt to reproduce error with dummy package failed (i.e. no issues
> with R CMD build).
>
> Cheers,
> Rob.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] try() in R CMD check --as-cran

[William Dunlap]

I've attached a package, ppp_0.1.tar.gz, which probably will not get
through to R-help, that illustrates this.
It contains one function which, by default, triggers a condition-length>1
issue:
   f <- function(x = 1:3)
   {
   if (x > 1) {
   x <- -x
   }
   stop("this function always gives an error")
   }
and the help file example is
   try(f())

Then
   env _R_CHECK_LENGTH_1_CONDITION_=abort,verbose R-3.6.0 CMD check
--as-cran ppp_0.1.tar.gz
results in
* checking examples ... ERROR
Running examples in ‘ppp-Ex.R’ failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: f
> ### Title: Cause an error
> ### Aliases: f
> ### Keywords: error
>
> ### ** Examples
>
> try(f())
 --- FAILURE REPORT --
 --- failure: the condition has length > 1 ---
 --- srcref ---
:
 --- package (from environment) ---
ppp
 --- call from context ---
f()
 --- call from argument ---
if (x > 1) {
x <- -x
}
 --- R stacktrace ---
where 1: f()
where 2: doTryCatch(return(expr), name, parentenv, handler)
where 3: tryCatchOne(expr, names, parentenv, handlers[[1L]])
where 4: tryCatchList(expr, classes, parentenv, handlers)
where 5: tryCatch(expr, error = function(e) {
call <- conditionCall(e)
if (!is.null(call)) {
if (identical(call[[1L]], quote(doTryCatch)))
call <- sys.call(-4L)
dcall <- deparse(call)[1L]
prefix <- paste("Error in", dcall, ": ")
LONG <- 75L
sm <- strsplit(conditionMessage(e), "\n")[[1L]]
w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w")
if (is.na(w))
w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L],
type = "b")
if (w > LONG)
prefix <- paste0(prefix, "\n  ")
}
else prefix <- "Error : "
msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))
if (!silent && isTRUE(getOption("show.error.messages"))) {
cat(msg, file = outFile)
.Internal(printDeferredWarnings())
}
invisible(structure(msg, class = "try-error", condition = e))
})
where 6: try(f())

 --- value of length: 3 type: logical ---
[1] FALSE  TRUE  TRUE
 --- function from context ---
function (x = 1:3)
{
if (x > 1) {
x <- -x
}
stop("this function always gives an error")
}


 --- function search by body ---
Function f in namespace ppp has this body.
 --- END OF FAILURE REPORT --
Fatal error: the condition has length > 1
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR, 1 NOTE
See
  ‘/tmp/bill/ppp.Rcheck/00check.log’
for details.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Jun 7, 2019 at 10:21 AM Duncan Murdoch 
wrote:

> On 07/06/2019 12:32 p.m., William Dunlap wrote:
> > The length-condition-not-equal-to-one checks will cause R to shutdown
> > even if the code in a tryCatch().
>
> That's strange.  I'm unable to reproduce it with my tries, and John's
> package is no longer online.  Do you have an example I could look at?
>
> Duncan Murdoch
>
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com <http://tibco.com>
> >
> >
> > On Fri, Jun 7, 2019 at 7:47 AM Duncan Murdoch  > <mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > On 07/06/2019 9:46 a.m., J C Nash wrote:
> >  > Should try() not stop those checks from forcing an error?
> >
> > try(stop("msg"))  will print the error message, but won't stop
> > execution.  Presumably the printed message is what is causing you
> > problems.  If you want to suppress that, use
> >
> > try(stop("msg"), silent = TRUE)
> >
> > Duncan Murdoch
> >
> >  >
> >  > I recognize that this is the failure -- it is indeed the check
> > I'm trying to
> >  > catch -- but I don't want tests of such checks to fail my package.
> >  >
> >  > JN
> >  >
> >  > On 2019-06-07 9:31 a.m., Sebastian Meyer wrote:
> >  >> The failure stated in the R CMD check failure report is:
> >  >>
> >  >>>   --- failure: length > 1 in coercion to logical ---
> >  >>
> >  >> This comes from --as-cran performing useful extra checks via
> > setting the
> >  >> environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:
> >  >>
> >  >>> check if either argument of the binary operators &

Re: [R-pkg-devel] try() in R CMD check --as-cran

[William Dunlap]

The length-condition-not-equal-to-one checks will cause R to shutdown even
if the code in a tryCatch().

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Jun 7, 2019 at 7:47 AM Duncan Murdoch 
wrote:

> On 07/06/2019 9:46 a.m., J C Nash wrote:
> > Should try() not stop those checks from forcing an error?
>
> try(stop("msg"))  will print the error message, but won't stop
> execution.  Presumably the printed message is what is causing you
> problems.  If you want to suppress that, use
>
> try(stop("msg"), silent = TRUE)
>
> Duncan Murdoch
>
> >
> > I recognize that this is the failure -- it is indeed the check I'm
> trying to
> > catch -- but I don't want tests of such checks to fail my package.
> >
> > JN
> >
> > On 2019-06-07 9:31 a.m., Sebastian Meyer wrote:
> >> The failure stated in the R CMD check failure report is:
> >>
> >>>   --- failure: length > 1 in coercion to logical ---
> >>
> >> This comes from --as-cran performing useful extra checks via setting the
> >> environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:
> >>
> >>> check if either argument of the binary operators && and || has length
> greater than one.
> >>
> >> (see https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools
> )
> >>
> >> The failure report also states the source of the failure:
> >>
> >>>   --- call from context ---
> >>> fchk(x, benbad, trace = 3, y)
> >>>   --- call from argument ---
> >>> is.infinite(fval) || is.na(fval)
> >>
> >> The problem is that both is.infinite(fval) and is.na(fval) return
> >> vectors of length 10 in your test case:
> >>
> >>>   --- value of length: 10 type: logical ---
> >>>   [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
> >>
> >> The || operator works on length 1 Booleans. Since fval can be of length
> >> greater than 1 at that point, the proper condition seems to be:
> >>
> >> any(is.infinite(fval)) || any(is.na(fval))
> >>
> >> Best regards,
> >>
> >>  Sebastian
> >>
> >>
> >> Am 07.06.19 um 14:53 schrieb J C Nash:
> >>> Sorry reply not quicker. For some reason I'm not getting anything in
> the thread I started!
> >>> I found the responses in the archives. Perhaps cc: nas...@uottawa.ca
> please.
> >>>
> >>> I have prepared a tiny (2.8K) package at
> >>> http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz
> >>>
> >>> R CMD check --> OK
> >>>
> >>> R CMD check --as-cran --> 1 ERROR, 1 NOTE
> >>>
> >>> The error is in an example:
> >>>
>  benbad<-function(x, y){
>  # y may be provided with different structures
>  f<-(x-y)^2
>  } # very simple, but ...
> 
>  y<-1:10
>  x<-c(1)
>  cat("test benbad() with y=1:10, x=c(1)\n")
>  tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
>  print(tryfc01)
>  print(fc01)
> >>>
> >>> There's quite a lot of output, but it doesn't make much sense to me, as
> >>> it refers to code that I didn't write.
> >>>
> >>> The function fchk is attempting to check if functions provided for
> >>> optimization do not violate some conditions e.g., character rather than
> >>> numeric etc.
> >>>
> >>> JN
> >>>
> >>>
> >>> On 2019-06-07 8:44 a.m., J C Nash wrote:
>  Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
>  Fri Jun 7 11:44:37 CEST 2019
> 
>   Previous message (by thread): [R-pkg-devel] try() in R CMD check
> --as-cran
>   Next message (by thread): [R-pkg-devel] using package data in
> package code
>   Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
>  Right, what problem are you talking about? Can you tell us which check
>  it is and what it actually complained about.
>  There is no check that looks at the sizes of x and y in exypressions
>  such as
>  (x - y)^2.
>  as far as I know.
> 
>  Best,
>  Uwe
> 
>  On 07.06.2019 10:33, Berry Boessenkool wrote:
> >
> > Not entirely sure if this is what you're looking for:
> >
> https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R
> > It does contain --as-cran a few times and there's the change-history:
> >
> https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R
> >
> > Regards,
> > Berry
> >
> >
> > 
> > From: R-package-devel 
> on behalf of J C Nash 
> > Sent: Thursday, June 6, 2019 15:03
> > To: List r-package-devel
> > Subject: [R-pkg-devel] try() in R CMD check --as-cran
> >
> > After making a small fix to my optimx package, I ran my usual R CMD
> check --as-cran.
> >
> > To my surprise, I got two ERRORs unrelated to the change. The errors
> popped up in
> > a routine designed to check the call to the user objective function.
> In particular,
> > one check is that the size of vectors is the same in expressions
> like (x - y)^2.
> > This works fine with R CMD check, but the --as-cran seems to have
> changed and it
> > pops an error, even when the call is inside 

Re: [R-pkg-devel] CRAN review

[William Dunlap]

One can use 'g++ -E' to find the which include file is the culprit.  E.g.,

% g++ -c -E -I`R RHOME`/include -I`R RHOME`/site-library/Rcpp/include -I`R
RHOME`/site-library/RcppEigen/include -Iexternal/LPsolve_src/run_headers
-Iexternal/minimum_ellipsoid -Iinclude -Iinclude/volume
-Iinclude/generators -Iinclude/samplers -Iinclude/annealing
-Iinclude/convex_bodies -std=gnu++11 rotating.cpp | egrep '\|^#
*[0-9]+' | grep -C 1 '\'
# 315 "/usr/include/stdlib.h" 2 3 4
extern int rand (void) throw ();
# 1 "/usr/include/alloca.h" 1 3 4
--
# 114 "/usr/include/c++/4.8.2/cstdlib" 3
  using ::rand;
# 196 "/usr/include/c++/4.8.2/cstdlib" 3
--
# 5185 "/usr/include/c++/4.8.2/bits/stl_algo.h" 3
 + std::rand() % ((__i - __first) + 1);
# 5218 "/usr/include/c++/4.8.2/bits/stl_algo.h" 3
--
# 455
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/MathFunctions.h"
return x + (y-x) * Scalar(std::rand()) / Scalar(2147483647);
  offset = (std::size_t(std::rand()) * multiplier) / divisor;
return Scalar((std::rand() >> shift) - offset);
# 689
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/MathFunctions.h"
--
# 295
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/arch/CUDA/Half.h"
return x + (y-x) * half(float(std::rand()) / float(2147483647));
# 412 "/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/Core" 2

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 9:37 AM William Dunlap  wrote:

> Oops, RcppEigen does contain compiled code, but its header files include
> much more code that doesn't get checked because it is not used in
> RcppEigen.so.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 9:35 AM William Dunlap  wrote:
>
>> The check only looks at compiled code.  BH contains only headers, no
>> compiled code.
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Fri, Mar 29, 2019 at 9:27 AM Maxime Turgeon <
>> maxime.turg...@mail.mcgill.ca> wrote:
>>
>>> Hi Bill,
>>>
>>> Maybe I'm missing something, but if RcppEigen were the cause of the
>>> NOTE, wouldn't RcppEigen also get the same NOTE? However, it does not:
>>> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
>>>
>>> And for what it's worth, neither does BH:
>>> https://cran.r-project.org/web/checks/check_results_BH.html
>>>
>>> Max
>>> --
>>> *From:* R-package-devel  on
>>> behalf of William Dunlap 
>>> *Sent:* March 29, 2019 12:05 PM
>>> *To:* Vissarion Fisikopoulos
>>> *Cc:* R Package Development
>>> *Subject:* Re: [R-pkg-devel] CRAN review
>>>
>>> It looks like it is not boost but RcppEigen that has the call to
>>> std::rand() that volesti/src/rotating.cpp contains.
>>>
>>> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>>>   static inline Scalar run(const Scalar& x, const Scalar& y)
>>>   {
>>> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>>>   }
>>>
>>>
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>>
>>>
>>> On Fri, Mar 29, 2019 at 8:43 AM William Dunlap 
>>> wrote:
>>>
>>> > > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
>>> > > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
>>> > > R’s internal random number generation routines as it is proposed in
>>> > > `Writing R Extensions`. Moreover if you run in folder `/src`:
>>> > > $ grep -r 'rand()'
>>> > > You just get:
>>> > > `utils.c:  range *= (LPSREAL) unif_rand();`
>>> > > which is our replacement. If you replace `rand()` with `srand` in
>>> grep
>>> > > search you get a null result.
>>> > > This NOTE appears because of our functions in `/src/include/samplers`
>>> > > where word `rand` appears a lot of times, for example
>>> > > `rand_point_generator()`.
>>> >
>>> > I don't think the note about using 'rand' comes from looking at strings
>>> > in the source code.  It is probably looking at undefined symbols in the
>>> > symbol table of the compiled and linked code with something like the
>>> > following
>>> >
>>> > % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' |
>>> grep
>>> >

Re: [R-pkg-devel] CRAN review

[William Dunlap]

The check only looks at compiled code.  BH contains only headers, no
compiled code.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 9:27 AM Maxime Turgeon <
maxime.turg...@mail.mcgill.ca> wrote:

> Hi Bill,
>
> Maybe I'm missing something, but if RcppEigen were the cause of the NOTE,
> wouldn't RcppEigen also get the same NOTE? However, it does not:
> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
>
> And for what it's worth, neither does BH:
> https://cran.r-project.org/web/checks/check_results_BH.html
>
> Max
> --
> *From:* R-package-devel  on behalf
> of William Dunlap 
> *Sent:* March 29, 2019 12:05 PM
> *To:* Vissarion Fisikopoulos
> *Cc:* R Package Development
> *Subject:* Re: [R-pkg-devel] CRAN review
>
> It looks like it is not boost but RcppEigen that has the call to
> std::rand() that volesti/src/rotating.cpp contains.
>
> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>   static inline Scalar run(const Scalar& x, const Scalar& y)
>   {
> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>   }
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 8:43 AM William Dunlap  wrote:
>
> > > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> > > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> > > R’s internal random number generation routines as it is proposed in
> > > `Writing R Extensions`. Moreover if you run in folder `/src`:
> > > $ grep -r 'rand()'
> > > You just get:
> > > `utils.c:  range *= (LPSREAL) unif_rand();`
> > > which is our replacement. If you replace `rand()` with `srand` in grep
> > > search you get a null result.
> > > This NOTE appears because of our functions in `/src/include/samplers`
> > > where word `rand` appears a lot of times, for example
> > > `rand_point_generator()`.
> >
> > I don't think the note about using 'rand' comes from looking at strings
> > in the source code.  It is probably looking at undefined symbols in the
> > symbol table of the compiled and linked code with something like the
> > following
> >
> > % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' |
> grep
> > rand
> > volesti/src/lp_solve/lp_rlp.o: U storevarandweight
> > volesti/src/lp_solve/lp_price.o: U rand_uniform
> > volesti/src/lp_solve/lp_utils.o: U unif_rand
> > volesti/src/lp_solve/lp_lib.o: U rand_uniform
> > volesti/src/rotating.o: U rand
> > volesti/src/volesti.so: U rand@@GLIBC_2.2.5
> > volesti/src/volesti.so: U unif_rand
> >
> > You will have to poke through the boost headers or docs to see how to
> avoid
> > using rand in volesti/src/rotating.cpp.
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >
> > On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos <
> fisi...@gmail.com>
> > wrote:
> >
> >> Dear all,
> >>
> >> @Henrik: thanks a lot for your reply.
> >>
> >> I did one more submission (the third) and I am posting below my answer
> >> to the automatic cran email with 2 NOTES.
> >>
> >> Looking forward to your feedback.
> >>
> >> Best regards,
> >> Vissarion.
> >>
> >> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos  >
> >> wrote:
> >> >
> >> > Dear all,
> >> >
> >> > We got the results from the automated check for our package. There are
> >> > two NOTEs in both checks in Windows and Debian. We are sure that the
> >> > rejections are false positive, so with this e-mail we try to explain
> >> > why. Please find our explanations below.
> >> >
> >> > On Thu, 28 Mar 2019 at 16:40, 
> wrote:
> >> > >
> >> > > Dear maintainer,
> >> > >
> >> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
> >> automatically, please see the following pre-tests:
> >> > > Windows: <
> >>
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
> >> >
> >> > > Status: 2 NOTEs
> >> > > Debian: <
> >>
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
> >> >
> >> > > Statu

Re: [R-pkg-devel] CRAN review

[William Dunlap]

It looks like it is not boost but RcppEigen that has the call to
std::rand() that volesti/src/rotating.cpp contains.

RcppEigen/include/Eigen/src/Core/MathFunctions.h:
  static inline Scalar run(const Scalar& x, const Scalar& y)
  {
return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
  }


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 8:43 AM William Dunlap  wrote:

> > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> > R’s internal random number generation routines as it is proposed in
> > `Writing R Extensions`. Moreover if you run in folder `/src`:
> > $ grep -r 'rand()'
> > You just get:
> > `utils.c:  range *= (LPSREAL) unif_rand();`
> > which is our replacement. If you replace `rand()` with `srand` in grep
> > search you get a null result.
> > This NOTE appears because of our functions in `/src/include/samplers`
> > where word `rand` appears a lot of times, for example
> > `rand_point_generator()`.
>
> I don't think the note about using 'rand' comes from looking at strings
> in the source code.  It is probably looking at undefined symbols in the
> symbol table of the compiled and linked code with something like the
> following
>
> % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' | grep
> rand
> volesti/src/lp_solve/lp_rlp.o: U storevarandweight
> volesti/src/lp_solve/lp_price.o: U rand_uniform
> volesti/src/lp_solve/lp_utils.o: U unif_rand
> volesti/src/lp_solve/lp_lib.o: U rand_uniform
> volesti/src/rotating.o: U rand
> volesti/src/volesti.so: U rand@@GLIBC_2.2.5
> volesti/src/volesti.so: U unif_rand
>
> You will have to poke through the boost headers or docs to see how to avoid
> using rand in volesti/src/rotating.cpp.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos 
> wrote:
>
>> Dear all,
>>
>> @Henrik: thanks a lot for your reply.
>>
>> I did one more submission (the third) and I am posting below my answer
>> to the automatic cran email with 2 NOTES.
>>
>> Looking forward to your feedback.
>>
>> Best regards,
>> Vissarion.
>>
>> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos 
>> wrote:
>> >
>> > Dear all,
>> >
>> > We got the results from the automated check for our package. There are
>> > two NOTEs in both checks in Windows and Debian. We are sure that the
>> > rejections are false positive, so with this e-mail we try to explain
>> > why. Please find our explanations below.
>> >
>> > On Thu, 28 Mar 2019 at 16:40,  wrote:
>> > >
>> > > Dear maintainer,
>> > >
>> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
>> automatically, please see the following pre-tests:
>> > > Windows: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
>> >
>> > > Status: 2 NOTEs
>> > > Debian: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
>> >
>> > > Status: 2 NOTEs
>> > >
>> > >
>> > >
>> > > Please fix all problems and resubmit a fixed version via the webform.
>> > > If you are not sure how to fix the problems shown, please ask for
>> help on the R-package-devel mailing list:
>> > > <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>> > > If you are fairly certain the rejection is a false positive, please
>> reply-all to this message and explain.
>> > >
>> > > More details are given in the directory:
>> > > <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
>> >
>> > > The files will be removed after roughly 7 days.
>> > >
>> > > No strong reverse dependencies to be checked.
>> > >
>> > > Best regards,
>> > > CRAN teams' auto-check service
>> > > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
>> > > Check: CRAN incoming feasibility, Result: NOTE
>> > >   Maintainer: 'Vissarion Fisikopoulos <
>> vissarion.fisikopou...@gmail.com>'
>> > >
>> > >   New submission
>> > >
>> > >   Possibly mis-spelled words in DES

Re: [R-pkg-devel] CRAN review

[William Dunlap]

> Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> R’s internal random number generation routines as it is proposed in
> `Writing R Extensions`. Moreover if you run in folder `/src`:
> $ grep -r 'rand()'
> You just get:
> `utils.c:  range *= (LPSREAL) unif_rand();`
> which is our replacement. If you replace `rand()` with `srand` in grep
> search you get a null result.
> This NOTE appears because of our functions in `/src/include/samplers`
> where word `rand` appears a lot of times, for example
> `rand_point_generator()`.

I don't think the note about using 'rand' comes from looking at strings
in the source code.  It is probably looking at undefined symbols in the
symbol table of the compiled and linked code with something like the
following

% find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' | grep
rand
volesti/src/lp_solve/lp_rlp.o: U storevarandweight
volesti/src/lp_solve/lp_price.o: U rand_uniform
volesti/src/lp_solve/lp_utils.o: U unif_rand
volesti/src/lp_solve/lp_lib.o: U rand_uniform
volesti/src/rotating.o: U rand
volesti/src/volesti.so: U rand@@GLIBC_2.2.5
volesti/src/volesti.so: U unif_rand

You will have to poke through the boost headers or docs to see how to avoid
using rand in volesti/src/rotating.cpp.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos 
wrote:

> Dear all,
>
> @Henrik: thanks a lot for your reply.
>
> I did one more submission (the third) and I am posting below my answer
> to the automatic cran email with 2 NOTES.
>
> Looking forward to your feedback.
>
> Best regards,
> Vissarion.
>
> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos 
> wrote:
> >
> > Dear all,
> >
> > We got the results from the automated check for our package. There are
> > two NOTEs in both checks in Windows and Debian. We are sure that the
> > rejections are false positive, so with this e-mail we try to explain
> > why. Please find our explanations below.
> >
> > On Thu, 28 Mar 2019 at 16:40,  wrote:
> > >
> > > Dear maintainer,
> > >
> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> > > Windows: <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
> >
> > > Status: 2 NOTEs
> > > Debian: <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
> >
> > > Status: 2 NOTEs
> > >
> > >
> > >
> > > Please fix all problems and resubmit a fixed version via the webform.
> > > If you are not sure how to fix the problems shown, please ask for help
> on the R-package-devel mailing list:
> > > 
> > > If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
> > >
> > > More details are given in the directory:
> > > <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
> >
> > > The files will be removed after roughly 7 days.
> > >
> > > No strong reverse dependencies to be checked.
> > >
> > > Best regards,
> > > CRAN teams' auto-check service
> > > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> > > Check: CRAN incoming feasibility, Result: NOTE
> > >   Maintainer: 'Vissarion Fisikopoulos <
> vissarion.fisikopou...@gmail.com>'
> > >
> > >   New submission
> > >
> > >   Possibly mis-spelled words in DESCRIPTION:
> > > Minkowski (9:17)
> > > Polytopes (4:49)
> > > Volesti (7:71)
> > > polytopes (8:39, 10:83)
> > > volesti (7:50)
> > > zonotopes (9:44)
> > These words, except of 'volesti' (which is the name of our package),
> > describe geometrical concepts.
> >
> > > Flavor: r-devel-windows-ix86+x86_64
> > > Check: compiled code, Result: NOTE
> > >   File 'volesti/libs/i386/volesti.dll':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >   File 'volesti/libs/x64/volesti.dll':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >
> > >   Compiled code should not call entry points which might terminate R
> nor
> > >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> > >   nor system RNGs.
> > >
> > >   See 'Writing portable packages' in the 'Writing R Extensions' manual.
> > >
> > > Flavor: r-devel-linux-x86_64-debian-gcc
> > > Check: compiled code, Result: NOTE
> > >   File 'volesti/libs/volesti.so':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >
> > >   Compiled code should not call entry points which might terminate R
> nor
> > >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> > >   nor system RNGs.
> >
> > Library lpSolveAPI uses rand() 

Re: [R-pkg-devel] How to debug CRAN errors?

[William Dunlap]

You can stick your own version of expect_silent into the test file.  Have
it print
the messages, output, and warnings that it finds.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Mar 13, 2019 at 10:13 AM David Hugh-Jones 
wrote:

> Hi Bill,
>
> I take your point. Meanwhile, though, is there any way to debug the
> problem? I’ll assume that making repeated uploads to CRAN is not a viable
> approach it would be great if there were a Docker image of their setup
> available, for example.
>
> On Wed, 13 Mar 2019 at 17:00, William Dunlap  wrote:
>
>> The complaint
>>
>> > test_check("huxtable")
>>  -- 1. Failure: Data written in appropriate format
>> (@test-openxlsx.R#101) --
>>  `openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx", overwrite =
>> TRUE)` produced messages.
>>
>> comes from your call to testthat::expect_silent()
>>
>> test_that("Data written in appropriate format", {
>>   hx <- huxtable(a = 1:2 + 0.5, b = -1:-2 + 0.5, d = letters[1:2],
>> add_colnames = TRUE)
>>   wb <- as_Workbook(hx)
>>   expect_silent(openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx",
>> overwrite = TRUE))
>>
>>
>> Perhaps you should suggest to the authors of testthat that it would be
>> nice if expect_silent() showed some of the text of the messages, etc.,
>> instead of just saying that messages were produced.
>>
>> By the way, I think your test test should write to a file in [a
>> subdirectory of]] tempdir(), not to a file in the current directory.
>>
>> comes from
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>>
>> On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > My package has errors on CRAN's Linux and Solaris:
>> >
>> > https://cran.r-project.org/web/checks/check_results_huxtable.html
>> >
>> > which I can't reproduce on my local OSX Machine, nor on Linux on Travis.
>> >
>> > Does anyone have any general hints on how to reproduce and/or debug such
>> > errors?
>> >
>> > Specifically the error relates to a call to openxlsx::saveWorkbook
>> > producing a message. openxlsx hasn't changed recently, though.
>> >
>> > Cheers,
>> > David
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> --
> Sent from Gmail Mobile
>

[[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] How to debug CRAN errors?

[William Dunlap]

The complaint

> test_check("huxtable")
 -- 1. Failure: Data written in appropriate format
(@test-openxlsx.R#101) --
 `openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx", overwrite =
TRUE)` produced messages.

comes from your call to testthat::expect_silent()

test_that("Data written in appropriate format", {
  hx <- huxtable(a = 1:2 + 0.5, b = -1:-2 + 0.5, d = letters[1:2],
add_colnames = TRUE)
  wb <- as_Workbook(hx)
  expect_silent(openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx",
overwrite = TRUE))


Perhaps you should suggest to the authors of testthat that it would be nice
if expect_silent() showed some of the text of the messages, etc., instead
of just saying that messages were produced.

By the way, I think your test test should write to a file in [a
subdirectory of]] tempdir(), not to a file in the current directory.

comes from
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones 
wrote:
>
> Hi all,
>
> My package has errors on CRAN's Linux and Solaris:
>
> https://cran.r-project.org/web/checks/check_results_huxtable.html
>
> which I can't reproduce on my local OSX Machine, nor on Linux on Travis.
>
> Does anyone have any general hints on how to reproduce and/or debug such
> errors?
>
> Specifically the error relates to a call to openxlsx::saveWorkbook
> producing a message. openxlsx hasn't changed recently, though.
>
> Cheers,
> David
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[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] nativeRoutines error when using roxygen2 in RStudio

[William Dunlap]

After installing a new version of R the OP may have to rebuild (and retest)
packages like pkgload that define functions by grabbing functions from the
base package and modifying them, as in pkgload/R/namespace-env.r:

onload_assign("makeNamespace",
  eval(
modify_lang(
  extract_lang(body(loadNamespace),

# Find makeNamespace definition
comp_lang, y = quote(makeNamespace <- NULL), idx = 1:2)[[3]],

  # Replace call to .Internal(registerNamespace()) is replaced by a
call to
  # register_namespace
  function(x) {
if (comp_lang(x, quote(.Internal(registerNamespace(name, env) {
  quote(register_namespace(name, env))
} else {
  x
}
  }))
)




Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Nov 7, 2018 at 3:45 AM, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> Without code we are guessing.  A bug is possible but I will make another
> guess suggestion.
>
> Delete all binary files created by devtools during compilation in your
> package directory.
> devtools::load_all() is so fast partly because it recompiles the C/Fortran
> files only when necessary
> but sometimes compilation may be needed even if devtools thinks otherwise.
>
>  Georgi Boshnakov
>
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: 07 November 2018 00:26
> To: Rampal Etienne; Georgi Boshnakov; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in
> RStudio
>
> On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> > Dear Duncan,
> >
> > I don't get it when using R CMD check.
> >
> > I only get it when building/loading using roxygen2 or when I call
> > load_all (which roxygen2 does too, I think). load_all calls load_dll
> > which then throws this error. I have registered my routines in
> > R_init_secsse.c:
> >
> > void R_init_secsse(DllInfo *dll)
> > {
> > R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
> > R_useDynamicSymbols(dll, FALSE);
> > }
> >
> > Any suggestions?
>
> Nope!  Sounds like a bug in devtools/roxygen2, but I don't know either
> of those packages well.
>
> Duncan Murdoch
>
> >
> > Cheers, Rampal
> >
> >
> > On 06-Nov-18 22:50, Duncan Murdoch wrote:
> >> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
> >>> Dear Georgi,
> >>>
> >>> Thanks for your suggestions. I have tried to install the development
> >>> version of roxygen2, but to no avail.
> >>>
> >>> I don't have a Collate field in DESCRIPTION.
> >>>
> >>> devtools::check() gives me:
> >>>
> >>> Updating secsse documentation Loading secsse Registered S3 method
> >>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
> >>> Registered S3 method overwritten by 'geiger': method from
> >>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
> >>> object 'nativeRoutines' not found
> >>
> >> Do you get that error if you run "R CMD check" on the tarball of your
> >> package?
> >>
> >> If so, how comfortable are you with debugging R code?  I can tell you
> >> how to debug the check process, but it's a little tricky.
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>>
> >>> Any other suggestions?
> >>>
> >>> Cheers, Rampal
> >>>
> >>> On 02-Nov-18 08:33, Georgi Boshnakov wrote:
>  Try installing the latest development version of roxygen2, if you
>  are not using it already.
>  There was a bug in the released version preventing installation in
>  some cases.
>  If you don't want to use development version of roxygen2,
>  try putting all filenames in the Collate field in DESCRIPTION on one
>  line and make sure that there is a single space
>  between them. This should work if your problem is what I think.
> 
>  By the way, in such cases you will get more informative messages if
>  you run devtools::check().
> 
>  --
>  Georgi Boshnakov
> 
> 
>  
>  From: R-package-devel [r-package-devel-boun...@r-project.org] on
>  behalf of Rampal Etienne [rampaletie...@gmail.com]
>  Sent: 01 November 2018 22:40
>  To: r-package-devel@r-project.org
>  Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in
>  RStudio
> 
>  Since a few weeks (after updating R-devel and Rtools) I get the
>  following error when trying to build a package or document it, when
>  using roxygen2 in RStudio:
> 
>  In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
>  'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
>  withCallingHandlers ->  -> load_all -> load_dll Execution
>  halted
> 
>  When I disable roxygen2, I do not get this error, but of course the
>  documentation is not created.
> 
>  I have installed the latest versions of RStudio, Rtools, R-devel,
>  roxygen2, pkgload, but the problem persists.
> 
>  Does anybody have a clue what is causing this? 

Re: [R-pkg-devel] dependency on a bioconductor package

[William Dunlap]

It looks like affy is the culprit.

> requiredByCAMERA <- tools::package_dependencies("CAMERA",
recursive=TRUE)$CAMERA
> directlyRequired <- tools::package_dependencies(requiredByCAMERA)
> names(directlyRequired)[ vapply(directlyRequired,
function(x)"BiocInstaller"%in%x, FUN.VALUE=NA) ]
[1] "affy"
> directlyRequired$affy
 [1] "BiocGenerics"   "Biobase""affyio" "BiocInstaller"
"graphics"   "grDevices"
 [7] "methods""preprocessCore" "stats"  "utils"
"zlibbioc"
> getOption("repos")
  CRAN
 BioCsoft
 "https://cloud.r-project.org;"
http://www.bioconductor.org/packages/release/bioc;
   BioCann
  BioCexp
"http://bioconductor.org/packages/3.5/data/annotation; "
http://bioconductor.org/packages/3.5/data/experiment;


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Oct 5, 2018 at 10:58 AM, Morgan, Martin 
wrote:

> (don't forget to 'reply all', so that others may benefit / contribute to
> the conversation).
>
> You or one of the packages your package depends on must Depend: or Import:
> BiocInstaller. If it is your package, then you should no longer do so. If
> it is one of the packages your package depends on, then the responsible
> thing to do is to contact the author of that package and indicate that they
> should update their package to no longer depend on BiocInstaller.
>
> I do not know how the CRAN team will view this warning; I would guess
> that, if it is not directly under your control, then they will not be
> overly concerned about it.
>
> Martin
>
> On 10/5/18 1:35 PM, maia...@alumni.uv.es wrote:
>
>> Hello Morgan,
>>
>> thank you for the replay but, how should I solve the problem in my
>> package? I did install CAMERA using BiocManager in my computer and my
>> package works fine. I do not get any warnings when I run R CDM check but
>> the problem appears when I try to submit it to CRAN.
>>
>> Maribel
>>
>>
>> BiocInstaller has been replaced by the CRAN package BiocManager; the
>>> appropriate way to install Bioconductor packages is
>>> BiocManager::install(). See the vignette at
>>>
>>> https://cran.r-project.org/web/packages/BiocManager/vignette
>>> s/BiocManagerhtml
>>>
>>> Martin
>>>
>>>
>>> On 10/5/18 5:36 AM, maia...@alumni.uv.es wrote:
>>>
 I do not know how to solve this warning. I guess it comes from the
 package dependency on CAMERA (bioconductor) but I can´t solve it.

 https://win-builder.r-project.org/incoming_pretest/LipidMS_1
 .0.0_20181005_103151/Windows/00check.log>

 __
 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-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Determine subset from glm object

[William Dunlap]

If there might be NA's in the response or predictors so na.exclude or
na.omit would remove
some rows as well, then using the row.names might be an easier way to match
up rows in
the original data with rows in gout$x.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Sun, Jul 8, 2018 at 11:04 AM, Charles Geyer  wrote:

> I think your second option sounds better because this is all happening
> inside one function I'm writing so users won't be able mess with the glm
> object. Many thanks.
>
> On Sun, Jul 8, 2018, 12:10 PM Duncan Murdoch 
> wrote:
>
> > On 08/07/2018 11:48 AM, Charles Geyer wrote:
> > > I need to find out from an object returned by R function glm with
> > argument
> > > x = TRUE
> > > what the subsetting was.  It appears that if gout is that object, then
> > >
> > > as.integer(rownames(gout$x))
> > >
> > > is a subset vector equivalent to the one actually used.
> >
> > You don't want the "as.integer".  If the dataframe had rownames to start
> > with, the x component of the fit will have row labels consisting of
> > those labels, so as.integer may fail.  Even if it doesn't, the rownames
> > aren't necessarily sequential integers.   You can index the dataframe by
> > the character versions of the default numbers, so simply
> > rownames(gout$x) should always work.
> >
> > More generally, I'm not sure your question is well posed.  What do you
> > mean by "the subsetting"?  If you have something like
> >
> > df <- data.frame(letters, x = 1:26, y = rbinom(26, 1, 0.5))
> >
> > df1 <- subset(df, letters > "b" & letters < "y")
> >
> > gout <- glm(y ~ x, data = df1, subset = letters < "q", x = TRUE)
> >
> > the rownames(gout$x) are going to be numbers for rows of df, because df1
> > will get a subset of those as row labels.
> >
> >
> > > I do also have the call to glm (as a call object) so can determine the
> > > actual subset argument, but this seems to be not so useful because I
> > don't
> > > know the length of the original variables before subsetting.
> >
> > You should be able to evaluate the subset expression in the environment
> > of the formula, i.e.
> >
> > eval(gout$call$subset, envir = environment(gout$formula))
> >
> > This may give incorrect results if the variables used in subsetting
> > aren't in the dataframe and have changed since glm() was called.
> >
> >
> > > So now my questions.  Is this idea above (using rownames) OK even
> though
> > I
> > > cannot find where (if anywhere) it is documented?  Is there a better
> way?
> > > One more guaranteed to be correct in the future?
> > >
> >
> > I would trust evaluating the subset more than grabbing row labels from
> > gout$x, but I don't know for sure it is likely to be more robust.
> >
> > Duncan Murdoch
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] mvrnorm, eigen, tests, and R CMD check

[William Dunlap]

But why would you want to tie your tests to specific platforms, if
mathematically all those results are equivalent?  You could compare the
orthogonal complements from a full rank matrix (say the identity) to each
expected eigenspace.  E.g., for the example I gave above, where e2 and e1
gave different basis for 2 eigenspaces:

> all.equal(tol=0,
+   residuals(lm.fit(y=diag(5), e1$vectors[,1,drop=FALSE])),
+   residuals(lm.fit(y=diag(5), e2$vectors[,1,drop=FALSE])))
[1] "Mean relative difference: 4.791489e-16"
> all.equal(tol=0,
+   residuals(lm.fit(y=diag(5), e1$vectors[,2:3,drop=FALSE])),
+   residuals(lm.fit(y=diag(5), e2$vectors[,2:3,drop=FALSE])))
[1] "Mean relative difference: 1.469377e-15"
> all.equal(tol=0,
+   residuals(lm.fit(y=diag(5), e1$vectors[,4:5,drop=FALSE])),
+   residuals(lm.fit(y=diag(5), e2$vectors[,4:5,drop=FALSE])))
[1] TRUE


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, May 17, 2018 at 12:55 PM, Ben Bolker <bbol...@gmail.com> wrote:

> There have been various comments in this thread (by me, and I think
> Duncan Murdoch) about how you can identify the platform you're running
> on (some combination of .Platform and/or R.Version()) and use it to
> write conditional statements so that your tests will only be compared
> with reference values that were generated on the same platform ... did
> those get through?  Did they make sense?
>
> On Thu, May 17, 2018 at 3:30 PM, Kevin Coombes
> <kevin.r.coom...@gmail.com> wrote:
> > Yes; I'm pretty sure that it is exactly the repeated eigenvalues that are
> > the issue. The matrices I am using are all nonsingular, and the various
> > algorithms have no problem computing the eigenvalues correctly (up to
> > numerical errors that I can bound and thus account for on tests by
> rounding
> > appropriately). But an eigenvalue of multiplicity M has an M-dimensional
> > eigenspace with no preferred basis. So, any M-dimensional  (unitary)
> change
> > of basis is permitted. That's what give rise to the lack of
> reproducibility
> > across architectures. The choice of basis appears to use different
> > heuristics on 32-bit windows than on 64-bit Windows or Linux machines.
> As a
> > result, I can't include the tests I'd like as part of a CRAN submission.
> >
> > On Thu, May 17, 2018, 2:29 PM William Dunlap <wdun...@tibco.com> wrote:
> >
> >> Your explanation needs to be a bit more general in the case of identical
> >> eigenvalues - each distinct eigenvalue has an associated subspace, whose
> >> dimension is the number repeats of that eigenvalue and the eigenvectors
> for
> >> that eigenvalue are an orthonormal basis for that subspace.  (With no
> >> repeated eigenvalues this gives your 'unique up to sign'.)
> >>
> >> E.g., for the following 5x5 matrix with two eigenvalues of 1 and two of
> 0
> >>
> >>   > x <- tcrossprod( cbind(c(1,0,0,0,1),c(0,1,0,0,1),c(0,0,1,0,1)) )
> >>   > x
> >>[,1] [,2] [,3] [,4] [,5]
> >>   [1,]10001
> >>   [2,]01001
> >>   [3,]00101
> >>   [4,]00000
> >>   [5,]11103
> >> the following give valid but different (by more than sign) eigen vectors
> >>
> >> e1 <- structure(list(values = c(4, 1, 0.999, 0,
> >> -2.22044607159862e-16
> >> ), vectors = structure(c(-0.288675134594813, -0.288675134594813,
> >> -0.288675134594813, 0, -0.866025403784439, 0, 0.707106781186547,
> >> -0.707106781186547, 0, 0, 0.816496580927726, -0.408248290463863,
> >> -0.408248290463863, 0, -6.10622663543836e-16, 0, 0, 0, -1, 0,
> >> -0.5, -0.5, -0.5, 0, 0.5), .Dim = c(5L, 5L))), .Names = c("values",
> >> "vectors"), class = "eigen")
> >> e2 <- structure(list(values = c(4, 1, 1, 0, -2.29037708937563e-16),
> >> vectors = structure(c(0.288675134594813, 0.288675134594813,
> >> 0.288675134594813, 0, 0.866025403784438, -0.784437556312061,
> >> 0.588415847923579, 0.196021708388481, 0, 4.46410900710223e-17,
> >> 0.22654886208902, 0.566068420404321, -0.79261728249334, 0,
> >> -1.11244069540181e-16, 0, 0, 0, -1, 0, -0.5, -0.5, -0.5,
> >> 0, 0.5), .Dim = c(5L, 5L))), .Names = c("values", "vectors"
> >> ), class = "eigen")
> >>
> >> I.e.,
> >> > all.equal(crossprod(e1$vectors), diag(5), tol=0)
> >> [1] "Mean relative difference: 1.407255e-15"
> >> > all.equal(crossprod(e2$vectors), diag(5), tol=0)
> >> [1] "Me

Re: [R-pkg-devel] How to write example results to a tempdir()?

[William Dunlap]

The withr package has a bunch of simple functions executing code in various
contexts, e.g., in a given directory or with given options() settings:

> withr::with_dir
function (new, code)
{
old <- setwd(dir = new)
on.exit(setwd(old))
force(code)
}

> withr::with_dir(tempdir(), getwd())
[1] "/tmp/RtmpvClVBM"

Perhaps some could be moved into core R since they are good for running
examples
and tests.



Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Apr 26, 2018 at 10:20 AM, Duncan Murdoch 
wrote:

> On 26/04/2018 1:04 PM, Henrik Bengtsson wrote:
>
>> On Thu, Apr 26, 2018 at 6:28 AM, Spencer Graves
>>  wrote:
>>
>>>
>>>
>>> On 2018-04-26 07:11, Jose A Guijarro wrote:
>>>

 El 25/04/18 a las 20:21, Duncan Murdoch escribió:

>
> On 25/04/2018 1:32 PM, Sarah Goslee wrote:
>
>>
>> Don't change the working directory! That has all kinds of unpleasant
>> side effects for the unsuspecting user, possibly even more so than
>> writing to a file.
>>
>> Instead, write the file to the temp directory, and read it from there,
>> with e.g.
>>
>> wd <- tempdir()
>> write(dat, file.path(wd, 'Ttest_1981-2000.dat'))
>>
>> Using file.path() means that the appropriate path delimiter for that
>> OS will be used.
>>
>
>
> That's one good way to do it.  But it is possible to change directory
> and
> change back at the end of the example.  For example,
>
> wd <- tempdir()
> savedir <- setwd(wd)
>
> ... # the original code that writes and reads in the current dir
>
> setwd(savedir)
>
> There's a worry that an error in the middle of the code will leave the
> user in the wrong place.  If that's really unlikely to happen, then
> this
> code is a little simpler than Sarah's suggestion.
>
> If it is likely, you can use tryCatch(..., finally = setwd(savedir)),
> but
> I think Sarah's solution would be preferable in most cases:  many
> users will
> not understand what tryCatch() does.
>

>>>
>>>
>>> Hi, Duncan, et al.:
>>>
>>>
>>>Under what circumstances should one also use "on.exit":
>>>
>>>
>>> wd <- tempdir()
>>> savedir <- setwd(wd)
>>> on.exit(setwd(savedir))?
>>>
>>>
>>>Even senior R programmers may miss a failure mode.  In a function,
>>> this works well:  I don't need to remember to "setwd(savedir)" later in
>>> the
>>> code, which could be a problem if I have multiple exit points.  I don't
>>> know
>>> how it would work in a vignette or the examples section of a *.Rd file.
>>> tryCatch(..., finally = setwd(savedir)) condenses this into one line ...
>>> and
>>> is too terse for me in many cases.
>>>
>>
>> FWIW, it can also be used in a local() call, e.g.
>>
>> local({
>>wd <- tempdir()
>>savedir <- setwd(wd)
>>on.exit(setwd(savedir))
>>[...]
>> })
>>
>
> Thanks for pointing that out.  That also has the advantage that it doesn't
> wipe out variables named "wd" and "savedir".
>
> On the other hand, it has the disadvantage that it doesn't leave wd and
> savedir behind for the user to examine, and cut and paste of the central
> executable lines won't work, you need to cut the whole local() call.
>
> Duncan Murdoch
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] reg.finalizer and .onUnload

[William Dunlap]

I have a package that lets a user log into another system
and I want it to be sure to log the user out, at least by the
time the R session is over.

My Login(username,password) function stashes a token
(the username in my simplfied code) in an environment
and my Logout() function needs to use that stored token
to logout.  Logout() sets the stored token to NULL when it is
done and the stored token is NULL when the package is loaded.

I first tried calling the logout function from a finalizer registered
in .onLoad.  This basicly worked:
  > testFinalize::Login("Bill")
  [Loading testFinalize from /homes/bill/packages/tmp/lib]
  *** Logging in user Bill ***
  > q("no")
  [invoking registered finalizer]
  *** Logging out user Bill ***

However, it failed when the user manually unloaded the
package's namespace.  In that case, running
the registered finalizer, either because the session ended or
because of a garbage collection, caused the namespace to be
reloaded, so the stored token is NULL, making it look like
no logout is required:
  > testFinalize::Login("Bill")
  [Loading testFinalize from /homes/bill/packages/tmp/lib]
  *** Logging in user Bill ***
  > unloadNamespace("testFinalize")
  [Unloading /homes/bill/packages/tmp/lib/testFinalize]
  --- Not calling Logout at unload time ---
  > gc() # or q()
  [invoking registered finalizer]
  [Loading testFinalize from /homes/bill/packages/tmp/lib]
  *** No need to log out ***
   used (Mb) gc trigger (Mb) max used (Mb)
  Ncells 255820 13.7 46 24.6   35 18.7
  Vcells 535039  4.11023718  7.9   786426  6.0

If I only call Logout() from .onUnload, and not from the registered
finalizer, nothing happens when the R session is done, since packages are
not unloaded then.

It looks like I need to call Logout from both .onUnload and from
the registered finalizer to make sure it gets called.  Is that
right or is there a standard way to make sure some package-specific
cleanup gets done?

Since the finalizer will still cause the package's namespace to be
loaded we waste some time after q().  Is there a way to unregister
a finalizer so we can avoid the reloading?

I've appended the R code in the package below.  The package exports
Login, Logout, and LogoutAtUnload.  The last lets you force .unLoad to
call Logout() or not.

Reply privately if you want the tar.gz file for the test package.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

.loginInfo <- list2env(
list(token = NULL,
 logoutAtUnload = FALSE)
)
Login <- function(username, password) {
if (is.null(.loginInfo$token)) {
message("*** Logging in user ", username, " ***")
.loginInfo$token <- username
} else {
message("*** Cannot log in user ", username, ", ",
.loginInfo$token, " is already logged in ***")
}
}
Logout <- function() {
if (!is.null(.loginInfo$token)) {
message("*** Logging out user ", .loginInfo$token, " ***")
.loginInfo$token <- NULL
} else {
message("*** No need to log out ***")
}
}
LogoutAtUnload <- function(flag = NA) {
stopifnot(is.logical(flag), length(flag)==1)
old <- isTRUE(.loginInfo$LogoutAtUnload)
if (!is.na(flag)) {
.loginInfo$LogoutAtUnload <- flag
}
old
}
.onLoad <- function(libname, pkgname) {
message("[Loading ", pkgname, " from ", libname, "]")
reg.finalizer(getNamespace(pkgname), function(envir) {
message("[invoking registered finalizer]"); Logout()}, onexit=TRUE)
}
.onUnload <- function(libpath) {
message("[Unloading ", libpath, "]")
if (LogoutAtUnload()) {
Logout()
} else {
message("--- Not calling Logout at unload time ---")
}
}

[[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] Working with R-devel

[William Dunlap]

On Linux you can trace all the getenv calls with ltrace.  It only
works on ELF files, not sh scripts:

% R CMD ltrace -e getenv `R RHOME`/bin/*/R
libR.so->getenv("R_HOME")
   = "/home/R/R-3.4.3/lib64/R"
libR.so->getenv("R_TRANSLATIONS")
   = nil
libR.so->getenv("R_PLATFORM")
   = "x86_64-pc-linux-gnu"
libR.so->getenv("R_PAPERSIZE")
  = "letter"
libR.so->getenv("R_PAPERSIZE")
  = "letter"
libR.so->getenv("R_PRINTCMD")
   = "lpr"
libR.so->getenv("R_RD4PDF")
   = "times,hyper"
...

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Jan 24, 2018 at 6:11 AM, Dirk Eddelbuettel  wrote:

>
> On 24 January 2018 at 07:03, luke-tier...@uiowa.edu wrote:
> | If you are picking up an R 3.4.x that is trying to load a package
> | built by R-devel you should also see a warning that the package was
> | built under R version 3.5.0
>
> Yes, I am of course very aware of the issue.
>
> But we had to separate out R-release and R-devel for years, and so I did. I
> had separate libPaths (or, at least, leading component) for R-devel because
> of that.
>
> | If you are not, then you could be picking up an older R-devel from
> | before the internals change. Probably more likely, the Rcpp being
> | loaded at that point was built by 3.4.x, which would suggest library
> | path settings are messed up at that point, but not clear why. [It
> | might be possible and useful to provide more information about the
> | broken pieces in the error message but I won't have time to look any
> | time soon.]
> |
> | At the moment when it matters I usually use
> |
> | env R_LIBS= R CMD check ...
> |
> | for checks under R_devel
>
> It was the R_LIBS_USER (which used to work) to R_LIBS change that got plus
> the fact that my R-devel was picking up my R-release check.Renviron. The
> hint
> from Martin got rid of that.
>
> Sometimes I wonder if we should have an extra-verbose mode that picks up
> EVERY single Sys.getenv() and alike to make it easier to trace this. But
> run-time cost of the check is probably unattractive.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Assignments to the Global environment

[William Dunlap]

I think that assigning something to parent.frame() is bad practice, for the
same reasons that assigning to .GlobalEnv is bad.  You could instead make
an environment in your package called, say, "TSEtools.env", with
TSETools.env <- new.env()
in some *.R file in the package's R directory.  Export it via NAMESPACE.
 Then use
TSETools.env as the default value of assign.env().



Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Sun, Jan 7, 2018 at 6:41 AM, Hugh Parsonage 
wrote:

> I'm not CRAN, but something like this might be permissible while
> satisfying your requirements.
>
>z <- function(..., assign.env = parent.frame(1))
> assign(as.character(s), temp3, envir = assign.env)
>
> The problem with assigning to the global environment is that z might
> be called where it is expected to only have a local effect. If users
> really want to assign to the global environment, providing an option
> might be appropriate.
>
>z <- function(y, s, assign.env = getOption("TSEtools.z.env",
> parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)
>
>options("TSEtools.z.env" = .GlobalEnv)
>
>
> On Sun, 7 Jan 2018 at 23:21 Saeb  wrote:
> >
> > The function downloads the list of index's value and assigned them to
> > the individual's name correspond with the indexes. If remove the
> > .GlobalEnv, then we can not return the values in output.
> >
> > Since, the data is updated daily, I think that the storage on device is
> > not user friendly enough.
> >
> > I already used the following code with same R report:
> >
> > assign(as.character(s), temp3, envir = .GlobalEnv)
> >
> > |
> > |
> >
> >
> > On 01/07/2018 01:30 AM, Uwe Ligges wrote:
> > > Let me add: Frequently you can use storage in an enmvironment in yur
> > > package, if that helps to avoid assigning into .GlobalEnv.
> > >
> > > Best,
> > > Uwe Ligges
> > >
> > > On 06.01.2018 22:07, peter dalgaard wrote:
> > >> You probably need to tell us what you are trying to achieve. Why do
> > >> you want to assign temp3 to a variable with its name in s into the
> > >> global environment? Not doing that would clearly eliminate the Note:,
> > >> but presumably it has a function. However, writing to the global
> > >> environment, especially to variables with arbitrary names, is
> > >> potentially antisocial behaviour, since it may overwrite user
> variables.
> > >>
> > >> Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is
> > >> as intended?
> > >>
> > >> -pd
> > >>
> > >>> On 6 Jan 2018, at 20:36 , Saeb  wrote:
> > >>>
> > >>> * checking R code for possible problems ... [4s] NOTE
> > >>> Found the following assignments to the global environment:
> > >>> File 'TSEtools/R/getTSE.R':
> > >>> assign(as.character(s), temp3, envir = as.environment(1))
> > >>>
> > >>> Please let me know, how can I eliminate this problem? I didn't find
> out
> > >>> any good information on websites!
> > >>
> >
> >
> > [[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
>

[[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] Exited with status -1073741819.

[William Dunlap]

You wrote
Exited with status -1073741819.

The low byte of that status code is 5, which I think means a segmentation
fault - reading
or writing an address that you do not have permission of use.
  > as.hexmode(-1073741819)
  [1] "c005"
If your code uses memory that it has not allocated it is somewhat random
whether you
get a segmentation fault or not.  'valgrind' can detect such errors more
reliably.  Try that
on a platform where your package builds.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Tue, Nov 28, 2017 at 12:51 PM, Rampal Etienne 
wrote:

> Dear all,
>
> I updated RStudio, Rtools and R-devel, and then I tried to build a package
> in RStudio that I had been able to build before without any problems. But
> now I got the following error:
>
> Updating SADISA documentatiob
> Loading SADISA
> Exited with status -1073741819.
>
> That's all. What is this exit status? I can still build other packages, so
> it does not happen all the time. I can use "Load all" and all functions
> sseem to work fine.
>
> Any suggestions?
>
> Kind regards, Rampal Etienne
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Solaris SPARC, Fortran, and logical errors?

[William Dunlap]

I don't know about the current Sparc Fortran compilers, but over the
years have learned not to try to pass logicals and character strings
between C and Fortran.  I have seen Fortran compilers that treated
integer -1 (all bits 1) as .true. and anything else as .false. and I
have see ones that looked only at bit 7, counting from the right, to
determine the value.

I recommend changing your Fortran code to accept an integer instead of
a logical for boolean inputs and outputs.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Mar 15, 2017 at 7:40 AM, Avraham Adler  wrote:
> Hello.
>
> The Delaporte package works properly on all R-core platforms except
> Solaris SPARC, where it  compiles properly but fails a number of its
> tests [1]. Not having access to a SPARC testbed, I'm limited in what
> kind of diagnostics I can do. One thing I have noticed is that a lot
> of the failures occur when I am passing non-default logicals (like
> lower tail or log). For example, the first failure at that link is
> when "log = true" is supposed to be passed, but the SPARC answers are
> the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
>
> I'll bring an example of how it is coded below, and if anyone
> recognizes where SPARC specifically goes wrong, I'd appreciate. I
> guess, if I absolutely had to, I could convert the logical to an
> integer in C and pass the integer to Fortran which should work even
> for SPARC, but I'd prefer not to if I could help it.
>
> Thank you,
>
> Avi
>
> [1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
>
> *Example Code*
>
> R code:
>
> ddelap <- function(x, alpha, beta, lambda, log = FALSE){
>   if(!is.double(x)) {storage.mode(x) <- 'double'}
>   if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
>   if(!is.double(beta)) {storage.mode(beta) <- 'double'}
>   if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
>   if(any(x > floor(x))) {
> warning("Non-integers passed to ddelap. These will have 0 probability.")
>   }
>   .Call(ddelap_C, x, alpha, beta, lambda, log)
> }
>
> C code:
>
> void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
> double *l, int nl,
>   int *lg, double *ret);
>
> extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP lg){
>   const int nx = LENGTH(x);
>   const int na = LENGTH(alpha);
>   const int nb = LENGTH(beta);
>   const int nl = LENGTH(lambda);
>   SEXP ret;
>   PROTECT(ret = allocVector(REALSXP, nx));
>   ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
> nl, LOGICAL(lg), REAL(ret));
>   UNPROTECT(1);
>   return(ret);
> }
>
> Fortran: (not posting ddelap_f_s as that doesn't handle the logging)
>
> subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
> name="ddelap_f")
>
> integer(kind = c_int), intent(in), value :: nx, na, nb, nl
> ! Sizes
> real(kind = c_double), intent(in), dimension(nx) :: x
> ! Observations
> real(kind = c_double), intent(out), dimension(nx):: pmfv
> ! Result
> real(kind = c_double), intent(in):: a(na), b(nb),
> l(nl)! Parameters
> logical(kind = c_bool), intent(in)   :: lg
> ! Log flag
> integer  :: i
> ! Integer
>
> !$omp parallel do default(shared) private(i)
> do i = 1, nx
> if (x(i) > floor(x(i))) then
> pmfv(i) = ZERO
> else
> pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
>  b(mod(i - 1, nb) + 1), l(mod(i -
> 1, nl) + 1))
> end if
> end do
> !$omp end parallel do
>
> if (lg) then
> pmfv = log(pmfv)
> end if
>
> end subroutine ddelap_f
>
> __
> 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

Re: [R-pkg-devel] TryCatch messages

[William Dunlap]

Use conditonMessage() to extract the message from an error, warning,
message, or other 'condition'

For more, see Hadley Wickham's book, "Advanced R":

  http://adv-r.had.co.nz/Exceptions-Debugging.html
  http://adv-r.had.co.nz/beyond-exception-handling.html

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Feb 3, 2017 at 9:36 AM, Glenn Schultz  wrote:
> All,
> I have my tryCatch working on my function and rather than crashing I get the
> error message below.  However, I would just like price must be entered as a
> character without the information to the right of the : Can this information
> be suppressed?
>
> Thanks,
> Glenn
>
>  settlement.date = "08-18-2016", price = 100, PrepaymentAssumption =
> PrepaymentModel(bond.id = FNAR7401, TermStructure =
> TermStructure(rates.data = Curve, method = "dl"), MortgageRate =
> MtgRate(), ModelTune = ModelTune(MBS(MBS.id = "3138W5GK8")), Burnout
> = Burnout(MBS(MBS.id = "3138W5GK8")), PrepaymentAssumption = "MODEL")):
> price must be entered as a character>
> __
> 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

Re: [R-pkg-devel] Weird MAKEFLAGS bug

[William Dunlap]

MAKEFLAGS='CXXFLAGS=-std=c++0x -O2' R CMD SHLIB

passes two items, 'CXXFLAGS=-std=c++0x' and '-O2', not the single item
'CXXFLAG=-std=c++0x -O2', to make.  Suitably recent versions of GNU
make take the make argument -O2 to control the 'output-sync'.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Jan 10, 2017 at 12:39 PM, Costas Tsirogiannis
 wrote:
> Thanks a lot, indeed it worked using the Makevars file. I still do not
> understand why the command-line input fails but so be it.
>
> One more quick question: if I include the Makevars file in my package code
> then the requested flags are used every time somebody installs my package
> in his system. However, -O2 is a gcc-specific flag so it won't work for
> every compiler. Is there a simple way to declare another optimization flag
> in Makevars, that works for all compilers?
>
> Thanks for all the help,
>
> --Constantinos
>
> On 10 January 2017 at 12:39, Dirk Eddelbuettel  wrote:
>
>>
>> On 10 January 2017 at 11:55, Costas Tsirogiannis wrote:
>> | Greetings and thanks for previously offered solutions,
>> |
>> | I am developing a package that makes use of C++ code, and I want to
>> compile
>> | this code for testing reasons with the "R CMD SHLIB" command. Using
>> Ubuntu
>> | and gcc 5.4, and because for certain reasons I have to use the c++0x
>> | standard, I try the following command:
>> |
>> | > MAKEFLAGS='CXXFLAGS=-std=c++0x -lpthread -O2' R CMD SHLIB
>> MyMainCode.cpp
>> |
>> | For some weird reason, flag -O2 is not recognized properly and I get the
>> | following error message:
>> |
>> | > make: *** unknown output-sync type '2'.  Stop.
>> |
>> | If I try -O3, I get "unknown output-sync type '3' ", and so on.
>> Everything
>> | works fine if I drop this optimization flag. Could you suggest a
>> workaround
>> | for that?
>>
>> Sounds weird. Wonder if something else could go on here.
>>
>> But in general, using ~/.R/Makevars is better.  Try that.
>>
>> edd@max:~$ grep FLAGS ~/.R/Makevars | grep -v "^#"
>> CFLAGS +=  -O3 -Wall -pipe -pedantic -std=gnu99
>> CXXFLAGS +=   -O3 -Wall -pipe -Wno-unused -pedantic
>> FFLAGS += -O3 -g0 -Wall -pipe
>> FCFLAGS += -O3 -g0 -Wall -pipe
>> CXX1XFLAGS=-O3 -Wall -pipe -Wno-unused -pedantic
>> FLAGS=-Wall -O3
>> DYLIB_LDFLAGS = -Wl,-S -shared -fopenmp# $(CFLAGS) $(CPICFLAGS)
>> SHLIB_CXXLDFLAGS = -Wl,-S -shared
>> SHLIB_CXX1XLDFLAGS = -Wl,-S -shared
>> SHLIB_FCLDFLAGS = -Wl,-S -shared
>> SHLIB_LDFLAGS = -Wl,-S -shared# $(CFLAGS) $(CPICFLAGS)
>> edd@max:~$
>>
>> Dirk
>>
>> --
>> http://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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] accessing data by packagename::dataname from within package code fails.

[William Dunlap]

You can define the data in the R directory.  You can keep it all in a *.R
file
by wrapping the text of the *.csv file in quotes and using
read.table(text="quoted stuff"), as in:

theData <- read.csv(header=TRUE, text="
English,Digit
One,1
Two,2
Three,3")
N <- nrow(theData)

You need to make sure 'theData' is defined before using it so put
everything requiring
it in one file or use the Collate: directive in the DESCRIPTION file.



Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Mon, Dec 12, 2016 at 12:34 PM, Witold E Wolski 
wrote:

> I have narrowed down the problem.
> The error
> Error : 'AminoAcids' is not an exported object from 'namespace:bibliospec'
> Error : unable to load R code in package 'bibliospec'
>
> occurs only if I try to access the data using bibliospec::AminoAcids
>
> within the initialize method of an R reference class.
> It does work, as far as I tested everywhere else. In other methods of
> a reference class as well as in free functions.
> It also does not work in the initialization list to the initialize
> function.
> So I also can't do something like
> initialize = function(aminoAcids=bibliospec::AminoAcids){
>
>
> I guess this is an R FEATURE.
>
> But then where and how is the best practice to initialize class
> members with default values?
>
> Thank you.
>
>
>
>
>
> On 12 December 2016 at 15:45, Witold E Wolski  wrote:
> > I am wrting a package called bibliospec.
> > I have a dataset in data/AminoAcids.tsv and would like to be able to
> > access it with
> >
> > bibliospec::AminoAcids
> >
> > from within my package code.
> >
> > R CMD build gives me the error:
> > Error : 'AminoAcids' is not an exported object from
> 'namespace:bibliospec'
> >
> > I am able to access the data in package code with
> > data(AminoAcids)
> > AminoAcids
> >
> > but this will give me a NOTE with R CMD check
> >
> > Also, after loading the packagepackage I am able to access the data with
> > bibliospec::AminoAcids
> >
> > But I can't access it from the package bibliospec code.
> > So why can't I access bibliospec::AminoAcids from within package code?
> >
> > Help appreciated
> >
> > Witold
> > --
> > Witold Eryk Wolski
>
>
>
> --
> Witold Eryk Wolski
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Using BLAS on Windows

[William Dunlap]

The MGGM package has the following in src/Makevars.win to tell the linker
to link with the Lapack, BLAS, and Fortran libraries.

PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

Its Makevars file is identical - is that Makevars.win really needed?  I
don't see Makevars or Makevars.win in your github site.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Nov 10, 2016 at 8:38 AM, Vilhelm von Ehrenheim <
vonehrenh...@gmail.com> wrote:

> Hi!
> I've tried to submit a package to CRAN that fails to build on windows as it
> cannot find BLAS.
>
> Here is the error:
> ```
> #> lognet.o:lognet.c:(.text+0x8c): undefined reference to `dgemv_'
> #> lognet.o:lognet.c:(.text+0x3d7): undefined reference to `dgemv_'
> ```
>
> It works fine to build on linux machines and I'm currently using rhub to
> try and build it on windows. I got a pointer from the denied CRAN
> submission that I need to set my Makevars.win properly but I can't find how
> to do this is a way that makes it work on Windows. Im no windows user so i
> really dont understand what im doing.
>
> My package is located here on github:
> https://github.com/while/FTRLProximal
>
> Any help would be greatly apprechiated.
>
> Regards,
> Vilhelm von Ehrenheim
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] environment scoping

[William Dunlap]

If I were writing a package for factoring integers I might store a vector
of known primes in an environment in my package and have my factoring
functions append to the list when they find some more primes.  This works
because there is only one set of of primes (given we stick with ordinary
integers).

However the term structure (of interest rates, I assume) depends on the
date, the county, the type of bond, the method used to estimate it, etc.  I
think it would be better to store it in some sort of object (function,
list, or environment) that the user would be expected to know about.  The
user would be expected to pass that data into each function that need that
information (via the argument list, by using a function made in the
environment containing the term structure, etc.).


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Oct 27, 2016 at 7:55 AM, Jenny Bryan  wrote:

> Hi Glenn,
>
> It sounds like you should create an environment for your package. If you
> store these objects in the global environment, they are exposed to the user
> and, more importantly, user could modify or delete them. If you use an
> environment specific to your package, you can be sure you are the only one
> messing with them.
>
> You create it like so:
>
> .package_env <- new.env(parent = emptyenv())
>
> And read from / write into it like so (very much like a list):
>
> .package_env$foo <- ...
> .package_env$foo
>
> or with assign() and get():
>
> assign(foo, bar, envir = .package_env)
> get(foo, envir = .package_env)
>
> This blog post by Jeff Allen is a nice write-up of what you're trying to
> do:
>
> http://trestletech.com/2013/04/package-wide-variablescache-in-r-package/
>
> -- Jenny
>
> > On Oct 27, 2016, at 7:05 AM, Glenn Schultz  wrote:
> >
> > All,
> >
> > I would like to have some inputs available to many functions.  For
> example, I have coefficient for a term structure fit which I would like to
> make a available to total return functions.  Thereby eliminating the need
> to fit the same term structure over and over again.  However, I still
> reading and researching scoping.  My understanding is that I could fit the
> term structure and keep the coefficients in the global environment which
> would then make those coefficients available to all functions requiring a
> term structure object input.  Am I correct in my understanding.  What is
> the downside of environment global, if any?
> >
> > Best Regards,
> > Glenn
> > __
> > 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
>

[[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] Only printing a message once per top-level call.

[William Dunlap]

This is not a complete answer to your problem, but here is an example of
how to make and store messages of a certain class, "lowMessage", and later
print a table of the messages and their counts.

> lowMessage <- function(text, call = sys.call(-1))
   {
   # make a message of class "lowMessage"
   text <- sub("([^\n])$", "\\1\n", text)
   msg <- simpleMessage(text, call = call)
   class(msg) <- c("lowMessage", class(msg))
   message(msg)
   }

> handleLowMessages <- function(expr, call = sys.call(-1))
   {
   # store up lowMessages generated while evaluating 'expr'
   # and print a table of them when 'expr' has completed.
   # Returrn value of 'expr'.
   msgEnvir <- new.env()
   on.exit({
   lapply(names(msgEnvir), function(msg) message(msg, " (",
msgEnvir[[msg]], " times)"))
   })
   withCallingHandlers(expr, lowMessage = function(e)
   {
   text <- sub("\n$", "", conditionMessage(e))
   if (is.null(msgEnvir[[text]])) {
   msgEnvir[[text]] <- 1
   } else {
   msgEnvir[[text]] <- msgEnvir[[text]] + 1
   }
   invokeRestart("muffleMessage")
   })
   }

> low1 <- function(x) { lowMessage("using low1") ; x + 1 }

> low2 <- function(x) { lowMessage("using low2") ; x - 1 }

> high <- function(x, n1=3, n2=5) {
   for(i in seq_len(n1)) x <- low1(x)
   for(i in seq_len(n2)) x <- low2(x)
   x
   }

> high(10, 4, 7) # don't use the handler
using low1
using low1
using low1
using low1
using low2
using low2
using low2
using low2
using low2
using low2
using low2
[1] 7

> handleLowMessages(high(10, 4, 7))
using low1 (4 times)
using low2 (7 times)
[1] 7

> handleLowMessages(for(i in 1:3)high(i, 2, 8))
using low1 (6 times)
using low2 (24 times)


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Oct 21, 2016 at 12:39 AM, Pavel N. Krivitsky 
wrote:

> Dear All,
>
> I have a package (ergm, in case you are wondering) that has some low-
> level routines (say, low()) that produce messages that the end-user
> needs to see and that tend to be called multiple times for every time
> the top-level routine (say, high()) is called, often by other routines
> that are top-level routines themselves.
>
> What I'd like to do to have the low-level routine print the message the
> first time it's called for a given top-level call, and then "remember"
> and stay silent the next time to avoid spamming the end-user.
>
> In other words,
>1. high()
>   1. low()
>  1. print message
>   2. low()
>  1. don't print message
>   3. high()
>  1. low()
> 1. don't print message
>2. high()
>   1. low()
>  1. print message
>
> One way to do that that I can see is to use local() to create a
> blacklist of messages that have already been printed, which get cleared
> every time the top-level call exists. I.e.,
>1. Use local() with a list of messages printed so far and a status of
>   "active" or "inactive" (the initial state), which returns  a
>   function that can query and update both of those.
>2. When high() is called, it first checks if the blacklist is active.
>   1. If it's active, then this high() must have been called from
>  another high(), so it leaves the blacklist alone.
>   2. If it's inactive, then it must be the top-level call, so it sets
>  it to active and sets an on.exit() handler to clear the blacklist
>  and set it to inactive.
>3. When low() wants to print a message, it queries the blacklist to see
>   if it's already printed it. If not, it prints and adds it to the
>   list.
>4. When the top-level high() finishes, the blacklist is cleared and set
>   to inactive.
>
> However, I wonder if there already is a way to do that, ideally built
> in.
>
> Any thoughts?
> Pavel
>
>
>
> --
> Pavel Krivitsky
> Lecturer in Statistics
> National Institute of Applied Statistics Research Australia (NIASRA)
> School of Mathematics and Applied Statistics | Building 39C Room 154
> University of Wollongong NSW 2522 Australia
> T +61 2 4221 3713
> Web (NIASRA): http://niasra.uow.edu.au/index.html
> Web (Personal): http://www.krivitsky.net/research
> ORCID: -0002-9101-3362
>
> NOTICE: This email is intended for the addressee named and may contain
> confidential information. If you are not the intended recipient, please
> delete it and notify the sender. Please consider the environment before
> printing this email.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[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] win-builder, compiling C code, make[1]: ar: Command not found

[William Dunlap]

If you hadn't squelched command line echoing from your makefiles (by
putting the 'at' signs in front of the commands)  you might have discovered
the problem faster.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Oct 7, 2016 at 5:30 PM, Gillian Sharer <gill...@iris.washington.edu>
wrote:

>
> It’s solved! Changing ‘ar’ to ‘$(AR)’ in the Makefile along with adding
> AR="$(AR)" to @(cd libmseed && $(MAKE) static CC="$(CC)"
> CFLAGS="$(CFLAGS)") in the Makevars.win fixed the problem.
>
> Thank you!
> Gillian Sharer
>
> > On Oct 7, 2016, at 3:50 PM, William Dunlap <wdun...@tibco.com> wrote:
> >
> > Do you have a Makefile in the directory yourPackage/src/libmseed?
> > If so, how does it call 'ar' or '$(AR)'?
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> > On Fri, Oct 7, 2016 at 3:44 PM, Gillian Sharer <
> gill...@iris.washington.edu> wrote:
> > Thank you for your response. I apologize for asking basic questions, but
> I’m new to this. On my local machine (mac osx) the $R_HOME/etc/Makeconf
> AR=ar and $BINPREF is not set. I have ar in my path.
> >
> > I’m uploading the package to http://win-builder.r-project.org/ using
> devtools::build_win. Am I right in thinking the path in question is on the
> Windows machine? I don’t have access to the Windows Makeconf file, so do I
> need to set something in the Makevars.win file?
> >
> > I tried adding this to the src/Makevars.win file:
> > AR=$(BINPREF)ar
> >
> > Then I tried:
> > BINPREF=/mingw_$(WIN)/bin/
> > AR=$(BINPREF)ar
> >
> > And:
> > BINPREF=d:/Compiler/gcc-4.9.3/mingw_32/bin/
> > AR=$(BINPREF)ar
> >
> > None of these changed the win-builder results. Do I have the wrong path
> or is Makevars.win the wrong place to set this?
> >
> > Thanks,
> > Gillian Sharer
> >
> >
> > > On Oct 7, 2016, at 12:24 PM, Duncan Murdoch <murdoch.dun...@gmail.com>
> wrote:
> > >
> > > On 07/10/2016 3:06 PM, Gillian Sharer wrote:
> > >> Hi,
> > >>
> > >> I tried to submit a package to win-builder with C code and it won’t
> compile. I get this result:
> > >>
> > >>   ar -crs libmseed.a fileutils.o genutils.o gswap.o lmplatform.o
> lookup.o msrutils.o pack.o packdata.o traceutils.otracelist.o
> parseutils.o unpack.o unpackdata.o selection.o logging.o
> > >>   make[1]: ar: Command not found
> > >>   make[1]: *** [libmseed.a] Error 127
> > >>   make[1]: Leaving directory `/cygdrive/d/temp/RtmpUvWmaH/
> R.INSTALL3e847db06d40/IRISSeismic/src- i386/libmseed'
> > >>   make: *** [libmseed/libmseed.a] Error 2
> > >>   Warning: running command 'make -f "Makevars.win" -f
> "D:/RCompile/recent/R/etc/i386/Makeconf" -f   
> "D:/RCompile/recent/R/etc/i386/Makevars.site"
> -f "D:/RCompile/recent/R/share/make/winshlib.mk"
>  SHLIB="IRISSeismic.dll" OBJECTS="parseMiniSEED.o"' had status 2
> > >>   ERROR: compilation failed for package ‘IRISSeismic'
> > >>
> > >> It says it can’t find the command ar, which I don’t understand. This
> was my original Makevars.win file:
> > >>
> > >>   PKG_CFLAGS=
> > >>   PKG_CPPFLAGS=-Ilibmseed
> > >>   PKG_LIBS=-Llibmseed -lmseed
> > >>   $(SHLIB): libmseed/libmseed.a
> > >>   libmseed/libmseed.a:
> > >>  @(cd libmseed && $(MAKE) static CC="$(CC)" CFLAGS="$(CFLAGS)”)
> > >>   clean:
> > >>  @(cd libmseed && $(MAKE) clean)
> > >>
> > >> and I also tried it using the following with the same results:
> > >>
> > >>   libmseed/libmseed.a:
> > >>  @(cd libmseed && $(MAKE) static CC="$(CC)" CFLAGS="$(CFLAGS)”
> AR="$(AR)")
> > >>
> > >> A google search turned up nothing and a stackoverflow question has
> not had any responses yet. Is there something I’m missing? And is there any
> other relevant information I can provide? I don’t have much experience
> compiling C code, but it works on Mac OSX and Linux.
> > >
> > > It's just what it said:  you don't have ar on your path.  Normally the
> $(AR) variable is set to $(BINPREF)ar.  Perhaps you've changed
> R_HOME/etc/Makeconf so that isn't true, or have overridden BINPREF with a
> value different from the default.
> > >
> > > Duncan Murdoch
> > >
> > >
> >
> > __
> > 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
>

[[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] win-builder, compiling C code, make[1]: ar: Command not found

[William Dunlap]

Do you have a Makefile in the directory yourPackage/src/libmseed?
If so, how does it call 'ar' or '$(AR)'?

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Oct 7, 2016 at 3:44 PM, Gillian Sharer 
wrote:

> Thank you for your response. I apologize for asking basic questions, but
> I’m new to this. On my local machine (mac osx) the $R_HOME/etc/Makeconf
> AR=ar and $BINPREF is not set. I have ar in my path.
>
> I’m uploading the package to http://win-builder.r-project.org/ using
> devtools::build_win. Am I right in thinking the path in question is on the
> Windows machine? I don’t have access to the Windows Makeconf file, so do I
> need to set something in the Makevars.win file?
>
> I tried adding this to the src/Makevars.win file:
> AR=$(BINPREF)ar
>
> Then I tried:
> BINPREF=/mingw_$(WIN)/bin/
> AR=$(BINPREF)ar
>
> And:
> BINPREF=d:/Compiler/gcc-4.9.3/mingw_32/bin/
> AR=$(BINPREF)ar
>
> None of these changed the win-builder results. Do I have the wrong path or
> is Makevars.win the wrong place to set this?
>
> Thanks,
> Gillian Sharer
>
>
> > On Oct 7, 2016, at 12:24 PM, Duncan Murdoch 
> wrote:
> >
> > On 07/10/2016 3:06 PM, Gillian Sharer wrote:
> >> Hi,
> >>
> >> I tried to submit a package to win-builder with C code and it won’t
> compile. I get this result:
> >>
> >>   ar -crs libmseed.a fileutils.o genutils.o gswap.o lmplatform.o
> lookup.o msrutils.o pack.o packdata.o traceutils.otracelist.o
> parseutils.o unpack.o unpackdata.o selection.o logging.o
> >>   make[1]: ar: Command not found
> >>   make[1]: *** [libmseed.a] Error 127
> >>   make[1]: Leaving directory `/cygdrive/d/temp/RtmpUvWmaH/
> R.INSTALL3e847db06d40/IRISSeismic/src- i386/libmseed'
> >>   make: *** [libmseed/libmseed.a] Error 2
> >>   Warning: running command 'make -f "Makevars.win" -f
> "D:/RCompile/recent/R/etc/i386/Makeconf" -f   
> "D:/RCompile/recent/R/etc/i386/Makevars.site"
> -f "D:/RCompile/recent/R/share/make/winshlib.mk"
>  SHLIB="IRISSeismic.dll" OBJECTS="parseMiniSEED.o"' had status 2
> >>   ERROR: compilation failed for package ‘IRISSeismic'
> >>
> >> It says it can’t find the command ar, which I don’t understand. This
> was my original Makevars.win file:
> >>
> >>   PKG_CFLAGS=
> >>   PKG_CPPFLAGS=-Ilibmseed
> >>   PKG_LIBS=-Llibmseed -lmseed
> >>   $(SHLIB): libmseed/libmseed.a
> >>   libmseed/libmseed.a:
> >>  @(cd libmseed && $(MAKE) static CC="$(CC)" CFLAGS="$(CFLAGS)”)
> >>   clean:
> >>  @(cd libmseed && $(MAKE) clean)
> >>
> >> and I also tried it using the following with the same results:
> >>
> >>   libmseed/libmseed.a:
> >>  @(cd libmseed && $(MAKE) static CC="$(CC)" CFLAGS="$(CFLAGS)”
> AR="$(AR)")
> >>
> >> A google search turned up nothing and a stackoverflow question has not
> had any responses yet. Is there something I’m missing? And is there any
> other relevant information I can provide? I don’t have much experience
> compiling C code, but it works on Mac OSX and Linux.
> >
> > It's just what it said:  you don't have ar on your path.  Normally the
> $(AR) variable is set to $(BINPREF)ar.  Perhaps you've changed
> R_HOME/etc/Makeconf so that isn't true, or have overridden BINPREF with a
> value different from the default.
> >
> > Duncan Murdoch
> >
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[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] --as-cran URL check

[William Dunlap]

I'm sorry, I hadn't noticed that the URL checks were not done because
of the note
   Checking URLs requires 'libcurl' support in the R build
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Dec 14, 2015 at 6:15 PM, Paul Gilbert <pgilbert...@gmail.com> wrote:
> No, that what I meant by "percent signs escaped". It just gets me back to
> the status 500 error. I think Dirk may be correct that it is a bug in the
> --as-can URL check.
>
> Paul
>
>
> On 12/14/2015 09:10 PM, William Dunlap wrote:
>>
>> Put backslashes in front of the percent signs in the Rd file's URL:
>>
>> \url{http://www.rug.nl/research/portal/publications/pub\%28d7d4ea3d-af1d-487a-b9b6-c0816994ef5a\%29.html}
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Mon, Dec 14, 2015 at 4:46 PM, Paul Gilbert <pgilbert...@gmail.com>
>> wrote:
>>>
>>>
>>> I am having some trouble with a NOTE produced by an R-devel check of URL
>>> references. The reference was
>>>
>>>   \url{http://som.eldoc.ub.rug.nl/reports/themeF/2005/05F10/}
>>>
>>> which the --as-cran check finds has moved and notifies about the
>>> redirected
>>> address
>>>
>>>
>>>
>>> http://www.rug.nl/research/portal/publications/pub(d7d4ea3d-af1d-487a-b9b6-c0816994ef5a).html
>>>
>>> My browser finds this, and does not distinguish it from
>>>
>>>
>>>
>>> http://www.rug.nl/research/portal/publications/pub%28d7d4ea3d-af1d-487a-b9b6-c0816994ef5a%29.html
>>>
>>> However, I cannot get either of these forms of the new address to work in
>>> the man page and/or CITATION file  \url{}. The first gives
>>>
>>> Found the following (possibly) invalid URLs:
>>>URL:
>>>
>>> http://www.rug.nl/research/portal/publications/pub(d7d4ea3d-af1d-487a-b9b6-c0816994ef5a).html
>>>  From: man/estFAmodel.Rd
>>>man/estTSFmodel.Rd
>>>man/tsfa-package.Rd
>>>inst/CITATION
>>>  Status: 500
>>>  Message: Internal Server Error
>>>
>>> even though I can cut and paste that address from the error message into
>>> my
>>> browser and it works fine. The second form results in a problem parsing
>>> the
>>> Rd file, the end of the section is not recognized and for the next
>>> section I
>>> get "unexpected section header '\examples'". I think the percent signs
>>> cause
>>> the end of the line with the closing } to be treated as a comment, but if
>>> I
>>> put the } on a new line the status 500 occurs. With the percent signs
>>> escaped in the second form I get the status 500 error message as in the
>>> first form.
>>>
>>> Is this a bug in the R-devel --as-cran URL check, or does anyone see
>>> something I am missing?
>>>
>>> Thanks,
>>> Paul Gilbert
>>>
>>> __
>>> 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

Re: [R-pkg-devel] Visible bindings and reference classes

[William Dunlap]

You can avoid the temporary file by replacing
  dput(def, file= (tf - tempfile()))
  compiler::cmpfile(tf)
with
  cdef - compiler::compile(def)
  #Note: no visible binding for '-' assignment to 'ConfigString'
The compiled code appears to work.
  eval(cdef)
  c1 - Config$new()
  c1
  #Reference class object of class Config
  #Field ConfigString:
  #[1] Hello, World!
   objects(all=TRUE)
  #[1] .__C__Config   .__global__
  #[3] .requireCachedGenerics c1
  #[5] cdef   Config
  #[7] def


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Tue, Aug 11, 2015 at 8:47 AM, William Dunlap wdun...@tibco.com wrote:

 This is a problem in the compiler package.  Here is a way to reproduce it:

 def - quote(Config - setRefClass(Config,
 fields = list(
 ConfigString = character),
 methods = list(
 # Constructor
 initialize = function() {
 ConfigString - Hello, World!
 })
 ))
 dput(def, file= (tf - tempfile()))
 compiler::cmpfile(tf)
 #Note: no visible binding for '-' assignment to 'ConfigString'
 saving to file
 #C:\Users\wdunlap\AppData\Local\Temp\Rtmpk91qvT\file26d447c45b81.Rc ...
 done




 Bill Dunlap
 TIBCO Software
 wdunlap tibco.com

 On Tue, Aug 11, 2015 at 4:24 AM, Martin Maechler 
 maech...@stat.math.ethz.ch wrote:

  Colin Gillespie csgilles...@gmail.com
  on Mon, 10 Aug 2015 20:33:32 + writes:

  Dear All,
 
  I have a package that uses reference classes. When I build the package I
  get numerous notes of the sort
 
  Note: no visible binding for '-' assignment to 'pars'
 
  I've tried using GlobalVariables, but that didn't solve the issue.

 [ You mean globalVariables(): and it's a bad idea anyway IMO,
   even if it is recommended : If you declare a variable in
   there, it is global in all places in your package and the
   codetools won't report it anywhere anymore.
   Much better in my view is to use something like

   var7 - NULL # ~= globalVariables(var7)

 ]

 To your question:

 Reference classes are used in *many* places,  and the use of  ' - '
 is really standard there.
 e.g., package 'lme4', or 'pcalg' are two packages I'm involved with,
 which use ref.classes and ' - '  but are fine with that.

 So there must be something peculiar in your package leading to
 the  -  warnings.

 Maybe you should look into the source code of such other CRAN
 packages to see how they do it differently than you.

 Best regards,
 Martin

 Martin Maechler, ETH Zurich


  After some googling, I came across the page
  http://stackoverflow.com/q/23475309/203420 which suggests
 
  suppressBindingNotes - function(variablesMentionedInNotes) {
for(variable in variablesMentionedInNotes) {
  assign(variable,NULL, envir = .GlobalEnv)
}
  }
  suppressBindingNotes(c(dat, internal, xmin, pars, no_pars))
 
  But checking the package with --as-cran raises the note
 
  * checking R code for possible problems ... NOTE
  Found the following assignments to the global environment:
File ‘poweRlaw/R/aaa_all_classes.R’:
assign(variable, NULL, envir = .GlobalEnv)
 
  What is the correct way of removing the visible bindings notes?
 
  Thanks
 
  Colin
 
[[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




[[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] Visible bindings and reference classes

[William Dunlap]

This is a problem in the compiler package.  Here is a way to reproduce it:

def - quote(Config - setRefClass(Config,
fields = list(
ConfigString = character),
methods = list(
# Constructor
initialize = function() {
ConfigString - Hello, World!
})
))
dput(def, file= (tf - tempfile()))
compiler::cmpfile(tf)
#Note: no visible binding for '-' assignment to 'ConfigString'
saving to file
#C:\Users\wdunlap\AppData\Local\Temp\Rtmpk91qvT\file26d447c45b81.Rc ...
done




Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Tue, Aug 11, 2015 at 4:24 AM, Martin Maechler maech...@stat.math.ethz.ch
 wrote:

  Colin Gillespie csgilles...@gmail.com
  on Mon, 10 Aug 2015 20:33:32 + writes:

  Dear All,
 
  I have a package that uses reference classes. When I build the package I
  get numerous notes of the sort
 
  Note: no visible binding for '-' assignment to 'pars'
 
  I've tried using GlobalVariables, but that didn't solve the issue.

 [ You mean globalVariables(): and it's a bad idea anyway IMO,
   even if it is recommended : If you declare a variable in
   there, it is global in all places in your package and the
   codetools won't report it anywhere anymore.
   Much better in my view is to use something like

   var7 - NULL # ~= globalVariables(var7)

 ]

 To your question:

 Reference classes are used in *many* places,  and the use of  ' - '
 is really standard there.
 e.g., package 'lme4', or 'pcalg' are two packages I'm involved with,
 which use ref.classes and ' - '  but are fine with that.

 So there must be something peculiar in your package leading to
 the  -  warnings.

 Maybe you should look into the source code of such other CRAN
 packages to see how they do it differently than you.

 Best regards,
 Martin

 Martin Maechler, ETH Zurich


  After some googling, I came across the page
  http://stackoverflow.com/q/23475309/203420 which suggests
 
  suppressBindingNotes - function(variablesMentionedInNotes) {
for(variable in variablesMentionedInNotes) {
  assign(variable,NULL, envir = .GlobalEnv)
}
  }
  suppressBindingNotes(c(dat, internal, xmin, pars, no_pars))
 
  But checking the package with --as-cran raises the note
 
  * checking R code for possible problems ... NOTE
  Found the following assignments to the global environment:
File ‘poweRlaw/R/aaa_all_classes.R’:
assign(variable, NULL, envir = .GlobalEnv)
 
  What is the correct way of removing the visible bindings notes?
 
  Thanks
 
  Colin
 
[[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


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel