On 11 June 2024 at 10:05, Peter Green wrote:
| Package: beast-mcmc
| Version: 1.10.4+dfsg-5
| Severity: serious
| x-debbugs-cc: r-cran-rj...@packages.debian.org
|
| beast-mcmc build-depends on r-cran-rjava, which is no longer available
| on i386. It appears that the package failed to build, and
On 11 June 2024 at 10:05, Peter Green wrote:
| Package: beast-mcmc
| Version: 1.10.4+dfsg-5
| Severity: serious
| x-debbugs-cc: r-cran-rj...@packages.debian.org
|
| beast-mcmc build-depends on r-cran-rjava, which is no longer available
| on i386. It appears that the package failed to build, and
On 6 June 2024 at 04:47, Paul Kabaila wrote:
| When I resubmitted, I didn't realise that I needed to change the version
number.
As this comes up every now and then: This is still a _soft_ requirement. CRAN
does not 'cache' what versions you used in uploads. I have often reiterated
with the
On 6 June 2024 at 08:22, Johannes Ranke wrote:
| Am Mittwoch, 5. Juni 2024, 22:27:09 CEST schrieb Dirk Eddelbuettel:
| > On 5 June 2024 at 21:55, Paul Gevers wrote:
| > | Source: survival
| > | Version: 3.5-8-1
| > | Severity: serious
| > | Control: close -1 3.6-4-1
| >
On 6 June 2024 at 08:22, Johannes Ranke wrote:
| Am Mittwoch, 5. Juni 2024, 22:27:09 CEST schrieb Dirk Eddelbuettel:
| > On 5 June 2024 at 21:55, Paul Gevers wrote:
| > | Source: survival
| > | Version: 3.5-8-1
| > | Severity: serious
| > | Control: close -1 3.6-4-1
| >
Source: r-cran-popepi
Version: 0.4.11+dfsg-1
This package is holding CRAN package 'survival' (aka r-cran-survival, a
package listed as part of the 'recommended' set by R Core and hence in
r-recommended) back from migrating and is now threatening removal. See
#1072648 for details.
And that is
On 5 June 2024 at 21:57, Paul Gevers wrote:
| Source: quantlib-swig
| Version: 1.33-1
| Severity: serious
| Control: close -1 1.34-1
| Tags: sid trixie ftbfs
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
On 5 June 2024 at 21:57, Paul Gevers wrote:
| Source: quantlib-swig
| Version: 1.33-1
| Severity: serious
| Control: close -1 1.34-1
| Tags: sid trixie ftbfs
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
On 5 June 2024 at 21:55, Paul Gevers wrote:
| Source: survival
| Version: 3.5-8-1
| Severity: serious
| Control: close -1 3.6-4-1
| Tags: sid trixie
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages that are
On 5 June 2024 at 21:55, Paul Gevers wrote:
| Source: survival
| Version: 3.5-8-1
| Severity: serious
| Control: close -1 3.6-4-1
| Tags: sid trixie
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages that are
Mark,
On 31 May 2024 at 22:33, Voorhies, Mark wrote:
| Package: r-cran-gdata
| Version: 2.18.0.1-1
| Severity: normal
|
| Dear Maintainer,
|
| I believe r-cran-gdata 2.18.0.1-1 in Debian 12 is vulnerable to CVE-2023-7101
| due to shipping a copy of Utility.pm from Spreadsheet::ParseExcel that
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
experimental was has now cleared NEW.
I checked my email folder, and the last time this happened (gsl 2.7,
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
experimental was has now cleared NEW.
I checked my email folder, and the last time this happened (gsl 2.7,
On 26 May 2024 at 13:31, Kurt Hornik wrote:
| >>>>> Dirk Eddelbuettel writes:
|
| > Kurt,
|
| > Could you do me a favour and run on that clang18-using machine in question
| > the following one-liner (provided your session has access to a .libPaths()
| > inclu
We are still having the open issue of rpy2 now segfaulting on the embedding
tests which reproduces on my plain vanilla amd64 setup -- so I commented that
test out too.
Laurent: Any idea why R 4.4.0 and rpy2 do not get along on embedding?
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel
We are still having the open issue of rpy2 now segfaulting on the embedding
tests which reproduces on my plain vanilla amd64 setup -- so I commented that
test out too.
Laurent: Any idea why R 4.4.0 and rpy2 do not get along on embedding?
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel
On 26 May 2024 at 11:41, Jörg-Volker Peetz wrote:
| Package: r-cran-matrix
| Version: 1.7-0-2
| Severity: wishlist
|
| Dear Dirk Eddelbuettel,
|
| shouldn't this package depend on r-base-core instead of r-base?
| The description of r-base says it "eases the transition from the
| pre-
On 25 May 2024 at 12:35, Bo YU wrote:
| Hi,
| On Sat, May 18, 2024 at 06:41:53AM -0500, Dirk Eddelbuettel wrote:
| >
| >On 17 May 2024 at 23:05, Santiago Vila wrote:
| >| Dirk Eddelbuettel wrote:
| >| > Is there a chance this could be spurious?
| >|
| >| Unlikely because
On 25 May 2024 at 12:35, Bo YU wrote:
| Hi,
| On Sat, May 18, 2024 at 06:41:53AM -0500, Dirk Eddelbuettel wrote:
| >
| >On 17 May 2024 at 23:05, Santiago Vila wrote:
| >| Dirk Eddelbuettel wrote:
| >| > Is there a chance this could be spurious?
| >|
| >| Unlikely because
On 24 May 2024 at 20:01, Brad Eck wrote:
| I received a note that my package -- epanet2toolkit -- was showing a
| warning in the fedora-gcc results on CRAN.
| https://www.stats.ox.ac.uk/pub/bdr/gcc12/epanet2toolkit.out
|
| I'd like to reproduce the warning and fix it. Usually I'd do that with
Kurt,
Could you do me a favour and run on that clang18-using machine in question
the following one-liner (provided your session has access to a .libPaths()
including Rcpp) and, in the case of success, the resulting function?
> Rcpp::cppFunction("int ompconfigtest() { return
On 23 May 2024 at 20:02, Ivan Krylov wrote:
| On Wed, 22 May 2024 09:18:13 -0500
| Dirk Eddelbuettel wrote:
|
| > Testing via 'nm' as you show is possible but not exactly 'portable'.
| > So any suggestions as to what to condition on here?
|
| (My apologies if you already got an answe
On 22 May 2024 at 14:03, Duncan Murdoch wrote:
| On 2024-05-22 10:18 a.m., Dirk Eddelbuettel wrote:
| >
| > On 22 May 2024 at 13:54, Nixon, Michelle Pistner wrote:
| > | Thank you both for your responses and help! Kurt-- your message makes a
lot of
| > | sense. I'll try t
the Right
Thing (TM) by 'borrowing' from the fairly mature check in RcppArmadillo.
Dirk
|
| Thanks,
| Michelle
|
━━━
| From: Kurt Hornik
| Sent: Wednesday, May 22, 2024 3:57 AM
| To: Dirk Eddelbuettel
| Cc: Nixon, Michelle
As lyx is not listed in 'Writing R Extensions', the one (authorative) manual
describing how to build packages for R, I would not assume it to be present
on every CRAN machine building packages. Also note that several user recently
had to ask here how to deal with less common fonts for style
Hi Michelle,
On 21 May 2024 at 13:46, Nixon, Michelle Pistner wrote:
| Hi all,
|
| I'm running into build issues for my package (fido:
https://github.com/jsilve24/fido) on the r-devel-linux-x86_64-debian-clang
system on CRAN (full check log here:
On 21 May 2024 at 15:59, Ivan Krylov wrote:
| On Tue, 21 May 2024 14:48:48 +0200
| Kurt Hornik wrote:
|
| > I guess foer the CXXFLAGS we want dpkg-buildflags --get CXXFLAGS?
Good catch, and expansion, by both of you.
| It must be the case. It's both the documented option [1] and it
|
On 21 May 2024 at 13:01, Jeroen Ooms wrote:
| Compiling packages with C++ code using the default r-base-dev
| configuration on debian:sid shows a lot of:
|
|cc1plus: warning: '-Werror=' argument
| '-Werror=implicit-function-declaration' is not valid for C++
|
| Can this flag be removed
On 20 May 2024 at 19:12, Andreas Tille wrote:
| Source: car
| Version: 3.1-2-2
| Severity: normal
|
| Hi,
|
| car mentions r-cran-maptools in (Build-)Depends which is not backed up
| by the DESCRIPTION file. Since maptools is removed from CRAN I'd like
Yes, we fail to build if 'added'
On 18 May 2024 at 07:59, Dirk Eddelbuettel wrote:
|
| Hi Laurent,
|
| We a build issue in Debian found via bulk rebuilds. Which everything current
| in 'unstable', rpy2 (version 3.5.16) segfaults in a test when embedding.
|
| Details are at https://bugs.debian.org/1071362
|
| If you kee 1071
On 18 May 2024 at 07:59, Dirk Eddelbuettel wrote:
|
| Hi Laurent,
|
| We a build issue in Debian found via bulk rebuilds. Which everything current
| in 'unstable', rpy2 (version 3.5.16) segfaults in a test when embedding.
|
| Details are at https://bugs.debian.org/1071362
|
| If you kee 1071
Appears to be a duplicate of 1071379, maybe check if your script meant to
remove another one.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 17 May 2024 at 23:05, Santiago Vila wrote:
| Dirk Eddelbuettel wrote:
| > Is there a chance this could be spurious?
|
| Unlikely because it also happens here:
|
| https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html
Ok, I will get in touch with Laurent.
D
On 17 May 2024 at 23:05, Santiago Vila wrote:
| Dirk Eddelbuettel wrote:
| > Is there a chance this could be spurious?
|
| Unlikely because it also happens here:
|
| https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html
Ok, I will get in touch with Laurent.
D
Is there a chance this could be spurious? The R API is reasonably stable,
including the part for embedding R (and I am upstream for a small project
doing that from C++). rpy2 is also mature and stable. So could this be a
one-off?
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel |
Is there a chance this could be spurious? The R API is reasonably stable,
including the part for embedding R (and I am upstream for a small project
doing that from C++). rpy2 is also mature and stable. So could this be a
one-off?
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel |
On 16 May 2024 at 05:34, Duncan Murdoch wrote:
| I forget now, but presumably the thinking at the time was that Suggested
| packages would always be available for building and checking vignettes.
Yes. I argued for years (cf https://dirk.eddelbuettel.com/blog/2017/03/22/
from seven (!!) years
On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
|
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel
| | User: debian...@lists.debian.org
| | Usertags: regression
| |
| | Hi Maintainer
On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
|
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel
| | User: debian...@lists.debian.org
| | Usertags: regression
| |
| | Hi Maintainer
On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-mutationalpatterns' autopkgtest regresses when
On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-s4vectors' autopkgtest regresses when tested with r
On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-mutationalpatterns' autopkgtest regresses when
On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-s4vectors' autopkgtest regresses when tested with r
On 10 May 2024 at 10:58, Graham Inggs wrote:
| Source: r-bioc-iranges
| Version: 2.36.0-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
On 10 May 2024 at 10:58, Graham Inggs wrote:
| Source: r-bioc-iranges
| Version: 2.36.0-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1
On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1
Software Heritage (see [1] for their website and [2] for a brief intro I gave
at useR! 2019 in Toulouse) covers GitHub and CRAN [3]. It is by now 'in
collaboration with UNESCO', supported by a long and posh list of sponsors [4]
and about as good as it gets to 'ensure longevity of artifacts'.
It
On 9 May 2024 at 03:20, Sameh Abdulah wrote:
| I need to serialize and save a 20K x 20K matrix as a binary file.
Hm that is an incomplete specification: _what_ do you want to do with it?
Read it back in R? Share it with other languages (like Python) ? I.e. what
really is your use case? Also,
On 8 May 2024 at 11:02, Josiah Parry wrote:
| CRAN has rejected this package with:
|
| * Size of tarball: 18099770 bytes*
|
| *Please reudce to less than 5 MB for a CRAN package.*
Are you by chance confusing a NOTE (issued, but can be overruled) with a
WARNING (more severe, likely a
Package: r-cran-tmb
Version: 1.9.11-1
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
Package: r-cran-openmx
Version: 2.21.11+dfsg-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
Package: r-cran-irlba
Version: 2.3.5.1-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
On 30 April 2024 at 11:59, peter dalgaard wrote:
| svn diff -c 86235 ~/r-devel/R
Which is also available as
https://github.com/r-devel/r-svn/commit/f7c46500f455eb4edfc3656c3fa20af61b16abb7
Dirk
| (or 86238 for the port to the release branch) should be easily backported.
|
| (CC Luke in
The file 'issue_563_fread.txt' appears to be an input to data.table::fread()
for a test on encodings, glancing at the context.
I can run 'R CMD check --as-cran data.table_1.15.4.tar.gz' just fine [1] here
without any failing tests (and I have no locale or anything set). It's not my
package but
The package is pristine at CRAN
https://cran.r-project.org/web/checks/check_results_data.table.html
(apart from some new warnings several packages now get about interal R API
headers, nothing to do with tests)
Maybe you can sort this with upstream -- data.table is effectively holding up
On 30 April 2024 at 01:21, Rolf Turner wrote:
| On Mon, 29 Apr 2024 06:30:20 -0500
| Dirk Eddelbuettel wrote:
|
|
|
| > These days, I strongly recommend r2u [1]. As you already use R via
| > CRAN through apt, r2u adds one more repository after which _all_ R
| > packages are ha
Rolf,
This question might have been more appropriate for r-sig-debian than here.
But as Simon noted, the lack of detail makes is difficult to say anything to
aid. It likely was an issue local to your setup and use.
These days, I strongly recommend r2u [1]. As you already use R via CRAN
Package: r-cran-data.table
Version: 1.14.10+dfsg-1
Severity: normal
data.table had a release 1.15.0 in January -- the first new one in three
years! -- and two follow-ups since bringing it 1.15.4 at CRAN.
Please update the Debian package to the current upstream version.
This should likely
On 27 April 2024 at 10:53, 신선영(수학과) via ESS-help wrote:
| Dear all,
|
| I get the following error message:
|
| make -C lisp all
| make[1]: Entering directory '/home/mathi/ess-24.01.1/lisp'
| test -f ../etc/.IS.RELEASE || wget -qO -
reassign 1069842 r-base
thanks
On 25 April 2024 at 18:27, Santiago Vila wrote:
| Package: src:rjava
| Version: 1.0-11-1
| Severity: serious
| Tags: ftbfs
|
| Dear maintainer:
|
| During a rebuild of all packages in unstable, your package failed to build:
Thanks for this. It is caused by the
reassign 1069842 r-base
thanks
On 25 April 2024 at 18:27, Santiago Vila wrote:
| Package: src:rjava
| Version: 1.0-11-1
| Severity: serious
| Tags: ftbfs
|
| Dear maintainer:
|
| During a rebuild of all packages in unstable, your package failed to build:
Thanks for this. It is caused by the
Hi Kurt,
On 25 April 2024 at 08:07, Kurt Hornik wrote:
| > Hervé Pagès writes:
|
| > Hi Kurt,
| > Is it intended that numeric_version() returns an error by default on
| > non-character input in R 4.4.0?
|
| Dear Herve, yes, that's the intention.
|
| > It seems that I can turn this into
On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote:
| On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote:
| > R upstream no longer releases or tests for 32 bits (and has not since the R
| > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the
| > release team
Hi Graham, Hi Release Team,
On 21 April 2024 at 13:37, Graham Inggs wrote:
| On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote:
| > Right now it now only shows 'all reports (re-)running'.
|
| That was because of the new upload, but I see the results there now.
|
| The packa
Hi Paul,
On 18 April 2024 at 11:50, Paul Gevers wrote:
| Hi Dirk,
|
| On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote:
| > I uploaded a first
| > beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just
| > followed up with a rc release r-base_4.3.3.20240416-1.
|
R 4.4.0 will be released on April 24 (following the long established pattern
of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc)
have been made available for four weeks leading up to it. I uploaded a first
beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago,
R 4.4.0 will be released on April 24 (following the long established pattern
of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc)
have been made available for four weeks leading up to it. I uploaded a first
beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago,
As an aside, the odd format does not seem to bother data.table::fread() which
also happens to be my personally preferred workhorse for these tasks:
> fname <- "/tmp/r/filename.csv"
> read.csv(fname)
Gene SNP prot log10p
1 YWHAE 13:62129097_C_T 1433 7.35
2 YWHAE 4:72617557_T_TA
On 16 April 2024 at 10:46, jing hua zhao wrote:
| Dear R-developers,
|
| I came to a somewhat unexpected behaviour of read.csv() which is trivial but
worthwhile to note -- my data involves a protein named "1433E" but to save
space I drop the quote so it becomes,
|
| Gene,SNP,prot,log10p
|
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 8 April 2024 at 18:21, Lucas Thode wrote:
| Apologies for the confusion, I didn't realize the patch in question was a new
| addition. Just confirmed that it errors out instead of segfaulting or
hanging.
Thanks for confirming!
Dirk
| On Sat, Apr 6, 2024 at 5:32 PM Dirk Eddelbuettel
Hi Lucas,
As Milan suggested, please sure you are current. If in doubt, park you
current checkout and start from
git checkout https://github.com/eddelbuettel/dieharder.git
where you should see today's commit from merging PR 24.
edd@rob:~/git/dieharder(master)$ git ls | head
*
Hi Lucas,
On 30 March 2024 at 22:47, Lucas Thode wrote:
| Package: dieharder
| Version: 3.31.1.4-1.1
| Severity: normal
| X-Debbugs-Cc: thode...@gmail.com
|
| Dear Maintainer,
|
| `dieharder -d 209 -n $nvalue` crashes for $nvalue>17:
|
| $ dieharder -d 209
|
On 2 April 2024 at 09:41, Duncan Murdoch wrote:
| On 02/04/2024 8:50 a.m., Dirk Eddelbuettel wrote:
| > On 2 April 2024 at 07:37, Dirk Eddelbuettel wrote:
| > blosxom, simple as it is, takes (IIRC) filesystem ctime as the posting
| > timestamp so would be best if you had a backup wit
On 2 April 2024 at 07:37, Dirk Eddelbuettel wrote:
|
| On 2 April 2024 at 08:21, Duncan Murdoch wrote:
| | I have just added R-4-4-branch to the feeds. I think I've also fixed
| | the \I issue, so today's news includes a long list of old changes.
|
| These feeds can fussy: looks like you
On 2 April 2024 at 08:21, Duncan Murdoch wrote:
| I have just added R-4-4-branch to the feeds. I think I've also fixed
| the \I issue, so today's news includes a long list of old changes.
These feeds can fussy: looks like you triggered many updates. Feedly
currently greets me with 569 new
On 1 April 2024 at 17:44, Uwe Ligges wrote:
| Untested:
|
| install.packages() calls available.packages() to find out which packages
| are available - and passes a "filters" argument if supplied.
| That can be a user defined filter. It should be possible to write a user
| defined filter which
On 31 March 2024 at 11:43, Martin Morgan wrote:
| So all repositories are consulted and then the result filtered to contain just
| the most recent version of each. Does it matter then what order the
| repositories are visited?
Right. I fall for that too often, as I did here. The order matters
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Greg,
There are AFAICT two issues here: how R unrolls the named vector that is the
'repos' element in the list 'options', and how your computer resolves DNS for
localhost vs 172.17.0.1. I would try something like
options(repos = c(CRAN = "http://localhost:3001/proxy;,
On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
| Dear all,
|
| I have a question regarding the R-devel version of .make_numeric_version()
function. As far as I can understand, the current code
Marco,
It usually helps to be aware of one's hardware platform ;-)
There is an option for Docker command to tell it to switch to x86_64, my
colleagues who are on M1 and alike use that to access the generally richer
eco-system of binaries for the Intel world. If on the other hand you prefer
to
: https://github.com/google/highway
docs: https://google.github.io/highway/en/master/
|
| Op di 26 mrt 2024 om 15:41 schreef Dirk Eddelbuettel :
| >
| >
| > On 26 March 2024 at 10:53, jesse koops wrote:
| > | How can I make this portable and CRAN-acceptable?
| >
| > But wri
On 27 March 2024 at 11:03, Prof Brian Ripley via R-devel wrote:
| On 27/03/2024 10:28, Alexandre Courtiol wrote:
| > Hi all,
| >
| > I don't know if it is a local issue on my hands or not, but after
| > installing R-devel the output of grDevices::dev.capabilities()$paths is
| > FALSE, while it
On 26 March 2024 at 09:37, Dirk Eddelbuettel wrote:
|
| Avi,
|
| That was a hickup and is now taken care of. When discussing this (off-line)
| with Jeroen we (rightly) suggested that keeping an eye on
Typo, as usual, "he (rightly) suggested". My bad.
D.
|
|https://con
On 26 March 2024 at 10:53, jesse koops wrote:
| How can I make this portable and CRAN-acceptable?
But writing (or borrowing ?) some hardware detection via either configure /
autoconf or cmake. This is no different than other tasks decided at
install-time.
Start with 'Writing R Extensions', as
Avi,
That was a hickup and is now taken care of. When discussing this (off-line)
with Jeroen we (rightly) suggested that keeping an eye on
https://contributor.r-project.org/svn-dashboard/
is one possibility to keep track while we have no status alert system from
CRAN. I too was quite
On 25 March 2024 at 11:12, Jairo Hidalgo Migueles wrote:
| I'm reaching out to seek some guidance regarding the storage of relatively
| large data, ranging from 10-40 MB, intended for use within an R package.
| Specifically, this data consists of regression and random forest models
| crucial for
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary
On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| A couple of days ago, the (effective) Maintainer and rather active developer
| of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
| (the primary list for R package development) that the upcoming change
1 - 100 of 16012 matches
Mail list logo
