Full_Name: John Brzustowski
Version: 2.8.1
OS: linux
Submission from: (NULL) (67.71.250.146)
My apologies - there was a bug in the patch I submitted on this topic earlier
today.
diff -cr R-2.8.1/src/library/base/man/options.Rd
R-2.8.1-patched/src/library/base/man/options.Rd
*** R-2.8.1/src/libra
Full_Name: John Brzustowski
Version: 2.8.1
OS: linux
Submission from: (NULL) (67.71.250.146)
When entering a debug()'ed function, the call printout is not limited by
options()$deparse.max.lines as it is when one uses browser() or trace().
Should it be? If so, here's a patch:
diff -cr R-2.8.1/s
Full_Name: John Brzustowski
Version: R-devel trunk and R-2.4.0
OS: linux
Submission from: (NULL) (76.10.152.79)
Here are two minor potential issues in pointer protection stack (PPS) code which
could arise in debugging R with valgrind. Only the second could possibly cause
a problem in normal use
Full_Name: John Brzustowski
Version: R-devel trunk and R 2.4.0
OS: linux
Submission from: (NULL) (76.10.152.79)
# Bug:
> x<-1:3
> attr(x, "names")<-pairlist("a", "b", "c")
> x
a a a
1 2 3
# Note that the simpler alternative does work:
> names(x)<-pairlist("a", "b", "c")
> x
a b c
1 2 3
# Af
Full_Name: John Brzustowski
Version: R-devel-trunk, R-2.4.0
OS: linux, gcc 4.0.3
Submission from: (NULL) (206.248.157.184)
This isn't a bug, but an easily-remedied performance issue.
SYMPTOM
> for (i in 1000 * (1:20)) {
y <- paste(rep("asdf", times=i), collapse=" ")
t <- system.time(strsp
Full_Name: John Brzustowski
Version: R-devel-trunk, R-2.4.0
OS: linux
Submission from: (NULL) (206.248.132.197)
DESCRIPTION
seek() on files larger than 2 gigabytes fails for large values of "where" on
i386 linux 2.6.13 (and presumably other 32-bit unix-like platforms).
e.g.:
> f<-file("3gigaby
Full_Name: John Brzustowski
Version: R-devel-trunk
OS: linux (problem under Windows too)
Submission from: (NULL) (74.101.124.238)
(This bug was discovered by Phil Taylor, Acadia University.)
I'm not sure from reading the documentation whether strptime(x, "%j") is meant
to be supported, but if so,
Hello,
If repeated calls are made to save() using the same pre-opened gzfile
connection to a file, and then the connection is closed, the objects
saved by the second and subsequent calls are not correctly restored by
repeated calls to load() with a new gzfile connection to the same file.
What fo
