FWIW: connectivity from GH runners is notoriously patchy*, so I wouldn’t rely
on those for URL checks, so I’d recommend using the solution by Ivan in actions
and simply running a separate check without the option once in a while locally
(e.g., before submission) to detect such issues. After all,
Josh,
your package got caught up in a chain-reaction: the pan package failed to
install *after* its binary package was built due to disk space issues, so
although the pan package binary is on CRAN, the package itself was not
available in the build machine’s R library. JWileymisc doesn’t depend
… but you have
SystemRequirements: GNU make, CMake (>= 3.10),
so clearly something it wrong in your package?
Cheers,
Simon
> On 22 Mar 2025, at 21:52, matthias-gon...@gmx.de wrote:
>
> Dear CRAN people, and R package developers,
>
>
>
> since the last update, the CRAN tests of my package
I would like to second the Zenodo recommendation. Github is not reliable enough
for reproducible research (your files can disappear at any point - or can
change without notice), that's why Zenodo was created. It assumes that your
package has the list of DOIs to offer, but that should be ideally
Josiah,
that test tests the accuracy of the system clock by querying
https://worldtimeapi.org/api/timezone/etc/UTC so my guess would be that you
have either network or proxy issues which cause that request to fail by
providing garbage instead of the actual response.
The call to test yourself
Lluís,
the timestamps are generated by the CRAN server when it updates webpage from
the actual check reports so it does not reflect the date/time of the check
itself (neither does the timestamp of the URL as it is often re-generated). So
in short, no, there is no way to know the timestamp of th
Naras,
sorry, but since this involves some Rust code, I fear that you'll have to
discuss it with Brian directly. FWIW on the CRAN M1 build machine it seems to
use the correct flags:
$ grep fortran/lib
/Volumes/Builds/packages/big-sur-arm64/results/4.5/clarabel.Rcheck/00install.out
clang -arc
Steven,
> On 19 Jan 2025, at 05:37, Steven Jenkins wrote:
>
> Longtime R user, first-time packager. Devtools are great; it’s pretty easy.
>
> I’m trying to submit a package (https://github.com/jsjuni/massProps) that
> calculates mass properties and uncertainties for assembly trees. Very
> st
ve error message.
>
> The CRAN Windows as well as Linux build service included fftwf in their
> fftw build out of the box, and so building there was no problem, R CMD
> Check passes there. In the past, building for MacOS was more trouble, since
> its fftw package does not include a sing
John,
does it have to be PDF? Unfortunately, PDF is not easy to deal with in
platform-independent way (and generally as well - of all the systems only macOS
has native support for it). If you really have no other choice, my only
suggestion would be to use poppler to render it so it can be displ
> On 27 Oct 2024, at 23:03, Gianmarco Alberti
> wrote:
>
> Dear R Package Developers,
> I am seeking guidance regarding a situation with my package 'chisquare'
> (version 1.1) on CRAN.
>
> Current situation:
>
> 1. The package was submitted and (automatically) accepted to CRAN (version
> 1.
See the error - that looks like a temporary issue. I'd contact CRAN or resubmit.
Cheers,
Simon
> On Oct 17, 2024, at 09:04, Michael Mahony wrote:
>
>
>
> Apologies in advance for not providing a reproducible example, but I am
> unsure how to reproduce the below error, as it did not occur o
Ben,
if I recall there were a couple regressions in knitr that broke things, but
since this is only a WARNING it means the check has not been automatically
repeated after knitr update (ERRORs are re-tried nightly). I can kick off
things manually which is likely to remove the WARNING.
Cheers,
S
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 cla
> 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 infor
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 package
> 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 typi
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 any
y 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
> 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 t
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({
ently 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 - additi
> 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 manag
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 w
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 w
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 br
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 mult
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" w
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 (e.
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 9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad84
Cheers,
Simon
> 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
meone should likely at 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
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 c
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 r
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 wr
> 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 way
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 s
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 dire
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 t
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 if
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 in
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 old
to be okay with the new reading of 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
E
> )
> 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,
>
>
>
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 yo
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
>> C
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:
>
>https://
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 whi
>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 el
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 (a
mail.com>> wrote:
> Is there any way to submit 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
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,
>
> c
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 forces
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 w
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 - s
tual package so can'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 <mai
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 def
> 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 is
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, Di
> 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. And
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
imon
> 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 expe
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 use
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 11:50
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 in
> 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 depend
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 can d
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 out
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 th
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 togethe
ay involve 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 yo
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 wrote:
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 spa
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 recen
ire a kind 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
> 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 versions,
> 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 exact
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 t
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 c
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 the
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 one
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 reaso
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]))
Cheers
1 - 100 of 125 matches
Mail list logo
