Othman,
I'm not sure why you would expect a response from CRAN. The ball is in your
court - you have to either fix your code (ideally) or provide a justification
why you think it is safe. I have not seen any email from you to
c...@r-project.org and you have not mentioned the name of the
> On 29/05/2024, at 11:21 AM, Boylan, Ross wrote:
>
> Is it required that the package submitted to CRAN have been built with R CMD
> build rather than some other tool? When you say "CRAN has nothing to do with
> any of the above [different tools]" it sounds as if one can use anything; but
Ross,
R CMD build is the only offical way to build a (source) package in R.
All other "tools" are just convenience wrappers by 3rd parties that call R CMD
build eventually. There is no reason to assume that those tools should behave
in a certain way - nor are you required to use them. They
Ross,
It's entirely up to you how you do this -- what you describe is something that
has to happen before your run R CMD build, so it's not reflected in your
package that you submit (and this has nothing to do with CRAN or R). There is
nothing automatic as it requires you to do something in
the name of the package, otherwise the thread can quickly degrade to
wild guesswork and misleading or incorrect answers from unrelated parties.
Cheers,
Simon
> On 7/05/2024, at 6:56 PM, Simon Urbanek wrote:
>
> Ivan,
>
> sorry if it wasn't clear, but this thread was about stro
> On 10/05/2024, at 12:31 PM, Henrik Bengtsson
> wrote:
>
> On Thu, May 9, 2024 at 3:46 PM Simon Urbanek
> wrote:
>>
>> FWIW serialize() is binary so there is no conversion to text:
>>
>>> serialize(1:10+0L, NULL)
>> [1] 58 0a 00 00 00 03 00
> On 9/05/2024, at 11:58 PM, Vladimir Dergachev wrote:
>
>
>
> On Thu, 9 May 2024, Sameh Abdulah wrote:
>
>> Hi,
>>
>> I need to serialize and save a 20K x 20K matrix as a binary file. This
>> process is significantly slower in R compared to Python (4X slower).
>>
>> I'm not sure about
Sameh,
if it's a matrix, that's easy as you can write it directly which is the fastest
possible way without compression - e.g. quick proof of concept:
n <- 2^2
A <- matrix(runif(n), ncol = sqrt(n))
## write (dim + payload)
con <- file(description = "matrix_file", open = "wb")
system.time({
this only affects
R-oldrel so presumable Bioc upgrade may fix this so I'll have a look tomorrow.
Cheers,
Simon
> On May 7, 2024, at 6:15 PM, Ivan Krylov wrote:
>
> On Tue, 7 May 2024 10:07:59 +1200
> Simon Urbanek wrote:
>
>> That doesn't work - additional reposit
> On 5/05/2024, at 4:32 AM, Ivan Krylov via R-package-devel
> wrote:
>
> В Sat, 4 May 2024 15:53:25 +
> Sharon Bewick пишет:
>
>> I have a dependency on phyloseq, which is available through GitHub
>> but not on the CRAN site. I have a similar problem with microViz,
>> however I’ve
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
Kevin,
welcome to the S4 world! ;) There is really no good solution since S4 only
works at all if you attach the package since it relies on replacing the base S3
generic with its own - so the question remains what are your options to do it.
The most obvious is to simply add Depends: Rgraphviz
Rolf,
what do you mean by "broken"? Since you failed to include any proof nor details
it's unlikely that anyone can help you, but chances are pretty high that it was
a problem on your end. I just checked with R 4.4.0 on Ubuntu 22.04 and devtools
install and load just fine, so it is certainly
To quote Rob: "Version numbers are cheap"
The way the policy is worded it is clear that you cannot complain if you didn't
increase it as you are taking a risk. Also the the incoming FTP won't let you
upload same version twice so it wasn't really a problem until more recently
when there are
Just to include the necessary details: macOS CRAN build uses Apple clang-14, so
you cannot assume anything higher. Also the target is macOS 11 SDK.
That said, LLVM does not support the special math functions at all according to
the status report (see Mathematical Special Functions for C++17 at
Satyaprakash,
those are clear bugs in the SUNDIALS library - they assume that "unsigned long"
type is 64-bit wide (that assumption is also mentioned in the comments), but
there is no such guarantee and on Windows it is only 32-bit wide, so the code
has to be changed to replace "unsigned long"
email
> address) to c...@r-project.org on Mon, 23 Oct 2023.
>
> Thanks,
>
> Nic
>
>
> On Mon, 29 Jan 2024 at 18:51, Simon Urbanek
> wrote:
>>
>> Neal,
>>
>> generally, binaries are not allowed since CRAN cannot check the provenance
>> s
Neal,
generally, binaries are not allowed since CRAN cannot check the provenance so
it's not worth the risk, and it's close to impossible to maintain them over
time across different systems, toolchains and architectures as they evolve.
Historically, some packages allowed to provide binaries
First, let's take a step back, because I think there is way too much confusion
here.
The original report was about the vignette from the poweRlaw package version
0.70.6. That package contains a vignette file d_jss_paper.pdf with the SHA256
hash
mon
> I don't think these are "false claims".
>
> Iñaki
>
> El sáb., 27 ene. 2024 11:19, Simon Urbanek <mailto:simon.urba...@r-project.org>> escribió:
> Bob,
>
> I was not making assertions, I was only dismissing clearly false claims: CRAN
> did NO
t least poke at more 2020 PDFs from CRAN vignette
> builds (perhaps just the ones built that were JSS articles…it's possible the
> header image sourced at that time was tampered with during some time window,
> since image decoding issues have plagued Adobe Reader in buffer overflow land
>
Iñaki,
I think you got it backwards in your conclusions: CRAN has not generated that
PDF file (and Windows machines are not even involved here), it is the contents
of a contributed package, so CRAN itself is not compromised. Also it is far
from clear that it is really a malware - in fact it's
This is a reminder why one should never build packages directly in their source
directory since it can only be done once (for packages with native source code)
- always use
R CMD build --no-build-vignettes foo && R CMD INSTALL foo_*.tar.gz
if you plan to edit files in the source directory and
I had a quick look and that package (assuming it's
https://github.com/stsds/MPCR) does not adhere to any rules from R-exts (hence
the removal from CRAN I presume) so the failure to detect cmake is the least
problem. I would strongly recommend reading the R documentation as cmake is
just the
> On Jan 17, 2024, at 3:46 AM, Josiah Parry wrote:
>
> Hey folks! I've received note that a package of mine is failing tests on
> oldrel.
>
> Check results:
> https://www.r-project.org/nosvn/R.check/r-oldrel-windows-x86_64/arcgisutils-00check.html
>
> I think I've narrowed it down to the
Ralf,
that check always hangs for me (I don't think it likes NZ ;)), so I just use
_R_CHECK_CRAN_INCOMING_REMOTE_=0 R CMD check --as-cran ...
Cheers,
Simon
> On Jan 16, 2024, at 6:49 PM, Rolf Turner wrote:
>
>
> On Tue, 16 Jan 2024 16:24:59 +1100
> Hugh Parsonage wrote:
>
>>> Surely the
This has nothing to do with Steven's question since he is creating a *static*
library whereas install_name_tool changes install name ID entry of a *dynamic*
library. Also the data.table example is effectively a no-op, because changing
the ID makes no difference as it can't be linked against
Steven,
no, I'm not aware of any negative effect, in fact having an index in the
archive is always a good idea - some linkers require it, some work faster with
it and at the worst the linker ignores it. And as far as I can tell all current
system "ar" implementations support the -s flag (even
Justin,
now that you clarified what you are actually talking about, this is a question
about the CRAN policies, so you should really direct it to the CRAN team as it
is their decision (R-devel would be appropriate if this was a limitation in R
itself, and R-package-devel would be appropriate
As discussed here before packages should *never* set -mmacosx-version-min or
similar flags by hand. As documented in R-exts 1.2 packages should retrieve
compiler flags from R (this includes compiling 3rd party dependencies).
Incidentally, older versions of R have included -mmacosx-version-min
Jon,
The high-sierra build packages are currently not built due to hardware issues.
The macOS version is so long out of support by Apple (over 6 years) that it is
hard to maintain it. Only big-sur builds are supported at this point. Although
it is possible that we may be able to restore the
the policy. (At
> least, the CRAN volunteers seem to accept packages which use this approach.)
>
> Best,
> Chris
>
>
> From: R-package-devel on behalf of
> Simon Urbanek
> Sent: Saturday, November 18, 2023 6:14 PM
> To: Adam
> Cc: r-package-devel@r-project.
expect_false(
> endsWith(Sys.getenv("MEGAMATION_URL"), "/")
> )
> })
>
> Best,
> Adam
>
>
> On Sat, Nov 18, 2023 at 4:52 PM Simon Urbanek <mailto:simon.urba...@r-project.org>> wrote:
> Adam,
>
>
> > On Nov 1
Adam,
> On Nov 19, 2023, at 9:39 AM, Adam wrote:
>
> Dear Ivan,
>
> Thank you for explaining in such depth. I had not submitted to CRAN before.
> I will look into tools::R_user_dir().
>
> - May you point me toward the policy that the package should not edit
> .Renviron?
It is the policy
Dirk,
> On 17/11/2023, at 10:28 AM, Dirk Eddelbuettel wrote:
>
>
> Simon,
>
> On 17 November 2023 at 09:35, Simon Urbanek wrote:
> | can you clarify where the flags come from? The current CRAN builds
> (big-sur-x86_64 and big-sur-arm64) use
> |
> | exp
Dirk,
can you clarify where the flags come from? The current CRAN builds
(big-sur-x86_64 and big-sur-arm64) use
export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
export MACOSX_DEPLOYMENT_TARGET=11.0
so the lowest target is 11.0 and it is no longer forced it in the flags (so
...
>
> Mikael
>
> On 2023-10-31 3:33 pm, Simon Urbanek wrote:
>> Mikael,
>> current Matrix fails checks on R-oldrel so that's why only the last working
>> version is installed:
>> https://cran.r-project.org/web/checks/check_results_Matrix.html
>> Cheers
Mikael,
current Matrix fails checks on R-oldrel so that's why only the last working
version is installed:
https://cran.r-project.org/web/checks/check_results_Matrix.html
Cheers,
Simon
> On 1/11/2023, at 4:05 AM, Mikael Jagan wrote:
>
> I am guessing that they mean EdSurvey:
>
>
Paul,
can you give us a bit more detail? Which package, which build and where you got
the errors? Older builds may not have the latest Matrix.
Cheers,
Simon
> On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel
> wrote:
>
> Hi,
>
> I'm the maintainer for a few packages, one of
>From CRAN policy (which you agreed to when you submitted your package) - note
>in particular the "nor anywhere else on the file system" part and also note
>that it tells you what to do in your case:
Packages should not write in the user’s home filespace (including clipboards),
nor anywhere
discussed to death so I
didn't comment on those.
Cheers,
Simon
> On 18/10/2023, at 11:03 AM, Dirk Eddelbuettel wrote:
>
>
> On 18 October 2023 at 08:51, Simon Urbanek wrote:
> | John,
> |
> | the short answer is it won't work (it defeats the purpose of vignettes).
>
&
John,
the short answer is it won't work (it defeats the purpose of vignettes).
However, this sounds like a purely hypothetical question - CRAN policies allow
long-running vignettes if they declared.
Cheers,
Simon
> On 18/10/2023, at 3:02 AM, John Fox wrote:
>
> Hello Dirk,
>
> Thank you
packages directly to the CRAN's clang17 setup? I
> can enable verbose output for CMake and compare the output, but I'd rather
> not clog up the CRAN incoming queue just to debug a linker error?
>
> On Wed, Sep 27, 2023 at 2:43 PM Simon Urbanek <mailto:simon.urba...@r-project.org&g
Franz,
it means that the author(s) have abandoned the package: as the note says it was
failing checks and the authors have not fixed the problems so it has been
removed from CRAN (more than a year ago).
Cheers,
Simon
> On 9/10/2023, at 10:28 AM, Dr. Franz Király wrote:
>
> Dear all,
>
>
Matthias,
this has nothing to do with R, but rather your code. You have the wrong order
of headers: the SWI headers mess up visibility macros, so you have to include
them *after* Rcpp.h.
Cheers,
Simon
> On 9/10/2023, at 8:41 AM, Matthias Gondan wrote:
>
> Dear developers and CRAN people,
>
It looks like a C++ run-time mismatch between what cmake is using to build the
static library and what is used by R. Unfortunately, cmake hides the actual
compiler calls so it's hard to tell the difference, but that setup relies on
the correct sequence of library paths.
The rhub manually
I think the logic Jeff had in mind is that R order() uses C do_order() for
method="shell" and since do_order() uses orderVector1() by induction it is the
shell-sort implementation.
order() itself uses whatever you specify in method=.
Cheers,
Simon
> On Sep 25, 2023, at 7:10 AM, Jan Gorecki
Aron,
one package managed to spawn a separate process that was blocking the build
process (long story) and I was on the other side of the world. It should be
fixed now, but it may take up to a day before the backlog is processed. In the
future for faster response, please contact me directly -
n't
check - thus just trying reverse-engineer what happens by looking at the
dependencies which leads to GitHub).
> Sorry for nitpicking.
>
Sure, good to get the fact straight.
Cheers,
Simon
> Best,
> Yutani
>
> 2023年8月27日(日) 6:57 Simon Urbanek <mailto:simon.urba...@r-project.or
Tatsuya,
What you do is contact CRAN. I don't think anyone here can answer your
question, only CRAN can, so ask there.
Generally, packages with sufficiently many Rust dependencies have to be handled
manually as they break the size limit, so auto-rejections are normal. Archival
is unusual, but
> On Aug 26, 2023, at 11:01 AM, Dirk Eddelbuettel wrote:
>
>
> On 25 August 2023 at 18:45, Duncan Murdoch wrote:
> | The real problem is that there are two stubborn groups opposing each
> | other: the data.table developers and the CRAN maintainers. The former
> | think users should by
> On 14/08/2023, at 5:25 AM, Jamie Lentin wrote:
>
> Thanks both!
>
> On 2023-08-12 23:52, Uwe Ligges wrote:
>> On 12.08.2023 23:19, Dirk Eddelbuettel wrote:
>>> On 12 August 2023 at 18:12, Uwe Ligges wrote:
>>> | On 12.08.2023 15:10, Jamie Lentin wrote:
>>> | > The system call in question
Dirk,
thanks - one of those annoying cases where a script works in the login shell,
but not in the cron job -- hopefully fixed.
Cheers,
Simon
> On 9/08/2023, at 12:45 AM, Dirk Eddelbuettel wrote:
>
>
> Simon,
>
> This is still an issue for arm64. Uploaded tiledb and RQuantLib yesterday,
Drik,
thanks. I have tried to address the problem and the actual sync problem for
big-sur-x86_64 was fixed (as you can the see the results have been updated
after you reported it), but apparently there was another, independent, problem
with the cron jobs on that machine. I have changed the way
I looked into it and there was no issue on the build machine or staging server,
so it will require some more digging in the international waters .. hopefully
sometime next week…
Cheers,
Simon
> On 16/07/2023, at 11:25, Dirk Eddelbuettel wrote:
>
>
> Simon,
>
> On 12 July 2023 at 19:02,
> On Jul 14, 2023, at 11:19 AM, Hadley Wickham wrote:
>
>>> If CRAN cannot trust even the official one of Rust, why does CRAN have Rust
>>> at all?
>>>
>>
>> I don't see the connection - if you downloaded something in the past it
>> doesn't mean you will be able to do so in the future.
Yutani,
[moving back to the original thread, please don't cross-post]
> On Jul 13, 2023, at 3:34 PM, Hiroaki Yutani wrote:
>
> Hi Simon,
>
> Thanks for the response. I thought
>
>> download a specific version from a secure site and check that the
> download is the expected code by some sort
> Presumedly, the vendored sources would be built using the versions specified
> in an accompanying Cargo.lock as well.
>
> https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
>
>
> On Wed, Jul 12, 2023, 7:35 PM Simon Urbanek
> wrote:
> Yutani,
>
&g
Yutani,
I'm not quite sure your reading fully matches the intent of the policy.
Cargo.lock is not sufficient, it is expected that the package will provide
*all* the sources, it is not expected to use cargo to resolve them from random
(possibly inaccessible) places. So the package author is
Dewey,
you will definitely need to include all the necessary sources for your package.
You may want to have a look at the "Using Rust"[1] document linked from the
CRAN policy. I think Go is quite similar to Rust in that sense so you should
use the same approach, i.e. checking for system and
To quote from the page you downloaded R from:
This release uses Xcode 14.2/14.3 and GNU Fortran 12.2. If you wish to compile
R packages which contain Fortran code, you may need to download the
corresponding GNU Fortran compiler from https://mac.R-project.org/tools.
> On Jul 6, 2023, at
Stephen,
If you want to give the system version a shot, I would simply look for
pkg-config, add the supplied CPPFLAGS to the package R flags if present and
then test (regardless of pkg-config) with AC_CHECK_HEADER (see standard R-exts
autoconf rules for packages). If that fails then use your
> On Jun 24, 2023, at 12:19 AM, Uwe Ligges
> wrote:
>
>
>
> On 23.06.2023 11:27, Helmut Schütz wrote:
>> Dear all,
>> since a while (January?) we face NOTEs in package checks
>> (https://cran.r-project.org/web/checks/check_results_PowerTOST.html):
>> Version: 1.5-4
>> Check: package
Bernd,
the sequence in which you submit doesn't matter - the packages have to work
regardless of the sequence. Suggests means that the dependency is optional, not
that it can break tests. You have to skip the tests that cannot be run due to
missing dependencies (see 1.1.3.1 in R-exts)
Cheers,
Andreas,
Xcode update fixed the issue as expected so in due time the ERRORs should
disappear.
Cheers,
Simon
> On 18/06/2023, at 10:29 AM, Simon Urbanek wrote:
>
> Andreas,
>
> that is actually not your problem - the stubs are generated in glib, so your
> package ca
Andreas,
that is actually not your problem - the stubs are generated in glib, so your
package can do nothing about it, your compile flags won't change it. The only
way to fix it is on my end, the proper way is to upgrade to Xcode 14 for the
package builds, but that requires some changes to the
Florian,
ok, understood. It works for me on both M1 build machines, so can't really
help. I'd simply submit the new version on CRAN. Of course it would help if the
tests were more informative such as actually showing the values involved on
failure so you could at least have an idea from the
Florian,
looking at the notes for 2.1-4 it says the tolerance has the wrong sign, i.e.
you're adding it to the value on both sides of the interval (instead of
subtracting for the lower bound). In your latest version the tolerances get
added everywhere so that makes even less sense to me, but
This thread went way off the rails and was cross-posted so the solution is on
R-SIG-Mac.
It was simply wrong Fortran with wrong R - installing latest R and Fortran
(from CRAN or https://mac.r-project.org/tools/) is the easiest way to solve the
problem.
Note that R binaries and tools go
volve cron jobs which is why the total time
from upload to published binary can take a bit of time.
Cheers,
Simon
> On 17/05/2023, at 10:55 AM, Dirk Eddelbuettel wrote:
>
>
> On 17 May 2023 at 10:39, Simon Urbanek wrote:
> | Dirk,
> |
> | thanks, ok, now I get wh
,
Simon
> On 17/05/2023, at 8:39 AM, Dirk Eddelbuettel wrote:
>
>
> Simon:
>
> On 17 May 2023 at 07:57, Simon Urbanek wrote:
> | builds are immediate, so it is a matter of seconds for most packages. I
> don't see any issues on the Mac Builder server.
> | If you hav
Dirk,
builds are immediate, so it is a matter of seconds for most packages. I don't
see any issues on the Mac Builder server.
If you have a problem, please be more specific and include the check link
returned at submission.
Cheers,
Simon
> On 17/05/2023, at 4:27 AM, Dirk Eddelbuettel
I think it would be quite useful to have some community repository of code
snippets dealing with such situations. R-exts gives advice and pieces of code
which are useful, but they are not complete solutions and situations like
Dirk's example are not that uncommon. (E.g., I recall some of the
Dirk,
can you be more specific, please? I suspect that it may be rather an issue in
your package. All build machines have the official cmake releases installed and
there are many packages that use it successfully. Here is the report on the
currently installed versions. If you require more
of "local" registration and then
replacing the name-based search up the call chain with local registration
search - but probably again at the cost of performance.
Cheers,
Simon
> On May 9, 2023, at 11:23 AM, Duncan Murdoch wrote:
>
> On 08/05/2023 6:58 p.m., Simon Urbanek w
> On 8/05/2023, at 11:58 PM, Duncan Murdoch wrote:
>
> There really isn't such a thing as "a function that looks like an S3 method,
> but isn't". If it looks like an S3 method, then in the proper circumstances,
> it will be called as one.
>
I disagree - that was the case in old
> On May 4, 2023, at 3:36 AM, Martin Morgan wrote:
>
> CRAN is fine with Bioconductor Depends: and Imports: dependencies, as
> previously mentioned. This is because the CRAN maintainers explicitly
> configure their system to know about Bioconductor package repositories.
>
That is not
Dirk,
thanks - the problem is that there is not a single installer package (for
several years now), so that URL is ambiguous. Whether the missing link is a
good or bad depends on how it is used. I would argue that any link to that URL
is inherently bad, because there is no way of knowing that
John,
you provide no details to go on, but generally the main difference is that
arm64 uses 64-bit precision for long double (which is permitted by the C
standard), while Intel uses 80-bits of precision (on systems that enable it).
That leads to differences in results, e.g. when computing long
Packages can only be installed from the repositories listed and only CRAN is
the default so only CRAN package are guaranteed to work. I'd like to add that
the issue below is exactly why, personally, I would not recommend using
Bioconductor package as strong dependency (imports/depends), because
Bill,
the short answer is you can't limit anything at R level. Any attempts to create
a list of "bad" commands are trivial to circumvent since you can compute on the
language in R, so you can construct and call functions with trivial operations.
Similarly, since R allows the loading of binary
Quirin,
this is a contributed package question, so you should either use the GitHub
issues (https://github.com/s-u/OpenCL/issues) for the package or contact the
maintainer (me). But before you do so, you have to provide a lot more details
including exact code you used and the full output of
Duncan,
I don't know if it is best, but you can have a look at "background"[1] which is
I believe what "later" was inspired by. It is a very minimal example so should
give you ideas on how to do that in your package - it runs the R code on the
main thread so it should be as close to safe as
Uri,
I can speak only for macOS package binaries and they have been rarely re-built.
The only time when a re-build is necessary is when a dependency is updated and
breaks its backward-compatibility (sadly, yes, that happens). It is relatively
rare, but recently Matrix was one example with
David,
why not
call[[1]] <- parse_args
The assignment is evaluated in your namespace so that makes sure the call is
that of your function. The only downside I see is that in a stack trace you'll
see the definition instead of the name.
Or possibly
do.call(parse_args, as.list(call[-1]))
el wrote:
>
>
> Simon,
>
> On 9 December 2022 at 10:00, Simon Urbanek wrote:
> | the minimum required version for the high-sierra build is 10.13 and for
> big-sur build is 11.0 (as the names imply). Although it is not unrealistic to
> move Intel to macOS 10.14, it wou
Dirk,
the minimum required version for the high-sierra build is 10.13 and for big-sur
build is 11.0 (as the names imply). Although it is not unrealistic to move
Intel to macOS 10.14, it would be more problematic to move to 10.15 since it is
the version that killed 32-bit support so 10.14 is
Louis,
you didn't provide any details (please always post a link to the sources you're
talking about!), but I suspect you are missing character length arguments,
Lapack.h has:
F77_NAME(dgeevx)(const char* balanc, const char* jobvl, const char* jobvr,
const char* sense, const
Have you followed the instructions?
> CRAN Repository Policy
>
> Submission
> [...]
> Explain any change in the maintainer’s email address and if possible send
> confirmation from the previous address (by a separate email to
> cran-submissi...@r-project.org) or explain why it is not possible.
community to do.
Cheers,
Simon
> On Nov 13, 2022, at 9:20 AM, Dirk Eddelbuettel wrote:
>
>
> On 13 November 2022 at 08:15, Simon Urbanek wrote:
> | sorry, I think you misunderstood: CRAN machines have the compilers, but the
> packages were not detecting it properly and
to make the same mistakes
over again.
Cheers,
Simon
> On Nov 13, 2022, at 7:27 AM, Jeroen Ooms wrote:
>
> On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek
> wrote:
>>
>> this does not directly address your question, but I think it would make a
>> lot of sense to
Florian,
this does not directly address your question, but I think it would make a lot
of sense to standardize the process, given how many issues there were with
packages using Rust (mainly not detecting compilers correctly, not supplying
source code, unsolicited writing into user's
Liam,
I think I have failed to convey my main point in the last e-mail - which was
that you want to parse the date/time in the timezone that you care about so in
your example that would be
> foo <- as.Date(33874, origin = "1899-12-30")
> foo
[1] "1992-09-27"
> as.POSIXlt(as.character(foo),
Alexandre,
it's better to parse the timestamp in correct timezone:
> foo = as.POSIXlt("2021-10-01", "UTC")
> as.POSIXct(as.character(foo), "Europe/Berlin")
[1] "2021-10-01 CEST"
The issue stems from the fact that you are pretending like your timestamp is
UTC (which it is not) while you want to
Paul,
I wouldn't worry about oldrel - that's likely an incomplete run (I don't see
that error anymore), but I would worry about the failure on R-release:
https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/EdSurvey-00check.html
You can always check with the Mac Builder before you
Florian,
since there was no direct response and given the earlier discussion I figured I
chime. The main problem seems to be your build system that doesn't work. Since
you didn't post the actual version of the package, I can only see the CRAN
version which still don't set any of the necessary
Thanks, indeed, as part of full re-install for R 4.2.0 package builds the
Tcl/Tk libraries were missing. Now fixed and summarytools check with
* checking data for non-ASCII characters ... NOTE
Note: found 78 marked UTF-8 strings
Status: 1 NOTE
I'll just repeat the important link that Tomas
Michael,
I can replicate the problem on macOS so this is not system-specific - did you
actually try to re-build the vignette? As can be seen from the output the
problem is is the following line:
one_rec %>% pull(abstract_text) %>% print
Xavier,
short answer is no, because there is no guarantee that user's system supports
any encoding other than ASCII, so that code wouldn't run. Hence you can't use
non-ASCII characters in symbols.
That said, you can use Unicode _strings_, so metadata[["\u00e1cc\u00e9nts"]]
will work in
Sure, installed pandoc 2.16.2.
Cheers,
Simon
> On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel wrote:
>
>
> CRAN results flag NOTEs on the two platforms
> r-release-macos-x86_64
> r-oldrel-macos-x86_64
> because `pandoc` is apparently missing. These platforms being somewhat
> common,
1 - 100 of 110 matches
Mail list logo
