[Rd] Mistake in CP1257.enc file of grDevices package (PR#13736)
Full_Name: Vaidotas Zemlys Version: 2.9.0 OS: Ubuntu 8.10 Submission from: (NULL) (213.197.173.50) Hi, This is the same bug as bug #9845. Encodings CP1257 and ISOLatin7 are used for Lithuanian and Latvian languages. They differ only by certain symbols such as quotation marks. Instead of umacron and Umacron there are symbols ucircmuflex and Ucircumflex in file CP1257.enc, which belongs to package grDevices. To see the problem compare the outputs > postscript(encoding="CP1257.enc") > plot(rnorm(100),main="\u016B\u016A") > dev.off() and plot(rnorm(100),main="\u016B\u016A"). This bug appears only in Windows environment with Lithuanian locale, since only then CP1257 is used as default encoding. Changing [uU]circumflex to [uU]macron in file CP1257.enc fixes the problem. Vaidotas Zemlys __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in nlme package function predict.lmList (PR#13788)
Full_Name: Vaidotas Zemlys
Version: 2.9.0
OS: Ubuntu 8.10
Submission from: (NULL) (213.197.173.50)
Steps to reproduce the bug:
library(nlme)
data(Oxboys)
qm=lmList(height~age|Subject,data=Oxboys)
grid=with(Oxboys,expand.grid(age=seq(min(age),max(age),length=50),Subject=levels(Subject)))
res <- predict(qm,grid,se=TRUE)
Erreur dans if (pool) { : l'argument est de longueur nulle
res <- predict(qm,grid,se=TRUE,pool=TRUE)
Erreur dans sprintf(gettext(fmt, domain = domain), ...) :
objet 'form' introuvable
The result: predicting does not work, when new data is supplied.
The problem is in the function predict.lmList. When argument newdata is not
NULL, argument subset is set to TRUE, and following code gets executed:
Start of the relevant code snippet
if (!is.null(subset)) {
if (any(is.na(match(subset, names(object) {
stop("Non-existent group requested in \"subset\".")
}
oclass <- class(object)
oatt <- attr(object, "call")
object <- object[subset]
attr(object, "call") <- oatt
class(object) <- oclass
if (is.null(newdata)) {
myData <- myData[subset]
}
}
#End of relevant code snippet
Only attribute call is saved from original object, but the following code
assumes that attributes groupsForm and pool are present, and when they are not
found, error is produced. The problem with missing pool attribute can be worked
arround by supplying it directly. But it is not possible to do that with
attribute groupsForm.
The patch which fixes this problem :
--- lmList.R2008-02-11 16:05:14.0 +0200
+++ lmListnew.R 2009-06-30 09:49:21.0 +0300
@@ -853,9 +853,10 @@ predict.lmList <-
stop("Non-existent group requested in \"subset\".")
}
oclass <- class(object)
-oatt <- attr(object, "call")
+oatt <- attributes(object)[c("call","groupsForm","pool")]
object <- object[subset]
-attr(object, "call") <- oatt
+oatt <- c(attributes(object),oatt)
+attributes(object) <- oatt
class(object) <- oclass
if(is.null(newdata)) {
myData <- myData[subset]
I did not do extensive tests, but it works with previous example and my own
datasets.
Here is the relevant information about R and nlme on my system:
> R.version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major 2
minor 9.0
year 2009
month 04
day17
svn rev48333
language R
version.string R version 2.9.0 (2009-04-17)
> packageDescription("nlme")
Package: nlme
Version: 3.1-92
Date: 2009-05-22
Priority: recommended
Title: Linear and Nonlinear Mixed Effects Models
Author: Jose Pinheiro , Douglas
Bates , Saikat DebRoy
, Deepayan Sarkar
, the R Core team.
Maintainer: R-core
Description: Fit and compare Gaussian linear and nonlinear
mixed-effects models.
Depends: graphics, stats, R (>= 2.4.0)
Imports: lattice
LazyLoad: yes
LazyData: yes
License: GPL (>= 2)
Packaged: 2009-05-23 16:39:47 UTC; ripley
Repository: CRAN
Date/Publication: 2009-05-24 08:46:01
Built: R 2.9.0; i486-pc-linux-gnu; 2009-06-30 06:00:47 UTC; unix
I did update.packages() before testing and reporting the bug.
I hope that this is correct place to report bug on package of R.
Vaidotas Zemlys
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Mistake in ISOLatin7.enc file (PR#9845)
Full_Name: Vaidotas Zemlys Version: 2.5.1 OS: Ubuntu 7.04 Submission from: (NULL) (213.197.173.50) Hi, There is a mistake in ISOLatin7.enc file which is shipped with grDevices package. Instead of Umacron and umacron there are Ucirmcumflex and ucirmcumflex. There is no U cirmcumflex in ISO Latin 7 encoding, as can be seen in http://en.wikipedia.org/wiki/ISO/IEC_8859-13 and I also can report this as native Lithuanian speaker, since ISO Latin 7 encoding is used for Lithuanian and Latvian languages. Steps to reproduce 1. In R issue commands : postscript(file="test.ps",encoding="ISOLatin7") plot(rnorm(100),main="Ūū") dev.off() When viewing postcript file instead of Ūū you will see Ûû. Changing [uU]circumflex to [uU]macron in file ISOLatin7.enc fixes the problem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with Sweave and pdf.options(encoding="ISOLatin7") (PR#13234)
Hi,
Sweave for some reason does not respect encoding setting in pdf.options.
Everything is OK with ps.options. Thus when using non-default encoding
for graphs, resulting graphics eps file is correct, but pdf file is
not. Workaround is very simple, just use latex->dvips->ps2pdf chain to
get the intended pdf document. I tried to find the explanation for this,
but I did not find anything. If this is documented behaviour, I am sorry
for the disturbance.
After Sweaving the file below, pdflatex and latex->dvips->ps2pdf will
produce different pdfs. The tex file compiled succesfully in Ubuntu
8.04, and TeXLive 2007.
Sincerely yours,
Vaidotas Zemlys
test.Rnw file:
\documentclass[a4paper]{article}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\title{Problem with pdf.options}
\author{Vaidotas Zemlys}
\begin{document}
\maketitle
Note the Lithuanian letters in latex will not display correctly, you
need
additional package. This does not matter to R, since we use Unicode and
pass the
correct encoding.
\begin{center}
<>=
pdf.options(enc="ISOLatin7")
ps.options(enc="ISOLatin7")
plot(rnorm(100),main="Ä
žųÄÅ¡ÄÄįū")
@
\end{center}
\end{document}
--please do not edit the information below--
Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 8.0
year = 2008
month = 10
day = 20
svn rev = 46754
language = R
version.string = R version 2.8.0 (2008-10-20)
Locale:
[EMAIL PROTECTED];LC_NUMERIC=C;[EMAIL PROTECTED];[EMAIL
PROTECTED];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:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Hi, On 03 Nov 2005 12:41:53 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > > We do not usually put features in R which are specific to just some > > distributions of some OSes, and in this case to one editor on those. > > We do not for example include the ESS mode for the much-more-widely-used > > Emacs family of editors. > > > > This looks as if it might be appropriate to the Linux binary packages for > > R, so I suggest you contact their maintainers. But my understanding is > > that this is an issue for gedit and not for R. Indeed .R is just a > > convention (one of many choices, including .r and .q) for R itself. > > > > I do wonder why you concentrated on .R files and not .Rd files, where I > > find syntax highlighting more useful. > > Mime-types shouldn't be distribution-specific or even editor-specific, > should they? The whole point is that they can be used for things like > email attachments that pass from one OS to the other. > > It might be useful to have the mime-type definitions for R (and Rd) > files centralized in R core, with the appropriate OS conventions > systematized. But I think we need to know more. Who keeps track of > mime-types? Can we just grab text/x-R (and text/x-Rd and > application/x-Rdata)? To which extent the XML format a standard; is it > only used by particular applications? > > As far as I know, at least in Debian, the mimetypes are tracked by shared-mime-info package. The upstream is freedesktop.org. I do not know about oficial standarts, but Gnome and KDE tries to adher to some of the freedesktop.org standarts. I can confirm that mimetypes provided by shared-mime-info are widely used in Gnome, for some time now. Vaidotas Zemlys -- Doctorate student, http://www.mif.vu.lt/katedros/eka/katedra/zemlys.php Vilnius University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Hi, On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > One further thought about this: > > On SUSE, > > rpm -qif /usr/share/mime/ > > points at > > http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo > > So I guess that the proper tree to bark at is the upstreams > maintainers of > > http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz > > Instructions there say to submit new XML files to > > https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > It would likely be a good idea to send them first to R-devel for review. > I already barked at upstream. The upstream barked back. The result is here: https://bugs.freedesktop.org/show_bug.cgi?id=1782 There you can find xml file for R scripts. I've made it from some example. It is really only a proof of a concept. But it would not be very difficult to produce xml files for mimetypes of all R related files. We must only decide which R related files would benefit from having mimetypes. My proposal is 1. R source code, R scripts. Files with extensions .R, .r and others (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc 2. R documentation files. File extension .Rd. Mimetype text/x-Rd 3. RData files. File extension .RData, files which at beginning have RDX2. Mimetype application/x-RData. 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype text/x-Rtranscript The relevant xml code could be pushed upstream to end up in freedesktop.org.xml, or it could be distributed with R linux package, and installed into relevant subdirectory of /usr/share/mime. With a bit more work the result could be, that people using for example Nautilus (graphical Gnome browser) could see R related files displayed with R logo, and clicking them could result in various appropriate actions. For example for .RData R process could be iinvoked and relevant .RData file could be loaded. I could write and test the xml code. But first we have to agree on which files benefit from having mimetypes and how the mimetypes should be named. Feel free to suggest. Vaidotas Zemlys -- Doctorate student, http://www.mif.vu.lt/katedros/eka/katedra/zemlys.php Vilnius University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving a plot in R-LINUX
On 1/13/06, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
>
> On 13 January 2006 at 11:02, [EMAIL PROTECTED] wrote:
> | Is there any way to save a plot produced by
> | R in a LINUX (Debian) machine?
>
> It is the same on every platform and ...
>
> | The window opened by R to put the plot in,
> | does not give any option to save it (there
> | are options to move, close, minimise it, etc.
> | but not to save it). How do you do that?
>
What about using dev.copy? Or am I missing something? In windows there
is a context menu when you click with the right mouse button, which
lets you choose how do you want to save the plot. On linux I came up
with such function, which albeit not perfectly but does the job:
d2b <- function(file="Rplot%d.bmp",height=4,width=4,res=150,which=dev.cur(),...)
{
if(which!=dev.cur()) {
cur <- dev.cur()
dev.set(which)
}
else cur <- NULL
dev.copy(device=bitmap,file=file,height=height,width=width,point=8,res=res,...)
dev.off()
if(!is.null(cur))dev.set(cur)
else dev.set(which)
}
It copies told device (current by default) to bitmap file. This
function could be easily adapted for copying to other formats.
Since the answer was too easy, probably I did not understand question
correctly. In that case please ignore this message.
Vaidotas Zemlys
--
Doctorate student, http://www.mif.vu.lt/katedros/eka/katedra/zemlys.php
Vilnius University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7")
2008/11/19 Prof Brian Ripley <[EMAIL PROTECTED]>: > I can't actually check what happens since the message has been garbled en > route to me. Can you please send what you intended using \u escapes so > it is portable. (What I have is what appears to be UTF-8 re-encoded in > UTF-8, things like c3 84 3f.) > > And can you also confirm that the example works correctly directly in pdf()? OK, the modified R code is: plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. > On Fri, 31 Oct 2008, [EMAIL PROTECTED] wrote: > >> Hi, >> >> Sweave for some reason does not respect encoding setting in pdf.options. > > Rather it uses its own setting. I think you need to set option > pdf.encoding="ISOLatin7" on the Sweave call. Is it possible to do that? Sweave function in R, does not support that, and using SweaveHooks produced the same result. > > It would probably be better if Sweave() fetched the default for > options$pdf.encoding from pdf.options(), and definitely that this was > documented. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. I looked at the code of RweaveLatexSetup, and saw that pdf.encoding is defined explicitly, that is how I figured out, that probably eps files are probably ok. Sorry for the garbled message, next time I will send unicode portable code without relying on email encodings. Sincerely yours, Vaidotas Zemlys __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7")
2008/11/19 Prof Brian Ripley <[EMAIL PROTECTED]>: > On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: > >> OK, the modified R code is: >> >> >> plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") >> >> It does not work correctly with Sweave, as I wrote in my email, I >> rechecked. And yes it works if only pdf is used. > > It works for me in xpdf, but not Acroread 8.1.3. Yes, I checked only with evince, and assumed, that Acroread will be similar. Acrobat 9 (on windows) shows the letters, but they are bunched up together. Changing the default family to URWHelvetica did not help either. So that rules out using pdf for me. > >> >> I did not find any mention about encodings in ?Sweave, ?RweaveLatex >> and ?Rtangle, and Sweave manual and FAQ. > > Yes, Sweave is supposedly frozen pending unbundling. > > Note that this does work (at least for me) in lt_LT.utf8: it is because you > were in fr_FR.utf8 that you had a problem. > > So I think the solution is actually pretty simple: use the correct locale. > I've changed R-patched to take the defaults from pdf.options(), but Sweave > should still be able to set them. > Aah, this does not occured to me. I thought that because locale is unicode it should not matter which unicode letters I use. That is a not correct assumption. Thank you for your answers, Vaidotas Zemlys __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
