I am looking for a way to generate .Rout.save files for vignettes.
The manual "Writing R Extensions" states here [1] in item number 20:
"If there is a target output file .Rout.save in the vignette source
directory, the output from running the code in that vignette is compared
with the target ou
On 12-12-10 11:45 AM, Benjamin Hofner wrote:
I am looking for a way to generate .Rout.save files for vignettes.
The manual "Writing R Extensions" states here [1] in item number 20:
"If there is a target output file .Rout.save in the vignette source
directory, the output from running the code in
But note that this was added at the request of one package author. We
don't generally recommended it, not least as people do not take
sufficient care about platform differences and keeping such output up to
date. So people (including authors) tend to simply ignore a mass of
differences.
It
Dear all,
The background is that I'm trying to fix this bug in the geometry
package:
https://r-forge.r-project.org/tracker/index.php?func=detail&aid=1993&group_id=1149&atid=4552
Boiled down, the problem is that there exists at least one matrix X for
which det(X) != 0 and for which solve(X) fails
Dear David,
I can think of two strategies for dealing with this problem:
>
> Strategy 1: Some code like this:
>if (det(X) < epsilon) {
> warning("Near singular matrix")
> return(NULL)
>}
>return(solve(X))
This solution is probably the easiest one to take, but to match
sol
(Sorry for the repeat message; I forgot to send the previous message
in plain text.)
I've been using mclapply and have encountered situations where it
gives errors or returns incorrect results. Here's a minimal example,
which gives the error on R 2.15.2 on Mac and Linux:
library(parallel)
f <- fu
On 12-12-11 9:41 AM, Prof Brian Ripley wrote:
But note that this was added at the request of one package author. We
don't generally recommended it, not least as people do not take
sufficient care about platform differences and keeping such output up to
date. So people (including authors) tend t
On 11/12/2012 17:27, Duncan Murdoch wrote:
On 12-12-11 9:41 AM, Prof Brian Ripley wrote:
But note that this was added at the request of one package author. We
don't generally recommended it, not least as people do not take
sufficient care about platform differences and keeping such output up to
Hi R-devel, tcltk devel, and sqldf devel,
The transcript below shows how loading the tcl/tk library in under R causes
subprocesses to ignore SIGPIPE.
I am including the developer of the (wonderful) sqldf package since it requires
tcltk and you might like to make this dependence optional to the
On Tue, Dec 11, 2012 at 3:14 PM, Cook, Malcolm wrote:
> Hi R-devel, tcltk devel, and sqldf devel,
>
> The transcript below shows how loading the tcl/tk library in under R causes
> subprocesses to ignore SIGPIPE.
>
> I am including the developer of the (wonderful) sqldf package since it
> require
Excellent, thanks for the workaround, that gets _me_ by, for now.
~Malcolm
> -Original Message-
> From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com]
> Sent: Tuesday, December 11, 2012 2:40 PM
> To: Cook, Malcolm
> Cc: r-discuss...@listserv.stowers.org; r-devel@r-project.org;
On Dec 11, 2012, at 23:50 , Cook, Malcolm wrote:
> Excellent, thanks for the workaround, that gets _me_ by, for now.
The real issue is probably yet another symptom of something that can be
described as insufficient separation between the R engine and its GUI
components. Or: One process try
12 matches
Mail list logo
