Re: [Rd] NaN behavior of cumsum

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

Re: [Rd] Debugging tools and practices in Windows?

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

Re: [Rd] Ancient C /Fortran code linpack error

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, , , ,

Re: [Rd] accelerating matrix multiply

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

Re: [Rd] accelerating matrix multiply

ng list. 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...@gmail.com]

Re: [Rd] Error: memory exhausted (limit reached?)

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

Re: [Rd] failure of make check-all

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

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

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

Re: [Rd] symantec treating R-devel r73003 for Windows as malware

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

Re: [Rd] attributes on symbols

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

Re: [Rd] Problem with a regular expression.

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

Re: [Rd] strange behaviour read.table and clipboard

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

Re: [Rd] [Bug Fix] Default values not applied to ... arguments

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

Re: [Rd] tempdir() may be deleted during long-running R session

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

Re: [Rd] Crash after (wrongly) applying product operator on object from LIMMA package

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

Re: [Rd] Possible repeat{} / break function bug in R 3.4.1

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

Re: [Rd] Possible repeat{} / break function bug in R 3.4.1

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 <tomas.kalib...@gmail.com> wrote: It is a bug in the byte-code compiler. I w

Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

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

Re: [Rd] Bug in R 3.4.0: R CMD Sweave return value is 1 on success (instead of 0)

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

Re: [Rd] Interpreting R memory profiling statistics from Rprof() and gc()

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

Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf

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

Re: [Rd] Null pointer dereference?

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

Re: [Rd] translateChar in NewName in bind.c

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

Re: [Rd] Byte compilation with window<- in R3.4.0

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

Re: [Rd] complex tests failure

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

Re: [Rd] complex tests failure

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 > <tomas.kalib...@gmail.com <mailto:tomas.kalib...@gmail.com>> w

Re: [Rd] complex tests failure

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 > >

Re: [Rd] calling R API functions after engine shutdown

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

Re: [Rd] unpackPkgZip: "unable to move temporary installation" due to antivirus

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.

Re: [Rd] socketSelect(..., timeout): non-integer timeouts in (0, 2) (?) equal infinite timeout on Linux - weird

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

Re: [Rd] Bug: Issues on Windows with SFN disabled

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

Re: [Rd] Change of variable address due to GC

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

Re: [Rd] strange behaviour read.table and clipboard

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

Re: [Rd] Problem with a regular expression.

to the TRE library has recently been made, but I don't know about its status. Daniel Von: R-devel <r-devel-boun...@r-project.org> im Auftrag von Tomas Kalibera <tomas.kalib...@gmail.com> Gesendet: Donnerstag, 17. August 2017 10:14 An: r-devel@r

Re: [Rd] Control multi-threading in standard matrix product

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

Re: [Rd] readLines() segfaults on large file & question on how to work around

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

Re: [Rd] Illegal Logical Values

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

Re: [Rd] check does not check that package examples remove tempdir()

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

Re: [Rd] Memory address of character datatype

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,

Re: [Rd] Rscript Bug Report (improper parsing of [args])

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

Re: [Rd] range function with finite=T and logical parameters

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: >>

Re: [Rd] command line arguments are parsed differently on windows, from 3.4.3

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,

Re: [Rd] Bug: Issues on Windows with SFN disabled

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

Re: [Rd] command line arguments are parsed differently on windows, from 3.4.3

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

Re: [Rd] Bug: Issues on Windows with SFN disabled

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 ins

Re: [Rd] command line arguments are parsed differently on windows, from 3.4.3

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"

Re: [Rd] download.file does not process gz files correctly (truncates them?)

On 05/08/2018 05:15 PM, Hadley Wickham wrote: On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera <tomas.kalib...@gmail.com> wrote: On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: Also, as mentioned in my https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when not specifying th

Re: [Rd] [Bug report] Chinese characters are not handled correctly in Rterm for Windows

e related to this mechanism. If you need further information, please let me know. Thanks, i...@azurefx.name Tomas Kalibera <tomas.kalib...@gmail.com> 2018/4/5 22:42 Thank you for the report and initial debugging. I am not sure what is going wrong, we may have to rely on your help to debug th

Re: [Rd] Possible bug in package installation when R_ICU_LOCALE is set

Thanks for the report, fixed in 74706. Best, Tomas On 04/26/2018 08:43 AM, Korpela Mikko (MML) wrote: (Belated) thanks for the confirmation, Ista. I just reported this issue on the R bug tracker: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17412 Best regards, - Mikko

Re: [Rd] debugonce() functions are not considered as debugged

debug(fun) marks "fun" for debugging, it makes sure that whenever "fun" is called, the debugger is entered undebug(fun) removes this mark; it won't stop any current debugging of that function isdebugged(fun) tells whether this mark is set or not; it does not tell whether "fun" is currently

Re: [Rd] R Bug: write.table for matrix of more than 2, 147, 483, 648 elements

Fixed in R-devel 74754. Tomas On 04/19/2018 12:15 PM, Tomas Kalibera wrote: On 04/19/2018 11:47 AM, Serguei Sokol wrote: Le 19/04/2018 à 09:30, Tomas Kalibera a écrit : On 04/19/2018 02:06 AM, Duncan Murdoch wrote: On 18/04/2018 5:08 PM, Tousey, Colton wrote: Hello, I want to report a bug

Re: [Rd] debugonce() functions are not considered as debugged

On 05/22/2018 06:07 PM, Gábor Csárdi wrote: On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalib...@gmail.com> wrote: [...] Do you have a good use case when it would be useful to query/unset the mark for debugonce? Well, I suppose the same use cases when it is useful to query

Re: [Rd] Rd parser throws error for user macros invoked with empty argument

Thanks for the report and the examples - and they do not have to be that verbose, it is enough to just define and use a command, e.g. cat("\\newcommand{\\mac1}{MAC1:#1}\\mac1{}", file=f) rd <- tools::parse_Rd(f) Whenever you get an error message like "Value of SET_STRING_ELT() must be a

Re: [Rd] patch for scan.c for long vector support

Thanks for the report, fixed in R-devel 74782. Please report back if the fix is not sufficient for your use case. Tomas On 05/23/2018 06:16 AM, Aaron Goodman wrote: I noticed that scan.c does not yet support long vectors. It was causing a problem in the rstan library

Re: [Rd] Rgui 3.5.0 print issue

Thanks for the report, I can reproduce. In Rgui, the output of "print(cars)" is incorrect, the line numbers appear as part of the command prompt string (printed in reverse order, without newlines), while the rest of the output is correctly displayed. This is a bug, I will have a closer look

Re: [Rd] Byte-compilation failure on different architectures / low-memory systems

l wrote: On 4 June 2018 at 20:06, Tomas Kalibera wrote: | thanks for the report. Access to the test system is not necessary, the | memory requirements of the byte-code compiler are usually | platform-independent and specifically with this package I can reproduce | they are very high. We'll have a

[Rd] readBin/writeBin (was Buffering in R 3.5, ref WURVX1BEBiQLAlteFVdEVFFbFQFIAF1f)

updated the docs. Thanks again for the report, Best Tomas On 05/30/2018 03:38 PM, Tomas Kalibera wrote: > For now I have added a warning that is issued (only) when there is > definitely a problem (currently a read buffer, a pushback buffer or > encoding conversion of the input).  And I h

Re: [Rd] Buffering in R 3.5 connections causes incorrect data in readChar

On 05/26/2018 05:15 AM, Aaron Goodman wrote: I noticed an issue where readChar does not return the correct value after a call to readline. It appears that readChar is not aware of the buffering, so it reads from the end of the buffer, rather than the current position in the file. This is a

Re: [Rd] user macros with multi-line arguments in Rd (was Re: Rd parser throws error for user macros invoked with empty argument)

Now in R-devel, Best, Tomas On 06/01/2018 11:33 AM, Tomas Kalibera wrote: Thanks for the report, I am testing a patch that will allow multi-line arguments to user macros. Best Tomas On 05/25/2018 04:45 PM, Georgi Boshnakov wrote: While on the topic of Rd macro arguments, it seems

[Rd] user macros with multi-line arguments in Rd (was Re: Rd parser throws error for user macros invoked with empty argument)

ignored: f <- tempfile() mac6 <- "\\newcommand{\\mac6}{mac6: #1}" cat(mac6, "\\mac6{2*3 2+2 sin(pi) }\n", file = f) rd <- tools::parse_Rd(f) rd mac6: 2*3 --- Georgi Boshnakov -Original Message- From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com] Sent:

Re: [Rd] encoding argument of source() in 3.5.0

Thanks for the report, fixed in R-devel (74848). Best Tomas On 06/04/2018 02:41 PM, NELSON, Michael wrote: On R 3.5.0 (Mac) The issue appears when using the default (libcurl) method and specifying the encoding Note that using method='internal' causes a segfault if used in conjunction with

Re: [Rd] encoding argument of source() in 3.5.0

Thanks, the fix is now in R-patched and will be included in 3.5.1. Tomas On 06/06/2018 09:54 PM, Stephen Berman wrote: On Tue, 5 Jun 2018 16:03:54 +0200 Tomas Kalibera wrote: Thanks for the report, fixed in R-devel (74848). Best Tomas FTR, I confirm that the problem I reported is now

Re: [Rd] Buffering in R 3.5 connections causes incorrect data in readChar

as changed in R-3.5. > > On Tue, May 29, 2018 at 3:09 AM, Tomas Kalibera > mailto:tomas.kalib...@gmail.com>> wrote: > > On 05/26/2018 05:15 AM, Aaron Goodman wrote: > > I noticed an issue where readChar does not return the correct > value after a >

Re: [Rd] Byte-compilation failure on different architectures / low-memory systems

Hi Dirk, thanks for the report. Access to the test system is not necessary, the memory requirements of the byte-code compiler are usually platform-independent and specifically with this package I can reproduce they are very high. We'll have a look what we can do, certainly there should at

Re: [Rd] DOCUMENTATION(?): parallel::mcparallel() gives various types of "Error in unserialize(r) : ..." errors if value is of type raw

Thanks for the report, fixed in documentation of mcparallel. Raw vectors are reserved for internal use and cannot be returned by expressions passed to mcparallel. But one can indeed wrap a raw vector into a list. FYI this internal use is not in readChild/mccollect, but in

Re: [Rd] Rgui 3.5.0 print issue

Fixed in R-devel and R-patched. Best Tomas On 06/13/2018 01:36 PM, Tomas Kalibera wrote: Thanks for the report, I can reproduce. In Rgui, the output of "print(cars)" is incorrect, the line numbers appear as part of the command prompt string (printed in reverse order, without newline

Re: [Rd] Bug in file.access on Windows when using network shares

Dear Nick, thank you for your report. In general one cannot know reliably in advance whether reading a file will work, if nothing else, there are possible race conditions with other applications and/or the system (e.g. a service may lock the file, move it away temporarily, etc). The only

Re: [Rd] Bug in RScript.exe for 3.5.0

lly port both the fix and the NEWS entry to R-patched. > > > On Sat, Apr 28, 2018 at 11:36 PM, Tomas Kalibera > <tomas.kalib...@gmail.com <mailto:tomas.kalib...@gmail.com>> wrote: > > > I don't have an opinion if this requires 3.5.1 to be released >

Re: [Rd] Bug in RScript.exe for 3.5.0

Fixed in R-devel. I will port to R-patched after more testing. Tomas On 04/26/2018 01:52 AM, Tomas Kalibera wrote: Thanks for the report. A quick workaround before this gets fixed is to add an extra first argument that has no space in it, e.g. Rscript --vanilla "foo bar.R" The prob

Re: [Rd] Bug in RScript.exe for 3.5.0

ached): [1] compiler_3.6.0 C:\> -Original Message- From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com] Sent: Thursday, April 26, 2018 10:22 AM To: Kerry Jackson <kerry.jack...@ipsos.com> Cc: r-devel@r-project.org Subject: Re: [Rd] Bug in RScript.exe for 3.5.0 Thanks, actually this is b

Re: [Rd] download.file does not process gz files correctly (truncates them?)

On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: Also, as mentioned in my https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when not specifying the mode argument, the default on Windows is mode = "w" *except* for certain, case-sensitive, filename extensions: if(missing(mode)

Re: [Rd] Bug: Issues on Windows with SFN disabled

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

Re: [Rd] Fixed BLAS tests for external BLAS library

, when we already have a > local solution (which I hoped others would be able to benefit from).  > Ah well. > > cheers, > Simon > > On 5 January 2018 at 00:07, Tomas Kalibera <tomas.kalib...@gmail.com > <mailto:tomas.kalib...@gmail.com>> wrote: >

Re: [Rd] Fwd: R/MKL Intel 2018 Compatibility

Hi Guillaume, In principle, mycrossprod function does not need to PROTECT "ans", because it does not call any allocating function after allocating "ans" ("dgemm" in particular should not allocate from the R heap). So it is surprising that PROTECTion makes a difference in your case. I agree

Re: [Rd] Buffer overflow in cairoBM.c line 402

Thanks for reporting - there is no need to reproduce this, it is an obvious error. I'll probably fix by throwing an error - like it is done in devX11.c when the file names are too long. Tomas On 01/19/2018 09:41 PM, Omri Schwarz wrote: Hi, all. Testing a change to that line to

Re: [Rd] Fortran programs not writing stdout on windows

For reference, this has been fixed in R-devel, 74168. The problem only exists on Windows with RGui. As a workaround for older versions of R, one can unset environment variables "GFORTRAN_STDOUT_UNIT" and "GFORTRAN_STDERR_UNIT" for the duration of system/system2 calls that invoke external

Re: [Rd] R CMD build then check fails on R-devel due to serialization version

To reduce difficulties for people relying on automated tests set up to build&"check --as-cran" using R-devel (e.g. travis-ci), the default serialization version has been temporarily switched back to 2. Thank you for your patience - according to svn history, the last change of the serialization

Re: [Rd] Error message: 'Rscript' should not be used without a path

Hi Michal, On 02/01/2018 09:23 AM, Michal Burda wrote: Dear R-devel members, recently, I ran into the following error message (R-devel 2018-01-31): 'Rscript' should not be used without a path -- see par. 1.6 of the manual I would like to know more about it, why is it required to run Rscript

Re: [Rd] makeCluster hangs

Also using R-devel might help - the forking support in parallel has been made more robust against race conditions, but the changes are probably too substantial to port to 3.4.x. If you find how to cause a race condition using parallel/forking in R-devel, a report would be greatly appreciated.

Re: [Rd] Setting the path to Rtools for package compilation on Windows

Thanks for the report - this has been already reported as bug 17376, it is caused by scripts that build the Windows binaries and by now has been fixed in R-patched and R-devel snapshot builds. So as a solution that works now I would recommend using R-patched. Tomas On 02/13/2018 08:33 AM,

Re: [Rd] Fix minor typo in error message from grDevices

Fixed, thanks, Tomas On 02/12/2018 09:33 PM, John Blischak wrote: > Hi, > > I fixed a minor typo in an error message from grDevices. Please see > attached for a patch to revision 74246. > > Thanks, > > John > > > __ > R-devel@r-project.org mailing list

Re: [Rd] R Compilation gets stuck on Windows 64

Please note that building R on Windows is documented in "R Installation and Administration", including links to external software. Particularly there is a link to texinfo which is part of Rtools. The documentation is maintained and it is a sufficient source of information for building R on

Re: [Rd] Warning from Sys.junction when using network drive.

Unfortunately, junctions cannot link to a network drive, they only can link directories on the same computer (possibly on different local volumes). This is a limitation imposed by Windows. I have updated the documentation for Sys.junction in R-devel accordingly. Tomas On 02/06/2018 10:50

Re: [Rd] How to modify dots and dispatch NextMethod

The example is invoking NextMethod via an anonymous function, which is not allowed (see documentation for NextMethod). Normally one gets a runtime error "'NextMethod' called from an anonymous function", but not here as the anonymous function is called via do.call. I will fix so that there is

Re: [Rd] How to modify dots and dispatch NextMethod

On 02/22/2018 02:31 PM, Iñaki Úcar wrote: 2018-02-22 12:39 GMT+01:00 Tomas Kalibera <tomas.kalib...@gmail.com>: On 02/22/2018 12:07 PM, Iñaki Úcar wrote: 2018-02-22 10:29 GMT+01:00 Tomas Kalibera <tomas.kalib...@gmail.com>: The example is invoking NextMethod via an anonymous fun

Re: [Rd] How to modify dots and dispatch NextMethod

On 02/22/2018 12:07 PM, Iñaki Úcar wrote: 2018-02-22 10:29 GMT+01:00 Tomas Kalibera <tomas.kalib...@gmail.com>: The example is invoking NextMethod via an anonymous function, which is not allowed (see documentation for NextMethod). Thanks for your response. I definitely missed th

Re: [Rd] readLines interaction with gsub different in R-dev

Thank you for the report and analysis. Now fixed in R-devel. Tomas On 02/17/2018 08:24 PM, William Dunlap via R-devel wrote: I think the problem in R-devel happens when there are non-ASCII characters in any of the strings passed to gsub. txt <- vapply(list(as.raw(c(0x41, 0x6d, 0xc3, 0xa9,

Re: [Rd] Unnecessary lines in stem.c?

Thanks! Cleaned up in R-devel, Tomas On 02/16/2018 05:03 PM, S Ellison wrote: A discussion on r-help led me to look at stem.c at https://github.com/wch/r-source/blob/trunk/src/library/graphics/src/stem.c Lines 76-77 appear superfluous. They sit inside a condition, and set mu, as follows:

Re: [Rd] writeLines argument useBytes = TRUE still making conversions

I think it is as Kevin described in an earlier response - the garbled output is because a UTF-8 encoded string is assumed to be native encoding (which happens not to be UTF-8 on the platform where this is observed) and converted again to UTF-8. I think the documentation is consistent with

Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

Bug 17159 has been fixed (in R-devel), but there may be more issues left with UNC paths. Tomas On 01/17/2018 01:37 PM, Joris Meys wrote: Hi Peter, I share your experience with trying to help IT departments setting things up. The network directory of the students is mapped to a drive, but R

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

There is a simple way to achieve something similar: one can add a time stamp to each line of output, e.g. using "ts" command from "moreutils". Tomas On 12/21/2017 06:45 PM, Jim Hester wrote: R does provide the addTaskCallback / taskCallbackManager to run a callback function after every top

Re: [Rd] Problem with parseData

Dear Barbara, thank you for the report. This is something to be fixed in R - I am now testing a patch that adds the extra node for the equality assignment expression. Best, Tomas On 07/30/2018 05:35 PM, Barbara Lerner wrote: Hi, I have run into a problem with parseData from the utils

Re: [Rd] Package compiler - efficiency problem

ank you for suggestions for improvement in our approach, i am going > to discuss them with other package developers. > > Regards, > Karol Podemski > > pon., 13 sie 2018 o 18:02 Tomas Kalibera <mailto:tomas.kalib...@gmail.com>> napisał(a): > > Dear Karol, >

Re: [Rd] Package compiler - efficiency problem

Dear Karol, thank you for the report. I can reproduce that the function from you example takes very long to compile and I can see where most time is spent. The compiler is itself written in R and requires a lot of resources for large functions (foo() has over 16,000 lines of code, nearly 1

Re: [Rd] SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

R's dyn.unload() will unconditionally unload the given shared object; it does not check whether there is any object (external pointer or weak reference) with a C finalizer pointing into the space of the shared object being unloaded. So it is expected that R will segfault later when such

Re: [Rd] SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

On 9.8.2018 20:58, Dirk Eddelbuettel wrote: On 9 August 2018 at 20:37, Tomas Kalibera wrote: | So to answer your original question, this could probably be handled in | Rcpp, Hm. Why do you say that / what did you have in mind? Recall that we do not alter SEXPs or introduce additional

Re: [Rd] SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

a corolary would be, can't R on Windows do the same? Regards, Iñaki El jue., 9 ago. 2018 a las 21:13, escribió: On Thu, 9 Aug 2018, Dirk Eddelbuettel wrote: On 9 August 2018 at 20:37, Tomas Kalibera wrote: | So to answer your original question, this could probably be handled in | Rcpp, Hm.

Re: [Rd] odd behavior of names

Both bugs should now be fixed in R-devel. The first one was causing the difference between the first and the following element. The second one was causing the printing of unnecessary backticks, inconsistently with Unix systems. Best Tomas On 07/30/2018 09:32 AM, Martin Maechler wrote:

Re: [Rd] Get Logical processor count correctly whether NUMA is enabled or disabled

Dear Arun, thank you for the report. I agree with the analysis, detectCores() will only report logical processors in the NUMA group in which R is running. I don't have a system to test on, could you please check these workarounds for me on your systems? # number of logical processors - what

Re: [Rd] Get Logical processor count correctly whether NUMA is enabled or disabled

ing a process on more than 1 processor group has come up - https://github.com/axboe/fio/issues/527 and is addressed - https://github.com/axboe/fio/blob/c479640d6208236744f0562b1e79535eec290e2b/os/os-windows-7.h . I am not sure though if this is entirely relevant since we would be forking new

  1   2   3   4   5   6   >