On 2/17/20 5:36 PM, Serguei Sokol wrote:
Hi,
A colleague of mine has spotted me a passage of the doc ?option
talking about Inf and NaN check in 'matprod=default' section:
https://stat.ethz.ch/R-manual/R-devel/library/base/html/options.html
I am wondering if NA should be mentioned too as the c
On 2/17/20 6:18 PM, Serguei Sokol wrote:
Le 17/02/2020 à 17:50, Tomas Kalibera a écrit :
On 2/17/20 5:36 PM, Serguei Sokol wrote:
Hi,
A colleague of mine has spotted me a passage of the doc ?option
talking about Inf and NaN check in 'matprod=default' section:
https://stat.ethz.ch/
On 3/5/20 5:39 PM, Therneau, Terry M., Ph.D. via R-devel wrote:
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
cod
(".")
> Loading testPackage
> Re-compiling testPackage
> ─ installing *source* package 'testPackage' ... (357ms)
> ** using staged installation
> ** libs
> test1 is [1] 0.00545376 0.30696231 0.68752312
> test2 is [1] 0.1
On 3/17/20 8:18 PM, Hervé Pagès wrote:
Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on
an Ubuntu 14.04.5 LTS system gives me the following error:
...
checking if lzma version >= 5.0.3... yes
checking for pcre2-config... no
checking for pcre_fullinfo in -lpcre... yes
checkin
now gives the required version and UTF-8 support
requirement, so one does not have to look that one line up.
Thanks to Brian Ripley,
Tomas
H.
On 3/18/20 01:08, Tomas Kalibera wrote:
On 3/17/20 8:18 PM, Hervé Pagès wrote:
Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on
Hi Jiefei,
the change in handling trailing path separators is not on purpose, but
is a byproduct of a new implementation of normalizePath, which now
handles symbolic links and normalizes case in long path names. It is not
documented what happens to trailing separators, and hence portable
pr
To clarify, these issues are about deleting the contents of the home
directory, not the directory itself, which cannot be deleted by ordinary
users on today's systems. Unfortunately this has to be fixed in the code
that calls unlink(), such code must be aware of the expansions. The "R
CMD build
On 3/23/20 8:39 PM, Ben Bolker wrote:
Dear r-devel folks,
[if this is more appropriate for r-pkg-devel please let me know and
I'll repost it over there ...]
I'm writing to ask for help with some R/C++ integration idioms that are
used in a package I'm maintaining, that are unfamilar to me, an
On 2/19/20 3:55 AM, Stefan Schreiber wrote:
I have posted this question on R-help where it was suggested to me
that I might get a better response on R-devel. So far I have gotten no
response. The post I am talking about is here:
https://stat.ethz.ch/pipermail/r-help/2020-February/465700.html
My
On 3/27/20 4:39 PM, Hervé Pagès wrote:
Hi Tomas,
On 3/27/20 07:01, Tomas Kalibera wrote:
they provide an over-approximation
They can also provide an "under-approximation" (to say the least) e.g.
on reference objects where the entire substance of the object is
ignored w
+ 5.13 of Writing R Extensions
Tomas
On 4/3/20 3:04 PM, Gábor Csárdi wrote:
See R_RegisterCFinalizerEx() and set onexit to nonzero. Here:
https://github.com/wch/r-source/blob/9353ddfa8d30069ad8975e0364307d710f2488d5/src/include/Rinternals.h#L1279-L1280
Gabor
On Fri, Apr 3, 2020 at 1:56 PM Wang
Hi Samuel,
could you please provide more information? Where do you see the limit
reported or how did you trigger it, what version of Windows do you have,
are you using 64-bit build of R (sessionInfo())
Please check help("Memory-limits") and section 8 of R Admin manual
Best,
Tomas
On 4/7/20
Hi Samuel,
please also have a look at ?memory.limit. You can set this limit at R
startup. It is in megabytes. Maybe R Studio sets it at runtime.
Best
Tomas
On 4/7/20 3:57 PM, Samuel Granjeaud IR/Inserm wrote:
Hi Tomas,
Many thanks for your answer.
Here is a copy of a fresh session under RS
I think application-specific normalization is actually the right thing
to do, because the behavior of normalizePath() is too system-specific
and too unreliable. That is not a deficiency of R, the same problem
exists on other systems I've spent too much time recently working on
normalizePath() i
On 4/30/20 4:37 PM, Dirk Eddelbuettel wrote:
On 30 April 2020 at 09:11, luke-tier...@uiowa.edu wrote:
| On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote:
| Maybe I missed something. How is the 'compiler' package involved?
See the other email thread; you replied (~ 26 hours ago) to my message adding
Thanks for the report, fixed in R-devel.
Tomas
On 5/4/20 9:26 PM, Taiane S. Prass wrote:
Hi
I have a FORTRAN version of the L-BFGS-B algorithm and I was comparing it
to the code in the lbfgsb.c file available at R-4.0.0.tar.gz
Everithing looks the same, except for those two lines that must be
Thanks for the report, but it is unlikely anyone would be able to help
just based on this code fragment. We need a small and minimal but
complete reproducible example. That example should not use any
contributed packages (a contributed package may be corrupting memory,
which may cause R to cras
bug is in R, but one never knows before the case is fully analyzed.
Tomas
> --Russell
>
>
> On 5/12/20 5:30 AM, Tomas Kalibera wrote:
>> Thanks for the report, but it is unlikely anyone would be able to
>> help just based on this code fragment. We need a small and mi
Thanks, fixed.
Tomas
On 5/13/20 5:14 AM, Dirk Eddelbuettel wrote:
On 12 May 2020 at 19:59, Hervé Pagès wrote:
| While reading about the new 'recycle0' argument of paste/paste0, I
| spotted a mysterious "cd" floating in the air in the man page:
|
|recycle0: ‘logical’ indicating if zero-length
Thanks for reporting this, it is a bug, now fixed in R-devel and
R-patched (PR#17800).
Best
Tomas
On 5/15/20 3:50 AM, William Dunlap via R-devel wrote:
Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
double all the backslashes when options(keep.source=TRUE)? E.g.,
opti
On 5/14/20 8:34 PM, Jan Gorecki wrote:
Hi R developers,
I observed that system(timeout=) may still return exit code 0, when
killing the process due to timeout.
In src/unix/sys-unix.c there is
#define KILL_SIGNAL1 SIGINT
#define KILL_SIGNAL2 SIGTERM
#define KILL_SIGNAL3 SIGKILL
#define EMERGENC
Thanks, fixed now.
Tomas
On 5/22/20 10:18 AM, Jeroen Ooms wrote:
As of commit 78536 earlier this morning the build is failing on
windows 64, see https://r-devel.github.io
I cannot immediately spot what is the problem. The build fails with:
installing 'sysdata.rda'
make[3]: *** [../../../sha
Hi Robert,
thanks for the report and your suggestions how to make the NaN checks
faster.
Based on my experiments it seems that the "break" in the loop actually
can have positive impact on performance even in the common case when we
don't have NaNs. With gcc on linux (corei7), where isnan is
st.
I am measuring on Knight's Landing (KNL) that was released in November. KNL is
not a co-processor so no offload is necessary. R executes directly on the Phi,
which looks like a multi-core machine with 64 cores.
Robert
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@
Hi Lukas,
thanks for the report. I've changed cumsum so that it is now consistent
with cumprod wrt to NA/NaN propagation.
Now NaN is not turned into NA unnecessarily.
Still please be aware that generally NaNs may become NAs in R (on some
platforms/compilers)
?NaN says
"Computations involvin
On 02/09/2017 05:05 PM, Berend Hasselman wrote:
On 9 Feb 2017, at 16:00, Göran Broström wrote:
In my package 'glmmML' I'm using old C code and linpack in the optimizing
procedure. Specifically, one part of the code looks like this:
F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, inf
The R for Windows FAQ suggests "make DEBUG=T" and has some more hints
https://cran.r-project.org/bin/windows/base/rw-FAQ.html
Tomas
On 02/23/2017 08:10 PM, Javier Luraschi wrote:
Right, I'm talking about C code.
Do you remember if you had to set specific CFLAGS or other settings to get
gdb wo
Hi Guillaume,
the error "C stack usage is too close to the limit" is usually caused by
infinite recursion.
It can also be caused by an external library that corrupts the C stack
(such as Java on Linux, e.g. when using rJava).
I cannot repeat the problem on my machine.
To rule out the second
The warning that dummy_ii returns address of local variable is benign,
this function is intended to do so.
I've silenced it in R-devel.
Tomas
On 04/06/2017 03:51 PM, Therneau, Terry M., Ph.D. wrote:
Peter,
Retry how much of it? That is, where does it go in the sequence
from svn up to ma
We're working on a workaround for the JVM issue, it should be available
in rJava soon.
(the JVM issue is only on Linux and it turns infinite/deep recursion
into a crash of R; it also effectively reduces the R stack size)
Best
Tomas
On 04/19/2017 02:56 PM, Michael Lawrence wrote:
I think thi
asily identified in the stacktrace.
Best
Tomas
On 04/24/2017 11:58 AM, Hilmar Berger wrote:
Hi January,
I believe the root of the xlsx issue has been identified and a fix
suggested by Tomas Kalibera (see https://github.com/s-u/rJava/pull/102).
In a nutshell, Oracle Java on Linux modifies the stack
I agree this should be solved in configuration of
systemd/tmpreaper/whatever tmp cleaner - the cleanup must be prevented
in configuration files of these tools. Moving session directories under
/var/run (XDG_RUNTIME_DIR) does not seem like a good solution to me,
sooner or later someone might c
Thanks for the report, fixed in R-devel and R-patched.
Best
Tomas
On 04/30/2017 10:48 PM, Christoph Sax wrote:
Hi,
I am running into a problem when I use the window<- replacement function in R
3.4.0. It will lead to an error when it is called inside a loop, probably
the result of the byte comp
As a quick fix, you can undefine HAVE_CTANH in complex.c, somewhere
after including config.h
An internal substitute, which is implemented inside complex.c, will be used.
Best
Tomas
On 05/04/2017 02:57 PM, Kasper Daniel Hansen wrote:
For a while I have been getting that the complex tests fa
uld be great for something like
> this which affects tests and seems to be a known problem for older C
> standard libraries.
>
> Best,
> Kasper
>
> On Thu, May 4, 2017 at 9:12 AM, Tomas Kalibera
> mailto:tomas.kalib...@gmail.com>> wrote:
>
>
> As a
Thanks for the report, handled in configure in 72661 (R-devel).
I'll also port to R-patched.
Best
Tomas
On 05/04/2017 03:49 PM, Tomas Kalibera wrote:
>
> There is no way to control this at runtime.
> We will probably have to add a configure test.
>
> Best,
> Tomas
>
The difference in the outputs between 3.3 and 3.4 is in how call
expressions are selected in presence of .Internals. R is asked for a
call expression for "eval". In 3.3 one gets the arguments for the call
expression from the .Internal that implements eval. In 3.4 one gets the
arguments for th
Thanks, the tool is indeed right, this is a real error. Although it is
unlikely to trigger and unlikely to cause new problems (R would fail
soon anyway if out of memory), it is clearly something to be fixed and
something to be classified as "true positive".
I've fixed this in a way that is con
Thanks, fixed in 72737 (R-devel).
Best
Tomas
On 05/23/2017 06:32 PM, Evan Cortens wrote:
Yes, what Joris posts about is exactly what I noted in my March 9th post to
R-devel. The behaviour is sort of documented, but not in the clearest
manner (in my opinion). Like I say, my ultimate conclusion w
This bug has been fixed in R-devel 72612 and R-patched 72614.
Best
Tomas
On 05/26/2017 02:59 PM, Roman Kiselev wrote:
Dear all,
after an update from R 3.3.x to R 3.4.0 I cannot build Sweave documents
using make, because make checks the exit code of the `R CMD Sweave` and
stops if it is not zer
On 05/18/2017 06:54 PM, Joy wrote:
Sorry, this might be a really basic question, but I'm trying to interpret
the results from memory profiling, and I have a few questions (marked by
*Q#*).
From the summaryRprof() documentation, it seems that the four columns of
statistics that are reported when
Thanks, fixed in R-devel.
Best
Tomas
On 06/11/2017 02:30 PM, Suharto Anggono Suharto Anggono via R-devel wrote:
I see another thing in function 'NewName' in bind.c. In
else if (*CHAR(tag)) ,
'ans' is basically copied from 'tag'. Could the whole thing there be just the
following?
ans = tag;
It s
Thanks for the report, I've fixed 15199 in the AST interpreter in 72664,
I will fix it in the byte-code interpreter as well.
If you ever needed to disable the JIT, there is API for that, see
?compiler. Note though that by disabling the JIT you won't disable the
byte-code interpreter, because c
Hi Petr,
I can repeat this behavior (or similar) with Norton Security:
R-devel-win.exe is reported by Download Insight
R-3.4.1patched-win.exe is reported by Download Insight
R-3.4.1-win.exe is fine
And the report is that the binary is very new (released less than 1 week
ago) and has very few us
Thanks for spotting this issue. The short answer is yes, adding
attributes to a symbol is a bad idea and will be turned into a runtime
error soon. Maintainers of packages that add attributes to symbols have
been notified and some have already fixed their code.
At least in one case the packag
The problem is in TRE library, in regcomp, while compiling the regular
expression.
This is enough to trigger in R (to do this without re-boot: ulimit -v
50 ):
> strsplit("", ")")
To repeat in TRE, one can build TRE from sources and run
> ./src/agrep ")" README.md
Tomas
On 08/
Thank you for the report, it is a bug in buffering in R (not specific to
Windows) and will be fixed.
Best
Tomas
On 08/17/2017 10:37 AM, PIKAL Petr wrote:
Hi
-Original Message-
From: Robert Baer [mailto:rb...@atsu.edu]
Sent: Wednesday, August 16, 2017 3:04 PM
To: PIKAL Petr ; Duncan M
Hi Ghislain,
I think you might be comparing two versions of R with different BLAS
implementations, one that is single threaded (is your 3.3.2 used with
reference blas?) and one that is multi threaded (3.4.1 with openblas).
Could you check with "perf"? E.g. run your benchmark with "perf record"
TRE library has
recently been made, but I don't know about its status.
Daniel
Von: R-devel im Auftrag von Tomas Kalibera
Gesendet: Donnerstag, 17. August 2017 10:14
An: r-devel@r-project.org
Betreff: Re: [Rd] Problem with a regular expression.
It is a bug in the byte-code compiler. I will fix
Tomas
On 08/23/2017 09:22 AM, Lionel Henry wrote:
I don't think that's a bug. source() uses eval(), and eval() creates a
new function-like context frame. In a way expecting `break` to work
inside source() is like expecting `break` to cross stack
fically do not
assume this would turn off a particular compiler optimization in future
versions.
Best
Tomas
On 08/23/2017 09:24 AM, Tomas Kalibera wrote:
It is a bug in the byte-code compiler. I will fix
Tomas
On 08/23/2017 09:22 AM, Lionel Henry wrote:
I don't think that's a bug
at(eval(expr))
So eval() has hybrid semantics where `break` has more reach than
return(), weird.
expr <- quote(return())
repeat(eval(expr)) # infloop
Lionel
On 23 août 2017, at 09:24, Tomas Kalibera wrote:
It is a bug in the byte-code compiler. I will fix
Tomas
On 08/23/2017
As of R-devel 72925 one gets a proper error message instead of the crash.
Tomas
On 09/04/2017 08:46 AM, rh...@eoos.dds.nl wrote:
Although the problem can apparently be avoided in this case. readLines
causing a segfault still seems unwanted behaviour to me. I can
replicate this with the exampl
Fixed in R-devel 73212 (and 73121).
Best
Tomas
On 08/17/2017 11:58 AM, Tomas Kalibera wrote:
Thank you for the report, it is a bug in buffering in R (not specific
to Windows) and will be fixed.
Best
Tomas
On 08/17/2017 10:37 AM, PIKAL Petr wrote:
Hi
-Original Message-
From
I think you might get a more useful answer if you say what you want to
achieve.
"address(x)" does not give you an address of variable "x" but of an
object bound to x. The GC in R is non-moving, it does not relocate
objects. However, a number of things can happen that will change the
binding
This windows/anti-virus problem has been worked around in R-devel 73329.
Thanks to Mike for reporting this and testing the changes.
Best
Tomas
On 09/13/2017 01:40 AM, Mike Toews wrote:
Hi,
Me and an office colleague on Microsoft Windows 10 PCs are having
difficulty installing any package. This
Calling R_ReleaseObject in a C++ destructor is not reliable - it can be
bypassed by a non-local return, such as an error. Generally in R one
cannot use C++ destructors reliably for anything that the R runtime
wouldn't do on its own in case of a non-local return.
A destructor that calls just
Fixed in 73470
Best,
Tomas
On 10/05/2017 06:11 AM, Henrik Bengtsson wrote:
I'd like to follow up/bump the attention to this bug causing the
timeout to fail for socketSelect() on Unix. It is still there in R
3.4.2 and R-devel. I've identified the bug in the R source code - the
bug is due to fl
Hi Zach,
thanks for the report, I can reproduce the problem and confirm it is a
bug in R and will be fixed.
Hopefully it only impacts few users now. The workaround is to create the
short name for the directory where R is installed, using "fsutil file
setshortname" (for all elements of the pa
This has now been mostly fixed in R-devel. What remains to be resolved
is that some packages with custom make files cannot be installed from
source (when R is installed into a directory with space in its name and
short file names are not available)
Tomas
On 10/17/2017 10:37 AM, Tomas
On 10/21/2017 04:14 PM, Radford Neal wrote:
On Fri, 2017-10-20 at 14:01 +, brodie gaslam via R-devel wrote:
I'm thinking of this passage:
Logical values are sent as 0 (FALSE), 1 (TRUE) or INT_MIN =
-2147483648 (NA, but only if NAOK is true), and the compiled code
should return one of these
If you were curious about the hidden details of the memory layout in R,
the best reference is the source code. In your example, you are not
getting to your string because there is one more pointer in the way, "x"
is a vector of strings, each string is represented by a pointer.
At C level, ther
FYI this has been fixed in R-devel by Martin
Tomas
On 10/23/2017 06:36 PM, Martin Maechler wrote:
Lukas Stadler
on Mon, 23 Oct 2017 15:56:55 +0200 writes:
> Hi!
> I was wondering about the behavior of the range function wrt. logical
NAs:
>> range(c(0L, 1L, NA), finite=T)
Thanks for the report, fixed in R-devel.
Tomas
On 10/20/2017 08:09 PM, Trevor Davis wrote:
Hi,
A user of my `optparse` package discovered a bug in Rscript's parsing of
[args]. (https://github.com/trevorld/optparse/issues/24)
I've reproduced the bug on my machine including compiling and checkin
Please note there is parallel::mcparallel/mccollect in R which provides
similar functionality, mcparallel starts a new job and mccollect allows
to wait for it.
You are right about _exit, but there are additional issues which cannot
be solved independently in an external package, and, such a lo
Thanks, will fix this
Best
Tomas
On 12/05/2017 12:44 PM, Gábor Csárdi wrote:
I wonder if this is intended.
Thanks,
Gabor
C:\Users\rhub>"c:\Program Files\R\R-3.4.2\bin\R" -q -e "1 + 1"
1 + 1
[1] 2
C:\Users\rhub>"c:\Program Files\R\R-3.4.3\bin\R" -q -e "1 + 1"
'c:\PROGRA~1\R\R-34~1.3\bin\x
A quick workaround if you needed to execute R expressions in Windows is
calling RTerm directly.
But a fix should be available soon.
Tomas
On 12/05/2017 05:51 PM, Henrik Bengtsson wrote:
Sorry for not reading carefully and thanks for confirming problem with
Rscript too.
On Dec 5, 2017 08:47, "
Fixed in R-devel and R-patched.
Tomas
On 12/05/2017 05:58 PM, Tomas Kalibera wrote:
A quick workaround if you needed to execute R expressions in Windows
is calling RTerm directly.
But a fix should be available soon.
Tomas
On 12/05/2017 05:51 PM, Henrik Bengtsson wrote:
Sorry for not
ot regularly tested. If you
find a case when this does not work, please submit a bug report.
Thanks
Tomas
On 10/20/2017 04:29 PM, Tomas Kalibera wrote:
This has now been mostly fixed in R-devel. What remains to be resolved
is that some packages with custom make files cannot be installed
On 12/07/2017 06:15 PM, Dirk Eddelbuettel wrote:
On 7 December 2017 at 17:56, Tomas Kalibera wrote:
|
| An update on this. Writing R Extensions does not recommend to have a
| space character in R_HOME. This means that on Windows one either should
| have SFN enabled (which is still the common
Hi Carson,
thanks for the report. This is a bug in R, specific to Windows and to
characters that use surrogate pairs - other characters will work fine,
other recent operating systems where R runs will work fine (all where a
single wchar_t holds complete Unicode characters). Now fixed in R-deve
Dear Juan,
I don't see what is the problem from your report. Please try to create a
minimal but complete reproducible example that does not use the renv
package. Perhaps you could use the R debugger (e.g. via
options(error=recover)) to find out what is the argument that
file.exists() has be
1252
system code page: 936
FWIW, I also tested Chinese characters in the variable `z` above, and
file.exists() returns TRUE only after I Sys.setlocale(, "Chinese").
Regards,
Yihui
On Thu, Jun 11, 2020 at 3:11 AM Tomas Kalibera wrote:
Dear Juan,
I don't see what is the problem
This can be narrowed down to
Sys.setlocale("LC_CTYPE","C")
x2 <- "\u00e7"
x1 <- iconv(x2, from="UTF-8", to="latin1")
x1 < x2 # FALSE or NA
In R 4.0 it returns NA, in R-devel it returns FALSE (when running in
CP1252 locale on Windows).
It is the same character, only the encoding is different,
Thanks for spotting this outdated bit in the documentation. Updated now
in R-devel. The byte-code compiler does additional optimizations - the
contexts are not included when not needed, and source
references/expressions are tracked in a different way. That is
documented in the compiler document
From the user's (or package author's) point, all strings should always
be valid in their declared encoding. If they are not, the result of
string operations is undefined - it may be an error or warning, but also
silently produced correct or incorrect result. There are R functions
that check if
On 6/29/20 4:39 PM, Johannes Rauh wrote:
Dear R Developers,
I noticed that `basename` and `dirname` always return "UTF-8" on Windows
(tested with R-4.0.0 and R-3.6.3):
p <- "Föö/Bär"
Encoding(p)
[1] "latin1"
Encoding(dirname(p))
[1] "UTF-8"
Encoding(basename(p))
[1] "UTF-8"
Is this on p
On 6/30/20 1:06 PM, Jan Gorecki wrote:
It is quite known that R documentation on R C api could be improved...
Please see "5.11 Evaluating R expressions from C" from "Writing R
Extensions"
Best
Tomas
Still R-package-devel mailing list should be preferred for this kind
of questions.
Not sure
On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote:
I am having exactly the same issue as the following bug report:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515.
RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit
RTerm.exe runs fine.
No errors are di
On 8/21/20 9:20 PM, m17hpj+bt626qpx8w70w--- via R-devel wrote:
For some further information, on compiling with rtools, using the following
scripts, https://github.com/r-windows/r-base, I receive a segfault:
installing 'sysdata.rda'
building package 'compiler'
byte-compiling package 'compiler'
On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:
Ah yes, this is related. I reported v2010 below, but it looks like I was
updated to this Insider Build overnight without my knowledge, and conflated it
with the new installation R v4 this morning.
I will continue to look into the i
On 8/22/20 7:58 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote:
On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:
Ah yes, this is related. I reported v2010 below, but it looks like I was
updated to this Insider Build overnight without my knowledge
On 8/22/20 8:26 PM, Tomas Kalibera wrote:
On 8/22/20 7:58 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
wrote:
On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:
Ah yes, this is related. I reported v2010 below, but it looks like
I was updated to this
On 8/23/20 5:02 PM, Rory Winston wrote:
Hi
I noticed a small inconsistency when using sum() vs cumsum()
I have a char-based series
> tryjpy$long
[1] "0.0022" "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" "-0.0022"
[8] "0.0003" "-0.0001" "-0.0004" "-0.0036" "-0.001" "-0.0011" "
On 8/22/20 9:33 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera wrote:
On 8/22/20 8:26 PM, Tomas Kalibera wrote:
On 8/22/20 7:58 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
wrote:
On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote
Please note that this is documented in ?trace. "fun" is matched to what,
it is a _name_ of the function to be traced, which is traced in the
top-level environment. I don't know why it was designed this way, but it
is documented in detail, and hence the expected behavior.
Debugging is often, an
s created in the base
> environment, which is not "where the function was found". It's not
> clear to me what "where it was found" would mean in that case, but I
> would assume the execution environment of trace2, or maybe the calling
> environment (gl
On 8/25/20 6:14 PM, Tomas Kalibera wrote:
On 8/22/20 9:33 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera
wrote:
On 8/22/20 8:26 PM, Tomas Kalibera wrote:
On 8/22/20 7:58 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
wrote:
On 8/21/20 11:45 PM
The general principle is that R packages are only allowed to use what is
documented in the R help (? command) and in Writing R Extensions. The
former covers what is allowed from R code in extensions, the latter
mostly what is allowed from C code in extensions (with some references
to Fortran
ternal.go#L86-L118
On Tue, 2020-09-08 at 11:07 +0200, Tomas Kalibera wrote:
The general principle is that R packages are only allowed to use what
is
documented in the R help (? command) and in Writing R Extensions. The
former covers what is allowed from R code in extensions, the latter
mostly what i
On 9/8/20 1:13 PM, Dan Kortschak wrote:
On Tue, 2020-09-08 at 12:08 +0200, Tomas Kalibera wrote:
I am not sure if I understand correctly, but if you were accessing
directly the memory of SEXPs from Go implementation instead of
calling
through exported access functions documented in WRE, that
On 9/8/20 4:48 PM, Hugh Parsonage wrote:
Unfortunately I only get
[Thread 21752.0x4aa8 exited with code 3221225477]
[Thread 21752.0x4514 exited with code 3221225477]
[Thread 21752.0x3f10 exited with code 3221225477]
[Inferior 1 (process 21752) exited with code 0305]
(I'm guessing I woul
an take care of this report, but of course in
the longer term it would help if more people could take their time to
setup debugging and analyze bugs even on Windows.
Tomas
On Wed, 9 Sep 2020 at 07:47, Jeroen Ooms wrote:
On Tue, Sep 8, 2020 at 11:44 PM Jeroen Ooms wrote:
On Tue, Sep 8, 2020 at
signal SIGSEGV, Segmentation fault.
0x6c72d206 in compact_intseq_Dataptr (x=0x12783350,
writeable=) at altclasses.c:169
169 altclasses.c: No such file or directory.
Thanks, would you know which svn version this is?
Tomas
On Wed, 9 Sep 2020 at 17:03, Tomas Kalibera wrote:
On 9/9
Thanks. Should be now fixed in 79169.
Tomas
On 9/9/20 10:32 AM, Hugh Parsonage wrote:
R Under development (unstable) (2020-09-08 r79165)
On Wed, 9 Sep 2020 at 18:00, Tomas Kalibera wrote:
On 9/9/20 9:30 AM, Hugh Parsonage wrote:
Thank you!
I get
Starting program: C:\R\R-devel-20200909\bin
On 9/8/20 11:47 PM, Jeroen Ooms wrote:
On Tue, Sep 8, 2020 at 11:44 PM Jeroen Ooms wrote:
On Tue, Sep 8, 2020 at 5:20 PM Tomas Kalibera wrote:
On 9/8/20 4:48 PM, Hugh Parsonage wrote:
Unfortunately I only get
[Thread 21752.0x4aa8 exited with code 3221225477]
[Thread 21752.0x4514 exited
On 8/27/20 8:38 PM, Jeroen Ooms wrote:
On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera wrote:
On 8/25/20 6:14 PM, Tomas Kalibera wrote:
On 8/22/20 9:33 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera
wrote:
On 8/22/20 8:26 PM, Tomas Kalibera wrote:
On 8/22/20 7:58 PM
Dear Kasper,
if you want to submit a bug via bugzilla, please first read
https://www.r-project.org/bugs.html
and you will learn there that there is an email address to use when
asking for an account, not all R-devel mailing list readers need to read
that.
Moreover, I can see you already hav
> Despite having been reported multiple times, it was not at all clear
> to me that this was being worked on with the intention of addressing
> make check - that is one of the limitations of the communication
> system we use.
>
> Best,
> Kasper
>
> On F
201 - 300 of 489 matches
Mail list logo
