> As such, I cannot manage the MSRV of the package's dependencies.
It seems the reason for geographiclib-rs's MSRV is just that it uses
std::sync::OnceLock. Maybe a possible workaround is to fork the repo and
replace it with the once_cell crate? You should be able to override the
dependency by
I think saying that Fedora is not supported is the wrong solution,
unless you know that Rust version 1.70 will never be supported on
Fedora. Isn't the appropriate solution to document the MSRV in the
SystemRequirements field of your DESCRIPTION file?
When you submit, point out that you have
Hi all!
I have 2 errors related to minimum supported rust version (MSRV) on fedora
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rsgeo-00install.html
that I do not know how to resolve.
The package {rsgeo} has a dependency on the rust crate geo which itself has
a
Thank you Duncan for providing detailed information on parsing in R. I will
check it out and utilize the string inputs for my functions.
Best regards,
Khue Tran
On Sat, Jul 20, 2024 at 4:40 AM Duncan Murdoch
wrote:
> Just for your info:
>
> > exp(mpfr("0.1", 152))
> 1 'mpfr' number of
Thank you Prof. Maechler! Indeed 0.1 is not the same as 1/10 and there are
many ways to get more precise versions of it. I will look into how to take
inputs as strings. Thank you!
Best,
Khue Tran
On Sat, Jul 20, 2024 at 4:40 AM Duncan Murdoch
wrote:
> Just for your info:
>
> > exp(mpfr("0.1",
Dear Leonard,
Thank you so much for the detailed response! Indeed, it would be nice to
have it included in the BH header. Thank you for sharing your codes with
me, I will definitely take a look at them to see if I can apply them to my
case. I was steering away from mpfr type for a while since
On Sat, 20 Jul 2024 06:20:00 +0200
Uwe Ligges wrote:
>
> Strange. Your package has been processed. Have you tried again?
> Are you sure the maintainer address is specified correctly and that
> the auto generated message did not make it onto your spam box?
>
> If it still does not work, please
Dear Khue,
As mentioned before, you can use Rmpfr to read in strings or compute higher
precision values, like
x = mpfr(1, 192) /10;
# 0.1 with 192 bits precision
# or x = mpfr("0.1", 192);
mpfr(1, 192) /10 - mpfr("0.1", 192)
# 1 'mpfr' number of precision 192 bits
# [1] 0
However, I do not
On 20.07.2024 01:52, Rolf Turner wrote:
On Fri, 19 Jul 2024 10:18:27 +0200
Uwe Ligges wrote:
Not that I know, which queue do you mean?
Apologies for my ignorance but I don't understand the question. I did
not choose a "queue". I simply (as I have always done in the past)
pointed my
On Fri, 19 Jul 2024 10:18:27 +0200
Uwe Ligges wrote:
> Not that I know, which queue do you mean?
Apologies for my ignorance but I don't understand the question. I did
not choose a "queue". I simply (as I have always done in the past)
pointed my browser at https://win-builder.r-project.org/
Just for your info:
> exp(mpfr("0.1", 152))
1 'mpfr' number of precision 152 bits
[1] 1.1051709180756476248117078264902466682245471948
So it looks like your approach of parsing the numbers yourself makes sense.
You can find the R parser here:
On 2024-07-19 12:37 p.m., Martin Maechler wrote:
Khue Tran
on Fri, 19 Jul 2024 09:32:14 +1000 writes:
> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right
> Khue Tran
> on Fri, 19 Jul 2024 09:32:14 +1000 writes:
> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right now, it doesn't have all the functions I need
Hi Ivan,
Thanks kindly for your expedient reply and pointer to the LF/CRLF issue. Not
sure that I would have found that issue so quickly, so was hoping for some
intuition here, as you have provided.
Thanks!
Regards,
Marc
-Original Message-
From: Ivan Krylov
Dear Marc Schwartz,
В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz пишет:
> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with
Hi All,
I recently became aware of what appears to be some kind of incompatibility
between the Perl distribution that is included in the RTools 4.4 distribution
and my WriteXLS package on CRAN, running R 4.4.1. As far as I can tell, since
the vast majority of the users of my package, which
Not that I know, which queue do you mean?
Best,
Uwe
On 19.07.2024 00:45, Rolf Turner wrote:
I submitted a package to winbuilder, yesterday. Twice. No response of
any sort. Is the system down, for some reason? Anyone know? Ta.
cheers,
Rolf Turner
On Fri, 19 Jul 2024, Khue Tran wrote:
I will need to run eigen() on a symmetric matrix, but I want to get arbitrary
precise eigenvalues since we will need those eigenvalues for our further
calculations. Does that make sense?
For a symmetric matrix there is a nice algorithm that is simple
I will need to run eigen() on a symmetric matrix, but I want to get
arbitrary precise eigenvalues since we will need those eigenvalues for our
further calculations. Does that make sense?
Best,
Khue Tran
On Fri, Jul 19, 2024 at 12:14 PM Vladimir Dergachev
wrote:
>
> Do you need to run eigen()
Do you need to run eigen() on an arbitrary matrix or symmetric one ?
best
Vladimir Dergachev
On Fri, 19 Jul 2024, Khue Tran wrote:
Thank you Simon! This is very helpful! Regarding eigen, I found in the
Boost library the following example for arbitrary precision matrix solver:
Thank you Simon! This is very helpful! Regarding eigen, I found in the
Boost library the following example for arbitrary precision matrix solver:
https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp.
I am not sure if the precision is fully preserved throughout the
On the other hand, Rmpfr did allow me to write an mpfr rootfinder for Martin M.
in 2011
(he modified and streamlined it for use) since one can run R codes on mpfr
objects
as long as one is careful which operators are applied. So one probably could do
something with a very pedestrian eigenvalue
Khue,
> On 19/07/2024, at 11:32 AM, Khue Tran wrote:
>
> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right now, it doesn't have all the functions I need (ie.
> eigen for mpfr
Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
looked into Rmpfr and while the package can interface GNU MPFR with R
smoothly, as of right now, it doesn't have all the functions I need (ie.
eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
precision
I submitted a package to winbuilder, yesterday. Twice. No response of
any sort. Is the system down, for some reason? Anyone know? Ta.
cheers,
Rolf Turner
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Stats. Dep't. (secretaries) phone:
Hi Khue,
On 19 July 2024 at 06:29, Khue Tran wrote:
| I am currently trying to get precise inputs by taking strings instead of
| numbers then writing a function to decompose the string into a rational
| with the denominator in the form of 10^(-n) where n is the number of
| decimal places. I am
I see there are existing extended precision packages: Ryacas and Rmpfr,
you might want to take a look at them and their representation of numbers
with higher precision than a double.
best
Vladimir Dergachev
On Fri, 19 Jul 2024, Khue Tran wrote:
Hi,
I am trying to create an Rcpp package
Hi Khue,
Have you already checked the Rmpfr package?:
https://cran.r-project.org/package=Rmpfr
Best,
Denes
On 7/18/24 22:29, Khue Tran wrote:
Hi,
I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits
Hi,
I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Hi Chaofan and welcome to R-package-devel!
В Wed, 17 Jul 2024 11:52:53 -0700
Bill Huang <10billhuan...@gmail.com> пишет:
> The package can be installed successfully locally and passed CRAN
> auto-check. However, it cannot pass the gcc-UBSAN test with the
> following error message: a problem with
On the subject of extendr ... the recently published JOSS paper (which also
mentions CRAN compliance under the "Creating Rust-powered R packages section")
provides a good entry point for those interested in using extendr for their
R/Rust packages:
Hi, Team.
I am working on a package that uses RcppEigen. The package can be installed
successfully locally and passed CRAN auto-check. However, it cannot pass
the gcc-UBSAN test with the following error message: a problem with the LLT
function in Eigen. I am not sure how to fix this. Any
To add to this, I would like to point out that extendr actually has a
guide on how to make an R package with Rust code CRAN compliance.
https://github.com/extendr/rextendr/blob/main/vignettes/articles/cran-compliance.Rmd
On Wed, Jul 17, 2024 at 10:21 AM Ivan Krylov via R-package-devel
wrote:
>
В Tue, 16 Jul 2024 21:18:17 -0300
Alberson Miranda пишет:
> besides examples, tests, vignettes and readme, what parts of code
> runs during installation of a R package
Neither. This is about `cargo build` compiling in parallel, not your
package code computing in parallel. Giving the -j 2 flag
Dear listeners,
I'm having a hard time trying to figure out the following NOTE:
|* checking whether package 'fio' can be installed... [202s/46s] NOTE
Installation took CPU time 4.4 times elapsed time |
Uwe asked if there's code running in parallel by default and, yes, there
was: my code uses
Thank you everyone, I think this gives me everything I need to know and I have
no problem spreading the copyright around.
I'm not sure adding my dependencies to MXE is going to make sense here but open
to being convinced otherwise. The package I am working on is wrapping functions
from my own
В Fri, 12 Jul 2024 20:17:22 +
DRC via R-package-devel пишет:
> > Has copyright holders of included software in a [ctb] role only
>
> I think I'm being asked to add the cph role to essentially every
> author in addition to [ctb]
That's how I'm reading it too.
> but that doesn't seem to
On 7/13/24 12:24, Simon Urbanek wrote:
On 12 Jul 2024, at 10:07, Ivan Krylov via R-package-devel
wrote:
В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel пишет:
1. How does linking to external libs differ from providing the source
of a library and linking against that?
I think
> On 12 Jul 2024, at 10:07, Ivan Krylov via R-package-devel
> wrote:
>
> В Thu, 11 Jul 2024 20:58:53 +
> DRC via R-package-devel пишет:
>
>> 1. How does linking to external libs differ from providing the source
>> of a library and linking against that?
>
> I think that the author
Thanks that helps. Are there any thoughts on the feedback I was given? I'm
still a bit confused on the note:
> Has copyright holders of included software in a [ctb] role only
I think I'm being asked to add the cph role to essentially every author in
addition to ctp but that doesn't seem to be
Hi,
Do the r-oldrel-macos-* CRAN check servers use a different setting that affects
how vignette paths work? These two flavors seem less robust to relative
vignette paths than other flavors, and I haven't been able to figure out why by
looking at the descriptions of the flavors or the R CMD
В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel пишет:
> 1. How does linking to external libs differ from providing the source
> of a library and linking against that?
I think that the author information in the DESCRIPTION is about what
your package provides by itself, not everything
I'm trying to submit a package to CRAN that uses external C libs but properly
crediting copyright holders and authors is the main issue holding up the
submission and I've repeatedly failed to satisfy the requirements. I am having
a lot of trouble understanding what/who I need to be listing in
On Thu, 11 Jul 2024, David Hugh-Jones wrote:
This surprised me, even though it shouldn’t have done. (My false internal
model of the world was that oo <- options(); … options(oo) would overwrite
the entire options list with the old values.) I wonder if it would be worth
pointing out
Dear Ivan,
Thank you so much for your help.
I followed your advices and I reduced the size of the example data, move one
package from Import to Suggest.
The type of the license is unfortunately not depending on me so I’ll try one
last time with the CC license and the new improvements.
Thank
Not from CRAN, also not in a position to opine on cpp11 status, but I
wrote about it recently. My solution for readODS back then was to
vendor cpp11 and remove the SET_LENGTH call manually, like . But back
then CRAN might not know about this. I think it should be easier now.
This surprised me, even though it shouldn’t have done. (My false internal
model of the world was that oo <- options(); … options(oo) would overwrite
the entire options list with the old values.) I wonder if it would be worth
pointing out explicitly in ?options.
Writing: wyclif.substack.com
Book:
Dear John,
You need to collect the return value when setting options. This will include an
explicit NULL value for an option that was previously NULL.
Best,
Greg Jefferis.
options(digits.secs = NULL)
noset2 = function() {
opts <- options(digits.secs = 3)
on.exit(options(opts))
On Wed, 10 Jul 2024, Duncan Murdoch wrote:
An update to the rgl package was rejected with this note:
* checking compiled code ... NOTE
File ‘rgl/libs/rgl.so’:
Found non-API call to R: ‘R_InputHandlers’
Compiled code should not call non-API entry points in R.
See ‘Writing portable
When setting options in a function, I have always used the following:
opts <- options()
on.exit(options(opts), add = TRUE)
and assumed it "reset" options to what they were prior to running the
function. But for some options that are set to NULL, it does not seem to
reset them. Specifically,
An update to the rgl package was rejected with this note:
* checking compiled code ... NOTE
File ‘rgl/libs/rgl.so’:
Found non-API call to R: ‘R_InputHandlers’
Compiled code should not call non-API entry points in R.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual,
and
(I am adding the mailing list back in Cc: because package licensing is
a complicated topic.)
В Tue, 9 Jul 2024 09:25:14 +
Matei Teleman пишет:
> I’ve added “ … SuperCell uses
> [velocyto.R](https://github.com/velocyto-team/velocyto.R) for RNA
> velocity. ” in the Description field. Is that
Thank you to, in alphabetical order of given names, Iris, Ivan, Uwe and
Wolfgang for your responses. I implemented Iris' suggestion and have
successfully uploaded one of the packages to CRAN.
Michael
On 09/07/2024 10:06, Ivan Krylov wrote:
В Tue, 9 Jul 2024 08:54:22 +
"Viechtbauer,
В Tue, 9 Jul 2024 08:54:22 +
"Viechtbauer, Wolfgang (NP)"
пишет:
> This appears to be related to this change
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
>
> - tools::checkRd() (used by R CMD check) detects more problems with
> \Sexpr-based dynamic content, including bad
Hi Mark,
The cpp11 package is now maintained by Davis Vaughan and we will release a
new version once the C API status is a little cleaner. This warnings
generated from cpp11 will not interfere with your ability to submit your
package; just let CRAN know that the warnings are coming from cpp11.
Hi Michael,
I assume you are getting this note because you are using mathjaxr. I am also
getting this and others have reported the same:
https://github.com/wviechtb/mathjaxr/issues/15
(my response on the forum was a bit premature, since this note eventually did
show up for me as well).
This
В Mon, 8 Jul 2024 15:12:24 +
Matei Teleman пишет:
> Non-FOSS package license (file LICENSE)
> The license we’re using is the standard CC BY-NC-ND 4.0 and is listed
> among the accepted licenses for CRAN
Instead of putting the license text in a file inside the package (that
would have to
The first NOTE is irrelevant. The second NOTE says that you must
reduce the running time of your examples (so that the longest of them
takes <10 seconds on the *slowest* CRAN testing platform). This thread
might be useful:
https://stat.ethz.ch/pipermail/r-package-devel/2021q4/007521.html
Hello everyone,
I hope this email finds you well.
I’m sorry to bother you, it’s the very first time I’m submitting a package to
CRAN.
Recently my submission got rejected with the following feedback:
Non-FOSS package license (file LICENSE)
Suggests or Enhances not in mainstream
Hello everyone
I need your attention. I have developed a new R package and submitted it to
CRAN. In return main i got two notes they are:
* using log directory 'd:/RCompile/CRANincoming/R-devel/drglm.Rcheck'
* using R Under development (unstable) (2024-07-05 r86875 ucrt)
* using platform:
I'm pretty sure this is from this R-devel commit:
https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
This turns on stricter boundary checking, specifically see
https://github.com/lme4/lme4/issues/794#issuecomment-2154948145
Arguably, accessing an element of
Seemingly starting with the most recent builds of R-devel, I�ve been getting
segfaults related to a piece of cpp code that indexes a zero-size
NumericVector. Essentially the same as this dummy example:
```
library(Rcpp)
sourceCpp(
code = '
#include
using namespace Rcpp;
//
On 08.07.2024 16:08, Iris Simmons wrote:
This is something I'd run into recently as well.
The R devs changed the default from building the manual to not building the
manual. Now if you want (or need) to build the manual, you should add
Well, not really, we still build manuals unless
Hi Mark,
As someone else affected by this issue, it is actually quite tough to
resolve. This is because quite literally every other day, the list of what
is and is not non-API is changing. It is particularly challenging since
this is in R-devel and not any stable R release.
If there were a
Have you contacted the maintainer directly (i.e. by e-mail)? (Yes,
they should be paying attention to Github, but trying another channel
never hurts.)
My personal experience is that I was succeeded in submitting a
package update to CRAN even though there were NOTEs of this sort (in
that
Dear R-pkg-dev folk,
The cpp11 package, which was developed yet is no longer maintained by
Jim Hester, now triggers warnings on some CRAN pre-submit checks for
"non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
relevant issue is https://github.com/r-lib/cpp11/issues/355,
This is something I'd run into recently as well.
The R devs changed the default from building the manual to not building the
manual. Now if you want (or need) to build the manual, you should add
BuildManual: TRUE
to your DESCRIPTION.
On Mon, Jul 8, 2024, 10:05 Michael Dewey wrote:
> Short
Short version
I have recently tried to update two of my CRAN packages and I am getting
the NOTE from R CMD check --as-cran
Package has help file(s) containing install/render-stage \Sexpr{}
expressions but no prebuilt PDF manual.
(It comes on one line in the check.log)
What am I doing
On Tue, 2 Jul 2024, Martin Maechler wrote:
Achim Zeileis
on Tue, 2 Jul 2024 01:05:07 +0200 (CEST) writes:
> Kevin, R-Forge is still alive but there are problems with
> the build queue as you noticed. The problems occurred
> after R-Forge upgraded to R 4.4.0 - just as there was a
> Achim Zeileis
> on Tue, 2 Jul 2024 01:05:07 +0200 (CEST) writes:
> Kevin, R-Forge is still alive but there are problems with
> the build queue as you noticed. The problems occurred
> after R-Forge upgraded to R 4.4.0 - just as there was a
> switch in the maintenance
I cannot/will not to help you do this, but there are people out there who
disagree with me who put considerable effort into doing this... the search term
you would need in order to find them is "monorepo". But please reconsider...
the whole point of putting code into separate packages is to
Kevin,
R-Forge is still alive but there are problems with the build queue as you
noticed. The problems occurred after R-Forge upgraded to R 4.4.0 - just as
there was a switch in the maintenance team at WU Wien.
The problem is with the Windows build/check tools which work fine when run
While you can put multiple packages in one Git repository, I'd suggest
that you don't do that. Most packages are in their own repository, and
that means that users who want to contribute to your packages are
familiar with that setup. If they have to fork 20 packages at once to
make a
I don't know about R-forge, but it's perfectly workable to put
multiple packages within a single repo, with each package in its own
subdirectory. You'll run into some headaches occasionally with (e.g.)
CI machinery that assumes that the head of a git repo is also the
primary package
Kevin,
I can't speak to whether R-Forge is dead, we migrated our projects to
github a long time ago.
The most straightforward answer for R packages in git repositories is
to use separate git projects. we were even able to import the entire
SVN history and r-forge issue history to github for
Hi,
I have been maintaining packages in R-Forge for many tears. Last week I
sent an email to r-fo...@r-project.org to report problems with the build
process. It appears that any changes I have pushed to R-Forge over
approximately the last two months have resulted in the package remaining
in
Hi folks,
A new release of extendr v0.7.0 is now available.
This release addresses the R-devel WARNings from non-API functions being
used.
This release also comes with breaking changes. We've written a brief
migration guide
which can be found at:
Hello, Pedro et al.:
Your package is on GitHub with GitHub Actions.[1] If whoever manages
GitHub actions feels inclined to add macos-latest (oldrel-1), this would
be one argument for doing that, though this kind of problem may be too
rare to justify the expense. That's particularly true
On 2024-06-30 5:17 a.m., Aphalo, Pedro J wrote:
Hello,
A few days ago I submitted to CRAN an updated version of package 'ggpp', it
passed checks during submission and version 0.5.8 is now on CRAN. However I see
errors for old-rel only for MacOS at
Hello,
A few days ago I submitted to CRAN an updated version of package 'ggpp', it
passed checks during submission and version 0.5.8 is now on CRAN. However I see
errors for old-rel only for MacOS at
https://cran.r-project.org/web/checks/check_results_ggpp.html and I am stuck as
I do not have
That was it. Thanks very much.
Now I can go back to working on the "[.findFn" problem that you
helped me identify. (I translated the Sweave vignette to RMarkdown to
isolate that. Progress, with your help.)
Spencer
On 6/29/24 04:47, Ivan Krylov wrote:
В Fri, 28 Jun
В Fri, 28 Jun 2024 17:57:13 -0400
Iris Simmons пишет:
> * checking whether the namespace can be unloaded cleanly ... WARNING
> unloading
Here's what the check does (in a separate process):
invisible(suppressMessages(loadNamespace("this.path")));
cat('\n unloading\n');
В Fri, 28 Jun 2024 22:55:23 -0500
Spencer Graves пишет:
> I'm getting, "Error: processing vignette 'sos.Rmd' failed
> with diagnostics: there is no package called 'markdown'":
>
>
> https://github.com/sbgraves237/sos/actions/runs/9721300082/job/26833793243
>
>
> This is in:
>
Hello, All:
I'm getting, "Error: processing vignette 'sos.Rmd' failed with
diagnostics: there is no package called 'markdown'":
https://github.com/sbgraves237/sos/actions/runs/9721300082/job/26833793243
This is in:
Have you reviewed WRE 5.3? I don't have personal experience with R 4.4 much
less the dev version, but it seems that often they add checks in new versions
of R for rules that have been published but ignored.
On June 28, 2024 4:00:06 PM PDT, Iris Simmons wrote:
>Thank you Jeff! I'm not worried
>From https://r-pkgs.org/r-cmd-check.html:
Checking whether the namespace can be unloaded cleanly. Runs
loadNamespace("pkg"); unloadNamespace("pkg"). Check .onUnload() for problems.
HTH,
-Roy
> On Jun 28, 2024, at 4:00 PM, Iris Simmons wrote:
>
> Thank you Jeff! I'm not worried about the
Thank you Jeff! I'm not worried about the NOTE about the URLs, I've
submitted many previous versions of this package that all had that note and
they've all been accepted.
I'm worried about the WARNING when the namespace is unloaded. The message
is just " unloading" with no further
Google for "http 403 error"... likely win-builder has multiple packages with
links to Posit, and the Posit web server is throttling automated hits.
Theoretically this is just a warning and you can try submitting to CRAN, but
CRAN may have even less luck accessing Posit than win-builder.
Hi,
I've got an update for my R package ready to go. It checks successfully on
my own machine for r-oldrel and r-release, but when I submit it to R Win
Builder for r-devel to be checked, it gives me a warning not seen before
with an uninformative message:
* checking whether the namespace can be
Dear All,
If you would like to share your thoughts on the CRAN submission process, please
fill this short survey from the CRAN Cookbook project
Survey: https://forms.gle/umdew9KHWeQSehq8A
Project announcement:
Thank you, but I still think the Writing R Extensions manual needs to be
updated. The manual lists a large number of remapped function names.
These names cannot be used in any package in the current R version
(4.4.1) because R_NO_REMAP is defined in the Debian build script
(intentionally or
On 6/24/24 09:45, Agner Fog wrote:
On 24/06/2024 08.56, Tomas Kalibera wrote:
In principle it is the NEWS file that gives hints about important
changes and then one can find the details in Writing R Extensions.
The NEWS file as of mid-April says that "R CMD check --as-cran" will
compile
On 24/06/2024 08.56, Tomas Kalibera wrote:
In principle it is the NEWS file that gives hints about important
changes and then one can find the details in Writing R Extensions.
The NEWS file as of mid-April says that "R CMD check --as-cran" will
compile C++ code with -DR_NO_REMAP. And then
On 6/24/24 08:25, Agner Fog wrote:
Jarrod Hadfield wrote:
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).
I had the same
Jarrod Hadfield wrote:
> 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).
I had the same problem. A lot of functions in my
It is probably checking the version anyway. If a binary package is
available for a later version, then it may say something like:
"The latest version of the binary package does not match your currently
installed version of R. You may update R, or you may compile the package
for the installed
On 2024-06-23 8:01 a.m., Agner Fog wrote:
Also, I think the system should recommend to the user to update RStudio
when a package is not available for the installed version. The current
message does not tell the cause of the problem. It just says:
Do you want to install from sources the package
Also, I think the system should recommend to the user to update RStudio
when a package is not available for the installed version. The current
message does not tell the cause of the problem. It just says:
Do you want to install from sources the package which needs compilation?
- Agner
Duncan Murdoch wrote on 2024-06-23 13:04:
[…] One exception is the one run by Posit: because it is cloud based,
I think they spend quite a lot of money on it. […] it means that it is
very reliable, and it's the one I use almost all the time.
I agree. It is also helpful for developers of
On 2024-06-23 5:44 a.m., Agner Fog wrote:
On 23/06/2024 09.56, Duncan Murdoch wrote:
CRAN only builds Windows binaries for the devel version, the current
release, and the previous release, so nothing older than 4.3.0 will
get it.
Thank you. Updating R helped.
BTW, I don't think we need so
1 - 100 of 8875 matches
Mail list logo
