Re: [Rd] Question lattice SplomT
On Mon, Sep 24, 2012 at 9:22 PM, Christian Hoffmann c-w.hoffm...@sunrise.ch wrote: Dear Deepayan Sarkar, I have (again) a question concerning panel and my function SplomT, see attachments. Some time ago you helped me to write this function, thanks again. I have used it to great advantage in my statistics instructions. Now the problem I encounter is that the .pdf figure generated in Sweave consists of one extra empty page at the start. This seems to be due to the get.gpar() call in the SplomT() function -- it produces a new page if it is called before any graphics output is drawn. That's not quite correct: The point is that grid.newpage() does some magic to NOT create a new page if it realizes that it is being called with a fresh device with nothing drawn on it yet. Calling get.gpar() is enough to make that magic fail, so the grid.newpage() call inside print.trellis() is actually creating a new page. Your options are: (1) get rid of the get.gpar()$cex call (can it be anything other than 1 on a new device?), or (2) call print(splom(...), newpage=FALSE) -Deepayan This prevents it from showing up in the final .pdf document. I am not sure whether this has any thing to do with Sweave. (If the statement is executed on the command line, the plot in the Quartz window looks allright.) Since I have no full version of Adobe Acrobat I cannot eliminate the empty first page. I tried to fiddle around with the panel functions, but was not table to mimic my function. Thanks for your attention and for looking at my problem. Christian Hoffmann PS: for *r-devel*: Could this be an Sweave problem? Files attached: SplomT.Rnw : File containing the Functiond and an example, SplomT.tex : Result from Sweave of .Rnw, SplomT.pdf : Result from TeXing the .tex, Fig_A.pdf: Resulting figure from Sweave SplomT.png : Screenshot of Fig_A.pdf sessionInfo() R version 2.15.1 (2012-06-22) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C attached base packages: [1] tools tcltk stats4splines parallel datasets compiler [8] graphics grDevices stats grid utils methods base other attached packages: [1] survival_2.36-14 spatial_7.3-3 rpart_3.1-53 nnet_7.3-1 [5] nlme_3.1-104 mgcv_1.7-18 foreign_0.8-50 codetools_0.2-8 [9] cluster_1.14.2class_7.3-3 boot_1.3-4 Matrix_1.0-6 [13] MASS_7.3-18 KernSmooth_2.23-7 cwhmisc_3.0 lattice_0.20-6 -- Christian W. Hoffmann, CH - 8915 Hausen am Albis, Switzerland Rigiblickstrasse 15 b, Tel.+41-44-7640853 c-w.hoffm...@sunrise.ch, christ...@echoffmann.ch, www.echoffmann.ch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] license
R-devel now gives a warning for a non-standard license (this may have happened for a while). In Rgraphviz we include the Graphviz source code, which is under Eclipse. But the rest of the R package is under Artistic-2.0 or at least contains code from past contributors which were licensed under Artistic-2.0. The standard licenses does not really give an option for this situation, apart from using 'file LICENSE' (with details on this). However, this situation - including an external piece of software - seems to me to be increasingly common. It may be worthwhile to have the possibility of specifying this in a more machine readable way. But it may also be too complicated. I just wanted to bring attention to the issue. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] license
On 24.09.2012 19:30, Kasper Daniel Hansen wrote: R-devel now gives a warning for a non-standard license (this may have happened for a while). Yes, for several years now. In Rgraphviz we include the Graphviz source code, which is under Eclipse. But the rest of the R package is under Artistic-2.0 or at least contains code from past contributors which were licensed under Artistic-2.0. If it is possible to mix these two at all (I do not know the details)... The standard licenses does not really give an option for this situation, apart from using 'file LICENSE' (with details on this). Yes, that's why it has been introduced: Describing non trivial license situations. Best, Uwe Ligges However, this situation - including an external piece of software - seems to me to be increasingly common. It may be worthwhile to have the possibility of specifying this in a more machine readable way. But it may also be too complicated. I just wanted to bring attention to the issue. Kasper __ 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] Segmentation fault when options(max.print = .Machine$integer.max)
Seemed like a good idea at the time, but options(max.print = .Machine$integer.max) 1:10 [1] Program received signal SIGSEGV, Segmentation fault. because of an integer overflow at src/main/printvector.c:176 sessionInfo() R Under development (unstable) (2012-09-24 r60800) Platform: x86_64-unknown-linux-gnu (64-bit) ... also R-patched, etc. Martin -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error on uneven recycling?
Is there some reason why (1:2)+(1:3) [1] 2 4 4 Warning message: In (1:2) + (1:3) : longer object length is not a multiple of shorter object length can't be made into an error? I realise it was there in S-PLUS, but since it produces a warning there can't be many examples on CRAN or Bioconductor using it, and I can't think of any situation where it would be used deliberately. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error on uneven recycling?
That is an error in Splus 8.3. It must have changed quite a while ago - it was an error in Splus 5.1, released in 1999 and I don't have an older version handy right now. Current behavior is 1:10 + 0:1 [1] 1 3 3 5 5 7 7 9 9 11 1:10 + 0:2 Problem in 1:10 + 0:2: length of longer operand (10) should be a multiple of length of shorter (3) Use traceback() to see the call stack I vaguley recall running into some problems when we made the change, but I think it was only in our internal test suite, using a trick like the above to produce a patterned sequence. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Thomas Lumley Sent: Monday, September 24, 2012 7:45 PM To: R-devel Subject: [Rd] error on uneven recycling? Is there some reason why (1:2)+(1:3) [1] 2 4 4 Warning message: In (1:2) + (1:3) : longer object length is not a multiple of shorter object length can't be made into an error? I realise it was there in S-PLUS, but since it produces a warning there can't be many examples on CRAN or Bioconductor using it, and I can't think of any situation where it would be used deliberately. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ 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
