On 20 October 2021 at 09:31, Sebastian Meyer wrote:
| If you set the environment variable inside a running R process, it will
| only affect that process and child processes, but not an independent R
| process launched from a shell like you seem to be doing here:
Yes. That is somewhat common,
On 16 October 2021 at 17:50, Sebastian Ramacher wrote:
| On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
| >
| > On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > Turns out this was fu
On 16 October 2021 at 17:50, Sebastian Ramacher wrote:
| On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
| >
| > On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > Turns out this was fu
On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| >
| > Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
| > and I didn't use that.
|
| No, it doesn't. gsl 2.7 has current=26 and age=1
On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| >
| > Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
| > and I didn't use that.
|
| No, it doesn't. gsl 2.7 has current=26 and age=1
Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
and I didn't use that.
So a new package will be forthcoming, and likely need a transition. That
means I should upload to experimental first, right, to then request the
transition? (I'll read up on it later today as a
Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
and I didn't use that.
So a new package will be forthcoming, and likely need a transition. That
means I should upload to experimental first, right, to then request the
transition? (I'll read up on it later today as a
Graham,
On 15 October 2021 at 13:34, Graham Inggs wrote:
| > Yes. And I follow upstream. They didn't change :-/
|
| Right, so please speak to your upstream. Dropping (or renaming) a
Done.
Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there
and we get to do (yet
Graham,
On 15 October 2021 at 13:34, Graham Inggs wrote:
| > Yes. And I follow upstream. They didn't change :-/
|
| Right, so please speak to your upstream. Dropping (or renaming) a
Done.
Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there
and we get to do (yet
On 14 October 2021 at 23:20, Sebastian Ramacher wrote:
| On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
| >
| > Hi Sebastian,
| >
| > On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| > | Hi Dirk
| > |
| > | On 2021-08-30 16:27:49 -0500, Di
On 14 October 2021 at 23:20, Sebastian Ramacher wrote:
| On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
| >
| > Hi Sebastian,
| >
| > On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| > | Hi Dirk
| > |
| > | On 2021-08-30 16:27:49 -0500, Di
Hi Sebastian,
On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| Hi Dirk
|
| On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| >
| > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | Package: libgsl25
| > | Version: 2.7+dfsg-2
| > | Control: affects -1 l
Hi Sebastian,
On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| Hi Dirk
|
| On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| >
| > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | Package: libgsl25
| > | Version: 2.7+dfsg-2
| > | Control: affects -1 l
On 14 October 2021 at 10:55, Paul Gevers wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: serious
| Control: close -1 2.7+dfsg-2
| Tags: sid bookworm
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
On 14 October 2021 at 10:55, Paul Gevers wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: serious
| Control: close -1 2.7+dfsg-2
| Tags: sid bookworm
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
Severity: normal
Package: its
The its package was retired from CRAN five years ago [1] upon the request of
its original author (who is a friend), but I kept it in Debian because it was
generally useful. However, as time and packaging standards move on (while the
package remains frozen) it is
On 9 October 2021 at 12:08, Ben Bolker wrote:
|FWIW there is some machinery in the glmmTMB package for querying,
| setting, etc. the number of OpenMP threads.
|
| https://github.com/glmmTMB/glmmTMB/search?q=omp
https://cloud.r-project.org/package=RhpcBLASctl
Dirk
--
A new r-cran-rgtk2 build has been uploaded which no longer builds on s390x by
default, so closing the bug report.
If someone from the s390 team wants to try just add the arch to the
Architecture line in debian/control.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Howdy,
Somone (on r-help which I don't really follow for lack of time) called [3]
this a 'quasi-FAQ':
This problem is pratically a StackOverflow FAQ [1], with link to the
Rcpp-devel mailing list [2].
[1]
On 22 September 2021 at 15:15, Lionel Henry wrote:
| We'd love to do a release but ESS is not in a good place right now.
| Recent versions of Emacs interrupt background commands (essential to
| completion and contextual help like eldoc) when the user starts
| typing, which causes hard to solve
On 20 September 2021 at 13:59, Sparapani, Rodney via ESS-help wrote:
| Generally, this stuff should just work out-of-the-box.
Understood.
| And we are not a company like RStudio so this FOSS setup works for us as
| developers and hopefully it still serves the users well.
But legal structure
On 20 September 2021 at 13:59, Sparapani, Rodney via ESS-help wrote:
| Over the last few years, we have moved away from having to set up features
| with .emacs/etc. as much as possible. Generally, this stuff should just
| work out-of-the-box.
I completely concur and _love it_.
I mostly just
On 20 September 2021 at 07:50, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 03:45:57PM -0500, Dirk Eddelbuettel wrote:
| >
| > | I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
| >
| > I had a similar thought. I am also f
On 20 September 2021 at 07:50, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 03:45:57PM -0500, Dirk Eddelbuettel wrote:
| >
| > | I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
| >
| > I had a similar thought. I am also f
On 19 September 2021 at 16:09, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 05:31:14PM +0530, Nilesh Patra wrote:
| >
| > But I do wonder if more packages in future might as well end up needing
basilisk too.
|
| I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
I had a
On 19 September 2021 at 16:09, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 05:31:14PM +0530, Nilesh Patra wrote:
| >
| > But I do wonder if more packages in future might as well end up needing
basilisk too.
|
| I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
I had a
Chris,
I don't have great advice.
I have been doing this in Emacs with ESS (and friends like polymode) 'for
years' and it mostly worked. So thumbs up -- it worth doing and I prefer
doing it in Emacs. Polymode is actually rather cool.
The world being what it is these days, the predictable
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
Also: No other R packages here. Maybe something off with gtk2?
Build-Depends: debhelper (>= 10), dh-r (>= 20180615), \
r-base-dev (>= 3.6.1), libgtk2.0-dev (>= 2.10.12), \
libglade2-dev, libpango1.0-dev, libcairo2-dev
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel |
Also: No other R packages here. Maybe something off with gtk2?
Build-Depends: debhelper (>= 10), dh-r (>= 20180615), \
r-base-dev (>= 3.6.1), libgtk2.0-dev (>= 2.10.12), \
libglade2-dev, libpango1.0-dev, libcairo2-dev
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel |
On 6 September 2021 at 00:46, Simon McVittie wrote:
| Source: rgtk2
| Version: 2.20.36-2
| Severity: serious
| Tags: ftbfs bookworm sid
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: debian-s...@lists.debian.org
| User:
On 6 September 2021 at 00:46, Simon McVittie wrote:
| Source: rgtk2
| Version: 2.20.36-2
| Severity: serious
| Tags: ftbfs bookworm sid
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: debian-s...@lists.debian.org
| User:
Rolf,
Glad you're sorted out, and I concur in the thanks to Ivan (and Johannes and
other who patiently helped).
To me, the take-away message is that /usr/local wins generally, not just in
your $PATH (or, say, in R's library path) but also for configure and friends
so ... it opens the door for
On 31 August 2021 at 15:36, Andreas Tille wrote:
| I think cheating with different Debian versions is one thing but IMHO
| the versions inside the package (I mean Debian package version and the
| version inside DESCRIPTION) should match no matter what actual libboost
| version is in Debian.
s
(reply to Dirk Eddelbuettel ).
| [...]
| > -BEGIN PGP SIGNED MESSAGE-
| > Hash: SHA256
| >
| > Format: 1.8
| > Date: Tue, 31 Aug 2021 06:40:29 -0500
| > Source: r-cran-bh
| > Architecture: source
| > Version: 1.74.0-2
| > Distribution: unstable
| > Urgency: mediu
-12
| Author: Dirk Eddelbuettel, John W. Emerson and Michael J. Kane
| Maintainer: Dirk Eddelbuettel
| --- a/debian/control
| +++ b/debian/control
| @@ -11,7 +11,7 @@ Homepage: https://cran.r-project.org/package=BH
| Package: r-cran-bh
| Architecture: all
| Multi-Arch: foreign
| -Depe
On 30 August 2021 at 23:42, Niko Tyni wrote:
| Package: libgsl25
| Version: 2.7+dfsg-2
| Control: affects -1 libmath-gsl-perl
| Severity: serious
|
| gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest
regressions:
|
|not ok 7 - use Math::GSL::Matrix;
|
|#
On 30 August 2021 at 23:42, Niko Tyni wrote:
| Package: libgsl25
| Version: 2.7+dfsg-2
| Control: affects -1 libmath-gsl-perl
| Severity: serious
|
| gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest
regressions:
|
|not ok 7 - use Math::GSL::Matrix;
|
|#
On 29 August 2021 at 08:06, Michael Mahoney wrote:
| Forgive me if I'm missing something here, but do you need to install
| from source or do you just need R 4.1.0?
|
| If the latter, my understanding is that you should be able to get R
| version 4.1.0 on Ubuntu distributions via:
An even
Rolf,
I am truly sorry but I am getting lost in your original message. Could you
follow-up and describe (concisely, if possible) what your question is? Is it
- installing 4.1.1 or 4.1.0
- developing a package of yours
- installing a package ?
You seem to interweave a few strands in ways
Rolf,
Asking here is the Right Thing (TM) but I am in at this moment between two
differen things (one of them being dinner...) so I have to come back to this
but regarding
> Package libcurl-dev is a virtual package provided by:
> libcurl4-openssl-dev 7.68.0-1ubuntu2.6
> libcurl4-nss-dev
On 27 August 2021 at 20:48, William Denton via ESS-help wrote:
| Let's say I enter the following keystrokes:
|
| 1 + 1 RET M-p C-a
|
| This adds 1+1, gets the result, then runs comint-previous-input and reenters
the
| previous command. C-a moves to the start of the line ... but puts the
While we generally get an email about these things, CRAN appears to have
closed shop for a week to take a well deserved break until September 1.
Or so the message says---the hourly CRANberriesFeed cron job saw packages
being processed, but that too is not uncommon when the queues get cleared.
As I type this, we are eight messages into this thread -- but I am not sure
it has been made clear what the actual contentious issues are.
There appear to be two toolchains, and they appear to be interoperate (though
Duncan stated he had issues with an (arguably demanding) package). Now, I
On 19 August 2021 at 10:04, Naeem Khoshnevis wrote:
| Thank you so much, everyone, for responding to this email.
Thanks for circling back! This was a pretty impressive thread as you got
three distinct answers that all added some value :)
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel
Naeem,
I would simplify, simplify, simplify -- as 'Rcpp FAQ 7.31' reminds us all,
testing _equality_ of doubles is challenging anyway.
Besides, it may make sense to would ascertain first you get what you want in
_purely serial modes_ and then move to OpenMP.
Dirk
--
On 18 August 2021 at 16:36, Simon Zehnder wrote:
| I am using R 4.0.5 on a Fedora 34 System, Rcpp 1.0.6 and nloptr 1.2.2.2.
Works here (Ubuntu 21.04, Rcpp 1.0.7) (see [1] below)
Works at CRAN (see [2] below)
Works at universe (see [3] below)
I would suspect the error is at your end.
Dirk
On 18 August 2021 at 01:26, Dillon Hammill wrote:
| Thanks for your help Dirk, I think I have everything I need to get things
working now. I just needed a push in the right direction to discover wrap and
as from Rcpp - they are awesome!
They are indeed. (And, if I may, feature prominently in
On 17 August 2021 at 19:19, Dillon Hammill wrote:
| What is the easiest way to perform this conversion (say for vector to RVector
or vector of vectors to matrix)?
I always find that the existing RcppParallel that JJ and Kevin set up years
ago excels there. Study them, they do it right, they
Dillon,
The point of RMatrix and RVector in RcppParallel is to shield objects inside
the RcppParallel blocks using Intel TBB from any interaction with the outer R
process which may, or may not, run a gc() to rearrange its memory.
Where they work, you should not use Rcpp's own NumericMatrix and
Dario,
On 14 August 2021 at 00:00, Dario Strbenac via R-devel wrote:
| Good day,
|
| Ah, I was confident it wouldn't be environment-specific but it is. My
environment is
|
| R version 4.1.0 (2021-05-18)
| Platform: x86_64-pc-linux-gnu (64-bit)
| Running under: Debian GNU/Linux 10 (buster)
|
On 12 August 2021 at 15:19, Andrew Piskorski wrote:
| Ok, but what's the recommended way to actually USE Rprofile.site now?
| Should I move all my local configuration into a special package, and
| do nothing in Rprofile.site except require() that package?
Exactly as before. I set my mirror as I
(I replied earlier but that seems to have gotten lost. Apologies to anybody
who may receive two copies, and thanks to Simon for his answer. -- Dirk)
On 9 August 2021 at 17:04, Naeem Khoshnevis wrote:
| Do you know a workaround for this issue?
Wrap the #include by #ifdef _OPENMP and #endif
Rolf,
Sorry for only briefly chiming in, and late, but I don't usually follow
r-help that much these days.
I am writing this from an Ubuntu machine running R as well as RStudio from
pre-made binary .deb packages. R comes via apt from CRAN (using Michael's
binaries), RStudio from them via
If look closely enough at _Writing R Extensions_ you notice that it mentions
'configure.win' over half a dozen times. A powerful trick is to then use the
fact that there are other packages on CRAN, in fact almost 18k of them.
And e.g. this search
On 3 August 2021 at 09:35, Enrico Schumann wrote:
| More wild guesses:
|
| - maybe some Emacs minor mode does it? Any
| configuration for gtags-mode?
I use it (via elpa).
But I grep'ed and an ag'ed at length for anything related.
| - do you happen to use an Emacs package named ggtags
|
On 2 August 2021 at 21:20, Tyler Smith via ESS-help wrote:
| Can you reproduce the problem after starting Emacs via `emacs -Q`? That would
confirm the problem is not in your Emacs config. Or confirm that it is, if the
problem isn't reproduced.
Can confirm. With emacs -Q nothing happens to
On 2 August 2021 at 17:20, Dirk Eddelbuettel via ESS-help wrote:
|
| On 2 August 2021 at 23:56, Stephen Berman wrote:
| | Did you also try the more direct alternative of grepping simply for
| | "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function update
On 2 August 2021 at 23:56, Stephen Berman wrote:
| Did you also try the more direct alternative of grepping simply for
| "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function updates these
| files has to refer to them, either directly by name or indirectly by a
| variable or function that in
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-vroom
Version : 1.5.3
Upstream Author : James Hester and Hadley Wickham
* URL or Web page : https://cran.r-project.org/package=vroom
* License : MIT
Description : GNU R package
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-vroom
Version : 1.5.3
Upstream Author : James Hester and Hadley Wickham
* URL or Web page : https://cran.r-project.org/package=vroom
* License : MIT
Description : GNU R package
On 30 July 2021 at 21:32, Andreas Leha via ESS-help wrote:
| wild guess: file/dir local variable?
I considered that too esp as I see it only in some repos. But no repo-local
file I can see or tell (and I know repo layout / files well enough).
On 30 July 2021 at 17:27, Tyler Smith via ESS-help
Section 2.7.3 'C++ Support' of the R Admin manual says, "C++ is not used by R
itself, but support is provided ...". This is all stored from when R itself
is configure (prior to compiling) and override-able in package configuration
(Section 2.7.3 covers that) but as that in other places _it all
tl;dr: I enabled an action 'on save' and I no longer find where :-/
Longer story: I settled upon GNU global and ggtags at some point for a
(mostly multilingual) system of tags in R and C++ (and some more). So a few
of source directories have these (ugly names) files GPATH, GTAGS, GRTAGS.
And
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-tzdb
Version : 0.1.2
Upstream Author : Davis Vaughan
* URL or Web page : https://cran.r-project.org/package=tzdb
* License : MIT
Description : GNU R package for Time Zone Database
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-tzdb
Version : 0.1.2
Upstream Author : Davis Vaughan
* URL or Web page : https://cran.r-project.org/package=tzdb
* License : MIT
Description : GNU R package for Time Zone Database
On 24 July 2021 at 15:53, Steve Haroz wrote:
| I'd like to propose moving the default library install location on Windows
from:
| %USERPROFILE%/Documents/R
| to some other location such as:
| %USERPROFILE%/R
Can you not set .Library.site in R_HOME/etc/Rprofile.site (or maybe setting
Russell,
On 24 July 2021 at 12:04, Russell Almond wrote:
| I'm working on a package called RNetica which links to a 3rd party
| library: Netica. Netica is available in both static (libnetica.a) and
| shared (libnetica.so) version (also Netica.dll for windows, but that is
| a separate
Luben,
Adding to what Tyler kindly said:
On 23 July 2021 at 19:35, Tyler Smith wrote:
| libcurl and libcurl4-openssl-dev are Debian packages, not R packages. You can
install them from the command line (not R):
|
| sudo apt-get install libcurl4-openssl-dev
|
| Or use your package manager.
ter system / what is known in the _entire distribution_
which is very different from the build-a-package clean room.
| Package: r-cran-dbi
| Source: dbi
| Version: 1.0.0-2
| Installed-Size: 1931
| Maintainer: Dirk Eddelbuettel
| Architecture: all
| Depends: r-base-core (>= 3.5.0-3), r-api-3.5
Package: r-cran-knitr
Severity: normal
We have knitr 1.31 per
https://packages.debian.org/search?keywords=r-cran-knitr
but upstream is (since April) at 1.33 per
https://cran.r-project.org/package=knitr
which is now needed by e.g. rgl aka r-cran-rgl.
We are in a freeze, so I too have been
Hi Gennadiy,
On 20 July 2021 at 10:25, Gennadiy Starostin wrote:
| Thank you for your feedback. There was a misconfigured redirection
| indeed. It should work well now.
Fabulous, thanks as always.
| The top page does say "If you experience any problems or need help you
| can submit a
(Sorry for posting here but the top-level r-forge page does not make it all
that clear where to contact its admins.)
When an old-style 'http' URL at r-forge is resolved / redirected to 'https',
it is corrupted and the redirect breaks. That required a package re-upload
for me a few days ago (as
On 15 July 2021 at 15:44, Naeem Khoshnevis wrote:
| Thanks, Simon and Dirk,
|
| I can install the packages normally on macOS. However, I want to install it
| in a conda environment.
That is (for all intents and purposes) a different use case than what we
support (for free) so I suggest you rely
On 15 July 2021 at 14:41, Iñaki Ucar wrote:
| On Thu, 15 Jul 2021 at 10:27, ma wh wrote:
| > Error in C_valid_tz(tzone): Function 'Rcpp_precious_remove' not provided by
package 'Rcpp'
|
| TL;DR: update your library.
Good catch by Inaki. I had overlooked the C_valid_tz() handle. You are trying
On 15 July 2021 at 08:24, ma wh wrote:
| Colleague of mine wrote some R last week that was working OK, and hasn't been
changed in itself since that time. This week it's ceased working( I've tried it
on my machine and also see a fail, the following error is encountered:
|
| Error in
rstand why you do not recommend it. I will
| prepare a reproducible example and will let you know. Thank you so much.
Sounds good. Hopefully we get that squared away in a few controlled steps.
Dirk
| Best regards,
| Naeem
|
| On Wed, Jul 14, 2021 at 9:55 AM Dirk Eddelbuettel wrote:
|
| >
Hi Naeem,
On 14 July 2021 at 09:41, Naeem Khoshnevis wrote:
| Hi,
|
| I hope this email finds you well.
| I wondered what the best approaches to troubleshooting C++ dependencies
| issues in general and specifically in R are; specifically, those packages
| which are using OpenMP and we want to
On 8 July 2021 at 10:41, Uwe Ligges wrote:
| It was likely an interim version of Rcpp (which never made it to CRAN)
| that was causing trouble.
Yup, our bad.
While we test against 2300+ reverse depends, we only test against them _under
the most recent versions we have seen_ which affects the
Rcpp 1.0.7 is now on CRAN. As emailed here on Saturday, we actually needed
to make one change relative to how Modules code from earlier builds is
handled. (And with that I replaced the 1.0.7 version in the drat repo; if you
installed it earlier than today, and "experience symptoms", consider an
Rcpp 1.0.7 was uploaded to CRAN; it may take a few days to sort the release
out as it the weekend and as the number of reverse dependencies may throw up
an issue or two. In the mean time you can get the release from the usual
drat repo.
See the NEWS.Rd for a summary of changes. Thanks to
On 1 July 2021 at 20:00, Lluís Revilla wrote:
| I have a question related to changing maintainers.
| What happens when the old/current maintainer does not respond to
| emails or other methods of contact?
| Would the new maintainer need to wait until the package is removed
| from CRAN to submit
On 24 June 2021 at 16:31, Duncan Murdoch wrote:
| This does the full compile again, so it's slow.
ccache fixes that (as it has its own cache). It also works on macOS.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
Hi Greg,
On 24 June 2021 at 12:15, Greg Minshall wrote:
| when developing packages, my current work flow is to change the code,
| (re-)build the package, detach/load the package, test (to find the
| N+1'st bug, sigh).
|
| the building step takes tens of seconds.
You may benefit from looking
Hi there,
On 16 June 2021 at 13:52, Vagrant Cascadian wrote:
| Source: tclap
| Severity: normal
| Tags: patch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: buildpath usrmerge shell
| X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
|
| The build path, several binary
On 13 June 2021 at 11:40, Joseph Park wrote:
| Thank you.
|
| Changing the function argument limit to 20 variables resolves the error.
Excellent.
| If this limit can be relaxed, that would be helpful for future development.
For that to happen someone will have to sit down and do it.
|
On 12 June 2021 at 16:02, Kevin Ushey wrote:
| I think you're bumping into the 20 argument limit for our (now rather old)
| Vector::create() implementation. I thought we also had a variadic C++11
| version for this, but apparently I am mistaken...
Hm. We have a few header files that are
On 10 June 2021 at 09:22, J C Nash wrote:
| Thanks to help from Duncan Murdoch, we have extracted the nls() functionality
to a package nlspkg and are building
| an nlsalt package. We can then run nlspkg::AFunction() and
nlsalt::AFunction() in a single script to compare.
| This works great in
Hi Karl,
Thanks for circling back!
On 4 June 2021 at 17:00, Karl Dunkle Werner wrote:
| For anyone else who runs into this issue, you can do either of the
| following;
| (a) Remove the flags "-flto=auto" and "-ffat-lto-objects" from the
| CXX11FLAGS in your /etc/R/Makeconf
| (b) Set
On 4 June 2021 at 16:21, Balasubramanian Narasimhan wrote:
| Suggests" would trigger an attempt to install gurobi, which is not on CRAN.
To my understanding that is not the case. It would only do so if and when
install.packages() is asked to also install packages in Suggests:. And point
of
Hi Karl,
On 1 June 2021 at 19:12, Karl Dunkle Werner wrote:
| Thanks for the very helpful response!
Thanks for weaving the threads back together.
| Got it, and thank you for the offer! I can edit my Makeconf (everything
| works when I remove the LTO-related flags). I was hoping to make
|
Two more follow-ups if I may:
- the Debian and hence derived Ubuntu package of R 4.1.0 does *not* enable
LTO yet, in other words I have not yet add --enable-lto to the configure
call and we use to default of 'nope'
- my dev box is still 20.10; I only run 21.04 on one small machine where I
Hi Karl,
On 1 June 2021 at 22:22, Karl Dunkle Werner wrote:
| I noticed the Makeconf file that comes with the Ubuntu version of R 4.1.0
| has link-time optimization (LTO) flags enabled. For instance:
| CXX11FLAGS = -g -O2 -ffile-prefix-map=/build/r-base-aXXzqd/r-base-4.1.0=.
| -flto=auto
Danielle,
On 26 May 2021 at 21:23, Danielle Maeser wrote:
| Please excuse the very simple question, but I received the following
| message from a CRAN maintainer, and I am not sure what code to include
| inside of the \donttest{}. This is meant to enclose code that typically
| should be run,
801 - 900 of 15988 matches
Mail list logo
