Re: [Rd] Invalid date-times and as.POSIXct problems (remotely related to DST issues)
Karl Ove Hufthammer wrote: > I think this should be handled as a bug, but I’m not sure which > platforms and versions it applies to, so I’m writing to this list. No response, so I‘ve filed a bug at https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14845 (with some additional info). -- Karl Ove Hufthammer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ESS] completion in [] (R internal completion fails)
Hello,
I am forwarding this from ESS mailing list, as it's a failure of
internal R completion system:
This fails:
utils:::.assignLinebuffer('iris[iris$Spec')
utils:::.assignEnd(15)
utils:::.guessTokenFromLine()
utils:::.completeToken()
utils:::.retrieveCompletions() ## -> [1] "iris[iris$Spec"
This works
utils:::.assignLinebuffer('iris[ iris$Spec') # note the space after [
utils:::.assignEnd(15)
utils:::.guessTokenFromLine()
utils:::.completeToken()
utils:::.retrieveCompletions() ## -> [1] "iris$Species"
Best,
Vitalie.
Andreas Leha
on Wed, 14 Mar 2012 10:21:37 +0100 wrote:
>> Hi all,
>> I am seeing strange behaviour with completion inside [].
>> Suppose I have
>> ttt <- data.frame(aaa=1, bbb=1)
>> and I want to run
>> ttt$aaa[ttt$aaa == 1] <- 2
>> then completion at this point fails:
>> ttt$aaa[ttt$aa
>> On the other hand, strangly enough, this works as expected:
>> ttt$aaa[ ttt$aa
>> Regards,
>> Andreas
>> __
>> ess-h...@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/ess-help
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] merge bug fix in R 2.15.0
Is it intended that the first suffix can no longer be blank? Seems to be
caused by a bug fix to merge in R 2.15.0.
$Rdevel --vanilla
DF1 = data.frame(a=1:3,b=4:6)
DF2 = data.frame(a=1:3,b=7:9)
merge(DF1,DF2,by="a",suffixes=c("",".1"))
Error in merge.data.frame(DF1, DF2, by = "a", suffixes = c("", ".1")) :
there is already a column named b
$R --vanilla
R version 2.14.2 (2012-02-29)
> DF1 = data.frame(a=1:3,b=4:6)
> DF2 = data.frame(a=1:3,b=7:9)
> merge(DF1,DF2,by="a",suffixes=c("",".1"))
a b b.1
1 1 4 7
2 2 5 8
3 3 6 9
>
Matthew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dealing with printf() &c. in third-party library code
Dear all,
I recognise the reason for strongly discouraging use of printf() and
similar C functions in R packages, but I wonder what people do in
practice about third-party code which may be littered with such calls.
I maintain a package (RNiftyReg) which provides an R interface to a
third-party library which contains hundreds of calls to printf(...),
fprintf(stderr,...) and similar. It seems to me that there are several
possible approaches, but all have their issues:
1. Replace all such calls with equivalent Rprintf() calls, using
compiler preprocessing directives to ensure the library does not
become incompatible with other code. For example,
#ifdef RNIFTYREG
Rprintf(...);
#else
printf(...);
#endif
This will be very time-consuming if there are lots of calls, and also
makes the code very untidy and much harder to update when a new
version of the upstream library is released.
2. Remove all such calls from the code altogether, or comment them
out. The problem here is that doing this safely is hard, because the
call could be part of an "if" statement or similar. For example,
if (test)
printf("Something");
do_something_important;
If the middle line here is removed, then the last line becomes
(erroneously) conditioned on the test. Plus, once again, you are
introducing a lot of small changes to the library itself.
3. Redefine printf to use Rprintf, viz.
#ifdef RNIFTYREG
#include
#define printf Rprintf
#endif
This will compile as long as the R function is a drop-in replacement
for the original function, which I believe is true for Rprintf (vs.
printf), but isn't true for Calloc (vs. calloc), for example. And I'm
not sure whether this approach can be used to deal with cases of the
form fprintf(stderr,...), where stderr would need to be redefined.
This approach requires only modest changes to the library itself, but
may be fragile to future changes in R.
Are there any other (better?) alternatives? Any thoughts or advice
would be appreciated.
All the best,
Jon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] issue with Rd2pdf and \Sexpr in Rd files
Hi,
The following command:
R CMD Rd2pdf --no-preview --output=./tmp.pdf --title=test genefu-package.Rd
run against this file:
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/genefu/man/genefu-package.Rd
(username: readonly; password: readonly)
produces a very verbose error (see below)
with R version 2.15.0 alpha (2012-03-07 r58622).
The .Rd file has these lines in it:
Version: \tab \Sexpr{packageDescription("genefu")$Version}\cr
Date: \tab \Sexpr{packageDescription("genefu")$Date}\cr
If I take these lines out, or take out the \Sexpr part, the Rd2pdf
command will complete successfully.
Is there some other step I need to run to evaluate the \Sexpr tags
before running Rd2pdf, or is there an issue that needs to be fixed?
Thanks,
Dan
Error output:
Converting Rd files to LaTeX ...
genefu-package.Rd
Creating pdf output from LaTeX ...
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'Rd2.tex' failed.
Messages:
/usr/bin/texi2dvi: pdflatex exited with bad status, quitting.
/usr/bin/texi2dvi: see Rd2.log for errors.
Output:
This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
restricted \write18 enabled.
entering extended mode
(/Users/dtenenba/dev/bioc_devel/genefu/man/.Rd2pdf62869/Rd2.tex
LaTeX2e <2011/06/27>
Babel and hyphenation patterns for english, dumylang, nohyphenation, ge
rman-x-2011-07-01, ngerman-x-2011-07-01, afrikaans, ancientgreek, ibycus, arabi
c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, czech, danis
h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, finnis
h, french, galician, german, ngerman, swissgerman, monogreek, greek, hungarian,
icelandic, assamese, bengali, gujarati, hindi, kannada, malayalam, marathi, or
iya, panjabi, tamil, telugu, indonesian, interlingua, irish, italian, kurmanji,
lao, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, nynorsk, pol
ish, portuguese, romanian, russian, sanskrit, serbian, serbianc, slovak, sloven
ian, spanish, swedish, turkish, turkmen, ukrainian, uppersorbian, welsh, loaded
.
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/book.cls
Document Class: book 2007/10/19 v1.4h Standard LaTeX document class
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/bk10.clo))
(/Library/Frameworks/R.framework/Resources/share/texmf/tex/latex/Rd.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/tools/bm.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/alltt.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/tools/verbatim.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/url/url.sty) NOT loading ae
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/t1enc.def))
(/usr/local/texlive/2011/texmf-dist/tex/latex/psnfss/times.sty)
NOT loading lmodern
(/usr/local/texlive/2011/texmf-dist/tex/latex/inconsolata/inconsolata.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/textcomp.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/local/texlive/2011/texmf-dist/tex/latex/graphics/keyval.sty))
(/usr/local/texlive/2011/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2011/texmf-dist/tex/latex/pdftex-def/pdftex.def
(/usr/local/texlive/2011/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/local/texlive/2011/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)))
(/usr/local/texlive/2011/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/local/texlive/2011/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
(/usr/local/texlive/2011/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
(/usr/local/texlive/2011/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/local/texlive/2011/texmf-dist/tex/latex/latexconfig/hyperref.cfg))
Package hyperref Message: Driver (autodetected): hpdftex.
(/usr/local/texlive/2011/texmf-dist/tex/latex/hyperref/hpdftex.def
(/usr/local/texlive/2011/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
Package hyperref Warning: Option `hyperindex' has already been used,
(hyperref)setting the option has no effect on input line 356.
Package hyperref Warning: Option `pagebackref' has already been used,
(hyperref)setting the option has no effect on input line 356.
) (/usr/local/texlive/2011/texmf-dist/tex/latex/base/makeidx.sty)
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/inputenc.sty
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/utf8.def
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/t1enc.dfu)
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/ot1enc.dfu)
(/usr/local/texlive/2011/texmf-dist/tex/latex/base/omsenc.dfu)
(/usr/local/texlive/2011/texmf-dist/tex
[Rd] using predict() with poly(x, raw=TRUE)
Dear r-devel list members, I've recently encountered the following problem using predict() with a model that has raw-polynomial terms. (Actually, I encountered the problem using model.frame(), but the source of the error is the same.) The problem is technical and concerns the design of poly(), which is why I'm sending this message to r-devel rather than r-help. To illustrate: snip - > mod.pres <- lm(prestige ~ log(income, 10) + poly(education, 3) + poly(women, 2), +data=Prestige) # Prestige data from car package > predict(mod.pres, newdata=data.frame(education=10, income=6000, women=30)) # works 1 39.66414 > model.frame(delete.response(terms(mod.pres)), data.frame(education=10, income=6000, women=30)) log(income, 10) poly(education, 3).1 poly(education, 3).2 poly(education, 3).3 poly(women, 2).1 poly(women, 2).2 13.778151 -0.02691558 -0.08720086 0.07199804 0.003202256 -0.138777837 > mod.pres.raw <- lm(prestige ~ log(income, 10) + poly(education, 3, raw=TRUE) + poly(women, 2, raw=TRUE), +data=Prestige) > predict(mod.pres.raw, newdata=data.frame(education=10, income=6000, women=30)) # doesn't work Error in poly(education, 3, raw = TRUE) : 'degree' must be less than number of unique points > model.frame(delete.response(terms(mod.pres.raw)), data.frame(education=10, income=6000, women=30)) Error in poly(education, 3, raw = TRUE) : 'degree' must be less than number of unique points snip - I understand the source of the error, but what's unclear to me is why it's necessary for poly() to check the degree of the polynomial against the number of unique supplied points when raw=TRUE. For example, if I simply remove this check from poly(), then snip - > predict(mod.pres.raw, newdata=data.frame(education=10, income=6000, women=30)) 1 39.66414 > model.frame(delete.response(terms(mod.pres.raw)), data.frame(education=10, income=6000, women=30)) log(income, 10) poly(education, 3, raw = TRUE).1 poly(education, 3, raw = TRUE).2 poly(education, 3, raw = TRUE).3 poly(women, 2, raw = TRUE).1 poly(women, 2, raw = TRUE).2 13.778151 10 100 1000 30 900 snip - Of course, if one then used the modified poly() in a regression with fewer unique Xs than the degree of the polynomial, the model matrix would be singular; but why not just let the error appear at that stage? I could solve my problem by maintaining a local version of poly(), but why should it not be possible to get predictions under these circumstances? Best, John John Fox Senator William McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] methods::trace fails when signature specified
With > R.version.string [1] "R version 2.15.0 alpha (2012-03-14 r58748)" trying to trace a method using the 'signature' argument fails rather than enabling the trace: > trace(initialize, signature="ANY") Error in matchSignature(signature, fdef, where) : trying to match a method signature of class “signature”; expects a list or a character vector -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dealing with printf() &c. in third-party library code
On 03/14/2012 05:15 AM, Jon Clayden wrote:
Dear all,
I recognise the reason for strongly discouraging use of printf() and
similar C functions in R packages, but I wonder what people do in
practice about third-party code which may be littered with such calls.
I maintain a package (RNiftyReg) which provides an R interface to a
third-party library which contains hundreds of calls to printf(...),
fprintf(stderr,...) and similar. It seems to me that there are several
possible approaches, but all have their issues:
1. Replace all such calls with equivalent Rprintf() calls, using
compiler preprocessing directives to ensure the library does not
become incompatible with other code. For example,
#ifdef RNIFTYREG
Rprintf(...);
#else
printf(...);
#endif
This will be very time-consuming if there are lots of calls, and also
makes the code very untidy and much harder to update when a new
version of the upstream library is released.
2. Remove all such calls from the code altogether, or comment them
out. The problem here is that doing this safely is hard, because the
call could be part of an "if" statement or similar. For example,
if (test)
printf("Something");
do_something_important;
If the middle line here is removed, then the last line becomes
(erroneously) conditioned on the test. Plus, once again, you are
introducing a lot of small changes to the library itself.
3. Redefine printf to use Rprintf, viz.
#ifdef RNIFTYREG
#include
#define printf Rprintf
#endif
This will compile as long as the R function is a drop-in replacement
for the original function, which I believe is true for Rprintf (vs.
printf), but isn't true for Calloc (vs. calloc), for example. And I'm
not sure whether this approach can be used to deal with cases of the
form fprintf(stderr,...), where stderr would need to be redefined.
This approach requires only modest changes to the library itself, but
may be fragile to future changes in R.
Are there any other (better?) alternatives? Any thoughts or advice
would be appreciated.
In Makevars, I add -Dfprintf=my_fprintf to the pre-processor flags and
then implement my_fprintf in a separate source file. This means that the
source code of the 3rd party library is not touched, and there is some
scope for re-mapping or otherwise intercepting function arguments. For
abort and error, I throw an error that encourages the user to save and
quit immediately, though this is far from ideal. I too would be
interested in better practices for dealing with this, short of
whole-sale modification of the third-party library.
Martin
All the best,
Jon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] windows() device: plot does not refresh with new drawing after opening and closing a new device
Hello, I see this problem in 2.14.1, a recent dev, and 2.15.0 alpha, but not in an older build. Start the R windows console and run this code: plot(1:10);windows();dev.off();points(10:1) The second set of points does not show up until the window is minimized and restored. If the device is replaced with a file-based one (pdf, png) there's no problem. I see this behaviour on these versions: R version 2.15.0 alpha (2012-03-13 r58726) Platform: x86_64-pc-mingw32/x64 (64-bit) R Under development (unstable) (2012-02-28 r58513) Platform: x86_64-pc-mingw32/x64 (64-bit) R version 2.14.1 (2011-12-22) Platform: x86_64-pc-mingw32/x64 (64-bit) I have an old beta install of 2.13.2 where the problem does not occur: R version 2.13.2 beta (2011-09-22 r57035) Platform: x86_64-pc-mingw32/x64 (64-bit) Cheers, Mike. -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
