Re: [Rd] PR#9299:Re: Bugs with partial name matching during partial replacement (PR#9299)
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 original bug in the subject line you have > just filed a new bug report for it. > > -thomas I am sorry (about both the duplicate report and the comment). I don't know what happened with the duplication - but as you see I replied to both r-devel and r-bugs in the same e-mail, and the one arriving back via r-devel did have the right subject with the PR#9202 at the end, and the other copy via r-bugs didn't and got a new one. It seems somewhere during in the round-trip over-long subject lines get truncated and/or a new-line inserted in the middle. May worth investigating... Regards, Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PR#9299:Re: Bugs with partial name matching during partial replacement (PR#9299)
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. Unfortunately, since you >> didn't quote the PR# of the original bug in the subject line you have >> just filed a new bug report for it. >> >> -thomas > > I am sorry (about both the duplicate report and the comment). > > I don't know what happened with the duplication - but as you see > I replied to both r-devel and r-bugs in the same e-mail, and the > one arriving back via r-devel did have the right subject with > the PR#9202 at the end, and the other copy via r-bugs didn't and > got a new one. It seems somewhere during in the round-trip > over-long subject lines get truncated and/or a new-line inserted in > the middle. May worth investigating... We know you need to have the PR# number on the first line of the subject. This is why Thomas duplicated it (and I move it to the beginning). At one time JitterBug had a higher version number than R, and at around that time it seemed to be orphaned. Now R > 2.4.0, and JitterBug is still at 1.6.2. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot, notches, etc.
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 free to say "this is just cosmetic/isn't an issue, go > away" ... > > cheers > Ben Bolker > followup (one week later): does anyone have any opinions on this ... ??? (If someone will tell me this isn't worth pursuing, I will give up on it) Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] request for additional test in R CMD check
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
[Rd] R and JAVA
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 distribute our java application as a *.jar archive and I wondered what is the best way to install it on window: is there a way to embed 'R' in my java archive ? can I install 'R' on windows from my java archive ? what is the best way to call 'R' from java. Can I avoid this system call ?...etc... Any help will be appreciated :-) Thanks in advance. Pierre __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] request for additional test in R CMD check
"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 where a function is redefined based on available packages, for example. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot, notches, etc.
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, is displayed for that group indicating low confidence in it." While this convention appears to have been abandoned, the wierd-looking notches indicate a group with odd behaviour warranting more careful consideration. So I vote to retain odd-looking notches. Et al and Tukey (1) discuss their reasoning and empirical findings as to the formulation for the notch width. They used median +/- 1.7(1.25R/1.35sqrt(N)) which reduces to median +/- 1.574*(IQR)/sqrt(N) Perhaps similar reasoning can resolve the issue of notches for boxplots of log(y)? I'll see if I can work through the normal - lognormal transformation machinery and propose a reasonable notch strategy for the log(y) case. Maybe someone out there has already done so? (1) R. McGill, J. Tukey, W. Larsen (1978) "Variations of Box Plots" The American Statistician, Vol. 32, No. 1, pp 12-16 http://www.jstor.org/view/00031305/di020553/02p0045u/0 Cheers Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: [EMAIL PROTECTED] tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada -Original Message- From: [EMAIL PROTECTED] on behalf of Ben Bolker Sent: Tue 10/17/2006 6:09 AM To: r-devel@stat.math.ethz.ch Subject: Re: [Rd] boxplot, notches, etc. 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 free to say "this is just cosmetic/isn't an issue, go > away" ... > > cheers > Ben Bolker > followup (one week later): does anyone have any opinions on this ... ??? (If someone will tell me this isn't worth pursuing, I will give up on it) Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] performance reflections
[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, 2006, at 11:29 AM, René J.V. Bertin wrote: Anyway, it has nothing to do with the G4 optimisations, as the generic 2.4.0 on CRAN also shows the same performance drop. Thanks for the example. I think I have a clarification on this. On a higher level it's happening in "do_cov", but the underlying issue is the use of "long double" computations. First the results: The timings I get (on 2xG5 2.7GHz) are: gcc3: 0.8s gcc4: 4.5s (dynamic libgcc) gcc4: 4.2s (static libgcc) Basically any calls that use long double will be affected: qadd: 4.5s (gcc3 opt), 6.7s (Agcc4 opt), 7.4s (gcc3), 7.9s (gcc4 opt +dyngcc), 10.5s (Agcc4), 10.6s (gcc4 dyngcc) (this test basically runs 500x 1M long double additions on an array - it's even more extreme if you run it on short arrays : 250kx1k will give 2s on gcc3 and 7.7s on gcc4) Now, the actual reason is that gcc3 simply ignores "long double" and performs all computation using regular double precision (sizeof(long double)=8 in gcc3 and 16 in gcc4). What this means is that you lose precision in gcc3. To illustrate the impact, changing "long double" to "double" in gcc4 will bring the 250kx1k test down from 7.7s to 2.1s which is almost the same as gcc3. Thus, restricting R to double computations I get for the 37x37 test with gcc 4.0.3: gcc4nld: 0.7s which is actually even faster than the gcc3 result. Attached you will find the R benchmarks 2.3 results (ran with R 2.4.0) - there is pretty much no difference between the binaries except for the 37x37 test and the explanation is above. Cheers, Simon I. Matrix calculation gcc3 gcc4d CRAN - Creation, transp., deformation of a 1500x1500 matrix (sec): 1.42 1.37 1.48 800x800 normal distributed random matrix ^1000__ (sec): 0.10 0.11 0.11 Sorting of 2,000,000 random values__ (sec): 0.36 0.34 0.34 700x700 cross-product matrix (b = a' * a)___ (sec): 0.057 0.057 0.058 Linear regression over a 600x600 matrix (c = a \ b') (sec): 0.090 0.090 0.090 Trimmed geom. mean (2 extremes eliminated): 0.149 0.148 0.149 II. Matrix functions FFT over 800,000 random values__ (sec): 0.76 0.76 0.77 Eigenvalues of a 320x320 random matrix__ (sec): 0.33 0.33 0.32 Determinant of a 650x650 random matrix__ (sec): 0.068 0.068 0.066 Cholesky decomposition of a 900x900 matrix__ (sec): 0.102 0.103 0.104 Inverse of a 400x400 random matrix__ (sec): 0.051 0.055 0.052 Trimmed geom. mean (2 extremes eliminated): 0.131 0.133 0.131 III. Programmation -- 750,000 Fibonacci numbers calculation (vector calc)_ (sec): 0.44 0.44 0.47 Creation of a 2250x2250 Hilbert matrix (matrix calc) (sec): 1.87 1.80 1.97 Grand common divisors of 70,000 pairs (recursion)___ (sec): 0.31 0.32 0.34 Creation of a 220x220 Toeplitz matrix (loops)___ (sec): 0.36 0.35 0.35 Escoufier's method on a 37x37 matrix (mixed) (sec): 2.37 2.27 5.76 Trimmed geom. mean (2 extremes eliminated): 0.667 0.654 0.683 Total time for all 15 tests_ (sec): 8.68 8.47 12.27 Overall mean (sum of I, II and III trimmed means/3)_ (sec): 0.236 0.234 0.237 --- End of test --- --- gcc3 = Apple gcc-3.3 + g77 3.4.6 + -O9 + -mtune=G5 (R24-branch 39648) gcc4d = CRAN gcc 4.0.3 + #undef HAVE_LONG_DOUBLE + -O9 + -mtune=G5 (R24-branch 39648) CRAN = CRAN binary 2.4.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] plotting text with very small negative rotation hangs (PR#9301)
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, 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-15).
plot(0:1,0:1)
for (i in 1:10) {
cat(i,"\n")
text(0.5,0.5,"hello",srt=3D(-10^-i))
}
I have traced this a fair ways into
the C code -- I think it happens somewhere
in clipText -- but I'm not sure. Sorry not
to be able to provide a fix at the moment.
This is on Ubuntu 6.06, not sure whether
it affects other platforms or not ...
Ben Bolker
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 4.0
year 2006
month 10
day03
svn rev39566
language R
version.string R version 2.4.0 (2006-10-03)
--enig308510A16A445880F353C5C9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNV75c5UpGjwzenMRAhu9AKCVHQ3khVCj1skWyn8wCHl2w0nkbQCfdct5
zehYhcbw2bazsjuTvX9eAIk=
=CL1h
-END PGP SIGNATURE-
--enig308510A16A445880F353C5C9--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Caching bug with showMethods?
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",
prototype=list(x=2))
setMethod("initialize", "A",
function(.Object) {
cat("In A's init\n")
[EMAIL PROTECTED] <- [EMAIL PROTECTED] + 1
.Object
})
setMethod("show", "A",
function(object) cat("An A like thing. x =", [EMAIL PROTECTED], "\n"))
showMethods(classes="B") ## should give output, but doesn't
showMethods(classes="A")
aa <- new("A")
bb <- new("B")
aa
bb
## Now it will give output
showMethods(classes="B")
--
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotting text with very small negative rotation hangs (PR#9301)
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-15).
>
> plot(0:1,0:1)
> for (i in 1:10) {
> cat(i,"\n")
> text(0.5,0.5,"hello",srt=(-10^-i))
> }
>
>
There were some "3D"s inserted after
the equals signs. I don't know what that
is -- some kind of encoding issue ... ??
sorry 'bout that
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error condition in evaluating a promise
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
Error: you have to initialize me first!
> x
Error: recursive default argument reference
^^-- from now on x is completely unusable - it has no value (i.e.
cannot be passed to any function) and yet won't be evaluated again
> failed<-FALSE
> x
Error: recursive default argument reference
> delayedAssign("x", if (failed) stop("you have to initialize me
first!") else foo)
> x
[1] "I'm foo"
I'd expect something like
> failed<-TRUE
> x
Error: you have to initialize me first!
> x
Error: you have to initialize me first!
> failed<-FALSE
> x
[1] "I'm foo"
Is there a way to achieve that? Intuitively I'd think that this is
the desired behavior, because currently the promise is sort of
'broken' after an error (AFAICT the behavior is not documented
anywhere) - but then, I wasn't messing with promises until now...
Thanks,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error condition in evaluating a promise
> 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!
> failed <- FALSE
> x
[1] "is me"
??
Martin
Simon Urbanek <[EMAIL PROTECTED]> writes:
> 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
> Error: you have to initialize me first!
> > x
> Error: recursive default argument reference
>
> ^^-- from now on x is completely unusable - it has no value (i.e.
> cannot be passed to any function) and yet won't be evaluated again
>
> > failed<-FALSE
> > x
> Error: recursive default argument reference
> > delayedAssign("x", if (failed) stop("you have to initialize me
> first!") else foo)
> > x
> [1] "I'm foo"
>
> I'd expect something like
> > failed<-TRUE
> > x
> Error: you have to initialize me first!
> > x
> Error: you have to initialize me first!
> > failed<-FALSE
> > x
> [1] "I'm foo"
>
> Is there a way to achieve that? Intuitively I'd think that this is
> the desired behavior, because currently the promise is sort of
> 'broken' after an error (AFAICT the behavior is not documented
> anywhere) - but then, I wasn't messing with promises until now...
>
> Thanks,
> Simon
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin T. Morgan
Bioconductor / Computational Biology
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotting text with very small negative rotation hangs (PR#9301)
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",srt=3D-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-15).
>
> plot(0:1,0:1)
> for (i in 1:10) {
> cat(i,"\n")
> text(0.5,0.5,"hello",srt=3D(-10^-i))
> }
>
> I have traced this a fair ways into
> the C code -- I think it happens somewhere
> in clipText -- but I'm not sure. Sorry not
> to be able to provide a fix at the moment.
I can confirm a (ridiculously) long pause on CentOS. Tracing deeper
into C code, it appears to be a loop in XmbRotCreateTextItem() in
rotate.c, which misses an important case when setting up loop
parameters. I have committed a fix to r-devel which solves the problem
for the example above.
Paul
> This is on Ubuntu 6.06, not sure whether
> it affects other platforms or not ...
>
> Ben Bolker
>
>> version
>_
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major 2
> minor 4.0
> year 2006
> month 10
> day03
> svn rev39566
> language R
> version.string R version 2.4.0 (2006-10-03)
>
>
> --enig308510A16A445880F353C5C9
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFNV75c5UpGjwzenMRAhu9AKCVHQ3khVCj1skWyn8wCHl2w0nkbQCfdct5
> zehYhcbw2bazsjuTvX9eAIk=
> =CL1h
> -END PGP SIGNATURE-
>
> --enig308510A16A445880F353C5C9--
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error condition in evaluating a promise
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
> Error in delayMe() : init me!
>> x
> Error in delayMe() : init me!
>> failed <- FALSE
>> x
> [1] "is me"
>
> ??
>
This works only because you assigned both x and the delayMe function
to the global environment. This won't work in any other case (and no,
I didn't want to use this in the global environment - you shouldn't
be trashing it anyway ;)).
Of course you can recursively re-install the promise, but that's
beside the point.
FWIW a general solution re-installing the promise could look like this:
local({ ae<-parent.env(environment()); d<-function() {print
(environment()); if(failed) { delayedAssign("x", d(), assign.env=ae);
stop("init me!") } else foo}; delayedAssign("x", d(),assign.env=ae)})
However in my particular case the whole point of using a promise is
that I'm dealing with a sealed environment (namespace) so you cannot
re-install delayedAssign again (it will fail because the binding is
locked). If the promise worked as I envision, re-installing
delayedAssign would be unnecessary, because the promise is already in
place and will stay there until the evaluation is successful.
Cheers,
Simon
> Simon Urbanek <[EMAIL PROTECTED]> writes:
>
>> 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
>> Error: you have to initialize me first!
>>> x
>> Error: recursive default argument reference
>>
>> ^^-- from now on x is completely unusable - it has no value (i.e.
>> cannot be passed to any function) and yet won't be evaluated again
>>
>>> failed<-FALSE
>>> x
>> Error: recursive default argument reference
>>> delayedAssign("x", if (failed) stop("you have to initialize me
>> first!") else foo)
>>> x
>> [1] "I'm foo"
>>
>> I'd expect something like
>>> failed<-TRUE
>>> x
>> Error: you have to initialize me first!
>>> x
>> Error: you have to initialize me first!
>>> failed<-FALSE
>>> x
>> [1] "I'm foo"
>>
>> Is there a way to achieve that? Intuitively I'd think that this is
>> the desired behavior, because currently the promise is sort of
>> 'broken' after an error (AFAICT the behavior is not documented
>> anywhere) - but then, I wasn't messing with promises until now...
>>
>> Thanks,
>> Simon
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Martin T. Morgan
> Bioconductor / Computational Biology
> http://bioconductor.org
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error condition in evaluating a promise
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)
> environmentIsLocked(getNamespace("sandbox"))
[1] "TRUE"
> getx()
NULL
> setx(2)
> getx()
[1] 2
or otherwise:
> sbox <- sandbox:::sandbox
> sbox$x <- 3
> getx()
[1] 3
> sbox$y <- 4
> sbox$y
[1] 4
I think this works with delayedAssign.
> delayedAssign("z", { cat("hi\n"); 2}, assign.env=sbox)
> sbox$z
hi
[1] 2
> sbox$z
[1] 2
Martin
Martin Morgan <[EMAIL PROTECTED]> writes:
>> 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!
>> failed <- FALSE
>> x
> [1] "is me"
>
> ??
>
> Martin
>
> Simon Urbanek <[EMAIL PROTECTED]> writes:
>
>> 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
>> Error: you have to initialize me first!
>> > x
>> Error: recursive default argument reference
>>
>> ^^-- from now on x is completely unusable - it has no value (i.e.
>> cannot be passed to any function) and yet won't be evaluated again
>>
>> > failed<-FALSE
>> > x
>> Error: recursive default argument reference
>> > delayedAssign("x", if (failed) stop("you have to initialize me
>> first!") else foo)
>> > x
>> [1] "I'm foo"
>>
>> I'd expect something like
>> > failed<-TRUE
>> > x
>> Error: you have to initialize me first!
>> > x
>> Error: you have to initialize me first!
>> > failed<-FALSE
>> > x
>> [1] "I'm foo"
>>
>> Is there a way to achieve that? Intuitively I'd think that this is
>> the desired behavior, because currently the promise is sort of
>> 'broken' after an error (AFAICT the behavior is not documented
>> anywhere) - but then, I wasn't messing with promises until now...
>>
>> Thanks,
>> Simon
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Martin T. Morgan
> Bioconductor / Computational Biology
> http://bioconductor.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin T. Morgan
Bioconductor / Computational Biology
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] crush in edit()
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'; w_p=wcs; - cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(wcs),NULL); + cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(s)-1,NULL); s[cnt]='\0'; if (textwidth(s, strlen(s)) < (bw - text_offset)) break; *(++wcspc) = L'<'; @@ -1056,7 +1056,7 @@ for(j=0;*(wcspc+j)!=L'\0';j++)wcs[j]=*(wcspc+j); wcs[j]=L'\0'; w_p=wcs; - cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(wcs),NULL); + cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(s)-1,NULL); s[cnt]='\0'; if (textwidth(s, strlen(s)) < (bw - text_offset)) break; *(wcspbuf + i - 2) = L'>'; @@ -1066,7 +1066,7 @@ for(j=0;*(wcspc+j)!=L'\0';j++) wcs[j]=*(wcspc+j); wcs[j]=L'\0'; w_p=wcs; -cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(wcs),NULL); +cnt=wcsrtombs(s,(const wchar_t **)&w_p,sizeof(s)-1,NULL); drawtext(x_pos + text_offset, y_pos + box_h - text_offset, s, cnt); @@ -2398,6 +2398,7 @@ int cnt; char last_mbs[8]; char *mbs; +size_t bytes; mbs = (str == NULL) ? buf : str; @@ -2411,8 +2412,8 @@ if(wcs[0] == L'\0') return 0; memset(last_mbs, 0, sizeof(last_mbs)); -wcrtomb(last_mbs, wcs[cnt-1], &mb_st); -return(strlen(last_mbs)); +bytes=wcrtomb(last_mbs, wcs[cnt-1], &mb_st); /* -Wall */ +return(bytes); #else return(1); #endif 2006/10/18, crazybuddy Vincent <[EMAIL PROTECTED]>: > Dear all, > > I am new to R system. When I tried to edit data read from a csv file, R > system crushed, I got an error message as follows: > > > edit(data) > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > === Backtrace: = > /lib/libc.so.6(__chk_fail+0x41)[0x49d020b1] > /lib/libc.so.6[0x49d034a2] > /usr/lib/R/modules//R_X11.so[0x33ed7a] > /usr/lib/R/modules//R_X11.so[0x34050d] > /usr/lib/R/modules//R_X11.so[0x341858] > /usr/lib/R/modules//R_X11.so(RX11_dataentry+0xa25)[0x342f45] > /usr/lib/R/lib/libR.so[0xa34675] > /usr/lib/R/lib/libR.so[0x954ed6] > /usr/lib/R/lib/libR.so(Rf_eval+0x483)[0x925b23] > /usr/lib/R/lib/libR.so[0x929ed8] > /usr/lib/R/lib/libR.so(Rf_eval+0x483)[0x925b23] > /usr/lib/R/lib/libR.so[0x926a37] > /usr/lib/R/lib/libR.so(Rf_eval+0x483)[0x925b23] > /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2a7)[0x928117] > /usr/lib/R/lib/libR.so[0x95661f] > /usr/lib/R/lib/libR.so(Rf_usemethod+0x609)[0x957a89] > /usr/lib/R/lib/libR.so[0x95825e] > /usr/lib/R/lib/libR.so(Rf_eval+0x483)[0x925b23] > /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2a7)[0x928117] > /usr/lib/R/lib/libR.so(Rf_eval+0x2f4)[0x925994] > /usr/lib/R/lib/libR.so(Rf_ReplIteration+0x311)[0x945361] > /usr/lib/R/lib/libR.so[0x945571] > /usr/lib/R/lib/libR.so(run_Rmainloop+0x60)[0x9458c0] > /usr/lib/R/lib/libR.so(Rf_mainloop+0x1c)[0x9458ec] > /usr/lib/R/bin/exec/R(main+0x46)[0x80486f6] > /lib/libc.so.6(__libc_start_main+0xdc)[0x49c3b4e4] > /usr/lib/R/bin/exec/R[0x80485f1] > === Memory map: > 00111000-0012f000 r-xp fd:00 16943095 > /usr/lib/R/library/grDevices/libs/grDevices.so > 0012f000-0013 rwxp 0001d000 fd:00 16943095 > /usr/lib/R/library/grDevices/libs/grDevices.so > 0013-00181000 r-xp fd:00 16976568 > /usr/lib/R/library/stats/libs/stats.so > 00181000-00183000 rwxp 00051000 fd:00 16976568 > /usr/lib/R/library/stats/libs/stats.so > 00339000-00352000 r-xp fd:00 15959326 /usr/lib/R/modules/R_X11.so > 00352000-00353000 rwxp 00018000 fd:00 15959326 /usr/lib/R/modules/R_X11.so > 00353000-0035f000 rwxp 00353000 00:00 0 > 0048-00496000 r-xp fd:00 15303387 /usr/lib/gconv/SJIS.so > 00496000-00498000 rwxp 00015000 fd:00 15303387 /usr/lib/gconv/SJIS.so > 0056e000-00598000 r-xp fd:00 16452204 /usr/lib/R/lib/libRblas.so > 00598000-00599000 rwxp 00029000 fd:00 16452204 /usr/lib/R/lib/libRblas.so > 00848000-00851000 r-xp fd:00 15204401 /lib/libnss_files-2.4.so > 00851000-00852000 r-xp 8000 fd:00 15204401 /lib/libnss_files-2.4.so > 00852000-00853000 rwxp 9000 fd:00 15204401 /lib/libnss_files-2.4.so > 00885000-00abd000 r-xp fd:00 16452203 /usr/lib/R/lib/libR.so > 00abd000-00aca000 rwxp 00238000 fd:00 16452203 /usr/lib/R/lib/libR.so > 00aca000-00b61000 rwxp 00aca000 00:00 0 > 00c47000-00c4d000 r-xp fd:00 16944203 > /usr/lib/R/library/methods/libs/methods.so > 00c4d000-00c4e000 rwxp 5000 fd:00 16944203 > /usr/lib/R/library/methods/libs/methods.so > 00eb6000-00f31000 r-xp fd:00 15242987 > /usr/lib/libgfortran.so.1.0.0 > 00f31000-00f32000 rwxp 0007b000 fd:00 15242987 > /usr/lib/libgfortran.so.1.0.0 > 00f44000-00f45000 r-xp fd:00 15303344 /us
