I believe the technique is to create an environment in the namespace,
and then to access that through functions:
sandbox/NAMESPACE
export(getx, setx)
sandbox/R/sandbox.R:
sandbox <- new.env(parent=emptyenv())
getx <- function() sandbox$x
setx <- function(val) sandbox$x <- val
> library(sandbox)
It is a problem by stack smashing protector.
--- src/modules/X11/dataentry.c.orig2006-09-04 23:41:34.0 +0900
+++ src/modules/X11/dataentry.c 2006-10-18 11:31:43.0 +0900
@@ -1046,7 +1046,7 @@
for(j=0;*(wcspc+j)!=L'\0';j++)wcs[j]=*(wcspc+j);
wcs[j]=L'\0';
On Oct 17, 2006, at 8:33 PM, Martin Morgan wrote:
>> delayMe <- function() {
> + if (failed) {
> + delayedAssign("x", delayMe(), assign.env=topenv())
> + stop("init me!")
> + } else foo
> + }
>>
>> failed <- TRUE
>> foo <- "is me"
>> delayedAssign("x", delayMe())
>> x
> Er
Hi
[EMAIL PROTECTED] wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enig308510A16A445880F353C5C9
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
>
> to trigger the bug:
>
> plot(0:1,0:1)
> text(0.5,0.5,"abc",sr
> delayMe <- function() {
+ if (failed) {
+ delayedAssign("x", delayMe(), assign.env=topenv())
+ stop("init me!")
+ } else foo
+ }
>
> failed <- TRUE
> foo <- "is me"
> delayedAssign("x", delayMe())
> x
Error in delayMe() : init me!
> x
Error in delayMe() : init me!
> faile
Is there a way to raise an error condition when a promise is
evaluated such that is can be evaluated again? Right now strange
things happen when the evaluation fails:
> delayedAssign("x", if (failed) stop("you have to initialize me
first!") else foo)
> foo <- "I'm foo"
> failed<-TRUE
> x
zoo.ufl.edu> writes:
> to trigger the bug:
>
> plot(0:1,0:1)
> text(0.5,0.5,"abc",srt=-1e-9)
>
> this doesn't happen for positive, small srt,
> or for negative srt with magnitude greater
> than about 1e-8 (the example in plot.phylo
> in the ape package triggers it, with a
> srt value of -3e-1
showMethods isn't reporting inherited methods when it is first
called. The methods are there and after calling them, showMethods
gives the right output.
Here is an example (using R-devel r39647):
setClass("A", representation(x="numeric"),
prototype=list(x=1))
setClass("B", contains="A"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig308510A16A445880F353C5C9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
to trigger the bug:
plot(0:1,0:1)
text(0.5,0.5,"abc",srt=3D-1e-9)
this doesn't happen for positive, smal
[This is a follow up on gcc3 vs. gcc4 discussion. Background: R
benchmark tests ( http://www.sciviews.org/benchmark/index.html ) show
a dramatic difference in "Escoufier's method on a 37x37 matrix
(mixed)" test when comparing binaries for PowerPC compiled with gcc3
vs gcc4.]
On Oct 16, 20
Hi Ben,
I like the odd looking notches, they reveal
that the data comprising the box plot need
more careful review.
Tukey et al (1) comment that
"It should be noted that the convention has been
adopted that, should the notch lie outside either
hinge, an unnotched box, plotted with dashed lines,
"Richard M. Heiberger" <[EMAIL PROTECTED]> writes:
> I inadvertently had the same function name defined in two different
> .R files. Can you add a test for that to the check program and
> issue a warning?
Please, not without a flag asking for such a check/warning.
There are reasonable cases whe
Hi all,
I'm Pierre Lindenbaum and I'm new to 'R'.
I'm currently working with a colleague who has created a java bioinformatic
tool using 'R' . No problem : we work on linux, we call 'R' using a system call
via java.lang.Runtime.exec, we know the $path to 'R', etc...
But now, we would like to di
I inadvertently had the same function name defined in two different
.R files. Can you add a test for that to the check program and
issue a warning?
Thanks
Rich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Ben Bolker zoo.ufl.edu> writes:
>
> Synopsis: boxplot notches look weird when notches
> are greater than hinges ((1.58*IQR/sqrt(n)) > approx IQR).
> When log="y" this causes an error. Below are several
> reproducible examples, some discussion, and a patch against
> calc.R.
>
> Please feel
On Tue, 17 Oct 2006, Hin-Tak Leung wrote:
> Thomas Lumley wrote:
>> On Mon, 16 Oct 2006, [EMAIL PROTECTED] wrote:
>>
>>> This is a rather interesting, but I don't think it is a bug - it is
>>> just things that "you are not supposed to do"
>>
>> It was a bug. It has been fixed in R 2.4.0. Unfortuna
Thomas Lumley wrote:
> On Mon, 16 Oct 2006, [EMAIL PROTECTED] wrote:
>
>> This is a rather interesting, but I don't think it is a bug - it is
>> just things that "you are not supposed to do"
>
> It was a bug. It has been fixed in R 2.4.0. Unfortunately, since you
> didn't quote the PR# of the or
17 matches
Mail list logo
