Re: [R-pkg-devel] Error in creating virtual environment on Debian machines

[Ivan Krylov via R-package-devel]

Hello Taeyong and welcome to R-package-devel!

В Thu, 5 Sep 2024 23:40:00 +0300
Taeyong Park  пишет:

>   # Define paths
>   venv_path <- file.path(Sys.getenv("HOME"), ".virtualenvs",
> "pytrends-in-r-new")
>   python_path <- file.path(venv_path, "bin", "python")

Please don't require placing the virtual environments under
~/.virtualenvs. 'reticulate' will use this path as a default if you only
provide the name of the virtual environment, but will also let the user
configure virtualenv_root() using environment variables.

>   TrendReq <<- reticulate::import("pytrends.request", delay_load =
> TRUE)$TrendReq
>   ResponseError <<- reticulate::import("pytrends.exceptions",
> delay_load = TRUE)$ResponseError

I'm afraid this defeats the purpose of 'delay_load' by immediately
accessing the module object and forcing 'reticulate' to load it.

I understand the desire to get everything working automatically right
when the package is loaded, but Python dependency management is a
complex topic and not all of it is safe to perform from .onLoad. In
particular, if .onLoad fails, you don't get to let the user call
PytrendsLongitudinalR::install_pytrends() because the namespace will
not be available. Try following the guidance in the 'reticulate'
vignettes [1]:

1. In .onLoad, only express a soft preference for a named virtual
environment and create but do not access lazy-load Python module
objects:

.onLoad <- function(libname, pkgname) {
 use_virtualenv("pytrends-in-r-new", required = FALSE)
 pytrends.request <<- reticulate::import("pytrends.request", delay_load
= TRUE)
 pd <<- reticulate::import("pandas", delay_load = TRUE)
 # and so on
}

2. Move all the installation work into a separate function:

install_pytrends <- function(envname = "pytrends-in-r-new", ...)
 # the vignette suggests wiping the "pytrends-in-r-new" venv here,
 # just in case
 py_install(
  c("pandas", "requests", "pytrends", "rich"),
  envname = envname, ...
 )

3. In tests and examples, wrap all uses of Python in checks for
py_module_available(...). In regular code, you can suggest running
install_pytrends(), but don't run it for the user. _Automatically_
installing additional software, whether Python modules or Python
itself, is prohibited by the CRAN policy [2]:

>> Packages should not write in the user’s home filespace <...> nor
>> anywhere else on the file system apart from the R session’s
>> temporary directory (or during installation in the location pointed
>> to by TMPDIR: and such usage should be cleaned up). <...>
>> Limited exceptions may be allowed in interactive sessions if the
>> package obtains confirmation from the user.

Admittedly, this complicates the tests and the examples for your
package with boilerplate. I see that 'tensorflow', for example, wraps
all its examples in \dontrun{}, but it's an exceptional package. A few
other packages that depend on 'reticulate' that I've just taken a look
at do wrap their examples in checks for the Python packages being
available.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/package=reticulate/vignettes/package.html
https://cran.r-project.org/package=reticulate/vignettes/python_dependencies.html

[2]
https://cran.r-project.org/web/packages/policies.html

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

[R-pkg-devel] Error in creating virtual environment on Debian machines

[Taeyong Park]

Hello,

I am trying to create a virtual environment in the zzz.r file of my
package, and my package is currently passing on Windows and failing on
Debian with 1 ERROR.


This is the ERROR:

* installing *source* package ‘PytrendsLongitudinalR’ ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Using Python: /usr/bin/python3.12
Creating virtual environment '/home/hornik/.virtualenvs/pytrends-in-r-new' ...
+ /usr/bin/python3.12 -m venv /home/hornik/.virtualenvs/pytrends-in-r-new
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt install python3.12-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: /home/hornik/.virtualenvs/pytrends-in-r-new/bin/python3.12

FAILED
Error: package or namespace load failed for ‘PytrendsLongitudinalR’:
 .onLoad failed in loadNamespace() for 'PytrendsLongitudinalR', details:
  call: NULL
  error: Error creating virtual environment
'/home/hornik/.virtualenvs/pytrends-in-r-new' [error code 1]
Error: loading failed
Execution halted
ERROR: loading failed
* removing 
‘/srv/hornik/tmp/CRAN_pretest/PytrendsLongitudinalR.Rcheck/PytrendsLongitudinalR’

and this is the onLoad function of my zzz.r file:


.onLoad <- function(libname, pkgname) {


  # Define paths
  venv_path <- file.path(Sys.getenv("HOME"), ".virtualenvs",
"pytrends-in-r-new")
  python_path <- file.path(venv_path, "bin", "python")

  # Ensure 'virtualenv' is installed
  if (!reticulate::py_module_available("virtualenv")) {
reticulate::py_install("virtualenv")
  }


  # Check if the virtual environment exists
  if (!reticulate::virtualenv_exists(venv_path)) {
# If it doesn't exist, attempt to create it
tryCatch({
  reticulate::virtualenv_create(envname = venv_path, python =
python_path, force = TRUE, module =
getOption("reticulate.virtualenv.module"))
}, error = function(e) {
  # Fallback: install Python and create the virtual environment
  reticulate::virtualenv_create(envname = venv_path, force = TRUE,
module = getOption("reticulate.virtualenv.module"))
})
  }

  # Use the virtual environment for reticulate operations
  reticulate::use_virtualenv(venv_path, required = TRUE)

  # Install packages if not already installed
  packages_to_install <- c("pandas", "requests", "pytrends", "rich")
  for (package in packages_to_install) {
if (!reticulate::py_module_available(package)) {
  reticulate::py_install(package, envname = "pytrends-in-r-new")
}
  }


  TrendReq <<- reticulate::import("pytrends.request", delay_load =
TRUE)$TrendReq
  ResponseError <<- reticulate::import("pytrends.exceptions",
delay_load = TRUE)$ResponseError
  pd <<- reticulate::import("pandas", delay_load = TRUE)
  os <<- reticulate::import("os", delay_load = TRUE)
  glob <<- reticulate::import("glob", delay_load = TRUE)
  json <<- reticulate::import("json", delay_load = TRUE)
  requests <<- reticulate::import("requests", delay_load = TRUE)
  dt <<- reticulate::import("datetime", delay_load = TRUE)
  relativedelta <<- reticulate::import("dateutil.relativedelta",
delay_load = TRUE)
  time <<- reticulate::import("time", delay_load = TRUE)
  logging <<- reticulate::import("logging", delay_load = TRUE)
  console <<- reticulate::import("rich.console", delay_load = TRUE)$Console
  RichHandler <<- reticulate::import("rich.logging", delay_load =
TRUE)$RichHandler
  math <<- reticulate::import("math", delay_load = TRUE)
  platform <<- reticulate::import("platform", delay_load = TRUE)

  # Configure logging
  configure_logging()
}

How do I ensure that the virtual environment is created properly on
Debian systems?  I tried the instructions in the error message but
still got the error.

Thank you in advance for your help!


Best,

Taeyong




*Taeyong Park, Ph.D.*
*Assistant Teaching Professor of Statistics*
*Director, Statistical Consulting Center*
*Carnegie Mellon University Qatar*

[[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 handling in C code

[Jarrod Hadfield]

Hi,

Using Rf_error() rather than error() fixed the problem. Not sure why the 
problem was only flagged on Debian, but it seems to have been triggered by 
R_NO_REMAP being defined (which will be default in R 4.5.0).

Thanks for the help.

Jarrod

From: Simon Urbanek 
Date: Monday, 6 May 2024 at 03:38
To: Jarrod Hadfield 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Error handling in C code
This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that the email 
is genuine and the content is safe.

Jarrod,

could you point us to the code? There is not much to go by based on your email. 
One thing just in general: it's always safer to not re-map function names, 
especially since "error" can be defined in many random other headers, so it's 
better to use Rf_error() instead to avoid confusions with 3rd party headers 
that may (re-)define the "error" macro (depending on the order you include them 
in).

Cheers,
Simon


> On 4/05/2024, at 3:17 AM, Jarrod Hadfield  wrote:
>
> Hi,
>
> I have an R library with C code in it. It has failed the CRAN checks for 
> Debian.  The problem is with the error function being undefined. Section 6.2 
> of the Writing R extensions (see below) suggests error handling can be 
> handled by error and the appropriate header file is included in R.h, but this 
> seems not to be the case?
>
> Any help would be appreciated!
>
> Thanks,
>
> Jarrod
>
> 6.2 Error signaling
>
> The basic error signaling routines are the equivalents of stop and warning in 
> R code, and use the same interface.
>
> void error(const char * format, ...);
> void warning(const char * format, ...);
> void errorcall(SEXP call, const char * format, ...);
> void warningcall(SEXP call, const char * format, ...);
> void warningcall_immediate(SEXP call, const char * format, ...);
>
> These have the same call sequences as calls to printf, but in the simplest 
> case can be called with a single character string argument giving the error 
> message. (Don�t do this if the string contains �%� or might otherwise be 
> interpreted as a format.)
>
> These are defined in header R_ext/Error.h included by R.h.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th� ann an 
> Oilthigh Dh�n �ideann, cl�raichte an Alba, �ireamh cl�raidh SC005336.
>
>   [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C02%7C%7C27d13d00316a466dc91f08dc6d759134%7C2e9f06b016694589878910a06934dc61%7C0%7C0%7C638505599232790068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bhr0SQN0UJq4FQgEgboltgm6dH1wo5aonYTDqRvsf2g%3D&reserved=0<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 handling in C code

[Simon Urbanek]

Jarrod,

could you point us to the code? There is not much to go by based on your email. 
One thing just in general: it's always safer to not re-map function names, 
especially since "error" can be defined in many random other headers, so it's 
better to use Rf_error() instead to avoid confusions with 3rd party headers 
that may (re-)define the "error" macro (depending on the order you include them 
in).

Cheers,
Simon


> On 4/05/2024, at 3:17 AM, Jarrod Hadfield  wrote:
> 
> Hi,
> 
> I have an R library with C code in it. It has failed the CRAN checks for 
> Debian.  The problem is with the error function being undefined. Section 6.2 
> of the Writing R extensions (see below) suggests error handling can be 
> handled by error and the appropriate header file is included in R.h, but this 
> seems not to be the case?
> 
> Any help would be appreciated!
> 
> Thanks,
> 
> Jarrod
> 
> 6.2 Error signaling
> 
> The basic error signaling routines are the equivalents of stop and warning in 
> R code, and use the same interface.
> 
> void error(const char * format, ...);
> void warning(const char * format, ...);
> void errorcall(SEXP call, const char * format, ...);
> void warningcall(SEXP call, const char * format, ...);
> void warningcall_immediate(SEXP call, const char * format, ...);
> 
> These have the same call sequences as calls to printf, but in the simplest 
> case can be called with a single character string argument giving the error 
> message. (Don�t do this if the string contains �%� or might otherwise be 
> interpreted as a format.)
> 
> These are defined in header R_ext/Error.h included by R.h.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th� ann an 
> Oilthigh Dh�n �ideann, cl�raichte an Alba, �ireamh cl�raidh SC005336.
> 
>   [[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 handling in C code

[Duncan Murdoch]

Most functions in R have a prefix on their name, with aliases defined so 
you can use the function without the prefix.  But you can turn off the 
aliasing, in which case you need the true name.  I think for all of the 
functions you list the prefix is "Rf_", so they are "Rf_error", etc.


Perhaps you turned off the aliasing?

Duncan Murdoch

On 03/05/2024 11:17 a.m., Jarrod Hadfield wrote:

Hi,

I have an R library with C code in it. It has failed the CRAN checks for 
Debian.  The problem is with the error function being undefined. Section 6.2 of 
the Writing R extensions (see below) suggests error handling can be handled by 
error and the appropriate header file is included in R.h, but this seems not to 
be the case?

Any help would be appreciated!

Thanks,

Jarrod

6.2 Error signaling

The basic error signaling routines are the equivalents of stop and warning in R 
code, and use the same interface.

void error(const char * format, ...);
void warning(const char * format, ...);
void errorcall(SEXP call, const char * format, ...);
void warningcall(SEXP call, const char * format, ...);
void warningcall_immediate(SEXP call, const char * format, ...);

These have the same call sequences as calls to printf, but in the simplest case 
can be called with a single character string argument giving the error message. 
(Don�t do this if the string contains �%� or might otherwise be interpreted as 
a format.)

These are defined in header R_ext/Error.h included by R.h.
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th� ann an Oilthigh 
Dh�n �ideann, cl�raichte an Alba, �ireamh cl�raidh SC005336.

[[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-pkg-devel] Error handling in C code

[Jarrod Hadfield]

Hi,

I have an R library with C code in it. It has failed the CRAN checks for 
Debian.  The problem is with the error function being undefined. Section 6.2 of 
the Writing R extensions (see below) suggests error handling can be handled by 
error and the appropriate header file is included in R.h, but this seems not to 
be the case?

Any help would be appreciated!

Thanks,

Jarrod

6.2 Error signaling

The basic error signaling routines are the equivalents of stop and warning in R 
code, and use the same interface.

void error(const char * format, ...);
void warning(const char * format, ...);
void errorcall(SEXP call, const char * format, ...);
void warningcall(SEXP call, const char * format, ...);
void warningcall_immediate(SEXP call, const char * format, ...);

These have the same call sequences as calls to printf, but in the simplest case 
can be called with a single character string argument giving the error message. 
(Don�t do this if the string contains �%� or might otherwise be interpreted as 
a format.)

These are defined in header R_ext/Error.h included by R.h.
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th� ann an Oilthigh 
Dh�n �ideann, cl�raichte an Alba, �ireamh cl�raidh SC005336.

[[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 windows R-devel builder, but not anywhere else

[Duncan Murdoch]

Looks like this recent change to R-devel has caught you:

  \code{is.atomic(NULL)} now returns \code{FALSE}, as \code{NULL}
  is not an atomic vector.  Strict back-compatibility would
  replace \code{is.atomic(foo)} by \code{(is.null(foo) || 
is.atomic(foo))}

  but should happen only sparingly.

I don't know why you didn't see this on the other platforms; maybe they 
just haven't been rebuilt recently.


Duncan Murdoch

On 13/04/2024 5:35 a.m., Tony Wilkes wrote:

Hi everyone,

I am updating my R package (tinycodet), and I have checked my R-package in all 
operating systems (Linux, Mac, Windows). All examples and tests run correctly 
for Linux, Mac, and Windows.  Rcmd checks also finds no issues on GitHub (I use 
rather strict Rcmdcheck workflows on GitHub, so any issues should be found 
quickly on GitHub; see https://github.com/tony-aw/tinycodet). But on the Win 
R-devel builder, I get an error. I use a Windows computer myself, and I can see 
where the error takes place on the win R-devel-builder, but I cannot reproduce 
the error. The error should not even be there.

The error takes place in the function `strfind(x, p, ..., i, rt)<-`. When the user specifies an 
incorrect string for the optional argument `rt`, the error message "improper `rt​`given" is 
called. This is also the error message that occurs in Win R-devel Builder, but it shouldn't be there, 
since no incorrect string is specified for "rt" there - otherwise, all operating systems 
would give an error there.
Link to win R-devel builder results: 
https://win-builder.r-project.org/2mG2vk48tri3/

My package has no Operating System specific functionality.

The fact that this error ONLY happens on win R-devel builder, and not when I 
run it on my windows laptop, nor on any other OS, nor on the many checks on 
GitHub, implies the issue might be on the Windows R-devel builder. But I don't 
want to jump to conclusions. Hence my question is:
Is there currently an issue in win R-devel-builder? If not, why is the error 
only on win R-devel-builder, and not anywhere else?

Thanks in advance for your help.

Kind regards,

Tony

[[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-pkg-devel] error in windows R-devel builder, but not anywhere else

[Tony Wilkes]

Hi everyone,

I am updating my R package (tinycodet), and I have checked my R-package in all 
operating systems (Linux, Mac, Windows). All examples and tests run correctly 
for Linux, Mac, and Windows.  Rcmd checks also finds no issues on GitHub (I use 
rather strict Rcmdcheck workflows on GitHub, so any issues should be found 
quickly on GitHub; see https://github.com/tony-aw/tinycodet). But on the Win 
R-devel builder, I get an error. I use a Windows computer myself, and I can see 
where the error takes place on the win R-devel-builder, but I cannot reproduce 
the error. The error should not even be there.

The error takes place in the function `strfind(x, p, ..., i, rt)<-`. When the 
user specifies an incorrect string for the optional argument `rt`, the error 
message "improper `rt​`given" is called. This is also the error message that 
occurs in Win R-devel Builder, but it shouldn't be there, since no incorrect 
string is specified for "rt" there - otherwise, all operating systems would 
give an error there.
Link to win R-devel builder results: 
https://win-builder.r-project.org/2mG2vk48tri3/

My package has no Operating System specific functionality.

The fact that this error ONLY happens on win R-devel builder, and not when I 
run it on my windows laptop, nor on any other OS, nor on the many checks on 
GitHub, implies the issue might be on the Windows R-devel builder. But I don't 
want to jump to conclusions. Hence my question is:
Is there currently an issue in win R-devel-builder? If not, why is the error 
only on win R-devel-builder, and not anywhere else?

Thanks in advance for your help.

Kind regards,

Tony

[[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 building MixAll on Windows platform

[Tomas Kalibera]

On 1/19/24 15:18, Serge wrote:
This post is a continuation of the post *[R-pkg-devel] Does 
dependencies up to date on the pretest CRAN infrastructure*


I made more (unsuccessful) tries:

- I installed a Windows 11 version in a VM on my compuiter and try to 
buid the MixAll package using Rtools42 and Rtools43 (it's quite easy, 
and funny, to do it on windows: you have just to rename C:\rtools42 as 
C:\rtools43).
There should be no renaming, instead, one should use R 4.2.x with 
Rtools42 and R 4.3.x (or current R-devel) with Rtools43. All of these 
can co-exist (be installed at the same time). Mixing the two could lead 
to different failures. I understand you want to test different versions 
of GCC, but to do that reliable you would have to rebuild the rest of 
Rtools with that, or just the part that is needed by the package.


The result is that MixAll is build using the 4.2 version and the buid 
failed using the 4.3 version.

Please make sure to use Rtools43 (the real one) with R 4.3.


- I installed the version 12.3 of gcc on ubuntu (the same version used 
on windows) and could build the package without problem


- Inspecting the log of the Rtools4.3 
(https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html) and 
g++12..3 (https://gcc.gnu.org/gcc-12/changes.html) does not give insight.


- The package is dependent of the rtkore package which use extensive 
use of templated class. As rtkore is a port for R of stk++, I try to 
compile the stk++ library on windows (using g++12). All tests are 
compiled without any troubles.


These attempts eliminate some causes, but don't give me any insight 
why MixAll (and blockcluster) failed to be build on the Windows-devel 
platform. It seems related to Rtools43. Does anyone else (using for 
exemple Rcppeigen) is experiencing this problem ?


If this is GCC running out of memory on Windows but not Linux, when 
there really should be enough of memory available (i.e. due to the 
problem that Uwe described, maybe the internal GC in GCC is asking for 
too much memory for its heap given that the OS is not overcomiting), you 
can try narrowing it down to a standalone C++ program (independent on R, 
Rtools, R packages, compilable on both Windows and Linux with disabled 
optimizations, etc) that still exhibits the problem and then submitting 
it in a bug report to GCC bugzilla.


In such case, it could be that some heuristics in the collector could be 
improved.


If you have such standalone example, it would be easier to test 
different versions of GCC or even bisect to a concrete GCC version. You 
might also compare memory usage when compiling and cross-compiling.


You might also be able to find a work-around for your package by 
disabling some compiler optimizations. Also if you can narrow this down 
to a concrete GCC optimization then it would help to mention that in the 
bug report.


Certainly all of this would be out of scope of R-(pkg)-devel, this would 
rather be a GCC/Windows thing.


Tomas



Serge



Le 14/01/2024 à 18:50, Uwe Ligges a écrit :



On 13.01.2024 15:01, Uwe Ligges wrote:
Fascinating, now it worked with the latest winbuilder submission 3 
times in a row when I checked it manually. So maybe Ivan was right 
and there was a very demanding set of other packages compiling at 
the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?


Really, I inspected some more. The underlying issue is simple:
The C++ compiler used under Windows asks for precomitted memory. If 
several processes are running at the same time, a lot of memory is 
precomitted. And Windows does not use it for other processes, even if 
almost nothing is actually used.
So while the used memory may be around 50GB, all of the rest (of 756 
GB including swap space) may have been precomitted (but unused) and 
new processes failed to start correctly. G.


Best,
Uwe Ligges






Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe 
calls. But this is a very wild guess.


Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:

After somme minor midficiations, I make a try on the winbuilder 
site.

I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); 
getchar();

so that almost all physical memory is allocated

3. Run gcc -DFO

[R-pkg-devel] ERROR building MixAll on Windows platform

[Serge]

This post is a continuation of the post *[R-pkg-devel] Does dependencies up to date on the pretest 
CRAN infrastructure*


I made more (unsuccessful) tries:

- I installed a Windows 11 version in a VM on my compuiter and try to buid the MixAll package using 
Rtools42 and Rtools43 (it's quite easy, and funny, to do it on windows: you have just to rename 
C:\rtools42 as C:\rtools43).

The result is that MixAll is build using the 4.2 version and the buid failed 
using the 4.3 version.

- I installed the version 12.3 of gcc on ubuntu (the same version used on windows) and could build 
the package without problem


- Inspecting the log of the Rtools4.3 
(https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html) and g++12..3 
(https://gcc.gnu.org/gcc-12/changes.html) does not give insight.


- The package is dependent of the rtkore package which use extensive use of templated class. As 
rtkore is a port for R of stk++, I try to compile the stk++ library on windows (using g++12). All 
tests are compiled without any troubles.


These attempts eliminate some causes, but don't give me any insight why MixAll (and blockcluster) 
failed to be build on the Windows-devel platform. It seems related to Rtools43. Does anyone else 
(using for exemple Rcppeigen) is experiencing this problem ?


Serge



Le 14/01/2024 à 18:50, Uwe Ligges a écrit :



On 13.01.2024 15:01, Uwe Ligges wrote:
Fascinating, now it worked with the latest winbuilder submission 3 times in a row when I checked 
it manually. So maybe Ivan was right and there was a very demanding set of other packages 
compiling at the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?


Really, I inspected some more. The underlying issue is simple:
The C++ compiler used under Windows asks for precomitted memory. If several processes are running at 
the same time, a lot of memory is precomitted. And Windows does not use it for other processes, even 
if almost nothing is actually used.
So while the used memory may be around 50GB, all of the rest (of 756 GB including swap space) may 
have been precomitted (but unused) and new processes failed to start correctly. G.


Best,
Uwe Ligges






Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But this 
is a very wild guess.

Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or more (depending in the 
machine) and additionally 500GB swap space on SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hard

Re: [R-pkg-devel] Error: [writeRaster] cannot write file

[Keshav, Krishna]

Hi,

This works. I think this is also an implementation of what Berry and Duncan 
suggested earlier. Thanks.

Best Regards,
Krishna Keshav

From: Iris Simmons 
Date: Monday, October 9, 2023 at 7:37 PM
To: Keshav, Krishna 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Error: [writeRaster] cannot write file
[External Email]
You wrote

# create the plots directory if it does not exist

but then created a directory named outdir/plots/typ_Sys.time.tif

You need to rewrite the code like:

plotsdir <- file.path(outdir, "plots")
fp <- file.path(plotsdir,  paste(typ, "_",
stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(plotsdir)) {
dir.create(plotsdir, recursive = TRUE)
  }

On Mon, Oct 9, 2023, 15:49 Keshav, Krishna 
mailto:kkes...@ufl.edu>> wrote:
Hi,

I am developing an R package where I need to save Raster file with .tif 
extension to the tempdir(). I am using terra::writeRaster for the same. While 
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {

  if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
  }

  # Save the plot as a raster file
  fp <- file.path(outdir, paste("plots", "/",
typ, "_",
stringr::str_replace_all(Sys.time(), 
"[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(fp)) {
dir.create(fp, recursive = TRUE)
  }

  terra::writeRaster(rast, overwrite = TRUE,
 filename = fp,
 gdal = c("COMPRESS=NONE"))
  message(paste("raster created", fp, sep = ": "), "\n")
}

Error �V

  Error: [writeRaster] cannot write file
   12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
   13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   15. �|�wterra (local) .local(x, filename, ...)
   16.   �|�wterra:::messages(x, "writeRaster")
   17. �|�wterra:::error(f, x@pnt$getError())



Best Regards,
Krishna Keshav

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org<mailto: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: [writeRaster] cannot write file

[Iris Simmons]

You wrote

# create the plots directory if it does not exist

but then created a directory named outdir/plots/typ_Sys.time.tif

You need to rewrite the code like:

plotsdir <- file.path(outdir, "plots")
fp <- file.path(plotsdir,  paste(typ, "_",
stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(plotsdir)) {
dir.create(plotsdir, recursive = TRUE)
  }

On Mon, Oct 9, 2023, 15:49 Keshav, Krishna  wrote:

> Hi,
>
> I am developing an R package where I need to save Raster file with .tif
> extension to the tempdir(). I am using terra::writeRaster for the same.
> While it works through R CMD check in mac, it is failing in R hub builder.
> Snippet ¡V
> .saverast <- function(typ, rast, outdir) {
>
>   if (is.null(outdir) || length(outdir) == 0) {
> outdir <- tempdir()
>   }
>
>   # Save the plot as a raster file
>   fp <- file.path(outdir, paste("plots", "/",
> typ, "_",
> stringr::str_replace_all(Sys.time(),
> "[^a-zA-Z0-9]", ""),
> ".tif", sep = ""))
> # Create the "plots" directory if it doesn't exist
>   if (!dir.exists(fp)) {
> dir.create(fp, recursive = TRUE)
>   }
>
>   terra::writeRaster(rast, overwrite = TRUE,
>  filename = fp,
>  gdal = c("COMPRESS=NONE"))
>   message(paste("raster created", fp, sep = ": "), "\n")
> }
>
> Error ¡V
>
>   Error: [writeRaster] cannot write file
>12. ¢|¢wgeohabnet:::.saverast(typ, rast, outdir)
>13.   ¢u¢wterra::writeRaster(rast, overwrite = TRUE, filename =
> fp, gdal = c("COMPRESS=NONE"))
>14.   ¢|¢wterra::writeRaster(rast, overwrite = TRUE, filename =
> fp, gdal = c("COMPRESS=NONE"))
>15. ¢|¢wterra (local) .local(x, filename, ...)
>16.   ¢|¢wterra:::messages(x, "writeRaster")
>17. ¢|¢wterra:::error(f, x@pnt$getError())
>
>
>
> Best Regards,
> Krishna Keshav
>
> [[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: [writeRaster] cannot write file

[Duncan Murdoch]

On 09/10/2023 6:56 p.m., Keshav, Krishna wrote:
Outdir is either a directory like getwd(), tempdir() etc or empty/null. 
If it is empty/null, then I set it to tempdir().


That doesn't answer the question, and the link you provided doesn't 
answer it either, as far as I can see.  In the test and the vignette 
that generated the errors, something specific was passed as outdir.  But 
what? If it was getwd(), that's bound to fail -- you don't have 
permission to write there.  tempdir() should have worked, but Berry 
pointed out some other things that might be problems.


Duncan Murdoch



/if (is.null(outdir) || length(outdir) == 0) {
     outdir <- tempdir()/

/}///

I am not sure how to debug when running it in Rbuilder. But you can look 
at results here - 
https://builder.r-hub.io/status/geohabnet_1.0.0.tar.gz-a2eaa40ccf1d026bbebf5077bfb482d5 <https://builder.r-hub.io/status/geohabnet_1.0.0.tar.gz-a2eaa40ccf1d026bbebf5077bfb482d5>


Best Regards,

Krishna Keshav

*From: *Duncan Murdoch 
*Date: *Monday, October 9, 2023 at 4:08 PM
*To: *Keshav, Krishna , r-package-devel@r-project.org 


*Subject: *Re: [R-pkg-devel] Error: [writeRaster] cannot write file

[External Email]

What were you using as "outdir"?


On 09/10/2023 2:59 p.m., Keshav, Krishna wrote:

Hi,

I am developing an R package where I need to save Raster file with .tif 
extension to the tempdir(). I am using terra::writeRaster for the same. While 
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {

    if (is.null(outdir) || length(outdir) == 0) {
  outdir <- tempdir()
    }

    # Save the plot as a raster file
    fp <- file.path(outdir, paste("plots", "/",
  typ, "_",
  stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]", 
""),
  ".tif", sep = ""))
  # Create the "plots" directory if it doesn't exist
    if (!dir.exists(fp)) {
  dir.create(fp, recursive = TRUE)
    }

    terra::writeRaster(rast, overwrite = TRUE,
   filename = fp,
   gdal = c("COMPRESS=NONE"))
    message(paste("raster created", fp, sep = ": "), "\n")
}

Error �V

    Error: [writeRaster] cannot write file
 12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
 13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal = 
c("COMPRESS=NONE"))
 14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal = 
c("COMPRESS=NONE"))
 15. �|�wterra (local) .local(x, filename, ...)
 16.   �|�wterra:::messages(x, "writeRaster")
 17. �|�wterra:::error(f, x@pnt$getError())



Best Regards,
Krishna Keshav

   [[alternative HTML version deleted]]


__
R-package-devel@r-project.org mailing list
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C01%7Ckkeshav%40ufl.edu%7Cddd83781762040d664dc08dbc9038ec7%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638324789348072931%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mBzV%2BSJoOTTnSpRzu0EvLT8sZ2NJ1OlhSGXqNCvGWB4%3D&reserved=0
 <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: [writeRaster] cannot write file

[Keshav, Krishna]

Outdir is either a directory like getwd(), tempdir() etc or empty/null. If it 
is empty/null, then I set it to tempdir().

if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
}
I am not sure how to debug when running it in Rbuilder. But you can look at 
results here - 
https://builder.r-hub.io/status/geohabnet_1.0.0.tar.gz-a2eaa40ccf1d026bbebf5077bfb482d5

Best Regards,
Krishna Keshav

From: Duncan Murdoch 
Date: Monday, October 9, 2023 at 4:08 PM
To: Keshav, Krishna , r-package-devel@r-project.org 

Subject: Re: [R-pkg-devel] Error: [writeRaster] cannot write file
[External Email]

What were you using as "outdir"?


On 09/10/2023 2:59 p.m., Keshav, Krishna wrote:
> Hi,
>
> I am developing an R package where I need to save Raster file with .tif 
> extension to the tempdir(). I am using terra::writeRaster for the same. While 
> it works through R CMD check in mac, it is failing in R hub builder.
> Snippet �V
> .saverast <- function(typ, rast, outdir) {
>
>if (is.null(outdir) || length(outdir) == 0) {
>  outdir <- tempdir()
>}
>
># Save the plot as a raster file
>fp <- file.path(outdir, paste("plots", "/",
>  typ, "_",
>  stringr::str_replace_all(Sys.time(), 
> "[^a-zA-Z0-9]", ""),
>  ".tif", sep = ""))
>  # Create the "plots" directory if it doesn't exist
>if (!dir.exists(fp)) {
>  dir.create(fp, recursive = TRUE)
>}
>
>terra::writeRaster(rast, overwrite = TRUE,
>   filename = fp,
>   gdal = c("COMPRESS=NONE"))
>message(paste("raster created", fp, sep = ": "), "\n")
> }
>
> Error �V
>
>Error: [writeRaster] cannot write file
> 12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
> 13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = 
> fp, gdal = c("COMPRESS=NONE"))
> 14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = 
> fp, gdal = c("COMPRESS=NONE"))
> 15. �|�wterra (local) .local(x, filename, ...)
> 16.   �|�wterra:::messages(x, "writeRaster")
> 17. �|�wterra:::error(f, x@pnt$getError())
>
>
>
> Best Regards,
> Krishna Keshav
>
>   [[alternative HTML version deleted]]
>
>
> __
> R-package-devel@r-project.org mailing list
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C01%7Ckkeshav%40ufl.edu%7Cddd83781762040d664dc08dbc9038ec7%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638324789348072931%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mBzV%2BSJoOTTnSpRzu0EvLT8sZ2NJ1OlhSGXqNCvGWB4%3D&reserved=0<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: [writeRaster] cannot write file

[Berry Boessenkool]

Are you intentionally running dir.exists on _file_names?
dir.exists("existing_folder/imaginary.file") shows FALSE, somwhat 
counterintuitively.
You might want to wrap the filenames in dirname...

Regards,
Berry

From: R-package-devel  on behalf of 
Keshav, Krishna 
Sent: Monday, October 9, 2023 20:59
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Error: [writeRaster] cannot write file

Hi,

I am developing an R package where I need to save Raster file with .tif 
extension to the tempdir(). I am using terra::writeRaster for the same. While 
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {

  if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
  }

  # Save the plot as a raster file
  fp <- file.path(outdir, paste("plots", "/",
typ, "_",
stringr::str_replace_all(Sys.time(), 
"[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(fp)) {
dir.create(fp, recursive = TRUE)
  }

  terra::writeRaster(rast, overwrite = TRUE,
 filename = fp,
 gdal = c("COMPRESS=NONE"))
  message(paste("raster created", fp, sep = ": "), "\n")
}

Error �V

  Error: [writeRaster] cannot write file
   12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
   13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   15. �|�wterra (local) .local(x, filename, ...)
   16.   �|�wterra:::messages(x, "writeRaster")
   17. �|�wterra:::error(f, x@pnt$getError())



Best Regards,
Krishna Keshav

[[alternative HTML version deleted]]


[[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: [writeRaster] cannot write file

[Duncan Murdoch]

What were you using as "outdir"?


On 09/10/2023 2:59 p.m., Keshav, Krishna wrote:

Hi,

I am developing an R package where I need to save Raster file with .tif 
extension to the tempdir(). I am using terra::writeRaster for the same. While 
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {

   if (is.null(outdir) || length(outdir) == 0) {
 outdir <- tempdir()
   }

   # Save the plot as a raster file
   fp <- file.path(outdir, paste("plots", "/",
 typ, "_",
 stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]", 
""),
 ".tif", sep = ""))
 # Create the "plots" directory if it doesn't exist
   if (!dir.exists(fp)) {
 dir.create(fp, recursive = TRUE)
   }

   terra::writeRaster(rast, overwrite = TRUE,
  filename = fp,
  gdal = c("COMPRESS=NONE"))
   message(paste("raster created", fp, sep = ": "), "\n")
}

Error �V

   Error: [writeRaster] cannot write file
12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal = 
c("COMPRESS=NONE"))
14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal = 
c("COMPRESS=NONE"))
15. �|�wterra (local) .local(x, filename, ...)
16.   �|�wterra:::messages(x, "writeRaster")
17. �|�wterra:::error(f, x@pnt$getError())



Best Regards,
Krishna Keshav

[[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-pkg-devel] Error: [writeRaster] cannot write file

[Keshav, Krishna]

Hi,

I am developing an R package where I need to save Raster file with .tif 
extension to the tempdir(). I am using terra::writeRaster for the same. While 
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {

  if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
  }

  # Save the plot as a raster file
  fp <- file.path(outdir, paste("plots", "/",
typ, "_",
stringr::str_replace_all(Sys.time(), 
"[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(fp)) {
dir.create(fp, recursive = TRUE)
  }

  terra::writeRaster(rast, overwrite = TRUE,
 filename = fp,
 gdal = c("COMPRESS=NONE"))
  message(paste("raster created", fp, sep = ": "), "\n")
}

Error �V

  Error: [writeRaster] cannot write file
   12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
   13.   �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   14.   �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, 
gdal = c("COMPRESS=NONE"))
   15. �|�wterra (local) .local(x, filename, ...)
   16.   �|�wterra:::messages(x, "writeRaster")
   17. �|�wterra:::error(f, x@pnt$getError())



Best Regards,
Krishna Keshav

[[alternative HTML version deleted]]

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

[R-pkg-devel] Error in find_vignette_product(name, by = "weave", dir = docdir, engine = engine)

[EcoC2S - Irucka Embry]

Hi, I am attempting to build my revised 'iemisc' package, but I am 
having trouble building one of the vignettes.


I am receiving the following error message:

* creating vignettes ...Error in find_vignette_product(name, by = 
"weave", dir = docdir, engine = engine) :
  Failed to locate ‘weave’ output file ‘Engineering_Survey_Examples.pdf’ 
or ‘Engineering_Survey_Examples.html’ for vignette with name 
‘Engineering_Survey_Examples’ and engine ‘knitr::rmarkdown’.



This is odd because the following command correctly produces the PDF of 
the document:


library("rmarkdown")
render("/vignettes/Engineering_Survey_Examples.Rmd", 
pdf_document(latex_engine = "xelatex"))


I have attached the .Rmd file for the vignette to this e-mail.

Thank you.

Irucka Embry

--
--
No fear, Only Love! / ¡No temas, solamente amor!
-Irucka Ajani Embry, 15 March 2020

Family Partners:
http://www.sustainlex.org/
https://www.schoolingsolutions.com/

---

The business collaboration between EConsulting (tm)
[https://www.econsultingllc.org/] and EcoC^2S, is Getting Back to 
Nature.


Getting Back to Nature LocalHarvest --
https://www.localharvest.org/getting-back-to-nature-M73453
Getting Back to Nature -- https://www.gettingback2nature.farm/

-- Irucka and his twin brother, Obiora, are featured in the Middle
Tennessee Local Table Magazine Annual issue. The article discusses their
family farm history and the current work that they are doing under 
Getting
Back to Nature. The full magazine can be found here [the article begins 
on

page 18 of the PDF document]:

https://media.gettingback2nature.farm/pdf/LocalTable_ANNUAL_2020_lo_res.pdf

-- Obiora and Irucka were interviewed separately in early 2020 for the
Natural Resources Defense Council's (NRDC) "Regenerative Agriculture: 
Farm
Policy for the 21st Century: Policy Recommendations to Advance 
Regenerative

Agriculture" report written By Arohi Sharma, Lara Bryant, and Ellen Lee.
The PDF report is available below:

https://www.nrdc.org/sites/default/files/regenerative-agriculture-farm-policy-21st-century-report.pdf

EcoC2S -- https://www.ecoccs.com/
Principal, Irucka Embry, EIT

Services:
Growing Food
Healthy Living Mentor
Data Analysis with R
R Training
Chemistry and Mathematics Tutoring
Free/Libre and Open Source Software (FLOSS) Consultation---
title: "iemisc: Engineering Survey Examples"
author: "Irucka Embry, E.I.T. (EcoC²S)"
date: "`r Sys.Date()`"
lang: en-us
urlcolor: blue
output:
  rmarkdown::pdf_document:
highlight: kate
toc: true
latex_engine: xelatex
vignette: >
  %\VignetteIndexEntry{iemisc Engineering Survey Examples}
  %\VignetteEngine{knitr::rmarkdown}
  \usepackage[utf8]{inputenc}
---

\bigskip

# Replicate the R code

Note: If you wish to replicate the R code below, then you will need to copy and 
paste the following commands in R first (to make sure you have the package and 
its dependencies):  

```{r eval = FALSE, tidy = TRUE}
install.packages("iemisc")
# install the package and its dependencies
```

\bigskip
\bigskip

```{r, warning = FALSE, message = FALSE, tidy = TRUE}
# load the required package
library("iemisc")
```

\bigskip
\bigskip

# Midpoint

## Examples

```{r, warning = FALSE, message = FALSE, tidy = TRUE}

Northing_begin <- 283715.8495
Easting_begin <- 1292428.3999

Northing_end <- 303340.6977
Easting_end <- 1295973.7743

project_midpoint(Northing_begin, Easting_begin, Northing_end, Easting_end, 
units =
"survey_ft", location = "TN", output = "advanced")




# Tennessee (TN) Northing and Easting in meters

Northing2 <- c(232489.480, 234732.431)

Easting2 <- c(942754.124, 903795.239)

dt4A <- project_midpoint(Northing2[1], Easting2[1], Northing2[2], Easting2[2],
"meters", "TN", output = "advanced")
dt4A
```

\bigskip
\bigskip
\bigskip
\bigskip

# Engineering Survey 1 (engr_survey)

## Example 1

```{r, warning = FALSE, message = FALSE, tidy = TRUE}

# Tennessee (TN) Northing and Easting in US Survey foot
Northing3 <- c("630817.6396", "502170.6065", "562,312.2349", "574,370.7178")

Easting3 <- c("2559599.9201", "1433851.6509", "1,843,018.4099", 
"1,854,896.0041")

dt3A <- engr_survey(Northing3[1], Easting3[1], "survey_ft", "TN", output =
"basic", utm = 1)
dt3A # first set of Northing, Easting points


dt3B <- engr_survey(Northing3[2], Easting3[2], "survey_ft", "TN", output =
"basic", utm = 0)
dt3B # second set of Northing, Easting points


dt3C <- engr_survey(Northing3[3], Easting3[3], "survey_ft", "TN", output =
"basic", utm = 1)
dt3C # third set of Northing, Easting points


dt3D <- engr_survey(Northing3[4], Easting3[4], "survey_ft", "TN", output =
"basic", utm = 0)
dt3D # fourth set of Northing, Easting points
```

\bigskip
\bigskip

## Example 2

```{r, warning = FALSE, message = FALSE, tidy = TRUE}

# Tennessee (TN) Northing and Easting in meters

Northing4 <- c(232489.480, 234732.431)

Easting4 <- c(942754.124, 903795.239)

dt4A <-

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Hello,

Many thanks for your reply.

Very helpful. I have made the necessary changes.

Regards,
Havisha

On Mon, Dec 5, 2022 at 12:01 PM Ivan Krylov  wrote:

> On Mon, 5 Dec 2022 11:14:19 +0400
> "Jahajeeah, Havisha"  wrote:
>
> > Will a binary package resolve the above issue?
>
> Due to an interaction between the way R binary packages work and the
> way you have implemented the Greymodels:::ui variable, this binary
> package will only work on your computer. (And, well, on other computers
> where the library path is the same.) A better workaround would be to
> ask your users to install the source package instead of installing the
> binary package when one is available for their platform.
>
> The code that creates the `ui` variable in your package is evaluated
> when the binary package is built by CRAN (or you). The resulting object
> contains file paths that are only valid on CRAN computers (or your
> computer). You need that code to run on users' computers after the
> package is installed, not on CRAN computers (or your computer) when
> it's built. In order to achieve that, you need to change the definition
> of the `ui` variable into a function. The function doesn't even have to
> take arguments; you can just prepend function() to the right-hand side
> of the assignment. Inside the `run_app` function, call that function
> instead of referring to that variable. This will make sure that the
> temporary object created by `ui()` contains the file paths from the
> user's computer.
>
> --
> Best regards,
> Ivan
>

[[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 uploading file on CRAN

[Ivan Krylov]

On Mon, 5 Dec 2022 11:14:19 +0400
"Jahajeeah, Havisha"  wrote:

> Will a binary package resolve the above issue?

Due to an interaction between the way R binary packages work and the
way you have implemented the Greymodels:::ui variable, this binary
package will only work on your computer. (And, well, on other computers
where the library path is the same.) A better workaround would be to
ask your users to install the source package instead of installing the
binary package when one is available for their platform.

The code that creates the `ui` variable in your package is evaluated
when the binary package is built by CRAN (or you). The resulting object
contains file paths that are only valid on CRAN computers (or your
computer). You need that code to run on users' computers after the
package is installed, not on CRAN computers (or your computer) when
it's built. In order to achieve that, you need to change the definition
of the `ui` variable into a function. The function doesn't even have to
take arguments; you can just prepend function() to the right-hand side
of the assignment. Inside the `run_app` function, call that function
instead of referring to that variable. This will make sure that the
temporary object created by `ui()` contains the file paths from the
user's computer.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Dear CRAN team,



I trust you are well.



Referring to the following issue I had when running the greymodels 2.0
package:



An error has occurred!

Couldn't normalize path in `addResourcePath`, with arguments: `prefix` =
'AdminLTE-2.0.6'; `directoryPath` =
'D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE'



I  used the following line code to build a binary package.



devtools::build(binary = TRUE)



A zip file is generated.



I opened the zip file from *"Install packages from local files”* in R and
the package seems to work.



I also went through the CRAN Repository Policy (
https://cran.r-project.org/web/packages/policies.html).


Will a binary package resolve the above issue? If yes, can I submit a
binary package to CRAN?


I look forward to hearing from you.


Many thanks,

Havisha

On Thu, Dec 1, 2022 at 7:36 PM Jahajeeah, Havisha 
wrote:

> Hello,
>
> Yes, the author is aware of the situation.
>
> We are currently working on resolving the issue.
>
> Thank you,
> Havisha
>
> On Thu, Dec 1, 2022 at 7:32 PM Uwe Ligges 
> wrote:
>
>>
>>
>> On 30.11.2022 14:18, Duncan Murdoch wrote:
>> > On 30/11/2022 7:56 a.m., Ivan Krylov wrote:
>> >> В Wed, 30 Nov 2022 16:10:22 +0400
>> >> "Jahajeeah, Havisha"  пишет:
>> >>
>> >>> How do I fix this problem? Kindly advise.
>> >>
>> >> I think I know what could be the problem.
>> >>
>> >> Your run_app function calls shiny::shinyApp(ui, server, options =
>> >> list(launch.browser = TRUE)). Here, `ui` is an object of class
>> >> "shiny.tag". I think that the file paths get cached in the `ui` object
>> >> when the binary package is built, and when the package is run on a
>> >> different computer, the loading process fails.
>> >
>> > That seems really likely.  When I run on a Mac, I see a directory on
>> the
>> > Mac build machine in the error message.
>>
>> Yep, have you reported this to the author of that package already? If
>> not, please do so.
>>
>> Best,
>> Uwe Ligges
>>
>>
>> >>
>> >> Does it work if you run install.packages('Greymodels', type =
>> 'source')?
>> >> If this works around the problem, you'll need to change the definition
>> >> of `ui` into a function to make sure it runs after the package is
>> >> installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.R
>> >>
>> >
>> > One warning:  make sure you run install.packages('Greymodels', type =
>> > 'source') in a new session, not in a session that already has
>> Greymodels
>> > loaded.
>> >
>> > 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] Error uploading file on CRAN

[Jahajeeah, Havisha]

Hello,

Yes, the author is aware of the situation.

We are currently working on resolving the issue.

Thank you,
Havisha

On Thu, Dec 1, 2022 at 7:32 PM Uwe Ligges 
wrote:

>
>
> On 30.11.2022 14:18, Duncan Murdoch wrote:
> > On 30/11/2022 7:56 a.m., Ivan Krylov wrote:
> >> В Wed, 30 Nov 2022 16:10:22 +0400
> >> "Jahajeeah, Havisha"  пишет:
> >>
> >>> How do I fix this problem? Kindly advise.
> >>
> >> I think I know what could be the problem.
> >>
> >> Your run_app function calls shiny::shinyApp(ui, server, options =
> >> list(launch.browser = TRUE)). Here, `ui` is an object of class
> >> "shiny.tag". I think that the file paths get cached in the `ui` object
> >> when the binary package is built, and when the package is run on a
> >> different computer, the loading process fails.
> >
> > That seems really likely.  When I run on a Mac, I see a directory on the
> > Mac build machine in the error message.
>
> Yep, have you reported this to the author of that package already? If
> not, please do so.
>
> Best,
> Uwe Ligges
>
>
> >>
> >> Does it work if you run install.packages('Greymodels', type = 'source')?
> >> If this works around the problem, you'll need to change the definition
> >> of `ui` into a function to make sure it runs after the package is
> >> installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.R
> >>
> >
> > One warning:  make sure you run install.packages('Greymodels', type =
> > 'source') in a new session, not in a session that already has Greymodels
> > loaded.
> >
> > 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] Error uploading file on CRAN

[Uwe Ligges]

On 30.11.2022 14:18, Duncan Murdoch wrote:

On 30/11/2022 7:56 a.m., Ivan Krylov wrote:

В Wed, 30 Nov 2022 16:10:22 +0400
"Jahajeeah, Havisha"  пишет:


How do I fix this problem? Kindly advise.


I think I know what could be the problem.

Your run_app function calls shiny::shinyApp(ui, server, options =
list(launch.browser = TRUE)). Here, `ui` is an object of class
"shiny.tag". I think that the file paths get cached in the `ui` object
when the binary package is built, and when the package is run on a
different computer, the loading process fails.


That seems really likely.  When I run on a Mac, I see a directory on the 
Mac build machine in the error message.


Yep, have you reported this to the author of that package already? If 
not, please do so.


Best,
Uwe Ligges




Does it work if you run install.packages('Greymodels', type = 'source')?
If this works around the problem, you'll need to change the definition
of `ui` into a function to make sure it runs after the package is
installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.R



One warning:  make sure you run install.packages('Greymodels', type = 
'source') in a new session, not in a session that already has Greymodels 
loaded.


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

Re: [R-pkg-devel] Error uploading file on CRAN

[Duncan Murdoch]

On 30/11/2022 7:56 a.m., Ivan Krylov wrote:

В Wed, 30 Nov 2022 16:10:22 +0400
"Jahajeeah, Havisha"  пишет:


How do I fix this problem? Kindly advise.


I think I know what could be the problem.

Your run_app function calls shiny::shinyApp(ui, server, options =
list(launch.browser = TRUE)). Here, `ui` is an object of class
"shiny.tag". I think that the file paths get cached in the `ui` object
when the binary package is built, and when the package is run on a
different computer, the loading process fails.


That seems really likely.  When I run on a Mac, I see a directory on the 
Mac build machine in the error message.




Does it work if you run install.packages('Greymodels', type = 'source')?
If this works around the problem, you'll need to change the definition
of `ui` into a function to make sure it runs after the package is
installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.R



One warning:  make sure you run install.packages('Greymodels', type = 
'source') in a new session, not in a session that already has Greymodels 
loaded.


Duncan Murdoch

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 16:10:22 +0400
"Jahajeeah, Havisha"  пишет:

> How do I fix this problem? Kindly advise.

I think I know what could be the problem.

Your run_app function calls shiny::shinyApp(ui, server, options =
list(launch.browser = TRUE)). Here, `ui` is an object of class
"shiny.tag". I think that the file paths get cached in the `ui` object
when the binary package is built, and when the package is run on a
different computer, the loading process fails.

Does it work if you run install.packages('Greymodels', type = 'source')?
If this works around the problem, you'll need to change the definition
of `ui` into a function to make sure it runs after the package is
installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.R

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Hello,

Yes I noticed that I did not reply to all. Apology.

Thank you for the reply and link to guide.

Does the D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE directory
exist?

The D:/RCompile... folder was never interacted with.

Has someone touched the shinydashboard package installation?

No one was to create or edit any folder when installing the package from
CRAN.

The user simply has to run the 3-line codes and the interface loads.

install.packages("Greymodels")
library(Greymodels)
run_app()

Does it help to remove and install shinydashboard again?

Uninstalling and reinstalling does not help either. The issue appears for
any individual installing the app.

The app did work on Monday when I installed from CRAN and now it does not
anymore.

How do I fix this problem? Kindly advise.

Thank you,
Havisha


On Wed, Nov 30, 2022 at 2:57 PM Ivan Krylov  wrote:

> В Wed, 30 Nov 2022 14:17:54 +0400
> "Jahajeeah, Havisha"  пишет:
>
> > To run the app, we use:
> >
> > install.packages("Greymodels")
> > library(Greymodels)
> > run_app()
> >
> > The app worked fine on Monday. Today it is showing error.
> >
> > Please see below  traceback()
> >
> > 13: execCallbacks(timeoutSecs, all, loop$id)
> > 12: run_now(timeoutMs/1000, all = FALSE)
> > 11: service(timeout)
> > 10: serviceApp()
> > 9: ..stacktracefloor..(serviceApp())
> > 8: withCallingHandlers(expr, error = doCaptureStack)
> > 7: domain$wrapSync(expr)
> > 6: promises::with_promise_domain(createStackTracePromiseDomain(),
> >expr)
> > 5: captureStackTraces({
> >while (!.globals$stopped) {
> >..stacktracefloor..(serviceApp())
> >}
> >})
> > 4: ..stacktraceoff..(captureStackTraces({
> >while (!.globals$stopped) {
> >..stacktracefloor..(serviceApp())
> >}
> >}))
> > 3: runApp(x)
> > 2: print.shiny.appobj(x)
> > 1: (function (x, ...)
> >UseMethod("print"))(x)
>
> Thanks!
>
> Does the D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE directory
> exist? Has someone touched the shinydashboard package installation?
> Does it help to remove and install shinydashboard again?
>
> Please keep the R-pkg-devel list in the recipients  when replying (use
> "reply to all").
>
> --
> Best regards,
> Ivan
>

[[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 uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 14:17:54 +0400
"Jahajeeah, Havisha"  пишет:

> To run the app, we use:
> 
> install.packages("Greymodels")
> library(Greymodels)
> run_app()
> 
> The app worked fine on Monday. Today it is showing error.
> 
> Please see below  traceback()
> 
> 13: execCallbacks(timeoutSecs, all, loop$id)
> 12: run_now(timeoutMs/1000, all = FALSE)
> 11: service(timeout)
> 10: serviceApp()
> 9: ..stacktracefloor..(serviceApp())
> 8: withCallingHandlers(expr, error = doCaptureStack)
> 7: domain$wrapSync(expr)
> 6: promises::with_promise_domain(createStackTracePromiseDomain(),
>expr)
> 5: captureStackTraces({
>while (!.globals$stopped) {
>..stacktracefloor..(serviceApp())
>}
>})
> 4: ..stacktraceoff..(captureStackTraces({
>while (!.globals$stopped) {
>..stacktracefloor..(serviceApp())
>}
>}))
> 3: runApp(x)
> 2: print.shiny.appobj(x)
> 1: (function (x, ...)
>UseMethod("print"))(x)

Thanks!

Does the D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE directory
exist? Has someone touched the shinydashboard package installation?
Does it help to remove and install shinydashboard again?

Please keep the R-pkg-devel list in the recipients  when replying (use
"reply to all").

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 13:43:21 +0400
"Jahajeeah, Havisha"  пишет:

> but now I am getting the following error:
> 
> An error has occurred!
> 
> Couldn't normalize path in `addResourcePath`, with arguments:
> `prefix` = 'AdminLTE-2.0.6'; `directoryPath` =
> 'D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE'

Thank you for providing the exact error message!

Could you please provide more information on _how_ you're getting the
error? In particular, (1) what do you do (lines of code you execute,
buttons you click and so on) before you get the error and (2) what you
expect to happen instead of the error? See also: a long guide on asking
technical questions [*]. It can be impossible to help with an error
message without the steps required to obtain it.

I can see that your package depends on shinydashboard, but I don't see
any calls to addResourcePath in your code. Is there a traceback you
could show us?

-- 
Best regards,
Ivan

[*] http://www.catb.org/~esr/faqs/smart-questions.html#beprecise

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Dear CRAN team,

I trust you are well.

The package 'Greymodels' worked fine the other day, but now I am getting
the following error:

An error has occurred!

Couldn't normalize path in `addResourcePath`, with arguments: `prefix` =
'AdminLTE-2.0.6'; `directoryPath` =
'D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE'

What could be the problem? Please help.

Thank you,

Havisha



On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:

> Dear CRAN team,
>
> The package 'Greymodels' has just been published on CRAN. After loading
> the package on CRAN, when I try to upload file (xlsx or xls)
> the following error appears:
>
> Error: cannot open the connection
>
> What could be the problem? Is it because of the working directory?
>
> Please advise on how to fix this.
>
> Many thanks,
> Havisha Jahajeeah
>

[[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 uploading file on CRAN

[Duncan Murdoch]

Thanks Spencer.  Yes, devtools does give good support for CRAN updates 
these days.


Duncan Murdoch

On 27/11/2022 12:07 p.m., Spencer Graves wrote:



On 11/27/22 10:44 AM, Duncan Murdoch wrote:

On 27/11/2022 11:29 a.m., Jahajeeah, Havisha wrote:

Dear CRAN team,

The Greymodels package has been debugged and the updated package has been
published on Github.

I would be very much grateful if the app could be updated on CRAN.


That needs to be done by the maintainer (that's you, I think), according
to the CRAN submission instructions here:
https://cran.r-project.org/web/packages/policies.html .  The last
section tells you how to do an update, but don't skip the earlier ones.

Duncan Murdoch



Thanks, Duncan.


  In addition to Duncan's comments, I perceive the development version
of Wickham and Bryan's "R Packages" to be also quite useful:


https://r-pkgs.org


  To make this simpler for me, I've summarized what I've gotten from
the CRAN source Duncan mentioned and from Wickham and Bryan in a file
with a name like "release_to_CRAN.R".  I add such a file to the packages
I maintain on GitHub, while adding that file name to ".Rbuildignore".
Anything in ".Rbuildignore" is available to me but is not submitted to
CRAN.  For an example of the current status of one such file, see:


https://github.com/sbgraves237/Ecdat/blob/master/Ecdat_release_to_CRAN.R


  Hope this helps.
  Spencer Graves





I look forward to hearing from you.

Thanking you and sincerely
Havisha Jahajeeah

On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:


Dear CRAN team,

The package 'Greymodels' has just been published on CRAN. After loading
the package on CRAN, when I try to upload file (xlsx or xls)
the following error appears:

Error: cannot open the connection

What could be the problem? Is it because of the working directory?

Please advise on how to fix this.

Many thanks,
Havisha Jahajeeah



 [[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] Error uploading file on CRAN

[Spencer Graves]

On 11/27/22 10:44 AM, Duncan Murdoch wrote:

On 27/11/2022 11:29 a.m., Jahajeeah, Havisha wrote:

Dear CRAN team,

The Greymodels package has been debugged and the updated package has been
published on Github.

I would be very much grateful if the app could be updated on CRAN.


That needs to be done by the maintainer (that's you, I think), according 
to the CRAN submission instructions here: 
https://cran.r-project.org/web/packages/policies.html .  The last 
section tells you how to do an update, but don't skip the earlier ones.


Duncan Murdoch



Thanks, Duncan.


	  In addition to Duncan's comments, I perceive the development version 
of Wickham and Bryan's "R Packages" to be also quite useful:



https://r-pkgs.org


	  To make this simpler for me, I've summarized what I've gotten from 
the CRAN source Duncan mentioned and from Wickham and Bryan in a file 
with a name like "release_to_CRAN.R".  I add such a file to the packages 
I maintain on GitHub, while adding that file name to ".Rbuildignore". 
Anything in ".Rbuildignore" is available to me but is not submitted to 
CRAN.  For an example of the current status of one such file, see:



https://github.com/sbgraves237/Ecdat/blob/master/Ecdat_release_to_CRAN.R


  Hope this helps.
  Spencer Graves





I look forward to hearing from you.

Thanking you and sincerely
Havisha Jahajeeah

On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:


Dear CRAN team,

The package 'Greymodels' has just been published on CRAN. After loading
the package on CRAN, when I try to upload file (xlsx or xls)
the following error appears:

Error: cannot open the connection

What could be the problem? Is it because of the working directory?

Please advise on how to fix this.

Many thanks,
Havisha Jahajeeah



[[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] Error uploading file on CRAN

[Duncan Murdoch]

On 27/11/2022 11:29 a.m., Jahajeeah, Havisha wrote:

Dear CRAN team,

The Greymodels package has been debugged and the updated package has been
published on Github.

I would be very much grateful if the app could be updated on CRAN.


That needs to be done by the maintainer (that's you, I think), according 
to the CRAN submission instructions here: 
https://cran.r-project.org/web/packages/policies.html .  The last 
section tells you how to do an update, but don't skip the earlier ones.


Duncan Murdoch



I look forward to hearing from you.

Thanking you and sincerely
Havisha Jahajeeah

On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:


Dear CRAN team,

The package 'Greymodels' has just been published on CRAN. After loading
the package on CRAN, when I try to upload file (xlsx or xls)
the following error appears:

Error: cannot open the connection

What could be the problem? Is it because of the working directory?

Please advise on how to fix this.

Many thanks,
Havisha Jahajeeah



[[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 uploading file on CRAN

[Ivan Krylov]

On Sun, 27 Nov 2022 20:29:10 +0400
"Jahajeeah, Havisha"  wrote:

> The Greymodels package has been debugged and the updated package has
> been published on Github.

Congratulations on getting it working!
 
> I would be very much grateful if the app could be updated on CRAN.

Please do it the same way you had uploaded the package initially after
changing the Version: field in the DESCRIPTION file to a higher value.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Dear CRAN team,

The Greymodels package has been debugged and the updated package has been
published on Github.

I would be very much grateful if the app could be updated on CRAN.

I look forward to hearing from you.

Thanking you and sincerely
Havisha Jahajeeah

On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:

> Dear CRAN team,
>
> The package 'Greymodels' has just been published on CRAN. After loading
> the package on CRAN, when I try to upload file (xlsx or xls)
> the following error appears:
>
> Error: cannot open the connection
>
> What could be the problem? Is it because of the working directory?
>
> Please advise on how to fix this.
>
> Many thanks,
> Havisha Jahajeeah
>

[[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 uploading file on CRAN

[Jahajeeah, Havisha]

Thank you for your help.

I will go through the guide.

Many thanks,
Havisha

On Mon, Nov 7, 2022 at 3:19 PM Ivan Krylov  wrote:

> В Mon, 7 Nov 2022 14:55:06 +0400
> "Jahajeeah, Havisha"  пишет:
>
> > The Greymodels package loads data from spreadsheets and each model
> > accepts a set of data and outputs the  values. However, the package
> > is unable to do that because of the error: cannot open connection.
>
> Thank you for clarifying the problem!
>
> The guide at https://shiny.rstudio.com/articles/debugging.html is full
> of useful things to try when a Shiny app is misbehaving. I could try to
> write an instruction for you to follow here, but it would end up being
> a paraphrase of this guide. If you follow the guide, you should be able
> to find out (1) which of your read_excel calls is failing, (2) what is
> its argument and (3) what actually ends up at that path at the time of
> the call. Once you know this information, the solution may become
> obvious, or at least there may be something for us to give you more
> pointers about.
>
> While there is a chance that someone else will come along, run your
> package on their machine and reproduce the problem, there's also a
> significant chance that no one will do that. Meanwhile, these steps are
> relatively simple and may help you solve the problem right away.
>
> --
> Best regards,
> Ivan
>

[[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 uploading file on CRAN

[Ivan Krylov]

В Mon, 7 Nov 2022 14:55:06 +0400
"Jahajeeah, Havisha"  пишет:

> The Greymodels package loads data from spreadsheets and each model
> accepts a set of data and outputs the  values. However, the package
> is unable to do that because of the error: cannot open connection.

Thank you for clarifying the problem!

The guide at https://shiny.rstudio.com/articles/debugging.html is full
of useful things to try when a Shiny app is misbehaving. I could try to
write an instruction for you to follow here, but it would end up being
a paraphrase of this guide. If you follow the guide, you should be able
to find out (1) which of your read_excel calls is failing, (2) what is
its argument and (3) what actually ends up at that path at the time of
the call. Once you know this information, the solution may become
obvious, or at least there may be something for us to give you more
pointers about.

While there is a chance that someone else will come along, run your
package on their machine and reproduce the problem, there's also a
significant chance that no one will do that. Meanwhile, these steps are
relatively simple and may help you solve the problem right away.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Thank you for the reply.

Yes, uploading files into the Shiny app.

The Greymodels package loads data from spreadsheets and each model accepts
a set of data and outputs the  values. However, the package is unable to do
that because of the error: cannot open connection.

Regards,
Havisha

On Mon, Nov 7, 2022 at 2:13 PM Ivan Krylov  wrote:

> В Mon, 7 Nov 2022 12:30:35 +0400
> "Jahajeeah, Havisha"  пишет:
>
> > After loading the package on CRAN, when I try to upload file (xlsx or
> > xls) the following error appears:
> >
> > Error: cannot open the connection
>
> Do you mean uploading files into your Shiny application, or somewhere
> else?
>
> Have you tried following this guide?
> https://shiny.rstudio.com/articles/debugging.html
>
> --
> Best regards,
> Ivan
>

[[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 uploading file on CRAN

[Ivan Krylov]

В Mon, 7 Nov 2022 12:30:35 +0400
"Jahajeeah, Havisha"  пишет:

> After loading the package on CRAN, when I try to upload file (xlsx or
> xls) the following error appears:
> 
> Error: cannot open the connection

Do you mean uploading files into your Shiny application, or somewhere
else?

Have you tried following this guide?
https://shiny.rstudio.com/articles/debugging.html

-- 
Best regards,
Ivan

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

[R-pkg-devel] Error uploading file on CRAN

[Jahajeeah, Havisha]

Dear CRAN team,

The package 'Greymodels' has just been published on CRAN. After loading the
package on CRAN, when I try to upload file (xlsx or xls)
the following error appears:

Error: cannot open the connection

What could be the problem? Is it because of the working directory?

Please advise on how to fix this.

Many thanks,
Havisha Jahajeeah

[[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 when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Carl Schwarz]

Yes, the resubmission and re-building has fixed the problem with buildmer/
Matrix.
Carl

On Tue, Oct 18, 2022 at 12:17 PM Duncan Murdoch 
wrote:

> I see the same thing.  This sounds like a problem in the handling of
> methods that has been discussed somewhat recently:
>
>https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html
>
> The problem is that when the binary is built, some code from other
> packages is kept as part of it.  When that other package is updated, you
> need a new source install of your own package (or a rebuild at CRAN to
> replace the binary) to cache the new code.
>
> This can also be done explicitly by package startup code; I think this
> thread
>
>https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html
>
> turned out to be a case where rstan was caching something, and an update
> to ggplot2 didn't work with the cached data.  Given the error message,
> your issue sounds more like the first one.
>
> I don't recall if there was a resolution.  Maybe you can ask the CRAN
> maintainers to rebuild buildmer.
>
> Duncan Murdoch
>
>
>
>
>
> On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
> > I've run into a problem where if you install the lme4, Matrix, and
> buildmer
> > packages using the binaries from CRAN on a Mac, I get an error message
> > about a missing method, but if I install the same packages from SOURCE,
> the
> > code runs fine.
> >
> > I would have thought that installing from source or using the binary
> > should look the same.
> >
> > Any suggestions on how to proceed to resolve this issue?
> >
> > The maintainer of buildmer is also puzzled.
> > You can follow the issue in more detail at:
> >  https://github.com/cvoeten/buildmer/issues/20
> >
> > This is way above my paygrade...
> >
> > Carl Schwarz
> >
> > --
> >
> > Tried this on an intel-Mac and arm-Mac with the same result.
> > Works fine on Windows machines under both scenarios.
> >
> > Here is a test example
> >
> > library(buildmer)
> > library(lme4)
> >
> > nrow <- 100
> >
> > test <- data.frame(x01=runif(nrow),
> > y=runif(nrow)<.1,
> block=as.factor(floor((1:nrow)/50)))
> > head(test)
> >
> >
> > fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
> > family=binomial(link="logit"))
> > fit.model # this works
> >
> > class(fit.model)
> >
> > summary(fit.model)
> > # gives the following error message
> > Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not found
> >
> > A pdf document showing output is attached (shows the sessionInfo etc).
> >
> > When you install the buildmer and Matrix packages from SOURCE, it runs
> fine.
> >
> > I've tried all combinations of installing binary/source and only if both
> > packages (Matrix and buidmer) are installed from source, does the code
> run.
> >
> > Same issue on an intel-Mac.
> > Same issue when running under the R directly rather than Rstudio on a
> Mac.
> >
> >
> > __
> > 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 when install binary from CRAN but not if install from source - Macintosh, lme4, Matrix, buildmer

[Martin Maechler]

> Duncan Murdoch 
> on Wed, 19 Oct 2022 14:55:24 -0400 writes:

> It seems that this could be mostly avoided if instead of caching copies 
> of Matrix methods when buildmer was installed, R would cache promises to 
> get those methods.  Then if the method for some particular signature 
> changed, on first use buildmer would retrieve the current version.

> There would still be a problem if Matrix completely dropped a method or 
> it migrated to a different package, but I think that's less frequent 
> than a change to the internal implementation.

> Has any thought been given to making this change for R 4.3.0?

> Duncan Murdoch

Not that I know of.

It sounds like a very promising (pun! ;-) idea, that could solve
many subtle  inter-package installation/update  problems.

Note that the methods *and* classes  caching had been introduced
a longer while ago as part of a concerted effort to make the
loading of packages with (many) S4 methods and classes considerably faster.

Before that effort, all these class and method "tables"/"lists"
(environments effectively) were (re-)computed at package load
time which was quite costly [time consuming].
I was not very much involved in that effort and I don't know if
using promises instead had been considered at the time.

(I've added Michael and the other Martin M to the CC , hoping
 they will know / remember more )

Martin Maechler


> On 19/10/2022 3:39 a.m., Martin Maechler wrote:
>>> Duncan Murdoch
>>> on Tue, 18 Oct 2022 15:17:33 -0400 writes:
>> 
>> > I see the same thing.  This sounds like a problem in the handling of
>> > methods that has been discussed somewhat recently:
>> 
>> > https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html
>> 
>> > The problem is that when the binary is built, some code from other
>> > packages is kept as part of it.  When that other package is updated, 
you
>> > need a new source install of your own package (or a rebuild at CRAN to
>> > replace the binary) to cache the new code.
>> 
>> > This can also be done explicitly by package startup code; I think this
>> > thread
>> 
>> > https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html
>> 
>> > turned out to be a case where rstan was caching something, and an 
update
>> > to ggplot2 didn't work with the cached data.  Given the error message,
>> > your issue sounds more like the first one.
>> 
>> > I don't recall if there was a resolution.  Maybe you can ask the CRAN
>> > maintainers to rebuild buildmer.
>> 
>> > Duncan Murdoch
>> 
>> Yes, thank you, Duncan!
>> 
>> The binary version of 'buildmer' (or also lme4 ?) must have been created
>> with an older version of Matrix  (which did not have the
>> dgeMatrix_getDiag C code)  and the respective maintainer of the
>> binary builds (*) must rebuild the binary versions of those
>> Matrix-reverse-dependant packages,
>> ---
>> *) in this case the macOS ones (both for Intel and ARM Macs)
>> 
>> Martin Maechler
>> (maintainer of Matrix)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
>> >> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
>> >> packages using the binaries from CRAN on a Mac, I get an error message
>> >> about a missing method, but if I install the same packages from 
SOURCE, the
>> >> code runs fine.
>> >>
>> >> I would have thought that installing from source or using the binary
>> >> should look the same.
>> >>
>> >> Any suggestions on how to proceed to resolve this issue?
>> >>
>> >> The maintainer of buildmer is also puzzled.
>> >> You can follow the issue in more detail at:
>> >> https://github.com/cvoeten/buildmer/issues/20
>> >>
>> >> This is way above my paygrade...
>> >>
>> >> Carl Schwarz
>> >>
>> >> --
>> >>
>> >> Tried this on an intel-Mac and arm-Mac with the same result.
>> >> Works fine on Windows machines under both scenarios.
>> >>
>> >> Here is a test example
>> >>
>> >> library(buildmer)
>> >> library(lme4)
>> >>
>> >> nrow <- 100
>> >>
>> >> test <- data.frame(x01=runif(nrow),
>> >> y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
>> >> head(test)
>> >>
>> >>
>> >> fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
>> >> family=binomial(link="logit"))
>> >> fit.model # this works
>> >>
>> >> class(fit.model)
>> >>
>> >> summary(fit.model)
>> >> # gives the following error message
>> >> Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not 
found
>> >>
>> >> A pdf document showing output is attached (shows the sessionInfo etc).
 

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Duncan Murdoch]

It seems that this could be mostly avoided if instead of caching copies 
of Matrix methods when buildmer was installed, R would cache promises to 
get those methods.  Then if the method for some particular signature 
changed, on first use buildmer would retrieve the current version.


There would still be a problem if Matrix completely dropped a method or 
it migrated to a different package, but I think that's less frequent 
than a change to the internal implementation.


Has any thought been given to making this change for R 4.3.0?

Duncan Murdoch



On 19/10/2022 3:39 a.m., Martin Maechler wrote:

Duncan Murdoch
 on Tue, 18 Oct 2022 15:17:33 -0400 writes:


 > I see the same thing.  This sounds like a problem in the handling of
 > methods that has been discussed somewhat recently:

 > https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

 > The problem is that when the binary is built, some code from other
 > packages is kept as part of it.  When that other package is updated, you
 > need a new source install of your own package (or a rebuild at CRAN to
 > replace the binary) to cache the new code.

 > This can also be done explicitly by package startup code; I think this
 > thread

 > https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html

 > turned out to be a case where rstan was caching something, and an update
 > to ggplot2 didn't work with the cached data.  Given the error message,
 > your issue sounds more like the first one.

 > I don't recall if there was a resolution.  Maybe you can ask the CRAN
 > maintainers to rebuild buildmer.

 > Duncan Murdoch

Yes, thank you, Duncan!

The binary version of 'builmer' (or also lme4 ?) must have been created
with an older version of Matrix  (which did not have the
dgeMatrix_getDiag C code)  and the respective maintainer of the
binary builds (*) must rebuild the binary versions of those
Matrix-reverse-dependant packages,
---
*) in this case the macOS ones (both for Intel and ARM Macs)

Martin Maechler
(maintainer of Matrix)








 > On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
 >> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
 >> packages using the binaries from CRAN on a Mac, I get an error message
 >> about a missing method, but if I install the same packages from SOURCE, 
the
 >> code runs fine.
 >>
 >> I would have thought that installing from source or using the binary
 >> should look the same.
 >>
 >> Any suggestions on how to proceed to resolve this issue?
 >>
 >> The maintainer of buildmer is also puzzled.
 >> You can follow the issue in more detail at:
 >> https://github.com/cvoeten/buildmer/issues/20
 >>
 >> This is way above my paygrade...
 >>
 >> Carl Schwarz
 >>
 >> --
 >>
 >> Tried this on an intel-Mac and arm-Mac with the same result.
 >> Works fine on Windows machines under both scenarios.
 >>
 >> Here is a test example
 >>
 >> library(buildmer)
 >> library(lme4)
 >>
 >> nrow <- 100
 >>
 >> test <- data.frame(x01=runif(nrow),
 >> y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
 >> head(test)
 >>
 >>
 >> fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
 >> family=binomial(link="logit"))
 >> fit.model # this works
 >>
 >> class(fit.model)
 >>
 >> summary(fit.model)
 >> # gives the following error message
 >> Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not 
found
 >>
 >> A pdf document showing output is attached (shows the sessionInfo etc).
 >>
 >> When you install the buildmer and Matrix packages from SOURCE, it runs 
fine.
 >>
 >> I've tried all combinations of installing binary/source and only if both
 >> packages (Matrix and buidmer) are installed from source, does the code 
run.
 >>
 >> Same issue on an intel-Mac.
 >> Same issue when running under the R directly rather than Rstudio on a 
Mac.


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

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Uwe Ligges]

Please let the Simon (Mac maintainer for CRAN) know.
For Windows, the revdeps get rebuild automatically.

Best,
Uwe Ligges


On 19.10.2022 09:39, Martin Maechler wrote:

Duncan Murdoch
 on Tue, 18 Oct 2022 15:17:33 -0400 writes:


 > I see the same thing.  This sounds like a problem in the handling of
 > methods that has been discussed somewhat recently:

 > https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

 > The problem is that when the binary is built, some code from other
 > packages is kept as part of it.  When that other package is updated, you
 > need a new source install of your own package (or a rebuild at CRAN to
 > replace the binary) to cache the new code.

 > This can also be done explicitly by package startup code; I think this
 > thread

 > https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html

 > turned out to be a case where rstan was caching something, and an update
 > to ggplot2 didn't work with the cached data.  Given the error message,
 > your issue sounds more like the first one.

 > I don't recall if there was a resolution.  Maybe you can ask the CRAN
 > maintainers to rebuild buildmer.

 > Duncan Murdoch

Yes, thank you, Duncan!

The binary version of 'builmer' (or also lme4 ?) must have been created
with an older version of Matrix  (which did not have the
dgeMatrix_getDiag C code)  and the respective maintainer of the
binary builds (*) must rebuild the binary versions of those
Matrix-reverse-dependant packages,
---
*) in this case the macOS ones (both for Intel and ARM Macs)

Martin Maechler
(maintainer of Matrix)








 > On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
 >> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
 >> packages using the binaries from CRAN on a Mac, I get an error message
 >> about a missing method, but if I install the same packages from SOURCE, 
the
 >> code runs fine.
 >>
 >> I would have thought that installing from source or using the binary
 >> should look the same.
 >>
 >> Any suggestions on how to proceed to resolve this issue?
 >>
 >> The maintainer of buildmer is also puzzled.
 >> You can follow the issue in more detail at:
 >> https://github.com/cvoeten/buildmer/issues/20
 >>
 >> This is way above my paygrade...
 >>
 >> Carl Schwarz
 >>
 >> --
 >>
 >> Tried this on an intel-Mac and arm-Mac with the same result.
 >> Works fine on Windows machines under both scenarios.
 >>
 >> Here is a test example
 >>
 >> library(buildmer)
 >> library(lme4)
 >>
 >> nrow <- 100
 >>
 >> test <- data.frame(x01=runif(nrow),
 >> y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
 >> head(test)
 >>
 >>
 >> fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
 >> family=binomial(link="logit"))
 >> fit.model # this works
 >>
 >> class(fit.model)
 >>
 >> summary(fit.model)
 >> # gives the following error message
 >> Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not 
found
 >>
 >> A pdf document showing output is attached (shows the sessionInfo etc).
 >>
 >> When you install the buildmer and Matrix packages from SOURCE, it runs 
fine.
 >>
 >> I've tried all combinations of installing binary/source and only if both
 >> packages (Matrix and buidmer) are installed from source, does the code 
run.
 >>
 >> Same issue on an intel-Mac.
 >> Same issue when running under the R directly rather than Rstudio on a 
Mac.

__
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 when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Martin Maechler]

> Duncan Murdoch 
> on Tue, 18 Oct 2022 15:17:33 -0400 writes:

> I see the same thing.  This sounds like a problem in the handling of 
> methods that has been discussed somewhat recently:

> https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

> The problem is that when the binary is built, some code from other 
> packages is kept as part of it.  When that other package is updated, you 
> need a new source install of your own package (or a rebuild at CRAN to 
> replace the binary) to cache the new code.

> This can also be done explicitly by package startup code; I think this 
> thread

> https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html

> turned out to be a case where rstan was caching something, and an update 
> to ggplot2 didn't work with the cached data.  Given the error message, 
> your issue sounds more like the first one.

> I don't recall if there was a resolution.  Maybe you can ask the CRAN 
> maintainers to rebuild buildmer.

> Duncan Murdoch

Yes, thank you, Duncan!

The binary version of 'builmer' (or also lme4 ?) must have been created
with an older version of Matrix  (which did not have the
dgeMatrix_getDiag C code)  and the respective maintainer of the
binary builds (*) must rebuild the binary versions of those
Matrix-reverse-dependant packages,
---
*) in this case the macOS ones (both for Intel and ARM Macs)

Martin Maechler
(maintainer of Matrix)








> On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
>> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
>> packages using the binaries from CRAN on a Mac, I get an error message
>> about a missing method, but if I install the same packages from SOURCE, 
the
>> code runs fine.
>> 
>> I would have thought that installing from source or using the binary
>> should look the same.
>> 
>> Any suggestions on how to proceed to resolve this issue?
>> 
>> The maintainer of buildmer is also puzzled.
>> You can follow the issue in more detail at:
>> https://github.com/cvoeten/buildmer/issues/20
>> 
>> This is way above my paygrade...
>> 
>> Carl Schwarz
>> 
>> --
>> 
>> Tried this on an intel-Mac and arm-Mac with the same result.
>> Works fine on Windows machines under both scenarios.
>> 
>> Here is a test example
>> 
>> library(buildmer)
>> library(lme4)
>> 
>> nrow <- 100
>> 
>> test <- data.frame(x01=runif(nrow),
>> y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
>> head(test)
>> 
>> 
>> fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
>> family=binomial(link="logit"))
>> fit.model # this works
>> 
>> class(fit.model)
>> 
>> summary(fit.model)
>> # gives the following error message
>> Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not found
>> 
>> A pdf document showing output is attached (shows the sessionInfo etc).
>> 
>> When you install the buildmer and Matrix packages from SOURCE, it runs 
fine.
>> 
>> I've tried all combinations of installing binary/source and only if both
>> packages (Matrix and buidmer) are installed from source, does the code 
run.
>> 
>> Same issue on an intel-Mac.
>> Same issue when running under the R directly rather than Rstudio on a 
Mac.

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

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Duncan Murdoch]

I see the same thing.  This sounds like a problem in the handling of 
methods that has been discussed somewhat recently:


  https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

The problem is that when the binary is built, some code from other 
packages is kept as part of it.  When that other package is updated, you 
need a new source install of your own package (or a rebuild at CRAN to 
replace the binary) to cache the new code.


This can also be done explicitly by package startup code; I think this 
thread


  https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html

turned out to be a case where rstan was caching something, and an update 
to ggplot2 didn't work with the cached data.  Given the error message, 
your issue sounds more like the first one.


I don't recall if there was a resolution.  Maybe you can ask the CRAN 
maintainers to rebuild buildmer.


Duncan Murdoch





On 18/10/2022 2:51 p.m., Carl Schwarz wrote:

I've run into a problem where if you install the lme4, Matrix, and buildmer
packages using the binaries from CRAN on a Mac, I get an error message
about a missing method, but if I install the same packages from SOURCE, the
code runs fine.

I would have thought that installing from source or using the binary
should look the same.

Any suggestions on how to proceed to resolve this issue?

The maintainer of buildmer is also puzzled.
You can follow the issue in more detail at:
 https://github.com/cvoeten/buildmer/issues/20

This is way above my paygrade...

Carl Schwarz

--

Tried this on an intel-Mac and arm-Mac with the same result.
Works fine on Windows machines under both scenarios.

Here is a test example

library(buildmer)
library(lme4)

nrow <- 100

test <- data.frame(x01=runif(nrow),
y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
head(test)


fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
family=binomial(link="logit"))
fit.model # this works

class(fit.model)

summary(fit.model)
# gives the following error message
Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not found

A pdf document showing output is attached (shows the sessionInfo etc).

When you install the buildmer and Matrix packages from SOURCE, it runs fine.

I've tried all combinations of installing binary/source and only if both
packages (Matrix and buidmer) are installed from source, does the code run.

Same issue on an intel-Mac.
Same issue when running under the R directly rather than Rstudio on a Mac.


__
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 DUE TO EXISTING BIOCONDUCTOR PACKAGES NOT WORKING ON R-DEVEL

[Duncan Murdoch]

If the Bioconductor packages are unconditional requirements, maybe you 
should submit your package to Bioconductor rather than CRAN.  Just from 
the name ("multiomicsR") it looks like it might be appropriate there.


Duncan Murdoch



On 19/09/2022 2:14 a.m., Das, Sarmistha wrote:

Hello,
I ran (1) R CMD check --as-cran mypackage.tar.gz without any error. But it 
gives an error while running the package on (2) current version-of-R-devel as 
my package uses Bioconductor package (that does not run on R version 4.3). 
Please help me with any idea how to fix this error. I have attached the check 
results below.

Thanks,
Sarmistha
**
R CMD check results:
**

(1)  * using log directory
   ‘/.../multiomicsR.Rcheck’
*
   using R version 4.2.1 (2022-06-23)
* using platform:
   x86_64-apple-darwin17.0 (64-bit)
* using session
   charset: UTF-8
* using option ‘--as-cran’
*
   checking for file ‘multiomicsR/DESCRIPTION’ ...
   OK
* this is package ‘multiomicsR’ version
   ‘0.1’
* package encoding: UTF-8
* checking CRAN
   incoming feasibility ... NOTE
Maintainer:
   ‘Sarmistha Das ’

New
   submission
* checking package namespace information
   ... OK
* checking package dependencies ... OK
*
   checking if this is a source package ... OK
*
   checking if there is a namespace ... OK
* checking
   for executable files ... OK
* checking for hidden
   files and directories ... OK
* checking for portable
   file names ... OK
* checking for sufficient/correct
   file permissions ... OK
* checking whether package
   ‘multiomicsR’ can be installed ... OK
* checking
   installed package size ... OK
* checking package
   directory ... OK
* checking for future file
   timestamps ... OK
* checking DESCRIPTION
   meta-information ... OK
* checking top-level files
   ... OK
* checking for left-over files ... OK
*
   checking index information ... OK
* checking package
   subdirectories ... OK
* checking R files for
   non-ASCII characters ... OK
* checking R files for
   syntax errors ... OK
* checking whether the package
   can be loaded ... OK
* checking whether the package
   can be loaded with stated dependencies ... OK
*
   checking whether the package can be unloaded cleanly
   ... OK
* checking whether the namespace can be
   loaded with stated dependencies ... OK
* checking
   whether the namespace can be unloaded cleanly ...
   OK
* checking use of S3 registration ... OK
*
   checking dependencies in R code ... OK
* checking S3
   generic/method consistency ... OK
* checking
   replacement functions ... OK
* checking foreign
   function calls ... OK
* checking R code for possible
   problems ... OK
* checking Rd files ... OK
*
   checking Rd metadata ... OK
* checking Rd line
   widths ... OK
* checking Rd cross-references ...
   OK
* checking for missing documentation entries ...
   OK
* checking for code/documentation mismatches ...
   OK
* checking Rd \usage sections ... OK
* checking
   Rd contents ... OK
* checking for unstated
   dependencies in examples ... OK
* checking examples
   ... NOTE
Examples with CPU (user + system) or
   elapsed time > 5s
user system
   elapsed
iosearchR 59.22  5.586 211.242
* checking
   PDF version of manual ... OK
* checking for
   non-standard things in the check directory ...
   NOTE
Found the following files/directories:

   ‘GDCdata’ ‘MANIFEST.txt’ ‘TCGAbiolinks’
   ‘clinical_InfoFile.txt’
   ‘omic1_Group1.txt’
   ‘omic1_Group2.txt’ ‘omic2_Group1.txt’

   ‘omic2_Group2.txt’ ‘pathway_genes.csv’
   ‘pathway_omic1.expr.csv’

   ‘pathway_omic2.expr.csv’
   ‘samplesheet_file.txt’ ‘status.txt’

   ‘subid.all.0.txt’ ‘subid.all.1.txt’
*
   checking for detritus in the temp directory ... OK
*
   DONE
Status: 3
   NOTEs

***
***

(2)
   On windows-x86_64-devel (r-devel)
   checking package
   dependencies ... ERROR
   Packages required but not
   available:
 'AnnotationDbi', 'KEGGREST',
   'org.Hs.eg.db', 'TCGAbiolinks'

   See section
   'The DESCRIPTION file' in the 'Writing R
   Extensions'
   manual.

1 error ✖ | 0 warnings
   ✔ | 0 notes ✔

*
Sarmistha Das, PhD. (she/her)
Postdoctoral Research Associate
Department of Biostatistics, St. Jude Children's Research Hospital
262 Danny Thomas Place
Room R6025A (Longinotti Building); Mail Stop 768
Memphis, TN 38105
Email: sarmistha@stjude.org
Phone: 901-595-1160



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

[[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 lis

[R-pkg-devel] ERROR DUE TO EXISTING BIOCONDUCTOR PACKAGES NOT WORKING ON R-DEVEL

[Das, Sarmistha]

Hello,
I ran (1) R CMD check --as-cran mypackage.tar.gz without any error. But it 
gives an error while running the package on (2) current version-of-R-devel as 
my package uses Bioconductor package (that does not run on R version 4.3). 
Please help me with any idea how to fix this error. I have attached the check 
results below.

Thanks,
Sarmistha
**
R CMD check results:
**

(1)  * using log directory
  ‘/.../multiomicsR.Rcheck’
*
  using R version 4.2.1 (2022-06-23)
* using platform:
  x86_64-apple-darwin17.0 (64-bit)
* using session
  charset: UTF-8
* using option ‘--as-cran’
*
  checking for file ‘multiomicsR/DESCRIPTION’ ...
  OK
* this is package ‘multiomicsR’ version
  ‘0.1’
* package encoding: UTF-8
* checking CRAN
  incoming feasibility ... NOTE
Maintainer:
  ‘Sarmistha Das ’

New
  submission
* checking package namespace information
  ... OK
* checking package dependencies ... OK
*
  checking if this is a source package ... OK
*
  checking if there is a namespace ... OK
* checking
  for executable files ... OK
* checking for hidden
  files and directories ... OK
* checking for portable
  file names ... OK
* checking for sufficient/correct
  file permissions ... OK
* checking whether package
  ‘multiomicsR’ can be installed ... OK
* checking
  installed package size ... OK
* checking package
  directory ... OK
* checking for future file
  timestamps ... OK
* checking DESCRIPTION
  meta-information ... OK
* checking top-level files
  ... OK
* checking for left-over files ... OK
*
  checking index information ... OK
* checking package
  subdirectories ... OK
* checking R files for
  non-ASCII characters ... OK
* checking R files for
  syntax errors ... OK
* checking whether the package
  can be loaded ... OK
* checking whether the package
  can be loaded with stated dependencies ... OK
*
  checking whether the package can be unloaded cleanly
  ... OK
* checking whether the namespace can be
  loaded with stated dependencies ... OK
* checking
  whether the namespace can be unloaded cleanly ...
  OK
* checking use of S3 registration ... OK
*
  checking dependencies in R code ... OK
* checking S3
  generic/method consistency ... OK
* checking
  replacement functions ... OK
* checking foreign
  function calls ... OK
* checking R code for possible
  problems ... OK
* checking Rd files ... OK
*
  checking Rd metadata ... OK
* checking Rd line
  widths ... OK
* checking Rd cross-references ...
  OK
* checking for missing documentation entries ...
  OK
* checking for code/documentation mismatches ...
  OK
* checking Rd \usage sections ... OK
* checking
  Rd contents ... OK
* checking for unstated
  dependencies in examples ... OK
* checking examples
  ... NOTE
Examples with CPU (user + system) or
  elapsed time > 5s
   user system
  elapsed
iosearchR 59.22  5.586 211.242
* checking
  PDF version of manual ... OK
* checking for
  non-standard things in the check directory ...
  NOTE
Found the following files/directories:

  ‘GDCdata’ ‘MANIFEST.txt’ ‘TCGAbiolinks’
  ‘clinical_InfoFile.txt’
  ‘omic1_Group1.txt’
  ‘omic1_Group2.txt’ ‘omic2_Group1.txt’

  ‘omic2_Group2.txt’ ‘pathway_genes.csv’
  ‘pathway_omic1.expr.csv’

  ‘pathway_omic2.expr.csv’
  ‘samplesheet_file.txt’ ‘status.txt’

  ‘subid.all.0.txt’ ‘subid.all.1.txt’
*
  checking for detritus in the temp directory ... OK
*
  DONE
Status: 3
  NOTEs

***
***

(2)
  On windows-x86_64-devel (r-devel)
  checking package
  dependencies ... ERROR
  Packages required but not
  available:
'AnnotationDbi', 'KEGGREST',
  'org.Hs.eg.db', 'TCGAbiolinks'

  See section
  'The DESCRIPTION file' in the 'Writing R
  Extensions'
  manual.

1 error ✖ | 0 warnings
  ✔ | 0 notes ✔

*
Sarmistha Das, PhD. (she/her)
Postdoctoral Research Associate
Department of Biostatistics, St. Jude Children's Research Hospital
262 Danny Thomas Place
Room R6025A (Longinotti Building); Mail Stop 768
Memphis, TN 38105
Email: sarmistha@stjude.org
Phone: 901-595-1160



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

[[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 checking in an independent C code and printing (perror, printf, etc.)

[Jiří Moravec]

I was hoping that you will tell me that R takes control of the C's 
stderr and stdout.

That would make stuff easier. But I guess that is not really possible.

I went the way suggested before and created an enum of error codes and a 
(static) const char* array of error messages.
When reading about error checking in C, that looked like the most 
wholesome way. First time using the dreadful "goto",
looks like it makes sense to free resources. 
(https://stackoverflow.com/a/59221452/4868692)


It still looks a bit ugly compared to simple "throw" (i.e., too much 
code noise),

and I now understand where the Java's checked exceptions are coming from.
And somehow, now that I am thinking about it, I am getting used to it.

Thanks again.
I hope I am responding correctly ("respond all") and not spamming people.

ps.: The .Call interface is easier than it seems, the R documentation is 
not very good and spread the information a bit too much over many pages.
Once I got my .Call(c_hello_world) (including all the linking, info 
about the C_ naming and speed, the 
`tools::package_native_routine_registration_skeleton` was nice),
it all went quite nicely from there. Particularly, when to use PROTECT() 
is not clear (new SEXP objects, but not required if they are just 
interfaced with INTEGER(), REAL()

or VECTOR_ELT).

The overview: 
https://stat.ethz.ch/pipermail/r-devel/attachments/20120323/a13f948a/attachment.pdf

was also really helpful and should be IMHO part of official documentation.

An example how to work with named list (e.g., an S3 class), where 
subsetting is done by name and not by position,

would be really useful.

-- Jirka


On 9/7/22 04:52, Ivan Krylov wrote:

Hello Jiří and welcome to the mailing list!

On Tue, 6 Sep 2022 14:48:02 +1200
"Jiří Moravec"  wrote:


That brings me to a problem: How to do error handling in C without
the use of various <...> R-specific print functions?

(Assuming that's what you meant...)

One way would be to introduce callbacks from the R-independent part to
the R-interfacing part, but I can imagine this to require tedious
boilerplate. Also, many of R's entry points can raise an error
condition (e.g. if an allocation fails), which would result in a
longjmp() away from your code. Any resource not known to R's garbage
collector is going to be leaked in this situation.

I think you're actually allowed to format strings using sprintf and
friends; only actual printing to stdout/stderr is disallowed because
the user may be using e.g. Rgui on Windows and not see it at all. If
you need to print error messages, you can pass them to the R side as
strings, probably in storage allocated by the caller to avoid leaks on
errors. Error codes are of course an option too, but can be less
informative if not accompanied by an explanation of what went wrong.

(It's considered polite for package code to use R's message system not
only because of the stdout/Rgui problem mentioned above, but also
because it gives the user an option to run your code with
suppressMessages() and disable the verbose output. When the R code
directly calls cat() or the C code prints directly to console, that
option disappears.)

To summarise, R would accept any option where only R is interacting
with the user (or doing other I/O). If neither of this is satisfying,
can you provide a bit more details on the kind of error handling you're
looking for?
  

This is my first time writing into mailing list, hopefully I am doing
everything ok.

Indeed you are!



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

Re: [R-pkg-devel] Error checking in an independent C code and printing (perror, printf, etc.)

[Dirk Eddelbuettel]

On 7 September 2022 at 11:58, Ivan Krylov wrote:
| there at all. On the other hand, my package that uses the
| R_InitOutPStream and R_Serialize entry points seems to have passed the
| CRAN review. A table of all public entry points including short
| descriptions and whether they allocate could be very useful.

And there is RApiSerialize:  https://cran.r-project.org/package=RApiSerialize

It takes R Core code and provides it in a package. That allows R Core to one
day change the non-exported API (so far it hasn't happened in the eight years
since the 0.1.0 release) yet lets packages use serialization: RcppRedis and
the excellent qs package make use of it.

Tip of the hat to the Rhpc package for the idea.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error checking in an independent C code and printing (perror, printf, etc.)

[Ivan Krylov]

Hello Jiří and welcome to the mailing list!

On Tue, 6 Sep 2022 14:48:02 +1200
"Jiří Moravec"  wrote:

> That brings me to a problem: How to do error handling in C without
> the use of various <...> R-specific print functions?

(Assuming that's what you meant...)

One way would be to introduce callbacks from the R-independent part to
the R-interfacing part, but I can imagine this to require tedious
boilerplate. Also, many of R's entry points can raise an error
condition (e.g. if an allocation fails), which would result in a
longjmp() away from your code. Any resource not known to R's garbage
collector is going to be leaked in this situation.

I think you're actually allowed to format strings using sprintf and
friends; only actual printing to stdout/stderr is disallowed because
the user may be using e.g. Rgui on Windows and not see it at all. If
you need to print error messages, you can pass them to the R side as
strings, probably in storage allocated by the caller to avoid leaks on
errors. Error codes are of course an option too, but can be less
informative if not accompanied by an explanation of what went wrong.

(It's considered polite for package code to use R's message system not
only because of the stdout/Rgui problem mentioned above, but also
because it gives the user an option to run your code with
suppressMessages() and disable the verbose output. When the R code
directly calls cat() or the C code prints directly to console, that
option disappears.)

To summarise, R would accept any option where only R is interacting
with the user (or doing other I/O). If neither of this is satisfying,
can you provide a bit more details on the kind of error handling you're
looking for?
 
> This is my first time writing into mailing list, hopefully I am doing 
> everything ok.

Indeed you are!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error checking in an independent C code and printing (perror, printf, etc.)

[Duncan Murdoch]

On 05/09/2022 10:48 p.m., Jiří Moravec wrote:

Hello,

this is my first time writing C code that interacts with R.
To make my C code more modular, reusable, and easier to test with
unittests, I split my code into:

a) code that does stuff
b) code that interfaces between a) and R.

Only the b) imports the R headers, a) is completely independent of R
(and potentially shared between different projects).

That brings me to a problem: How to do error handling in C without the
use of various C-specific print functions R-specific print functions?

The C-specific print functions raise a CRAN note:

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

But R(C) print functions cannot be used without importing particular
header,
which would induce otherwise another dependency, and tie it closely with R.


I think the best way is to think of error reporting as part of the 
interface.  Your code that does stuff shouldn't try to print anything, 
it should just return special error code values to indicate problems. 
The code in b) looks for those error codes and creates R messages or 
errors.  If you use the a) code in a different project, it would do the 
same, but report the errors in whatever way is natural in that context.




This is my first time writing into mailing list, hopefully I am doing
everything ok.


Looks fine to me!

Duncan Murdoch

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

Re: [R-pkg-devel] Error in r-devel-windows-x86_64 check: package not found.

[Arkajyoti Saha]

Thanks so much for the clarification!!

On Sat, Apr 30, 2022 at 8:09 AM Martin Maechler 
wrote:

> > Arkajyoti Saha
> > on Sat, 30 Apr 2022 07:54:22 -0700 writes:
>
> > I recently updated a package in CRAN. Though it passed the
> > r-devel-linux-x86_64
> > <
> https://cran.r-project.org/web/checks/check_flavors.html#r-devel-linux-x86_64-debian-clang
> >
> > flavors, I saw an error with r-devel-windows-x86_64
> > <
> https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/BRISC-00check.html
> >.
>
> > The error says "Error : package 'RANN' required by 'BRISC'
> > could not be found" The detailed report can be found at
> >
> https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/BRISC-00install.html
>
> > I was wondering if there is anything to be done on my
> > behalf to circumvent this problem, Please let me know if I
> > can provide you with any additional information,
>
> > thanks, Arka
>
> Fortunately, this has been a transitional bug in R-devel, and is
> unrelated to the Windows / non-Windows differences:
>
> It's been caused by fixing R bugzilla PR#18331  w/ NEWS entry
>
> * library() now passes its lib.loc argument when requiring Depends
>   packages; reported (with fix) in PR#18331 by Mikael Jagan.
>
> and the orginal change (svn rev 82284) inadvertantly "killed"
> correct working of install.packages()  in some not too
> unfrequent cases.
>
> I've looked for you at
>
> https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/BRISC-00check.txt
> and see that indeed the BRISC installation had happened with
> R-devel svn r88285 which contains this bug.
>
> This newly introduced bug (yesterday) has now been fixed, 28h
> later (with svn r88287).
> It's been my fault  (and fix).
>
> Martin
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Error in r-devel-windows-x86_64 check: package not found.

[Arkajyoti Saha]

I recently updated a package in CRAN. Though it passed the
r-devel-linux-x86_64

flavors, I saw an error with r-devel-windows-x86_64
.

The error says "Error : package 'RANN' required by 'BRISC' could not be
found"
The detailed report can be found at
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/BRISC-00install.html

I was wondering if there is anything to be done on my behalf to circumvent
this problem,
Please let me know if I can provide you with any additional information,

thanks,
Arka

[[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 inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/27/21 4:04 PM, Ezra Tucker wrote:

Hi Tomas,


Thanks again for all your great info. One last question- and maybe it's
a stupid one. You mention the JAGS package-- I've been using xml2 as my
kind-of template. Installing it on linux for example will fail unless
you have the libxml2-dev package installed (at least for debian-based),
whereas for windows it just goes and downloads the dll as part of the
install process. Why would/should this package NOT just perform this
action for linux as well (namely, automatically download the precompiled
.so from somewhere else and package it in so you don't need root
privileges to install the package)? Is this just a difference in install
philosophy between linux and windows?


Hi Ezra,

Dirk responded in detail re Unix.

On Windows, static libraries (not dynamic) are used by R and are part of 
the toolchain (Rtools42 for R-devel and R 4.2), you just link the 
libraries from there via PKG_LIBS in your Makevars.ucrt or Makevars.win 
file. See for example rgdal for the recommended way how to do this, and 
[1] for a description.


Best
Tomas

[1] https://developer.r-project.org/WindowsBuilds/winutf8/ucrt3/howto.html




Thanks again!

-Ezra

On 12/23/21 17:20, Tomas Kalibera wrote:

On 12/23/21 4:52 PM, Ezra Tucker wrote:

Hi Tomas and Dirk,


Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.

Well it is very exceptional that packages link to an external DLL, only
very few CRAN packages do (another example is packages linking to JAGS).
I know about these as some of them caused trouble with staged
installation and other with the switch to UCRT, they certainly make
maintaining and improving R harder. They typically won't work correctly
with encodings on Windows. The C++ interface is particularly tricky and
fragile. So, one thing is getting this to work in your package you need
another question is whether at all it should be published on CRAN, and
if that was your plan that'd be best discussed with the CRAN repository
maintainers. In some cases there is no other way thank linking to an
external DLL, but the question is always whether such package should be
on CRAN.

On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?

No, those concerns apply and are unrelated in principle to using an
external DLL. My understanding is that this was also an exception
discussed with the CRAN repository maintainers, but I don't know the
case specifically.

Best
Tomas



Thanks again!

-Ezra


On 12/23/21 09:34, Dirk Eddelbuettel wrote:

On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.

Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.

Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.

But you can use C linkage.  So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:

 - "wide" bottom layer (may be C++ or C) with the core implementation

 - "narrow" C layer accessing the bottom and priving an API providing via C
   which profits from C's portable foreign function interface

 - "wide" layer on top via a header-only C++ file accesssing the C and
   which the C++ compiler optimizes away so that the C API is used for 
linking

Sounds complicated, but works great.

Good detail is in a hour-long but not-too-technical talk here

 https://www.youtube.com/watch?v=PVYdHDm0q6Y

and slides etc are here

 
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Dirk Eddelbuettel]

Ezra,

[ A gentle plea: Can you please turn the encryption signing off when you
  reply?  Thank you, it really confuses one of the email programs I use. ]

What you state in passing is somewhere between misleading and just wrong,
likely due to a misunderstanding. Quoting from your email:

  a stupid one. You mention the JAGS package-- I've been using xml2 as my
  kind-of template. Installing it on linux for example will fail unless
  you have the libxml2-dev package installed (at least for debian-based),

That is only true if you used one particular source of binary "packages" that
is not actually official for either the distribution or CRAN, and where I use
term package in quotes because these are known to be potentially incomplete
for dependencies.  

But the package in question, xml2, has been packaged correctly by the
distributions proper, see for example for Debian [1] expanding to, say, [2]
or for Ubuntu [3] expanding to, say, [4] you see that proper packages (in the
distribution) of course have proper dependencies.

If you have more questions about how this works for Debian or Ubuntu, there
are numerous resources on the web, and thousands of packages in binary. We
also have 5000+ of in the 'CRAN for Ubuntu' Team repo at [5] and other
distributions have similar resources within or contributed.

The topic is a bit more complicated than a single email. If you care, Inaki
and I even wrote a paper on the state of affairs and possibly use of such
binaries directly from R, see [6]

If you have specific questions about R on Debian/Ubuntu, the list
r-sig-debian is good. You need to subscribe before you can post.

Cheers, Dirk

[1] https://tracker.debian.org/pkg/r-cran-xml2
[2] https://packages.debian.org/source/unstable/r-cran-xml2
[3] https://packages.ubuntu.com/search?keywords=r-cran-xml2
[4] https://packages.ubuntu.com/jammy/r-cran-xml2
[5] https://launchpad.net/~c2d4u.team/+archive/ubuntu/c2d4u4.0+
[6] https://arxiv.org/abs/2103.08069


-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/23/21 4:52 PM, Ezra Tucker wrote:

Hi Tomas and Dirk,


Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.
Well it is very exceptional that packages link to an external DLL, only 
very few CRAN packages do (another example is packages linking to JAGS). 
I know about these as some of them caused trouble with staged 
installation and other with the switch to UCRT, they certainly make 
maintaining and improving R harder. They typically won't work correctly 
with encodings on Windows. The C++ interface is particularly tricky and 
fragile. So, one thing is getting this to work in your package you need 
another question is whether at all it should be published on CRAN, and 
if that was your plan that'd be best discussed with the CRAN repository 
maintainers. In some cases there is no other way thank linking to an 
external DLL, but the question is always whether such package should be 
on CRAN.

On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?


No, those concerns apply and are unrelated in principle to using an 
external DLL. My understanding is that this was also an exception 
discussed with the CRAN repository maintainers, but I don't know the 
case specifically.


Best
Tomas





Thanks again!

-Ezra


On 12/23/21 09:34, Dirk Eddelbuettel wrote:

On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.

Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.

Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.

But you can use C linkage.  So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:

   - "wide" bottom layer (may be C++ or C) with the core implementation

   - "narrow" C layer accessing the bottom and priving an API providing via C
 which profits from C's portable foreign function interface

   - "wide" layer on top via a header-only C++ file accesssing the C and
 which the C++ compiler optimizes away so that the C API is used for linking

Sounds complicated, but works great.

Good detail is in a hour-long but not-too-technical talk here

   https://www.youtube.com/watch?v=PVYdHDm0q6Y

and slides etc are here

   
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Ezra Tucker]

Hi Tomas and Dirk,


Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.


On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?


Thanks again!

-Ezra


On 12/23/21 09:34, Dirk Eddelbuettel wrote:
> On 23 December 2021 at 11:07, Tomas Kalibera wrote:
> | You can have a look at CRAN package Rblpapi which is using an external DLL.
>
> Yes with one big caveat: You have to make sure the library follows what is
> the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
> library covering the wider underlying library and offered via a wider header.
>
> Only C linkage works across different compiler families. You just cannot use
> a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.
>
> But you can use C linkage.  So some libraries (such as the Bloomberg API used
> in Rblpapi and the TileDB API used in the tiledb package (when not using a
> local build) can use a library following the hourglass pattern:
>
>   - "wide" bottom layer (may be C++ or C) with the core implementation
>
>   - "narrow" C layer accessing the bottom and priving an API providing via C
> which profits from C's portable foreign function interface
>
>   - "wide" layer on top via a header-only C++ file accesssing the C and
> which the C++ compiler optimizes away so that the C API is used for 
> linking
>
> Sounds complicated, but works great.
>
> Good detail is in a hour-long but not-too-technical talk here
>
>   https://www.youtube.com/watch?v=PVYdHDm0q6Y
>
> and slides etc are here
>
>   
> https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Dirk Eddelbuettel]

On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.

Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.

Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.

But you can use C linkage.  So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:

 - "wide" bottom layer (may be C++ or C) with the core implementation
 
 - "narrow" C layer accessing the bottom and priving an API providing via C
   which profits from C's portable foreign function interface

 - "wide" layer on top via a header-only C++ file accesssing the C and
   which the C++ compiler optimizes away so that the C API is used for linking

Sounds complicated, but works great.

Good detail is in a hour-long but not-too-technical talk here

 https://www.youtube.com/watch?v=PVYdHDm0q6Y

and slides etc are here

 
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/21/21 5:40 PM, Ezra Tucker wrote:

Hi R package developers,


I'm developing an R package that wraps NREL's SSC library
(https://sam.nrel.gov/), which involves including one header file and
linking to one dll. Thus far it is only tested in linux (works just fine
there) but I am having trouble building/installing on Windows.


The package name is "ssc", after it is all done compiling it says:


  > * DONE (ssc)
  > Error in inDL(x, as.logical(local), as.logical(now), ...) :
  >   unable to load shared object
'C:/Users/EZRATU~1/AppData/Local/Temp/RtmpSaKZH0/pkgload13b41ff33604/ssc.dll':
  >   LoadLibrary failure:  The specified procedure could not be found.
  > Calls: suppressPackageStartupMessages ...  -> load_dll ->
library.dynam2 -> dyn.load -> inDL
  > Execution halted
  >
  > Exited with status 1.


My Makevars.win file, if useful, looks like:

PKG_CPPFLAGS=-I. -I"$C:/SAM/2021.12.02/runtime"
PKG_LIBS=-Wl,-rpath,$C:/SAM/2021.12.02/x64 -L"$C:/SAM/2021.12.02/x64" -lssc

the second includes is to pick up sscapi.h which is a necessary header
file for using this library,

The package relies heavily on Rcpp; My full sessionInfo() is:

R version 4.1.2 (2021-11-01)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
   [1] Rcpp_1.0.7    rstudioapi_0.13   magrittr_2.0.1 usethis_2.1.5
   [5] devtools_2.4.3    pkgload_1.2.4 R6_2.5.1 rlang_0.4.12
   [9] fastmap_1.1.0 fansi_0.5.0   tools_4.1.2 pkgbuild_1.3.0
[13] sessioninfo_1.2.2 utf8_1.2.2    cli_3.1.0 withr_2.4.3
[17] ellipsis_0.3.2    remotes_2.4.2 rprojroot_2.0.2 tibble_3.1.6
[21] lifecycle_1.0.1   crayon_1.4.2  processx_3.5.2 purrr_0.3.4
[25] callr_3.7.0   vctrs_0.3.8   fs_1.5.2 ps_1.6.0
[29] testthat_3.1.1    memoise_2.0.1 glue_1.6.0 cachem_1.0.6
[33] pillar_1.6.4  compiler_4.1.2    desc_1.4.0 prettyunits_1.1.1
[37] pkgconfig_2.0.3

and I have rtools40 installed in C:\rtools40. --no-multiarch is

I read on the internet in various places that this could have something
to do with 64 vs 32-bit architecture, but everything looks like it's
targeting a 64-bit architecture and the DLL I'm linking to is 64-bit.


I see these potential problems:

You cannot have your package named "ssc" if ssc.dll is also the name of 
the external DLL you are linking, because you cannot have two different 
DLLs with the same name linked to a process.


-rpath does not work on Windows. You need to have the directory with the 
external DLL on PATH for Windows to find that DLL.


Then I am not sure why you have the dollar sign in the paths, why not 
"C:/...".


You can have a look at CRAN package Rblpapi which is using an external DLL.

Best
Tomas





Any ideas? Thanks so much!

-Ezra

__
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-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Ezra Tucker]

Hi R package developers,


I'm developing an R package that wraps NREL's SSC library
(https://sam.nrel.gov/), which involves including one header file and
linking to one dll. Thus far it is only tested in linux (works just fine
there) but I am having trouble building/installing on Windows.


The package name is "ssc", after it is all done compiling it says:


 > * DONE (ssc)
 > Error in inDL(x, as.logical(local), as.logical(now), ...) :
 >   unable to load shared object
'C:/Users/EZRATU~1/AppData/Local/Temp/RtmpSaKZH0/pkgload13b41ff33604/ssc.dll':
 >   LoadLibrary failure:  The specified procedure could not be found.
 > Calls: suppressPackageStartupMessages ...  -> load_dll ->
library.dynam2 -> dyn.load -> inDL
 > Execution halted
 >
 > Exited with status 1.


My Makevars.win file, if useful, looks like:

PKG_CPPFLAGS=-I. -I"$C:/SAM/2021.12.02/runtime"
PKG_LIBS=-Wl,-rpath,$C:/SAM/2021.12.02/x64 -L"$C:/SAM/2021.12.02/x64" -lssc

the second includes is to pick up sscapi.h which is a necessary header
file for using this library,

The package relies heavily on Rcpp; My full sessionInfo() is:

R version 4.1.2 (2021-11-01)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
  [1] Rcpp_1.0.7    rstudioapi_0.13   magrittr_2.0.1 usethis_2.1.5
  [5] devtools_2.4.3    pkgload_1.2.4 R6_2.5.1 rlang_0.4.12
  [9] fastmap_1.1.0 fansi_0.5.0   tools_4.1.2 pkgbuild_1.3.0
[13] sessioninfo_1.2.2 utf8_1.2.2    cli_3.1.0 withr_2.4.3
[17] ellipsis_0.3.2    remotes_2.4.2 rprojroot_2.0.2 tibble_3.1.6
[21] lifecycle_1.0.1   crayon_1.4.2  processx_3.5.2 purrr_0.3.4
[25] callr_3.7.0   vctrs_0.3.8   fs_1.5.2 ps_1.6.0
[29] testthat_3.1.1    memoise_2.0.1 glue_1.6.0 cachem_1.0.6
[33] pillar_1.6.4  compiler_4.1.2    desc_1.4.0 prettyunits_1.1.1
[37] pkgconfig_2.0.3

and I have rtools40 installed in C:\rtools40. --no-multiarch is

I read on the internet in various places that this could have something
to do with 64 vs 32-bit architecture, but everything looks like it's
targeting a 64-bit architecture and the DLL I'm linking to is 64-bit.


Any ideas? Thanks so much!

-Ezra

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

Re: [R-pkg-devel] ERROR (re)building vignettes

[Maëlle SALMON via R-package-devel]

Dear Christine,

Looking at the chunk that causes the error 
https://github.com/cran/SleepCycles/blob/141186934418af387f0af257e3079af588e72844/vignettes/introduction.Rmd#L50-L56
 (via the CRAN mirror maintained by R-hub):

* You should not install packages from a vignette. You can add "eval=FALSE" as 
a chunk option.
* Regarding the other lines in that chunk, they do not provoke an error but are 
not recommended by all. See e.g. 
https://www.tidyverse.org/blog/2017/12/workflow-vs-script/

Good luck with re-submission!

Maëlle.




Den onsdag 22 september 2021 22:20:36 CEST, Blume Christine 
 skrev: 





Dear community,

When building my package 'SleepCycles' using devtools::check, 
devtools::check_win_devel, and devtools::check_rhub, I do not get warnings, 
errors, or notes. Nevertheless, there seems to be an error when building the 
vignettes eventually 
(https://cran-archive.r-project.org/web/checks/2021/2021-09-06_check_results_SleepCycles.html),
 which I did not notice and which led to the removal of the package.

Does anyone know how to solve this? I read something about changing the 
vignette engine, but when I tried this, I ran into other issues.

I cannot replicate the error, but simply resubmitting will most likely result 
in the same issue again.

Best,
Christine


    [[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-pkg-devel] ERROR (re)building vignettes

[Blume Christine]

Dear community,

When building my package 'SleepCycles' using devtools::check, 
devtools::check_win_devel, and devtools::check_rhub, I do not get warnings, 
errors, or notes. Nevertheless, there seems to be an error when building the 
vignettes eventually 
(https://cran-archive.r-project.org/web/checks/2021/2021-09-06_check_results_SleepCycles.html),
 which I did not notice and which led to the removal of the package.

Does anyone know how to solve this? I read something about changing the 
vignette engine, but when I tried this, I ran into other issues.

I cannot replicate the error, but simply resubmitting will most likely result 
in the same issue again.

Best,
Christine


[[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 uploading package to CRAN that depends on packages hosted in GitHub

[Uwe Ligges]

On 07.07.2021 17:21, Duncan Murdoch wrote:

On 07/07/2021 9:08 a.m., Uwe Ligges wrote:



On 07.07.2021 13:18, Duncan Murdoch wrote:

On 07/07/2021 5:29 a.m., David Enrique Payares García wrote:

Hello everybody,

I developed an R package that depends on packages hosted in GitHub.
In the DESCRIPTION file, I added the R packages (from GitHub ) in the
"Suggests" section and I included a copy of them in my personal 
GitHub so

they can be accessed in the "Additional_repositories:" section.


Suggests:
  rmarkdown,
  ANTsR,
  ANTsRCore,
  ITKR,
  extrantsr,
  MNITemplate,
  RAVEL
Imports:
  knitr,
  oro.nifti,
  fslr,
  neurobase
Depends:
  R (>= 3.5)
Additional_repositories: https://davidpayares.github.io/drat


A copy of the R packages my package needs is in
https://davidpayares.github.io/drat .
When I submit the package to CRAN, I get this error:


Suggests or Enhances not in mainstream repositories:
  ANTsR, ANTsRCore, ITKR, extrantsr, MNITemplate, RAVEL
    Availability using Additional_repositories specification:
  ANTsR yes   https://davidpayares.github.io/drat
  ANTsRCore yes   https://davidpayares.github.io/drat
  ITKR  yes   https://davidpayares.github.io/drat
  extrantsr yes   https://davidpayares.github.io/drat
  MNITemplate   yes   https://davidpayares.github.io/drat
  RAVEL yes   https://davidpayares.github.io/drat

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
    Packages suggested but not available for checking:
  'ANTsR', 'ANTsRCore', 'ITKR', 'extrantsr', 'MNITemplate', 'RAVEL'

    Namespace dependencies missing from DESCRIPTION Imports/Depends
entries:
  'MNITemplate', 'RAVEL', 'extrantsr'



As the message says: You likely have declared some import directives via
the NAMESPACE file. In that case you have to import from a package and
hence list it in the Imports field.


Maybe the message should say "NAMESPACE dependencies missing from 
DESCRIPTION Imports/Depends entries" to make that even more obvious?



Thanks, I will suggest the change,
Uwe


Duncan Murdoch



If the package is not available from a mainsteam repository and you want
to suggest it only, you cannot import from it via the NAMESPACE file.

Best,
Uwe Ligges




I think this one is the part causing the ERROR.  Without seeing your
package I can't say for sure, but I would guess you have made some
unconditional use of those three packages.  Since they are only
Suggested packages, you can't do that.  Your package has to run even if
they are not available at all.  (It may not have full functionality, but
it shouldn't generate any errors in its tests or examples.)

Duncan Murdoch




I found that this is the correct way to add dependencies that are not
hosted in CRAN. However, I do not understand why it is not working. If
anyone could help me, I would really appreciate it.

Thank you so much.

Cheers,

David Payares

 [[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] Error uploading package to CRAN that depends on packages hosted in GitHub

[Duncan Murdoch]

On 07/07/2021 9:08 a.m., Uwe Ligges wrote:



On 07.07.2021 13:18, Duncan Murdoch wrote:

On 07/07/2021 5:29 a.m., David Enrique Payares García wrote:

Hello everybody,

I developed an R package that depends on packages hosted in GitHub.
In the DESCRIPTION file, I added the R packages (from GitHub ) in the
"Suggests" section and I included a copy of them in my personal GitHub so
they can be accessed in the "Additional_repositories:" section.


Suggests:
  rmarkdown,
  ANTsR,
  ANTsRCore,
  ITKR,
  extrantsr,
  MNITemplate,
  RAVEL
Imports:
  knitr,
  oro.nifti,
  fslr,
  neurobase
Depends:
  R (>= 3.5)
Additional_repositories: https://davidpayares.github.io/drat


A copy of the R packages my package needs is in
https://davidpayares.github.io/drat .
When I submit the package to CRAN, I get this error:


Suggests or Enhances not in mainstream repositories:
  ANTsR, ANTsRCore, ITKR, extrantsr, MNITemplate, RAVEL
    Availability using Additional_repositories specification:
  ANTsR yes   https://davidpayares.github.io/drat
  ANTsRCore yes   https://davidpayares.github.io/drat
  ITKR  yes   https://davidpayares.github.io/drat
  extrantsr yes   https://davidpayares.github.io/drat
  MNITemplate   yes   https://davidpayares.github.io/drat
  RAVEL yes   https://davidpayares.github.io/drat

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
    Packages suggested but not available for checking:
  'ANTsR', 'ANTsRCore', 'ITKR', 'extrantsr', 'MNITemplate', 'RAVEL'

    Namespace dependencies missing from DESCRIPTION Imports/Depends
entries:
  'MNITemplate', 'RAVEL', 'extrantsr'



As the message says: You likely have declared some import directives via
the NAMESPACE file. In that case you have to import from a package and
hence list it in the Imports field.


Maybe the message should say "NAMESPACE dependencies missing from 
DESCRIPTION Imports/Depends entries" to make that even more obvious?


Duncan Murdoch



If the package is not available from a mainsteam repository and you want
to suggest it only, you cannot import from it via the NAMESPACE file.

Best,
Uwe Ligges




I think this one is the part causing the ERROR.  Without seeing your
package I can't say for sure, but I would guess you have made some
unconditional use of those three packages.  Since they are only
Suggested packages, you can't do that.  Your package has to run even if
they are not available at all.  (It may not have full functionality, but
it shouldn't generate any errors in its tests or examples.)

Duncan Murdoch




I found that this is the correct way to add dependencies that are not
hosted in CRAN. However, I do not understand why it is not working. If
anyone could help me, I would really appreciate it.

Thank you so much.

Cheers,

David Payares

 [[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] Error uploading package to CRAN that depends on packages hosted in GitHub

[Greg Jefferis]

> On 7 Jul 2021, at 14:08, Uwe Ligges  wrote:
> 
>>>Namespace dependencies missing from DESCRIPTION Imports/Depends entries:
>>>  'MNITemplate', 'RAVEL', 'extrantsr'
> 
> 
> As the message says: You likely have declared some import directives via the 
> NAMESPACE file. In that case you have to import from a package and hence list 
> it in the Imports field.
> 
> If the package is not available from a mainsteam repository and you want to 
> suggest it only, you cannot import from it via the NAMESPACE file.


As in 

https://github.com/DavidPayares/neuronorm/blob/eeb6249a3da5412cf3632e2a41233400707ef01b/NAMESPACE#L12-L17

importFrom(MNITemplate,getMNIPath)
importFrom(MNITemplate,readMNI)
importFrom(RAVEL,maskIntersect)
importFrom(RAVEL,normalizeRAVEL)
importFrom(extrantsr,ants_regwrite)
importFrom(extrantsr,bias_correct)

>From roxygen2 directives like this:

https://github.com/DavidPayares/neuronorm/blob/b0ca02478dcf7d5a61dad97ada407edf6b2da962/R/preprocessing.R#L209

Best,

Greg.

--
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://jefferislab.org
http://www.zoo.cam.ac.uk/departments/connectomics

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

Re: [R-pkg-devel] Error uploading package to CRAN that depends on packages hosted in GitHub

[Uwe Ligges]

On 07.07.2021 13:18, Duncan Murdoch wrote:

On 07/07/2021 5:29 a.m., David Enrique Payares García wrote:

Hello everybody,

I developed an R package that depends on packages hosted in GitHub.
In the DESCRIPTION file, I added the R packages (from GitHub ) in the
"Suggests" section and I included a copy of them in my personal GitHub so
they can be accessed in the "Additional_repositories:" section.


Suggests:
 rmarkdown,
 ANTsR,
 ANTsRCore,
 ITKR,
 extrantsr,
 MNITemplate,
 RAVEL
Imports:
 knitr,
 oro.nifti,
 fslr,
 neurobase
Depends:
 R (>= 3.5)
Additional_repositories: https://davidpayares.github.io/drat


A copy of the R packages my package needs is in
https://davidpayares.github.io/drat .
When I submit the package to CRAN, I get this error:


Suggests or Enhances not in mainstream repositories:
 ANTsR, ANTsRCore, ITKR, extrantsr, MNITemplate, RAVEL
   Availability using Additional_repositories specification:
 ANTsR yes   https://davidpayares.github.io/drat
 ANTsRCore yes   https://davidpayares.github.io/drat
 ITKR  yes   https://davidpayares.github.io/drat
 extrantsr yes   https://davidpayares.github.io/drat
 MNITemplate   yes   https://davidpayares.github.io/drat
 RAVEL yes   https://davidpayares.github.io/drat

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
   Packages suggested but not available for checking:
 'ANTsR', 'ANTsRCore', 'ITKR', 'extrantsr', 'MNITemplate', 'RAVEL'

   Namespace dependencies missing from DESCRIPTION Imports/Depends 
entries:

 'MNITemplate', 'RAVEL', 'extrantsr'



As the message says: You likely have declared some import directives via 
the NAMESPACE file. In that case you have to import from a package and 
hence list it in the Imports field.


If the package is not available from a mainsteam repository and you want 
to suggest it only, you cannot import from it via the NAMESPACE file.


Best,
Uwe Ligges



I think this one is the part causing the ERROR.  Without seeing your 
package I can't say for sure, but I would guess you have made some 
unconditional use of those three packages.  Since they are only 
Suggested packages, you can't do that.  Your package has to run even if 
they are not available at all.  (It may not have full functionality, but 
it shouldn't generate any errors in its tests or examples.)


Duncan Murdoch




I found that this is the correct way to add dependencies that are not
hosted in CRAN. However, I do not understand why it is not working. If
anyone could help me, I would really appreciate it.

Thank you so much.

Cheers,

David Payares

[[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] Error uploading package to CRAN that depends on packages hosted in GitHub

[Duncan Murdoch]

On 07/07/2021 5:29 a.m., David Enrique Payares García wrote:

Hello everybody,

I developed an R package that depends on packages hosted in GitHub.
In the DESCRIPTION file, I added the R packages (from GitHub ) in the
"Suggests" section and I included a copy of them in my personal GitHub so
they can be accessed in the "Additional_repositories:" section.


Suggests:
 rmarkdown,
 ANTsR,
 ANTsRCore,
 ITKR,
 extrantsr,
 MNITemplate,
 RAVEL
Imports:
 knitr,
 oro.nifti,
 fslr,
 neurobase
Depends:
 R (>= 3.5)
Additional_repositories: https://davidpayares.github.io/drat


A copy of the R packages my package needs is in
https://davidpayares.github.io/drat .
When I submit the package to CRAN, I get this error:


Suggests or Enhances not in mainstream repositories:
 ANTsR, ANTsRCore, ITKR, extrantsr, MNITemplate, RAVEL
   Availability using Additional_repositories specification:
 ANTsR yes   https://davidpayares.github.io/drat
 ANTsRCore yes   https://davidpayares.github.io/drat
 ITKR  yes   https://davidpayares.github.io/drat
 extrantsr yes   https://davidpayares.github.io/drat
 MNITemplate   yes   https://davidpayares.github.io/drat
 RAVEL yes   https://davidpayares.github.io/drat

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
   Packages suggested but not available for checking:
 'ANTsR', 'ANTsRCore', 'ITKR', 'extrantsr', 'MNITemplate', 'RAVEL'

   Namespace dependencies missing from DESCRIPTION Imports/Depends entries:
 'MNITemplate', 'RAVEL', 'extrantsr'


I think this one is the part causing the ERROR.  Without seeing your 
package I can't say for sure, but I would guess you have made some 
unconditional use of those three packages.  Since they are only 
Suggested packages, you can't do that.  Your package has to run even if 
they are not available at all.  (It may not have full functionality, but 
it shouldn't generate any errors in its tests or examples.)


Duncan Murdoch




I found that this is the correct way to add dependencies that are not
hosted in CRAN. However, I do not understand why it is not working. If
anyone could help me, I would really appreciate it.

Thank you so much.

Cheers,

David Payares

[[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-pkg-devel] Error uploading package to CRAN that depends on packages hosted in GitHub

[David Enrique Payares García]

Hello everybody,

I developed an R package that depends on packages hosted in GitHub.
In the DESCRIPTION file, I added the R packages (from GitHub ) in the
"Suggests" section and I included a copy of them in my personal GitHub so
they can be accessed in the "Additional_repositories:" section.


Suggests:
rmarkdown,
ANTsR,
ANTsRCore,
ITKR,
extrantsr,
MNITemplate,
RAVEL
Imports:
knitr,
oro.nifti,
fslr,
neurobase
Depends:
R (>= 3.5)
Additional_repositories: https://davidpayares.github.io/drat


A copy of the R packages my package needs is in
https://davidpayares.github.io/drat .
When I submit the package to CRAN, I get this error:


Suggests or Enhances not in mainstream repositories:
ANTsR, ANTsRCore, ITKR, extrantsr, MNITemplate, RAVEL
  Availability using Additional_repositories specification:
ANTsR yes   https://davidpayares.github.io/drat
ANTsRCore yes   https://davidpayares.github.io/drat
ITKR  yes   https://davidpayares.github.io/drat
extrantsr yes   https://davidpayares.github.io/drat
MNITemplate   yes   https://davidpayares.github.io/drat
RAVEL yes   https://davidpayares.github.io/drat

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
  Packages suggested but not available for checking:
'ANTsR', 'ANTsRCore', 'ITKR', 'extrantsr', 'MNITemplate', 'RAVEL'

  Namespace dependencies missing from DESCRIPTION Imports/Depends entries:
'MNITemplate', 'RAVEL', 'extrantsr'

I found that this is the correct way to add dependencies that are not
hosted in CRAN. However, I do not understand why it is not working. If
anyone could help me, I would really appreciate it.

Thank you so much.

Cheers,

David Payares

[[alternative HTML version deleted]]

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

[R-pkg-devel] ERROR: lazy loading failed for package 'movecost'

[Gianmarco Alberti]

Hello,

I am in the process of checking my ‘movecost’ package before submitting to CRAN.

As usual, I have tested my package locally (on my MAC) using devtools::check() 
and everything is fine, getting 0 error, 0 warnings and 0 notes.

Also, as I routinely do, I used (A) devtools::check_win_devel(); in the 
returned email, the status was OK 
(https://win-builder.r-project.org/lWar6m662wl3).

BUT, I got 1 error from both:
(B) devtools::check_win_release() 
(https://win-builder.r-project.org/6ZzaipUr9rPF)
(C) devtools::check_win_oldrelease() 
(https://win-builder.r-project.org/yXHZoOCov7xH)

I cannot really figure out what is actually causing the error (Im not a 
specialist in programming and the like):
ERROR: lazy loading failed for package ‘movecost'


Any hint/elucidation on the matter, so that I can spot what is causing the 
error, would be appreciated.
Thank you for your time and consideration.

Best
Gianmarco



Dr Gianmarco Alberti (PhD Udine)
Lecturer in Spatial Forensics
Coordinator of the BA dissertations
Department of Criminology
Faculty for Social Wellbeing
Room 332, Humanities B (FEMA)
University of Malta, Msida, Malta (Europe) - MSD 2080
tel +356 2340 3718

Academic profiles
https://www.researchgate.net/profile/Gianmarco_Alberti4
https://malta.academia.edu/GianmarcoAlberti

Google Scholar profile
https://scholar.google.com/citations?user=tFrJKQ0J&hl=en

Correspondence Analysis website
http://cainarchaeology.weebly.com/

R packages on CRAN:
CAinterprTools
https://cran.r-project.org/web/packages/CAinterprTools/index.html

GmAMisc
https://cran.r-project.org/package=GmAMisc

movecost
https://cran.r-project.org/web/packages/movecost/index.html


[[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] data length differs from size of matrix

[Tiago Olivoto]

Exactly Bill!
I'll implement your suggestion (solve_svd(cor.x2)%*%cor.y), to return betas.
Best!
Tiago


Em sex., 4 de jun. de 2021 às 15:12, Bill Dunlap 
escreveu:

> solve_svd's second argument is 'tolerance', a small scalar value, not the
> right hand side of X %*% beta == Y.  It returns the [approximate] inverse
> of X, not beta.
>
> solve_svd(cor.x2,cor.y) should probably be solve_svd(cor.x2)%*%cor.y (or
> just solve(cor.x2,cor.y)).
>
> -Bill
>
> On Fri, Jun 4, 2021 at 8:41 AM Bill Dunlap 
> wrote:
>
>> The offending line in path_coeff seems to be
>>betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
>> where i is a single integer, nvar is 15, and the right hand side is a 14
>> by 14 matrix.  What is this line trying to do?  Did it ever give the
>> correct result?
>>
>> -Bill
>>
>>
>> On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap 
>> wrote:
>>
>>> That log file includes the line
>>> using R Under development (unstable) (2021-05-30 r80413)
>>> and later says
>>>
>>> The error most likely occurred in:
>>>
>>> > ### Name: path_coeff
>>> > ### Title: Path coefficients with minimal multicollinearity
>>> > ### Aliases: path_coeff path_coeff_mat
>>> >
>>> > ### ** Examples
>>> >
>>> > ## No test:
>>> > library(metan)
>>> >
>>> > # Using KW as the response variable and all other ones as predictors
>>> > pcoeff <- path_coeff(data_ge2, resp = KW)
>>> Error in matrix(value, n, p) :
>>>   data length differs from size of matrix: [196 != 1 x 14]
>>> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
>>> Execution halted
>>>
>>> In the current R-devel the matrix command matrix(value, nrow, ncol) 
>>> complains if length(value)>nrow*ncol, so you need to truncate 'value'.  
>>> (Previously matrix() would silently truncate value.)
>>>
>>>
>>> -Bill
>>>
>>>
>>> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
>>> wrote:
>>>
 Dear all,
 I have received an email from the CRAN team to fix a problem with my R
 package metan > to safely retain it on
 CRAN.

 The error is given at <
 https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
 and seems to be related to data different from size of matrix.

 The question is that and I cannot reproduce the error locally and thus
 not
 able to fix anything. By googling the error I've seen similar issues
 with a
 lot of other packages. Could be this be a temporary issue?

 Thanks in advance!
 Tiago

 [[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] data length differs from size of matrix

[Bill Dunlap]

solve_svd's second argument is 'tolerance', a small scalar value, not the
right hand side of X %*% beta == Y.  It returns the [approximate] inverse
of X, not beta.

solve_svd(cor.x2,cor.y) should probably be solve_svd(cor.x2)%*%cor.y (or
just solve(cor.x2,cor.y)).

-Bill

On Fri, Jun 4, 2021 at 8:41 AM Bill Dunlap  wrote:

> The offending line in path_coeff seems to be
>betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
> where i is a single integer, nvar is 15, and the right hand side is a 14
> by 14 matrix.  What is this line trying to do?  Did it ever give the
> correct result?
>
> -Bill
>
>
> On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap 
> wrote:
>
>> That log file includes the line
>> using R Under development (unstable) (2021-05-30 r80413)
>> and later says
>>
>> The error most likely occurred in:
>>
>> > ### Name: path_coeff
>> > ### Title: Path coefficients with minimal multicollinearity
>> > ### Aliases: path_coeff path_coeff_mat
>> >
>> > ### ** Examples
>> >
>> > ## No test:
>> > library(metan)
>> >
>> > # Using KW as the response variable and all other ones as predictors
>> > pcoeff <- path_coeff(data_ge2, resp = KW)
>> Error in matrix(value, n, p) :
>>   data length differs from size of matrix: [196 != 1 x 14]
>> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
>> Execution halted
>>
>> In the current R-devel the matrix command matrix(value, nrow, ncol) 
>> complains if length(value)>nrow*ncol, so you need to truncate 'value'.  
>> (Previously matrix() would silently truncate value.)
>>
>>
>> -Bill
>>
>>
>> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
>> wrote:
>>
>>> Dear all,
>>> I have received an email from the CRAN team to fix a problem with my R
>>> package metan >> > to safely retain it on CRAN.
>>>
>>> The error is given at <
>>> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
>>> and seems to be related to data different from size of matrix.
>>>
>>> The question is that and I cannot reproduce the error locally and thus
>>> not
>>> able to fix anything. By googling the error I've seen similar issues
>>> with a
>>> lot of other packages. Could be this be a temporary issue?
>>>
>>> Thanks in advance!
>>> Tiago
>>>
>>> [[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] data length differs from size of matrix

[Tiago Olivoto]

Thanks, Bill and Max for your suggestions.
I was using R 4.1.0. After updating to R-devel I was able to reproduce the
error, which was just fixed by using solve() instead solve_svd() in the
line suggested by Bill.

Best regards,
Tiago

Em sex., 4 de jun. de 2021 às 12:41, Bill Dunlap 
escreveu:

> The offending line in path_coeff seems to be
>betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
> where i is a single integer, nvar is 15, and the right hand side is a 14
> by 14 matrix.  What is this line trying to do?  Did it ever give the
> correct result?
>
> -Bill
>
>
> On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap 
> wrote:
>
>> That log file includes the line
>> using R Under development (unstable) (2021-05-30 r80413)
>> and later says
>>
>> The error most likely occurred in:
>>
>> > ### Name: path_coeff
>> > ### Title: Path coefficients with minimal multicollinearity
>> > ### Aliases: path_coeff path_coeff_mat
>> >
>> > ### ** Examples
>> >
>> > ## No test:
>> > library(metan)
>> >
>> > # Using KW as the response variable and all other ones as predictors
>> > pcoeff <- path_coeff(data_ge2, resp = KW)
>> Error in matrix(value, n, p) :
>>   data length differs from size of matrix: [196 != 1 x 14]
>> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
>> Execution halted
>>
>> In the current R-devel the matrix command matrix(value, nrow, ncol) 
>> complains if length(value)>nrow*ncol, so you need to truncate 'value'.  
>> (Previously matrix() would silently truncate value.)
>>
>>
>> -Bill
>>
>>
>> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
>> wrote:
>>
>>> Dear all,
>>> I have received an email from the CRAN team to fix a problem with my R
>>> package metan >> > to safely retain it on CRAN.
>>>
>>> The error is given at <
>>> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
>>> and seems to be related to data different from size of matrix.
>>>
>>> The question is that and I cannot reproduce the error locally and thus
>>> not
>>> able to fix anything. By googling the error I've seen similar issues
>>> with a
>>> lot of other packages. Could be this be a temporary issue?
>>>
>>> Thanks in advance!
>>> Tiago
>>>
>>> [[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] data length differs from size of matrix

[Bill Dunlap]

The offending line in path_coeff seems to be
   betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
where i is a single integer, nvar is 15, and the right hand side is a 14 by
14 matrix.  What is this line trying to do?  Did it ever give the correct
result?

-Bill


On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap  wrote:

> That log file includes the line
> using R Under development (unstable) (2021-05-30 r80413)
> and later says
>
> The error most likely occurred in:
>
> > ### Name: path_coeff
> > ### Title: Path coefficients with minimal multicollinearity
> > ### Aliases: path_coeff path_coeff_mat
> >
> > ### ** Examples
> >
> > ## No test:
> > library(metan)
> >
> > # Using KW as the response variable and all other ones as predictors
> > pcoeff <- path_coeff(data_ge2, resp = KW)
> Error in matrix(value, n, p) :
>   data length differs from size of matrix: [196 != 1 x 14]
> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
> Execution halted
>
> In the current R-devel the matrix command matrix(value, nrow, ncol) complains 
> if length(value)>nrow*ncol, so you need to truncate 'value'.  (Previously 
> matrix() would silently truncate value.)
>
>
> -Bill
>
>
> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
> wrote:
>
>> Dear all,
>> I have received an email from the CRAN team to fix a problem with my R
>> package metan > > to safely retain it on CRAN.
>>
>> The error is given at <
>> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
>> and seems to be related to data different from size of matrix.
>>
>> The question is that and I cannot reproduce the error locally and thus not
>> able to fix anything. By googling the error I've seen similar issues with
>> a
>> lot of other packages. Could be this be a temporary issue?
>>
>> Thanks in advance!
>> Tiago
>>
>> [[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] data length differs from size of matrix

[Bill Dunlap]

That log file includes the line
using R Under development (unstable) (2021-05-30 r80413)
and later says

The error most likely occurred in:

> ### Name: path_coeff
> ### Title: Path coefficients with minimal multicollinearity
> ### Aliases: path_coeff path_coeff_mat
>
> ### ** Examples
>
> ## No test:
> library(metan)
>
> # Using KW as the response variable and all other ones as predictors
> pcoeff <- path_coeff(data_ge2, resp = KW)
Error in matrix(value, n, p) :
  data length differs from size of matrix: [196 != 1 x 14]
Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
Execution halted

In the current R-devel the matrix command matrix(value, nrow, ncol)
complains if length(value)>nrow*ncol, so you need to truncate 'value'.
(Previously matrix() would silently truncate value.)


-Bill


On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto  wrote:

> Dear all,
> I have received an email from the CRAN team to fix a problem with my R
> package metan  > to safely retain it on CRAN.
>
> The error is given at <
> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> and seems to be related to data different from size of matrix.
>
> The question is that and I cannot reproduce the error locally and thus not
> able to fix anything. By googling the error I've seen similar issues with a
> lot of other packages. Could be this be a temporary issue?
>
> Thanks in advance!
> Tiago
>
> [[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] data length differs from size of matrix

[Max Turgeon]

I apologize for the wrong link below; as described here: 
https://cran.r-project.org/doc/manuals/r-devel/NEWS.html



Max Turgeon<https://www.name-coach.com/maxime-turgeon>
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca<http://maxturgeon.ca>



From: R-package-devel  on behalf of Max 
Turgeon 
Sent: Friday, June 4, 2021 9:35 AM
To: Tiago Olivoto ; R Package Devel 

Subject: Re: [R-pkg-devel] [Error] data length differs from size of matrix


Caution: This message was sent from outside the University of Manitoba.


Hi Tiago,

Which version of R are you using? You will probably need to use the R-devel 
version to reproduce the error AND set a flag, as described here: 
https://cran.r-project.org/

Best,


Max Turgeon<https://www.name-coach.com/maxime-turgeon>
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca<http://maxturgeon.ca>



From: R-package-devel  on behalf of 
Tiago Olivoto 
Sent: Thursday, June 3, 2021 7:56 PM
To: R Package Devel 
Subject: [R-pkg-devel] [Error] data length differs from size of matrix


Caution: This message was sent from outside the University of Manitoba.


Dear all,
I have received an email from the CRAN team to fix a problem with my R
package metan <https://CRAN.R-project.org/package=metan
<https://cran.r-project.org/package=metan>> to safely retain it on CRAN.

The error is given at <https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
and seems to be related to data different from size of matrix.

The question is that and I cannot reproduce the error locally and thus not
able to fix anything. By googling the error I've seen similar issues with a
lot of other packages. Could be this be a temporary issue?

Thanks in advance!
Tiago

[[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


[[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] data length differs from size of matrix

[Max Turgeon]

Hi Tiago,

Which version of R are you using? You will probably need to use the R-devel 
version to reproduce the error AND set a flag, as described here: 
https://cran.r-project.org/

Best,


Max Turgeon<https://www.name-coach.com/maxime-turgeon>
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca<http://maxturgeon.ca>



From: R-package-devel  on behalf of 
Tiago Olivoto 
Sent: Thursday, June 3, 2021 7:56 PM
To: R Package Devel 
Subject: [R-pkg-devel] [Error] data length differs from size of matrix


Caution: This message was sent from outside the University of Manitoba.


Dear all,
I have received an email from the CRAN team to fix a problem with my R
package metan <https://CRAN.R-project.org/package=metan
<https://cran.r-project.org/package=metan>> to safely retain it on CRAN.

The error is given at <https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
and seems to be related to data different from size of matrix.

The question is that and I cannot reproduce the error locally and thus not
able to fix anything. By googling the error I've seen similar issues with a
lot of other packages. Could be this be a temporary issue?

Thanks in advance!
Tiago

[[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-pkg-devel] [Error] data length differs from size of matrix

[Tiago Olivoto]

Dear all,
I have received an email from the CRAN team to fix a problem with my R
package metan > to safely retain it on CRAN.

The error is given at 
and seems to be related to data different from size of matrix.

The question is that and I cannot reproduce the error locally and thus not
able to fix anything. By googling the error I've seen similar issues with a
lot of other packages. Could be this be a temporary issue?

Thanks in advance!
Tiago

[[alternative HTML version deleted]]

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

[R-pkg-devel] Error in methods::getMethod(name, eval(call$signature), where = env)

[Francisco Palomares]

Hi,
I have this problem:

Error in methods::getMethod(name, eval(call$signature), where = env) :
  no method found for function 'predict_inputs' and signature 
DecisionTreeClassifier
Calls: suppressPackageStartupMessages ... object_from_call -> 
parser_setMethod -> 



Code:
#' An S4 method to predict inputs.
#' @param object DecisionTree object
#' @param ... This parameter is included for compatibility reasons.
setGeneric("predict_inputs", function(object,...)
  standardGeneric("predict_inputs") )

#' @title Predict inputs Decision Tree
#' @description Function to predict one input in Decision Tree
#' @param object DecisionTree object
#' @param inputs inputs to be predicted
#' @param type type prediction, class or prob
#' @export
setMethod(f="predict_inputs",
  signature="DecisionTreeClassifier",
  definition=function(object,inputs,type = "class")
  {



What is the problem?
Thanks

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

Re: [R-pkg-devel] Error concerning rtracklayer

[Michael Dewey]

Dear Danielle

If you search the most recent postings on this list
https://stat.ethz.ch/pipermail/r-package-devel/2021q2/subject.html
you will see that several of them have rtracklayer in their title. Does 
any of them help you?


Note that if they had used an uninformative title as you do it would be 
harder to find them so I have added that to your title.


Michael

On 06/05/2021 22:59, Danielle Maeser wrote:

Hello,

The R CMD check passed with 0 errors and warnings, so I proceeded to submit
to CRAN. However, CRAN reported 1 error (see below). If you have any
insight as to what this error means, please let me know.

I'm perplexed because *rtracklayer *is not a package dependency, and
I'm not sure where it came from. Perhaps this is a false positive?

** installing *source* package 'oncoPredict' ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
versionCheck = vI[[j]]) :
   namespace 'rtracklayer' 1.48.0 is being loaded, but >= 1.51.5 is required
Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
Execution halted
ERROR: lazy loading failed for package 'oncoPredict'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/oncoPredict'
* restoring previous 'd:/RCompile/CRANincoming/R-devel/lib/oncoPredict'*

[[alternative HTML version deleted]]

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



--
Michael
http://www.dewey.myzen.co.uk/home.html

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

[R-pkg-devel] Error

[Danielle Maeser]

Hello,

The R CMD check passed with 0 errors and warnings, so I proceeded to submit
to CRAN. However, CRAN reported 1 error (see below). If you have any
insight as to what this error means, please let me know.

I'm perplexed because *rtracklayer *is not a package dependency, and
I'm not sure where it came from. Perhaps this is a false positive?

** installing *source* package 'oncoPredict' ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
versionCheck = vI[[j]]) :
  namespace 'rtracklayer' 1.48.0 is being loaded, but >= 1.51.5 is required
Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
Execution halted
ERROR: lazy loading failed for package 'oncoPredict'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/oncoPredict'
* restoring previous 'd:/RCompile/CRANincoming/R-devel/lib/oncoPredict'*

[[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 messages

[Uwe Ligges]

Or simply navigate to the install log which is avaiable from the links 
you got.


Best,
Uwe Ligges

On 14.04.2021 03:47, Dirk Eddelbuettel wrote:


On 14 April 2021 at 01:03, csmatyi wrote:
| Debian
|
| * using log directory ‘/srv/hornik/tmp/CRAN/hybridogram.Rcheck’
| * using R Under development (unstable) (2021-04-12 r80161)
| * using platform: x86_64-pc-linux-gnu (64-bit)
| * using session charset: UTF-8
| * checking for file ‘hybridogram/DESCRIPTION’ ... OK
| * checking extension type ... Package
| * this is package ‘hybridogram’ version ‘0.2.0’
| * package encoding: UTF-8
| * checking CRAN incoming feasibility ... NOTE
| Maintainer: ‘Matthew Cserhati <
| csma...@protonmail.com
| >’
|
| New submission
| * checking package namespace information ... OK
| * checking package dependencies ... OK
| * checking if this is a source package ... OK
| * checking if there is a namespace ... OK
| * checking for executable files ... OK
| * checking for hidden files and directories ... OK
| * checking for portable file names ... OK
| * checking for sufficient/correct file permissions ... OK
| * checking serialization versions ... OK
| * checking whether package ‘hybridogram’ can be installed ... [0s/0s] ERROR
| Installation failed.
| See ‘/srv/hornik/tmp/CRAN/
| hybridogram.Rcheck/00install.out
| ’ for details.
| * DONE
| Status: 1 ERROR, 1 NOTE

You need to figure out why it does not install.

RHub (http://builder.r-hub.io/) may help if you do not have a suitable
machine nearby.

Dirk



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

[R-pkg-devel] error messages

[csmatyi]

Hello R package developers,

I tried sending in my package for the fifth time or so, but it still says that 
it has errors. I read the error messages but I cannot figure out what the error 
could be. Does anyone know?

Thanks, Matthew

--
Windows

* using log directory 'd:/RCompile/CRANincoming/R-devel/hybridogram.Rcheck'
* using R Under development (unstable) (2021-04-11 r80157)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'hybridogram/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'hybridogram' version '0.2.0'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Matthew Cserhati <
csma...@protonmail.com
>'

New submission
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'hybridogram' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
** checking loading without being on the library search path ... OK
** checking use of S3 registration ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
** checking loading without being on the library search path ... OK
** checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... [4s] OK
* checking for missing documentation entries ... OK
* checking installed files from 'inst/doc' ... OK
* checking files in 'vignettes' ... OK
* checking examples ... NONE
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... OK
* checking re-building of vignette outputs ... [1s] OK
* checking PDF version of manual ... OK
* checking for detritus in the temp directory ... OK
* DONE
Status: 1 NOTE

Debian

* using log directory ‘/srv/hornik/tmp/CRAN/hybridogram.Rcheck’
* using R Under development (unstable) (2021-04-12 r80161)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘hybridogram/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘hybridogram’ version ‘0.2.0’
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Matthew Cserhati <
csma...@protonmail.com
>’

New submission
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking serialization versions ... OK
* checking whether package ‘hybridogram’ can be installed ... [0s/0s] ERROR
Installation failed.
See ‘/srv/hornik/tmp/CRAN/
hybridogram.Rcheck/00install.out
’ for details.
* DONE
Status: 1 ERROR, 1 NOTE
[[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 messages

[Dirk Eddelbuettel]

On 14 April 2021 at 01:03, csmatyi wrote:
| Debian
| 
| * using log directory ‘/srv/hornik/tmp/CRAN/hybridogram.Rcheck’
| * using R Under development (unstable) (2021-04-12 r80161)
| * using platform: x86_64-pc-linux-gnu (64-bit)
| * using session charset: UTF-8
| * checking for file ‘hybridogram/DESCRIPTION’ ... OK
| * checking extension type ... Package
| * this is package ‘hybridogram’ version ‘0.2.0’
| * package encoding: UTF-8
| * checking CRAN incoming feasibility ... NOTE
| Maintainer: ‘Matthew Cserhati <
| csma...@protonmail.com
| >’
| 
| New submission
| * checking package namespace information ... OK
| * checking package dependencies ... OK
| * checking if this is a source package ... OK
| * checking if there is a namespace ... OK
| * checking for executable files ... OK
| * checking for hidden files and directories ... OK
| * checking for portable file names ... OK
| * checking for sufficient/correct file permissions ... OK
| * checking serialization versions ... OK
| * checking whether package ‘hybridogram’ can be installed ... [0s/0s] ERROR
| Installation failed.
| See ‘/srv/hornik/tmp/CRAN/
| hybridogram.Rcheck/00install.out
| ’ for details.
| * DONE
| Status: 1 ERROR, 1 NOTE

You need to figure out why it does not install.

RHub (http://builder.r-hub.io/) may help if you do not have a suitable
machine nearby.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

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

[Bill Dunlap]

Have you run the offending examples under valgrind on Linux with
gctorture(TRUE)?

-Bill

On Thu, Apr 1, 2021 at 11:51 AM Zhang, Wan  wrote:
>
> Hello,
>
> In our package “BET” version 0.3.4 published on 2021-03-21, there is a 
> “memory not mapped” error on Solaris 10.
>
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/BET-00check.html
>
> I tried to replicate this error with R-hub but it works well. What can I do 
> to simulate CRAN’s environment in S 10 and fix this problem?
>
> Any help from you will be highly appreciated!
>
> Best,
> Wan
>
> [[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 on Solaris 10 'memory not mapped'

[Dirk Eddelbuettel]

On 1 April 2021 at 18:39, Zhang, Wan wrote:
| Hello,
| 
| In our package �BET� version 0.3.4 published on 2021-03-21, there is a 
�memory not mapped� error on Solaris 10.
| 
| https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/BET-00check.html
| 
| I tried to replicate this error with R-hub but it works well. What can I do 
to simulate CRAN�s environment in S 10 and fix this problem?

It is difficult to say more than Dave and I said in comments to your post on
this at StackOverflow:
https://stackoverflow.com/questions/66894044/memory-not-mapped-error-in-r-on-solaris-10

None of us have access to the exact same configuration as that test machine.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

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

[Zhang, Wan]

Hello,

In our package �BET� version 0.3.4 published on 2021-03-21, there is a �memory 
not mapped� error on Solaris 10.

https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/BET-00check.html

I tried to replicate this error with R-hub but it works well. What can I do to 
simulate CRAN�s environment in S 10 and fix this problem?

Any help from you will be highly appreciated!

Best,
Wan

[[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 occurring only when I submit to CRAN

[Elysée Aristide]

Thank you for your explanation.

*-*

*Aristide Elysée HOUNDETOUNGAN*
*Ph.D. Candidate in Economics at Université Laval*
*Personal website : *www.ahoundetoungan.com




On Fri, 12 Feb 2021 at 11:08, Ivan Krylov  wrote:

> On Fri, 12 Feb 2021 09:47:37 -0500
> Elysée Aristide  wrote:
>
> > I did not want to put restrictions.
>
> Apologies, I could have phrased this better.
>
> If you want the whole of your package to be distributed under the terms
> of Apache-2.0 or GPL-3 license (at the user's choosing), the following
> DESCRIPTION fragment seems to be the way to express that intent:
>
> License: GPL-3 | file LICENSE
>
> > What is the better thing to put if I do not want to put
> > restrictions? The easiest one which allows sharing, copying ...?
>
> Personally, I would keep things simple by choosing only one license.
> Exactly which one to choose is a question of personal preference, as
> such known to result in flame wars, so I must try to stay neutral.
>
> For R packages, the line between Apache-style "please retain the
> copyright notice if you redistribute" licenses and GPL-style "please
> share your improvements as source code if you redistribute" is somewhat
> blurry, since people typically share source .tar.gz packages anyway,
> thus fulfilling the terms of both licenses. The differences only come
> into play only when other people distribute the _binary_ packages built
> from your source code they _modified_.
>
> Perhaps re-reading WRE 1.1.2
>  or
> consulting websites like  or
>  would help?
>
> --
> Best regards,
> Ivan
>
> [If you don't mind, let's keep this correspondence on the list by
> replying-to-all and Cc:-ing ]
>

[[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 occurring only when I submit to CRAN

[Ivan Krylov]

On Fri, 12 Feb 2021 09:47:37 -0500
Elysée Aristide  wrote:

> I did not want to put restrictions.

Apologies, I could have phrased this better.

If you want the whole of your package to be distributed under the terms
of Apache-2.0 or GPL-3 license (at the user's choosing), the following
DESCRIPTION fragment seems to be the way to express that intent:

License: GPL-3 | file LICENSE

> What is the better thing to put if I do not want to put
> restrictions? The easiest one which allows sharing, copying ...?

Personally, I would keep things simple by choosing only one license.
Exactly which one to choose is a question of personal preference, as
such known to result in flame wars, so I must try to stay neutral.

For R packages, the line between Apache-style "please retain the
copyright notice if you redistribute" licenses and GPL-style "please
share your improvements as source code if you redistribute" is somewhat
blurry, since people typically share source .tar.gz packages anyway,
thus fulfilling the terms of both licenses. The differences only come
into play only when other people distribute the _binary_ packages built
from your source code they _modified_.

Perhaps re-reading WRE 1.1.2
 or
consulting websites like  or
 would help?

-- 
Best regards,
Ivan

[If you don't mind, let's keep this correspondence on the list by
replying-to-all and Cc:-ing ]

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

Re: [R-pkg-devel] Error occurring only when I submit to CRAN

[Sokol Serguei]

Le 12/02/2021 à 08:45, Elysée Aristide a écrit :
> Greetings,
>
> I submitted my package CDatanet .
> Before that I checked (as CRAN) locally on Linux and Windows and I did not
> get any error. I only get a note about my address mail (which is normal).
> However, when I submitted the package to CRAN, I got a warning and an error
> with the Window server:  
> https://win-builder.r-project.org/incoming_pretest/CDatanet_0.0.1_20210208_174258/Windows/00check.log
>
>
> * checking PDF version of manual ... WARNING
>
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! Package inputenc Error: Unicode char ‐ (U+2010)

This is a frequent source of errors. Somewhere in your manual there is a 
unicode 2010 hyphen "‐" ( https://www.compart.com/fr/unicode/U+2010 ) 
instead of plain ASCII hyphen "-". They look pretty similar, don't they? 
May be you did some copy/paste from e.g. a pdf file and thus got this 
character in your texts.

Supposing that it is not so critical for your documentation to have 
U+2010 char, you can replace it by a hyphen from your keyboard. To spot 
its exact place you can try |tools::showNonASCIIfile().|

|Best,
Serguei.|

|
|

> (inputenc)not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H   for immediate help.
> * checking PDF version of manual without hyperrefs or index ... ERROR
> * checking for detritus in the temp directory ... OK
> * DONE
>
> Status: 1 ERROR, 1 WARNING, 1 NOTE
>
>
> while the Debian server is ok:  
> https://win-builder.r-project.org/incoming_pretest/CDatanet_0.0.1_20210208_174258/Debian/00check.log
>
> How can I fix this given that I am not able to reproduce the error locally?
>
> Thank you very much for your help.
>
> *-*
>
> *Aristide Elysée HOUNDETOUNGAN*
> *Ph.D. Candidate in Economics at Université Laval*
> *Personal website : *www.ahoundetoungan.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

Re: [R-pkg-devel] Error occurring only when I submit to CRAN

[Ivan Krylov]

On Fri, 12 Feb 2021 02:45:02 -0500
Elysée Aristide  wrote:

> How can I fix this given that I am not able to reproduce the error
> locally?

Your LaTeX setup seems to have better Unicode support than the one
installed on CRAN machines. Try using tools::showNonASCIIfile on all
your *.Rd files to find the one containing a Unicode hyphen, then
replacing it with ASCII hyphen-minus.

I'm afraid that I'm finding your use of License: field a bit confusing.
"GPL-3 + file LICENSE" typically means that the package license
restricts a base license, the restrictions being provided in the
LICENSE file. In your case, LICENSE seems to contain the text
of Apache-2.0 license. Does it mean that some parts of the package are
GPL-3, while others are covered by the Apache license? If you want to
indicate that either license applies to the whole package, I think that
"GPL-3 | file LICENSE" would be a better fit. Apologies if you have
already clarified this particular usage with someone more knowledgeable
than me.

-- 
Best regards,
Ivan

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

[R-pkg-devel] Error occurring only when I submit to CRAN

[Elysée Aristide]

Greetings,

I submitted my package CDatanet .
Before that I checked (as CRAN) locally on Linux and Windows and I did not
get any error. I only get a note about my address mail (which is normal).
However, when I submitted the package to CRAN, I got a warning and an error
with the Window server:  
https://win-builder.r-project.org/incoming_pretest/CDatanet_0.0.1_20210208_174258/Windows/00check.log


* checking PDF version of manual ... WARNING

LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
! Package inputenc Error: Unicode char ‐ (U+2010)
(inputenc)not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H   for immediate help.
* checking PDF version of manual without hyperrefs or index ... ERROR
* checking for detritus in the temp directory ... OK
* DONE

Status: 1 ERROR, 1 WARNING, 1 NOTE


while the Debian server is ok:  
https://win-builder.r-project.org/incoming_pretest/CDatanet_0.0.1_20210208_174258/Debian/00check.log

How can I fix this given that I am not able to reproduce the error locally?

Thank you very much for your help.

*-*

*Aristide Elysée HOUNDETOUNGAN*
*Ph.D. Candidate in Economics at Université Laval*
*Personal website : *www.ahoundetoungan.com

[[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 loadNamespace(x) : there is no package called 'formatR'

[Martin Maechler]

> Duncan Murdoch 
> on Fri, 13 Nov 2020 17:45:44 -0500 writes:

> On 13/11/2020 4:32 p.m., Gábor Csárdi wrote:
>> On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch 
 wrote:
>> [...]
>>> Things may have changed since Henrik and I wrote the code, but his
>>> description matches my understanding as well (and I think he's
>>> contributed more recently than I have).
>>> 
>>> The way non-Sweave vignettes work is that some packages register
>>> themselves to recognize vignette files in the vignettes directory.  The
>>> default one recognizes .Rnw files as vignettes (and a few other
>>> extensions too); the knitr::rmarkdown one recognizes .Rmd files and some
>>> others.  The only way for a package's registration code to be called is
>>> for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine
>>> for details of the engine.
>> 
>> Can one of you please fix WRE then? The part that says
>> 
>> "...then knitr provides the engine but both knitr and rmarkdown are
>> needed for using it, so both these packages need to be in the
>> ‘VignetteBuilder’ field..."
>> 

> No, neither of us are members of R Core.  Only R Core can edit the 
manuals.

> Duncan Murdoch

I've (finaly) followed this thread to here  ((too many e-mails, too many ...)).

I think I have understood what you wrote and why R Core should
change WRE in this part.

Notably as I have not written it, there needs to be consultation
--> Forwarding to R-core  ((i.e., a very rare cross-post !))

Thank you, very much for the discussion, Gábor, Henrik and Duncan!
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Duncan Murdoch]

On 13/11/2020 4:32 p.m., Gábor Csárdi wrote:

On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch  wrote:
[...]

Things may have changed since Henrik and I wrote the code, but his
description matches my understanding as well (and I think he's
contributed more recently than I have).

The way non-Sweave vignettes work is that some packages register
themselves to recognize vignette files in the vignettes directory.  The
default one recognizes .Rnw files as vignettes (and a few other
extensions too); the knitr::rmarkdown one recognizes .Rmd files and some
others.  The only way for a package's registration code to be called is
for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine
for details of the engine.


Can one of you please fix WRE then? The part that says

"...then knitr provides the engine but both knitr and rmarkdown are
needed for using it, so both these packages need to be in the
‘VignetteBuilder’ field..."



No, neither of us are members of R Core.  Only R Core can edit the manuals.

Duncan Murdoch

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch  wrote:
[...]
> Things may have changed since Henrik and I wrote the code, but his
> description matches my understanding as well (and I think he's
> contributed more recently than I have).
>
> The way non-Sweave vignettes work is that some packages register
> themselves to recognize vignette files in the vignettes directory.  The
> default one recognizes .Rnw files as vignettes (and a few other
> extensions too); the knitr::rmarkdown one recognizes .Rmd files and some
> others.  The only way for a package's registration code to be called is
> for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine
> for details of the engine.

Can one of you please fix WRE then? The part that says

"...then knitr provides the engine but both knitr and rmarkdown are
needed for using it, so both these packages need to be in the
‘VignetteBuilder’ field..."

Thanks a lot!

Gabor

[...]

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Duncan Murdoch]

On 13/11/2020 1:48 p.m., Gábor Csárdi wrote:

On Fri, Nov 13, 2020 at 6:10 PM Henrik Bengtsson
 wrote:


I'm quite sure you want to use the following:

Suggests: knitr, rmarkdown, formatR
VignetteBuilder: knitr


So this means that WRE is wrong? It says:


> "Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
> then knitr provides the engine but both knitr and rmarkdown are needed
> for using it, so both these packages need to be in the
> ‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
> suggested by knitr, and hence not available automatically along with
> it). Many packages using knitr also need the package formatR which it
> suggests and so the user package needs to do so too and include this
> in ‘VignetteBuilder’."

Things may have changed since Henrik and I wrote the code, but his 
description matches my understanding as well (and I think he's 
contributed more recently than I have).


The way non-Sweave vignettes work is that some packages register 
themselves to recognize vignette files in the vignettes directory.  The 
default one recognizes .Rnw files as vignettes (and a few other 
extensions too); the knitr::rmarkdown one recognizes .Rmd files and some 
others.  The only way for a package's registration code to be called is 
for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine 
for details of the engine.


The rmarkdown package doesn't register any vignette engines, so it 
doesn't need to be in VignetteBuilder.  Same for formatR.


It's fairly common to have a package only used in the vignette, so you 
list it in Suggests.  But that wouldn't apply only to rmarkdown and 
formatR, there are lots of other examples.  However, I'd guess it's 
pretty common to forget to include rmarkdown and formatR, since they may 
not be explicitly used.  Then putting them in the VignetteBuilder field 
will trigger an error if they are not also in Suggests.


Duncan Murdoch




My understanding is that R CMD build (and possibly other
commands/functions as well) checks for the packages in
'VignetteBulider`, this is why you need to include rmarkdown and
formatR as well. See the source code in build.R and e.g.
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15775 etc.


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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

On Fri, Nov 13, 2020 at 6:10 PM Henrik Bengtsson
 wrote:
>
> I'm quite sure you want to use the following:
>
> Suggests: knitr, rmarkdown, formatR
> VignetteBuilder: knitr

So this means that WRE is wrong? It says:

"Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
then knitr provides the engine but both knitr and rmarkdown are needed
for using it, so both these packages need to be in the
‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
suggested by knitr, and hence not available automatically along with
it). Many packages using knitr also need the package formatR which it
suggests and so the user package needs to do so too and include this
in ‘VignetteBuilder’."

My understanding is that R CMD build (and possibly other
commands/functions as well) checks for the packages in
'VignetteBulider`, this is why you need to include rmarkdown and
formatR as well. See the source code in build.R and e.g.
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15775 etc.

G.

[...]

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Joseph Park]

Thank you for the clarification.

J Park

On 11/13/20 1:09 PM, Henrik Bengtsson wrote:
> I'm quite sure you want to use the following:
>
> Suggests: knitr, rmarkdown, formatR
> VignetteBuilder: knitr
>
> Here are the details.  For the 'VignetteBuilder' field, you want to
> put all packages that provide the **vignette engines** you are using.
> For example, if your package vignettes use either of
>
> %\VignetteEngine{knitr::knitr}
> %\VignetteEngine{knitr::rmarkdown}
>
> your package is using a vignette engine from the 'knitr' package, so
> you need to specify:
>
> VignetteBuilder: knitr
>
> Next, with 'knitr' listed in 'VignetteBuilder', you need to make sure
> 'knitr' is listed in either 'Depends' or 'Suggests' (or possibly
> 'Imports' - not sure).  If 'knitr' is only used for your vignettes, it
> is sufficient to specify it under 'Suggests', which is also the most
> common way to use it, i.e.
>
> Suggests: knitr
>
> The above settles the **vignette-engine package**.  Then your vignette
> engine might depend on additional packages.  Your package needs to
> depend on those too, typically also listed under 'Suggests'.  For
> example, when you use %\VignetteEngine{knitr::rmarkdown}, that
> vignette engine requires the 'rmarkdown' package (can be guessed from
> them name but reading the docs is the only way to be sure - I think
> there's work in 'tools' to improve on this).So, this means you
> need to use:
>
> Suggests: knitr, rmarkdown
>
> Finally, if your vignettes make use of additional, optional features
> from other packages, you need to make sure your package depends on
> those too.  Since you make use of 'formatR' features, you need to add
> that to Suggests as well;
>
> Suggests: knitr, rmarkdown, formatR
>
> /Henrik
>
> PS. Vignettes are a bit of special creatures. Their dependencies are
> only needed during 'R CMD build' and 'R CMD check', which most
> end-users never perform. I think it could be favorable if we could
> declare vignette dependencies separate from install/run-time
> dependencies, e.g.
>
> VignetteBuilder: knitr
> VignetteDepends: rmarkdown, formatR
>
> It should make the above process a bit clearer.  It would also make it
> clear to those who are only interested in viewing vignettes, but have
> no interest in rebuilding vignettes, what packages they need to
> install in order to access all of the package's functions.  Just an
> idea.
>
> On Fri, Nov 13, 2020 at 7:55 AM Joseph Park  wrote:
>> Thank you.
>>
>> On 11/13/20 10:31 AM, Gábor Csárdi wrote:
>>> >From WRE:
>>>
>>> "Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
>>> then knitr provides the engine but both knitr and rmarkdown are needed
>>> for using it, so both these packages need to be in the
>>> ‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
>>> suggested by knitr, and hence not available automatically along with
>>> it). Many packages using knitr also need the package formatR which it
>>> suggests and so the user package needs to do so too and include this
>>> in ‘VignetteBuilder’."
>>>
>>> So I think you need
>>>
>>> Suggests: knitr, rmarkdown, formatR
>>> VignetteBuilder: knitr, rmarkdown, formatR
>>>
>>> On Fri, Nov 13, 2020 at 3:23 PM Joseph Park  wrote:
 Ah, yes... I see it now in Writing R Extensions.  Apologies for the
 oversight.

 Regarding rmarkdown, is it redundant to include rmarkdown in
 VignetteBuilder if it is in Suggests, or is perhaps needed in the build
 config as a separate entity?

 e.g:

 Suggests: knitr, rmarkdown
 VignetteBuilder: knitr, formatR

 or

 Suggests: knitr, rmarkdown
 VignetteBuilder: knitr, rmarkdown, formatR

 Thank you.

 J Park

 On 11/13/20 8:58 AM, Gábor Csárdi wrote:
> I think you need to Suggest the formatR package, because your
> vignettes use it. From 'Writing R extensions':
>
> "Many packages using knitr also need the package formatR which it
> suggests and so the user package needs to do so too and include this
> in ‘VignetteBuilder’."
>
> Gabor
>
> On Fri, Nov 13, 2020 at 1:49 PM Joseph Park  wrote:
>> Dear r-package-devel,
>>
>> The rEDM package is failing the automated check, as noted here:
>>
>> https://win-builder.r-project.org/incoming_pretest/rEDM_1.7.0_20201113_131811/Windows/00check.log
>>
>> When running rhub::check_for_cran(), disk file errors were reported.
>>
>> The automated check seems to be failing with:
>>
>> Error in loadNamespace(x) : there is no package called 'formatR'
>>
>> This package does not explicitly use formatR:
>>
>> Imports: methods, Rcpp (>= 1.0.1)
>> LinkingTo: Rcpp, RcppThread
>> Suggests: knitr, rmarkdown
>> VignetteBuilder: knitr
>>
>> Could it be these errors (disk full, no formatR) are related?  If not,
>> does formatR need to be listed as a dependency?
>>
>> If the former (R s

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Henrik Bengtsson]

I'm quite sure you want to use the following:

Suggests: knitr, rmarkdown, formatR
VignetteBuilder: knitr

Here are the details.  For the 'VignetteBuilder' field, you want to
put all packages that provide the **vignette engines** you are using.
For example, if your package vignettes use either of

%\VignetteEngine{knitr::knitr}
%\VignetteEngine{knitr::rmarkdown}

your package is using a vignette engine from the 'knitr' package, so
you need to specify:

VignetteBuilder: knitr

Next, with 'knitr' listed in 'VignetteBuilder', you need to make sure
'knitr' is listed in either 'Depends' or 'Suggests' (or possibly
'Imports' - not sure).  If 'knitr' is only used for your vignettes, it
is sufficient to specify it under 'Suggests', which is also the most
common way to use it, i.e.

Suggests: knitr

The above settles the **vignette-engine package**.  Then your vignette
engine might depend on additional packages.  Your package needs to
depend on those too, typically also listed under 'Suggests'.  For
example, when you use %\VignetteEngine{knitr::rmarkdown}, that
vignette engine requires the 'rmarkdown' package (can be guessed from
them name but reading the docs is the only way to be sure - I think
there's work in 'tools' to improve on this).So, this means you
need to use:

Suggests: knitr, rmarkdown

Finally, if your vignettes make use of additional, optional features
from other packages, you need to make sure your package depends on
those too.  Since you make use of 'formatR' features, you need to add
that to Suggests as well;

Suggests: knitr, rmarkdown, formatR

/Henrik

PS. Vignettes are a bit of special creatures. Their dependencies are
only needed during 'R CMD build' and 'R CMD check', which most
end-users never perform. I think it could be favorable if we could
declare vignette dependencies separate from install/run-time
dependencies, e.g.

VignetteBuilder: knitr
VignetteDepends: rmarkdown, formatR

It should make the above process a bit clearer.  It would also make it
clear to those who are only interested in viewing vignettes, but have
no interest in rebuilding vignettes, what packages they need to
install in order to access all of the package's functions.  Just an
idea.

On Fri, Nov 13, 2020 at 7:55 AM Joseph Park  wrote:
>
> Thank you.
>
> On 11/13/20 10:31 AM, Gábor Csárdi wrote:
> > >From WRE:
> >
> > "Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
> > then knitr provides the engine but both knitr and rmarkdown are needed
> > for using it, so both these packages need to be in the
> > ‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
> > suggested by knitr, and hence not available automatically along with
> > it). Many packages using knitr also need the package formatR which it
> > suggests and so the user package needs to do so too and include this
> > in ‘VignetteBuilder’."
> >
> > So I think you need
> >
> > Suggests: knitr, rmarkdown, formatR
> > VignetteBuilder: knitr, rmarkdown, formatR
> >
> > On Fri, Nov 13, 2020 at 3:23 PM Joseph Park  wrote:
> >> Ah, yes... I see it now in Writing R Extensions.  Apologies for the
> >> oversight.
> >>
> >> Regarding rmarkdown, is it redundant to include rmarkdown in
> >> VignetteBuilder if it is in Suggests, or is perhaps needed in the build
> >> config as a separate entity?
> >>
> >> e.g:
> >>
> >> Suggests: knitr, rmarkdown
> >> VignetteBuilder: knitr, formatR
> >>
> >> or
> >>
> >> Suggests: knitr, rmarkdown
> >> VignetteBuilder: knitr, rmarkdown, formatR
> >>
> >> Thank you.
> >>
> >> J Park
> >>
> >> On 11/13/20 8:58 AM, Gábor Csárdi wrote:
> >>> I think you need to Suggest the formatR package, because your
> >>> vignettes use it. From 'Writing R extensions':
> >>>
> >>> "Many packages using knitr also need the package formatR which it
> >>> suggests and so the user package needs to do so too and include this
> >>> in ‘VignetteBuilder’."
> >>>
> >>> Gabor
> >>>
> >>> On Fri, Nov 13, 2020 at 1:49 PM Joseph Park  wrote:
>  Dear r-package-devel,
> 
>  The rEDM package is failing the automated check, as noted here:
> 
>  https://win-builder.r-project.org/incoming_pretest/rEDM_1.7.0_20201113_131811/Windows/00check.log
> 
>  When running rhub::check_for_cran(), disk file errors were reported.
> 
>  The automated check seems to be failing with:
> 
>  Error in loadNamespace(x) : there is no package called 'formatR'
> 
>  This package does not explicitly use formatR:
> 
>  Imports: methods, Rcpp (>= 1.0.1)
>  LinkingTo: Rcpp, RcppThread
>  Suggests: knitr, rmarkdown
>  VignetteBuilder: knitr
> 
>  Could it be these errors (disk full, no formatR) are related?  If not,
>  does formatR need to be listed as a dependency?
> 
>  If the former (R server config/resource build errors), do I need to
>  resubmit the package?
> 
>  Thank you.
> 
>  J Park
> 
> 
>    [[alternative HTML version deleted]]
>

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Joseph Park]

Thank you.

On 11/13/20 10:31 AM, Gábor Csárdi wrote:
> >From WRE:
>
> "Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
> then knitr provides the engine but both knitr and rmarkdown are needed
> for using it, so both these packages need to be in the
> ‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
> suggested by knitr, and hence not available automatically along with
> it). Many packages using knitr also need the package formatR which it
> suggests and so the user package needs to do so too and include this
> in ‘VignetteBuilder’."
>
> So I think you need
>
> Suggests: knitr, rmarkdown, formatR
> VignetteBuilder: knitr, rmarkdown, formatR
>
> On Fri, Nov 13, 2020 at 3:23 PM Joseph Park  wrote:
>> Ah, yes... I see it now in Writing R Extensions.  Apologies for the
>> oversight.
>>
>> Regarding rmarkdown, is it redundant to include rmarkdown in
>> VignetteBuilder if it is in Suggests, or is perhaps needed in the build
>> config as a separate entity?
>>
>> e.g:
>>
>> Suggests: knitr, rmarkdown
>> VignetteBuilder: knitr, formatR
>>
>> or
>>
>> Suggests: knitr, rmarkdown
>> VignetteBuilder: knitr, rmarkdown, formatR
>>
>> Thank you.
>>
>> J Park
>>
>> On 11/13/20 8:58 AM, Gábor Csárdi wrote:
>>> I think you need to Suggest the formatR package, because your
>>> vignettes use it. From 'Writing R extensions':
>>>
>>> "Many packages using knitr also need the package formatR which it
>>> suggests and so the user package needs to do so too and include this
>>> in ‘VignetteBuilder’."
>>>
>>> Gabor
>>>
>>> On Fri, Nov 13, 2020 at 1:49 PM Joseph Park  wrote:
 Dear r-package-devel,

 The rEDM package is failing the automated check, as noted here:

 https://win-builder.r-project.org/incoming_pretest/rEDM_1.7.0_20201113_131811/Windows/00check.log

 When running rhub::check_for_cran(), disk file errors were reported.

 The automated check seems to be failing with:

 Error in loadNamespace(x) : there is no package called 'formatR'

 This package does not explicitly use formatR:

 Imports: methods, Rcpp (>= 1.0.1)
 LinkingTo: Rcpp, RcppThread
 Suggests: knitr, rmarkdown
 VignetteBuilder: knitr

 Could it be these errors (disk full, no formatR) are related?  If not,
 does formatR need to be listed as a dependency?

 If the former (R server config/resource build errors), do I need to
 resubmit the package?

 Thank you.

 J Park


   [[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
-- 
Joseph Park , PhD, PE
U.S. Department of Interior , SFNRC 

Software Literacy Foundation 
UCSD Sugihara Lab 

[[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 loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

>From WRE:

"Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
then knitr provides the engine but both knitr and rmarkdown are needed
for using it, so both these packages need to be in the
‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
suggested by knitr, and hence not available automatically along with
it). Many packages using knitr also need the package formatR which it
suggests and so the user package needs to do so too and include this
in ‘VignetteBuilder’."

So I think you need

Suggests: knitr, rmarkdown, formatR
VignetteBuilder: knitr, rmarkdown, formatR

On Fri, Nov 13, 2020 at 3:23 PM Joseph Park  wrote:
>
> Ah, yes... I see it now in Writing R Extensions.  Apologies for the
> oversight.
>
> Regarding rmarkdown, is it redundant to include rmarkdown in
> VignetteBuilder if it is in Suggests, or is perhaps needed in the build
> config as a separate entity?
>
> e.g:
>
> Suggests: knitr, rmarkdown
> VignetteBuilder: knitr, formatR
>
> or
>
> Suggests: knitr, rmarkdown
> VignetteBuilder: knitr, rmarkdown, formatR
>
> Thank you.
>
> J Park
>
> On 11/13/20 8:58 AM, Gábor Csárdi wrote:
> > I think you need to Suggest the formatR package, because your
> > vignettes use it. From 'Writing R extensions':
> >
> > "Many packages using knitr also need the package formatR which it
> > suggests and so the user package needs to do so too and include this
> > in ‘VignetteBuilder’."
> >
> > Gabor
> >
> > On Fri, Nov 13, 2020 at 1:49 PM Joseph Park  wrote:
> >> Dear r-package-devel,
> >>
> >> The rEDM package is failing the automated check, as noted here:
> >>
> >> https://win-builder.r-project.org/incoming_pretest/rEDM_1.7.0_20201113_131811/Windows/00check.log
> >>
> >> When running rhub::check_for_cran(), disk file errors were reported.
> >>
> >> The automated check seems to be failing with:
> >>
> >> Error in loadNamespace(x) : there is no package called 'formatR'
> >>
> >> This package does not explicitly use formatR:
> >>
> >> Imports: methods, Rcpp (>= 1.0.1)
> >> LinkingTo: Rcpp, RcppThread
> >> Suggests: knitr, rmarkdown
> >> VignetteBuilder: knitr
> >>
> >> Could it be these errors (disk full, no formatR) are related?  If not,
> >> does formatR need to be listed as a dependency?
> >>
> >> If the former (R server config/resource build errors), do I need to
> >> resubmit the package?
> >>
> >> Thank you.
> >>
> >> J Park
> >>
> >>
> >>  [[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