Re: [Rd] parent.frame(1) of a S4 method is not a calling environment.
Hadley Wickham writes: > On Tuesday, August 17, 2010, Vitaly S. wrote: >> Duncan Murdoch writes: >> >>> Vitaly S. wrote: Martin Morgan writes: >> So, can I be sure that for such functions parent.frame(2) will always >> work? >> What are the additional rules? >> > callNextMethod() will cause additional problems; the idea that you'll > grab things from somewhere other than function arguments doesn't seem > like a robust design, even if it's used in some important parts of R. > > Martin > > That make it difficult to handle unevaluated expressions in methods. A solution would be to explicitly require the users to use quote() or expression(), and then to use the "expression" in the signature. Slightly unpleasant, though. >>> >>> You could use formulas for that. If you pass in >>> >>> formula = ~ x + y*z >>> >>> then environment(formula) will be the right evaluation environment, and >>> formula[[2]] will be the unevaluated x + >>> y*z. >>> >>> Duncan Murdoch >> >> Thank you Duncan, I didn't know that. >> >> For programmatic use though, formula interface is slightly inconvenient. A >> specialized function and class would be desirable. With the advent of more >> and >> more complex S4 classes, unevaluated expressions in methods calls will >> became a >> necessity, that's my feeling. > > I probably should move the quoting related out of plyr into it's own > package to facilitate this type of reuse. I think the current > structure is quite general. That would be neat. An S4 class "quote" which would store the parent.frame as a slot would be great! > > Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Problems building own package (Error: "package hasbeen build before R-2.10.0")
> -Ursprüngliche Nachricht-
> Von: William Dunlap [mailto:wdun...@tibco.com]
> Gesendet: Dienstag, 17. August 2010 22:25
> An: Janko Thyson
> Betreff: RE: [Rd] [R] Problems building own package (Error: "package
> hasbeen build before R-2.10.0")
>
> > ...
> > > > R CMD check mypackage works fine (no errors, no warnings)
> > > >
> > > > R CMD build mypackage works fine (no errors, no warnings)
> > > >
> > > > R CMD INSTALL -library="C:\R\R-2.11.1\library"
> > > > "something\mypackage\mypackage_1.0.tar.gz" works fine (no
> > errors, no
> > > > warnings)
> > > >
> > > >
> > > >
> > > > However, when I try loading the package in an R-Session (version
> > > 2.11.1) via
> > > > "library(mypackage)", R complains about the package being build
> > > before
> > > > version R-2.10.0 and tells me to rebuild it.
>
> Start R by typing 'R' (no other arguments) from the same
> command window that you used for the 'R CMD ...' commands.
> You ought to be able to load the package without warning
> from that session. Compare the output of Sys.getenv("R_HOME")
> and/or print(version) in that session and the in a session
> that could not load the package without warnings.
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
Hi Bill,
thanks for the suggestion. I don't quite get it, but even though version
2.11.1 was the only one in my PATH, it was always version 2.9.1 that was
called when using R CMD. I could only resolve it by uninstalling version
2.9.1, which is totally fine considering we're at 2.11.1 now ;-)
Janko
> > >
> > >
> > > So the R that is in your PATH is < 2.10.x
> > > Change your PATH and add the R version your are actually working
> > > with
> >
> > As I wrote: "My PATH is set up as explained in the R-Admin
> > manual. Also, the
> > only R version stated there is "C:\R\R-2.11.1\bin;".
> >
> > > Uwe Ligges
> > >
> > >
> > > >
> > > >
> > > > Could this possibly be due to the fact that I have multiple R
> > > versions
> > > > installed (this also includes the most recent one, though)?
> > > >
> > > >
> > > >
> > > > To provide you with some details:
> > > >
> > > > - Running Windows XP
> > > >
> > > > - All of my R versions are under "C:\R" (versions 2.9.2,
> > > 2.10.1,
> > > > 2.11.1).
> > > >
> > > > - I installed Rtools (version 2.1.2) to "C:\Rtools" and
> > > pointed it
> > > > to "C:\R" (as this was the default) to interact with R
> > (should this
> > > maybe
> > > > have been "C:\R\R-2.11.1"?). I also installed everything else
> > > necessary to
> > > > build packages (Inno Setup etc.).
> > > >
> > > > - My PATH is set up as explained in R-Admin manual.
> Also,
> > > the only
> > > > R version stated there is "C:\R\R-2.11.1\bin;".
> > > >
> > > > - I updated the DESCRIPTION file and specified
> > all .Rd files
> > > > correctly.
> > > >
> > > >
> > > >
> > > > Any idea what I'm doing wrong?
> > > >
> > > >
> > > >
> > > > Thanks a ton,
> > > >
> > > > Janko
> > > >
> > > >
> > > >
> > > >_
> > > >
> > > >
> > > >
> > > > Janko Thyson
> > > > janko.thy...@ku-
> > > eichstaett.de
> > > >
> > > > Catholic University of Eichstätt-Ingolstadt
> > > > Ingolstadt School of Management
> > > > Statistics and Quantitative Methods
> > > > Auf der Schanz 49
> > > > D-85049 Ingolstadt
> > > >
> > > > www.wfi.edu/lsqm
> > > >
> > > > Fon: +49 841 937-1923
> > > > Fax: +49 841 937-1965
> > > >
> > > > This e-mail and any attachment is for authorized use by
> > the intended
> > > > recipient(s) only. It may contain proprietary material,
> > confidential
> > > > information and/or be subject to legal privilege. It should not
> be
> > > > copied, disclosed to, retained or used by any other party.
> > > > If you are not an intended recipient then please promptly
> > delete this
> > > > e-mail and any attachment and all copies and inform the sender.
> > > >
> > > >
> > > >
> > > >_
> > > >
> > > >
> > > >
> > > >
> > > > [[alternative HTML version deleted]]
> > > >
> > > >
> > > >
> > > >
> > > > __
> > > > r-h...@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-help
> > > > PLEASE do read the posting guide http://www.R-
> project.org/posting-
> > > guide.html
> > > > and provide commented, minimal, self-contained, reproducible
> code.
> >
> > __
> > 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] 32/64-bit Windows builds for R-devel
We now have the integrated 32/64-bit installer for R-devel available from http://cran.r-project.org/bin/windows/base/rdevel.html , and binary builds of almost all the CRAN packages from CRAN or CRAN extras (and BioC 2.7 has a fairly complete 32/64-bit repository). There is also a win-builder service available for R-devel. These are built with different toolchains from R 2.11.x, using gcc 4.5.0 for 32-bit and 4.5.1 without leading underscores for 64-bit. We intend now to stop work on 64-bit Windows builds for 2.11.x: automated updates to the repositories will still be done, but no more manual updates. People using 64-bit Windows builds of R are advised to migrate to an R-devel snapshot. Because of the volunteers' vacations, there will be minimal support for Windows' binary packages for the next month and in particular package updates may be delayed. Some packages still need updates (apart from those already updated on CRAN extras) for use on Windows with R-devel, notably lossDev mvabund phylobase RInside Rserve xlsReadWrite Brian Ripley -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] Automatically retrieve correct collation
Dear List, consider the following scenario: setClass(Class = "A", representation = representation(B = "B", C = "C")) setClass(Class = "B", representation = representation(C = "C")) setClass(Class = "C", representation = representation(something = "character")) Obviously, the collation for sourcing these defs needs to be: C, B, A. Which doesn't correspond to the default collation of R (alphabetically). I've tried to pick up on how to ensure the right collation when building R Packages by reading some previous posts and as far as I understand I've basically got two options here: 1) Put all class defs in one script, e.g. allClasses.R. 2) Manually specify the collation via the "Collate" field in the DESCRIPTION file. I'm used to organizing my classes, generics, methods etc. on a "one-per-script" basis in various subdirectories (e.g. R/classes, R/methods etc.) and try automate manual steps wherever possible (not sure if that's the way most of you guys code, but it definitely helped me stay on top of things). But this doesn't really go well with my two options above, does it? ;-) So I thought about setting up a routine that - investigates the source code of all classes (via parsing and looking into the "representation" argument) - finds out the valid collation by itself based on all classes that it found in the representation argument of the respective class defs - and then writes all the class defs to one R script, e.g. allClasses.R, so I can bundle all my code in an R Package without worrying about the collation. This way I could stick to my old habits while automating the process of building a package a bit ;-) Now, I managed to get this done for "simple" class defs like the ones above but haven't looked into more complex class defs (e.g. including "contains" etc.) yet. Has anyone tried and succeeded in doing something similar or are all of you into the "one-script-contains-all" paradigm? If anyone is interested, I'd be glad to share code. Likewise I'd be interested in hearing about other "best practices" in this respect. Best regards, Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c.POSIXct
No one answered this so I submitted it to the bugs system and there I
got the response that it is documented behavior; however, whether its
documented or not is hardly the point -- its undesirable that tzone is
lost when using c.
On Thu, Aug 12, 2010 at 11:33 AM, Gabor Grothendieck
wrote:
> Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a
> tzone attribute even if x1 or x2 or both do but it should.
>
> This could be fixed with the following c.POSIXct:
>
> c.POSIXct <- function (..., recursive = FALSE) {
> tzones <- lapply(list(...), attr, which = "tzone")
> lengths <- sapply(tzones, length)
> if (any(lengths > 1)) stop("tzone cannot have length greater than 1")
> which <- sapply(tzones, length) == 1
> tzone <- unique(unlist(tzones[which]))
> if (length(tzone) != 1) tzone <- NULL
> structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt",
> "POSIXct"), tzone = tzone)
> }
>
> # test
> x1 <- Sys.time()
> x2 <- structure(x1, tzone = "UTC")
> x3 <- structure(x1, tzone = "other")
>
> # these all currently give NULL but with
> # above give indicated value
>
> attr(c(x1, x1), "tzone") # NULL
> attr(c(x2, x2), "tzone") # "UTC"
> attr(c(x1, x2), "tzone") # "UTC"
> attr(c(x2, x1), "tzone") # "UTC"
> attr(c(x1, x2, x3), "tzone") # NULL
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] perl.exe has stopped working
Hello: I just installed 14 security updates for Vista x64, and now "R CMD build packagename" terminates, saying, "perl.exe has stopped working". I reinstalled Rtools211 using the latest version after uninstalling the version I installed on 4/3/2010. What do you suggest? I can install the latest version of perl from "www.perl.org" (5.12.1), but I thought I'd ask here first. Thanks, Best Wishes, Spencer Graves __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c.POSIXct
On Aug 18, 2010, at 6:23 PM, Gabor Grothendieck wrote:
> No one answered this so I submitted it to the bugs system and there I
> got the response that it is documented behavior; however, whether its
> documented or not is hardly the point -- its undesirable that tzone is
> lost when using c.
>
That's one man's opinion - from docs
if you want to specify an object in a particular timezone but
to be printed in the current timezone you may want to remove the
‘"tzone"’ attribute (e.g. by ‘c(x)’).
so apparently that is a design choice and hence I doubt it can be changed as it
would break code that uses that feature. As many things in R whether it was a
good choice is up for debate but it has been made already. (Think about how you
would combine different times with different tzones - there is no "right" way
to do so and thus stripping is very plausible and consistent)
Cheers,
Simon
> On Thu, Aug 12, 2010 at 11:33 AM, Gabor Grothendieck
> wrote:
>> Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a
>> tzone attribute even if x1 or x2 or both do but it should.
>>
>> This could be fixed with the following c.POSIXct:
>>
>> c.POSIXct <- function (..., recursive = FALSE) {
>>tzones <- lapply(list(...), attr, which = "tzone")
>>lengths <- sapply(tzones, length)
>>if (any(lengths > 1)) stop("tzone cannot have length greater than 1")
>>which <- sapply(tzones, length) == 1
>>tzone <- unique(unlist(tzones[which]))
>>if (length(tzone) != 1) tzone <- NULL
>> structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt",
>>"POSIXct"), tzone = tzone)
>> }
>>
>> # test
>> x1 <- Sys.time()
>> x2 <- structure(x1, tzone = "UTC")
>> x3 <- structure(x1, tzone = "other")
>>
>> # these all currently give NULL but with
>> # above give indicated value
>>
>> attr(c(x1, x1), "tzone") # NULL
>> attr(c(x2, x2), "tzone") # "UTC"
>> attr(c(x1, x2), "tzone") # "UTC"
>> attr(c(x2, x1), "tzone") # "UTC"
>> attr(c(x1, x2, x3), "tzone") # NULL
>>
>
> __
> 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] c.POSIXct
On Wed, Aug 18, 2010 at 10:34 PM, Simon Urbanek wrote: > > On Aug 18, 2010, at 6:23 PM, Gabor Grothendieck wrote: > >> No one answered this so I submitted it to the bugs system and there I >> got the response that it is documented behavior; however, whether its >> documented or not is hardly the point -- its undesirable that tzone is >> lost when using c. >> > > That's one man's opinion - from docs > > if you want to specify an object in a particular timezone but > to be printed in the current timezone you may want to remove the > ‘"tzone"’ attribute (e.g. by ‘c(x)’). > > so apparently that is a design choice and hence I doubt it can be changed as > it would break code that uses that feature. As many things in R whether it > was a good choice is up for debate but it has been made already. (Think about > how you would combine different times with different tzones - there is no > "right" way to do so and thus stripping is very plausible and consistent) > I did already address the ambiguity point in the suggested code that I posted. It only maintains the tzone if there is no ambiguity. Note that there have been significant changes in POSIXt relatively recently, namely switching POSIXt and POSIXct class order, so it seems that such changes are not beyond possibility. At any rate, the underlying objective of getting time zones to work in the expected way still seems desirable. If backward compatibility is to be invoked (even though it wasnt in the case I just cited) then it would still be possible to address this with a new core class or subclass. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c.POSIXct
I'm with Gabor on this. I naively would not expect c() to strip attributes generally, and I've been surprise more than once to find the time zone attribute stripped when I did not expect that. Might it make sense to add an argument like "keepAttributes=FALSE" to the "c" function? Then people like Gabor and me would know that we would have to specify "keepAttributes = TRUE" if we wanted attributes to be kept. Having this in the documentation would also help advertise the default behavior. I would expect that attributes like "dim" and "dimnames" should always be dropped, regardless of the value of "keepAttributes". With "keepAttributes = TRUE", "names" would be concatenated, and other attributes would be taken from the first argument with other attributes of later arguments ignored. QUESTIONS: 1. With POSIXct, isn't the numeric part always in GMT, regardless of time zone? Then the "tzone" attribute only affects the display? Consider the following: > (z <- Sys.time()) [1] "2010-08-18 21:16:38 PDT" > as.numeric(z) [1] 1282191399 > attr(z, 'tzone') <- 'GMT' > as.numeric(z) [1] 1282191399 > z [1] "2010-08-19 04:16:38 GMT" 2. How can one specify a time zone other than "GMT" and the default local time zone? > attr(z, 'tzone') <- Sys.timezone() > z [1] "2010-08-19 04:16:38 GMT" Warning message: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'PDT' Thanks, Spencer Graves On 8/18/2010 7:53 PM, Gabor Grothendieck wrote: On Wed, Aug 18, 2010 at 10:34 PM, Simon Urbanek wrote: On Aug 18, 2010, at 6:23 PM, Gabor Grothendieck wrote: No one answered this so I submitted it to the bugs system and there I got the response that it is documented behavior; however, whether its documented or not is hardly the point -- its undesirable that tzone is lost when using c. That's one man's opinion - from docs if you want to specify an object in a particular timezone but to be printed in the current timezone you may want to remove the ‘"tzone"’ attribute (e.g. by ‘c(x)’). so apparently that is a design choice and hence I doubt it can be changed as it would break code that uses that feature. As many things in R whether it was a good choice is up for debate but it has been made already. (Think about how you would combine different times with different tzones - there is no "right" way to do so and thus stripping is very plausible and consistent) I did already address the ambiguity point in the suggested code that I posted. It only maintains the tzone if there is no ambiguity. Note that there have been significant changes in POSIXt relatively recently, namely switching POSIXt and POSIXct class order, so it seems that such changes are not beyond possibility. At any rate, the underlying objective of getting time zones to work in the expected way still seems desirable. If backward compatibility is to be invoked (even though it wasnt in the case I just cited) then it would still be possible to address this with a new core class or subclass. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Automatically retrieve correct collation
Hi, roxygen can create the collate field for you, if you specify the dependencies in the commented code. I've never tested it with S4 classes though. HTH, baptiste On 18 August 2010 22:28, Janko Thyson wrote: > Dear List, > > consider the following scenario: > > setClass(Class = "A", representation = representation(B = "B", C = "C")) > setClass(Class = "B", representation = representation(C = "C")) > setClass(Class = "C", representation = representation(something = > "character")) > > Obviously, the collation for sourcing these defs needs to be: C, B, A. Which > doesn't correspond to the default collation of R (alphabetically). > > I've tried to pick up on how to ensure the right collation when building R > Packages by reading some previous posts and as far as I understand I've > basically got two options here: > 1) Put all class defs in one script, e.g. allClasses.R. > 2) Manually specify the collation via the "Collate" field in the DESCRIPTION > file. > > I'm used to organizing my classes, generics, methods etc. on a > "one-per-script" basis in various subdirectories (e.g. R/classes, R/methods > etc.) and try automate manual steps wherever possible (not sure if that's > the way most of you guys code, but it definitely helped me stay on top of > things). But this doesn't really go well with my two options above, does it? > ;-) > > So I thought about setting up a routine that > - investigates the source code of all classes (via parsing and looking into > the "representation" argument) > - finds out the valid collation by itself based on all classes that it found > in the representation argument of the respective class defs > - and then writes all the class defs to one R script, e.g. allClasses.R, so > I can bundle all my code in an R Package without worrying about the > collation. > > This way I could stick to my old habits while automating the process of > building a package a bit ;-) > > Now, I managed to get this done for "simple" class defs like the ones above > but haven't looked into more complex class defs (e.g. including "contains" > etc.) yet. > > Has anyone tried and succeeded in doing something similar or are all of you > into the "one-script-contains-all" paradigm? If anyone is interested, I'd be > glad to share code. Likewise I'd be interested in hearing about other "best > practices" in this respect. > > Best regards, > Janko > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Dr. Baptiste Auguié Departamento de Química Física, Universidade de Vigo, Campus Universitario, 36310, Vigo, Spain tel: +34 9868 18617 http://webs.uvigo.es/coloides __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] One possible cause for incorrect symbols in X11() output
There have been spasmodic reports of symbols such as pi and infinity in plotmath being reproduced incorrectly on the X11 device on some Linux systems (at least Ubuntu 10 and Fedora 12/13), and we've managed to track down one cause whilst investigating PR#14355. Some systems have Wine and hence the Wine symbol font installed. 'fontconfig', which is used by cairographics in X11(type='cairo') and many other applications, prefers the Wine symbol font to the standard Type 1 URW font, and seems to misinterpret its encoding. You may well have Wine installed without realizing it (as I did) -- it is increasingly common as a dependency of other software. The best test is to run % fc-match symbol s05l.pfb: "Standard Symbols L" "Regular" This is the result on a system without Wine: if you see % fc-match symbol symbol.ttf: "Symbol" "Regular" you at least potentially have the problem. A good test is to look at ?points and run the function TestChars() defined there as TestChars(font=5) If you do have the problem, a workaround is to add the following lines to ~/.fonts.conf or /etc/fonts/local.conf (which you may need to create): Symbol Standard Symbols L and repeat the fc-match test to check that it worked. (This workaround was culled from https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/551977 ) -- Brian D. Ripley, rip...@stats.ox.ac.uk 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
