> 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
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
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({
> 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
> 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
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
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
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
> 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
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 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
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
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
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
> 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.
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
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
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
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
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
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
… 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
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
Tim,
no, and as far as I can tell some of the claims in that thread are incorrect.
Whether long double is identical to double is irrelevant and has nothing to do
with it.
R has a configuration option --enable-long-double which governs whether R
should use algorithms which can benefit from exte
John,
it's sort of the other way around: because neither the implementation, format
nor precision of "long double" are defined by the C standard (it's not even
required to be based on IEEE 754/IEC 60559 at all), it is essentially left to
the compilers+runtimes to do whatever they choose, making
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
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,
101 - 127 of 127 matches
Mail list logo
