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 lev
on making this work, 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 <mailto:tomas.kalib...@gmail.com>> wrote:
>
> Hi Simon,
>
>
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
the
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
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
strncpy(x
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 Fortr
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 w
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 PM
Thanks, this has been already reported as bug 17358. Addressed in
R-devel 74238. R may still create a corrupt file, though, in other
circumstances (e.g. if it runs out of memory or is interrupted during
serialization, etc).
Tomas
On 02/07/2018 04:14 PM, Kenny Bell wrote:
I ran into this beha
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 Wind
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.
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, Sø
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
>
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 sti
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 th
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, 0x6c,
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:
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
On 02/22/2018 12:07 PM, Iñaki Úcar wrote:
2018-02-22 10:29 GMT+01:00 Tomas Kalibera :
The example is invoking NextMethod via an anonymous function, which is not
allowed (see documentation for NextMethod).
Thanks for your response. I definitely missed that bit.
Normally one gets a runtime
On 02/22/2018 02:31 PM, Iñaki Úcar wrote:
2018-02-22 12:39 GMT+01:00 Tomas Kalibera :
On 02/22/2018 12:07 PM, Iñaki Úcar wrote:
2018-02-22 10:29 GMT+01:00 Tomas Kalibera :
The example is invoking NextMethod via an anonymous function, which is
not
allowed (see documentation for NextMethod
Thank you, Martin, for spotting this, it is clearly a bug, originally a
conformance check was intended here and time series were defined using
integers, so exact comparison would have made sense. Now time series are
defined using doubles and exact comparison could be too strict with
rounding er
Dear Christian and Henrik,
thank you for spotting the problem and suggestions for a fix. We'll
probably add a chunk.size argument to parLapplyLB and parLapply to
follow OpenMP terminology, which has already been an inspiration for the
present code (parLapply already implements static schedulin
us know ;)
Best Regards
On 02/26/2018 04:01 PM, Tomas Kalibera wrote:
Dear Christian and Henrik,
thank you for spotting the problem and suggestions for a fix. We'll probably
add a chunk.size argument to parLapplyLB and parLapply to follow OpenMP
terminology, which has already be
On 03/15/2018 05:25 PM, Henrik Bengtsson wrote:
On Thu, Mar 15, 2018 at 3:39 AM, wrote:
Thank you for your answer!
I agree with you except for the 3 (Error) example and
I realize now I should have started with that in the explanation.
From my point of view
parLapply(cl = clu, X = 1:2, fun =
R uses long double type for the accumulator (on platforms where it is
available). This is also mentioned in ?sum:
"Where possible extended-precision accumulators are used, typically well
supported with C99 and newer, but possibly platform-dependent."
Tomas
On 03/16/2018 06:08 PM, Pierre Chau
Fixed in R-devel (74418).
Tomas
On 03/15/2018 08:57 PM, Tomas Kalibera wrote:
On 03/15/2018 05:25 PM, Henrik Bengtsson wrote:
On Thu, Mar 15, 2018 at 3:39 AM, wrote:
Thank you for your answer!
I agree with you except for the 3 (Error) example and
I realize now I should have started with that
Thanks for spotting this, fixed in R-devel (including the Windows version).
Tomas
On 03/18/2018 09:53 PM, Henrik Bengtsson wrote:
For the record, I've just filed the following bug report with a patch
to https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17395:
tools::pskill() returns either
On 03/19/2018 02:23 PM, Detlef Steuer wrote:
Dear friends,
I stumbled into beheaviour of read.delim which I would consider a bug
or at least an inconsistency that should be improved upon.
Recently we had to work with data that used "", two double quotes, as
symbol to start and end character inp
On 03/27/2018 09:51 AM, Iñaki Úcar wrote:
2018-03-27 6:02 GMT+02:00 :
This has nothing to do with printing or dispatch per se. It is the
result of an internal register (R_ReturnedValue) being protected. It
gets rewritten whenever there is a jump, e.g. by an explicit return
call. So a simplified
On 03/27/2018 11:53 AM, Iñaki Úcar wrote:
2018-03-27 11:11 GMT+02:00 Tomas Kalibera :
On 03/27/2018 09:51 AM, Iñaki Úcar wrote:
2018-03-27 6:02 GMT+02:00 :
This has nothing to do with printing or dispatch per se. It is the
result of an internal register (R_ReturnedValue) being protected. It
Thanks! Fixed in R-devel,
Tomas
On 03/26/2018 03:22 PM, Korpela Mikko (MML) wrote:
I stumbled upon a typo in a time zone name: Irtutsk should be Irkutsk.
A patch is attached. I also checked that this is the only bug of its
kind in this file, i.e., all the other Olson time zones occurring in
the
Thanks, fixed in R-devel (by checking validity of UTF-8 strings for
substr/substring).
Tomas
On 03/29/2018 03:53 AM, brodie gaslam via R-devel wrote:
I think there is a memory bug in `substr` that is triggered by a UTF-8 corner
case: an incomplete UTF-8 byte sequence at the end of a string. W
On 03/28/2018 08:31 AM, Jialin Ma wrote:
Dear all,
It seems that as.pairlist does not convert call objects, producing
results like the following:
is.pairlist(as.pairlist(quote(x + y)))
[1] FALSE
Should this behavior be expected?
The documentation says that the behavior of as.pairlist is und
Thanks, fixed in R-devel.
Tomas
On 12/20/2017 02:38 PM, Gábor Csárdi wrote:
It does give a warning, but then it overwrites the files, anyway.
Reproducible example below.
This is R 3.4.3, but it does not seem to be fixed in R-devel:
https://github.com/wch/r-source/blob/4a9ca3e5ac6b19d7faa7c92903
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 this (I do not
have a system to reproduce on). A user-targeted advice would be to use
RGui (Rgui.exe).
Does the problem also exist in R-devel?
https://cran.r-project.org
Thanks for the report, fixed in R-devel.
Best,
Tomas
On 04/05/2018 05:01 PM, Gábor Csárdi wrote:
This is a recent R-devel. file.copy() is not vectorized if multiple
destinations succeed:
cat("foo1\n", file = "foo1")
cat("foo2\n", file = "foo2")
unlink(c("copy1", "copy2"), recursive = TRUE)
fi
Hi Vladimir,
thanks for your report - this was really a bug, now fixed in R-devel and
to appear in 3.5.0.
Apart from the bug, having source files in UTF-8 and reading them into R
on Windows is perfectly fine, you just need to specify that they are in
UTF-8. You also need to make sure R is ru
Hi Patrick,
thanks for your comments on the bug, just to clarify - one could
reproduce the bug simply using file() and readLines(). The parser saw a
real end of file as (incorrectly) communicated to it by lower level
connections code - there is no design issue related in the parser (nor
elsew
Thanks for the report, fixed in R-devel. Now we get a warning when
copying a directory over a non-directory file is attempted. The target
(non-directory) file is left alone.
Tomas
On 09/08/2017 06:54 PM, William Dunlap via R-devel wrote:
When I mistakenly use file.copy() with a directory for
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 in R that is limiting my capabilities to
export a matrix with write.csv or write.table with over 2,147,483,648
elements (C's int limit). I found this bug already reported a
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 in R that is limiting my capabilities to
export a matrix with write.csv or
AVE_VERSION=2 and
R_DEFAULT_SERIALIZE_VERSION=2). These frameworks could also be tested
before the change by running with R_DEFAULT_SAVE_VERSION=3 and
R_DEFAULT_SERIALIZE_VERSION=3.
Best
Tomas
On 01/13/2018 01:35 AM, Tomas Kalibera wrote:
To reduce difficulties for people relying on autom
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 problem exists on all systems, not just Windows.
Best
Tomas
On 04/25/2018 09:55 PM, Kerry Jackson wrote:
Hi R Developers,
I have
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
source code.
Thanks, Kerry.
There are binary builds for daily snapshots of R-devel
(development/unstable version of R) at
https://cran.r-project.org/bin/windows/base/rdevel.html
At this time the build should already have the fix.
Best
Tomas
-Original Message-
From: Tomas Kalibera
le or directory
C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" --vanilla "C:\foo bar.R"
What do you get when you multiply 6 * 9?
C:\>
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: Thursday, April 26, 2018 8:35 AM
To: Ker
C:\>
-----Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: Thursday, April 26, 2018 10:22 AM
To: Kerry Jackson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
Thanks, actually this is because the snapshot build is still one version behi
both the fix and the NEWS entry to
R-patched.
>
>
> On Sat, Apr 28, 2018 at 11:36 PM, Tomas Kalibera
> mailto:tomas.kalib...@gmail.com>> wrote:
>
>
> I don't have an opinion if this requires 3.5.1 to be released
> soon(er), but I have porte
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) &&
ost, may be related to this mechanism.
If you need further information, please let me know.
Thanks,
i...@azurefx.name
Tomas Kalibera 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 this (I do not have a s
On 05/08/2018 05:15 PM, Hadley Wickham wrote:
On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera
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 the mode argument, the default on
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
-Alkuperäi
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 runni
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
On 05/22/2018 06:07 PM, Gábor Csárdi wrote:
On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera
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/unset the
other debug
mark.
I asked
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 'CHARS
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 (https://github.com/stan-de
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 signif
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
>
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 hav
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:
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 lea
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 that if a
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
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
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 ha
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
B
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
wholeSrcref attribute is documented in ?parse to be the source reference
corresponding to the already parsed text. The implementation in the
parser matches the documentation - the code stops at the last
byte/character of the expression, that is, on the closing brace - which
is the "already pars
Dear Dario,
this question may be more suitable for R-pkg-devel or perhaps R-help
list, if you have subsequent questions, you might get better advice
there. In short, save() does no automated selection of a compression
algorithm - it just uses the one specified, by default "gzip". For
automate
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
sendMaster/mcparallel
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
co
On 07/17/2018 12:56 PM, Joshua Ulrich wrote:
This looks like a case of FAQ 7.42:
https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-is-R-apparently-not-releasing-memory_003f
Yes. A true memory leak in R would mean that repeated execution of the
same code (e.g. creation and deletion of the list) w
Hi Kevin,
the extra bytes you are seeing are escapes for UTF-8 strings used in
input to RGui console. Recently ascii strings are converted to UTF-8 so
you would get these escapes for ascii strings now as well. RGui
understands these escapes and converts from UTF-8 to wide characters
before pr
o print an empty list,
> 2) You need to invoke save() after printing that empty list,
> 3) Then, attempts to call encodeString() will produce the strange output.
>
> For what it's worth, it may be related to a behavior I'm seeing where
> the first name printed for an R
Fixed in R-devel and R-patched,
Tomas
On 07/18/2018 12:03 PM, Tomas Kalibera wrote:
> Thanks, I can now reproduce and it is a bug that is easy to fix, I
> will do so shortly.
>
> Fyi it can be reproduced simply by running these two lines in Rgui:
>
> list()
> encodeStr
Yes, the performance overhead of fixing this at R level would be too
large and it would complicate the code significantly. The result of
binary operations involving NA and NaN is hardware dependent (the
propagation of NaN payload) - on some hardware, it actually works the
way we would like - NA
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 fina
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
mpared to Windows? :) And 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 proba
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 mil
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 packa
s.
>
> Thank 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
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:
Wil
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 de
'fio' where the issue of running 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
On 08/31/2018 01:18 AM, Henrik Bengtsson wrote:
Hi, I'd like to test whether a (localhost) PSOCK cluster node is still
running or not by its PID, e.g. it may have crashed / core dumped.
I'm ok with getting false-positive results due to *another* process
with the same PID has since started.
kill(s
On 08/31/2018 03:13 PM, Gábor Csárdi wrote:
On Fri, Aug 31, 2018 at 2:51 PM Tomas Kalibera wrote:
[...]
kill(sig=0) is specified by POSIX but indeed as you say there is a race
condition due to PID-reuse. In principle, detecting that a worker
process is still alive cannot be done correctly
Please don't do this to get the underlying vector length (or to achieve
anything else). Setting/deleting attributes of an R object without
checking the reference count violates R semantics, which in turn can
have unpredictable results on R programs (essentially undebuggable
segfaults now or mor
luster to have 65 processors, a loop with 64
> iterations seem to complete as expected, but using all 65 processors to loop
> over 65 iterations didn't seem to complete. I stopped it after ~5mins. The
> same happens with the cluster started with any number between 65 and 88. It
>
On 09/03/2018 03:59 PM, Dénes Tóth wrote:
Hi Tomas,
On 09/03/2018 11:49 AM, Tomas Kalibera wrote:
Please don't do this to get the underlying vector length (or to
achieve anything else). Setting/deleting attributes of an R object
without checking the reference count violates R semantics,
On 08/24/2018 07:55 PM, Henrik Bengtsson wrote:
Is there a low-level function that returns the length of an object 'x'
- the length that for instance .subset(x) and .subset2(x) see? An
obvious candidate would be to use:
.length <- function(x) length(unclass(x))
However, I'm concerned that calli
in primitives. But a partial solution could be implemented at
some point with ALTREP wrappers when one could without copying create a
wrapper object with a modified class attribute.
Tomas
Iñaki
El mié., 5 sept. 2018 a las 10:09, Tomas Kalibera
() escribió:
On 08/24/2018 07:55 PM, Henrik
Hello Irene,
we can only change the documented behavior when there is a very strong
reason to do so, because it indeed can break existing code. A lot of
existing code would depend on the current behavior, using e.g. nzchar()
to check the output of system.file(). Changing the behavior that is u
Thanks, Tomas
On 09/19/2018 06:15 AM, Colin Gillespie wrote:
Hi,
Section 3.2 of the R-admin manual
https://cran.ma.imperial.ac.uk/doc/manuals/r-release/R-admin.html#Testing-a-Windows-Installation
could be improved. The particular sentence is
The Rtools are not needed to run these tests. but
I don't think this is possible. If you would like e.g. stricter checking
for --max-ppsize argument value, please try to come up with some example
that triggers such case.
Tomas
On 09/29/2018 06:41 PM, Henrik Bengtsson wrote:
Hi,
for simply for troubleshooting purposes (e.g. making sure that
The fix is now in R-devel, 75386. I have not ported to R-patched,
because the fix breaks two packages which are working around this bug
(and to my knowledge without having reported it before). So thanks again
for the report!
Best
Tomas
On 08/16/2018 10:06 AM, Tomas Kalibera wrote:
Dear
Thanks for the report, but unfortunately I cannot reproduce on my system
(either macOS nor Linux, from the command line) to debug. Did you run
this in the command line version of R?
I would not be surprised to see such a crash if executed from a
multi-threaded application, say from some GUI
I've checked in an experimental fix for this (75413). The newline was
lost in the shell script wrapper for R, it is now being escaped
similarly to space. To pass multiple commands to Rscript, one can also
use "-e" multiple times.
Tomas
On 09/17/2018 01:09 PM, Duncan Murdoch wrote:
On 16/09/2
Hi Paul,
thanks for the report. Fixed in R-devel 75417.
Best
Tomas
On 07/04/2018 10:08 PM, Paul Schrimpf wrote:
Hello,
I encountered some unexpected behavior of unzip when using info-zip's unzip
instead of R's internal program. Specifically, unzip("file.zip", list=TRUE,
unzip=/usr/bin/unzip)
1 - 100 of 487 matches
Mail list logo
