Re: [Rd] R_DEFAULT_DEVICE (PR#11294)
[EMAIL PROTECTED] wrote:
> Setting enviroment variable R_DEFAULT_DEVICE causes an error.
> The patch below fixes this.
>
Probably, but it may not be the best fix, so please give your analysis
of the situation. Reproducible example and all that.
To do your homework for you, the issue seems to be this:
viggo:~/>R_INTERACTIVE_DEVICE=pdf ~/misc/r-release-branch/BUILD-dist/bin/R
R version 2.7.0 (2008-04-22)
> plot(0)
Error in plot.new() : no active or default device
> names(options())
[1] "HTTPUserAgent" "OutDec"
[3] "add.smooth" "bitmapType"
[5] "browser" "check.bounds"
[7] "continue""contrasts"
[9] "defaultPackages" "device.R_INTERACTIVE_DEVICE"
OBS!!!
[11] "device.ask.default" "digits"
.
[47] "useFancyQuotes" "verbose"
[49] "warn""warnings.length"
[51] "width"
>
> I guess the same goes for R_INTERACTIVE_DEVICE.
>
>
> --- R-2.7.0/src/library/grDevices/R/zzz.R 2008-04-27 13:49:11.0
> +0200
> +++ R-2.7.0/src/library/grDevices/R/zzz.R.new 2008-04-27 13:59:37.0
> +0200
> @@ -22,7 +22,7 @@
> extras <- if(.Platform$OS.type == "windows")
> list(windowsTimeouts = c(100L,500L)) else
> list(bitmapType = if(capabilities("aqua")) "quartz" else
> if(capabilities("cairo")) "cairo" else "Xlib")
> -defdev <- Sys.getenv("R_DEFAULT_DEVICE")
> +defdev <- as.character(Sys.getenv("R_DEFAULT_DEVICE"))
> if(!nzchar(defdev)) defdev <- "pdf"
> device <- if(interactive()) {
> intdev <- Sys.getenv("R_INTERACTIVE_DEVICE")
>
>
>
>
> --please do not edit the information below--
>
> Version:
> platform = i686-pc-linux-gnu
> arch = i686
> os = linux-gnu
> system = i686, linux-gnu
> status =
> major = 2
> minor = 7.0
> year = 2008
> month = 04
> day = 22
> svn rev = 45424
> language = R
> version.string = R version 2.7.0 (2008-04-22)
>
> Locale:
> [EMAIL PROTECTED];LC_NUMERIC=C;[EMAIL
> PROTECTED];LC_COLLATE=C;LC_MONETARY=C;[EMAIL PROTECTED];[EMAIL
> PROTECTED];LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;[EMAIL
> PROTECTED];LC_IDENTIFICATION=C
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:utils,
> package:datasets, package:grDevices, package:methods, Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_DEFAULT_DEVICE (PR#11294)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-2109857085-1209372640=:16392
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
It has already been changed in R-patched, though
On Mon, 28 Apr 2008, Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
>> Setting enviroment variable R_DEFAULT_DEVICE causes an error.
>> The patch below fixes this.
>>
> Probably, but it may not be the best fix, so please give your analysis
> of the situation. Reproducible example and all that.
>
> To do your homework for you, the issue seems to be this:
>
> viggo:~/>R_INTERACTIVE_DEVICE=pdf ~/misc/r-release-branch/BUILD-dist/bin/R
>
> R version 2.7.0 (2008-04-22)
>
>> plot(0)
> Error in plot.new() : no active or default device
>> names(options())
> [1] "HTTPUserAgent" "OutDec"
> [3] "add.smooth" "bitmapType"
> [5] "browser" "check.bounds"
> [7] "continue""contrasts"
> [9] "defaultPackages" "device.R_INTERACTIVE_DEVICE"
>
> OBS!!!
>
> [11] "device.ask.default" "digits"
> .
> [47] "useFancyQuotes" "verbose"
> [49] "warn""warnings.length"
> [51] "width"
>>
>
>> I guess the same goes for R_INTERACTIVE_DEVICE.
>>
>>
>> --- R-2.7.0/src/library/grDevices/R/zzz.R 2008-04-27
>> 13:49:11.0 +0200
>> +++ R-2.7.0/src/library/grDevices/R/zzz.R.new 2008-04-27
>> 13:59:37.0 +0200
>> @@ -22,7 +22,7 @@
>> extras <- if(.Platform$OS.type == "windows")
>> list(windowsTimeouts = c(100L,500L)) else
>> list(bitmapType = if(capabilities("aqua")) "quartz" else
>> if(capabilities("cairo")) "cairo" else "Xlib")
>> -defdev <- Sys.getenv("R_DEFAULT_DEVICE")
>> +defdev <- as.character(Sys.getenv("R_DEFAULT_DEVICE"))
>> if(!nzchar(defdev)) defdev <- "pdf"
>> device <- if(interactive()) {
>> intdev <- Sys.getenv("R_INTERACTIVE_DEVICE")
>>
>>
>>
>>
>> --please do not edit the information below--
>>
>> Version:
>> platform = i686-pc-linux-gnu
>> arch = i686
>> os = linux-gnu
>> system = i686, linux-gnu
>> status =
>> major = 2
>> minor = 7.0
>> year = 2008
>> month = 04
>> day = 22
>> svn rev = 45424
>> language = R
>> version.string = R version 2.7.0 (2008-04-22)
>>
>> Locale:
>> [EMAIL PROTECTED];LC_NUMERIC=C;[EMAIL
>> PROTECTED];LC_COLLATE=C;LC_MONETARY=C;[EMAIL PROTECTED];[EMAIL
>> PROTECTED];LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;[EMAIL
>> PROTECTED];LC_IDENTIFICATION=C
>>
>> Search Path:
>> .GlobalEnv, package:stats, package:graphics, package:utils,
>> package:datasets, package:grDevices, package:methods, Autoloads, package:base
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> --
> O__ Peter Dalgaard Ãster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
--27464147-2109857085-1209372640=:16392--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#11291) View functionhas problems going beyond 65536
This is specific to the scrollbar: paging/End work fine -- so the original subject list was seriously misleading. It is a Windows limitation on scrollbars -- there was code to work around it, but it was not switched on - will be in R-devel and R-patched shortly. On Sun, 27 Apr 2008, [EMAIL PROTECTED] wrote: > Full_Name: jim holtman > Version: 2.7.0 > OS: Winfows XP > Submission from: (NULL) (75.186.87.163) > > > I am using the "View" function to look at a data frame. If the data has more > than 65535 rows in it, strange things happen. You can reproduce the problem > with the following: > > x <- 1:66000 > View(x) > > If you now take the scroll bar and move it to the end, you will see that the > row > number is now 464 and the bar has jumped back to that location. > > Now press the "End" and you will get to the end of the vector and the row > number > does show up as 66000. It appears there is some trucation happen when the > value > gets to be more than 65535 rows when using the scroll bar. You can move the > scroll bar to about 65000 and the "Page Down" will move the data to the last > row > (66000). > > This problem only seems to happen when using the scroll bar to move within the > data. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- 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
[Rd] R 2.7.0, match() and strings containing \0 - bug?
Hi,
A piece of my code that uses readBin() to read a certain file type is
behaving strangely with R 2.7.0. This seems to be because of a failure
to match() strings after using rawToChar() when the original was
terminated with a "\0" character. Direct equality testing with ==
still works as expected. I can reproduce this as follows:
> x <- "foo"
> y <- c(charToRaw("foo"),as.raw(0))
> z <- rawToChar(y)
> z==x
[1] TRUE
> z=="foo"
[1] TRUE
> z %in% c("foo","bar")
[1] FALSE
> z %in% c("foo","bar","foo\0")
[1] FALSE
But without the nul character it works fine:
> zz <- rawToChar(charToRaw("foo"))
> zz %in% c("foo","bar")
[1] TRUE
I don't see anything about this in the latest NEWS, but is this
expected behaviour? Or is it, as I suspect, a bug? This seems to be
new to R 2.7.0, as I said.
Regards,
Jon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.7.0, match() and strings containing \0 - bug?
Apologies for missing out the sessionInfo():
R version 2.7.0 (2008-04-22)
i386-apple-darwin8.10.1
locale:
en_GB.UTF-8/en_US.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
2008/4/28 Jon Clayden <[EMAIL PROTECTED]>:
> Hi,
>
> A piece of my code that uses readBin() to read a certain file type is
> behaving strangely with R 2.7.0. This seems to be because of a failure
> to match() strings after using rawToChar() when the original was
> terminated with a "\0" character. Direct equality testing with ==
> still works as expected. I can reproduce this as follows:
>
> > x <- "foo"
> > y <- c(charToRaw("foo"),as.raw(0))
> > z <- rawToChar(y)
> > z==x
> [1] TRUE
> > z=="foo"
> [1] TRUE
> > z %in% c("foo","bar")
> [1] FALSE
> > z %in% c("foo","bar","foo\0")
> [1] FALSE
>
> But without the nul character it works fine:
>
> > zz <- rawToChar(charToRaw("foo"))
> > zz %in% c("foo","bar")
> [1] TRUE
>
> I don't see anything about this in the latest NEWS, but is this
> expected behaviour? Or is it, as I suspect, a bug? This seems to be
> new to R 2.7.0, as I said.
>
> Regards,
> Jon
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.7.0, match() and strings containing \0 - bug?
On Mon, 28 Apr 2008, Jon Clayden wrote:
Hi,
A piece of my code that uses readBin() to read a certain file type is
behaving strangely with R 2.7.0. This seems to be because of a failure
to match() strings after using rawToChar() when the original was
terminated with a "\0" character. Direct equality testing with ==
still works as expected. I can reproduce this as follows:
x <- "foo"
y <- c(charToRaw("foo"),as.raw(0))
z <- rawToChar(y)
z==x
[1] TRUE
z=="foo"
[1] TRUE
z %in% c("foo","bar")
[1] FALSE
z %in% c("foo","bar","foo\0")
[1] FALSE
But without the nul character it works fine:
zz <- rawToChar(charToRaw("foo"))
zz %in% c("foo","bar")
[1] TRUE
I don't see anything about this in the latest NEWS, but is this
expected behaviour? Or is it, as I suspect, a bug? This seems to be
new to R 2.7.0, as I said.
And so is the comment in ?match:
Character inputs with embedded nul bytes will be truncated at the
first nul.
The bug is in the documentation here -- this was intentional.
As support for embedded nuls in character strings is being removed in R
2.8.0, you should not rely on this.
--
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] R 2.7.0, match() and strings containing \0 - bug?
2008/4/28 Prof Brian Ripley <[EMAIL PROTECTED]>:
>
> On Mon, 28 Apr 2008, Jon Clayden wrote:
>
>
> > Hi,
> >
> > A piece of my code that uses readBin() to read a certain file type is
> > behaving strangely with R 2.7.0. This seems to be because of a failure
> > to match() strings after using rawToChar() when the original was
> > terminated with a "\0" character. Direct equality testing with ==
> > still works as expected. I can reproduce this as follows:
> >
> >
> > > x <- "foo"
> > > y <- c(charToRaw("foo"),as.raw(0))
> > > z <- rawToChar(y)
> > > z==x
> > >
> > [1] TRUE
> >
> > > z=="foo"
> > >
> > [1] TRUE
> >
> > > z %in% c("foo","bar")
> > >
> > [1] FALSE
> >
> > > z %in% c("foo","bar","foo\0")
> > >
> > [1] FALSE
> >
> > But without the nul character it works fine:
> >
> >
> > > zz <- rawToChar(charToRaw("foo"))
> > > zz %in% c("foo","bar")
> > >
> > [1] TRUE
> >
> > I don't see anything about this in the latest NEWS, but is this
> > expected behaviour? Or is it, as I suspect, a bug? This seems to be
> > new to R 2.7.0, as I said.
> >
>
> And so is the comment in ?match:
>
> Character inputs with embedded nul bytes will be truncated at the
> first nul.
>
> The bug is in the documentation here -- this was intentional.
>
> As support for embedded nuls in character strings is being removed in R
> 2.8.0, you should not rely on this.
>
Thanks for the reply, but I don't see why this should make the match
fail. If "foo\0" gets truncated to "foo", then surely there's no
question that match("foo\0","foo") should produce "1" (which it does
if you use the literals, but not if it came out of rawToChar)?
Also, ?'==' seems to contain a similar comment:
When comparisons are made between character strings, parts of the
strings after embedded 'nul' characters are ignored.
So why are the results different? I would expect 'z=="foo"' and 'z
%in% "foo"' to both return TRUE, but the second returns FALSE.
Jon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#11291) View functionhas problems going beyond 65536 rows *using the scrollbar*
THanks for the response. Sorry about the misleading subject line, but I did say in the description that it only appears to happen with the scroll bar and can understand if it is a limitation of Windows. Probably left over from the days when Excel could only go to 65536 rows. On Mon, Apr 28, 2008 at 4:53 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > This is specific to the scrollbar: paging/End work fine -- so the original > subject list was seriously misleading. > > It is a Windows limitation on scrollbars -- there was code to work around > it, but it was not switched on - will be in R-devel and R-patched shortly. > > On Sun, 27 Apr 2008, [EMAIL PROTECTED] wrote: > > > Full_Name: jim holtman > > Version: 2.7.0 > > OS: Winfows XP > > Submission from: (NULL) (75.186.87.163) > > > > > > I am using the "View" function to look at a data frame. If the data has > more > > than 65535 rows in it, strange things happen. You can reproduce the > problem > > with the following: > > > > x <- 1:66000 > > View(x) > > > > If you now take the scroll bar and move it to the end, you will see that > the row > > number is now 464 and the bar has jumped back to that location. > > > > Now press the "End" and you will get to the end of the vector and the row > number > > does show up as 66000. It appears there is some trucation happen when the > value > > gets to be more than 65535 rows when using the scroll bar. You can move > the > > scroll bar to about 65000 and the "Page Down" will move the data to the > last row > > (66000). > > > > This problem only seems to happen when using the scroll bar to move within > the > > data. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > 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 > -- Jim Holtman Cincinnati, OH +1 513 646 9390 What is the problem you are trying to solve? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small Visual Bug in R GUI Package Installer (PR#11317)
Full_Name: Ana Nelson Version: R 2.7.0 GUI 1.24 (5102) OS: OSX 10.5.2 Submission from: (NULL) (87.198.253.138) When you switch the Package Installer repository selection box to any of the 3 "local" options, i.e. install from "Local Package Directory", the "Install All" button text becomes corrupted. Screenshot is here: http://skitch.com/ananelson/kmp6/r-package-installer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] OSX R GUI visual interface tweak (PR#11318)
Full_Name: Ana Nelson Version: R 2.7.0 GUI 1.24 (5102) OS: OSX 10.5.2 Submission from: (NULL) (213.94.201.89) The R GUI close button has a solid circle. Screenshot is here: http://skitch.com/ananelson/kmxj/r-console On OSX this indicates that there are unsaved changes pending. Please see page 201 of the Apple Human Interface Guidelines (version 2008-03-11): http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf However, I never save my workspace on exiting R, therefore I don't really have unsaved changes, so the "X" close button would be more appropriate. I know this might seem like a very fussy request, but I actually find it very distracting to think I have unsaved changes in a document, and every time I glance and see the solid circle I have to stop and think and remind myself that I don't. Apple has me so well trained! (sigh) I think it's because when I see a dot instead of an X, I anticipate that I will be faced with a "save as" dialog box, which will interrupt my workflow and I will have to think about where to save the file, what to call it etc. Anyway, I would vote to get rid of the dot, perhaps just for those users who have the "No" option selected for "save workspace on exit from R". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Take marginality into account in factor.scope
Dear devellopeRs,
I've altered factor.scope() from the stats package so it can take
marginality into account. Therefore I've added the argument marginal.
When marginal is NULL, factor.scope() works like the original version.
The marginality is to be specified as a named list. The name of the
elements is the name of a variable. The content of the element is a
character vector with the variable(s) that must be in the model.
E.g. marginal = list(D = c("B", "C"), A3 = "A2", A2 = "A1")
Means that
- D can only enter the model if B and C are present.
- A2 can only enter the model if A1 is present.
- A3 can only enter the model if A2 is present. Since the list contains
A2 = "A1", this implies that A1 needs to be present too.
- B can only leave the model if D is not present.
- C can only leave the model if D is not present.
- A2 can only leave the model if A3 is not present.
- A1 can only leave the model if A2 and A3 are not present.
It copes with interactions too.
A1:B needs
by default
A1 and B
due to marginality
none
A2:B needs
by default
A2 and B
due marginality
A1 and A1:B
Comments are welcome,
Cheers,
Thierry
factor.scope <- function (factor, scope, marginal = NULL) {
drop <- scope$drop
add <- scope$add
if (length(factor) && !is.null(drop)) {
nmdrop <- colnames(drop)
facs <- factor
if (length(drop)) {
nmfac <- colnames(factor)
nmfac0 <- sapply(strsplit(nmfac, ":", fixed = TRUE),
function(x) paste(sort(x), collapse = ":"))
nmdrop0 <- sapply(strsplit(nmdrop, ":", fixed = TRUE),
function(x) paste(sort(x), collapse = ":"))
where <- match(nmdrop0, nmfac0, 0)
if (any(!where)){
stop(gettextf("lower scope has term(s) %s not included
in model", paste(sQuote(nmdrop[where == 0]), collapse = ", ")), domain
= NA)
}
facs <- factor[, -where, drop = FALSE]
nmdrop <- nmfac[-where]
} else {
nmdrop <- colnames(factor)
}
if (ncol(facs) > 1) {
keep <- rep.int(TRUE, ncol(facs))
f <- crossprod(facs > 0)
for (i in seq(keep)){
keep[i] <- max(f[i, -i]) != f[i, i]
}
nmdrop <- nmdrop[keep]
}
keep <- unlist(lapply(strsplit(nmdrop, ":", fixed = TRUE),
function(x){
whereMarginal <- match(x, names(marginal))
if(!all(is.na(whereMarginal))){
if(length(x) == 1){
marginal[[whereMarginal]]
} else {
lowerOrderTerms <- lapply(seq_along(whereMarginal),
function(z){
if(is.na(whereMarginal[z])){
x[z]
} else {
c(x[z], marginal[[whereMarginal[z]]])
}
})
lowerOrder <- apply(expand.grid(lowerOrderTerms), 1,
function(z){
paste(sort(z), collapse = ":")
})
lowerOrder[!lowerOrder %in% paste(sort(x), collapse
= ":")]
}
}
}))
nmdrop <- nmdrop[!nmdrop %in% keep]
} else {
nmdrop <- character(0)
}
if (!length(add)){
nmadd <- character(0)
} else {
nmfac <- colnames(factor)
nmadd <- colnames(add)
if (!is.null(nmfac)) {
nmfac0 <- sapply(strsplit(nmfac, ":", fixed = TRUE),
function(x) paste(sort(x), collapse = ":"))
nmadd0 <- sapply(strsplit(nmadd, ":", fixed = TRUE),
function(x) paste(sort(x), collapse = ":"))
where <- match(nmfac0, nmadd0, 0)
if (any(!where)){
stop(gettextf("upper scope does not include model
term(s) %s", paste(sQuote(nmfac[where == 0]), collapse = ", ")), domain
= NA)
}
nmadd <- nmadd[-where]
add <- add[, -where, drop = FALSE]
}
if (ncol(add) > 1) {
keep <- rep.int(TRUE, ncol(add))
f <- crossprod(add > 0)
for (i in seq(keep)){
keep[-i] <- keep[-i] & (f[i, -i] < f[i, i])
}
nmadd <- nmadd[keep]
}
if(length(nmadd)){
keep <- sapply(strsplit(nmadd, ":", fixed = TRUE),
function(x){
whereMarginal <- match(x, names(marginal))
if(!all(is.na(whereMarginal))){
if(length(x) == 1){
all(!marginal[[whereMarginal]] %in% nmadd)
} else {
lowerOrderTerms <-
lapply(seq_along(whereMarginal), function(z){
if(is.na(whereMarginal[z])){
x[z]
} else {
c(x[z], marginal[[whereMarginal[z]]])
}
Re: [Rd] R 2.7.0, match() and strings containing \0 - bug?
Hi Jon,
* On 2008-04-28 at 11:00 +0100 Jon Clayden wrote:
> A piece of my code that uses readBin() to read a certain file type is
> behaving strangely with R 2.7.0. This seems to be because of a failure
> to match() strings after using rawToChar() when the original was
> terminated with a "\0" character. Direct equality testing with ==
> still works as expected. I can reproduce this as follows:
>
> > x <- "foo"
> > y <- c(charToRaw("foo"),as.raw(0))
> > z <- rawToChar(y)
> > z==x
> [1] TRUE
> > z=="foo"
> [1] TRUE
> > z %in% c("foo","bar")
> [1] FALSE
> > z %in% c("foo","bar","foo\0")
> [1] FALSE
>
> But without the nul character it works fine:
>
> > zz <- rawToChar(charToRaw("foo"))
> > zz %in% c("foo","bar")
> [1] TRUE
>
> I don't see anything about this in the latest NEWS, but is this
> expected behaviour? Or is it, as I suspect, a bug? This seems to be
> new to R 2.7.0, as I said.
The short answer is that your example works in R-2.6 and in the
current R-devel. Whether the behavior in R-2.7 is a bug is perhaps in
the eye of the beholder.
Historically, R's internal string representation allowed for embedded
nul characters. This was particularly useful before the raw vector
type, RAWSXP, was introduced. Since the vast majority of
R's internal string processing functions use standard C semantics
and truncated at first nul there has always been some room for
"interesting" behavior. The change in R-2.7 was an attempt to start
resolving these inconsistencies. Since then the core team has agreed
to remove the partial support for embedded nul in character strings --
raw can be used when this is desired, and having nul terminated
strings will make the code more consistent and easier to maintain
going forward.
Best Wishes,
+ seth
--
Seth Falcon | http://userprimary.net/user/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines
Dear R-devel, One of our R-Forge developers pointed out that it is not possible to build packages under Windows using the R-Forge repository structure: a package resides in ./pkg - not in a directory with the same name as the package name. Under Linux 'R CMD build pkg' or 'R CMD check pkg' work pretty well (I think Kurt Hornik fixed that in R 2.5.1 or so) whereas under Windows one gets the following error (this is the example sent by the user): c:\work\packages\spdep>R CMD check pkg * checking for working pdflatex ... OK * using log directory 'C:/work/packages/spdep/pkg.Rcheck' * using R version 2.7.0 (2008-04-22) * using session charset: ISO8859-1 * checking for file 'pkg/DESCRIPTION' ... OK * this is package 'spdep' version '0.4-21' * package encoding: latin1 * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'pkg/src' contains object files. * checking whether package 'spdep' can be installed ... ERROR Installation failed. See 'C:/work/packages/spdep/pkg.Rcheck/00install.out' for details. which is: installing R.css in C:/work/packages/spdep/pkg.Rcheck -- Making package pkg adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... ... DLL made installing DLL installing R files installing inst files installing data files preparing package pkg for lazy loading Loading required package: tripack Loading required package: sp ... Error in findpack(package, lib.loc) : *there is no package called 'pkg'* Calls: -> findpack Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-pkg] Error 2 *** Installation of pkg failed *** I could verify this on our 'Windows package building machine' not only for this package but also for others. Therefore, it seems to me that the (Windows) R CMD build/check scripts are not considering the package name in the DESCRIPTION file but rather take the directory name as package name. Or are we just doing something completely wrong? I used R-patched 2.7.0 on R-Forge to reproduce this error. Best regards, Stefan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] method dispatch conflict?
Hi, I vaguely recall this was discussed in the past, but I cannot remember the context. The code below shows the problem: ---<---cut here---start-->--- R> library(stats4) R> library(lme4) Loading required package: Matrix Attaching package: 'Matrix' The following object(s) are masked from package:stats : xtabs Attaching package: 'lme4' The following object(s) are masked from package:stats4 : BIC Warning messages: 1: In namespaceImportFrom(self, asNamespace(ns)) : replacing previous import: cov2cor 2: In namespaceImportFrom(self, asNamespace(ns)) : replacing previous import: update 3: In namespaceImportFrom(self, asNamespace(ns)) : replacing previous import: xtabs R> example example R> example(lmer) lmerR> (fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy)) Error in printMer(object) : no slot of name "status" for this object of class "table" In addition: Warning message: In printMer(object) : trying to get slot "status" from an object (class "table") that is not an S4 object ---<---cut here---end>--- IIUC, the problem lies in choosing the correct print method for the lmer object. If lme4 is loaded *before* stats4, then the object is printed without errors. This is with: ---<---cut here---start-->--- R> sessionInfo() R version 2.7.0 (2008-04-22) x86_64-pc-linux-gnu locale: LC_CTYPE=en_CA.UTF-8;LC_NUMERIC=C;LC_TIME=en_CA.UTF-8;LC_COLLATE=en_CA.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_CA.UTF-8;LC_PAPER=en_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_CA.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats4stats graphics grDevices utils datasets methods [8] base other attached packages: [1] lme4_0.99875-9Matrix_0.999375-9 lattice_0.17-6 loaded via a namespace (and not attached): [1] grid_2.7.0 ---<---cut here---end>--- Cheers, -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines
On 28/04/2008 12:22 PM, Stefan Theussl wrote: Dear R-devel, One of our R-Forge developers pointed out that it is not possible to build packages under Windows using the R-Forge repository structure: a package resides in ./pkg - not in a directory with the same name as the package name. Under Linux 'R CMD build pkg' or 'R CMD check pkg' work pretty well (I think Kurt Hornik fixed that in R 2.5.1 or so) whereas under Windows one gets the following error (this is the example sent by the user): c:\work\packages\spdep>R CMD check pkg * checking for working pdflatex ... OK * using log directory 'C:/work/packages/spdep/pkg.Rcheck' * using R version 2.7.0 (2008-04-22) * using session charset: ISO8859-1 * checking for file 'pkg/DESCRIPTION' ... OK * this is package 'spdep' version '0.4-21' * package encoding: latin1 * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'pkg/src' contains object files. * checking whether package 'spdep' can be installed ... ERROR Installation failed. See 'C:/work/packages/spdep/pkg.Rcheck/00install.out' for details. which is: installing R.css in C:/work/packages/spdep/pkg.Rcheck -- Making package pkg adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... ... DLL made installing DLL installing R files installing inst files installing data files preparing package pkg for lazy loading Loading required package: tripack Loading required package: sp ... Error in findpack(package, lib.loc) : *there is no package called 'pkg'* Calls: -> findpack Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-pkg] Error 2 *** Installation of pkg failed *** I could verify this on our 'Windows package building machine' not only for this package but also for others. Therefore, it seems to me that the (Windows) R CMD build/check scripts are not considering the package name in the DESCRIPTION file but rather take the directory name as package name. Or are we just doing something completely wrong? You're right, on Windows there's an assumption that package foo is in directory foo. But I don't see why this is a big problem. Can't you just check out pkg into foo, e.g. svn co svn://svn.r-forge.r-project.org/svnroot/foo/pkg foo (Not that I'd be against accepting a patch to remove this restriction; occasionally it might be nice to have two versions of the same package side-by-side.) Duncan Murdoch I used R-patched 2.7.0 on R-Forge to reproduce this error. Best regards, Stefan __ 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] OSX R GUI visual interface tweak (PR#11318)
On Apr 28, 2008, at 5:10 AM, [EMAIL PROTECTED] wrote: Full_Name: Ana Nelson Version: R 2.7.0 GUI 1.24 (5102) OS: OSX 10.5.2 Submission from: (NULL) (213.94.201.89) The R GUI close button has a solid circle. Screenshot is here: http://skitch.com/ananelson/kmxj/r-console On OSX this indicates that there are unsaved changes pending. Please see page 201 of the Apple Human Interface Guidelines (version 2008-03-11): http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf However, I never save my workspace on exiting R, therefore I don't really have unsaved changes, so the "X" close button would be more appropriate. The workspace has nothing to do with it. The window you are referring to is the console window and its contents (text) has changed (namely R output was added), hence the unsaved status. However, to avoid (unexpected) loss of data, we don't reset the status on console text save, either. The R console semantics doesn't readily correspond to Apple's document model. There are in fact at least two documents here - the console and the workspace. There's isn't much we can do about that. BTW: We are not creating those buttons, Apple's frameworks are, so we have no control over their appearance. I know this might seem like a very fussy request, but I actually find it very distracting to think I have unsaved changes in a document, and every time I glance and see the solid circle I have to stop and think and remind myself that I don't. Apple has me so well trained! (sigh) I think it's because when I see a dot instead of an X, I anticipate that I will be faced with a "save as" dialog box, which will interrupt my workflow and I will have to think about where to save the file, what to call it etc. Anyway, I would vote to get rid of the dot, perhaps just for those users who have the "No" option selected for "save workspace on exit from R". See above, that's not our call. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines
The difference is in INSTALL, not build/check. You are right that the Unix INSTALL was changed in r25808 (Aug 2003), but AFAICS this was not documented at the time in [O]NEWS, nor anywhere else. Can you point me to the documentation you used to implement this? On Mon, 28 Apr 2008, Duncan Murdoch wrote: On 28/04/2008 12:22 PM, Stefan Theussl wrote: Dear R-devel, One of our R-Forge developers pointed out that it is not possible to build packages under Windows using the R-Forge repository structure: a package resides in ./pkg - not in a directory with the same name as the package name. Under Linux 'R CMD build pkg' or 'R CMD check pkg' work pretty well (I think Kurt Hornik fixed that in R 2.5.1 or so) whereas under Windows one gets the following error (this is the example sent by the user): c:\work\packages\spdep>R CMD check pkg * checking for working pdflatex ... OK * using log directory 'C:/work/packages/spdep/pkg.Rcheck' * using R version 2.7.0 (2008-04-22) * using session charset: ISO8859-1 * checking for file 'pkg/DESCRIPTION' ... OK * this is package 'spdep' version '0.4-21' * package encoding: latin1 * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'pkg/src' contains object files. * checking whether package 'spdep' can be installed ... ERROR Installation failed. See 'C:/work/packages/spdep/pkg.Rcheck/00install.out' for details. which is: installing R.css in C:/work/packages/spdep/pkg.Rcheck -- Making package pkg adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... ... DLL made installing DLL installing R files installing inst files installing data files preparing package pkg for lazy loading Loading required package: tripack Loading required package: sp ... Error in findpack(package, lib.loc) : *there is no package called 'pkg'* Calls: -> findpack Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-pkg] Error 2 *** Installation of pkg failed *** I could verify this on our 'Windows package building machine' not only for this package but also for others. Therefore, it seems to me that the (Windows) R CMD build/check scripts are not considering the package name in the DESCRIPTION file but rather take the directory name as package name. Or are we just doing something completely wrong? You're right, on Windows there's an assumption that package foo is in directory foo. But I don't see why this is a big problem. Can't you just check out pkg into foo, e.g. svn co svn://svn.r-forge.r-project.org/svnroot/foo/pkg foo (Not that I'd be against accepting a patch to remove this restriction; occasionally it might be nice to have two versions of the same package side-by-side.) Duncan Murdoch I used R-patched 2.7.0 on R-Forge to reproduce this error. Best regards, Stefan __ 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 -- 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] R-Forge SVN repositories: R CMD build/check error on Windows machines
On 4/28/08, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > The difference is in INSTALL, not build/check. > > You are right that the Unix INSTALL was changed in r25808 (Aug 2003), but > AFAICS this was not documented at the time in [O]NEWS, nor anywhere else. > > Can you point me to the documentation you used to implement this? FWIW, the NEWS for 2.5.0 [1] has o R CMD build now takes the package name from the DESCRIPTION file and not from the directory. (PR#9266) and that does seem to work on Windows. [1] https://stat.ethz.ch/pipermail/r-announce/2007/000828.html -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.7.0, match() and strings containing \0 - bug?
Hi Jon,
Jon Clayden wrote:
Hi,
A piece of my code that uses readBin() to read a certain file type is
behaving strangely with R 2.7.0. This seems to be because of a failure
to match() strings after using rawToChar() when the original was
terminated with a "\0" character. Direct equality testing with ==
still works as expected. I can reproduce this as follows:
x <- "foo"
y <- c(charToRaw("foo"),as.raw(0))
z <- rawToChar(y)
z==x
[1] TRUE
z=="foo"
[1] TRUE
z %in% c("foo","bar")
[1] FALSE
z %in% c("foo","bar","foo\0")
[1] FALSE
But this gives TRUE:
> z %in% c("foo","bar", z)
[1] TRUE
An additional problem you have here is that when the "foo\0" string literal
is converted into a character string, then the string data that are after the
first embedded nul are dropped:
> identical("foo\0a\0b", "foo")
[1] TRUE
And to add to the endless source of surprises that come with embedded nuls:
> dump("z", file="")
z <-
"foo\0"
but of course sourcing the above dump into an R session will not restore 'z'.
Dropping support for embedded nuls in R 2.8.0 sounds like good news to me.
Cheers,
H.
But without the nul character it works fine:
zz <- rawToChar(charToRaw("foo"))
zz %in% c("foo","bar")
[1] TRUE
I don't see anything about this in the latest NEWS, but is this
expected behaviour? Or is it, as I suspect, a bug? This seems to be
new to R 2.7.0, as I said.
Regards,
Jon
__
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
[Rd] X11 window title setting in X11() Device (PR#11325)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
I think I have found a very little bug in the new version of the X11()
device in R 2.7.0, more precisely in the devX11.c file.
The problem is that when you open a new window with X11(), the title
of the window (the WM_NAME property) is not immediately set. It seems
that the window is created, then it is displayed (mapped) with no
title, and then the title is set.
It is something absolutely invisible for the user, but it leads to
problem for me because I use a window manager that relies on window
titles to give them different attributes (I use it to make all my R
Graphics windows floating). And due to the fact that the title is set
after opening, my window manager rules don't apply anymore.
I found a quick and dirty workaround which set the title immediately
after the window opening if the =C2=ABtitle=C2=BB option in X11.options() is
set. You will find the patch for devX11.c attached to this mail, it is
just two lines moved before the call to X11_Open.
Surely there could be something much better, but I am quite new to C
and X11 programming...
Here is my sessionInfo() :
,
| R version 2.7.0 (2008-04-22)=20
| i486-pc-linux-gnu=20
|=20
| locale:
| LC_CTYPE=3Dfr_FR.UTF-8;LC_NUMERIC=3DC;LC_TIME=3Dfr_FR.UTF-8;LC_COLLATE=3D=
fr_FR.UTF-8;LC_MONETARY=3DC;LC_MESSAGES=3Dfr_FR.UTF-8;LC_PAPER=3Dfr_FR.UTF-=
8;LC_NAME=3DC;LC_ADDRESS=3DC;LC_TELEPHONE=3DC;LC_MEASUREMENT=3Dfr_FR.UTF-8;=
LC_IDENTIFICATION=3DC
|=20
| attached base packages:
| [1] grDevices utils datasets graphics stats methods base=20=
=20=20=20=20
|=20
| other attached packages:
| [1] car_1.2-7
`
Thanks for all your work !
Regards,
Julien=20
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment; filename=devX11_patch.diff
--- devX11.c.orig 2008-04-28 16:22:46.0 +0200
+++ devX11.c2008-04-28 16:22:57.0 +0200
@@ -2225,6 +2225,9 @@
else strcpy(xd->symbolfamily,fn);
}
+strncpy(xd->title, title, 100);
+xd->title[100] = '\0';
+
/* Start the Device Driver and Hardcopy. */
if (!X11_Open(dd, xd, disp_name, width, height,
@@ -2238,8 +2241,6 @@
xd->fill = 0x; /* this is needed to ensure that the
first newpage does set whitecolor
if par("bg") is not transparent */
-strncpy(xd->title, title, 100);
-xd->title[100] = '\0';
#if BUG
R_ProcessX11Events((void*) NULL);
--=-=-=--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
