The advantage of "abort" (R_Suicide) over the default (R error) is that
it cannot be caught accidentally, so that one can detect more errors,
and it may be easier to find where the error happened. To make the
default behavior less surprising/more user friendly, and to allow
intentional
If you have not already done so, I'd check the package directory (and
its parent) is not opened in any application, including Windows
Explorer, including current working directory in any command prompt. I'd
also make sure the package is not loaded in any R session. The error
message may be
On 7/15/19 2:06 AM, Travers Ching wrote:
I think the major change was saving of alt-rep objects efficiently.
Example save(1:1e8, file=...) is very efficient.
I'm not sure if that is all that changed it, but I couldn't find
documentation on the differences.
Yes, format version 3 provides
On 9/3/19 3:07 PM, Benjamin Christoffersen wrote:
> Dear Sirs,
>
> I have tried to update my 'dynamichazard' package on CRAN but I have
> had some issues with the '-Wlto-type-mismatch' checks. In particular,
> I have tried to follow "Writing R Extensions" section "Fortran
> character strings" and
The error seems to be because you are trying to write to the user's home
directory. This is not allowed. Probably by accident your test creates
"~/testcsv4.csv" (the same problem is present for other test files).
Best
Tomas
On 9/13/19 1:21 PM, Vincent van Hees wrote:
Dear all,
I have a test
Please refer to BLAS_LIBS, LAPACK_LIBS in Writing R Extensions. For an
example package that uses BLAS/LAPACK, see e.g. "stats" or "Matrix". The
package will then use the BLAS/LAPACK implementation as chosen by the
user/system administrator at dynamic linking time (see R Installation
and
Dear Göran,
I can reproduce the problem with eha version 2.6.0. The reason for the
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv
from Fortran code, but the calls to dgemv from the C code from the other
source files in your package. There is no need to go through
On 9/20/19 2:43 AM, Aravind J. wrote:
Hi,
I was able to fix the issue and submit my package successfully to CRAN.
However, the question remains, is there any way to replicate the CRAN
pre-tests locally for future debugging, particularly in a windows
environment?
I had tried rhub platforms
On 9/19/19 6:29 AM, Spencer Graves wrote:
Update: A web search for 'installing pdflatex for "R CMD" on Windows
10?' suggested I install MiKTeX. I did that from miktex.org, and it
got me past that error. Spencer
Please note these things are documented in R Installation and
Administration
On 9/24/19 1:57 AM, Toby Hocking wrote:
Hi all,
is there a known fix for this WARNING which I am getting on solaris for my
newly submitted nc package?
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
It seems that deparse() came across some non-printable
On 6/28/19 5:16 PM, Florian Oswald wrote:
oh ok i see: so i will always be able to do
clean(path = "~/data.csv")
for example? in that case I completely misunderstood this and there must
indeed be some system.file call buried somewhere. will check. thanks!
In case it is hard to find manually,
On 11/4/19 8:40 PM, Roy Mendelssohn - NOAA Federal via R-package-devel
wrote:
Hi All:
I am wondering if it is possible to find out when packages that use the netcdf
libraries are built on the CRAN machines (such as ncdf4) what versions of the
netcdf library are being used on at least Mac and
On 10/31/19 12:58 AM, Toby Hocking wrote:
Hi all, I am getting an "invalid multibyte string" error from one of my
examples when it is run on solaris, which results in check FAILURE:
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
To fix this I guess I could just
On 11/13/19 10:19 AM, Tomáš Kliegr wrote:
Hello,
This question has not stirred much discussion ... If this is the wrong place to
ask, I was wondering if some one point me to where I should ask, or who to
approach? If I understand this issue correctly, it does not affect only my
package,
On 11/21/19 7:25 PM, Devin Incerti wrote:
Hi,
I'm attempting to submit a very minor update to my package where I replaced
a deprecated C++ function with an alternative. However, I'm receiving an
unrelated warning "*array subscript -1 is outside array bounds of ‘double
[52]’ [-Warray-bounds] *"
On 11/3/19 1:05 PM, Viktor Gal wrote:
ah yeah i forgot to mention. it’s the same, i.e. it’s not the byte code
compilation that causes this behaviour but the preparation for lazy loading.
R is not optimized for these cases (generated code, source file with
>100,000 lines of code), but R has
On 9/25/19 1:00 PM, Ralf Stubner wrote:
On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
wrote:
I am installing OpenBLAS because I need LAPACKE libraries which I cannot find
on the current version of OpenBLAS on CRAN.
I add the libraries directory in my package to the PKG_CONFIG_PATH. Is
es. I see \u4e8c \u4e09 \U0001F60E.
Tomas
>
> On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 9/24/19 1:57 AM, Toby Hocking wrote:
> > Hi all,
> >
> > is there a known fix for this WARNING which I
On 9/17/19 6:17 PM, Cristiane Hayumi Taniguti wrote:
Hello, thanks for all the answers.
I did the new tests with all suggestions.
I included the Rprintf in my script, however it did not show any NaN when
running with my examples (the same that CRAN check pointed the error)
The approach of
On 3/5/20 4:26 AM, John Lawson wrote:
> I see this error on the CRAN Check report
>
>> ### ** Examples
>>
>> #Definitive Screening Design
>> library(daewr)
>> set.seed(1234)
>> x <- DefScreen(m=5,c=0)
>> colnames(x) <- paste("x",1:5,sep="")
>> x$y <- 3*x$x1 + 2*x$x2 + 2*x$x4*x$x5 + x$x3^2 +
On 3/5/20 9:45 AM, Rolf Turner wrote:
On 5/03/20 9:04 pm, Tomas Kalibera wrote:
On 3/5/20 4:26 AM, John Lawson wrote:
I see this error on the CRAN Check report
Fatal error: the condition has length > 1
The problem is that the condition t1 == "I" & t2 == "
Hi Erin,
this comes from examples in ?str. Could you please try to find a minimal
example to reproduce on your system based on that? I would look for
"line needs" in ?str and experiment with reducing the example there
while still getting the error. Once it is minimal, could you please try
On 3/19/20 6:03 PM, Max Turgeon wrote:
> Is there perhaps a typo in the environment variable name? This line suggests
> there should be an underscore at the beginning too:
>
> https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L6028
Also the correct name is in R Internals,
glish_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605
> c.ch <http://c.ch> w.ch <http://w.ch> c.fw w.fw
> > 64 64 32 64
> >> stopifnot(unname(ncc) == c(64,64, 32, 64))
> >> ## nchar.max: 1st line needs an increase of 2 in order to
> see 1 (in
> > UTF-$
>
onv.def win_iconv.o
>
> Just the -march=native -pipe
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com <mailto:erinm.hodg...@gmail.com>
>
>
> On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> Th
The problem is with
if (class(data) != "matrix") stop("The data field should be an array or
a data frame")
Please use inherits() instead of checking class(), see this for more details
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again
Best
Tomas
On
On 2/9/20 5:14 PM, Benjamin Tyner wrote:
Hello,
Using package nlme as an example, where there is a registered routine
fit_gnls:
> library(nlme)
> getDLLRegisteredRoutines("nlme")$.C$fit_gnls
$name
[1] "fit_gnls"
$address
attr(,"class")
[1] "RegisteredNativeSymbol"
$dll
DLL name: nlme
On 7/16/20 7:57 PM, Steve Bronder wrote:
On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz wrote:
If you don't mind multi-gig docker containers, this can be helpful:
https://github.com/scottyhardy/docker-wine
It doesn't work with 64 bit versions of R as far as I could tell, but 32
bit did install
On 9/7/20 7:07 PM, b...@denney.ws wrote:
Hello,
My question is:
Can I use the 64-bit gcc to build a 32-bit package with the -m32 command
line option with Rtools? And, can that work for CRAN? Or more generally,
is there a work-around for needing lots of RAM during compilation with the
This is was a bug in R-devel, already fixed.
Sorry for the inconvenience,
Tomas
On 10/17/20 12:06 AM, John Mount wrote:
I am trying to move the wrapr package from RUnit to tinytest. All seemed well
on my tests, but when I submitted to CRAN I got:
Flavor: r-devel-linux-x86_64-debian-gcc
This was a bug in R-devel, already fixed.
(specific to Unix, and only 3 R-devel revisions)
Sorry for the inconvenience,
Tomas
On 10/20/20 4:48 PM, Cristoforo Simonetto wrote:
Dear all,
last week I tried to upload for the first time a package to CRAN but
my submission was refused:
Flavor:
On 9/18/20 11:56 PM, Steve Bronder wrote:
> inline
>
>
> On Wed, Sep 9, 2020 at 3:35 AM Tomas Kalibera
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 7/16/20 7:57 PM, Steve Bronder wrote:
> > On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz
On 6/30/20 11:48 AM, Göran Broström wrote:
On 2020-06-30 01:07, Jeff Newmiller wrote:
Your choice. Do you want to support people using older versions of R,
or not?
Is that all? No point at all with version 3 in packages? Why was it
introduced? I have seen an argument for version 2: "...
My recommendation would be to try to minimize the example (package) as
much as possible so that it still has the problem, and then try to
investigate why exactly/where is the type mismatch. This is what helped
me debug similar issues - sometimes it was hard to tell from the Fortran
warnings
On 6/15/20 6:52 PM, Duncan Murdoch wrote:
On 15/06/2020 12:30 p.m., Daniel Kelley wrote:
Duncan, thanks very much for that very helpful hint. I got as
follows. My guess is that the first column in rdx$variables is an
address offset, and so it seems that the lion's share of the storage
is
On 12/16/20 11:07 PM, jo...@jorisgoosen.nl wrote:
David,
Thanks for the response!
So the problem is a bit worse then just setting `encoding="UTF-8"` on
functions like readLines.
I'll describe our setup a bit:
So we run R embedded in a separate executable and through a whole bunch of
C(++)
On 12/17/20 5:17 PM, jo...@jorisgoosen.nl wrote:
>
>
> On Thu, 17 Dec 2020 at 10:46, Tomas Kalibera <mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 12/16/20 11:07 PM, jo...@jorisgoosen.nl
> <mailto:jo...@jorisgoosen.nl> wrote:
> > David,
ns (but does not include the complex type).
Best,
Tomas
>
> Have a nice day.
>
> Kind regards,
> Pierre
> --------
> *From:* Ivan Krylov
> *Sent:* Friday, 18 December 2020 18:16
> *To:* Pierre Lafaye de Micheaux
On 12/17/20 6:43 PM, jo...@jorisgoosen.nl wrote:
>
>
> On Thu, 17 Dec 2020 at 18:22, Tomas Kalibera <mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 12/17/20 5:17 PM, jo...@jorisgoosen.nl
> <mailto:jo...@jorisgoosen.nl> wrote:
>>
>>
>&g
native code locally on Windows, the toolchain includes a
native compiler and I build R packages natively as well.
Cross-compilation is used to build the compiler toolchain and external
libraries for packages.
Cheers
Tomas
>
> Cheers,
> Joris
>
>
> On Fri, 18 Dec 2020 at 18:05, Tom
here I wrote that displays the bytes straight from R's
> CHAR to be sure no conversion is happening.
> I would expect that the mathotString had "C3 B4" for "ô" but instead
> it gets "F4". As you can see when you run
> `utf8StringsPkg::testutf8_in_locale()`.
FC_LEN_T and Rcomplex, without any runtime overhead, but that
would be hiding potential problems as well.
Best
Tomas
>
> Thank you again all for sharing your precious time.
>
> Kind regards,
> Pierre L.
>
&
ch original declaration ).
>
> My version of fortran: GNU Fortran (Debian 8.3.0-6) 8.3.0 under Debian 10.
>
> Thank you very much for any further help you could provide so that I
> could have my package back to the CRAN.
>
> Kind regards,
> Pierre L.
>
>
> -
On 6/2/21 3:01 AM, Hugh Parsonage wrote:
Hello,
I received a valgrind warning about my package, hutilscpp, from CRAN
(thank you). I believe I've tracked down and fixed the problem, but I
wasn't able to reproduce the error on rhub (including with
--leak-check=full etc) so I'd like to know if
On 6/24/21 11:31 PM, Duncan Murdoch wrote:
On 24/06/2021 4:52 p.m., Dirk Eddelbuettel wrote:
On 24 June 2021 at 16:31, Duncan Murdoch wrote:
| This does the full compile again, so it's slow.
ccache fixes that (as it has its own cache). It also works on macOS.
I haven't tried ccache:
On 5/13/21 7:06 AM, SN248 wrote:
I am working on a package which provides an interface to the libsbml C++
library (http://sbml.org/Software/libSBML) in R. The source code of this
package (r2sbml) can be found at the following link
https://github.com/sn248/r2sbml
The package passes CRAN
On 5/13/21 7:29 AM, Sokol Serguei wrote:
Le 13/05/2021 à 07:06, SN248 a écrit :
I am working on a package which provides an interface to the libsbml C++
library (http://sbml.org/Software/libSBML) in R. The source code of this
package (r2sbml) can be found at the following link
e libraries, and someone has to do this work.
Installing libraries manually on the check machines is not going to
scale and may be too much burden for many end users, apart from
difficulties with repeatability, maintenance, etc.
Best
Tomas
>
> Thanks again for your help.
> Satya
>
&g
On 4/25/21 2:49 PM, Duncan Murdoch wrote:
The current CRAN release of rgl fails on winUCRT because of missing
dependencies:
'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr',
'crosstalk', 'manipulateWidget'.
Tracing `htmlwidgets` shows it also fails because of missing
On 4/2/21 1:05 PM, Daniel Kelley wrote:
The "oce" package for oceanographic analysis is failing a check on the
r-devel-windows-x86_64-gcc10-UCRT system (see
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64-gcc10-UCRT/oce-00check.html).
The problem seems to relate to the checking
On 2/11/21 8:28 AM, Evan Biederstedt wrote:
Hi there
Creating an R package here which I plan to upload to CRAN. Upon checking
the tarball created with `R CMD BUILD`, I try to use `R CMD CHECK` as
follows:
```
R CMD CHECK my_package.tar.gz --as-cran
```
This normally works smoothly. However,
On 8/16/21 12:42 PM, Ivan Krylov wrote:
On Mon, 16 Aug 2021 09:05:54 +
David Norris wrote:
Unicode U+00d7 (times), U+00b1 (plus-minus) and U+03bc (mu) have
equivalents in Latin-1 encoding, and I have used these without
difficulty in strings, neither U+2206 (INCREMENT) nor U+0394 (Greek
Dear Cristhian,
memory.limit() is called by package "ff" when it is loaded. Your new
package uses "ff" via "propagate". Perhaps the easiest option for you is
to re-try the submission once "ff" is adapted to this change in R-devel.
Best
Tomas
On 9/3/21 7:10 PM, Cristhian Paredes Cardona
In the current R releases, R symbol names are in the native encoding,
which on Windows in R (the normal MSVCRT builds up to R 4.1) cannot be
UTF-8 nor any other Unicode encoding. So you can't portably use such
characters e.g. in names of vector elements or of bindings in an
environment, so not
Dear Stephan,
On 9/21/21 8:10 PM, Struckmann, Stephan wrote:
Dear Thomas,
thank you for your quick reply. I'll consider then writing to the CRAN address
earler, if I have strong hints that the build/check system may cause a
warning/error.
So, I'll wait for the next check-run then. If I can
Dear Stephan,
On 9/21/21 3:31 PM, Stephan Struckmann wrote:
> Dear all,
>
> lately, an error and two warnings occurred for our package dataquieR on the
> platform r-devel-windows-x86_64-gcc10-UCRT
> (https://cran.r-project.org/web/checks/check_results_dataquieR.html).
>
> Unfortunately, error
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
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
!
-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
On 11/27/21 5:24 PM, Ben Engbers wrote:
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be
processed one byte at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
The message may contain embedded 0x00's. To distinguish these
On 11/27/21 8:05 PM, Tomas Kalibera wrote:
On 11/27/21 5:24 PM, Ben Engbers wrote:
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be
processed one byte at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
The message may
On 11/28/21 5:10 PM, Ben Engbers wrote:
Searching Google seems easy. But finding reaully usefull information
is often very difficult.
I alreay found hint #1. Thankfs for #2 and #3
Perhaps people who teach these things could give best recommendations
(and those may not be reading this
(My apologies for cross-posting to those reading also the R-devel
mailing list)
Please note an update concerning the support of UTF-8 as native encoding
on Windows, which may at this point be of interest particularly to
developers of packages with native code and to R users using R-devel
On 12/8/21 12:20 PM, Ben Engbers wrote:
Op 07-12-2021 om 23:49 schreef Ben Engbers:
After a long nightly session, I ended up with inserting a wait between
sending the authentication nonce and reading the status byte.
writeBin(auth, private$conn)
Sys.sleep(.1)
Accepted <- readBin(conn, what
On 12/16/21 4:17 PM, Hiroaki Yutani wrote:
This would be an empty character vector on my Alpine Linux server as
well.
I see, thanks for the information. Sorry for my lack of consideration on this.
So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of
ckages can be provided).
If this is not possible and you need a new version of SWI Prolog on all
systems, newer than normally available, perhaps best to write to CRAN
and ask there about this specific case.
Best
Tomas
> Best wishes,
>
> Matthias
>
> *Von: *Tomas Kalibera &l
R handles BOMs in the "connections" code, ?connections, and it
uses iconv for input conversion.
Thanks
Tomas
On April 5, 2022 11:20:37 AM PDT, Tomas Kalibera
wrote:
On 3/28/22 13:16, Ivan Krylov wrote:
On Mon, 28 Mar 2022 09:54:57 +0200
Tomas Kalibera wrote:
Could you please cl
On 11/1/23 12:15, Alberto Garre wrote:
Dear community,
I feel dismay for having to write this email, but the issue must be brought
up. On the 20th of October, I received an email from CRAN warning me of an
issue with one of the packages I maintain (bioOED). The package depended on
MEIGOR, a
On 7/5/22 16:11, Ivan Krylov wrote:
On Tue, 5 Jul 2022 09:35:05 -0400
Duncan Murdoch wrote:
I see the -O0 option that I added, but afterwards -O2 coming from
somewhere in R.
It seems to come from the CXXFLAGS macro defined in /etc/R/Makeconf.
It's the last to be added to ALL_CXXFLAGS, so
elp!
No problem, just please only regard it as my advice.
Best
Tomas
>
> Best,
> Yutani
>
> 2022年7月27日(水) 15:08 Tomas Kalibera :
>
>
> On 7/27/22 00:30, Hiroaki Yutani wrote:
> > Hi,
> >
> > Recently I got the following email from the
On 7/27/22 08:08, Tomas Kalibera wrote:
On 7/27/22 00:30, Hiroaki Yutani wrote:
Hi,
Recently I got the following email from the CRAN maintainer about my
package, string2path[1].
However, I do ensure the binary is the pinned version and verify if the
hash matches with the embedded one
On 7/15/22 14:50, Georgi Boshnakov wrote:
Submitted package 'fGarch' has been stuck in CRAN 'pretest' for about 24 hours
now. The same seems to hold for several other packages. Is this something that
can be expected normally?
The pretest service seems to work normally in that other packages
On 9/16/22 20:17, Edward Wei wrote:
That is an interesting thought. I don't think I have downloaded LaTex
explicitly, however, I do have MikTex and I added that file to PATH
manually.
This is what my current PATH calls:
On 9/28/22 00:50, Bailey, Paul wrote:
Hi,
I'm trying to update WeMix on CRAN and when I use R-devel (2022-09-26 r82921
ucrt) to R CMD check --as-cran R-devel will not install the package. This is
the log file
[snip]
** testing if installed package can be loaded from temporary location
***
On 1/19/23 05:00, mai zhou wrote:
Hi,
In the process of adding examples to the .RD file, I noticed
Rcmd check seems to skip certain example code.
I put my example code x%*%y%*%z (matrix multiplication) in the
RD file. After running Rcmd check
(on windows) and look into the xxx.Rcheck
On 1/22/23 22:36, Uri Simonsohn wrote:
This is not a perfect list for this question, but possibly a good list.
I think this is a good match.
I maintain 'groundhog', a package that seeks to simplify reproducibility
of R code based on R packages.
It has so far relied on MRAN for binaries of
On 1/23/23 17:51, Ying Li via R-package-devel wrote:
Dear all,
Hope you are well! Recently, in the check before a re-submission, I got an unexpected note
when doing R CMD Check using rhub::check_for_cran(), saying that "Examples with CPU
(user + system) or elapsed time > 5s".
I didn't expect
On 1/23/23 17:30, Maxim Nazarov wrote:
Hello all,
I am submitting a minor update to one of my CRAN package (BIGL), and get
strange errors on R-devel on win-builder -
https://win-builder.r-project.org/incoming_pretest/BIGL_1.6.7_20230119_225109/Windows/00check.log
and
On 3/22/23 16:51, Kenny, Christopher wrote:
Hi folks,
I'm the maintainer of the redist package
(https://cran.r-project.org/web/checks/check_results_redist.html) which was flagged for
additional issues with clang-UBSAN and gcc-UBSAN. Both of the 00check.log files say that
the status is "OK"
On 3/1/23 07:35, Matthias Gondan wrote:
For the record, here's the documentation of the Prolog sandbox,
https://www.swi-prolog.org/pldoc/doc/_SWI_/library/sandbox.pl
You get an idea of the implementation by clicking at the ":-" icons. It does
not seem too complicated, but I might be too
On 2/12/23 17:37, David Sterratt wrote:
On Sat, 2023-02-11 at 18:11 +0300, Ivan Krylov wrote:
On Sat, 11 Feb 2023 11:19:42 +
David Sterratt wrote:
WinDbg output reveals errors loading "NETIO.SYS" and "WINSPOOL.DRV"
when running "library(RGtk2)":
0c64:0640 @ 44312812 -
On 2/14/23 13:26, David Sterratt wrote:
On Mon, 2023-02-13 at 19:08 +0100, Tomas Kalibera wrote:
For reference, there is an old patch for RGtk2 package that I had
created when working on Rtools42, though I am not very optimistic it
will help in this case:
https://svn.r-project.org/R-dev-web
On 7/13/23 05:08, Hiroaki Yutani wrote:
I actually use cargo vendor.
https://github.com/yutannihilation/string2path/blob/main/src/rust/vendor.sh
One thing to note is that, prior to R 4.3.0, the vendored directories hit
the Windows' path limit so I had to put them into a TAR file. I haven't
On 12/18/23 15:09, Ivan Krylov wrote:
В Mon, 18 Dec 2023 11:06:16 +0100
Jisca Huisman пишет:
I isolated the problem in a minimal working example available here:
https://github.com/JiscaH/flang_segfault_min_example . All that does
is pass a vector of length N*N back and forth between R and
Jisca
On 18-12-2023 16:06, Tomas Kalibera wrote:
On 12/18/23 15:09, Ivan Krylov wrote:
В Mon, 18 Dec 2023 11:06:16 +0100
Jisca Huisman пишет:
I isolated the problem in a minimal working example available here:
https://github.com/JiscaH/flang_segfault_min_example . All that does
is pas
On 12/14/23 19:39, McGrath, Justin M wrote:
At this point, the policy appears to have nothing to do with tar, contrary to
the error message. Thus, replacing tar with zip wouldn't address CRAN's
concern. The policy given in this thread (and seemingly unstated anywhere
public) is that CRAN
On 12/13/23 14:56, McGrath, Justin M wrote:
Thanks. Pursuing this a bit further, from ?tar "Known problems":
> The handling of file paths of more than 100 bytes. These
> were unsupported in early versions of ‘tar’, and supported in
> one way by POSIX ‘tar’ and in another by GNU
On 12/13/23 15:59, Dirk Eddelbuettel wrote:
On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| Please don't forget about what has been correctly mentioned on this
| thread already: there is essentially a 260 character limit on Windows
| (see
| https://blog.r-project.org/2023/03/07/path
On 1/17/24 08:37, Sameh Abdulah wrote:
Hi All,
We recently encountered an installation issue with our package on CRAN. We've
been depending on CMake, assuming it is readily available by default, but it
appears to be only available on the M1mac system but not on the others. Should
we
On 1/17/24 09:41, Ivan Krylov via R-package-devel wrote:
В Wed, 17 Jan 2024 10:30:36 +1100
Hugh Parsonage пишет:
I am unable to immediately see where in the test suite this error has
occurred.
Without testthat, you would have gotten a line by line printout of the code,
letting you
On 11/28/23 22:21, Tomas Kalibera wrote:
On 11/28/23 21:50, Henrik Bengtsson wrote:
Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.
Please let me clarify. %td works in R on Windows in R 4.3 and R-devel,
when using the recommended toolchain,
On 11/28/23 21:50, Henrik Bengtsson wrote:
Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.
Please let me clarify. %td works in R on Windows in R 4.3 and R-devel,
when using the recommended toolchain, which is Rtools43. It also worked
with R 4.2 and
On 11/28/23 20:51, Ivan Krylov wrote:
On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage wrote:
Rprintf("%lld", (long long) xlength(x));
This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.
Right, this has been my choice for R-devel,
On 11/28/23 21:55, Daniel Kelley wrote:
I hope it's okay to ask this on the present thread, rather than starting a new
one...
On this issue of the C format for various integer-type items, I am finding that
checks made with devtools::check_win_devel() give different results than those
made
On 11/29/23 19:30, Henrik Bengtsson wrote:
On Tue, Nov 28, 2023 at 1:21 PM Tomas Kalibera wrote:
On 11/28/23 21:50, Henrik Bengtsson wrote:
Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.
Please let me clarify. %td works in R on Windows in R 4.3
On 12/4/23 15:44, SHIMA Tatsuya wrote:
Thanks for your answer.
Unlike Windows Server, which has a long support period, Fedora's
support period is usually about one year, so it is surprising that the
old Fedora continues to be used.
And, unlike Windows, Linux uses the distribution standard
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
On 1/21/24 09:44, Ivan Krylov via R-package-devel wrote:
В Sat, 20 Jan 2024 20:28:00 -0500
Johann Gaebler пишет:
most likely there’s some error on my part in how I’ve set up cpp11,
but it also seems possible that cpp11 should have detected that that
header needs to be included and added it
On 1/22/24 15:42, Ivan Krylov via R-package-devel wrote:
On Mon, 22 Jan 2024 12:30:46 +0100
Tomas Kalibera wrote:
Thanks, ported now to R-patched.
Thank you!
Is it fine to mention problems like this one in the middle of an
e-mail, or should I have left a note in the Bugzilla instead
1 - 100 of 104 matches
Mail list logo
