Follow-up and 'case (sort of) closed': Tomas and I dug around some more and
it is due to me setting CC in ~/.R/Makevars (to
VER=-14
CCACHE=ccache
CC=$(CCACHE) gcc$(VER)
which drops the compilation standard flag (needed here for C23) and attached
to CC by configure.
I think that is actual
On 15 March 2025 at 09:49, Ivan Krylov wrote:
| On Fri, 14 Mar 2025 22:25:54 -0500
| Dirk Eddelbuettel wrote:
|
| > An older package I looked at apparently currently fails to build under
| > r-devel (and with that my thanks to R-universe for giving us a
| > 'broad' range of builds for free -- o
On Sat, 15 Mar 2025 07:51:11 -0500
Dirk Eddelbuettel wrote:
> /usr/local/lib/R-devel/lib/R/include/R_ext/Boolean.h:62:16: warning: ISO C
> does not support specifying ‘enum’ underlying types before C23 [-Wpedantic]
> 62 | typedef enum :int { FALSE = 0, TRUE } Rboolean; // so NOT NA
>
On Fri, 14 Mar 2025 22:25:54 -0500
Dirk Eddelbuettel wrote:
> An older package I looked at apparently currently fails to build under
> r-devel (and with that my thanks to R-universe for giving us a
> 'broad' range of builds for free -- off our development sources) over
> 'bool' related changes an
An older package I looked at apparently currently fails to build under
r-devel (and with that my thanks to R-universe for giving us a 'broad' range
of builds for free -- off our development sources) over 'bool' related
changes and enum definitions.
I can get it to behave and build by declaring
Am 09.03.25 um 18:15 schrieb Avraham Adler:
Hello.
I recently built a new computer and I am now using Windows 11. When
building a distribution of R-devel from source using the most recent
Rtools44, the build consistently fails at the point it is supposed to
build the vignettes from base with the
Thank you very much, Sebastian. Your suggestion about checking the
FAIL solved the problem. It reminded me that GCC 12+ has a bug
regarding AVX2 alignments on Windows, which manifests when calling
`agrep` or `adist`, the latter being precisely the point of failure in
the FAIL file. See this thread
Hello.
I recently built a new computer and I am now using Windows 11. When
building a distribution of R-devel from source using the most recent
Rtools44, the build consistently fails at the point it is supposed to
build the vignettes from base with the message below. R-4-4-branch
(also 87913) comp
To bring closure to this thread, everything is back to normal at both the CRAN
machine that balked as well as at windows r-devel.
Thanks, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://
> Dirk Eddelbuettel
> on Thu, 13 Jun 2024 07:20:00 -0500 writes:
> I had a very routine CI job fail twice this morning on r-devel on Windows;
> the package (in fine standard form) doesn't even install under win-builder
> r-devel. Whereas on Linux with r86731 everything is
On 13 June 2024 at 15:26, Martin Maechler wrote:
| > Dirk Eddelbuettel
| > on Thu, 13 Jun 2024 07:20:00 -0500 writes:
|
| > I had a very routine CI job fail twice this morning on r-devel on
Windows;
| > the package (in fine standard form) doesn't even install under
win-bui
I had a very routine CI job fail twice this morning on r-devel on Windows;
the package (in fine standard form) doesn't even install under win-builder
r-devel. Whereas on Linux with r86731 everything is peachy.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Two quite related and recent threads on R-devel:
[1] proposal for WRE: clarify that use of S4 classes implies use of superclasses
https://stat.ethz.ch/pipermail/r-devel/2023-July/082739.html
[2] Should package version requirements assume installation from sources?
https://stat.ethz.ch/pipermail/r
I think this was possibly a typo (ALL_FCLAGS vs ALL_FCFLAGS), plus
those flags were never set for src/modules/lapack. Hence, this seems
like a better fix, that also adds the flags to src/extra/blas.
Best,
Gabor
diff --git a/src/extra/blas/Makefile.in b/src/extra/blas/Makefile.in
index 3661416..c9
More precisely the built-in Lapack module. AFAICT this is because the
f90 files are not compiled with -fpic. My output:
make[4]: Entering directory '/tmp/R-devel/src/modules/lapack'
gfortran -fpic -g -O2 -msse2 -mfpmath=sse -c dlamch.f -o dlamch.o
gfortran -fpic -g -O2 -c dlapack.f -o dlapack
I've moved this to https://bugs.r-project.org/show_bug.cgi?id=18443.
/Henrik
On Wed, Nov 30, 2022 at 2:03 PM Henrik Bengtsson
wrote:
>
> BACKGROUND:
>
> In recent versions of R-devel, sessionInfo() has a 'tzone' element, e.g.
>
> > sessionInfo()$tzone
> [1] "America/Los_Angeles"
>
>
> ISSUE:
>
>
BACKGROUND:
In recent versions of R-devel, sessionInfo() has a 'tzone' element, e.g.
> sessionInfo()$tzone
[1] "America/Los_Angeles"
ISSUE:
Some time zones, like the one above, has an underscore. This
underscore is *not* escaped by utils:::toLatex.sessionInfo, e.g.
$ TZ="America/Los_Angeles"
Hello.
Building 83314 on R using R-tools I get the following failure which
relates to lines 463--470 in the datetime3.R test:
```
> ifi3 <- is.finite(dctm3)
> stopifnot(exprs = {
+ all.equal(dD, dDc, tolerance = 1e-4)
+ (dDm3 - dDcm3)[ifi3] %in% 0:1
+ (dD - dDc )[ifi] %in% 0:1
+
On 7/18/22 19:14, Avraham Adler wrote:
Hello.
According to my understanding of the changes in R-devel, the flag
-fno-optimize-sibling-calls should no longer be forced when compiling
R. Yet, as I compile R, revision 82603, from source on Windows
(Skylake-X server) I see the flag being passed (e
On 4 May 2022 at 11:32, Martin Maechler wrote:
| I'm really sorry for this experience.
Stuff happens -- thanks for fixing it.
The weekly build for the rocker/drd container of r-devel (and r-patched)
worked fine now that you restored the mirror, so big thanks!
Dirk
--
dirk.eddelbuettel.com |
FWIW, the tarballs in
https://cran.r-project.org/src/base-prerelease/
seem ok at this point.
(We usually prefer that you use one of the two tarball sources over svn/git
because "make dist" issues otherwise can go unnoticed.)
-pd
> On 3 May 2022, at 13:54 , Dirk Eddelbuettel wrote:
>
>
>
Dear Martin as our trusted ETH point person,
I have some automated builders fall over as the tarball of R-devel is
currently empty:
edd@rob:/tmp$ wget https://stat.ethz.ch/R/daily/R-devel.tar.bz2
--2022-05-03 06:52:20-- https://stat.ethz.ch/R/daily/R-devel.tar.bz2
Resolving stat.ethz.ch (stat
On Wed, 30 Mar 2022 17:45:15 +
Georgi Boshnakov wrote:
> I am surprised that the above macro ever worked as intended.
I'm sorry, somehow I didn't pay enough attention when preparing that
part of the e-mail. The actual macro uses tools::toRd(bibentry(...)).
> I don't know if something was fi
Hi,
in R 4.1.2 we have:
> x <- structure(as.list(1:2), dim = c(1,2))
> x
[,1] [,2]
[1,] 12
> as.vector(x, mode = "list")
[,1] [,2]
[1,] 12
whereas in recent versions of R-devel (4.2.0) we have:
> x <- structure(as.list(1:2), dim = c(1,2))
> x
[,1] [,2]
[1,] 12
> as.ve
On Wed, Nov 24, 2021 at 11:45 AM Martin Maechler
wrote:
>
> > Avraham Adler on Thu, 18 Nov 2021 02:18:54 + writes:
>
> > Hello. I have isolated the issue: it is the
> > fused-multiply-add instruction set (FMA on Intel
> > processors). Running -march=skylake -mno-fma not only
> Avraham Adler on Thu, 18 Nov 2021 02:18:54 + writes:
> Hello. I have isolated the issue: it is the
> fused-multiply-add instruction set (FMA on Intel
> processors). Running -march=skylake -mno-fma not only does
> not hang, but passes make check-all (using R's native
Hello.
I have isolated the issue: it is the fused-multiply-add instruction
set (FMA on Intel processors). Running -march=skylake -mno-fma not
only does not hang, but passes make check-all (using R's native BLAS).
My intuition remains that something in the new more precise ebd0 code
used in dpois_r
Hello, Martin et. al.
I apologize for top posting, but I believe I have tracked down the
difference why last time my build worked and now it hangs on
`dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1)`. and it's NOT the
BLAS. I built against both 3.15 AND R's vanilla and it hung both
times. The issue
On Tue, Nov 16, 2021 at 10:42 PM Kevin Ushey wrote:
>
> Do you see this same hang in a build of R with debug symbols? Can you
> try running R with GDB, or even WinDbg or another debugger, to see
> what the call stack looks like when the hang occurs? Does the hang
> depend on the number of threads
Do you see this same hang in a build of R with debug symbols? Can you
try running R with GDB, or even WinDbg or another debugger, to see
what the call stack looks like when the hang occurs? Does the hang
depend on the number of threads used by OpenBLAS?
On the off chance it's relevant, I've seen h
On Tue, Nov 16, 2021 at 8:43 AM Martin Maechler
wrote:
>
> > Avraham Adler
> > on Tue, 16 Nov 2021 02:35:56 + writes:
>
> > I am building r-devel on Windows 10 64bit using Jeroen's mingw system,
> > and I am finding that my make check-devel hangs on the above issue.
> >
> Avraham Adler
> on Tue, 16 Nov 2021 02:35:56 + writes:
> I am building r-devel on Windows 10 64bit using Jeroen's mingw system,
> and I am finding that my make check-devel hangs on the above issue.
> Everything is vanila except that I am using OpenBLAS 0.3.18. I have
I am building r-devel on Windows 10 64bit using Jeroen's mingw system,
and I am finding that my make check-devel hangs on the above issue.
Everything is vanila except that I am using OpenBLAS 0.3.18. I have
been using OpenBLAS for over a decade and have not had this issue
before. Is there anything
Thanks for confirming and giving details on the rationale (... and
I'll updated R.utils to use format() instead).
Regarding as.character(x)[j] === as.character(x[j]): I agree with this
- is that property of as.character()/subsetting explicitly
stated/documented somewhere? I wonder if this is a pr
> Henrik Bengtsson
> on Wed, 22 Sep 2021 20:48:05 -0700 writes:
> The update in rev 80946
>
(https://github.com/wch/r-source/commit/d970867722e14811e8ba6b0ba8e0f478ff482f5e)
> caused as.character() on hexmode objects to no longer pads with zeros.
Yes -- very much on purp
The update in rev 80946
(https://github.com/wch/r-source/commit/d970867722e14811e8ba6b0ba8e0f478ff482f5e)
caused as.character() on hexmode objects to no longer pads with zeros.
Before:
> x <- structure(as.integer(c(0,8,16,24,32)), class="hexmode")
> x
[1] "00" "08" "10" "18" "20"
> as.character(x
> Jan Gorecki
> on Mon, 10 May 2021 12:42:09 +0200 writes:
> Hi R-devs,
> R 4.0.5 gives no warning. Is it expected? Searching the news for "I("
> doesn't give any info. Thanks
> z = I(getClass("MethodDefinition"))
Now what exactly did you intend with the above line ?
Hi R-devs,
R 4.0.5 gives no warning. Is it expected? Searching the news for "I("
doesn't give any info. Thanks
z = I(getClass("MethodDefinition"))
Warning message:
In `class<-`(x, unique.default(c("AsIs", oldClass(x :
Setting class(x) to multiple strings ("AsIs", "classRepresentation",
...);
On 3/11/21 4:21 PM, Dirk Eddelbuettel wrote:
I saw two (unchanged, long-existing) tests of main fail narrowly on this new
platform (relative to the tolerance argument set).
Thanks for already looking at the results. I'd be happy to have a look
if you point me to the example.
Attempting to chang
I saw two (unchanged, long-existing) tests of main fail narrowly on this new
platform (relative to the tolerance argument set).
Attempting to change the tolerance if .Platform$OS.type == "windows" failed
(any idea why that test would evaluate to FALSE?). Could it be that
capabilities("long.doub
On 18/12/2020 13:39, Gábor Csárdi wrote:
FYI.
tolower, toupper and chartr with non-native chars is work in progress.
(They were getting things wrong in a platform-dependent way, and it
seems the replacement code is also flaky, if in general better than what
went before.)
sessionInfo()
FYI.
> sessionInfo()
R Under development (unstable) (2020-12-17 r79645)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux bullseye/sid
Matrix products: default
BLAS: /opt/R-devel/lib/R/lib/libRblas.so
LAPACK: /opt/R-devel/lib/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US
> Jan Gorecki
> on Tue, 30 Jun 2020 11:29:24 +0100 writes:
> No packages are being loaded, or even installed.
> Did you try running the example on R-devel built with flags I have
> provided in this email?
> I checked now and it is required to use --enable-strict-barri
No packages are being loaded, or even installed.
Did you try running the example on R-devel built with flags I have
provided in this email?
I checked now and it is required to use --enable-strict-barrier to
reproduce the issue.
On Tue, Jun 30, 2020 at 9:02 AM Martin Maechler
wrote:
>
> > Kurt
On Tue, Jun 30, 2020 at 1:32 PM Martin Maechler
wrote:
>
> > Kurt Hornik
> > on Tue, 30 Jun 2020 06:20:57 +0200 writes:
>
> > Jan Gorecki writes:
> >> Thank you both, You are absolutely correct that example
> >> should be minimal, so here it is.
>
> >> l = list(a=new.en
> Kurt Hornik
> on Tue, 30 Jun 2020 06:20:57 +0200 writes:
> Jan Gorecki writes:
>> Thank you both, You are absolutely correct that example
>> should be minimal, so here it is.
>> l = list(a=new.env(), b=new.env()) unique(l)
>> Just for completeness, env_list dur
> Jan Gorecki writes:
> Thank you both,
> You are absolutely correct that example should be minimal, so here it is.
> l = list(a=new.env(), b=new.env())
> unique(l)
> Just for completeness, env_list during check that raises error
> env_list <- list(baseenv(),
> as.environment("package:gra
Thank you both,
You are absolutely correct that example should be minimal, so here it is.
l = list(a=new.env(), b=new.env())
unique(l)
Just for completeness, env_list during check that raises error
env_list <- list(baseenv(),
as.environment("package:graphics"),
as.environment("package:stats"
> Kurt Hornik
> on Mon, 29 Jun 2020 16:13:03 +0200 writes:
> Jan Gorecki writes:
>> So the unique.default is from the R tools package during
>> checks. I don't see those issues on CRAN checks.
> I cannot reproduce this locally (and have no clues about
> docker).
> Jan Gorecki writes:
> So the unique.default is from the R tools package during checks.
> I don't see those issues on CRAN checks.
I cannot reproduce this locally (and have no clues about docker).
Perhaps you can try to debug this on your end? And see what env_list is
when the error occurs?
So the unique.default is from the R tools package during checks.
I don't see those issues on CRAN checks.
Exact environment where I am reproducing this issue is a fresh ubuntu,
no R packages pre-installed
docker pull registry.gitlab.com/jangorecki/dockerfiles/r-devel
https://gitlab.com/jangorecki/d
Hi R developers,
On R-devel (2020-06-24 r78746) I am getting those two new exceptions
during R check. I found a change which eventually may be related
https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465
I think this may be a regression. I grep'ed package manuals and R c
Hello,
A solution is to use package cubature, both unscaled and scaled versions
return the correct result, 3.575294.
But the performance penalty is BIG. This is because the number of
evaluations is much bigger.
library(cubature)
cubintegrate(f, -Inf, 0, method = "hcubature")
#$integral
#[1]
Looks fixed as of revision 76417; thanks Brian!
On 4/21/19 9:02 PM, Benjamin Tyner wrote:
Duncan that does indeed look to be the case. Many thanks!
In particular, tests/reg-tests-1d.R optionally loads the Matrix
namespace which allows the test to succeed. Compare:
~/R-rc_2019-04-21_r76409
Duncan that does indeed look to be the case. Many thanks!
In particular, tests/reg-tests-1d.R optionally loads the Matrix
namespace which allows the test to succeed. Compare:
~/R-rc_2019-04-21_r76409/bin/Rscript -e "options(warn=2);
library(Matrix); res <- findMethods('isSymmetric'); pri
On 21/04/2019 4:56 p.m., Benjamin Tyner wrote:
Hello,
Most likely I'm doing something wrong, but am at a loss as to what the
issue is. I have a clean checkout of trunk here: >
~/svn/r-devel/R$ svn info
Path: .
Working Copy Root Path: /home/btyner/svn/r-devel/R
URL: https://sv
Hello,
Most likely I'm doing something wrong, but am at a loss as to what the
issue is. I have a clean checkout of trunk here:
~/svn/r-devel/R$ svn info
Path: .
Working Copy Root Path: /home/btyner/svn/r-devel/R
URL: https://svn.r-project.org/R/trunk
Relative URL: ^/trunk
Rep
integrate(f, xmin, xmax) will have problems when f(x) is 0 over large parts
of (xmin,xmax). It doesn't have any clues to where the non-zero regions
are. It computes f(x) at 21 points at each step and if all of those are
zero (or some other constant?) for a few steps, it calls it a day. If you
ca
Dear all,
This is the first time I am posting to the r-devel list. On
StackOverflow, they suggested that the strange behaviour of integrate()
was more bug-like. I am providing a short version of the question (full
one with plots: https://stackoverflow.com/q/55639401).
Suppose one wants integ
hi all
This is possibly a bit off topic.
However, the mailing list is quiet at the moment so I thought I would
mention it.
Recently, I had a look at R-devel (R-alpha?) from 1997.
And it's very informative and very cool.
I'm planning to go through it more carefully when I get some more free time.
Thanks.
I am fully aware of what aggregate() returnes, and I can post-process this into
the form I want — if the names are available.
But for foo, the returned object is both different in structure and loses the
name altogether:
foo <- function(x) { c(mean = base::mean(x)) }
str(aggregate(iris
I didn't find the development version of your package but the latest version
archived on CRAN uses Rcpp, RcppArmadillo.
Since the latest versions of Rcpp and Armadillo support registration, it may be
something related to RcppAttributes()
or similar. I think that you don't need to do registration
On 11/01/2018 7:17 AM, Therneau, Terry M., Ph.D. wrote:
This is not nice. I have easy access to the "institutional" version of R on the
department servers, which do not track R-release all that fast (3-12 month
delay, affects
300+ users, and at the back end of a formalized IT process), and a pe
On 17/09/2017 6:25 PM, Will Landau wrote:
Hello,
Windows R-devel no longer lets me use testthat even though the CRAN checks are
pretty much clean. I have copied my session output below.
There was a recent change in R-devel that means all packages with
compiled code need to be re-installed f
> On 18 Sep 2017, at 00:25 , Will Landau wrote:
>
> Hello,
>
>
> Windows R-devel no longer lets me use testthat even though the CRAN checks
> are pretty much clean. I have copied my session output below.
>
> Will
Well, there us a reason for the nickname of R-devel:
> R Under development
Hello,
Windows R-devel no longer lets me use testthat even though the CRAN checks are
pretty much clean. I have copied my session output below.
Will
R Under development (unstable) (2017-09-16 r73293) -- "Unsuffered Consequences"
Copyright (C) 2017 The R Foundation for Statistical Computing
P
On Tue, Sep 12, 2017 at 8:28 PM, wrote:
> (https://svn.r-project.org/R/branches/ALTREP/ALTREP.html outlines the
> framework).
Thank you for the nice writeup, hope this makes it into the R journal.
The spelling package finds a few typos:
> spelling::spell_check_files('ALTREP.md', lang = 'en_US')
For anyone using the development version of R:
svn revision 73243 introduces some changes to the memory layout of R
objects that require reinstalling packages using compiled
code. Attempting to load incompatible packages should signal an
error. These changes are to support a new extension framewo
Hello.
Unless I am mistakedn, it seems that lines 49 and 72 are copies of
each other and only one should be necessary to set the whether or not
Windows is 32- or 64-bit. If it were my guess, I'd say lines 48 & 49
are redundant.
Thanks,
Avi
__
R-devel@
Hi,
Short answer: import 'as.matrix' and export your method(s) for it. From WRE:
"All S4 classes to be used outside the package need to be listed in an
exportClasses directive. Alternatively, they can be specified using
exportClassPattern.(46) in the same style as for exportPattern. To export
Is the following intentional or something that has been overlooked?
[HB-X201]{hb}: R --vanilla
R Under development (unstable) (2016-05-13 r70616) -- "Unsuffered Consequences"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
[...]
## Note th
On 18 January 2016 at 17:38, Måns Magnusson wrote:
| I got the link from Garbor to work, but that is the old r-travis approach
| (using C).
I prefer that approach. It works _now_ and you get complete control.
| I tried the same approach with native R Travis build but
| unfortunately it did not
Thank you all for the comments and suggestions!
I got the link from Garbor to work, but that is the old r-travis approach
(using C). I tried the same approach with native R Travis build but
unfortunately it did not work. So I contacted Jim Hester and he told me
that they are now actively working w
On 18 January 2016 at 09:45, Måns Magnusson wrote:
| I'm developing R packages and use Travis CI for continous integration. When
| submitting to CRAN Im suggestet to test the package using the latest
| R-devel. I would like that all test where run using Travis. Is there anyone
| who knows if this
On Mon, Jan 18, 2016 at 9:00 AM, Peter Meissner
wrote:
> Hey,
>
> Metacran's rbuilder is the place to get started:
> https://github.com/metacran/r-builder
>
> You should be good to go by placing this in your Github repo (branch):
> https://github.com/metacran/r-builder/blob/master/.travis.yml
Act
Hey,
Metacran's rbuilder is the place to get started:
https://github.com/metacran/r-builder
You should be good to go by placing this in your Github repo (branch):
https://github.com/metacran/r-builder/blob/master/.travis.yml
.. than tell Travis to whatch you repo.
Best, Peter
Am .01
Hi!
I'm developing R packages and use Travis CI for continous integration. When
submitting to CRAN Im suggestet to test the package using the latest
R-devel. I would like that all test where run using Travis. Is there anyone
who knows if this is possible to run travis test using the latest r-devel
Hello all,
I have spent the last week going through the configure/configure.ac
file, basically line-by-line.
I am finding things related to AIX that have not been working well
(i.e., cleanly) for 32-bit builds and are a "root-cause" for 64-bit
builds to finish cleanly.
Trying to keep this sh
On 30 November 2015 at 08:54, Paul Murrell wrote:
| For the record, Dirk (after a couple of false starts and admirable
| persistance!) has got this to work for me.
[ This was entirely due to
a) Debian transitioning to g++-5 support and relabeling all (rebuilt) C++
libraries with a suffix
Hi
For the record, Dirk (after a couple of false starts and admirable
persistance!) has got this to work for me.
So on Ubuntu 14.04, adding Dirk's PPA, followed by apt-get update pulls
down a backport for libpcre3.
Thanks Dirk!
Paul
On 24/11/2015 4:57 p.m., Dirk Eddelbuettel wrote:
Seba
Sebastian, Paul,
Ubuntu 14.04 builds (for Linux 32 and 64 bit, ie i386 and amd64) of the (most
current) pcre package (ie 8.35-7) for Ubuntu are now in my PPA at
https://launchpad.net/~edd/+archive/ubuntu/misc/+packages
These should work. You can add this PPA as I do in some Travis runs via
For the record ...
I'm on Ubuntu 14.04 too (probably until 16.04 comes out)
Paul
On 21/11/15 10:39, Prof Brian Ripley wrote:
I think you have it backwards: Ubuntu 14.04 does not support R-devel
PCRE 8.32 is 3 years old, so Ubuntu 14.04 shipped an already quite old
version 19 months ago.
I think you have it backwards: Ubuntu 14.04 does not support R-devel
PCRE 8.32 is 3 years old, so Ubuntu 14.04 shipped an already quite old
version 19 months ago.
R has long said that its requirement was
PCRE (version 8.10 or later, preferably 8.32 or later)
and 8.32 is indeed prefer
On 20 November 2015 at 16:14, Sebastian Meyer wrote:
| Since yesterday's r69662, R no longer ./configure[s] on a standard
| Ubuntu 14.04.3 installation, which ships with PCRE 8.31
| (http://packages.ubuntu.com/trusty-updates/libpcre3-dev)
|
| I get:
|
| > checking if PCRE version >= 8.32, < 10.0
Since yesterday's r69662, R no longer ./configure[s] on a standard
Ubuntu 14.04.3 installation, which ships with PCRE 8.31
(http://packages.ubuntu.com/trusty-updates/libpcre3-dev)
I get:
> checking if PCRE version >= 8.32, < 10.0 and has UTF-8 support... no
> checking whether PCRE support suffice
> From: Joshua Bradley
>
> I have been having issues using parallel::mclapply in a memory-efficient
> way and would like some guidance. I am using a 40 core machine with 96 GB
> of RAM. I've tried to run mclapply with 20, 30, and 40 mc.cores and it has
> practically brought the machine to a stand
Thanks for your message! I am out of office until August 10, 2015. Your
message will be answered after I return to office on August 11, 2015. Thank
you in advance for your kind patience!
Best regards,
Ulrich Bodenhofer
__
R-devel@r-project.org mail
Some maintainer-mode changes to the configure script went AWOL. Rerunning the
nightly build script seems to have cleared it up.
-pd
On 22 Jun 2015, at 16:32 , Gábor Csárdi wrote:
> At least on Ubuntu 12.4. and 14.4. FYI.
>
> https://travis-ci.org/metacran/r-builder#L7003
>
> Gabor
>
> _
At least on Ubuntu 12.4. and 14.4. FYI.
https://travis-ci.org/metacran/r-builder#L7003
Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> On 05-06-2015, at 14:16, Thomas J. Leeper wrote:
>
> It's disappointing that many packages do not have a NEWS file. Perhaps
> CRAN should require NEWS or CHANGELOG, as long as the system is being
> reformed to potentially accommodate markdown anyway.
>
I don’t really care about markdown.
But
It's disappointing that many packages do not have a NEWS file. Perhaps
CRAN should require NEWS or CHANGELOG, as long as the system is being
reformed to potentially accommodate markdown anyway.
-Thomas
Thomas J. Leeper
http://www.thomasleeper.com
On Fri, Jun 5, 2015 at 12:00 PM, wrote:
> Date
> Hervé Pagès
> on Mon, 2 Mar 2015 13:00:47 -0800 writes:
> Hi,
> On 03/02/2015 12:18 PM, Dénes Tóth wrote:
>>
>>
>> On 03/02/2015 04:37 PM, Martin Maechler wrote:
>>>
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend
On 03/02/2015 01:00 PM, Hervé Pagès wrote:
Hi,
On 03/02/2015 12:18 PM, Dénes Tóth wrote:
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .
Hi,
On 03/02/2015 12:18 PM, Dénes Tóth wrote:
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ c
On 03/02/2015 11:39 AM, Dirk Eddelbuettel wrote:
On 2 March 2015 at 16:37, Martin Maechler wrote:
|
| > On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| > | I generally recommend that people use Rcpp, which hides a lot of the
| > | details. It will generate your .Call calls for you, and genera
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think a
On 2 March 2015 at 16:37, Martin Maechler wrote:
|
| > On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| > | I generally recommend that people use Rcpp, which hides a lot of the
| > | details. It will generate your .Call calls for you, and generate the
| > | C++ code that receives them; you ju
> On 2 March 2015 at 09:09, Duncan Murdoch wrote:
> | I generally recommend that people use Rcpp, which hides a lot of the
> | details. It will generate your .Call calls for you, and generate the
> | C++ code that receives them; you just need to think about the real
> | problem, not the interf
Thanks! I went through the online posts which supports the power of .Call
over .C. But my probably naive question is why does this work for my code
with R but not R-devel?
And another question is related to using .Call. Based on the manual page, I
do not need to change the function parameters when
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think about the real
| problem, not the interface. It h
1 - 100 of 227 matches
Mail list logo
