[Rd] CRAN website: link targets
Hello R-masters! R and CRAN webpages use HTML frames for layout. Links to files such as PDF are therefore opened within frame. However, with PDFs this can be distracting if you have a small monitor, since left frame can be small for viewing PDFs with bookmark toolbar in the left in Acrobat Reader. It isn't such a bug problem with others i.e. (K)Ghostview etc, but it can be still small to look at. I suggest to add targets to all links to PDF files. If one wants to see that link will be opened in new frame/tab then target=_blank should used, otherwise target=_top will cause that PDF will be opened over all frames of current website. I can help if you find this idea good and don't find time to do it. -- Lep pozdrav / With regards, Gregor Gorjanc --- University of Ljubljana Biotechnical FacultyURI: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department mail: gregor.gorjanc at bfro.uni-lj.si Groblje 3 tel: +386 (0)1 72 17 861 SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europe __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN website: link targets
On Fri, 25 Mar 2005, Gregor GORJANC wrote: Hello R-masters! This is R-devel, not the feedback page for CRAN/www.r-project.org. R R webpages do not AFAICS. www.r-project.org may, but that is not R. and CRAN webpages use HTML frames for layout. Links to files such as PDF are therefore opened within frame. However, with PDFs this can be distracting That is a function of your browser settings, not part of the WWW standard. Other settings open files in the assigned PDF reader. if you have a small monitor, since left frame can be small for viewing PDFs with bookmark toolbar in the left in Acrobat Reader. It isn't such a bug problem with others i.e. (K)Ghostview etc, but it can be still small to look at. I suggest to add targets to all links to PDF files. If one wants to see that link will be opened in new frame/tab then target=_blank should used, otherwise target=_top will cause that PDF will be opened over all frames of current website. A decent browser will allow you the choice of opening in the frame, in a new tab/window or in the application (here the PDF reader). If yours does not, try a better browser (e.g. Firefox). What I do think is desirable is for *off-site* HTML links (e.g. for the mailing lists) to use target=_top. That is certainly what my O'Reilly HTML book recommends. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] can R_do_slot_assign change slot type
I've done this by accident before and it works, but causes trouble down the line (IIRC saving and loading objects causes problems). On Mar 21, 2005, at 10:22 PM, Vadim Ogranovich wrote: Hi, It seems that R_do_slot_assign can change the type of an S4 class slot. For example I have a class setClass(ostream, representation(id = integer, keepOpen = logical)) and inside a C-function I was able to assign a RAW vector to the id slot. Is this intentional? I remember reading somewhere that the slot type is guaranteed by R. Maybe this doesn't extend to C code? Now, in the above example I actually don't know the eventual type of the 'id' slot, it will be set up in some C code that intializes the class instance. What is the right way to define the representation in such a case? Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel --- Byron Ellis ([EMAIL PROTECTED]) Oook -- The Librarian __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 methods semantics questions
Some quick questions about S4 methods. Does the typing of S4 methods mean that lazy evaluation is no longer possible? It seems that you would need to evaluate the arguments to determine their type at dispatch. Second, what role, if any, do default arguments play in S4 methods? I notice that you can put default arguments into generics but that the dispatch is still done on the type of the calling argument rather than the default argument, though the default arg is substituted. However, default values for arguments in method definition seem to be stripped or, more likely, overridden at dispatch by the calling argument (i.e. missing). Some examples: setGeneric(foo,function(x=bar) standardGeneric(foo)) setMethod(foo,missing,function(x) print(x)) foo() [1] bar setGeneric(foo,function(x,y) standardGeneric(foo)) setMethod(foo,numeric,function(x,y=2) x+y) foo(1) Error in foo(1) : argument y is missing, with no default --- Byron Ellis ([EMAIL PROTECTED]) Oook -- The Librarian __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 methods semantics questions
Byron Ellis wrote: Some quick questions about S4 methods. Does the typing of S4 methods mean that lazy evaluation is no longer possible? It seems that you would need to evaluate the arguments to determine their type at dispatch. Yes, it would be a neat trick to know the class of an actual argument without evaluating it ;-) However, the evaluation proceeds stepwise until a unique method matches, so that arguments not needed to do the dispatch will not yet be evaluated. The order of evaluation is controlled by the signature of the generic, by default all the arguments in order, but specifiable via the signature= argument to setGeneric. Second, what role, if any, do default arguments play in S4 methods? I notice that you can put default arguments into generics but that the dispatch is still done on the type of the calling argument rather than the default argument, though the default arg is substituted. Yes, dispatch depends on the call, not on the default expressions for the arguments. If an actual argument is missing, the dispatch tries to match missing or ANY. However, default values for arguments in method definition seem to be stripped or, more likely, overridden at dispatch by the calling argument (i.e. missing). Some examples: setGeneric(foo,function(x=bar) standardGeneric(foo)) setMethod(foo,missing,function(x) print(x)) foo() [1] bar setGeneric(foo,function(x,y) standardGeneric(foo)) setMethod(foo,numeric,function(x,y=2) x+y) foo(1) Error in foo(1) : argument y is missing, with no default Well, the intent is that defaults are indeed taken from the method, if there is a default there, otherwise from the generic. It looks as if there is a bug in the case that the generic has NO default for that argument (unless, of course, it's a subtle feature, but not that I can think of at the moment). Your example works as intended if there is a default expression for y in the generic: R setGeneric(foo,function(x,y=stop(Need y)) standardGeneric(foo)) [1] foo R setMethod(foo,numeric,function(x,y=2) x+y) [1] foo R foo(1) [1] 3 --- Byron Ellis ([EMAIL PROTECTED]) Oook -- The Librarian __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R fails to start (PR#7747)
Full_Name: Susan Kirschenbaum Version: 2.0.1 OS: Mac OS 10.3.8 Submission from: (NULL) (164.223.72.7) R failes to start. The console opens but, before fully loaded, it quits __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 methods semantics questions
John Chambers [EMAIL PROTECTED] writes: Well, the intent is that defaults are indeed taken from the method, if there is a default there, otherwise from the generic. It looks as if there is a bug in the case that the generic has NO default for that argument (unless, of course, it's a subtle feature, but not that I can think of at the moment). Your example works as intended if there is a default expression for y in the generic: R setGeneric(foo,function(x,y=stop(Need y)) standardGeneric(foo)) [1] foo R setMethod(foo,numeric,function(x,y=2) x+y) [1] foo R foo(1) [1] 3 FWIW, I've encountered the same error that the OP described. I certainly don't know if it is a bug, but I can say that I expected it to work based on the documentation of setMethod. I ended up with a different workaround: if you don't need to do dispatching on the default arguments, you can set setGeneric(foo, function(x, ...) standardGeneric(foo)) and then methods with defaults defined in their function do the expected thing. Best, + seth __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in setClass.Rd (PR#7748)
Full_Name: Stephen Weigand Version: R-alpha OS: Mac OS X Submission from: (NULL) (129.176.151.21) In R-alpha (R-latest.tar.gz as of Fri Mar 25 18:34:05 CST 2005) the file setClass.Rd has the following typo: Is this a the name of a formally defined class? Either a or the should be removed. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] na.omit error message
If I create a bivariate ts series with 3 time points and run na.omit on it expecting it to reduce it to a one point ts series instead I get the following error messasge: R hh - ts(matrix(c(NA,1:4,NA),3), start = c(1951,8), freq=12) R hh Series 1 Series 2 Aug 1951 NA3 Sep 195114 Oct 19512 NA R na.omit(hh) Error in tsp-(`*tmp*`, value = c(1951.667, 1951.667, : invalid time series parameters specified If I replace na.omit with na.contiguous then I get a protection stack overflow: R na.contiguous(hh) Error: protect(): protection stack overflow R R.version.string # Windows XP [1] R version 2.1.0, 2005-03-23 Any comments on what is wrong? __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RGUI font problem (PR#7749)
Full_Name: Christos Hatzis Version: 2.0.1 patched (2005-02-18) OS: WinXP SP2 Submission from: (NULL) (24.61.19.101) I had encountered a similar problem when changing the font in the R Console and then then open the graphics device by plot(), the console window whites out. this might be related to bug report 7271. I mentioned it sometime back and was told is was not reproducible. Now I have encountered a similar problem that does not appear to relate to the graphics device. I started an R session, changed the font to size 8, Apply/OK. Then I opened a help page by typing ?plot the R help page opened in a different (system?) font and the font in the console also changed to the same bold-face, non-proportional font. Then when I typed another help command, the console completely blanked out. There seems to be some strange interaction going on between new windows opened by the system and the font setting in the GUI preferences. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGUI font problem (PR#7749)
This would appear to be the same as PR#7277. That too is not really reproducible. One possible crucial piece of missing information: is RGui being run in SDi or MDI mode? On Sat, 26 Mar 2005 [EMAIL PROTECTED] wrote: Full_Name: Christos Hatzis Version: 2.0.1 patched (2005-02-18) OS: WinXP SP2 Submission from: (NULL) (24.61.19.101) I had encountered a similar problem when changing the font in the R Console and then then open the graphics device by plot(), the console window whites out. this might be related to bug report 7271. I mentioned it sometime back and was told is was not reproducible. Now I have encountered a similar problem that does not appear to relate to the graphics device. I started an R session, changed the font to size 8, Apply/OK. Then I opened a help page by typing ?plot the R help page opened in a different (system?) font and the font in the console also changed to the same bold-face, non-proportional font. Then when I typed another help command, the console completely blanked out. It is almost certainly not blank, just using the wrong foreground colour. There seems to be some strange interaction going on between new windows opened by the system and the font setting in the GUI preferences. Yes, and that is PR#7277. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
