> On Apr 24, 2024, at 12:52 AM, Hadley Wickham wrote:
>
>>
>>
>>
ALTREP is part of the official R api, as illustrated by the presence of
src/include/R_ext/Altrep.h. Everything declared in the header files in
>> that
directory is official API AFAIK (and I believe that is more
> On Apr 23, 2024, at 10:29 AM, Hadley Wickham wrote:
>
>
>
> On Mon, Apr 22, 2024 at 5:14 PM Simon Urbanek
> wrote:
>
>
> > On Apr 22, 2024, at 7:37 PM, Gabriel Becker wrote:
> >
> > Hi Yutani,
> >
> > ALTREP is part of the off
> On Apr 22, 2024, at 7:37 PM, Gabriel Becker wrote:
>
> Hi Yutani,
>
> ALTREP is part of the official R api, as illustrated by the presence of
> src/include/R_ext/Altrep.h. Everything declared in the header files in that
> directory is official API AFAIK (and I believe that is more
Duncan,
I have fixed up the repo with git restore-mtime -- I think that should solve it
- please check if it did what we needed.
Cheers,
Simon
> On Apr 3, 2024, at 2:41 AM, Duncan Murdoch wrote:
>
> On 02/04/2024 8:50 a.m., Dirk Eddelbuettel wrote:
>> On 2 April 2024 at 07:37, Dirk
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
> On 7/02/2024, at 5:06 AM, Prof Brian Ripley via R-devel
> wrote:
>
> On 04/02/2024 19:41, Holger Hoefling wrote:
>> Hi,
>> I wanted to ask if people have good advice on how to debug M1Mac package
>> check errors when you don´t have a Mac? Is a cloud machine the best option
>> or is there
> On Feb 5, 2024, at 12:26 PM, Duncan Murdoch wrote:
>
> Hi John.
>
> I don't think the 80 bit format was part of IEEE 754; I think it was an Intel
> invention for the 8087 chip (which I believe preceded that standard), and
> didn't make it into the standard.
>
> The standard does talk
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"
Any reason why you didn't use quiet=TRUE to suppress that output?
There is no official API structure for credentials in R repositories, so R has
no way of knowing which part of the URL are credentials as it is not under R's
purview - it could be part of the path or anything, so there is no way
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
William,
the check does not apply to binary installations (such as the Mac builds),
because those depend heavily on the static libraries included in the package
binary which can be quite big and generally cannot be reduced in size - for
example:
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
Harmen,
thanks for the additional details, it wasn't exactly clear what this is about.
Ivan's post didn't mention that the issue here is the caching, not the path
replacement which you are apparently already doing, now it makes more sense.
I still think it is dangerous as you have no way of
Ivan,
I suspect that the `which' case is just the tip of the iceberg - generally, R
expects all tools it detects at configure time to be callable, just to list a
few from a running session:
PAGER /usr/bin/less
R_BROWSER /usr/bin/open
R_BZIPCMD
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
Tim,
thanks. I have updated R to the latest R-devel on the machine in the hope that
is may help, but I suspect it will only affect new entries as they are
generated progressively each day.
Cheers,
Simon
> On Nov 18, 2023, at 11:38 AM, Tim Taylor
> wrote:
>
> The news feeds (e.g.
>
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
That said, both points were meant for the list in general - those are nice
self-contained projects (add libwayland to Cairo and GLFW to rgl) for someone
with spare time to contribute...
Cheers,
Simon
> On 30/10/2023, at 9:48 AM, Duncan Murdoch wrote:
>
> On 29/10/2023 4:20 p.m.,
> On 30/10/2023, at 8:38 AM, Dirk Eddelbuettel wrote:
>
>
> On 30 October 2023 at 07:54, Paul Murrell wrote:
> | I am unaware of any Wayland display support.
> |
> | One useful way forward would be an R package that provides such a device
> | (along the lines of 'Cairo', 'tikzDevice', et
>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,
>
Jan,
have you re-installed all packages? If you change (update) any package that
uses S4 it may be necessary to re-install all its reverse-dependencies as well
since they may include cached values in their namespaces, so the easiest is to
make sure you re-install all packages.
Cheers,
Simon
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
s safe.
>
> For future reference, will the measurements reported by
> textshaping::shape_text() match the values used by your Cairo package, or are
> equivalent measurements available elsewhere?
>
> Duncan Murdoch
>
> On 24/09/2023 6:55 p.m., Simon Urbanek wrote:
>>
Duncan,
drawing text is one of the most complicated things you can do, so it really
depends how for you want to go. You can do it badly with a simple cairo
show_text API. The steps involved in doing it properly are detecting the
direction of the language, finding fonts, finding glyphs
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,
> On 8/08/2023, at 12:07 PM, Dirk Eddelbuettel wrote:
>
>
> On 8 August 2023 at 11:21, Simon Urbanek wrote:
> | First, detecting HT vs cores is not necessarily possible in general, Linux
> may assign core id to each HT depending on circumstances:
> |
> | $ grep '
First, detecting HT vs cores is not necessarily possible in general, Linux may
assign core id to each HT depending on circumstances:
$ grep 'cpu cores' /proc/cpuinfo | uniq
cpu cores : 32
$ grep 'model name' /proc/cpuinfo | uniq
model name : Intel(R) Xeon(R) Gold 6142 CPU @ 2.60GHz
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
Carl,
I think your statement is false, the whole point of R_user_dir() is for
packages to have a well-defined location that is allowed - from CRAN policy:
"For R version 4.0 or later (hence a version dependency is required or only
conditional use is possible), packages may store user-specific
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
I agree that this is not an R issue, but rather user error of not defining a
proper generic so the check is right. Obviously, defining a generic with
implementation-specific ncol default makes no sense at all, it should only be
part of the method implementation. If one was to implement the same
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
Gabe,
thanks, this was a fall-out from a power outage due to the cyclone. Although
all systems were back up, svn lock files have led to an early abort in the
update step. It should be fixed now.
Cheers,
Simon
> On 27/02/2023, at 10:40 AM, Gabriel Becker wrote:
>
> Hi all,
>
> It looks
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
Nino,
that is the wrong way around as Ivan pointed out. Rprintf() is not the tool for
this as explained. If you want messages, use them, it's easy to wrap it to C
code:
static void Rmessage(const char *msg) {
SEXP msg_sym = Rf_install("message");
SEXP msg_call = PROTECT(lang2(msg_sym,
Ben,
yes, by definition - non-blocking means that reads won't block and always
return immediately (the point of non-blocking). The loop below is terrible as
it will cause 100% CPU usage while it's spinning. It seems that you want to
block so why are you using non-blocking mode? select()
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
ot;=", fixed = TRUE) :
> input string 137 is invalid in this locale
>
> # R 4.1.0 - ...
> $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv()['BOOM']"
> Error in substring(x, m + 1L) : invalid multibyte string at ''
> Calls: Sys.getenv -> substring
&g
Tomas,
I think you're not addressing the actual issue which is a clear regression in
Sys.getenv() [because it used to work and still works for single env var, but
not a list] and the cryptic error due to that regression (caused by changes in
R-devel). So in either case, Sys.getenv needs fixing
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
> On 7/01/2023, at 1:17 PM, gong yu wrote:
>
> understand your concerns.
> for registerTZ.c itself , IMHO , the most important part is the definition of
> tztable[] . which come form
> http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html ,but it
> can’t access now, the lasted
Just a quick comment here - this is not as easy as it sounds, because the code
is in the "extra" directory which means it is based on upstream sources, so
those sources are typically not patched manually as it would be hard to apply
upstream updates. In this case the standards have changed
This crashes unceremoniously in glibc:
> tools:::sysdata2LazyLoadDB("./R/sysdata.rda","../../../library/tools/R")
xdrmem_create(0x7ffdf19699e0, 0x7ffdf1969ba0, 4)
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1
Yes:
$ R CMD INSTALL --help | grep error
--no-clean-on-error do not remove installed package on error
But probably more commonly used way is to install the package from its unpacked
directory as that avoids the use of temporary directories in the first place.
In you case you can
1 - 100 of 1343 matches
Mail list logo
