Re: [Rd] Graphics driver test script?
On 2/11/07, Geoff Russell <[EMAIL PROTECTED]> wrote: > Hi, > > 1. I started work on a metapost graphics driver a week or so ago and it is > gradually taking shape. I'm building up my own test cases into a > script as I go, but > figured you may have a "canonical testing script" of cases a driver must > handle? > I typically use demo(graphics) for initial development and then things like example(plotmath) to make sure I'm getting font encoding working properly. > 2. The clipping function looks like being a tricky problem. It seems > to me that the > callers of the driver assume that clipping affects all following calls > until the next > clipping call resets the clipping box. With metapost, the clipping > function clips the > current graphics region and has no effect on following drawing functions. I'm > not sure how to handle this --- the 2 models are very different. > Sounds like you get to make a lot of clipping calls in metapost. > Cheers, > Geoff Russell > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphics driver test script?
On Mon, 12 Feb 2007, Byron Ellis wrote: > On 2/11/07, Geoff Russell <[EMAIL PROTECTED]> wrote: >> Hi, >> >> 1. I started work on a metapost graphics driver a week or so ago and it is >> gradually taking shape. I'm building up my own test cases into a >> script as I go, but >> figured you may have a "canonical testing script" of cases a driver must >> handle? >> > > I typically use demo(graphics) for initial development and then things > like example(plotmath) to make sure I'm getting font encoding working > properly. > >> 2. The clipping function looks like being a tricky problem. It seems >> to me that the >> callers of the driver assume that clipping affects all following calls >> until the next >> clipping call resets the clipping box. With metapost, the clipping >> function clips the >> current graphics region and has no effect on following drawing functions. >> I'm >> not sure how to handle this --- the 2 models are very different. >> > > Sounds like you get to make a lot of clipping calls in metapost. Or ask R to do the clipping. The structure for a graphics device includes Rboolean canClip; /* Hardware clipping */ R's clipping is not as sophisticated as is possible in some devices (e.g. it does not take line widths and joins into account AFAIR), but it is used by the XFig device, for example. -- 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xlsReadWrite Pro and embedding objects and files in Excel worksheets
Hi Mark, > I would like to be able to use a single Excel spreadsheet as an archive > for any output I generate in a single R session, including pdf files of > graphics and possibly the R history or even the R workspace itself. What we do is: - assemble all generated files (xls/png/txt) in a specific *folder* - the pictures currently end in zip files - Excel currently only holds the data (no images etc.) - we don't save any workspace or .Rdata. Each calculation starts from scratch (sometimes with cached data, but this is transparent) - we have some packages with the most important/stable source code - other code we source each time before a calculation - all code is in a subversion repository and therefore has it's full history. This works very nice for us. It was not so easy, i.e. we needed some time to find a lean and flexible setup. R still feels difficult for me. > sure that it can be done with VB. I am unsure, however, exactly how you > are generating the Excel files. For my own edification, are you using VB > or something similar? I use Delphi (Object Pascal). The hardwork is done by a 3rd party library which I bought (Flexcel/tmssoftware.com). You can download the source of the free xlsReadWrite to see how it was done. (To compile you would have to buy the flexcel library which - unfortunately - is not open source and I am not allowed to distribute it.) > Also, to make this not so Windows specific, would these files be > compatible with openOffice or some other open-source spreadsheet program > that would be compatible with the other OS's that R users employ? That > might make it more broadly appealing. No, its pure Excel format. - IIRC there is a ODF Toolkit Project which could be used to generate the files (maybe odfSweave does this already?). The ODF Toolkit Project is certainly appealing, not least because of the license situation. > I would also be interested in feedback from other developers as to what > they think of my general idea. Is it worth pursuing? Would it be worthy > of a simple package? About (small) original data, methods, parameters and matrix output I agree. Not so sure about graphs. I prefere to keep things separated. You can do this already today by controlling Excel from R (see tipps from Gabor) or (in part) with xlsReadWritePro. -- Regards, Hans-Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] append within worksheet in write.xls
Hi, 2007/2/9, Mark W Kimpel <[EMAIL PROTECTED]>: > I can currently append an entire worksheet with write.xls, but would > also like to be able to append within the same worksheet. Is this > possible? Of course. Please see ?xls.open, ?xls.sheet and ?write.xls (note the 'keep' argument!). I give you a short example at the end of the email. >It doesn't seem to work if I use append = T I am not aware of an issue. Please post (better email) your code. BTW the 'append' argument is only meant for single operations (the whole sheet will be re-read and rewritten each time). A last thing, such specific xlsReadWrite(Pro) questions are not very on topic for the the r-devel list. I don't know for sure, but I strongly suspect that this is not be appreciated here. It is probably better you just email me. Cheers, Hans-Peter (the example is with read, but write is analogue) rfile <- "TestReadDataFile.xls" cat( "### TEST: xls.open and xls.close\n" ) exc <- xls.open( rfile ) res1 <- read.xls( exc,, 1, from = 3, cols = 1 )[[1]] # switch to character sheet, check and read xls.sheet( exc, "select", "characterSheet" ) # switch to logical sheet, check and read xls.sheet( exc, "select", "logicalSheet" ) res1 <- read.xls( exc, type = "logical", from = 3, cols = 1 ) xls.close( exc ) cat( "### TEST: keep\n" ) # read first column from first sheet res1 <- read.xls( rfile,, 1, from = 3, cols = 1, keep = TRUE )[[1]] # switch to character sheet, check and read xls.sheet( rfile, "select", "characterSheet", keep = TRUE ) # switch to logical sheet, check and read xls.sheet( , "select", "logicalSheet", keep = TRUE ) # with the next command the file will be closed (without saving) res1 <- read.xls( , type = "logical", from = 3, cols = 1, keep = FALSE ) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] newline with cell of Excel worksheet created with write.xls
Hi Mark, You need a character vector or a data.frame for separate rows. Something like: longtext <- 'akdf kadfö \nkad flkdöflkadfk dafk \nlakdf kdjfkjdfkjadfk\njadfkjdflk adf' (rowtext <- as.data.frame( strsplit( longtext, split = "\n" )) ) may do this. Regards, Hans-Peter PS: Probably not so appropriate for the R-devel list either... 2007/2/9, Mark W Kimpel <[EMAIL PROTECTED]>: > As part of my project to put different types of results into worksheets, > I would like to be able to put an auto-generated methods section. If I > compose in RWinEdt, read into R, and use write.table with a .txt file > extension, what I get out has line-breaks that correspond to those I put > in in the first place. > > If I do the same thing but write.xls with .xls extention, I get an Excel > worksheet with the entire paragraph on one line (row). It seems to me > that Excel uses a special character for new-lines (new-rows). Is there a > way that write.xls could convert \n to this special character? > > I'm writing lots of posts on this, but trying to break up the subjects > to create better threads. > > Mark > > -- > Mark W. Kimpel MD > Neuroinformatics > Department of Psychiatry > Indiana University School of Medicine > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] newline with cell of Excel worksheet created with write.xls
Hans-Peter, I agree, I wasn't sure whether to put this stuff on-list or not. I have seen some people request that things NOT be taken of list because then the answers are not available to everybody. Let's solve some of these issues ourselves (I am willing to help) and, if appropriate, repost the solutions or additional functionality to the list. Mark Hans-Peter wrote: > Hi Mark, > > You need a character vector or a data.frame for separate rows. Something > like: > > longtext <- 'akdf kadfö \nkad flkdöflkadfk dafk \nlakdf > kdjfkjdfkjadfk\njadfkjdflk adf' > (rowtext <- as.data.frame( strsplit( longtext, split = "\n" )) ) > > may do this. > > Regards, > Hans-Peter > > > PS: Probably not so appropriate for the R-devel list either... > > > 2007/2/9, Mark W Kimpel <[EMAIL PROTECTED]>: >> As part of my project to put different types of results into worksheets, >> I would like to be able to put an auto-generated methods section. If I >> compose in RWinEdt, read into R, and use write.table with a .txt file >> extension, what I get out has line-breaks that correspond to those I put >> in in the first place. >> >> If I do the same thing but write.xls with .xls extention, I get an Excel >> worksheet with the entire paragraph on one line (row). It seems to me >> that Excel uses a special character for new-lines (new-rows). Is there a >> way that write.xls could convert \n to this special character? >> >> I'm writing lots of posts on this, but trying to break up the subjects >> to create better threads. >> >> Mark >> >> -- >> Mark W. Kimpel MD >> Neuroinformatics >> Department of Psychiatry >> Indiana University School of Medicine >> > -- Mark W. Kimpel MD Neuroinformatics Department of Psychiatry Indiana University School of Medicine __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package build Vignette creation errors
When I try to build my package I get latex errors even though i run the same steps (using another latex creation program - latex, and then dvipdf) independently of the R CMD build without fail. Also, R CMD check finishes without error. * creating vignettes ... ERROR /usr/lib/R/bin/texi2dvi: pdflatex exited with bad status, quitting. /usr/lib/R/bin/texi2dvi: see SuoPS1.log for errors. Error in texi2dvi(file = bft, pdf = TRUE, clean = FALSE, quiet = quiet) : running texi2dvi on 'SuoPS1.tex' failed Execution halted Running texi2pdf --pdf gives me more details: Error: pdflatex (file SuoPS1-002.pdf): pdf inclusion: required page does not ex ist <0> ==> Fatal error occurred, the output PDF file is not finished! Any help would be much appreciated. Thanks! Daniel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphics driver test script?
Hi Byron Ellis wrote: > On 2/11/07, Geoff Russell <[EMAIL PROTECTED]> wrote: >> Hi, >> >> 1. I started work on a metapost graphics driver a week or so ago and it is >> gradually taking shape. I'm building up my own test cases into a >> script as I go, but >> figured you may have a "canonical testing script" of cases a driver must >> handle? >> > > I typically use demo(graphics) for initial development and then things > like example(plotmath) to make sure I'm getting font encoding working > properly. > >> 2. The clipping function looks like being a tricky problem. It seems >> to me that the >> callers of the driver assume that clipping affects all following calls >> until the next >> clipping call resets the clipping box. With metapost, the clipping >> function clips the >> current graphics region and has no effect on following drawing functions. >> I'm >> not sure how to handle this --- the 2 models are very different. >> > > Sounds like you get to make a lot of clipping calls in metapost. Yes, it may not be the most efficient approach, but one method would be to keep track of the R's latest clipping region within your device structure (just update it whenever R asks your device to set the clip region, i.e., in MetaPost_Clip()) and enforce the current clip region for each drawing call. Paul >> Cheers, >> Geoff Russell >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in partial matching of attribute names
There looks to be a bug in do_attr() (src/main/attrib.c): incorrect
partial matches of attribute names can be returned when there are an odd
number of partial matches.
E.g.:
> x <- c(a=1,b=2)
> attr(x, "abcdef") <- 99
> attr(x, "ab")
[1] 99
> attr(x, "abc") <- 100
> attr(x, "ab") # correctly returns NULL because of ambig partial match
NULL
> attr(x, "abcd") <- 101
> attr(x, "ab") # incorrectly returns non-NULL for ambig partial match
[1] 101
> names(attributes(x))
[1] "names" "abcdef" "abc""abcd"
>
The problem in do_attr() looks to be that after match is set to
PARTIAL2, it can be set back to PARTIAL again. I think a simple fix is
to add a "break" in this block in do_attr():
else if (match == PARTIAL) {
/* this match is partial and we already have a partial match,
so the query is ambiguous and we return R_NilValue */
match = PARTIAL2;
break; /* < ADD BREAK HERE */
} else {
However, if this is indeed a bug, would this be a good opportunity to
get rid of partial matching on attribute names -- it was broken anyway
-- so toss it out? :-) Does anyone depend on partial matching for
attribute names? My view is that it's one of those things like partial
matching of list and vector element names that seemed like a good idea
at first, but turns out to be more trouble than it's worth.
On a related topic, partial matching does not seem to work for the
"names" attribute (which I would regard as a good thing :-). However,
I'm puzzled why it doesn't work, because the code in do_attr() seems to
try hard to make it work. Can anybody explain why?
E.g.:
> attr(x, "names")
[1] "a" "b"
> attr(x, "nam")
NULL
> sessionInfo()
R version 2.4.1 (2006-12-18)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
[7] "base"
>
-- Tony Plate
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphics driver test script?
On 2/13/07, Paul Murrell <[EMAIL PROTECTED]> wrote: > Hi > > > Byron Ellis wrote: > > On 2/11/07, Geoff Russell <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> 1. I started work on a metapost graphics driver a week or so ago and it is > >> gradually taking shape. I'm building up my own test cases into a > >> script as I go, but > >> figured you may have a "canonical testing script" of cases a driver must > >> handle? > >> > > > > I typically use demo(graphics) for initial development and then things > > like example(plotmath) to make sure I'm getting font encoding working > > properly. > > > >> 2. The clipping function looks like being a tricky problem. It seems > >> to me that the > >> callers of the driver assume that clipping affects all following calls > >> until the next > >> clipping call resets the clipping box. With metapost, the clipping > >> function clips the > >> current graphics region and has no effect on following drawing functions. > >> I'm > >> not sure how to handle this --- the 2 models are very different. > >> > > > > Sounds like you get to make a lot of clipping calls in metapost. > > > Yes, it may not be the most efficient approach, but one method would be > to keep track of the R's latest clipping region within your device > structure (just update it whenever R asks your device to set the clip > region, i.e., in MetaPost_Clip()) and enforce the current clip region > for each drawing call. Yes, I can draw to a temp picture, then clip to the current clip region and then add the temp picture to the current picture. Easy to do, but ugly. I'll also checkout R clipping - thanks. Cheers, Geoff > > Paul > > > >> Cheers, > >> Geoff Russell > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > [EMAIL PROTECTED] > http://www.stat.auckland.ac.nz/~paul/ > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
