[Rd] Severe memory problem using split()
Dear all,
With great interest I followed the discussion:
https://stat.ethz.ch/pipermail/r-devel/2010-July/057901.html
since I have currently a similar problem:
In a new R session (using xterm) I am importing a simple table
"Hu6800_ann.txt" which has a size of 754KB only:
> ann <- read.delim("Hu6800_ann.txt")
> dim(ann)
[1] 7129 11
When I call "object.size(ann)" the estimated memory used to store "ann"
is already 2MB:
> object.size(ann)
2034784 bytes
Now I call "split()" and check the estimated memory used which turns out
to be 3.3GB:
> u2p <- split(ann[,"ProbesetID"],ann[,"UNIT_ID"])
> object.size(u2p)
3323768120 bytes
During the R session I am running "top" in another xterm and can see
that the memory usage of R increases to about 550MB RSIZE.
Now I do:
> object.size(unlist(u2p))
894056 bytes
It takes about 3 minutes to complete this call and the memory usage of R
increases to about 1.3GB RSIZE. Furthermore, during evaluation of this
function the free RAM of my Mac decreases to less than 8MB free PhysMem,
until it needs to swap memory. When finished, free PhysMem is 734MB but
the size of R increased to 577MB RSIZE.
Doing "split(ann[,"ProbesetID"],ann[,"UNIT_ID"],drop=TRUE)" did not
change the object.size, only processing was faster and it did use less
memory on my Mac.
Do you have any idea what the reason for this behavior is?
Why is the size of list "u2p" so large?
Do I make any mistake?
Here is my sessionInfo on a MacBook Pro with 2GB RAM:
> sessionInfo()
R version 2.11.1 (2010-05-31)
x86_64-apple-darwin9.8.0
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Severe memory problem using split()
Dear Martin,
Thank you, you are right, now I get:
> ann <- read.delim("Hu6800_ann.txt", stringsAsFactors=FALSE)
> object.size(ann)
2035952 bytes
> u2p <- split(ann[,"ProbesetID"],ann[,"UNIT_ID"])
> object.size(u2p)
1207368 bytes
> object.size(unlist(u2p))
865176 bytes
Nevertheless, a size of 1.2MB for a list representing 2 of 11 columns of
a table of size 754KB seems still to be pretty large?
Best regards
Christian
On 7/12/10 11:44 PM, Martin Morgan wrote:
On 07/12/2010 01:45 PM, cstrato wrote:
Dear all,
With great interest I followed the discussion:
https://stat.ethz.ch/pipermail/r-devel/2010-July/057901.html
since I have currently a similar problem:
In a new R session (using xterm) I am importing a simple table
"Hu6800_ann.txt" which has a size of 754KB only:
ann<- read.delim("Hu6800_ann.txt")
dim(ann)
[1] 7129 11
When I call "object.size(ann)" the estimated memory used to store "ann"
is already 2MB:
object.size(ann)
2034784 bytes
Now I call "split()" and check the estimated memory used which turns out
to be 3.3GB:
u2p<- split(ann[,"ProbesetID"],ann[,"UNIT_ID"])
object.size(u2p)
3323768120 bytes
I guess things improve with stringsAsFactors=FALSE in read.delim?
Martin
During the R session I am running "top" in another xterm and can see
that the memory usage of R increases to about 550MB RSIZE.
Now I do:
object.size(unlist(u2p))
894056 bytes
It takes about 3 minutes to complete this call and the memory usage of R
increases to about 1.3GB RSIZE. Furthermore, during evaluation of this
function the free RAM of my Mac decreases to less than 8MB free PhysMem,
until it needs to swap memory. When finished, free PhysMem is 734MB but
the size of R increased to 577MB RSIZE.
Doing "split(ann[,"ProbesetID"],ann[,"UNIT_ID"],drop=TRUE)" did not
change the object.size, only processing was faster and it did use less
memory on my Mac.
Do you have any idea what the reason for this behavior is?
Why is the size of list "u2p" so large?
Do I make any mistake?
Here is my sessionInfo on a MacBook Pro with 2GB RAM:
sessionInfo()
R version 2.11.1 (2010-05-31)
x86_64-apple-darwin9.8.0
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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] Severe memory problem using split()
Dear Martin,
Thank you for this explanation.
Best regards
Christian
On 7/13/10 12:31 AM, Martin Morgan wrote:
On 07/12/2010 03:00 PM, cstrato wrote:
Dear Martin,
Thank you, you are right, now I get:
ann<- read.delim("Hu6800_ann.txt", stringsAsFactors=FALSE)
object.size(ann)
2035952 bytes
u2p<- split(ann[,"ProbesetID"],ann[,"UNIT_ID"])
object.size(u2p)
1207368 bytes
object.size(unlist(u2p))
865176 bytes
Nevertheless, a size of 1.2MB for a list representing 2 of 11 columns of
but it's a list of length(unique(ann[["UNIT_ID"]]))) elements, each of
which has a pointer to the element, a pointer to the name of the
element, and the element data itself. I'd guess it adds up in a
non-mysterious way. For a sense of it (and maybe only understandable if
you have a working understanding of how R represents data) see, e.g.,
.Internal(inspect(list(x=1,y=2)))
@1a4c538 19 VECSXP g0c2 [ATT] (len=2, tl=0)
@191cad8 14 REALSXP g0c1 [] (len=1, tl=0) 1
@191caa8 14 REALSXP g0c1 [] (len=1, tl=0) 2
ATTRIB:
@16fc8d8 02 LISTSXP g0c0 []
TAG: @60cf18 01 SYMSXP g0c0 [MARK,NAM(2),gp=0x4000] "names"
@1a4c500 16 STRSXP g0c2 [] (len=2, tl=0)
@674e88 09 CHARSXP g0c1 [MARK,gp=0x21] "x"
@728c38 09 CHARSXP g0c1 [MARK,gp=0x21] "y"
Martin
a table of size 754KB seems still to be pretty large?
Best regards
Christian
On 7/12/10 11:44 PM, Martin Morgan wrote:
On 07/12/2010 01:45 PM, cstrato wrote:
Dear all,
With great interest I followed the discussion:
https://stat.ethz.ch/pipermail/r-devel/2010-July/057901.html
since I have currently a similar problem:
In a new R session (using xterm) I am importing a simple table
"Hu6800_ann.txt" which has a size of 754KB only:
ann<- read.delim("Hu6800_ann.txt")
dim(ann)
[1] 7129 11
When I call "object.size(ann)" the estimated memory used to store "ann"
is already 2MB:
object.size(ann)
2034784 bytes
Now I call "split()" and check the estimated memory used which turns out
to be 3.3GB:
u2p<- split(ann[,"ProbesetID"],ann[,"UNIT_ID"])
object.size(u2p)
3323768120 bytes
I guess things improve with stringsAsFactors=FALSE in read.delim?
Martin
During the R session I am running "top" in another xterm and can see
that the memory usage of R increases to about 550MB RSIZE.
Now I do:
object.size(unlist(u2p))
894056 bytes
It takes about 3 minutes to complete this call and the memory usage of R
increases to about 1.3GB RSIZE. Furthermore, during evaluation of this
function the free RAM of my Mac decreases to less than 8MB free PhysMem,
until it needs to swap memory. When finished, free PhysMem is 734MB but
the size of R increased to 577MB RSIZE.
Doing "split(ann[,"ProbesetID"],ann[,"UNIT_ID"],drop=TRUE)" did not
change the object.size, only processing was faster and it did use less
memory on my Mac.
Do you have any idea what the reason for this behavior is?
Why is the size of list "u2p" so large?
Do I make any mistake?
Here is my sessionInfo on a MacBook Pro with 2GB RAM:
sessionInfo()
R version 2.11.1 (2010-05-31)
x86_64-apple-darwin9.8.0
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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] Problem with WARNING...headers with CRLF line endings
Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: "* checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h" The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liverpool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liverpool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Bill, It would be great if this warning message could at least be suppressed on Windows. Best regards Christian On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: "* checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h" The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Problem with WARNING...headers with CRLF line endings
Dear Dirk, Thank you for this suggestion, however I have no idea where this code could be used. As I have said, this file is created automatically during the compilation by the compiler, and I have no idea at which point "R CMD check" does check for CRLF line endings, and how to interfere with this step. Do you have any ideas? Best regards Christian On 9/13/10 11:31 PM, Dirk Eddelbuettel wrote: On 13 September 2010 at 23:07, cstrato wrote: | Dear all, | | When running R CMD check on Windows XP to test my package I get the | following warning message: | | "* checking line endings in C/C++/Fortran sources/headers ... WARNING | Found the following sources/headers with CR or CRLF line endings: |src/xpsDict.h" | | The problem is that this file is created by the compiler AUTOMATICALLY | during the compilation process, and since the file is created by VC++ on | WinXP, it will always have CRLF line endings. | | Thus my question is: | - Is it really necessary to issues this warning message? | - If yes, could it be suppressed on Windows XP, since there it should | obviously be no problem. | | One more issue: | While I have always received this warning on my WinXP installation, for | some lucky reason the warning did until now not appear on the | Bioconductor Windows server, see BioC 2.6 with R-2.11.1: | http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liverpool-checksrc.html | | However, for some reason on BioC 2.7 running R-2.12.0 this warning does | appear, see: | http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liverpool-checksrc.html | For this reason I would appreciate if there would be a possibility to | suppress this warning message. I once had the warning to in project and just added another filtering step using this ## simple 0d 0a -> 0a converter to suppress a warning on Windows filename<- commandArgs(trailingOnly=TRUE)[1] if (!file.exists(filename)) q() con<- file(filename, "rb") bin<- readBin(con, raw(), 10) bin<- bin[ which(bin != "0d") ] close(con) Sys.sleep(1) con<- file(filename, "wb") writeBin(bin, con) close(con) Maybe you can use something like this and have the generated file transformed. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with "If the file is created automatically then it has no business being in the package."? If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code "xps_1.9.6.tar.gz" has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: "* checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h" The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of "xps_1.9.6.tar.gz" increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? Best regards Christian On 9/14/10 11:32 PM, Hervé Pagès wrote: Hi Christian, On 09/14/2010 02:12 PM, cstrato wrote: Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with "If the file is created automatically then it has no business being in the package."? He means it shouldn't be in the source tarball. We run 'R CMD check' on source trees or source tarballs. Source tarballs are platform independent. If I understand correctly when you run 'R CMD build' on your source tree, you use some trick to generate this src/xpsDict.h file on Windows and this file ends up in the source tarball. But the source tarball created on Linux won't have this file. That doesn't sound like a good thing to me to have the content of the source tarball depending on the machine you've run 'R CMD build'. In other words, you should try to generate this src/xpsDict.h file at installation time but it shouldn't end up in the source tarball. My 2 cents... Cheers, H. If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code "xps_1.9.6.tar.gz" has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: "* checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h" The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this w
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Duncan, dear Herve, Thank you both for your help and suggestions. I think that you are both right: In principle I do not want to put these files in the source tarball (and I did not in the past), however because of the way R CMD check works this seems to be the only possibility to get rid of the warning message. I agree that it is weird to get this warning message although these files are not in the source tarball. Since I have a Makefile, as Herve mentions, I can try to remove these files in the clean step, which currently is: clean: rm -f $(MYOBJ) *.a *.d *.rc I will try to change this part but I am not sure if this will solve the problem. Best regards Christian On 9/15/10 1:58 AM, Hervé Pagès wrote: On 09/14/2010 03:30 PM, Duncan Murdoch wrote: On 14/09/2010 6:08 PM, Hervé Pagès wrote: On 09/14/2010 02:58 PM, cstrato wrote: Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. on every architecture... ok But if they are created during compilation, why do they need to be included in the source tarball? They are just temporary files right? Or I'm missing something... This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. I guess you mean they are not part of the source *tree*. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of "xps_1.9.6.tar.gz" increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? I still don't understand why you want to have them in the source tarball. I think he doesn't want to put them in the source tarball, but because of the way R CMD check works, he may have to. It appears that R CMD check builds those files, and then checks for CRLF endings on all files. If it did the CRLF check first, it wouldn't see them and complain. The problem with this change is that some packages might create files with CRLF endings on all platforms, and then check *should* complain about them. I see your point but, on the other hand, and more generally speaking, you expect 'R CMD check' to check the source files i.e. the files that belong to the source tarball, and not temporary compilation/installation products that 'R CMD INSTALL' didn't remove (for whatever reason). It's weird to get a message like: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h if there is no such file in the source tarball. My advice would be not to put them in the tarball, and ignore the warning. Or write a Makevars.win that fixes the line endings so that check is happy. Yes and since he already uses a Makefile, it should be easy to remove those files at the end of installation so they don't end up in the tarball anymore. Wouldn't that also be enough to silent 'R CMD check'? Perhaps package authors should really make sure that src/ gets cleaned after the installation step of 'R CMD build' (this step is performed only if the package has vignettes). Then it shouldn't matter whether 'R CMD check' checks for CRLF endings after or before installing the package. Cheers, H. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Dirk,
Thank you for this suggestion, however since I am not very good in
creating Makefiles I would appreciate if you could explain how to filter
at the compile stage.
These are the lines which I think are essential:
xps.dll: $(MYOBJ)
$(LINK) /dll /def:xps.def /out:xps.dll fp10.obj $(SOFLAGS) $(LDFLAGS)
$(GLIBS) *.obj
xpsDict.cxx: $(MYHDR) xpsLinkDef.h
@echo "Generating dictionary $...@..."
@rootcint -f $@ -c $(MYHDR) xpsLinkDef.h
xpsDict.obj: xpsDict.cxx xpsDict.h
$(CL) /I"${ROOTSYS}/include" /FIw32pragma.h /MT /EHsc /Ox /D "MSVC" /D
"WIN32" /c xpsDict.cxx
clean:
rm -f $(MYOBJ) *.a *.d *.rc
The line @rootcint creates the xpsLinkDef.h file.
Do I have to add something after the compilation step of xpsDict.obj?
Thank you in advance.
Best regards
Christian
On 9/15/10 10:51 PM, Dirk Eddelbuettel wrote:
On 15 September 2010 at 22:39, cstrato wrote:
| Dear Duncan, dear Herve,
|
| Thank you both for your help and suggestions. I think that you are both
| right:
|
| In principle I do not want to put these files in the source tarball (and
| I did not in the past), however because of the way R CMD check works
| this seems to be the only possibility to get rid of the warning message.
|
| I agree that it is weird to get this warning message although these
| files are not in the source tarball.
|
| Since I have a Makefile, as Herve mentions, I can try to remove these
If you have a Makefile, then you have implicit rules as well as explicit
ones. That is how the file gets created.
Now modify the rules and insert another layer which will do the filtering. As
the saying goes: "there is no problem that cannot be solved by adding
another layer of indirection". Instead of requiring the generated file,
require the generated and filtered file.
| files in the clean step, which currently is:
|
| clean:
| rm -f $(MYOBJ) *.a *.d *.rc
|
| I will try to change this part but I am not sure if this will solve the
| problem.
I fear that the clean step runs too late. You want the file filtered at the
compile stage.
Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Herve, I have just tested the modification of Makefile.win: clean: rm -f $(MYOBJ) *.a *.d *.rc xpsLinkDef.h and it was sufficient to eliminate the warning message. Thus R CMD check seems indeed to run the clean step. I have just uploaded the new version to BioC2.7. Best regards Christian On 9/15/10 11:53 PM, Hervé Pagès wrote: On 09/15/2010 01:51 PM, Dirk Eddelbuettel wrote: On 15 September 2010 at 22:39, cstrato wrote: | Dear Duncan, dear Herve, | | Thank you both for your help and suggestions. I think that you are both | right: | | In principle I do not want to put these files in the source tarball (and | I did not in the past), however because of the way R CMD check works | this seems to be the only possibility to get rid of the warning message. | | I agree that it is weird to get this warning message although these | files are not in the source tarball. | | Since I have a Makefile, as Herve mentions, I can try to remove these If you have a Makefile, then you have implicit rules as well as explicit ones. That is how the file gets created. Now modify the rules and insert another layer which will do the filtering. As the saying goes: "there is no problem that cannot be solved by adding another layer of indirection". Instead of requiring the generated file, require the generated and filtered file. | files in the clean step, which currently is: | | clean: | rm -f $(MYOBJ) *.a *.d *.rc | | I will try to change this part but I am not sure if this will solve the | problem. I fear that the clean step runs too late. But shouldn't 'R CMD check' run the clean step (if it runs it at all) right after the 'R CMD INSTALL' step? Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] WARNING Undocumented S4 methods 'initialize' - why?
Dear all,
I am just writing the documentation file for S4 class 'QualTreeSet' and
get the following warning with R CMD check:
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
generic 'initialize' and siglist 'QualTreeSet'
All user-level objects in a package (including S4 classes and methods)
should have documentation entries.
See the chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
All my S4 classes have a method 'initialize' and R CMD check has never
complained. Thus, do you have any idea why I get suddenly this warning
for method 'initialize'?
Here is the code for 'QualTreeSet':
setClass("QualTreeSet",
representation(qualtype = "character",
qualopt = "character"
),
contains=c("ProcesSet"),
prototype(qualtype = "rlm",
qualopt = "raw"
)
)#QualTreeSet
setMethod("initialize", "QualTreeSet",
function(.Object,
qualtype = "rlm",
qualopt = "raw",
...)
{
if (qualtype == "") qualtype <- "rlm";
if (qualopt == "") qualopt <- "raw";
.Object <- callNextMethod(.Object,
qualtype = qualtype,
qualopt = qualopt,
...);
.Object@qualtype = qualtype;
.Object@qualopt = qualopt;
.Object;
}
)#initialize
However, here is my code for a similar class 'ExprTreeSet' (which is the
class from where I have copied the code):
setClass("ExprTreeSet",
representation(exprtype = "character",
normtype = "character"
),
contains=c("ProcesSet"),
prototype(exprtype = "none",
normtype = "none"
)
)#ExprTreeSet
setMethod("initialize", "ExprTreeSet",
function(.Object,
exprtype = "none",
normtype = "none",
...)
{
if (exprtype == "") exprtype <- "none";
if (normtype == "") normtype <- "none";
.Object <- callNextMethod(.Object,
exprtype = exprtype,
normtype = normtype,
...);
.Object@exprtype = exprtype;
.Object@normtype = normtype;
.Object;
}
)#initialize
In this case R CMD check does not complain, so why does it in the case
of 'QualTreeSet'?
Here is my:
> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] xps_1.11.4
Thank you in advance
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] WARNING Undocumented S4 methods 'initialize' - why?
Dear all,
Meanwhile I found my mistake.
I forgot to add class QualTreeSet to 'initialize-methods.Rd'.
However, I am not sure if I should make 'initialize' public at all.
Best regards
Christian
On 3/11/11 9:58 PM, cstrato wrote:
Dear all,
I am just writing the documentation file for S4 class 'QualTreeSet' and
get the following warning with R CMD check:
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
generic 'initialize' and siglist 'QualTreeSet'
All user-level objects in a package (including S4 classes and methods)
should have documentation entries.
See the chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
All my S4 classes have a method 'initialize' and R CMD check has never
complained. Thus, do you have any idea why I get suddenly this warning
for method 'initialize'?
Here is the code for 'QualTreeSet':
setClass("QualTreeSet",
representation(qualtype = "character",
qualopt = "character"
),
contains=c("ProcesSet"),
prototype(qualtype = "rlm",
qualopt = "raw"
)
)#QualTreeSet
setMethod("initialize", "QualTreeSet",
function(.Object,
qualtype = "rlm",
qualopt = "raw",
...)
{
if (qualtype == "") qualtype <- "rlm";
if (qualopt == "") qualopt <- "raw";
.Object <- callNextMethod(.Object,
qualtype = qualtype,
qualopt = qualopt,
...);
.Object@qualtype = qualtype;
.Object@qualopt = qualopt;
.Object;
}
)#initialize
However, here is my code for a similar class 'ExprTreeSet' (which is the
class from where I have copied the code):
setClass("ExprTreeSet",
representation(exprtype = "character",
normtype = "character"
),
contains=c("ProcesSet"),
prototype(exprtype = "none",
normtype = "none"
)
)#ExprTreeSet
setMethod("initialize", "ExprTreeSet",
function(.Object,
exprtype = "none",
normtype = "none",
...)
{
if (exprtype == "") exprtype <- "none";
if (normtype == "") normtype <- "none";
.Object <- callNextMethod(.Object,
exprtype = exprtype,
normtype = normtype,
...);
.Object@exprtype = exprtype;
.Object@normtype = normtype;
.Object;
}
)#initialize
In this case R CMD check does not complain, so why does it in the case
of 'QualTreeSet'?
Here is my:
> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] xps_1.11.4
Thank you in advance
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l: cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to create vignette.pdf for R-2.13.0?
Dear all, While R CMD check and R CMD INSTALL have always created the vignettes on R-2.12.1 or any earlier versions of R, I am no longer able to build the vignettes on R-2.13.0. Instead R CMD check gives me the following output: * checking for unstated dependencies in vignettes ... OK * checking package vignettes in 'inst/doc' ... WARNING Package vignette(s) without corresponding PDF: APTvsXPS.Rnw xps.Rnw xpsClasses.Rnw xpsPreprocess.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK * checking PDF version of manual ... OK Does someone know what the reason might be? (R64 CMD check --help says that be default rebuild-vignettes is turned on.) Interestingly, R CMD check still creates the file "xps-manual.pdf". Here is my sessionInfo: > sessionInfo() R version 2.13.0 (2011-04-13) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] xps_1.13.1 loaded via a namespace (and not attached): [1] Biobase_2.12.1Biostrings_2.20.0 IRanges_1.10.0 [4] affy_1.30.0 affyPLM_1.28.5affyio_1.20.0 [7] preprocessCore_1.14.0 Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create vignette.pdf for R-2.13.0?
cel.root/tmpdt_DataTest3_cel_20110424_201301.root can not be opened is not clear to me since "/tmpdt_DataTest3_cel.root/" is definitively NOT a directory. Do you have any ideas? Please note that the vignette "xps.Rnw" did work for the last two years w/o problem. Furthermore, the Bioconductor servers are able to build the vignette, see: http://www.bioconductor.org/packages/release/bioc/html/xps.html Best regards Christian On 4/24/11 4:12 PM, Uwe Ligges wrote: On 23.04.2011 21:50, cstrato wrote: Dear all, While R CMD check and R CMD INSTALL have always created the vignettes on R-2.12.1 or any earlier versions of R, I am no longer able to build the vignettes on R-2.13.0. Instead R CMD check gives me the following output: * checking for unstated dependencies in vignettes ... OK * checking package vignettes in 'inst/doc' ... WARNING Package vignette(s) without corresponding PDF: APTvsXPS.Rnw xps.Rnw xpsClasses.Rnw xpsPreprocess.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK * checking PDF version of manual ... OK Does someone know what the reason might be? No, it does for me for other packages. Perhaps an error when processing the vignettes? Have you tried to build them manually? (R64 CMD check --help says that be default rebuild-vignettes is turned on.) Interestingly, R CMD check still creates the file "xps-manual.pdf". That is the collection of help pages, unrelated to the vignette. Uwe Ligges Here is my sessionInfo: > sessionInfo() R version 2.13.0 (2011-04-13) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] xps_1.13.1 loaded via a namespace (and not attached): [1] Biobase_2.12.1 Biostrings_2.20.0 IRanges_1.10.0 [4] affy_1.30.0 affyPLM_1.28.5 affyio_1.20.0 [7] preprocessCore_1.14.0 Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] How to create vignette.pdf for R-2.13.0?
Dear Uwe,
On 4/24/11 10:37 PM, Uwe Ligges wrote:
On 24.04.2011 20:59, cstrato wrote:
Dear Uwe,
Thank you for your reply.
ad 2, Yes, i know that "xps-manual.pdf" is the collection of help pages,
I have mentioned it only to show that creating pdf-files does work for
R-2.13.0.
ad 1, Could it be that this is a Mac-specific problem since I see it on
both my old MacBook Pro and my new Mac Mini.
Have you tried on any other OS? I did not since installing root is a bit
too much effort.
No, until now I did not try another OS, but I will, since xps has to
work on all three OSes.
Using R CMD check with R-2.12.2 I get:
I thought we are talking about R-2.13.0?
I showed you the output of R-2.12.2 first and then the output of
R-2.13.0, so that you can see that on the same machine with the same
file it works with one version but not the other.
Where is the R CMD build output (since R CMD build is supposed to
prepare the vignette).
$ R64 CMD check xps_1.13.1.tar.gz
* using log directory '/Volumes/CoreData/CRAN/xps.Rcheck'
* using R version 2.12.2 (2011-02-25)
* using platform: x86_64-apple-darwin9.8.0 (64-bit)
* using session charset: ASCII
* checking for file 'xps/DESCRIPTION' ... OK
* this is package 'xps' version '1.13.1'
...
...
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
* checking PDF version of manual ... OK
Using "RSwitch.app" I switch to R-2.13.0, but now I get:
$ R64 CMD check xps_1.13.1.tar.gz
* using log directory '/Volumes/CoreData/CRAN/xps.Rcheck'
* using R version 2.13.0 (2011-04-13)
* using platform: x86_64-apple-darwin9.8.0 (64-bit)
* using session charset: ASCII
* checking for file 'xps/DESCRIPTION' ... OK
* this is package 'xps' version '1.13.1'
...
...
* checking package vignettes in 'inst/doc' ... WARNING
Package vignette(s) without corresponding PDF:
APTvsXPS.Rnw
xps.Rnw
xpsClasses.Rnw
xpsPreprocess.Rnw
* checking running R code from vignettes ... OK
* checking re-building of vignettes ... OK
* checking PDF version of manual ... OK
I must admit that I have never built the vignettes manually, and I
cannot find a hint how I can do it from the command line. Is this
possible?
Is it possible to build the vignettes from the command line?
However, building the vignettes within R-2.13.0 I get:
> library(tools)
> buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
Overfull \vbox (21.68121pt too high) has occurred while \output is
Writing to file xps.tex
Processing code chunks with options ...
1 : term verbatim
2 : echo term hide
3 : echo term verbatim
4 : echo term verbatim
5 : echo term verbatim
SysError in : file
/tmpdt_DataTest3_cel.root/tmpdt_DataTest3_cel_20110424_201301.root can
not be opened (No such file or directory)
Error: Could not create file
Here are the two important chunks 4 and 5, which work fine with R-2.12.2
and earlier versions:
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3 <- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, in R-2.13.0 chunk 5 crashes!!!
It works only when replacing chunk 5 with:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles <- c("TestA1.CEL","TestA2.CEL")
scheme.test3 <- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
As you see R-2.13.0 does no longer remember the result of chunk 4, i.e.
"scheme.test3". Now I have to include the line defining "scheme.test3"
also in chunk 5.
How objects generated in one chunk can be reused later on is explained
in the Sweave manual.
Do you have any idea for this behavior?
An example, which does work in R-2.13.0 are the following two chunks:
#
### chunk number 20:
##
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code from the
chunk before but not from an earlier chunk.
Concretely, the following does not work since chunk 5 needs the code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3 <- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add "celdir" to chunk 5 then everything works since now
chunk 5 needs only the code from chunk 4 but not from chunk 3:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
Now buildVignettes() is able to create the vignettes, however R CMD
check still does not build the vignettes.
Yes, I get a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
However, with R-2.12.2 the following lines are added:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
and in xps.Rcheck the subdirectory "inst/doc" will be created which
contains the vignette data such as xps.Rnw, but also xps.tex and xps.pdf.
In contrast, R-2.13.0 does not create the subdirectory "inst/doc" and no
vignettes are built.
One more issue:
In contrast to my former believe R CMD INSTALL does not build the
vignettes, neither in R-2.12.2 nor in R-2.13.0. I have to run
buildVignettes() after installation. Is this the usual case?
Best regards
Christian
On 4/25/11 4:00 PM, Uwe Ligges wrote:
On 24.04.2011 23:10, cstrato wrote:
Dear Uwe,
On 4/24/11 10:37 PM, Uwe Ligges wrote:
On 24.04.2011 20:59, cstrato wrote:
Dear Uwe,
Thank you for your reply.
ad 2, Yes, i know that "xps-manual.pdf" is the collection of help
pages,
I have mentioned it only to show that creating pdf-files does work for
R-2.13.0.
ad 1, Could it be that this is a Mac-specific problem since I see it on
both my old MacBook Pro and my new Mac Mini.
Have you tried on any other OS? I did not since installing root is a bit
too much effort.
No, until now I did not try another OS, but I will, since xps has to
work on all three OSes.
Using R CMD check with R-2.12.2 I get:
I thought we are talking about R-2.13.0?
I showed you the output of R-2.12.2 first and then the output of
R-2.13.0, so that you can see that on the same machine with the same
file it works with one version but not the other.
But you got a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
Where is the R CMD build output (since R CMD build is supposed to
prepare the vignette).
$ R64 CMD check xps_1.13.1.tar.gz
* using log directory '/Volumes/CoreData/CRAN/xps.Rcheck'
* using R version 2.12.2 (2011-02-25)
* using platform: x86_64-apple-darwin9.8.0 (64-bit)
* using session charset: ASCII
* checking for file 'xps/DESCRIPTION' ... OK
* this is package 'xps' version '1.13.1'
...
...
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
* checking PDF version of manual ... OK
Using "RSwitch.app" I switch to R-2.13.0, but now I get:
$ R64 CMD check xps_1.13.1.tar.gz
* using log directory '/Volumes/CoreData/CRAN/xps.Rcheck'
* using
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users of
xps have to use, and there was never a problem.
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this in a
Sweave file:
<<>>=
x <- 1
@
<<>>=
y <- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3 <- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add "celdir" to chunk 5 then everything works since
now chunk 5 needs only the code from chunk 4 but not from chunk 3:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
Now buildVignettes() is able to create the vignettes, however R CMD
check still does not build the vignettes.
Yes, I get a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
However, with R-2.12.2 the following lines are added:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
and in xps.Rcheck the subdirectory "inst/doc" will be created which
contains the vignette data such as xps.Rnw, but also xps.tex and xps.pdf.
In contrast, R-2.13.0 does not create the subdirectory "inst/doc" and
no vignettes are built.
One more issue:
In contrast to my former believe R CMD INSTALL does not build the
vignettes, neither in R-2.12.2 nor in R-2.13.0. I have to run
buildVignettes() after installation. Is this the usual case?
Best regards
Christian
On 4/25/11 4:00 PM, Uwe Ligges wrote:
On 24.04.2011 23:10, cstrato wrote:
Dear Uwe,
On 4/24/11 10:37 PM, Uwe Ligges wrote:
On 24.04.2011 20:59, cstrato wrote:
Dear Uwe,
Thank you for your reply.
ad 2, Yes, i know that "xps-manual.pdf" is the collection of help
pages,
I have mentioned it only to show that creating pdf-files does work
for
R-2.13.0.
ad 1, Could it be that this is a Mac-specific problem since I see
it on
both my old MacBook Pro and my new Mac Mini.
Have you tried on any other OS? I did not since installing root is
a bit
too much effort.
No, until now I did not try another OS, but I will, since xps has to
work on all three OSes.
Using R CMD check with R-2.12.2 I get:
I thought we are talking about R-2.13.0?
I showed you the output of R-2.12.2 first and then the output of
R-2.13.0, so that you can see that on the same machine with the same
file it works with one version but not the other.
But you got a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
Where is the R CMD build output (sinc
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Thank you.
My problem seems to be that at the moment the problem can be seen only
on my Mac, since e.g. the Bioconductor servers have no problems creating
the vignettes.
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users
of xps have to use, and there was never a problem.
This might be a problem in R, or might be a problem in your code. As far
as I know, it has only shown up in your code, so I'd guess that's where
the problem is. In any case, you're the one in the best position to
isolate it and debug it.
If it turns out to be a problem in R, put together an example
illustrating the problem that doesn't involve your code, and I'll take a
look.
Duncan Murdoch
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this in a
Sweave file:
<<>>=
x <- 1
@
<<>>=
y <- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3 <- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add "celdir" to chunk 5 then everything works since
now chunk 5 needs only the code from chunk 4 but not from chunk 3:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celdir <- file.path(.path.package("xps"), "raw")
celfiles <- c("TestA1.CEL","TestA2.CEL")
data.test3 <- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
Now buildVignettes() is able to create the vignettes, however R CMD
check still does not build the vignettes.
Yes, I get a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
However, with R-2.12.2 the following lines are added:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
and in xps.Rcheck the subdirectory "inst/doc" will be created which
contains the vignette data such as xps.Rnw, but also xps.tex and
xps.pdf.
In contrast, R-2.13.0 does not create the subdirectory "inst/doc" and
no vignettes are built.
One more issue:
In contrast to my former believe R CMD INSTALL does not build the
vignettes, neither in R-2.12.2 nor in R-2.13.0. I have to run
buildVignettes() after installation. Is this the usual case?
Best regards
Christian
On 4/25/11 4:00 PM, Uwe Ligges wrote:
On 24.04.2011 23:10, cstrato wrote:
Dear Uwe,
On 4/24/11 10:37 PM, Uwe Ligges wrote:
On 24.04.2011 20:59, cstrato wrote:
Dear Uwe,
Thank you for your reply.
ad 2, Yes, i know that "xps-manual.pdf" is the collection of help
pages,
I have mentioned it only to show that creating pdf-files does work
for
R-2.13.0.
ad 1, Could it be that this is a Mac-specific problem since I see
it on
both my old MacBo
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Thank you, I will try. Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/04/2011 3:16 PM, cstrato wrote:
Thank you.
My problem seems to be that at the moment the problem can be seen only
on my Mac, since e.g. the Bioconductor servers have no problems creating
the vignettes.
Then you are definitely the one in the best position to diagnose the
problem. Use the usual approach: simplify it by cutting out everything
that looks unrelated. Verify that the problem still exists, then cut
some more. Eventually you'll have isolated the error to a particular
small snippet of code, and then you can add print() statements, or use
trace(), or do whatever is necessary to see what's so special about your
system.
I suspect it will turn out to be an assumption in the code that is not
true on your system.
If the assumption is being made by code you wrote, then fix it. If it's
being made by R, let us know.
Duncan Murdoch
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till
R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users
of xps have to use, and there was never a problem.
This might be a problem in R, or might be a problem in your code. As far
as I know, it has only shown up in your code, so I'd guess that's where
the problem is. In any case, you're the one in the best position to
isolate it and debug it.
If it turns out to be a problem in R, put together an example
illustrating the problem that doesn't involve your code, and I'll take a
look.
Duncan Murdoch
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this
in a
Sweave file:
<<>>=
x<- 1
@
<<>>=
y<- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from
two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3<- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles<- c("TestA1.CEL","TestA2.CEL")
data.test3<- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add "celdir" to chunk 5 then everything works since
now chunk 5 needs only the code from chunk 4 but not from chunk 3:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
celfiles<- c("TestA1.CEL","TestA2.CEL")
data.test3<- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
Now buildVignettes() is able to create the vignettes, however R CMD
check still does not build the vignettes.
Yes, I get a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
However, with R-2.12.2 the following lines are added:
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/APTvsXPS.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xps.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsClasses.Rnw
/Volumes/CoreData/CRAN/xps.Rcheck/00_pkg_src/xps/inst/doc/xpsPreprocess.Rnw
and in xps.Rcheck the subdirectory "inst/doc" will be created which
contains the vignette data such as xps.Rnw, but also xps.tex and
xps.pdf.
In contrast, R-2.13.0
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Duncan, dear Uwe,
Just now I have re-run everything, and today xps.Rnw can be converted to
a vignette w/o any problems using:
a, buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
b, R CMD Sweave xps.Rnw
In both cases the vignette xps.pdf is created (maybe my Mac did not like
to work during eastern holidays).
However, one issue remains:
"R64 CMD check xps_1.13.1.tar.gz" no longer creates any pdf files for
the vignettes.
Best regards
Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/04/2011 3:16 PM, cstrato wrote:
Thank you.
My problem seems to be that at the moment the problem can be seen only
on my Mac, since e.g. the Bioconductor servers have no problems creating
the vignettes.
Then you are definitely the one in the best position to diagnose the
problem. Use the usual approach: simplify it by cutting out everything
that looks unrelated. Verify that the problem still exists, then cut
some more. Eventually you'll have isolated the error to a particular
small snippet of code, and then you can add print() statements, or use
trace(), or do whatever is necessary to see what's so special about your
system.
I suspect it will turn out to be an assumption in the code that is not
true on your system.
If the assumption is being made by code you wrote, then fix it. If it's
being made by R, let us know.
Duncan Murdoch
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till
R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users
of xps have to use, and there was never a problem.
This might be a problem in R, or might be a problem in your code. As far
as I know, it has only shown up in your code, so I'd guess that's where
the problem is. In any case, you're the one in the best position to
isolate it and debug it.
If it turns out to be a problem in R, put together an example
illustrating the problem that doesn't involve your code, and I'll take a
look.
Duncan Murdoch
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this
in a
Sweave file:
<<>>=
x<- 1
@
<<>>=
y<- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from
two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3<- root.scheme(file.path(.path.package("xps"), "schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles<- c("TestA1.CEL","TestA2.CEL")
data.test3<- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add "celdir" to chunk 5 then everything works since
now chunk 5 needs only the code from chunk 4 but not from chunk 3:
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
celfiles<- c("TestA1.CEL","TestA2.CEL")
data.test3<- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
Now buildVignettes() is able to create the vignettes, however R CMD
check still does not build the vignettes.
Yes, I get a Warning in both cases:
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF:
However, with R-2.12.2 the following lines are ad
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe,
As I have already mentioned R CMD check gives the following output:
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... WARNING
Package vignette(s) without corresponding PDF:
APTvsXPS.Rnw
xps.Rnw
xpsClasses.Rnw
xpsPreprocess.Rnw
* checking running R code from vignettes ... OK
* checking re-building of vignettes ... OK
* checking PDF version of manual ... OK
WARNING: There was 1 warning, see
'/Volumes/CoreData/CRAN/xps.Rcheck/00check.log'
for details
Although the output says "checking PDF version of manual ... OK" I
cannot find any result in "xps.Rcheck".
When I run "R64 CMD build xps" I get:
* checking for file 'xps/DESCRIPTION' ... OK
* preparing 'xps':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to re-build vignettes
* creating vignettes ... OK
* cleaning src
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'xps_1.13.1.tar.gz'
However, the resulting file "xps_1.13.1.tgz" does also not contain any
vignettes.
Best regards
Christian
On 4/27/11 10:16 AM, Uwe Ligges wrote:
On 26.04.2011 21:58, cstrato wrote:
Dear Duncan, dear Uwe,
Just now I have re-run everything, and today xps.Rnw can be converted to
a vignette w/o any problems using:
a, buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
b, R CMD Sweave xps.Rnw
In both cases the vignette xps.pdf is created (maybe my Mac did not like
to work during eastern holidays).
However, one issue remains:
"R64 CMD check xps_1.13.1.tar.gz" no longer creates any pdf files for
the vignettes.
Dioes it give an error or warning? It should check the code. R CMD build
creates the pdf files.
Uwe Ligges
Best regards
Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/04/2011 3:16 PM, cstrato wrote:
Thank you.
My problem seems to be that at the moment the problem can be seen only
on my Mac, since e.g. the Bioconductor servers have no problems
creating
the vignettes.
Then you are definitely the one in the best position to diagnose the
problem. Use the usual approach: simplify it by cutting out everything
that looks unrelated. Verify that the problem still exists, then cut
some more. Eventually you'll have isolated the error to a particular
small snippet of code, and then you can add print() statements, or use
trace(), or do whatever is necessary to see what's so special about your
system.
I suspect it will turn out to be an assumption in the code that is not
true on your system.
If the assumption is being made by code you wrote, then fix it. If it's
being made by R, let us know.
Duncan Murdoch
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till
R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users
of xps have to use, and there was never a problem.
This might be a problem in R, or might be a problem in your code. As
far
as I know, it has only shown up in your code, so I'd guess that's
where
the problem is. In any case, you're the one in the best position to
isolate it and debug it.
If it turns out to be a problem in R, put together an example
illustrating the problem that doesn't involve your code, and I'll
take a
look.
Duncan Murdoch
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code
from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this
in a
Sweave file:
<<>>=
x<- 1
@
<<>>=
y<- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from
two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the
code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
###
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Duncan, dear Uwe,
Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a
virtual machine, I have now done the following tests on all three
architectures:
1, R CMD build xps:
This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as
pdf-file. Thus R CMD build is ok.
2, R CMD check xps:
This does NOT build the vignettes as pdf-files on all three
architectures. Or to be more precise, R-2.13.0 does no longer build the
vignettes since with R-2.12.2 and earlier versions R did create the
vignettes as pdf-files.
Thus the question is:
Why does R CMD check no longer create the vignettes?
Best regards
Christian
On 4/27/11 10:16 AM, Uwe Ligges wrote:
On 26.04.2011 21:58, cstrato wrote:
Dear Duncan, dear Uwe,
Just now I have re-run everything, and today xps.Rnw can be converted to
a vignette w/o any problems using:
a, buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
b, R CMD Sweave xps.Rnw
In both cases the vignette xps.pdf is created (maybe my Mac did not like
to work during eastern holidays).
However, one issue remains:
"R64 CMD check xps_1.13.1.tar.gz" no longer creates any pdf files for
the vignettes.
Dioes it give an error or warning? It should check the code. R CMD build
creates the pdf files.
Uwe Ligges
Best regards
Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/04/2011 3:16 PM, cstrato wrote:
Thank you.
My problem seems to be that at the moment the problem can be seen only
on my Mac, since e.g. the Bioconductor servers have no problems
creating
the vignettes.
Then you are definitely the one in the best position to diagnose the
problem. Use the usual approach: simplify it by cutting out everything
that looks unrelated. Verify that the problem still exists, then cut
some more. Eventually you'll have isolated the error to a particular
small snippet of code, and then you can add print() statements, or use
trace(), or do whatever is necessary to see what's so special about your
system.
I suspect it will turn out to be an assumption in the code that is not
true on your system.
If the assumption is being made by code you wrote, then fix it. If it's
being made by R, let us know.
Duncan Murdoch
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do not believe that there is a bug in my code, since:
1, it worked in all versions from R starting with R-2.6.0 till
R-2.12.2.
2, the identical code works in the examples
3, this code (or a similar code) is the starting code which all users
of xps have to use, and there was never a problem.
This might be a problem in R, or might be a problem in your code. As
far
as I know, it has only shown up in your code, so I'd guess that's
where
the problem is. In any case, you're the one in the best position to
isolate it and debug it.
If it turns out to be a problem in R, put together an example
illustrating the problem that doesn't involve your code, and I'll
take a
look.
Duncan Murdoch
Maybe the reason could be that my code has to import
- the CEL-files from the package dir
- the file SchemeTest3.root from the package dir
??
Best regards
Christian
On 4/25/11 8:00 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Uwe,
Your suggestion to look at the Sweave manual helped me to solve the
problem. It seems that in R-2.13.0 every chunk can use the code
from
the chunk before but not from an earlier chunk.
I'm either misreading what you wrote, or it's wrong. If I have this
in a
Sweave file:
<<>>=
x<- 1
@
<<>>=
y<- 2
@
<<>>=
print(x)
@
I will see the value of x getting printed, even though it came from
two
chunks earlier.
I think Uwe is right: there is some bug in the code you're running.
Sweave isn't the problem.
Duncan Murdoch
Concretely, the following does not work since chunk 5 needs the
code
from chunk 3 and 4:
###
### chunk number 3:
###
#line 126 "xps.Rnw"
celdir<- file.path(.path.package("xps"), "raw")
###
### chunk number 4:
###
#line 132 "xps.Rnw"
scheme.test3<- root.scheme(file.path(.path.package("xps"),
"schemes",
"SchemeTest3.root"))
###
### chunk number 5:
###
#line 137 "xps.Rnw"
celfiles<- c("TestA1.CEL","TestA2.CEL")
data.test3<- import.data(scheme.test3, "tmpdt_DataTest3",
celdir=celdir, celfiles=celfiles, verbose=FALSE)
However, when I add &q
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Prof. Ripley,
Thank you for your confirmation and explanation, I understand the reason
for cleaning things up to save memory. However, it was very convenient
to have this feature in earlier versions of R. It would be really
helpful to have an additional option to R CMD check, e.g.
"--no-clean-vignettes".
FYI, I did not claim "..create the vignettes *in inst/doc*",
instead my words were:
One interesting observation is that xps.Rcheck from R-2.12.2 contains
the subdirectory "inst/doc" with the vignettes while xps.Rcheck from
R-2.13.0 does not contain "inst".
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
On 5/2/11 7:08 AM, Prof Brian Ripley wrote:
On Sun, 1 May 2011, Duncan Murdoch wrote:
On 11-05-01 4:10 PM, cstrato wrote:
Dear Duncan, dear Uwe,
Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a
virtual machine, I have now done the following tests on all three
architectures:
1, R CMD build xps:
This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as
pdf-file. Thus R CMD build is ok.
2, R CMD check xps:
This does NOT build the vignettes as pdf-files on all three
architectures. Or to be more precise, R-2.13.0 does no longer build the
vignettes since with R-2.12.2 and earlier versions R did create the
vignettes as pdf-files.
Thus the question is:
Why does R CMD check no longer create the vignettes?
Probably the answer is simply "because it doesn't". For a truly
reliable check, you should build the package, then check the tar.gz
file. Anything else is, and always has been, an approximation.
Actually, it does. What earlier versions never did (despite 'cstrato's
repeated delusional claims earlier) was to create the vignettes *in
inst/doc*. All of them re-created (by default) vignettes in a
working directory. The difference is that 2.13.0 deletes that working
directory if the test was successful, whereas earlier versions left the
results somewhere in .Rcheck (the 'somewhere' has varied). However,
earier versions of R CMD check sometimes failed when R CMD build succeeded
Using Animal (a small CRAN package with one vignette).
R 2.12.2 gave
* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignettes without corresponding PDF:
/tmp/Animal/inst/doc/Animal.Rnw
and the vignette was re-created in Animal.Rcheck/inst/doc.
R 2.13.0 gives
* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignette(s) without corresponding PDF:
Animal.Rnw
Non-ASCII package vignette(s) without specified encoding:
Animal.Rnw
* checking running R code from vignettes ... OK
* checking re-building of vignettes ... OK
and the working directory was Animal.Rcheck/vign_test .
The main reason for cleaning up is that to mimic R CMD build the test
has to make a complete copy of the package sources, and that adds up:
checking CRAN already takes 17GB for each flavour.
Duncan Murdoch
Best regards
Christian
On 4/27/11 10:16 AM, Uwe Ligges wrote:
On 26.04.2011 21:58, cstrato wrote:
Dear Duncan, dear Uwe,
Just now I have re-run everything, and today xps.Rnw can be
converted to
a vignette w/o any problems using:
a, buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
b, R CMD Sweave xps.Rnw
In both cases the vignette xps.pdf is created (maybe my Mac did not
like
to work during eastern holidays).
However, one issue remains:
"R64 CMD check xps_1.13.1.tar.gz" no longer creates any pdf files for
the vignettes.
Dioes it give an error or warning? It should check the code. R CMD
build
creates the pdf files.
Uwe Ligges
Best regards
Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/04/2011 3:16 PM, cstrato wrote:
Thank you.
My problem seems to be that at the moment the problem can be seen
only
on my Mac, since e.g. the Bioconductor servers have no problems
creating
the vignettes.
Then you are definitely the one in the best position to diagnose the
problem. Use the usual approach: simplify it by cutting out
everything
that looks unrelated. Verify that the problem still exists, then cut
some more. Eventually you'll have isolated the error to a particular
small snippet of code, and then you can add print() statements, or
use
trace(), or do whatever is necessary to see what's so special
about your
system.
I suspect it will turn out to be an assumption in the code that is
not
true on your system.
If the assumption is being made by code you wrote, then fix it. If
it's
being made by R, let us know.
Duncan Murdoch
Best regards
Christian
On 4/25/11 8:55 PM, Duncan Murdoch wrote:
cstrato wrote:
Dear Duncan,
Thank you for your example, however it is different since it
does not
use x and y. What about print(x+y)?
Try it.
Sorry, I do
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe,
This is my development cycle:
First, I run R CMD check until there are no more warnings/errors. Since
years it was very convenient that R CMD check builds the pdf-files of
the vignettes, too, since this allowed me to correct errors in the
manual files and the vignette files at the same time!
Afterwards I run R CMD INSTALL to install my package and do more tests
until everything works.
As you see I do not use R CMD build, since every run takes about 5
minutes, it overwrites my zipped source code, and I would need to unzip
it to get access to the vignette pdf-files.
Best regards
Christian
On 5/3/11 1:07 PM, Uwe Ligges wrote:
On 02.05.2011 21:24, cstrato wrote:
Dear Prof. Ripley,
Thank you for your confirmation and explanation, I understand the reason
for cleaning things up to save memory. However, it was very convenient
to have this feature in earlier versions of R. It would be really
helpful to have an additional option to R CMD check, e.g.
"--no-clean-vignettes".
FYI, I did not claim "..create the vignettes *in inst/doc*",
instead my words were:
One interesting observation is that xps.Rcheck from R-2.12.2 contains
the subdirectory "inst/doc" with the vignettes while xps.Rcheck from
R-2.13.0 does not contain "inst".
But you do not need it. I do not know how often I have to mention that
vignettes are produced by R CMD build! They are already build when
running R CMD check. And please do not tell us about tzhe PDF version
oif manuals which are *unrelated* to vignettes, because they are not
built in advance and need to be checked, since they should be produced
at user level while vignettes are built at developer level already.
Uwe Ligges
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l: cstrato at aon.at
_._._._._._._._._._._._._._._._._._
On 5/2/11 7:08 AM, Prof Brian Ripley wrote:
On Sun, 1 May 2011, Duncan Murdoch wrote:
On 11-05-01 4:10 PM, cstrato wrote:
Dear Duncan, dear Uwe,
Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a
virtual machine, I have now done the following tests on all three
architectures:
1, R CMD build xps:
This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as
pdf-file. Thus R CMD build is ok.
2, R CMD check xps:
This does NOT build the vignettes as pdf-files on all three
architectures. Or to be more precise, R-2.13.0 does no longer build
the
vignettes since with R-2.12.2 and earlier versions R did create the
vignettes as pdf-files.
Thus the question is:
Why does R CMD check no longer create the vignettes?
Probably the answer is simply "because it doesn't". For a truly
reliable check, you should build the package, then check the tar.gz
file. Anything else is, and always has been, an approximation.
Actually, it does. What earlier versions never did (despite 'cstrato's
repeated delusional claims earlier) was to create the vignettes *in
inst/doc*. All of them re-created (by default) vignettes in a
working directory. The difference is that 2.13.0 deletes that working
directory if the test was successful, whereas earlier versions left the
results somewhere in .Rcheck (the 'somewhere' has varied). However,
earier versions of R CMD check sometimes failed when R CMD build
succeeded
Using Animal (a small CRAN package with one vignette).
R 2.12.2 gave
* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignettes without corresponding PDF:
/tmp/Animal/inst/doc/Animal.Rnw
and the vignette was re-created in Animal.Rcheck/inst/doc.
R 2.13.0 gives
* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignette(s) without corresponding PDF:
Animal.Rnw
Non-ASCII package vignette(s) without specified encoding:
Animal.Rnw
* checking running R code from vignettes ... OK
* checking re-building of vignettes ... OK
and the working directory was Animal.Rcheck/vign_test .
The main reason for cleaning up is that to mimic R CMD build the test
has to make a complete copy of the package sources, and that adds up:
checking CRAN already takes 17GB for each flavour.
Duncan Murdoch
Best regards
Christian
On 4/27/11 10:16 AM, Uwe Ligges wrote:
On 26.04.2011 21:58, cstrato wrote:
Dear Duncan, dear Uwe,
Just now I have re-run everything, and today xps.Rnw can be
converted to
a vignette w/o any problems using:
a, buildVignettes("xps", dir="/Volumes/CoreData/CRAN/xps", quiet=F)
b, R CMD Sweave xps.Rnw
In both cases the vignette xps.pdf is created (maybe my Mac did not
like
to work during eastern holidays).
However, one issue remains:
"R64 CMD check xps_1.13.1.tar.gz" no longer creates any pdf files
for
the vignettes.
Dioes it give an error or warning? It should check the code. R CMD
build
creates the pdf files.
Uwe Ligges
Best regards
Christian
On 4/25/11 9:31 PM, Duncan Murdoch wrote:
On 25/
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe, Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not polluted. Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. "--no-clean-vignettes". FYI, I did not claim "..create the vignettes *in inst/doc*", instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory "inst/doc" with the vignettes while xps.Rcheck from R-2.13.0 does not contain "inst". But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply "because it doesn't". For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in inst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in .Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK and the working directory was Animal.Rcheck/vign_test . The main reason for cleaning up is that to mimic R CMD build the test has to make a complete copy of the package sources, and that adds up: checking CRAN already t
Re: [Rd] How to create vignette.pdf for R-2.13.0?
No, I simply do "tar czf xps_1.13.1.tar.gz xps". Best regards Christian On 5/3/11 11:11 PM, Simon Urbanek wrote: > On May 3, 2011, at 4:48 PM, cstrato wrote: > >> Dear Uwe, >> >> Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is >> not polluted. >> > > But then you already used build to create the tar ball so the vignette has > been built. So what is your point? > > Cheers, > S > > >> Furthermore, I forgot to mention that finally I upload the source code only >> to the BioC svn repository. The rest is done by the BioC servers, including >> building the pdf-files for the vignettes. >> >> Best regards >> Christian >> >> >> On 5/3/11 10:13 PM, Uwe Ligges wrote: >>> >>> >>> On 03.05.2011 21:14, cstrato wrote: >>>> Dear Uwe, >>>> >>>> This is my development cycle: >>>> >>>> First, I run R CMD check until there are no more warnings/errors. Since >>>> years it was very convenient that R CMD check builds the pdf-files of >>>> the vignettes, too, since this allowed me to correct errors in the >>>> manual files and the vignette files at the same time! >>>> >>>> Afterwards I run R CMD INSTALL to install my package and do more tests >>>> until everything works. >>>> >>>> As you see I do not use R CMD build, since every run takes about 5 >>>> minutes, it overwrites my zipped source code, and I would need to unzip >>>> it to get access to the vignette pdf-files. >>> >>> >>> Then this is the main problem here. The *recommended* development cycle >>> from the manuals is to run >>> >>> 1. R CMD build in order to get a valid source tarball and clean the sources >>> 2. R CMD INSTALL to check if your package can be installed >>> 3. R CMD check in order to finally check your package >>> >>> Running R CMD INSTALL on your source directory may pollute it, hence >>> this is not recommended at all. >>> >>> >>> Best, >>> UWe >>> >>> >>> >>> >>> >>>> >>>> Best regards >>>> Christian >>>> >>>> >>>> On 5/3/11 1:07 PM, Uwe Ligges wrote: >>>>> >>>>> >>>>> On 02.05.2011 21:24, cstrato wrote: >>>>>> Dear Prof. Ripley, >>>>>> >>>>>> Thank you for your confirmation and explanation, I understand the >>>>>> reason >>>>>> for cleaning things up to save memory. However, it was very convenient >>>>>> to have this feature in earlier versions of R. It would be really >>>>>> helpful to have an additional option to R CMD check, e.g. >>>>>> "--no-clean-vignettes". >>>>>> >>>>>> FYI, I did not claim "..create the vignettes *ininst/doc*", >>>>>> instead my words were: >>>>>> One interesting observation is that xps.Rcheck from R-2.12.2 contains >>>>>> the subdirectory "inst/doc" with the vignettes while xps.Rcheck from >>>>>> R-2.13.0 does not contain "inst". >>>>> >>>>> >>>>> But you do not need it. I do not know how often I have to mention that >>>>> vignettes are produced by R CMD build! They are already build when >>>>> running R CMD check. And please do not tell us about tzhe PDF version >>>>> oif manuals which are *unrelated* to vignettes, because they are not >>>>> built in advance and need to be checked, since they should be produced >>>>> at user level while vignettes are built at developer level already. >>>>> >>>>> Uwe Ligges >>>>> >>>>> >>>>>> Best regards >>>>>> Christian >>>>>> _._._._._._._._._._._._._._._._._._ >>>>>> C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a >>>>>> V.i.e.n.n.a A.u.s.t.r.i.a >>>>>> e.m.a.i.l: cstrato at aon.at >>>>>> _._._._._._._._._._._._._._._._._._ >>>>>> >>>>>> >>>>>> On 5/2/11 7:08 AM, Prof Brian Ripley wrote: >>>>>>> On Sun, 1 May 2011, Duncan Murdoch wrote: >>>>>>> >>>>>>>> On 11-05-01 4:10 PM, cstrato wrote: >>>>>>>>> Dear
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Simon, I did not complain about the R doing something wrong. I only wanted to know why, after all these years, R CMD check does suddenly no longer build the pdf-files of the vignettes. I also think that this is a legal question. Let me compare the times spent: 1, the "official" development cycle: - R CMD build: 5 minutes - R CMD INSTALL: 3 minutes - R CMD check: 6 minutes 2, my own development cycle: - manual tarring: 2 seconds - R CMD check:6 minutes This means spending 14 minutes vs 6 minutes. If I assume that in one evening I have to make 10 corrections this would mean 140 minutes vs 60 minutes, i.e. the official development cycle would take 1 hr and 20 min longer than my own development cycle. This is time I do not have. Best regards Christian On 5/4/11 12:13 AM, Simon Urbanek wrote: On May 3, 2011, at 5:15 PM, cstrato wrote: No, I simply do "tar czf xps_1.13.1.tar.gz xps". Well, that's your problem then, not R's. Source packages are created using R CMD build, not by manual tarring (you can do the latter if you know what you're doing, but then you can't complain about the R doing something wrong). Cheers, S On 5/3/11 11:11 PM, Simon Urbanek wrote: On May 3, 2011, at 4:48 PM, cstrato wrote: Dear Uwe, Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. "--no-clean-vignettes". FYI, I did not claim "..create the vignettes *ininst/doc*", instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory "inst/doc" with the vignettes while xps.Rcheck from R-2.13.0 does not contain "inst". But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply "because it doesn't". For
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Herve, In my initial mail: https://stat.ethz.ch/pipermail/r-devel/2011-April/060688.html I wrote: "While R CMD check and R CMD INSTALL have always created the vignettes on R-2.12.1 or any earlier versions of R, I am no longer able to build the vignettes on R-2.13.0." Although I made the mistake to include R CMD INSTALL, I wanted simply to know why R CMD check suddenly (after all these years) does no longer build the pdf-versions of the vignettes. After many replies and discussions Prof. Ripley gave finally the answer: https://stat.ethz.ch/pipermail/r-devel/2011-May/060782.html I understand the reason for this and made the suggestion to include an option such as "--no-clean-vignettes" to R CMD check, since this would be a convenient option for me: https://stat.ethz.ch/pipermail/r-devel/2011-May/060797.html Best regards Christian On 5/8/11 9:29 PM, Hervé Pagès wrote: Hi Christian, On 11-05-04 01:02 PM, cstrato wrote: Dear Simon, I did not complain about the R doing something wrong. I only wanted to know why, after all these years, R CMD check does suddenly no longer build the pdf-files of the vignettes. I also think that this is a legal question. Let me compare the times spent: 1, the "official" development cycle: - R CMD build: 5 minutes - R CMD INSTALL: 3 minutes - R CMD check: 6 minutes 2, my own development cycle: - manual tarring: 2 seconds - R CMD check: 6 minutes This means spending 14 minutes vs 6 minutes. My understanding is that R CMD INSTALL is not strictly necessary in the official devel cycle. However, to be fair you should either include that step in both cycles (devel and yours) or not. Then the numbers are 14 minutes vs 9 minutes (or 11 minutes vs 6 minutes). If I assume that in one evening I have to make 10 corrections this would mean 140 minutes vs 60 minutes, i.e. the official development cycle would take 1 hr and 20 min longer than my own development cycle. This is time I do not have. No matter how you put it and how much benefits you get from this, manual tarring is *wrong* and "after all these years" you should really know this. Furthermore, here is what you claimed in a previous email: This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. You didn't mention the manual tarring. Then later: Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not polluted. So you are contradicting yourself. No, I simply do "tar czf xps_1.13.1.tar.gz xps". Whaooo, finally! Note that, among other problems, this manual tarring is very likely to pollute your source tree (this is one of the things R CMD build will take care of). You are free to do manual tarring for your own internal business if you want, nobody cares, but you should keep this kind of dirty little secrets for you. For your 10 corrections, you can do manual tarring 10 times, that's your problem, but that doesn't prevent you from doing the right thing, i.e. R CMD build + R CMD check, as a *final* pass (e.g. just before you commit your changes to svn). Now that means 71 minutes vs 60 minutes, but you did the *right* thing. Cheers, H. Best regards Christian On 5/4/11 12:13 AM, Simon Urbanek wrote: On May 3, 2011, at 5:15 PM, cstrato wrote: No, I simply do "tar czf xps_1.13.1.tar.gz xps". Well, that's your problem then, not R's. Source packages are created using R CMD build, not by manual tarring (you can do the latter if you know what you're doing, but then you can't complain about the R doing something wrong). Cheers, S On 5/3/11 11:11 PM, Simon Urbanek wrote: On May 3, 2011, at 4:48 PM, cstrato wrote: Dear Uwe, Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since thi
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Herve, Since 'R CMD check' has already options '--no-vignettes' and '--no-rebuild-vignettes', so why not option '--no-clean-vignettes'? But, as you admitted, it is only a suggestion. Maybe it is time to close this thread. (If you want we can discuss this issue further privately.) Best regards Christian On 5/9/11 7:20 AM, Hervé Pagès wrote: Christian, On 11-05-08 01:19 PM, cstrato wrote: Dear Herve, In my initial mail: https://stat.ethz.ch/pipermail/r-devel/2011-April/060688.html I wrote: "While R CMD check and R CMD INSTALL have always created the vignettes on R-2.12.1 or any earlier versions of R, I am no longer able to build the vignettes on R-2.13.0." Although I made the mistake to include R CMD INSTALL, I wanted simply to know why R CMD check suddenly (after all these years) does no longer build the pdf-versions of the vignettes. After many replies and discussions Prof. Ripley gave finally the answer: https://stat.ethz.ch/pipermail/r-devel/2011-May/060782.html I understand the reason for this and made the suggestion to include an option such as "--no-clean-vignettes" to R CMD check, since this would be a convenient option for me: https://stat.ethz.ch/pipermail/r-devel/2011-May/060797.html and then someone tried to explain you that you didn't need that, you just need to use the standard development cycle. And in your last 5 emails you're still trying to convince the people around that you have a better/faster development cycle that doesn't use 'R CMD build' at all. No matter this better development cycle is broken, it should be supported anyway by adding a "--no-clean-vignettes" option to 'R CMD check' just because that would be a "convenient option for you"? I know, you are just suggesting this option, but still... H. Best regards Christian On 5/8/11 9:29 PM, Hervé Pagès wrote: Hi Christian, On 11-05-04 01:02 PM, cstrato wrote: Dear Simon, I did not complain about the R doing something wrong. I only wanted to know why, after all these years, R CMD check does suddenly no longer build the pdf-files of the vignettes. I also think that this is a legal question. Let me compare the times spent: 1, the "official" development cycle: - R CMD build: 5 minutes - R CMD INSTALL: 3 minutes - R CMD check: 6 minutes 2, my own development cycle: - manual tarring: 2 seconds - R CMD check: 6 minutes This means spending 14 minutes vs 6 minutes. My understanding is that R CMD INSTALL is not strictly necessary in the official devel cycle. However, to be fair you should either include that step in both cycles (devel and yours) or not. Then the numbers are 14 minutes vs 9 minutes (or 11 minutes vs 6 minutes). If I assume that in one evening I have to make 10 corrections this would mean 140 minutes vs 60 minutes, i.e. the official development cycle would take 1 hr and 20 min longer than my own development cycle. This is time I do not have. No matter how you put it and how much benefits you get from this, manual tarring is *wrong* and "after all these years" you should really know this. Furthermore, here is what you claimed in a previous email: This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. You didn't mention the manual tarring. Then later: Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code is not polluted. So you are contradicting yourself. No, I simply do "tar czf xps_1.13.1.tar.gz xps". Whaooo, finally! Note that, among other problems, this manual tarring is very likely to pollute your source tree (this is one of the things R CMD build will take care of). You are free to do manual tarring for your own internal business if you want, nobody cares, but you should keep this kind of dirty little secrets for you. For your 10 corrections, you can do manual tarring 10 times, that's your problem, but that doesn't prevent you from doing the right thing, i.e. R CMD build + R CMD check, as a *final* pass (e.g. just before you commit your changes to svn). Now that means 71 minutes vs 60 minutes, but you did the *right* thing. Cheers, H. Best regards Christian On 5/4/11 12:13 AM, Simon Urbanek wrote: On May 3, 2011, at 5:15 PM, cstrato wrote: No, I simply do "tar czf xps_1.13.1.tar.gz xps". Well, that's your problem then, not R's. Source packages ar
[Rd] operation on ‘numsels’ may be undefined
Dear all, Since many years the following C++ code does compile on ALL Bioconductor servers (Linux, Windows, Mac) without any warnings: Int_t numsels = 0; //number of selected entries ... for (Int_t i=0; iEven on the recently added release server 'zin2' Linux (Ubuntu 12.04.4 LTS) the above code compiles w/o warnings. However, on the new development server 'zin1' Linux (Ubuntu 12.04.4 LTS) I get suddenly the following warning message: Found the following significant warnings: XPSPreProcessing.cxx:3026:56: warning: operation on ‘numsels’ may be undefined [-Wsequence-point] Interestingly, both servers do not only run the same version of Ubuntu, but also the same version of the C++ compiler, i.e. g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, and use the same flags, see: http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html My question is now, why do I suddenly get the compiler warning? The reason why I ask at R-devel and not Bioc-devel is that it may not only be a Bioc question, since I found the following links: http://c-faq.com/expr/seqpoints.html http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c I am not sure if I understand the meaning, but until now I have never got any warning from any compiler the I have used (including MS Visual C++). Do I really have to replace '++numsels' with 'numsels+1'? Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operation on ‘numsels’ may be undefined
Dear Romain, Thank you for your suggestions, I like especially the first one. However, you did not explain why I have never got this warning message on any compiler, and why only one of the two identical Ubuntu compilers did give this warning message? Best regards, Christian On 6/23/14 3:45 PM, Romain François wrote: Le 23 juin 2014 à 15:20, cstrato a écrit : Dear all, Since many years the following C++ code does compile on ALL Bioconductor servers (Linux, Windows, Mac) without any warnings: Int_t numsels = 0; //number of selected entries ... for (Int_t i=0; i This is confusing. I would write the loop body like this: numsels += (arrMask[i] == 1) ; or preferably using the STL: Int_t numsels = std::count( begin(arrMask), end(arrMask), 1 ) ; or some other variation of this, i.e. perhaps you don’t have a C++11 compiler, so perhaps one of these depending on what is arrMask: Int_t numsels = std::count( arrMask.begin(), arrMask.end(), 1 ) ; Int_t numsels = std::count( arrMask, arrMask + size, 1 ) ; Romain Even on the recently added release server 'zin2' Linux (Ubuntu 12.04.4 LTS) the above code compiles w/o warnings. However, on the new development server 'zin1' Linux (Ubuntu 12.04.4 LTS) I get suddenly the following warning message: Found the following significant warnings: XPSPreProcessing.cxx:3026:56: warning: operation on ‘numsels’ may be undefined [-Wsequence-point] Interestingly, both servers do not only run the same version of Ubuntu, but also the same version of the C++ compiler, i.e. g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, and use the same flags, see: http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html My question is now, why do I suddenly get the compiler warning? The reason why I ask at R-devel and not Bioc-devel is that it may not only be a Bioc question, since I found the following links: http://c-faq.com/expr/seqpoints.html http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c I am not sure if I understand the meaning, but until now I have never got any warning from any compiler the I have used (including MS Visual C++). Do I really have to replace '++numsels' with 'numsels+1'? Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] operation on ‘numsels’ may be undefined
Dear Romain, I do not know enough about compilers, but as far as I remember, they 'work' from right to left, so numsels = ++numsels should not confuse the compiler. Anyhow I will change my code to your first suggestion since it is more elegant. Best regards, Christian On 6/23/14 7:13 PM, Romain François wrote: Le 23 juin 2014 à 18:28, cstrato a écrit : Dear Romain, Thank you for your suggestions, I like especially the first one. However, you did not explain why I have never got this warning message on any compiler, and why only one of the two identical Ubuntu compilers did give this warning message? Best regards, Christian I don’t know, but this: numsels = ++numsels ; seems fishy to me, and so it keeps feeling weird with the addition of the ternary operator. There is obviously a difference of setup between these two machines, but I don’t have time to sherlock that for you. One of the compilers is getting more careful than the other. Getting warnings you did not get before is a good thing, as it helps you update the code with that new insight. Welcome to my world, I’m sometimes thrown all kinds of new warnings from esoteric compilers, all of them have value . Romain On 6/23/14 3:45 PM, Romain François wrote: Le 23 juin 2014 à 15:20, cstrato a écrit : Dear all, Since many years the following C++ code does compile on ALL Bioconductor servers (Linux, Windows, Mac) without any warnings: Int_t numsels = 0; //number of selected entries ... for (Int_t i=0; i This is confusing. I would write the loop body like this: numsels += (arrMask[i] == 1) ; or preferably using the STL: Int_t numsels = std::count( begin(arrMask), end(arrMask), 1 ) ; or some other variation of this, i.e. perhaps you don’t have a C++11 compiler, so perhaps one of these depending on what is arrMask: Int_t numsels = std::count( arrMask.begin(), arrMask.end(), 1 ) ; Int_t numsels = std::count( arrMask, arrMask + size, 1 ) ; Romain Even on the recently added release server 'zin2' Linux (Ubuntu 12.04.4 LTS) the above code compiles w/o warnings. However, on the new development server 'zin1' Linux (Ubuntu 12.04.4 LTS) I get suddenly the following warning message: Found the following significant warnings: XPSPreProcessing.cxx:3026:56: warning: operation on ‘numsels’ may be undefined [-Wsequence-point] Interestingly, both servers do not only run the same version of Ubuntu, but also the same version of the C++ compiler, i.e. g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, and use the same flags, see: http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html My question is now, why do I suddenly get the compiler warning? The reason why I ask at R-devel and not Bioc-devel is that it may not only be a Bioc question, since I found the following links: http://c-faq.com/expr/seqpoints.html http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c I am not sure if I understand the meaning, but until now I have never got any warning from any compiler the I have used (including MS Visual C++). Do I really have to replace '++numsels' with 'numsels+1'? Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] operation on ‘numsels’ may be undefined
Dear Kasper,
What do you mean with 'undefined aspect of ++'?
Every compiler has to evaluate first the expression on the right side
and then apply the result to the variable on the left side, as in:
i = i + 1;
I understand that the expression:
i = i++;
may be confusing, but the expression:
i = ++i;
should work. What about:
i = (++i); or i = {++i}
Would this also result in a warning message?
Best regards,
Christian
On 6/23/14 10:05 PM, Kasper Daniel Hansen wrote:
You're getting this message because you are using an undefined aspect of
++. Depending on compiler convention re. the interpretation of ++, your
code may be interpreted differently; ie. different compilers will
interpret the code differently. This is a bad thing.
You're presumably getting the warning now, because the compiler flag has
been added on the Bioc build servers.
There was a recent thread on this specific aspect of ++ recently, but I
forgot which email list.
Kasper
On Mon, Jun 23, 2014 at 2:54 PM, cstrato mailto:cstr...@aon.at>> wrote:
Dear Romain,
I do not know enough about compilers, but as far as I remember, they
'work' from right to left, so numsels = ++numsels should not confuse
the compiler. Anyhow I will change my code to your first suggestion
since it is more elegant.
Best regards,
Christian
On 6/23/14 7:13 PM, Romain François wrote:
Le 23 juin 2014 à 18:28, cstrato mailto:cstr...@aon.at>> a écrit :
Dear Romain,
Thank you for your suggestions, I like especially the first one.
However, you did not explain why I have never got this
warning message on any compiler, and why only one of the two
identical Ubuntu compilers did give this warning message?
Best regards,
Christian
I don’t know, but this:
numsels = ++numsels ;
seems fishy to me, and so it keeps feeling weird with the
addition of the ternary operator.
There is obviously a difference of setup between these two
machines, but I don’t have time to sherlock that for you. One of
the compilers is getting more careful than the other. Getting
warnings you did not get before is a good thing, as it helps you
update the code with that new insight.
Welcome to my world, I’m sometimes thrown all kinds of new
warnings from esoteric compilers, all of them have value .
Romain
On 6/23/14 3:45 PM, Romain François wrote:
Le 23 juin 2014 à 15:20, cstrato mailto:cstr...@aon.at>> a écrit :
Dear all,
Since many years the following C++ code does compile
on ALL Bioconductor servers (Linux, Windows, Mac)
without any warnings:
Int_t numsels = 0; //number of selected entries
...
for (Int_t i=0; ihttp://bioconductor.org/__checkResults/2.14/bioc-LATEST/__zin2-NodeInfo.html
<http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html>
http://bioconductor.org/__checkResults/devel/bioc-__LATEST/zin1-NodeInfo.html
<http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html>
My question is now, why do I suddenly get the
compiler warning?
The reason why I ask at R-devel and not Bioc-devel
is that it may not only be a Bioc question, since I
found the following links:
http://c-faq.com/expr/__seqpoints.html
<http://c-faq.com/expr/seqpoints.html>
http://stackoverflow.com/__questions/16838884/why-i-got-__operation-may-be-undefined-in-__statement-expression-in-c
<http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c>
I am not sure if I understand the meaning, but until
now I have never got any warning from any compiler
the I have used (including MS Visual C++).
Do I really have to replace '++numsels' with
'numsels+1'?
Best regards,
Christian
_._._._._._._._._._._._._._._.___._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at <http://aon.at>
_._._._._._._._._._._._._._._.___._._
R-devel@r-project.org <mailto:R-devel@r-project.org>
mai
Re: [Rd] operation on ‘numsels’ may be undefined
Dear all,
Thank you very much for this interesting discussion, I appreciate it.
I think that Kevin gave a very good explanation why my code is
ambiguous, although it is not clear to me why the C/C++ standard leaves
this case undefined. One last question:
If I would write
numsels = {++numsels;}
Is this also undefined or is this then allowed?
Best regards,
Christian
On 6/24/14 7:28 AM, Kevin Ushey wrote:
I don't see what's so surprising here.
That statement is identical to writing:
if (arrMask[i] == 1) {
numsels = ++numsels;
} else {
numsels = numsels;
}
and
numsels = ++numsels;
has two statements modifying the value of numsels (= and prefix-++) in
a single sequence point. (Do we increment then assign, or assign then
increment? The C / C++ standards leave this undefined.)
Imagine writing the operations out as functions: we have the `=`
function, and the `prefix-++` function -- both of these 'modify' (one
of) their arguments. Do we evaluate it as `=`(a, `prefix-++`(a)) or
`prefix-++`(`=`(a, a))? The C standard leaves this undefined, so
compilers are free to do what they wish (and the nice ones warn you
when there is such an ambiguity). I guess the net result of the
operation is the same in each case _here_, but this is of course not
the case for other functions that modify the value of their
operand(s). And, in truth, this is _undefined behaviour_ and so the
compiler could still rightly make demons fly out of your nose if it
wanted to upon program execution.
I highly recommend reading the slides at
http://www.slideshare.net/olvemaudal/deep-c, especially the bit on
sequence points.
Cheers,
Kevin
On Mon, Jun 23, 2014 at 9:22 PM, Kasper Daniel Hansen
wrote:
I am not an expert on this, but I note that the section on -Wsequence-point
at
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
specifically mentions ? and :. Perhaps some more work on tracking down
their definitions and precedence might lead to insights.
Best,
Kasper
On Mon, Jun 23, 2014 at 6:42 PM, Hervé Pagès wrote:
On 06/23/2014 03:18 PM, Hervé Pagès wrote:
Hi Christian,
On 06/23/2014 11:54 AM, cstrato wrote:
Dear Romain,
I do not know enough about compilers, but as far as I remember, they
'work' from right to left,
Not necessarily. So you should not rely on that. This is what the
(somewhat obscure) warning you see on zin1 is trying to tell you.
Actually, I don't see an ambiguity in your code:
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
Yes it's confusing and unnecessarily complicated but I don't see that
it relies on some undefined behavior. It's not like in the thread on
Bioc-devel where the expression was:
*p++ = tolower(*p);
In that case the left-value of the assignment is itself an expression
that needs to be evaluated and the outcome of the assignment depends
on whether the left-value is evaluated before the right expression or
not. But in your case the left-value is a variable name so there is
nothing to evaluate.
So I don't know. Looks like a false positive from the gcc compiler to
me. Someone on the list might have a better insight.
Cheers,
H.
Personally I would just do:
if (arrMask[i] == 1) numsels++;
which is the standard way to implement the "if (some condition)
then increment counter" idiom.
As Kasper mentioned, a similar issue was recently discussed here:
https://stat.ethz.ch/pipermail/bioc-devel/2014-June/005858.html
Cheers,
H.
so numsels = ++numsels should not confuse the
compiler. Anyhow I will change my code to your first suggestion since it
is more elegant.
Best regards,
Christian
On 6/23/14 7:13 PM, Romain François wrote:
Le 23 juin 2014 à 18:28, cstrato a écrit :
Dear Romain,
Thank you for your suggestions, I like especially the first one.
However, you did not explain why I have never got this warning
message on any compiler, and why only one of the two identical Ubuntu
compilers did give this warning message?
Best regards,
Christian
I don’t know, but this:
numsels = ++numsels ;
seems fishy to me, and so it keeps feeling weird with the addition of
the ternary operator.
There is obviously a difference of setup between these two machines,
but I don’t have time to sherlock that for you. One of the compilers
is getting more careful than the other. Getting warnings you did not
get before is a good thing, as it helps you update the code with that
new insight.
Welcome to my world, I’m sometimes thrown all kinds of new warnings
from esoteric compilers, all of them have value .
Romain
On 6/23/14 3:45 PM, Romain François wrote:
Le 23 juin 2014 à 15:20, cstrato a écrit :
Dear all,
Since many years the following C++ code does compile on ALL
Bioconductor servers (Linux, Windows, Mac) without any warnings:
Int_t numsels = 0; //number of selected entries
...
for (Int_t i=0; i
This is confusing. I
[Rd] Hidden files problem in R CMD check
Dear all, When running R CMD check on my Mac (Yosemite 10.10.5) I get suddenly NOTEs and WARNINGs that my tar.gz file does contain hidden files. However, when checking the corresponding directories with 'ls -al' (or with mc) none of these files does exist!! (with exception .BBSoptions). Here is a partial output of 00check.log: * using log directory '/Volumes/LumiData/CRAN/xps.Rcheck' * using R version 3.2.0 (2015-04-16) * using platform: x86_64-apple-darwin13.4.0 (64-bit) * using session charset: ASCII * checking for file 'xps/DESCRIPTION' ... OK * this is package 'xps' version '1.29.2' * checking package namespace information ... OK * checking package dependencies ... OK * checking if this is a source package ... OK * checking if there is a namespace ... OK * checking for executable files ... OK * checking for hidden files and directories ... NOTE Found the following hidden files and directories: .BBSoptions ._.BBSoptions ._DESCRIPTION ._NAMESPACE ._R ._README ._build ._inst ._man ._src ._vignettes R/._AffyRNAdeg.R R/._Constructors.R R/._TreeSetClasses.R R/._bgcorrect.R R/._dabg.call.R ... man/._AffyRNAdeg.Rd man/._AnalysisTreeSet-class.Rd man/._CallTreeSet-class.Rd man/._DataTreeSet-class.Rd man/._ExprTreeSet-class.Rd ... src/._rwrapper.cxx src/._rwrapper.h src/._xps.def src/._xpsLinkDef.h vignettes/._APTvsXPS.Rnw vignettes/._BoxPlot_BgrdGC_bgrd.png vignettes/._BoxPlot_BgrdMAS5_bgrd.png vignettes/._BoxPlot_BgrdRMA.png ... * checking package subdirectories ... WARNING Subdirectory 'R' contains invalid file names: '._AffyRNAdeg.R' '._Constructors.R' '._TreeSetClasses.R' '._bgcorrect.R' '._dabg.call.R' '._dfw.R' '._export.R' '._express.R' ... Subdirectory 'man' contains invalid file names: '._AffyRNAdeg.Rd' '._AnalysisTreeSet-class.Rd' '._CallTreeSet-class.Rd' '._DataTreeSet-class.Rd' '._ExprTreeSet-class.Rd' '._Filter-class.Rd' ... Does anyone know why these files are listed? For some reason all these hidden files start with '._' My suspicion was that maybe there is something wrong with Spotlight (i.e. mdutil) so I excluded the whole volume from Spotlight. This did not help. Adding the volume again and thus forcing a rebuild for Spotlight did not help either. What could I do to remove these apparently non-existing hidden files? Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hidden files problem in R CMD check
Dear Simon, Thank you very much for your help, it did solve my problems!! Great! I have googled COPYFILE_DISABLE and found the following site which does explain the issue with tar on Mac OS X, see: http://unix.stackexchange.com/questions/9665/create-tar-archive-of-a-directory-except-for-hidden-files Instead of doing: $tar czf xps_1.29.2.tar.gz xps I did now: $COPYFILE_DISABLE=1 tar czf xps_1.29.2.tar.gz xps Running: $R CMD check xps_1.29.2.tar.gz now leaves only '.BBSoptions' as hidden file. However, I must admit that I do not understand it. Since more than ten years I am running the 'tar' command on my Macs (using Leopard, Snow Leopard, Lion and now Yosemite) and running R CMD check did never give these warning messages. Even two weeks ago everything was ok. Could it be that upgrading from OS X 10.10.3 to 10.10.5 did change the behaviour? (However, the link above is already from 2011) Maybe one word regarding the editor I am using: Yes, I am using 'nedit-5.5-Darwin-i386/nedit' which is pretty old, but in my opinion the best and fastest editor I know: - When I open a C++ file containing more than 10,000 lines it opens it immediately with all C++ instructions highlighted immediately (in contrast to emacs) - I can open the huge (>500 MB) Affymetrix annotation files containing more than one million lines in few seconds and scroll fast from beginning to end - It does even have a Language Mode for R I do not believe that 'nedit' does create these hidden files, since it never did. Thank you once again. Best regards, Christian On 09/26/15 21:44, Simon Urbanek wrote: Christian, those are resource forks from your files - possibly maintained by your (likey very old?) editor. First, is seems that you are not creating the tar ball correctly - the correct way is to use R CMD build which should not include resource forks nor files on the ignore list. That said, if for some reason you intend to create is by hand (not recommended), you may want to set COPYFILE_DISABLE=1 so it doesn't include resource forks. Cheers, Simon On Sep 26, 2015, at 3:30 PM, cstrato wrote: Dear all, When running R CMD check on my Mac (Yosemite 10.10.5) I get suddenly NOTEs and WARNINGs that my tar.gz file does contain hidden files. However, when checking the corresponding directories with 'ls -al' (or with mc) none of these files does exist!! (with exception .BBSoptions). Here is a partial output of 00check.log: * using log directory '/Volumes/LumiData/CRAN/xps.Rcheck' * using R version 3.2.0 (2015-04-16) * using platform: x86_64-apple-darwin13.4.0 (64-bit) * using session charset: ASCII * checking for file 'xps/DESCRIPTION' ... OK * this is package 'xps' version '1.29.2' * checking package namespace information ... OK * checking package dependencies ... OK * checking if this is a source package ... OK * checking if there is a namespace ... OK * checking for executable files ... OK * checking for hidden files and directories ... NOTE Found the following hidden files and directories: .BBSoptions ._.BBSoptions ._DESCRIPTION ._NAMESPACE ._R ._README ._build ._inst ._man ._src ._vignettes R/._AffyRNAdeg.R R/._Constructors.R R/._TreeSetClasses.R R/._bgcorrect.R R/._dabg.call.R ... man/._AffyRNAdeg.Rd man/._AnalysisTreeSet-class.Rd man/._CallTreeSet-class.Rd man/._DataTreeSet-class.Rd man/._ExprTreeSet-class.Rd ... src/._rwrapper.cxx src/._rwrapper.h src/._xps.def src/._xpsLinkDef.h vignettes/._APTvsXPS.Rnw vignettes/._BoxPlot_BgrdGC_bgrd.png vignettes/._BoxPlot_BgrdMAS5_bgrd.png vignettes/._BoxPlot_BgrdRMA.png ... * checking package subdirectories ... WARNING Subdirectory 'R' contains invalid file names: '._AffyRNAdeg.R' '._Constructors.R' '._TreeSetClasses.R' '._bgcorrect.R' '._dabg.call.R' '._dfw.R' '._export.R' '._express.R' ... Subdirectory 'man' contains invalid file names: '._AffyRNAdeg.Rd' '._AnalysisTreeSet-class.Rd' '._CallTreeSet-class.Rd' '._DataTreeSet-class.Rd' '._ExprTreeSet-class.Rd' '._Filter-class.Rd' ... Does anyone know why these files are listed? For some reason all these hidden files start with '._' My suspicion was that maybe there is something wrong with Spotlight (i.e. mdutil) so I excluded the whole volume from Spotlight. This did not help. Adding the volume again and thus forcing a rebuild for Spotlight did not help either. What could I do to remove these apparently non-existing hidden files? Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Hidden files problem in R CMD check
Dear Dirk, Yes, I know, however forget for one moment R. If I use tar independent of R it still should not create these hidden files. BTW, do you know where these hidden files are stored on the Mac? Best regards, Christian On 09/26/15 23:01, Dirk Eddelbuettel wrote: On 26 September 2015 at 22:41, cstrato wrote: | Dear Simon, | | Thank you very much for your help, it did solve my problems!! Great! | | I have googled COPYFILE_DISABLE and found the following site which does | explain the issue with tar on Mac OS X, see: | http://unix.stackexchange.com/questions/9665/create-tar-archive-of-a-directory-except-for-hidden-files | | Instead of doing: | $tar czf xps_1.29.2.tar.gz xps | | I did now: | $COPYFILE_DISABLE=1 tar czf xps_1.29.2.tar.gz xps | | Running: | $R CMD check xps_1.29.2.tar.gz | now leaves only '.BBSoptions' as hidden file. No, still wrong. As Simon said, we all are supposed to use 'R CMD build xps' to create the tarball. "Back in the day ..." straight tar cfz ... worked, it more or less stopped _many_ years ago. Cf TheOneManualThatMatters: 1.3.1 Checking packages --- Using 'R CMD check', the R package checker, one can test whether _source_ R packages work correctly. It can be run on one or more directories, or compressed package 'tar' archives with extension '.tar.gz', '.tgz', '.tar.bz2' or '.tar.xz'. It is strongly recommended that the final checks are run on a 'tar' archive prepared by 'R CMD build'. Ie "It is strongly recommended ... 'tar' archive prepared by 'R CMD build'. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hidden files problem in R CMD check
Dear Dirk, Please do not get me wrong. Yes, I am doing it the wrong way and I am doing it since about eight years. Nevertheless I am still allowed to be confused when something suddenly happens which did not happen before during all these years. Doing it correctly will solve the problem, but it will not explain this behavior which suddenly popped up. Best regards, Christian On 09/26/15 23:30, Dirk Eddelbuettel wrote: On 26 September 2015 at 23:06, cstrato wrote: | Dear Dirk, | | Yes, I know, however forget for one moment R. No we can't. Your question was about to make R CMD check happy and 'quiet'. And one answer is to feed it a properly constructed file. | | If I use tar independent of R it still should not create these hidden | files. Hm, I doubt that. We have to tell R explicitly to exclude dotfiles, directories from version control etc pp. Recall the discussion years when .git was added to the already existing .svn? In any event, R is open source so you can check what 'build' does and follow its code into the tools package. | BTW, do you know where these hidden files are stored on the Mac? Pass -- I am too pedestrian for owing one of those machines ;-) Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hidden files problem in R CMD check
Dear Simon, As usual you are not only right but also very helpful. It seems that I did miss your point with '._*' files. Now, when I do 'ls -@l' I get e.g. in directory /R: s$ ls -@l total 1232 -rw-r--r--@ 1 rabbitus staff4691 Apr 10 22:07 AffyRNAdeg.R com.apple.quarantine26 -rw-r--r--@ 1 rabbitus staff3629 Apr 10 22:07 Constructors.R com.apple.quarantine26 -rw-r--r--@ 1 rabbitus staff 26283 Apr 10 22:07 TreeSetClasses.R com.apple.quarantine26 ... Thank you and Best regards, Christian On 09/27/15 03:36, Simon Urbanek wrote: On Sep 26, 2015, at 5:06 PM, cstrato wrote: Dear Dirk, Yes, I know, however forget for one moment R. If I use tar independent of R it still should not create these hidden files. BTW, do you know where these hidden files are stored on the Mac? Please consider reading my original reply - those are not actual files (all but .BBSoptions which is an actual file you can see with ls -a), those are just resource forks of files [or extended attributes in general] -- and Apple tar if instructed to preserve resource forks encodes them as ._* in tar balls since tar has no native way of storing resource forks. And, again, as I said in my reply those likely come from some software you may have used (possibly the editor). For example, some editors store the file encoding in xattr. To list them you can use ls -l@ Cheers, Simon Best regards, Christian On 09/26/15 23:01, Dirk Eddelbuettel wrote: On 26 September 2015 at 22:41, cstrato wrote: | Dear Simon, | | Thank you very much for your help, it did solve my problems!! Great! | | I have googled COPYFILE_DISABLE and found the following site which does | explain the issue with tar on Mac OS X, see: | http://unix.stackexchange.com/questions/9665/create-tar-archive-of-a-directory-except-for-hidden-files | | Instead of doing: | $tar czf xps_1.29.2.tar.gz xps | | I did now: | $COPYFILE_DISABLE=1 tar czf xps_1.29.2.tar.gz xps | | Running: | $R CMD check xps_1.29.2.tar.gz | now leaves only '.BBSoptions' as hidden file. No, still wrong. As Simon said, we all are supposed to use 'R CMD build xps' to create the tarball. "Back in the day ..." straight tar cfz ... worked, it more or less stopped _many_ years ago. Cf TheOneManualThatMatters: 1.3.1 Checking packages --- Using 'R CMD check', the R package checker, one can test whether _source_ R packages work correctly. It can be run on one or more directories, or compressed package 'tar' archives with extension '.tar.gz', '.tgz', '.tar.bz2' or '.tar.xz'. It is strongly recommended that the final checks are run on a 'tar' archive prepared by 'R CMD build'. Ie "It is strongly recommended ... 'tar' archive prepared by 'R CMD build'. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xps installation error on Mac OS X 10.11
Dear Jack,
First, please do not use r-help or r-devel to ask Bioconductor-related
questions, Bioconductor has its own support site for BioC packages:
https://support.bioconductor.org/
Second, please note that ROOT_6.x cannot be used for xps.
In the README file I mention for Yosemite:
ftp://root.cern.ch/root/root_v5.34.30.macosx64-10.10-clang61.tar.gz
However, you can probably also use the newest version:
ftp://root.cern.ch/root/root_v5.34.34.macosx64-10.10-clang61.tar.gz
Before installing ROOT again please make sure to delete all versions of
ROOT that you have already installed.
Best regards,
Christian
On 01/13/16 18:28, Zhu, Jack (NIH/NCI) [E] wrote:
Dear Christian,
Sorry for bothering you, but it looks like I really need your help with
the xps installation on my Mac OS X 10.11 system. I have been
struggling for a few days and tried all the options listed in your
README file:
http://bioconductor.org/packages/devel/bioc/readmes/xps/README
I also read all the online posts related to the xps installation. But
still have problem. By strictly following the instructions, I
re-installed ROOT from both source and binary for Mac OS X 10.11 and
added ROOT environmental variables in my .bashrc (all the four lines).
The ROOT itself seems working totally fine by different tests and the
$ echo $ROOTSYS
/Applications/root_v6.06.00
$ echo $LD_LIBRARY_PATH
/Applications/root_v6.06.00/lib
$ echo $DYLD_LIBRARY_PATH
/Applications/root_v6.06.00
$echo $PATH
/Applications/root_v6.06.00/bin:…
But I always get an error with LD_LIBRARY_PATH when I try to install the
xps package from the source:
---
$R CMD INSTALL -d -l /Users/zhujack/Library/R/3.3/library
xps_1.31.0.tar.gz
found ROOT version 6.06/00 in directory /Applications/root_v6.06.00
xps configuration error:
You must set the shell variable LD_LIBRARY_PATH to the
directory where ROOT resides and re-run R CMD INSTALL
e.g., (using Bourne shell syntax):
export "LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH"
R CMD INSTALL xps
Please consult the README file for more information
ERROR: configuration failed for package ‘xps’
* removing ‘/Users/zhujack/Library/R/3.3/library/xps’
* restoring previous ‘/Users/zhujack/Library/R/3.3/library/xps’
I also tried to add the following line to the /usr/local/bin/R:
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/Applications/root_v6.06.00/lib"
export LD_LIBRARY_PATH
But I still get the same error. Your help and insigts will be greatly
appreciared.
Jack
> sessionInfo()
R Under development (unstable) (2016-01-11 r69918)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.2 (El Capitan)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] BiocInstaller_1.21.2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error when using buildVignettes()
dataset consists of
6 Affymetrix GeneChip arrays of type 'Test3'. \\
This report was generated using function \Rfunction{xpsQAReport} of
package \xps. \\
\section{Summary}
The current quality report for dataset 'My Dataset' displays the most
important quality plots, using the
default settings for most plots. Package \xps\ contains additional
plots which can be used for further
quality assessments. \\
\section*{Session Information:}
<>=
sessionInfo()
@
\end{document}
Can you please tell me why function buildVignettes() of the tools
package is no longer able to convert this file into a pdf-file?
Thank you in advance.
> sessionInfo()
R version 3.0.0 Patched (2013-04-11 r62551)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] C
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] xps_1.21.4
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error when using buildVignettes()
Dear Henrik,
Thank you for your suggestion, however the error was detected by a user
who is already using R 3.0.1, see:
https://www.stat.math.ethz.ch/pipermail/bioconductor/2013-August/054633.html
Best regards,
Christian
On 8/28/13 11:49 PM, Henrik Bengtsson wrote:
sessionInfo()
R version 3.0.0 Patched (2013-04-11 r62551)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
I would check with R 3.0.1 patched and R devel before anything else,
especially when troubleshooting vignette-related issues.
/Henrik
On Wed, Aug 28, 2013 at 12:33 PM, cstrato wrote:
Dear all,
When running function 'testQAReport()', which uses function
'buildVignettes()' to create a pdf-file I get the following error:
source("testQAReport.R")
testQAReport()
Error in .get_package_metadata(pkgdir) :
Files 'DESCRIPTION' and 'DESCRIPTION.in' are missing.
Since I did not get this error in earlier versions of R, could you please
tell me what may be the reason for this error?
Here is the code for "testQAReport.R":
#--#
# testQAReport.R: test quality control report
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
testQAReport <-
function(dataset = "My Dataset",
title = "Quality Report",
date= "October, 2011",
author = "Christian Stratowa",
outdir = file.path(getwd(), "TestQA"),
...)
{
## directory containing parts of QAReport.Rnw
indir <- file.path(path.package("xps"), "QC");
## create directory containing final QAReport.Rnw
if (!dir.create(outdir))
stop("could not create report directory");
if (!dir.create(file.path(outdir, "inst")))
stop("could not create report subdirectory 'inst'");
if (!dir.create(file.path(outdir, "inst", "doc")))
stop("could not create report subdirectory 'doc'");
docdir <- file.path(outdir, "inst", "doc");
QCb <- readLines(file.path(indir, "QC.begin.Rnw"));
## replace title, date, author
QCb <- sub("@TITLE@", title, QCb);
QCb <- sub("@DATE@", date, QCb);
QCb <- sub("@AUTHOR@", author, QCb);
## dataset info
numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
QCb <- sub("@DATASET@", dataset, QCb);
QCb <- sub("@NUMTREES@", numtrees, QCb);
QCb <- sub("@CHIPNAME@", chipname, QCb);
QCb <- sub("@CHIPTYPE@", chiptype, QCb);
write(QCb, file.path(docdir, "QAReport.Rnw"));
QCe <- readLines(file.path(indir, "QC.end.Rnw"));
QCe <- sub("@DATASET@", dataset, QCe);
QCe <- gsub("_","_", QCe);
write(QCe, file.path(docdir, "QAReport.Rnw"), append=TRUE);
## build vignette QC.pdf
if (require(tools)) {
buildVignettes(dir=outdir, lib.loc=NULL, quiet=FALSE, clean=FALSE);
}#if
}#xpsQAReport
#--#
The file "QC.begin.Rnw" is as follows:
\documentclass{article}
\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in
\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}
\begin{document}
\title{@TITLE@}
\date{@DATE@}
\author{@AUTHOR@}
\maketitle
\tableofcontents
\section{Introduction}
This is the quality assessment report for the dataset '@DATASET@'. The
dataset consists of
@NUMTREES@ Affymetrix @CHIPTYPE@ arrays of type '@CHIPNAME@'. \\
This report was generated using function \Rfunction{xpsQAReport} of package
\xps. \\
The file "QC.end.Rnw" is as follows:
\section{Summary}
The current quality report for dataset '@DATASET@' displays the most
important quality plots, using the
default settings for most plots. Package \xps\ contains additional plots
which can be used for further
quality assessments. \\
\section*{Session Information:}
<>=
sessionInfo()
@
\end{document}
Finally, the output which is located in TestQA/inst/doc/QAReport.Rnw is as
follows:
\documentclass{article}
\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in
\newcommand{\Rfuncti
[Rd] Packages not found
Dear all, On the CRAN website http://cran.r-project.org/ it is currently not possible to get to the packages. Clicking on "Packages" or on "Contributed extension packages" results in Error 404: Object not found!, see: http://cran.r-project.org/web/packages/ Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages not found
Dear Uwe and Martin, Thank you for your reply and workaround. Best regards, Christian On 8/29/13 2:56 PM, Martin Maechler wrote: Uwe Ligges on Thu, 29 Aug 2013 14:47:21 +0200 writes: > Thanks, we know, this is work in progress. Uwe Ligges and mirrors still work, e.g., http://cran.CH.r-project.org/web/packages/ --- Martin > On 29.08.2013 14:08, cstrato wrote: >> Dear all, >> >> On the CRAN website http://cran.r-project.org/ it is >> currently not possible to get to the packages. Clicking >> on "Packages" or on "Contributed extension packages" >> results in Error 404: Object not found!, see: >> http://cran.r-project.org/web/packages/ >> >> Best regards, Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error when using buildVignettes()
Dear Henrik,
Thank you for your extensive reply, using:
Sweave("QAReport.Rnw")
tools::texi2pdf("QAReport.tex", clean = TRUE)
did solve my problem.
Nevertheless, I do not understand why function buildVignettes() was
modified in a way that it can no longer be used to create vignettes for
testing purposes w/o a DESCRIPTION file. This is also nowhere mentioned
in the R News file. The only comment is: "If there is a field
BuildVignettes in the package ‘DESCRIPTION’ file with a false value,
re-building the vignettes is skipped." It would be easy to simply use
true as default if there is no DESCRIPTION file is present.
Best regards,
Christian
On 8/29/13 12:58 AM, Henrik Bengtsson wrote:
Ok. ...I've now read your original thread more carefully, and I'd say
that tools::buildVignettes() is intended for building vignettes within
packages, not for compiling vignette files in general. This is most
likely why it complains - it simply looks for files that it expect to
see in a package source tree. FYI, lots of changes were made to these
tools in R 3.0.0, which may explain why you didn't see them before
(not saying it was correct usage before either).
I'd say, use Sweave/Stangle "manually" and then pass it on to tools::texi2pdf().
1. For *.Rnw -> *.tex -> *.pdf, you can use R.rsp::compileRnw() that
does all this in one go with more sanity checks.
2. Instead of using all those sub("@TITLE@", title, ...) coding to
generate the report Rnw from a main Rnw template, add a layer of RSP
markup and run it through the RSP compiler. For instance, with a
template.Rnw.rsp containing:
This is the quality assessment report for the dataset '<%=dataset%>'.
The dataset consists of
<%=numtrees%> Affymetrix <%=chiptype%> arrays of type '<%=chipname%>'.
you can compile it all in one go into a final PDF by pdf <-
R.rsp::rfile("template.Rnw.rsp"). RSP supports <%@include
file="..."%> statements and more if you wish to bring multiple Rnw
templates into a final one. See help("R.rsp") for vignettes etc.
On Wed, Aug 28, 2013 at 3:10 PM, cstrato wrote:
Dear Henrik,
Thank you for your suggestion, however the error was detected by a user who
is already using R 3.0.1, see:
https://www.stat.math.ethz.ch/pipermail/bioconductor/2013-August/054633.html
Best regards,
Christian
On 8/28/13 11:49 PM, Henrik Bengtsson wrote:
sessionInfo()
R version 3.0.0 Patched (2013-04-11 r62551)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
I would check with R 3.0.1 patched and R devel before anything else,
especially when troubleshooting vignette-related issues.
/Henrik
On Wed, Aug 28, 2013 at 12:33 PM, cstrato wrote:
Dear all,
When running function 'testQAReport()', which uses function
'buildVignettes()' to create a pdf-file I get the following error:
source("testQAReport.R")
testQAReport()
Error in .get_package_metadata(pkgdir) :
Files 'DESCRIPTION' and 'DESCRIPTION.in' are missing.
Since I did not get this error in earlier versions of R, could you please
tell me what may be the reason for this error?
Here is the code for "testQAReport.R":
#--#
# testQAReport.R: test quality control report
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
testQAReport <-
function(dataset = "My Dataset",
title = "Quality Report",
date= "October, 2011",
author = "Christian Stratowa",
outdir = file.path(getwd(), "TestQA"),
...)
{
## directory containing parts of QAReport.Rnw
indir <- file.path(path.package("xps"), "QC");
## create directory containing final QAReport.Rnw
if (!dir.create(outdir))
stop("could not create report directory");
if (!dir.create(file.path(outdir, "inst")))
stop("could not create report subdirectory 'inst'");
if (!dir.create(file.path(outdir, "inst", "doc")))
stop("could not create report subdirectory 'doc'");
docdir <- file.path(outdir, "inst", "doc");
QCb <- readLines(file.path(indir, "QC.begin.Rnw"));
## replace title, date, author
QCb <- sub("@TITLE@", title, QCb);
QCb <- sub("@DATE@", date, QCb);
QCb <- sub("@AUTHOR@", author, QCb);
## dataset info
numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
QCb <- sub("@DATASET@", dataset, QCb);
QCb <- sub("@NUMTREES@", numtrees, QCb);
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
Dear Duncan, dear Marc,
Thank you for your fast reply.
Can you please tell me:
If texi2pdf() won't delete files how are the files deleted when the
directory structure is Test/inst/doc/?
Is this done by Sweave()?
Best regards,
Christian
On 8/30/13 9:14 PM, Duncan Murdoch wrote:
On 30/08/2013 3:09 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:00 PM, cstrato wrote:
> Dear all,
>
> To create a *.pdf file from a *.Rnw file I do:
>
> olddir <- getwd();
> setwd(outdir);
>
> tryCatch({Sweave("QAReport.Rnw");
>tools::texi2pdf("QAReport.tex", clean=TRUE)
> },
> finally = setwd(olddir)
> );
>
> This works fine, however 'clean=TRUE' does only work when:
> outdir <- "Test/inst/doc/"
> but does not remove the files *.aux, *.log, *.toc when:
> outdir <- "Test/"
>
> Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
>
> (The help file?texi2pdf does not mention that this structure is
necessary.)
>
> Best regards
> Christian
In the Details section of ?texi2pdf, there is:
"Despite the name, this is used in R to compile LaTeX files,
specifically those generated from vignettes."
Since it is intended specifically for package vignettes, the path
requirement should not be a surprise. :-)
There is no path requirement. Christian was incorrect in his diagnosis.
texi2pdf won't delete files that existed before it was run, whether or
not they were changed during the run. That's likely what Christian was
seeing.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
Dear Henrik,
Thank you for this information, I will try to install the patched version.
Best regards,
Christian
On 8/30/13 10:23 PM, Henrik Bengtsson wrote:
Just checked the SVN logs and the comparison towards file timestamps
have been dropped in R devel and R 3.0.1 SVN r63690 (Aug 25, 2013) and
newer. It is now simply comparing the set of files before and after.
Try with one of those and I'll bet you that clean=TRUE does what it
supposed to.
/Henrik
On Fri, Aug 30, 2013 at 1:05 PM, cstrato wrote:
Dear Henrik,
I am trying to attach the 'QAReport.Rnw' file which I am using on my Mac to
reproduce your problem.
Best regards,
Christian
On 8/30/13 9:50 PM, cstrato wrote:
Dear Henrik,
Thank you for your explanation.
Yes, this behavior is reproducible many times.
When I copy both lines together into R, i.e.
Sweave("QAReport.Rnw")
tools::texi2pdf("QAReport.tex", clean = TRUE)
then the auxiliary files are deleted. However, when I keep the *.tex
file only and run:
tools::texi2pdf("QAReport.tex", clean = TRUE)
then these files are not deleted. I can delete them manually many times
and run texi2pdf() again, they will never be deleted.
I really hope that your patch will be applied, so that it works as
expected with the next Bioconductor release on October.
Best regards,
Christian
On 8/30/13 9:36 PM, Henrik Bengtsson wrote:
On Fri, Aug 30, 2013 at 12:21 PM, cstrato wrote:
Dear Duncan, dear Marc,
Thank you for your fast reply.
Can you please tell me:
If texi2pdf() won't delete files how are the files deleted when the
directory structure is Test/inst/doc/?
Check if what you're observing is reproducible when you run it *many*
times. If not, see my previous reply.
/Henrik
Is this done by Sweave()?
Best regards,
Christian
On 8/30/13 9:14 PM, Duncan Murdoch wrote:
On 30/08/2013 3:09 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:00 PM, cstrato wrote:
Dear all,
To create a *.pdf file from a *.Rnw file I do:
olddir <- getwd();
setwd(outdir);
tryCatch({Sweave("QAReport.Rnw");
tools::texi2pdf("QAReport.tex", clean=TRUE)
},
finally = setwd(olddir)
);
This works fine, however 'clean=TRUE' does only work when:
outdir <- "Test/inst/doc/"
but does not remove the files *.aux, *.log, *.toc when:
outdir <- "Test/"
Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
(The help file?texi2pdf does not mention that this structure is
necessary.)
Best regards
Christian
In the Details section of ?texi2pdf, there is:
"Despite the name, this is used in R to compile LaTeX files,
specifically those generated from vignettes."
Since it is intended specifically for package vignettes, the path
requirement should not be a surprise. :-)
There is no path requirement. Christian was incorrect in his
diagnosis.
texi2pdf won't delete files that existed before it was run, whether or
not they were changed during the run. That's likely what Christian was
seeing.
Duncan Murdoch
__
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] Problem with texi2pdf(..,clean=TRUE)
Dear Henrik,
Below is the 'QAReport.Rnw' file which I use on my Mac to reproduce your
problem. Maybe this will help others to reproduce this problem, too.
Best regards,
Christian
begin QAReport.Rnw
\documentclass{article}
\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in
\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}
\begin{document}
\title{Quality Report}
\date{October, 2011}
\author{Christian Stratowa}
\maketitle
\tableofcontents
\section{Introduction}
This is the quality assessment report for the dataset 'My Dataset'.
The dataset consists of
6 Affymetrix GeneChip arrays of type 'Test3'. \\
This report was generated using function \Rfunction{xpsQAReport} of
package \xps. \\
\section{Summary}
The current quality report for dataset 'My Dataset' displays the most
important quality plots, using the
default settings for most plots. Package \xps\ contains additional
plots which can be used for further
quality assessments. \\
\section*{Session Information:}
<>=
sessionInfo()
@
\end{document}
end QAReport.Rnw
On 8/30/13 9:46 PM, Henrik Bengtsson wrote:
On Fri, Aug 30, 2013 at 12:40 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:20 PM, Henrik Bengtsson wrote:
On Fri, Aug 30, 2013 at 12:14 PM, Duncan Murdoch
wrote:
On 30/08/2013 3:09 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:00 PM, cstrato wrote:
Dear all,
To create a *.pdf file from a *.Rnw file I do:
olddir <- getwd();
setwd(outdir);
tryCatch({Sweave("QAReport.Rnw");
tools::texi2pdf("QAReport.tex", clean=TRUE)
},
finally = setwd(olddir)
);
This works fine, however 'clean=TRUE' does only work when:
outdir <- "Test/inst/doc/"
but does not remove the files *.aux, *.log, *.toc when:
outdir <- "Test/"
Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
(The help file?texi2pdf does not mention that this structure is
necessary.)
Best regards
Christian
In the Details section of ?texi2pdf, there is:
"Despite the name, this is used in R to compile LaTeX files, specifically
those generated from vignettes."
Since it is intended specifically for package vignettes, the path
requirement should not be a surprise. :-)
There is no path requirement. Christian was incorrect in his diagnosis.
texi2pdf won't delete files that existed before it was run, whether or not
they were changed during the run. That's likely what Christian was seeing.
Or, that the cleanup fails if the compilation is too quick, cf.
PR#15394 'texi2dvi(..., clean=TRUE) sometimes too quick for "clean"
(with PATCH)' submitted on July 17, 2013:
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15394
/Henrik
Interesting.
It is late on a Friday, so perhaps I am short on functioning neurons.
If the intent of 'clean = TRUE' is to remove the byproducts of compiling the
.PDF file from the source .TEX file, why not just delete the resultant
aux|log|tex|dvi files that match the basename of the source .TEX file rather
than being dependent upon the time stamp?
I'm quite sure because it is not easy/impossible to predict which the
byproducts are. To catch everything, you'd have to do something
.* and that is certainly not safe.
/Henrik
Is there a reason that I am failing to consider for a need to retain these
files if older than the current time stamp? Perhaps if the compilation requires
multiple cycles of latex processing (eg. the use of longtables, etc.), in which
case, one could run texi2pdf(..., clean = FALSE) some number of times, then a
final texi2pdf(..., clean = TRUE) when done. I actually have my own shell
script that does this when creating Sweave files.
Of course, the help file does have the following for the 'clean' argument:
...May not work on some platforms.
Thanks,
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
Dear Henrik,
Thank you for your explanation.
Yes, this behavior is reproducible many times.
When I copy both lines together into R, i.e.
Sweave("QAReport.Rnw")
tools::texi2pdf("QAReport.tex", clean = TRUE)
then the auxiliary files are deleted. However, when I keep the *.tex
file only and run:
tools::texi2pdf("QAReport.tex", clean = TRUE)
then these files are not deleted. I can delete them manually many times
and run texi2pdf() again, they will never be deleted.
I really hope that your patch will be applied, so that it works as
expected with the next Bioconductor release on October.
Best regards,
Christian
On 8/30/13 9:36 PM, Henrik Bengtsson wrote:
On Fri, Aug 30, 2013 at 12:21 PM, cstrato wrote:
Dear Duncan, dear Marc,
Thank you for your fast reply.
Can you please tell me:
If texi2pdf() won't delete files how are the files deleted when the
directory structure is Test/inst/doc/?
Check if what you're observing is reproducible when you run it *many*
times. If not, see my previous reply.
/Henrik
Is this done by Sweave()?
Best regards,
Christian
On 8/30/13 9:14 PM, Duncan Murdoch wrote:
On 30/08/2013 3:09 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:00 PM, cstrato wrote:
Dear all,
To create a *.pdf file from a *.Rnw file I do:
olddir <- getwd();
setwd(outdir);
tryCatch({Sweave("QAReport.Rnw");
tools::texi2pdf("QAReport.tex", clean=TRUE)
},
finally = setwd(olddir)
);
This works fine, however 'clean=TRUE' does only work when:
outdir <- "Test/inst/doc/"
but does not remove the files *.aux, *.log, *.toc when:
outdir <- "Test/"
Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
(The help file?texi2pdf does not mention that this structure is
necessary.)
Best regards
Christian
In the Details section of ?texi2pdf, there is:
"Despite the name, this is used in R to compile LaTeX files,
specifically those generated from vignettes."
Since it is intended specifically for package vignettes, the path
requirement should not be a surprise. :-)
There is no path requirement. Christian was incorrect in his diagnosis.
texi2pdf won't delete files that existed before it was run, whether or
not they were changed during the run. That's likely what Christian was
seeing.
Duncan Murdoch
__
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] Problem with texi2pdf(..,clean=TRUE)
Dear Henrik,
I am trying to attach the 'QAReport.Rnw' file which I am using on my Mac
to reproduce your problem.
Best regards,
Christian
On 8/30/13 9:50 PM, cstrato wrote:
Dear Henrik,
Thank you for your explanation.
Yes, this behavior is reproducible many times.
When I copy both lines together into R, i.e.
Sweave("QAReport.Rnw")
tools::texi2pdf("QAReport.tex", clean = TRUE)
then the auxiliary files are deleted. However, when I keep the *.tex
file only and run:
tools::texi2pdf("QAReport.tex", clean = TRUE)
then these files are not deleted. I can delete them manually many times
and run texi2pdf() again, they will never be deleted.
I really hope that your patch will be applied, so that it works as
expected with the next Bioconductor release on October.
Best regards,
Christian
On 8/30/13 9:36 PM, Henrik Bengtsson wrote:
On Fri, Aug 30, 2013 at 12:21 PM, cstrato wrote:
Dear Duncan, dear Marc,
Thank you for your fast reply.
Can you please tell me:
If texi2pdf() won't delete files how are the files deleted when the
directory structure is Test/inst/doc/?
Check if what you're observing is reproducible when you run it *many*
times. If not, see my previous reply.
/Henrik
Is this done by Sweave()?
Best regards,
Christian
On 8/30/13 9:14 PM, Duncan Murdoch wrote:
On 30/08/2013 3:09 PM, Marc Schwartz wrote:
On Aug 30, 2013, at 2:00 PM, cstrato wrote:
Dear all,
To create a *.pdf file from a *.Rnw file I do:
olddir <- getwd();
setwd(outdir);
tryCatch({Sweave("QAReport.Rnw");
tools::texi2pdf("QAReport.tex", clean=TRUE)
},
finally = setwd(olddir)
);
This works fine, however 'clean=TRUE' does only work when:
outdir <- "Test/inst/doc/"
but does not remove the files *.aux, *.log, *.toc when:
outdir <- "Test/"
Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
(The help file?texi2pdf does not mention that this structure is
necessary.)
Best regards
Christian
In the Details section of ?texi2pdf, there is:
"Despite the name, this is used in R to compile LaTeX files,
specifically those generated from vignettes."
Since it is intended specifically for package vignettes, the path
requirement should not be a surprise. :-)
There is no path requirement. Christian was incorrect in his
diagnosis.
texi2pdf won't delete files that existed before it was run, whether or
not they were changed during the run. That's likely what Christian was
seeing.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
\documentclass{article}
\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in
\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}
\begin{document}
\title{Quality Report}
\date{October, 2011}
\author{Christian Stratowa}
\maketitle
\tableofcontents
\section{Introduction}
This is the quality assessment report for the dataset 'My Dataset'. The
dataset consists of
6 Affymetrix GeneChip arrays of type 'Test3'. \\
This report was generated using function \Rfunction{xpsQAReport} of package
\xps. \\
\section{Summary}
The current quality report for dataset 'My Dataset' displays the most
important quality plots, using the
default settings for most plots. Package \xps\ contains additional plots which
can be used for further
quality assessments. \\
\section*{Session Information:}
<>=
sessionInfo()
@
\end{document}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with texi2pdf(..,clean=TRUE)
Dear all,
To create a *.pdf file from a *.Rnw file I do:
olddir <- getwd();
setwd(outdir);
tryCatch({Sweave("QAReport.Rnw");
tools::texi2pdf("QAReport.tex", clean=TRUE)
},
finally = setwd(olddir)
);
This works fine, however 'clean=TRUE' does only work when:
outdir <- "Test/inst/doc/"
but does not remove the files *.aux, *.log, *.toc when:
outdir <- "Test/"
Why does function texi2pdf() require the directory structure for
vignettes for the deletion of interim files?
(The help file?texi2pdf does not mention that this structure is necessary.)
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem using ofstream in C++ class in package for MacOS X
Dear all,
I am currently learning how to create R packages using C++ classes.
For this purpose I have written a small package MyClass (which I try
to attach since I do not have access to a website).
MyClass has methods WriteFileC() and WriteFileCpp() which implement
C-style and C++-style writing of a table to a file using FILE or
ofstream respectively, and the corresponding R-functions writeFileC.R
and writeFileCpp.R.
While I can compile and execute my package w/o problems on Fedora Core 4,
I can only execute writeFileC.R on my Intel-MacBook Pro, but not
writeFileCpp.R.
Executing my functions I get the following output:
> library(MyClass)
Welcome to MyClass
> writeFileC("myout_fileC.txt")
[1] "outfile = myout_fileC.txt"
Writing file myout_fileC.txt using C style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileC-
<20> records exported.
---MyClassA::~MyClassA()-
[1] "writeFileC finished"
NULL
> writeFileCpp("myout_fileCpp.txt")
[1] "outfile = myout_fileCpp.txt"
Writing file myout_fileCpp.txt using C++ style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileCpp-
*** caught bus error ***
address 0x6, cause 'non-existent physical address'
Traceback:
1: .C("WriteFileCpp", as.character(outfile), PACKAGE = "MyClass")
2: writeFileCpp("myout_fileCpp.txt")
While I understand, that C++ iostreams are best avoided, since there is
no guarantee that the output will appear in the R console (as mentioned
on page 62 of R-exts.pdf), I do not understand why I cannot use ofstream,
which is isolated in a C++ method only.
Is there a way how to use ofstream on MacOS X or is this a limit of the
current Mac implementation?
Thank you in advance.
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
MyClass_0.1.2.tar.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dirk Eddelbuettel wrote:
> On 4 February 2007 at 20:17, cstrato wrote:
> | I am currently learning how to create R packages using C++ classes.
>
> Congratulations :)
>
> [ This reminds me to email Oleg (CC'ed). Oleg, your HOWTO is a very useful.
> Would you consider adding a section on Dominick's most excellent RcppTemplate
> package which makes writing code to go back and forth between R and C++ s
> much easier? ]
>
> | For this purpose I have written a small package MyClass (which I try
> | to attach since I do not have access to a website).
> [...]
> | While I can compile and execute my package w/o problems on Fedora Core 4,
>
> Works for me too on Debian.
>
> [...]
> | > writeFileCpp("myout_fileCpp.txt")
> | [1] "outfile = myout_fileCpp.txt"
> | Writing file myout_fileCpp.txt using C++ style.
> | ---MyClassA::MyClassA()-
> | ---MyClassA::WriteFileCpp-
> |
> | *** caught bus error ***
> | address 0x6, cause 'non-existent physical address'
> |
> | Traceback:
> | 1: .C("WriteFileCpp", as.character(outfile), PACKAGE = "MyClass")
> | 2: writeFileCpp("myout_fileCpp.txt")
> |
> |
> | While I understand, that C++ iostreams are best avoided, since there is
> | no guarantee that the output will appear in the R console (as mentioned
> | on page 62 of R-exts.pdf), I do not understand why I cannot use ofstream,
> | which is isolated in a C++ method only.
> |
> | Is there a way how to use ofstream on MacOS X or is this a limit of the
> | current Mac implementation?
>
> Can you get to this in a debugger on MacOS X? Just glancing at your code I
> saw nothing obviously sticking out...
>
> Dirk
>
>
Dear Dirk
Thank you for your fast answer.
Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
old-style print commands.
However, here is the output of the crash log from my Mac. Does it help?
**
Host Name: coeurebooks-computer
Date/Time: 2007-02-04 18:51:50.233 +0100
OS Version: 10.4.8 (Build 8N1051)
Report Version: 4
Command: R
Path:/Library/Frameworks/R.framework/Resources/bin/exec/i386/R
Parent: bash [206]
Version: ??? (???)
PID:1836
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0006
Thread 0 Crashed:
0 libstdc++.6.dylib 0x020fe231 std::basic_ostream >::flush() + 17 (ostream.tcc:395)
1 libstdc++.6.dylib 0x020fe358 std::basic_ostream
>::sentry::sentry[in-charge](std::basic_ostream >&) + 120 (ostream.tcc:56)
2 libstdc++.6.dylib 0x02100b5d std::basic_ostream >& std::operator<<
>(std::basic_ostream >&, char const*) + 29
(ostream.tcc:620)
3 MyClass.so0x0004a30f MyClassA::WriteFileCpp(char const*)
+ 335
4 MyClass.so0x0004a6d0 WriteFileCpp + 80
5 libR.dylib0x0106c701 do_dotCode + 7789 (dotcode.c:1732)
6 libR.dylib0x01096a0f Rf_eval + 1530 (eval.c:445)
7 libR.dylib0x01098b43 do_set + 561 (eval.c:1357)
8 libR.dylib0x010968b4 Rf_eval + 1183 (eval.c:431)
9 libR.dylib0x01098be1 do_begin + 62 (eval.c:1108)
10 libR.dylib0x010968b4 Rf_eval + 1183 (eval.c:431)
11 libR.dylib0x01099fd6 Rf_applyClosure + 688 (eval.c:614)
12 libR.dylib0x01096725 Rf_eval + 784 (eval.c:455)
13 libR.dylib0x010b458c Rf_ReplIteration + 396 (main.c:256)
14 libR.dylib0x010b48f3 R_ReplConsole + 148 (main.c:306)
15 libR.dylib0x010b4c30 run_Rmainloop + 91 (main.c:945)
16 libR.dylib0x010b4c4b Rf_mainloop + 16 (main.c:952)
17 R 0x1f64 main + 54 (Rmain.c:35)
18 R 0x1f12 _start + 216
19 R 0x1e39 start + 41
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x0012ebx: 0x0004a1cb ecx: 0x0214f178 edx: 0x
edi: 0xbfffe568esi: 0x0214f178 ebp: 0xbfffe508 esp: 0xbfffe4f0
ss: 0x001fefl: 0x00010286 eip: 0x020fe231 cs: 0x0017
ds: 0x001f es: 0x001f fs: 0x gs: 0x0037
Binary Images Description:
0x1000 - 0x1fff R
/Library/Frameworks/R.framework/Resources/bin/exec/i386/R
0x5000 - 0x6fff libRblas.dylib
/Library/Frameworks/R.framework/Resources/lib/i386/libRblas.dylib
0xa000 -0x11fff libgcc_s.1.0.dylib
/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libgcc_s.1.0.dylib
0x49000 -0x4afff MyClass.so
/Users/rabbitus/Library/R/library/MyClass/libs/i386/MyClass.so
0x53000 -0x70fff libreadline.5.1.dylib
/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libreadline.5.1.dylib
0x582000 - 0x5c libgfortran.0.dylib
/Library/Frameworks/R.framework/Versions/
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dirk Eddelbuettel wrote: > On 4 February 2007 at 21:20, cstrato wrote: > | Thank you for your fast answer. > | Sorrowly, I don´t know how to use a debugger on MacOS X, I am using > | old-style print commands. > | However, here is the output of the crash log from my Mac. Does it help? > > Not me. I barely know what Mac OS X is, and never used it myself. You may > need to talk to the r-sig-mac folks. If everything else fails, Simon tends to > come up with answers no matter how hard or esoteric the question :) > > Dirk > > Thank you. I have seen that Mac-questions get also answered on this mailing list, so maybe someone has an answer? BTW, I forgot to mention that I downloaded the R-2.4.1.dmg binary since I wanted to create a package for the current version. So I don´t know if the problem disappears when using the new developer version. Is the problem 2.4.1-specific only? Best regards Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Seth Falcon wrote:
> cstrato <[EMAIL PROTECTED]> writes:
>
>> Thank you for your fast answer.
>> Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
>> old-style print commands.
>>
>
> You should be able to use gdb on OS X (works for me, YMMV). So you
> could try:
>
> R -d gdb
> run
> # source a script that causes crash
> # back in gdb, use backtrace, etc.
>
> + seth
>
>
>
Dear Seth
Thank you for this tip, I just tried it and here is the result:
Welcome to MyClass
> writeFileCpp("myout_fileCpp.txt")
[1] "outfile = myout_fileCpp.txt"
Writing file myout_fileCpp.txt using C++ style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileCpp-
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0006
0x020fe231 in std::ostream::flush (this=0x214f178) at
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:395
395
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:
No such file or directory.
in
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc
(gdb)
It seems that it cannot find ostream.tcc, whatever this extension means.
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dear Jochen
Thank you, there seems to be a problem with accessing memory but
probably not in my simple program.
Here are the essential parts:
1. R-function:
"writeFileCpp" <-
function(outfile=character(0)) {
r <- .C("WriteFileCpp",as.character(outfile), PACKAGE="MyClass");
return();
}
2. R-wrapper:
void WriteFileCpp(char **outfile)
{
MyClassA *classA = new MyClassA();
classA->WriteFileCpp(outfile[0]);
delete classA;
}
3. C++ method:
void MyClassA::WriteFileCpp(const char *outfile)
{
ofstream output(outfile, ios::out);
output << 21 << endl;
output.close();
}
This crashes with "non-existent physical address"
Interestingly, the following C++ method works:
void MyClassA::WriteFileCpp(const char *outfile)
{
ofstream output(outfile, ios::out);
// output << 21 << endl;
output.close();
}
This means, that the operator "<<" seems to cause the problem, but why?
Best regards
Christian
Jochen Laubrock wrote:
> Hi cstrato,
>
>
> On 04.02.2007, at 22:47, cstrato wrote:
>
>> ostream.tcc
>>
>
>
> On my system (Mac OS X), ostream.tcc seems to be just a part of the
> FSF/GNU implementation of the stl, as
>
> head -n 40 /usr/include/c++/4.0.0/bits/ostream.tcc
>
> gives
>
>> // This file is part of the GNU ISO C++ Library. This library is free
>> // software; you can redistribute it and/or modify it under the
>> [...]
>> /** @file ostream.tcc
>> * This is an internal header file, included by other library headers.
>> * You should not attempt to use it directly.
>> */
>>
>> //
>> // ISO C++ 14882: 27.6.2 Output streams
>
>
> I think your error looks more like you are accessing invalid memory,
> maybe a dangling pointer ?
>
> hth, jochen
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Ross Boylan wrote:
> On Sun, Feb 04, 2007 at 10:47:37PM +0100, cstrato wrote:
>
>> Seth Falcon wrote:
>>
>>> cstrato <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>> Thank you for your fast answer.
>>>> Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
>>>> old-style print commands.
>>>>
>>>>
>>> You should be able to use gdb on OS X (works for me, YMMV). So you
>>> could try:
>>>
>>> R -d gdb
>>> run
>>> # source a script that causes crash
>>> # back in gdb, use backtrace, etc.
>>>
>>> + seth
>>>
>>>
>>>
>>>
>> Dear Seth
>>
>> Thank you for this tip, I just tried it and here is the result:
>>
>> Welcome to MyClass
>> > writeFileCpp("myout_fileCpp.txt")
>> [1] "outfile = myout_fileCpp.txt"
>> Writing file myout_fileCpp.txt using C++ style.
>> ---MyClassA::MyClassA()-
>> ---MyClassA::WriteFileCpp-
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x0006
>> 0x020fe231 in std::ostream::flush (this=0x214f178) at
>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:395
>> 395
>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:
>> No such file or directory.
>> in
>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc
>> (gdb)
>>
>> It seems that it cannot find ostream.tcc, whatever this extension means.
>>
>> Best regards
>> Christian
>>
>
> I also don't see what the problem is, but have a couple of thoughts.
> Under OS-X there is an environment variable you can define to get the
> dynamic linker to load debug versions of libraries. I can't remember
> what it is, but maybe something like DYLD_DEBUG (but probably DEBUG is
> part of the value of the variable).
>
> For that, or the tracing above, to be fully informative you need to
> have installed the appropriate debugging libraries and sources.
>
> You may need to set an explicit source search path in gdb to pick up
> the source files.
>
> Try stepping through the code from write before the crash to determine
> exactly where it runs into trouble.
>
> Does the output file you are trying to create exist?
>
> Unfortunately, none of this really gets at your core bug, but it might
> help track it down.
>
> Ross
>
>
>
Dear Ross
Thank you, my problem is that I know exactly where the problem is but
not how to solve it.
I have installed R-2.4.1 on three different machines to test the package:
- Intel-Laptop running Fedora Core 4: package is OK
- PPC-PowerBook Titanium OS X 10.4.4: package is OK
- Intel-MacBook Pro Core 2 Duo OS X 10.4.8: C output OK, C++ output
crashes R
The following code in method WriteFileCpp() works, but gives no result:
{
std::ofstream output(outfile);
output.close();
}
The following code in method WriteFileCpp() crashes R:
{
std::ofstream output(outfile);
output << "21" << endl;
output.close();
}
It seems that on the Intel-MacBook Pro the operator "<<" is not
recognized, when called
from within my package in R.
In contrast, when compiled as a C++ library, the same code does work on
my Intel-Mac!
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Ross Boylan wrote:
> On Thu, Feb 08, 2007 at 10:04:14PM +0100, cstrato wrote:
>
>> Ross Boylan wrote:
>>
>>> On Sun, Feb 04, 2007 at 10:47:37PM +0100, cstrato wrote:
>>>
>>>
>>>> Seth Falcon wrote:
>>>>
>>>>
>>>>> cstrato <[EMAIL PROTECTED]> writes:
>>>>>
>>>>>
>>>>>
>>>>>> Thank you for your fast answer.
>>>>>> Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
>>>>>> old-style print commands.
>>>>>>
>>>>>>
>>>>>>
>>>>> You should be able to use gdb on OS X (works for me, YMMV). So you
>>>>> could try:
>>>>>
>>>>> R -d gdb
>>>>> run
>>>>> # source a script that causes crash
>>>>> # back in gdb, use backtrace, etc.
>>>>>
>>>>> + seth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Dear Seth
>>>>
>>>> Thank you for this tip, I just tried it and here is the result:
>>>>
>>>> Welcome to MyClass
>>>>
>>>>> writeFileCpp("myout_fileCpp.txt")
>>>>>
>>>> [1] "outfile = myout_fileCpp.txt"
>>>> Writing file myout_fileCpp.txt using C++ style.
>>>> ---MyClassA::MyClassA()-
>>>> ---MyClassA::WriteFileCpp-
>>>>
>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0006
>>>> 0x020fe231 in std::ostream::flush (this=0x214f178) at
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:395
>>>> 395
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:
>>>>
>>>> No such file or directory.
>>>>in
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc
>>>> (gdb)
>>>>
>>>> It seems that it cannot find ostream.tcc, whatever this extension means.
>>>>
>>>> Best regards
>>>> Christian
>>>>
>>>>
>>> I also don't see what the problem is, but have a couple of thoughts.
>>> Under OS-X there is an environment variable you can define to get the
>>> dynamic linker to load debug versions of libraries. I can't remember
>>> what it is, but maybe something like DYLD_DEBUG (but probably DEBUG is
>>> part of the value of the variable).
>>>
>>> For that, or the tracing above, to be fully informative you need to
>>> have installed the appropriate debugging libraries and sources.
>>>
>>> You may need to set an explicit source search path in gdb to pick up
>>> the source files.
>>>
>>> Try stepping through the code from write before the crash to determine
>>> exactly where it runs into trouble.
>>>
>>> Does the output file you are trying to create exist?
>>>
>>> Unfortunately, none of this really gets at your core bug, but it might
>>> help track it down.
>>>
>>> Ross
>>>
>>>
>>>
>>>
>> Dear Ross
>>
>> Thank you, my problem is that I know exactly where the problem is but
>> not how to solve it.
>>
>> I have installed R-2.4.1 on three different machines to test the package:
>> - Intel-Laptop running Fedora Core 4: package is OK
>> - PPC-PowerBook Titanium OS X 10.4.4: package is OK
>> - Intel-MacBook Pro Core 2 Duo OS X 10.4.8: C output OK, C++ output
>> crashes R
>>
>> The following code in method WriteFileCpp() works, but gives no result:
>> {
>> std::ofstream output(outfile);
>> output.close();
>> }
>>
>> The following code in method WriteFileCpp() crashes R:
>> {
>> std::ofstream output(outfile);
>> output << "21" << endl;
>> output.close();
>> }
>>
>> It seems that on the Intel-MacBook Pro the operator "<<" is not
>> recognized, when called from within my package in R.
>> In contrast, when compiled as a C++ library, the same code does work on
>> my Intel-Mac!
>>
>> Best regards
>> Ch
[Rd] Problem using ofstream in C++ class in package for MacOS X
Dear Ross Thank you for this clarification, maybe there is something misconfigured on my Intel-Mac. BTW, I have now upgraded to XCode 2.4.1 from 2.4, but the result remains the same. I don´t know if this could help clarify what might be wrong, but I am not able to compile plier, a simple package containing an R-wrapper around Affymetrix C++ plier code. This is the output I get when trying to compile plier: m3450p027:/Volumes/CoreData/CRAN/Bioconductor/packages rabbitus$ R_ARCH=/i386 R CMD INSTALL -l ~/Library/R/library plier_1.4.0.tar.gz * Installing *source* package 'plier' ... ** libs ** arch - i386 g++-4.0 -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -msse3 -fPIC -g -O2 -march=nocona -c affyplier.cpp -o affyplier.o /Volumes/CoreData/temp/cc3VRxb1.s:4750:indirect jmp without `*' /Volumes/CoreData/temp/cc3VRxb1.s:4769:indirect jmp without `*' /Volumes/CoreData/temp/cc3VRxb1.s:4784:indirect jmp without `*' /Volumes/CoreData/temp/cc3VRxb1.s:4799:indirect jmp without `*' /Volumes/CoreData/temp/cc3VRxb1.s:4818:indirect jmp without `*' /Volumes/CoreData/temp/cc3VRxb1.s:4833:indirect jmp without `*' g++-4.0 -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -msse3 -fPIC -g -O2 -march=nocona -c plier_impl.cpp -o plier_impl.o /Volumes/CoreData/temp/ccLq6FYI.s:554:indirect jmp without `*' /Volumes/CoreData/temp/ccLq6FYI.s:569:indirect jmp without `*' /Volumes/CoreData/temp/ccLq6FYI.s:584:indirect jmp without `*' /Volumes/CoreData/temp/ccLq6FYI.s:599:indirect jmp without `*' /Volumes/CoreData/temp/ccLq6FYI.s:618:indirect jmp without `*' g++-4.0 -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -msse3 -fPIC -g -O2 -march=nocona -c plieralg.cpp -o plieralg.o plieralg.cpp:30:20: error: malloc.h: No such file or directory make: *** [plieralg.o] Error 1 chmod: /Users/rabbitus/Library/R/library/plier/libs/i386/*: No such file or directory ** arch - ppc g++-4.0 -arch ppc -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/ppc -I/usr/local/include-fPIC -g -O2 -c affyplier.cpp -o affyplier.o g++-4.0 -arch ppc -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/ppc -I/usr/local/include-fPIC -g -O2 -c plier_impl.cpp -o plier_impl.o g++-4.0 -arch ppc -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/ppc -I/usr/local/include-fPIC -g -O2 -c plieralg.cpp -o plieralg.o plieralg.cpp:30:20: error: malloc.h: No such file or directory make: *** [plieralg.o] Error 1 chmod: /Users/rabbitus/Library/R/library/plier/libs/ppc/*: No such file or directory ERROR: compilation failed for package 'plier' ** Removing '/Users/rabbitus/Library/R/library/plier In any case, the problem seems to be R-specific, since the same code for my package MyClass runs fine, when compiled as a shared library and called from other C++ code. BTW, since I do not have an url, I would like to attach my package, so that people could try it. In my initial mailing I have attached my package as MyClass_0.1.2.tar.gz, but it got scrambled as https://stat.ethz.ch/pipermail/r-devel/attachments/20070204/2e7fb79c/attachment.gz Is there a possibility to attach it in a way so that people can use it? Thank you Best regards Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dear Kasper Thank you, but I want to keep the focus on my own problem (I can indeed compile your package). Since I do not have an url, I would like to attach my package, so that people could try it. In my initial mailing I have attached my package as MyClass_0.1.2.tar.gz, but it got scrambled as https://stat.ethz.ch/pipermail/r-devel/attachments/20070204/2e7fb79c/attachment.gz Is there a possibility to attach it in a way so that people can use it? Thank you Best regards Christian Kasper Daniel Hansen wrote: > I have some experience wrapping code from Affymetrix in R (see the > affxparser package). Depending on who actually wrote the package, you > may find that it is not trivial to get it to work on different > platforms. They are not always carefully to think about different > compilers etc. > > You may want to look at the plier package in Bioconductor to who they > do it. > > Of course this may or may not be related to your other C++ problems. > > Kasper > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem using callNextMethod() in S4
Dear all,
Maybe, I am doing something wrong, but using R-2.5.0 on my Intel-Mac, I
have problems
using function callNextMethod() in method initialize.
I am loading the following code as file "testS4.R":
setClass("baseClass",
representation(myname = "character",
mydir = "character",
"VIRTUAL"),
prototype(myname = "",
mydir = "")
)#baseClass
setClass("derivedClass",
representation(mytitle = "character"),
contains=c("baseClass"),
prototype(mytitle = "")
)#derivedClass
setMethod("initialize", "baseClass",
function(.Object, ...) {
print("---initialize:baseClass---")
#.Object <- callNextMethod();
if ([EMAIL PROTECTED] == "") {
[EMAIL PROTECTED] <- as.character(getwd());
}#if
print(paste("mydir = ", [EMAIL PROTECTED]))
.Object <- callNextMethod();
.Object;
}
)#initialize
setValidity("baseClass",
function(object) {
print("---setValidity:baseClass---")
strg <- [EMAIL PROTECTED];
if (!(is(strg, "character") && nchar(strg) > 0)) {
warning(paste(sQuote("myname"), "is missing"));
}#if
print(paste("myname = ",[EMAIL PROTECTED]))
strg <- [EMAIL PROTECTED];
if (!(is(strg, "character") && file.exists(strg))) {
warning(paste(sQuote("mydir"), "is not a system directory"));
}#if
if (substr(strg, nchar(strg), nchar(strg)) == "/") {
[EMAIL PROTECTED] <- substr(strg, 0, nchar(strg)-1);
}#if
print(paste("mydir = ",[EMAIL PROTECTED]))
}
)#setValidity
setMethod("initialize", "derivedClass",
function(.Object, ...) {
print("---initialize:derivedClass---")
#.Object <- callNextMethod();
if ([EMAIL PROTECTED] == "") {
[EMAIL PROTECTED] = "MyTitle";
}#if
print(paste("mytitle = ",[EMAIL PROTECTED]))
#.Object <- callNextMethod();
.Object;
}
)#initialize
setValidity("derivedClass",
function(object) {
print("---setValidity:derivedClass---")
strg <- [EMAIL PROTECTED];
if (!(is(strg, "character") && nchar(strg) > 0)) {
warning(paste(sQuote("mytitle"), "is missing"));
}#if
print(paste("mytitle = ",[EMAIL PROTECTED]))
}
)#setValidity
This is the output of an R session:
> library(methods)
> source("testS4.R")
> tmp<-new("derivedClass")
[1] "---initialize:derivedClass---"
[1] "mytitle = MyTitle"
[1] "---initialize:baseClass---"
[1] "mydir = /Volumes/CoreData/CRAN/Workspaces/tests"
>
> tmp<-new("derivedClass",myname="testname",mytitle="testitle")
[1] "---initialize:derivedClass---"
[1] "mytitle = MyTitle"
[1] "---initialize:baseClass---"
[1] "mydir = /Volumes/CoreData/CRAN/Workspaces/tests"
[1] "---setValidity:baseClass---"
[1] "myname = testname"
[1] "mydir = /Volumes/CoreData/CRAN/Workspaces/tests"
Error in validObject(.Object) : invalid class "derivedClass" object:
mydir = /Volumes/CoreData/CRAN/Workspaces/tests
>
> tmp<-new("derivedClass",myname="testname",mydir="",mytitle="testitle")
[1] "---initialize:derivedClass---"
[1] "mytitle = MyTitle"
[1] "---initialize:baseClass---"
[1] "mydir = /Volumes/CoreData/CRAN/Workspaces/tests"
[1] "---setValidity:baseClass---"
[1] "myname = testname"
[1] "mydir = "
Error in validObject(.Object) : invalid class "derivedClass" object:
mydir =
In addition: Warning message:
'mydir' is not a system directory in: validityMethod(as(object,
superClass))
>
Can someone tell me why mydir gives an error although it is defined
correctly?
Thank you in advance
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using callNextMethod() in S4
Dear Seth
Thank you for your comments. Please see my comments and at the end my
corrected code and output.
Sorrowly, the problem remains the same.
Seth Falcon wrote:
> cstrato <[EMAIL PROTECTED]> writes:
>
>
>> Dear all,
>>
>> Maybe, I am doing something wrong, but using R-2.5.0 on my Intel-Mac, I
>> have problems
>> using function callNextMethod() in method initialize.
>>
>> I am loading the following code as file "testS4.R":
>>
>
> I don't think this is the code in the same state as that which you ran
> the examples. Did you add/remove some comment lines perhaps?
>
> After copy/pasting the code you posted, I get:
>
> > tmp<-new("derivedClass")
> [1] "---initialize:derivedClass---"
> [1] "mytitle = MyTitle"
> > tmp<-new("derivedClass",myname="testname",mytitle="testitle")
> [1] "---initialize:derivedClass---"
> [1] "mytitle = MyTitle"
>
>
I am sorry, you are correct, I have commented out ".Object <-
callNextMethod()" in method
initialize for derivedClass afterwards.
>> setValidity("baseClass",
>>function(object) {
>> print("---setValidity:baseClass---")
>> strg <- [EMAIL PROTECTED];
>> if (!(is(strg, "character") && nchar(strg) > 0)) {
>> warning(paste(sQuote("myname"), "is missing"));
>> }#if
>> print(paste("myname = ",[EMAIL PROTECTED]))
>> strg <- [EMAIL PROTECTED];
>> if (!(is(strg, "character") && file.exists(strg))) {
>> warning(paste(sQuote("mydir"), "is not a system directory"));
>> }#if
>> if (substr(strg, nchar(strg), nchar(strg)) == "/") {
>> [EMAIL PROTECTED] <- substr(strg, 0, nchar(strg)-1);
>> }#if
>> print(paste("mydir = ",[EMAIL PROTECTED]))
>>}
>> )#setValidity
>>
>
> Your validity function isn't valid :-P It should either return TRUE or
> return a character vector describing what isn't valid about the
> object. Don't call warning() or print().
>
Please see my corrected code where I use "validMsg()" from BioBase.
> Also, you don't need those ';'
>
> And finally, you are operating on a _copy_ in the validity method
> (just like everywhere else) and so this
>
>
>> if (substr(strg, nchar(strg), nchar(strg)) == "/") {
>> [EMAIL PROTECTED] <- substr(strg, 0, nchar(strg)-1);
>> }#if
>>
>
> will not have any effect on the instance passed in. It is an odd
> thing to do in a validity method.
>
You are right, I moved this code to method "initialize".
> + seth
>
>
Here is my new code "testS4.R" (as used in the output):
setClass("baseClass",
representation(myname = "character",
mydir = "character",
"VIRTUAL"),
prototype(myname = "",
mydir = "")
)#baseClass
setClass("derivedClass",
representation(mytitle = "character"),
contains=c("baseClass"),
prototype(mytitle = "")
)#derivedClass
# taken from package BioBase: tools.R
validMsg <- function(msg, result) {
if (is.character(result)) {
append(msg, result);
} else {
msg;
}#if
}
setMethod("initialize", "baseClass",
function(.Object, ...) {
print("---initialize:baseClass---")
#.Object <- callNextMethod();
strg <- [EMAIL PROTECTED];
print(paste("base:strg = ", strg))
if (strg == "") {
[EMAIL PROTECTED] <- as.character(getwd());
}#if
if (substr(strg, nchar(strg), nchar(strg)) == "/") {
[EMAIL PROTECTED] <- substr(strg, 0, nchar(strg)-1);
}#if
print(paste("base:mydir = ", [EMAIL PROTECTED]))
.Object <- callNextMethod();
.Object;
}
)#initialize
setValidity("baseClass",
function(object) {
print("---setValidity:baseClass---")
msg <- NULL;
strg <- [EMAIL PROTECTED];
if (!(is(strg, "character") && nchar(strg) > 0)) {
msg <- validMsg(msg, paste(sQuote("myname"), "is missing"));
}#if
print(paste("base:myname = ",[EMAIL PROTECTED]))
strg <- [EMAIL PROTECTED];
if (!(is(strg, "character") && file.exists(strg))) {
msg <- validMsg(msg, paste(sQuote("mydir"), "is not a s
Re: [Rd] Problem using callNextMethod() in S4
Dear Martin
Thank you for this extensive explanation!
I hope that I have understood it, but I will realize it as I proceed with my
package. Now, my example works as I have expected it to work, great!
One problem that I face is lack of extensive explanation of S4 classes,
especially with respect to inheritance. (Neither the tutorial "S4 Classes
in 15 pages" nor the book "S Programming" are really helpful.) Most
of the time I study the code in BioBase and affy, since there are not
many packages available using S4 and inheritance.
Your explanation below is a good example, how a good S4 tutorial
should cover these issues.
Best regards
Christian
Martin Morgan wrote:
> In this method...
>
> setMethod("initialize", "baseClass",
>function(.Object, ...) {
> print("---initialize:baseClass---")
> #.Object <- callNextMethod();
> strg <- [EMAIL PROTECTED];
> print(paste("base:strg = ", strg))
> if (strg == "") {
> [EMAIL PROTECTED] <- as.character(getwd());
> }#if
> if (substr(strg, nchar(strg), nchar(strg)) == "/") {
> [EMAIL PROTECTED] <- substr(strg, 0, nchar(strg)-1);
> }#if
> print(paste("base:mydir = ", [EMAIL PROTECTED]))
> .Object <- callNextMethod();
> .Object;
>}
> )#initialize
>
> the argument '...' includes the argument mydir="". Later, when you
> .Object <- callNextMethod(), it invokes the 'next' method with the
> same argument, i.e., with mydir="". This causes the 'mydir' slot to be
> initialized with "", triggering the validity error. You can see this
> more clearly in the following, where the provided argument x=10:1
> overrides the assignment in initialize:
>
>
>> setClass("A", representation=representation(x="numeric"))
>>
> [1] "A"
>
>> setMethod("initialize", "A",
>>
> + function(.Object, ...) {
> + [EMAIL PROTECTED] <- 1:10
> + callNextMethod()
> + })
> [1] "initialize"
>
>
>> new("A", x=10:1)
>>
> An object of class "A"
> Slot "x":
> [1] 10 9 8 7 6 5 4 3 2 1
>
> One solution is to name any arguments you're going to manipulate in
> the initialize method, and then make sure the correct arguments are
> passed to callNextMethod. You'll probably want to provide a sensible
> default argument to mydir, so that user doesn't have to do anything
> clever (like remember to pass "") to get the default behavior. Here's
> what I end up with:
>
> setMethod("initialize", "baseClass",
> function(.Object, mydir=as.character(getwd()), ...) {
> if (substr(mydir, nchar(mydir), nchar(mydir)) == "/") {
> mydir <- substr(mydir, 0, nchar(mydir)-1)
> }
> callNextMethod(.Object, mydir=mydir, ...);
> })
>
> setMethod("initialize", "derivedClass",
> function(.Object, mytitle="MyTitle", ...) {
> callNextMethod(.Object, mytitle=mytitle, ...)
> })
>
> Another solution is to follow the convention where callNextMethod()
> comes first (constructing a valid object!), and your initialize method
> then fills in slots with the appropriate values.
>
> One interesting part of your example is that new('derivedClass') does
> NOT cause a validity error, even though the object is invalid
> ('myname' is ""; also, none of your validity method messages are
> printed)! Apparently, the assumption is that you (the programmer, as
> opposed to the user) are not going to create an invalid object by
> default.
>
> Also, take a look at the initialize method that R has constructed for
> derivedClass:
>
>
>> getMethod("initialize", "derivedClass")
>>
> Method Definition:
>
> function (.Object, ...)
> {
> .local <- function (.Object, mytitle = "MyTitle", ...)
> {
> callNextMethod(.Object, mytitle = mytitle, ...)
> }
> .local(.Object, ...)
> }
>
> Signatures:
> .Object
> target "derivedClass"
> defined "derivedClass"
>
> Notice how the function is defined in terms of .Object and The
> named arguments not present in the generic signature (i.e., 'mytitle')
> are 'hidden' in the .local function definition. By the time
> callNextMethod() has been evaluated, '...' does NOT include
> 'mytitle'. I think this is why you must explicitly include any named
> arguments you want to pass to callNextMethod -- the default is to
> callNextMethod with the generic signature, but with symbols (.Object,
> ...) taking their current value. Here's a simpler illustration:
>
> setClass("A", representation=representation(x="numeric"))
> setMethod("initialize", "A",
> function(.Object, x, ...) callNextMethod())
>
> This leads to the perhaps unexpected outcome
>
>
>> new("A", x=10:1)
>>
> An object of class "A"
> Slot "x":
> numeric(0)
>
> I say unexpected because, if there was no initialize method, or if the
> initialize method were written without 'x' in the signature, then the
> argument 'x' would be used to fill the slot:x.
>
> Here's the soluti
[Rd] Inherited S4 methods
Dear all, Recently, there was a question to use the same method for more than one class: https://stat.ethz.ch/pipermail/r-devel/2007-March/044809.html I have a variation of this question: Is it possible to use the same function name, e.g. "myfunction" in both, an S4 baseClass and derivedClass. The method "myfunction" in derivedCalss should extend the functionality defined in baseClass, analogously to C++ methods. If this is possible, does there exist an example? Best regards Christian _._._._._._._._._._._._._._._._ C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a _._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inherited S4 methods
Dear Seth
Thank you, maybe I still do not understand S4 methods.
I thought that the purpose of function "callNextMethod()" is to allow
some kind of inheritance. In the Bioconuductor packages which are
using S4, it is only used for method("initialize") but I thought, that
it can be used with every method "mymethod()", is this correct?
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with package containing S4 classes
Dear all,
Currently, I am trying to create a test package "testS4" using S4 classes,
which I am attaching.
Running R CMD check gives the following error:
coeurebooks-computer:/Volumes/CoreData/CRAN cs$ R CMD check
testS4_0.1.1.tar.gz
* checking for working latex ...sh: line 1: latex: command not found
NO
* using log directory '/Volumes/CoreData/CRAN/testS4.Rcheck'
* using R version 2.5.0 Under development (unstable) (2007-02-26 r40806)
* checking for file 'testS4/DESCRIPTION' ... OK
* this is package 'testS4' version '0.1.1'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'testS4' can be installed ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... ERROR
Error in library.dynam(lib, package, package.lib) :
shared library 'testS4' not found
Error: package/namespace load failed for 'testS4'
Execution halted
Can someone explain what this error means?
What is meant with "shared library"?
For another test package I get the following error
coeurebooks-computer:/Volumes/CoreData/CRAN cs$ R CMD INSTALL -l
~/Library/R/library mytest_0.3.2.tar.gz
* Installing *source* package 'mytest' ...
** R
** save image
Error in setMethod("export", "derivedClass", export.derivedClass) :
no existing definition for function "export"
Error: unable to load R code in package 'mytest'
Execution halted
This error is even more strange since I cannot reproduce it in the
attached package.
What may be the reason for this error?
Thank you in advance.
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
testS4_0.1.1.tar.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with package containing S4 classes
Dear Benilton
Thank you, now my package works.
Do you have an explanation for my second problem:
* Installing *source* package 'mytest' ...
** R
** save image
Error in setMethod("export", "derivedClass", export.derivedClass) :
no existing definition for function "export"
Error: unable to load R code in package 'mytest'
Execution halted
What may be the reason for this error?
Best regards
Christian
Benilton Carvalho wrote:
> your namespace probably contains:
>
> useDynLib(testS4)
>
> but you don't have any compiled code...
>
> remove that line and everything will be fine.
>
> btw, if you're playing with S4, you must import 'methods'
>
> b
>
> On Mar 16, 2007, at 4:55 PM, cstrato wrote:
>
>> Dear all,
>>
>> Currently, I am trying to create a test package "testS4" using S4
>> classes,
>> which I am attaching.
>>
>> Running R CMD check gives the following error:
>>
>> coeurebooks-computer:/Volumes/CoreData/CRAN cs$ R CMD check
>> testS4_0.1.1.tar.gz
>> * checking for working latex ...sh: line 1: latex: command not found
>> NO
>> * using log directory '/Volumes/CoreData/CRAN/testS4.Rcheck'
>> * using R version 2.5.0 Under development (unstable) (2007-02-26 r40806)
>> * checking for file 'testS4/DESCRIPTION' ... OK
>> * this is package 'testS4' version '0.1.1'
>> * checking package dependencies ... OK
>> * checking if this is a source package ... OK
>> * checking whether package 'testS4' can be installed ... OK
>> * checking package directory ... OK
>> * checking for portable file names ... OK
>> * checking for sufficient/correct file permissions ... OK
>> * checking DESCRIPTION meta-information ... OK
>> * checking top-level files ... OK
>> * checking index information ... OK
>> * checking package subdirectories ... OK
>> * checking R files for non-ASCII characters ... OK
>> * checking R files for syntax errors ... OK
>> * checking whether the package can be loaded ... ERROR
>> Error in library.dynam(lib, package, package.lib) :
>>shared library 'testS4' not found
>> Error: package/namespace load failed for 'testS4'
>> Execution halted
>>
>> Can someone explain what this error means?
>> What is meant with "shared library"?
>>
>> For another test package I get the following error
>> coeurebooks-computer:/Volumes/CoreData/CRAN cs$ R CMD INSTALL -l
>> ~/Library/R/library mytest_0.3.2.tar.gz
>> * Installing *source* package 'mytest' ...
>> ** R
>> ** save image
>> Error in setMethod("export", "derivedClass", export.derivedClass) :
>>no existing definition for function "export"
>> Error: unable to load R code in package 'mytest'
>> Execution halted
>>
>> This error is even more strange since I cannot reproduce it in the
>> attached package.
>> What may be the reason for this error?
>>
>> Thank you in advance.
>> Best regards
>> Christian
>> _._._._._._._._._._._._._._._._
>> C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
>> V.i.e.n.n.a A.u.s.t.r.i.a
>> _._._._._._._._._._._._._._._._
>>
>>
>> __
>> 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] Inherited S4 methods
Dear Seth Thank you, I will further explain this feature. Best regards Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with package containing S4 classes
Dear Benilton
Yes, but the error disappears only when I define it twice.
For my package I create three files:
1. MyClasses.R:
Here I define the classes only using
setClass("baseClass")
setClass("derivedClass")
2. methods.baseClass.R
Here I define the methods for baseClass
setGeneric("export", function(object,...) standardGeneric("export"))
setMethod("export", "baseClass", export.baseClass);
3. methods.derivedClass.R
Here I define the methods for derivedClass
setGeneric("export", function(object,...) standardGeneric("export"))
setMethod("export", "derivedClass", export.derivedClass);
As you see, I need to define setGeneric twice, otherwise I get the error.
It is not clear to me, why this is the case?
I know, that BioBase has a file AllGeneric.R, but I would like to define
the generics in the respective methods files.
Best regards
Christian
Benilton Carvalho wrote:
> do you have a generic for 'export'?
>
> On Mar 16, 2007, at 5:38 PM, cstrato wrote:
>
>> Dear Benilton
>>
>> Thank you, now my package works.
>>
>> Do you have an explanation for my second problem:
>>
>> * Installing *source* package 'mytest' ...
>> ** R
>> ** save image
>> Error in setMethod("export", "derivedClass", export.derivedClass) :
>>no existing definition for function "export"
>> Error: unable to load R code in package 'mytest'
>> Execution halted
>>
>> What may be the reason for this error?
>>
>> Best regards
>> Christian
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with package containing S4 classes
I agree, but I hope that "AllGeneric.R" is not the only possibility.
BTW, what is a collate field?
Best regards
Christian
Benilton Carvalho wrote:
> Well, my understanding is that if you "need" to define it (the
> generic) twice you're doing something wrong.
>
> Do you have a collate field in your description file? IMHO, the
> "AllGeneric.R"/"AllClasses.R" approach is the way to go... keeping
> your code organized is always a good thing, right?
>
> b
>
> On Mar 16, 2007, at 6:35 PM, cstrato wrote:
>
>> Dear Benilton
>>
>> Yes, but the error disappears only when I define it twice.
>>
>> For my package I create three files:
>>
>> 1. MyClasses.R:
>> Here I define the classes only using
>> setClass("baseClass")
>> setClass("derivedClass")
>>
>> 2. methods.baseClass.R
>> Here I define the methods for baseClass
>> setGeneric("export", function(object,...) standardGeneric("export"))
>> setMethod("export", "baseClass", export.baseClass);
>>
>> 3. methods.derivedClass.R
>> Here I define the methods for derivedClass
>> setGeneric("export", function(object,...) standardGeneric("export"))
>> setMethod("export", "derivedClass", export.derivedClass);
>>
>> As you see, I need to define setGeneric twice, otherwise I get the
>> error.
>> It is not clear to me, why this is the case?
>>
>> I know, that BioBase has a file AllGeneric.R, but I would like to define
>> the generics in the respective methods files.
>>
>> Best regards
>> Christian
>>
>> Benilton Carvalho wrote:
>>> do you have a generic for 'export'?
>>>
>>> On Mar 16, 2007, at 5:38 PM, cstrato wrote:
>>>
>>>> Dear Benilton
>>>>
>>>> Thank you, now my package works.
>>>>
>>>> Do you have an explanation for my second problem:
>>>>
>>>> * Installing *source* package 'mytest' ...
>>>> ** R
>>>> ** save image
>>>> Error in setMethod("export", "derivedClass", export.derivedClass) :
>>>>no existing definition for function "export"
>>>> Error: unable to load R code in package 'mytest'
>>>> Execution halted
>>>>
>>>> What may be the reason for this error?
>>>>
>>>> Best regards
>>>> Christian
>>>>
>>>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with package containing S4 classes
Thank you, I have already read the R-exts manual, but the collate field is optional. Do you know a package which uses the Collate field so that I can study it? Best regards Christian Benilton Carvalho wrote: > The Collate field gives the order that the files are going to be > concatenated. If they're concatenated using the "wrong" order, your > installation might fail (for example, the generic is defined after the > method). > > A recommended source is the "Writing R Extensions" > > http://cran.r-project.org/doc/manuals/R-exts.html > > Session 1.1.1 - The Description File (Writing R Extensions) > > says exactly what you shohuld know about the Collate field (and not > only that). > > b > > On Mar 16, 2007, at 7:01 PM, cstrato wrote: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with package containing S4 classes
I must have missed this, thank you. Good night Christian Benilton Carvalho wrote: > Biobase itself does. > b > > On Mar 16, 2007, at 7:43 PM, cstrato wrote: > >> Thank you, I have already read the R-exts manual, but the collate >> field is optional. >> Do you know a package which uses the Collate field so that I can >> study it? >> >> Best regards >> Christian >> >> Benilton Carvalho wrote: >>> The Collate field gives the order that the files are going to be >>> concatenated. If they're concatenated using the "wrong" order, your >>> installation might fail (for example, the generic is defined after >>> the method). >>> >>> A recommended source is the "Writing R Extensions" >>> >>> http://cran.r-project.org/doc/manuals/R-exts.html >>> >>> Session 1.1.1 - The Description File (Writing R Extensions) >>> >>> says exactly what you shohuld know about the Collate field (and not >>> only that). >>> >>> b >>> >>> On Mar 16, 2007, at 7:01 PM, cstrato wrote: > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] how to use debug.mypkg
Dear all,
The package "affy" has the following statement in file "AffyBatch.R":
if (debug.affy123) cat("-->initAffyBatch\n")
This is great and I would also like to use it. However, when I run my
package
I get the following error:
Error in .local(object, ...) : object "debug.mypkg" not found
Since I am not able to find the position where "affy" defines
"debug.affy123"
my question is: where do I need to define "debug.mypkg"?
Thank you in advance
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to use debug.mypkg
Yes, I know, but somewhere in my package I need to define this flag.
When I set the flag "debug.mypkg<-T" in the R session, everything works,
but the problem is that if I do not set it, it is undefined. So I need
to set it
initially in my package, but where?
Christian
Benilton Carvalho wrote:
> debug.affy123 is not a function... it's just a logical flag set in
> ProgressBarText.R.
>
> b
>
> On Mar 22, 2007, at 6:22 PM, cstrato wrote:
>
>> Dear all,
>>
>> The package "affy" has the following statement in file "AffyBatch.R":
>> if (debug.affy123) cat("-->initAffyBatch\n")
>>
>> This is great and I would also like to use it. However, when I run my
>> package
>> I get the following error:
>> Error in .local(object, ...) : object "debug.mypkg" not found
>>
>> Since I am not able to find the position where "affy" defines
>> "debug.affy123"
>> my question is: where do I need to define "debug.mypkg"?
>>
>> Thank you in advance
>> Best regards
>> Christian
>> _._._._._._._._._._._._._._._._
>> C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
>> V.i.e.n.n.a A.u.s.t.r.i.a
>> _._._._._._._._._._._._._._._._
>>
>> __
>> 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] how to use debug.mypkg
Thank you all for your suggestions, I have implemented the OPTIONS "option", since it allows to define other options, too. Yes, I use now the Collate field, since it gives me the possibility to organize my files in the way I want. Best regards Christian Benilton Carvalho wrote: > it doesn't matter where.. > > just pick one of your files and set it... > > of course, your file should be listed in the Collate field (in case > you changed your mind and are now using it). > > b > > On Mar 22, 2007, at 6:52 PM, cstrato wrote: > >> Yes, I know, but somewhere in my package I need to define this flag. >> When I set the flag "debug.mypkg<-T" in the R session, everything works, >> but the problem is that if I do not set it, it is undefined. So I >> need to set it >> initially in my package, but where? >> >> Christian >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Limitation of dirname() and basename()
Dear all,
I have already twice encountered a case which I consider a limitation of
dirname() and basename().
In my functions I have a parameter "outfile" which e.g. tells where a file
should be stored. Usually "outfile" is of the form:
oufile = "/my/path/myname.txt"
> outfile <- "/my/path/myname.txt"
> dirname(outfile)
[1] "/my/path"
> basename(outfile)
[1] "myname.txt"
However, in addition I want to be able to define the path only, while
creating the name "myname.txt" automatically.
Sorrowly, I get the following:
> outfile <- "/my/path/"
> dirname(outfile)
[1] "/my"
> basename(outfile)
[1] "path"
It would be great if dirname() and basename() could recognize:
dirname("/my/path/") = /my/path/
basename(""/my/path/") = ""
i.e. they should be able to recognize a trailing "/".
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Limitation of dirname() and basename()
1. I did read the help file.
2. I have my own workaround, using e.g.
file.info("/my/path/")[,"isdir"]
3. This was a suggestion.
4. If you agree with me that "/my/path/" is a path, then both
"dirname()" and "dirname" give an incorrect answer.
5. Maybe, you can give me a logical reason (besides a
historical reason) why this should be the way it is.
Prof Brian Ripley wrote:
> These functions work as they should: did you not read the help page
> which explicitly tells you what happens in this case?
>
> The Unix originals work in the same way:
>
> gannet% dirname /my/path/
> /my
>
> Please DO study the R posting guide and do the homework requesting of
> you before posting.
>
> On Mon, 26 Mar 2007, cstrato wrote:
>
>> Dear all,
>>
>> I have already twice encountered a case which I consider a limitation of
>> dirname() and basename().
>>
>> In my functions I have a parameter "outfile" which e.g. tells where a
>> file
>> should be stored. Usually "outfile" is of the form:
>> oufile = "/my/path/myname.txt"
>>
>> > outfile <- "/my/path/myname.txt"
>> > dirname(outfile)
>> [1] "/my/path"
>> > basename(outfile)
>> [1] "myname.txt"
>>
>> However, in addition I want to be able to define the path only, while
>> creating the name "myname.txt" automatically.
>> Sorrowly, I get the following:
>>
>> > outfile <- "/my/path/"
>> > dirname(outfile)
>> [1] "/my"
>> > basename(outfile)
>> [1] "path"
>>
>> It would be great if dirname() and basename() could recognize:
>> dirname("/my/path/") = /my/path/
>> basename(""/my/path/") = ""
>> i.e. they should be able to recognize a trailing "/".
>
> Not according to the documentation.
>
>>
>> Best regards
>> Christian
>> _._._._._._._._._._._._._._._._
>> C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
>> V.i.e.n.n.a A.u.s.t.r.i.a
>> _._._._._._._._._._._._._._._._
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Limitation of dirname() and basename()
Hin-Tak Leung wrote:
> cstrato wrote:
>> 1. I did read the help file.
>> 2. I have my own workaround, using e.g.
>> file.info("/my/path/")[,"isdir"]
>> 3. This was a suggestion.
>> 4. If you agree with me that "/my/path/" is a path, then both
>>"dirname()" and "dirname" give an incorrect answer.
>> 5. Maybe, you can give me a logical reason (besides a
>>historical reason) why this should be the way it is.
>
> Can you just read "man 3 dirname" and "man 1 dirname" on any unix box?
> Isn't "historical reason" - this is how dirname works for the last
> 25(?) years, some people will be *very* upset if it behaves
> differently now -
> a good enough reason?
>
> HTL
A 25 year old mistake is no reason for R to duplicate this mistake.
>
>> Prof Brian Ripley wrote:
>>> These functions work as they should: did you not read the help page
>>> which explicitly tells you what happens in this case?
>>>
>>> The Unix originals work in the same way:
>>>
>>> gannet% dirname /my/path/
>>> /my
>>>
>>> Please DO study the R posting guide and do the homework requesting
>>> of you before posting.
>>>
>>> On Mon, 26 Mar 2007, cstrato wrote:
>>>
>>>> Dear all,
>>>>
>>>> I have already twice encountered a case which I consider a
>>>> limitation of
>>>> dirname() and basename().
>>>>
>>>> In my functions I have a parameter "outfile" which e.g. tells where
>>>> a file
>>>> should be stored. Usually "outfile" is of the form:
>>>> oufile = "/my/path/myname.txt"
>>>>
>>>>> outfile <- "/my/path/myname.txt"
>>>>> dirname(outfile)
>>>> [1] "/my/path"
>>>>> basename(outfile)
>>>> [1] "myname.txt"
>>>>
>>>> However, in addition I want to be able to define the path only, while
>>>> creating the name "myname.txt" automatically.
>>>> Sorrowly, I get the following:
>>>>
>>>>> outfile <- "/my/path/"
>>>>> dirname(outfile)
>>>> [1] "/my"
>>>>> basename(outfile)
>>>> [1] "path"
>>>>
>>>> It would be great if dirname() and basename() could recognize:
>>>> dirname("/my/path/") = /my/path/
>>>> basename(""/my/path/") = ""
>>>> i.e. they should be able to recognize a trailing "/".
>>> Not according to the documentation.
>>>
>>>> Best regards
>>>> Christian
>>>> _._._._._._._._._._._._._._._._
>>>> C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
>>>> V.i.e.n.n.a A.u.s.t.r.i.a
>>>> _._._._._._._._._._._._._._._._
>>
>> __
>> 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] Limitation of dirname() and basename()
Gabor Grothendieck wrote:
> On 3/27/07, cstrato <[EMAIL PROTECTED]> wrote:
>> Hin-Tak Leung wrote:
>> > cstrato wrote:
>> >> 1. I did read the help file.
>> >> 2. I have my own workaround, using e.g.
>> >> file.info("/my/path/")[,"isdir"]
>> >> 3. This was a suggestion.
>> >> 4. If you agree with me that "/my/path/" is a path, then both
>> >>"dirname()" and "dirname" give an incorrect answer.
>> >> 5. Maybe, you can give me a logical reason (besides a
>> >>historical reason) why this should be the way it is.
>> >
>> > Can you just read "man 3 dirname" and "man 1 dirname" on any unix box?
>> > Isn't "historical reason" - this is how dirname works for the last
>> > 25(?) years, some people will be *very* upset if it behaves
>> > differently now -
>> > a good enough reason?
>> >
>> > HTL
>> A 25 year old mistake is no reason for R to duplicate this mistake.
>> >
>
> It would be possible to have the way it works controlled by an argument
> if backward compatibility is the issue:
> e.g.
>
> dirname("/my/path/", extended = TRUE)
>
> or it would be possible to have a second command:
>
> dirname2("/my/path/")
>
>
Thank you, I like your first suggestion very much, it is very elegant.
(dirname2() is also a possibility but not so elegant.)
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Limitation of dirname() and basename()
Simon Urbanek wrote:
>
> On Mar 27, 2007, at 2:49 PM, cstrato wrote:
>
>> Hin-Tak Leung wrote:
>>> cstrato wrote:
>>>> 1. I did read the help file.
>>>> 2. I have my own workaround, using e.g.
>>>> file.info("/my/path/")[,"isdir"]
>>>> 3. This was a suggestion.
>>>> 4. If you agree with me that "/my/path/" is a path, then both
>>>>"dirname()" and "dirname" give an incorrect answer.
>>>> 5. Maybe, you can give me a logical reason (besides a
>>>>historical reason) why this should be the way it is.
>>>
>>> Can you just read "man 3 dirname" and "man 1 dirname" on any unix box?
>>> Isn't "historical reason" - this is how dirname works for the last
>>> 25(?) years, some people will be *very* upset if it behaves
>>> differently now -
>>> a good enough reason?
>>>
>>> HTL
>> A 25 year old mistake is no reason for R to duplicate this mistake.
>
>
> Please read the corresponding docs before posting such nonsense
> (especially the Rationale section):
> http://www.opengroup.org/onlinepubs/95399/utilities/basename.html
>
> Your proposed behavior is inconsistent, anyway. The purpose of dirname
> is to return parent directory of the entity represented by the
> pathname. "/my/path" and "/my/path/" are equivalent as they both
> represent the directory "path" whose parent is "/my", therefore
> returning "/my/path" in either case is inconsistent with the purpose
> of this function. As of trailing slashes (independently of dirname),
> sadly, some programs exploit the equivalence of both representations
> by encoding meta-information in the representation, but this behavior
> is quite confusing and error-prone. You're free to add such special
> cases to your application, but there is no reason to add such
> confusion to R.
>
> Cheers,
> Simon
>
Your explanation of dirname returning the "parent" directory sounds
reasonable, however, none of the documents mentions this.
Maybe, I do not understand the documents correctly, nevertheless I have
to accept this behavior.
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Limitation of dirname() and basename(): file.name() and file.dir() ?
I am glad to hear that there seems to be some commitment for improvement,
although I must admit, that I did not realize that both functions do not
check
if a name is a directory or a filename, even though the definition in "The
Open Group Base Specifications" says:
dirname - return the directory portion of a pathname
basename - return non-directory portion of a pathname
Using basename() and dirname() I tried to define functions, which show
what I wanted to do:
file.name <- function(fullname, name.exists=T) {
isdir <- file.info(fullname)[,"isdir"]
if (is.na(isdir)) return(ifelse (name.exists, NA, basename(fullname)))
ifelse (isdir, "", basename(fullname))
}
file.dir <-function(fullname, name.exists=T) {
isdir <- file.info(fullname)[,"isdir"]
if (is.na(isdir)) return(ifelse (name.exists, NA,
file.dir(dirname(fullname
path.expand(ifelse (isdir, fullname, dirname(fullname)))
}
Here are some examples:
> file.name("/net/home/stratowa/Diverses/tmp.txt")
[1] "tmp.txt"
> file.name("/net/home/stratowa/Diverses/")
[1] ""
> file.name("/net/home/stratowa/Diverses")
[1] ""
> file.dir("/net/home/stratowa/Diverses/tmp.txt")
[1] "/net/home/stratowa/Diverses"
> file.dir("/net/home/stratowa/Diverses/")
[1] "/net/home/stratowa/Diverses/"
> file.dir("/net/home/stratowa/Diverses")
[1] "/net/home/stratowa/Diverses"
To get the filename part for a novel filename, I can set "name.exists=F".
I think, that it would be really helpful, if R could add these (or similar)
functions to the base package, but this is my personal opinion.
Best regards
Christian
Simon Urbanek wrote:
>
> On Mar 27, 2007, at 5:42 PM, Herve Pages wrote:
>
>> Simon Urbanek wrote:
>>> Your proposed behavior is inconsistent, anyway. The purpose of
>>> dirname is to return parent directory of the entity represented by
>>> the pathname.
>>
>> Mmmm, I don't think this is true:
>>
>>> dirname("aaa/..")
>> [1] "aaa"
>>
>> "aaa" is not the parent directory of "aaa/.."
>>
>> Same here:
>>
>>> dirname("/usr/./.")
>> [1] "/usr/."
>>
>
> Yes, the problem is that most dirname implementations don't
> canonicalize the path - they are working on the string representation
> and don't use the underlying FS. I wasn't saying that dirname is
> perfect, in fact I refrained from commenting on this earlier exactly
> because of the behavior you describe, but the decision to remove
> trailing slashes was a deliberate as can be seen from the specs.
> Semantically correct behavior (taking the definition of the dirname
> function literally) would be dirname "/usr/." = "/", basename "/usr/."
> = "usr". However, I suspect that not many people would expect this ;).
> As was proposed earlier, one could think of "true" dirname" or perhaps
> better "parentdir" function, although admittedly I don't see an issue
> here ...
>
> Cheers,
> Simon
>
>
>
>>
>>> "/my/path" and "/my/path/" are equivalent as they both
>>> represent the directory "path" whose parent is "/my", therefore
>>> returning "/my/path" in either case is inconsistent with the purpose
>>> of this function. As of trailing slashes (independently of dirname),
>>> sadly, some programs exploit the equivalence of both representations
>>> by encoding meta-information in the representation, but this behavior
>>> is quite confusing and error-prone. You're free to add such special
>>> cases to your application, but there is no reason to add such
>>> confusion to R.
>>
>> Note that Python's designers were not afraid to emancipate from Unix for
>> this particular case:
>>
> import os.path
> os.path.dirname("aaa/..")
>> 'aaa'
> os.path.dirname("aaa/../")
>> 'aaa/..'
>>
>>
>> Also note that, if the goal was to mimic Unix behaviour, then why not
>> fully go for it, even for edge-cases:
>>
>> R
>>
>>> dirname("/")
>> [1] "/"
>>> basename("/")
>> [1] ""
>>
>> Unix
>>
>> [EMAIL PROTECTED]:~> dirname "/"
>> /
>> [EMAIL PROTECTED]:~> basename "/"
>> /
>>
>> Just my 2 cents...
>>
>> Cheers,
>> H.
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Replacing slot of S4 class in method of S4 class?
Dear all,
Assume that I have an S4 class "MyClass" with a slot "myname", which
is initialized to: myname="" in method("initialize"):
myclass <- new("MyClass", myname="")
Assume that class "MyClass" has a method "mymethod":
"mymethod.MyClass" <-
function(object, myname=character(0), ...) {
[EMAIL PROTECTED] <- myname;
#or:myName(object) <- myname
}
setMethod("mymethod", "MyClass", mymethod.MyClass);
Furthermore, I have a replacement method:
setReplaceMethod("myName", signature(object="MyClass", value="character"),
function(object, value) {
[EMAIL PROTECTED] <- value;
return(object);
}
)
I know that it is possible to call:
myName(myclass) <- "newname"
However, I want to replace the value of slot "myname" for object "myclass"
in method "mymethod":
mymethod(myclass, myname="newname")
Sorrowly, the above code in method "mymethod" does not work.
Is there a possibility to change the value of a slot in the method of a
class?
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Replacing slot of S4 class in method of S4 class?
Dear Ross
Thank you for your explanation, now mymethod works (Simon gave me
already a hint).
Regarding the use of this list, I am confused. Which of my former questions
regarding S4 classes belong to this list:
https://stat.ethz.ch/pipermail/r-devel/2007-March/044840.html
https://stat.ethz.ch/pipermail/r-devel/2007-March/044918.html
https://stat.ethz.ch/pipermail/r-devel/2007-March/044937.html
Since I am trying to develop a package for Bioconductor, should I use the
Bioconductor development list instead?
Best regards
Christian
Ross Boylan wrote:
> On Fri, Mar 30, 2007 at 10:45:38PM +0200, cstrato wrote:
>
>> Dear all,
>>
>> Assume that I have an S4 class "MyClass" with a slot "myname", which
>> is initialized to: myname="" in method("initialize"):
>>myclass <- new("MyClass", myname="")
>>
>> Assume that class "MyClass" has a method "mymethod":
>>"mymethod.MyClass" <-
>>function(object, myname=character(0), ...) {
>>[EMAIL PROTECTED] <- myname;
>>#or:myName(object) <- myname
>>}
>>setMethod("mymethod", "MyClass", mymethod.MyClass);
>>
>> Furthermore, I have a replacement method:
>> setReplaceMethod("myName", signature(object="MyClass", value="character"),
>>function(object, value) {
>> [EMAIL PROTECTED] <- value;
>> return(object);
>>}
>> )
>>
>> I know that it is possible to call:
>>myName(myclass) <- "newname"
>>
>> However, I want to replace the value of slot "myname" for object "myclass"
>> in method "mymethod":
>>mymethod(myclass, myname="newname")
>>
>> Sorrowly, the above code in method "mymethod" does not work.
>>
>> Is there a possibility to change the value of a slot in the method of a
>> class?
>>
>
> Yes, but to make the effect persistent (visible might be a more
> accurate description) that method must return the
> object being updated, and you must use the return value. R uses call
> by value semantics, so in the definition of mymethod.MyClass when you
> change object you only change a local copy. It needs to be
> "mymethod.MyClass" <-
> function(object, myname=character(0), ...) {
> [EMAIL PROTECTED] <- myname;
> object
> }
>
> Further, if you invoke it with
> mymethod(myclass, "new name")
> you will discover myclass is unchanged. You need
> myclass <- mymethod(myclass, "new name")
>
> You might consider using the R.oo package, which probably has
> semantics closer to what you're expecting. Alternately, you could
> study more about R and functional programming.
>
> Ross Boylan
>
> P.S. Regarding the follow up saying that this is the wrong list, the
> guide to mailing lists says of R-devel
> "This list is intended for questions and discussion about code
> development in R. Questions likely to prompt discussion unintelligible
> to non-programmers or topics that are too technical for R-help's
> audience should go to R-devel,"
> The question seems to fall under this description to me, though I am
> not authoritative. It is true that further study would have disclosed
> what is going on. Since the same thing tripped me up too, I thought
> I'd share the answer.
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear all,
To explain my problem I am attaching a demonstration package "myclasspkg":
I have the following two S4 classes with similar inheritance:
SubSubClassA <- SubClassB <- BaseClass
SubSubClassB <- SubClassB <- BaseClass
In R I am calling the following functions:
> library(myclasspkg)
> subA <-
new("SubClassA",filename="OutSubA",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",mytitle="TitleSubA")
> subsubA <-
new("SubSubClassA",filename="MyFileName",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
> subsubB <-
new("SubSubClassB",filename="MyFileNameB",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
Creating subsubA works fine and gives the correct result:
> subsubA <-
new("SubSubClassA",filename="MyFileName",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassA--"
[1] "SubSubClassA:init:class(.Object) = SubSubClassA"
[1] "--initialize:SubClassB--"
[1] "SubClassB:init:class(.Object) = SubSubClassA"
[1] "--initialize:BaseClass--"
[1] "BaseClass:init:class(.Object) = SubSubClassA"
[1] "--pathFile--"
[1] "BaseClass:init:dirfile =
/Volumes/CoreData/CRAN/Workspaces/rclasspkg/MyFileName"
[1] "--setValidity:BaseClass--"
[1] "BaseClass:val:class(object) = SubClassB"
[1] "BaseClass:val:dirfile =
/Volumes/CoreData/CRAN/Workspaces/rclasspkg/MyFileName"
[1] "BaseClass:val:filedir = /Volumes/CoreData/CRAN/Workspaces/rclasspkg"
[1] "--setValidity:SubClassB--"
[1] "SubClassB:val:class(object) = SubClassB"
[1] "SubClassB:val:filename = MyFileName"
[1] "BaseClass:val:dirfile =
/Volumes/CoreData/CRAN/Workspaces/rclasspkg/MyFileName"
[1] "--setValidity:SubSubClassA--"
[1] "SubSubClassA:val:class(.Object) = SubSubClassA"
In contrast, when trying to create subsubB, it seems that setValidity
re-initializes SubClassB:
> subsubB <-
new("SubSubClassB",filename="MyFileNameB",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassB--"
[1] "SubSubClassB:init:class(.Object) = SubSubClassB"
[1] "SubSubClassB:init:subsubnameB = subsubNameB"
[1] "--initialize:SubClassB--"
[1] "SubClassB:init:class(.Object) = SubSubClassB"
[1] "--initialize:BaseClass--"
[1] "BaseClass:init:class(.Object) = SubSubClassB"
[1] "--pathFile--"
[1] "BaseClass:init:dirfile =
/Volumes/CoreData/CRAN/Workspaces/rclasspkg/MyFileNameB"
[1] "--setValidity:BaseClass--"
[1] "--initialize:SubClassB--"
[1] "SubClassB:init:class(.Object) = SubClassB"
[1] "--initialize:BaseClass--"
[1] "BaseClass:init:class(.Object) = SubClassB"
[1] "--pathFile--"
Error in if (dirname(filename) != ".") { :
argument is of length zero
Can someone tell me why the first case works fine, but the second case not?
Probably, I am making some mistake, but since two weeks I am unable to
find it.
Thank you in advance.
P.S.: I am running R-2.5.0 on Intel-Mac OS 10.4.8.
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
myclasspkg_0.1.1.tar.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear S4 experts,
Since I was reminded that I posted a similar question some time ago,
I am attaching a modified version of my demo package, which allows me
to track what happens during initialization of the following similar
subclasses:
SubSubClassA <- SubClassB <- BaseClass
SubSubClassB <- SubClassB <- BaseClass
First, I need to create SubClassA:
> library(myclasspkg)
> subA <-
new("SubClassA",filename="OutSubA",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",mytitle="TitleSubA")
Then, I create both subclasses, SubSubClassA and SubSubClassB, either
with a virtual BaseClass or with a non-virtual BaseClass:
1. new("SubSubClassA"): BaseClass is VIRTUAL
> subsubA <-
new("SubSubClassA",filename="MyFileName",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassA--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassB--"
[1] "--setValidity:SubSubClassA--"
As far as I understand the S4 classes, this is the correct initialization
workflow that I expect. The resulting object "subsubA" is correct.
However, when BaseClass is not virtual, I get the following unexpected
initialization workflow:
2. new("SubSubClassA"): BaseClass is NOT VIRTUAL
> subsubA <-
new("SubSubClassA",filename="MyFileName",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassA--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--" (called but NOT executed!)
[1] "--initialize:BaseClass--" (2.initialization, why?)
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassB--"
[1] "--setValidity:SubSubClassA--"
The first call to setValidity is not executed, and BaseClass is
initialized twice, the second time in a completely wrong way, which
normally results in an error. Interestingly, the resulting object
"subsubA" is still correct.
The results are completely different for SubSubClassB:
3. new("SubSubClassB"): BaseClass is VIRTUAL
> subsubB <-
new("SubSubClassB",filename="MyFileNameB",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassB--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--initialize:SubClassA--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassA--"
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassB--"
Error in validObject(.Object) : invalid class "SubClassB" object:
'filename' is missing
For some unknown reason SubClassA is initialized and BaseClass is
initialized three times. SetValidity is called until an error occurs.
Things get more weird when BaseClass is not virtal:
4. new("SubSubClassB"): BaseClass is NOT VIRTUAL
> subsubB <-
new("SubSubClassB",filename="MyFileNameB",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassB--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
[1] "--initialize:SubClassA--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassA--"
[1] "--setValidity:BaseClass--"
[1] "--initialize:BaseClass--"
[1] "--setValidity:BaseClass--"
[1] "--setValidity:SubClassB--"
Error in validObject(.Object) : invalid class "SubClassB" object:
'filename' is missing
It seems that initialization occurs in an endless cycle until an
error occurs.
Finally, let us look what happens when I follow the usual convention
where callNextMethod() is called first:
5. new("SubSubClassA"): callNextMethod() as 1.command; BaseClass is VIRTUAL
> subsubA <-
new("SubSubClassA",filename="MyFileName",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassA--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
The object "subsubA" is created correctly, however, setValidity()
is never called.
The same is true for SubSubClassB:
6. new("SubSubClassB"): callNextMethod() as 1.command; BaseClass is VIRTUAL
> subsubB <-
new("SubSubClassB",filename="MyFileNameB",filedir="/Volumes/CoreData/CRAN/Workspaces/rclasspkg",subA=subA)
[1] "--initialize:SubSubClassB--"
[1] "--initialize:SubClassB--"
[1] "--initialize:BaseClass--"
The object "subsubB" is for the first time created correctly, however,
once again setValidity() is never called.
Maybe, I a
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear Herve
Thank you for your helpful comments, and I especially appreciate that
you tried to run my package. I will try to answer each point separately.
Herve Pages wrote:
Hi Christian,
I can only give you a few reasons why IMO it is very unlikely that anybody
will be able to help you on this, with the current form of your post.
1) Unless you have a really good reason to do so, don't attach a package
to your post. Do your best to provide a few lines of code that anybody
can easily copy and paste into their session.
Sorrowly, sometimes, a few lines of code are not sufficient to show
the problem. Furthermore, most of the time there are complaints that
people do not provide enough information, an issue I wanted to avoid.
At the end of my answer I provide now the minimal necessary code for
people to easily copy-paste into their session.
Nevertheless, I also attach the same code as package, since some
problems only appear when compiling the package, concretely:
The behavior of the attached package is completely different, when
I "exportMethods("initialize")" in the NAMESPACE file or not. To see
the changes, please comment-out this one line in the NAMESPACE file.
2) Your package is messy (yes I looked at it). You have far too many classes
with far too many slots that we don't care about. If you could provide
the smallest possible set of classes with the smallest possible set of slots
with the smallest possible set of generics and methods that still allow to
reproduce the issue you want to show us, that would help!
You are correct, I wanted to provide a complete demo-package. As
mentioned above, I provide now the minimal necessary code (at least
I hope so).
3) You show us an example where BaseClass is VIRTUAL (which is indeed how it is
defined in your package) and then an example where BaseClass is NOT VIRTUAL.
How can we reproduce the latter? Don't expect people to go into your package,
change the class definition, reinstall, restart R and then run your example!
I thought, it would be easy for developers to understand what I mean
and to simply comment-out the one line in the definition of BaseClass.
4) Note that for clarity and conformance to almost universal convention, it's
better to use arrows pointing from derived classes to base classes
in your inheritance tree.
Sorry, my mistake.
5) It's good to provide the inheritance tree, but it's better when it's
complete.
I've looked at what you actually have in your package and the complete
inheritance tree is something like this:
BaseClass <- SubClassA
<- SubClassB <- SubSubClassA
<- SubSubClassB
Where is the SubClassA class in the inheritance tree that you included in
your
post below?
Sorry, my mistake.
6) Another thing I note is that you have a naming problem: any reason why you
name
"SubSubClassA" a subclass of SubClassB? Given that you also have defined
SubClassA,
this can only lead to confusion!
Again, you are correct, my mistake. Here is the corrected inheritance tree:
BaseClass <- SubClassA
<- SubClassB <- SubSubClassB1
<- SubClassB <- SubSubClassB2
7) You need to use proper terminology if you expect people to follow you. In
your post
below, every time you instanciate a class you say that your are creating it:
o "First, I need to create SubClassA..."
o "I create both subclasses, SubSubClassA and SubSubClassB..."
o etc...
Creating a class is not the same as instanciating it!
You are correct, this was confusing. I meant, theat I create an object,
which is probably the same as instanciating a class?
Here is the actual code to use:
> subA <-
new("SubClassA",filename="OutSubA",filedir="/Volumes/CoreData/CRAN/",namesubA="NameSubA")
> subsubB1 <-
new("SubSubClassB1",filename="MyFileNameB1",filedir="/Volumes/CoreData/",subA=subA)
> subsubB2 <-
new("SubSubClassB2",filename="MyFileNameB2",filedir="/Volumes/CoreExtra",subA=subA)
8) You start your examples by "First, I need to create SubClassA..." so you are
introducing us a class that doesn't show up in your inheritance tree so we
don't
know how it is related to the other classes. Also you say that you "need" to
create SubClassA but we have no idea why!
Once again you are correct, this was confusing. I need to create object
"subA" of class SubClassA, since it is a slot of SubClassB, and needs to
be included in the instanciation of objects "subsubB1" and "subsubB2".
9) You have a slot in SubClassB that is of class SubClassA! This means "a
SubClassB
object _is_ a BaseClass object and it _has_ a slot that is itself a BaseClass
object (since a SubClassA object is a BaseClass object too)". I hope that
this
is really what you want... but maybe this could be related to the fact that
you
see 2 instanciations of BaseClass when you instanciate SubSubClassA or
SubSubClassB.
This is the mos
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
ot;, sep="")
if (is.null(msg)) TRUE else msg
}
)
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
setMethod("initialize", "SubClassB",
function(.Object, nameB="", ...) {
cat("--initialize:SubClassB--\n")
cat("SubClassB:init:class(.Object) = ", class(.Object), "\n", sep="")
.Object <- callNextMethod(.Object, nameB=nameB, ...)
[EMAIL PROTECTED] = nameB
.Object
}
)
setValidity("SubClassB",
function(object) {
cat("--setValidity:SubClassB--\n")
cat("SubClassB:val:class(object) = ", class(object), "\n", sep="")
msg <- NULL
if (!(is.character([EMAIL PROTECTED]) && length([EMAIL PROTECTED]) > 0))
msg <- cat("missing nameB\n")
cat("SubClassB:val:nameB = ",[EMAIL PROTECTED], "\n", sep="")
if (is.null(msg)) TRUE else msg
}
)
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
setMethod("initialize", "SubSubClassB1",
function(.Object, ...) {
cat("--initialize:SubSubClassB1--\n")
cat("SubSubClassB1:init:class(.Object) = ", class(.Object), "\n",
sep="")
.Object <- callNextMethod(.Object, ...)
.Object
}
)
setValidity("SubSubClassB1",
function(object) {
cat("--setValidity:SubSubClassB1--\n")
cat("SubSubClassB1:val:class(object) = ", class(object), "\n", sep="")
return(TRUE)
}
)
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
setMethod("initialize", "SubSubClassB2",
function(.Object, nameB2="MyNameB2", ...) {
cat("--initialize:SubSubClassB2--\n")
cat("SubSubClassB2:init:class(.Object) = ", class(.Object), "\n",
sep="")
if (nameB2 == "") nameB2 <- "DefaultNameB2";
cat("SubSubClassB2:init:nameB2 = ", nameB2, "\n", sep="")
.Object <- callNextMethod(.Object, nameB2=nameB2, ...)
[EMAIL PROTECTED] <- nameB2
.Object
}
)
setValidity("SubSubClassB2",
function(object) {
cat("--setValidity:SubSubClassB2--\n")
cat("SubSubClassB2:val:class(object) = ", class(object), "\n", sep="")
msg <- NULL;
if (!(is.character([EMAIL PROTECTED]) && length([EMAIL PROTECTED]) > 0))
msg <- cat("missing nameB2\n")
cat("SubClassB:val:nameB2 = ",[EMAIL PROTECTED], "\n", sep="")
if (is.null(msg)) TRUE else msg
}
)
# - - - - - - - - - - - - - - - END - - - - - - - - - - - - - - - - -
Herve Pages wrote:
> Hi Christian,
>
> cstrato wrote:
>
>> Dear Herve
>>
>> Thank you for your helpful comments, and I especially appreciate that
>> you tried to run my package. I will try to answer each point separately.
>>
>> Herve Pages wrote:
>>
>>> Hi Christian,
>>>
>>> I can only give you a few reasons why IMO it is very unlikely that
>>> anybody
>>> will be able to help you on this, with the current form of your post.
>>>
>>> 1) Unless you have a really good reason to do so, don't attach a package
>>>to your post. Do your best to provide a few lines of code that anybody
>>>can easily copy and paste into their session.
>>>
>>>
>> Sorrowly, sometimes, a few lines of code are not sufficient to show
>> the problem. Furthermore, most of the time there are complaints that
>> people do not provide enough information, an issue I wanted to avoid.
>>
>
> The code you provide below is still too long and overcluttered with stuff
> that is
> probably unrelated with the issue you want to discuss. Your class definitions
> still have slots that we don't care about. Basically if you want to
> discuss an S4 issue, you should get rid of all this file system related stuff
> (the 'dirfile', 'filedir', 'filename' slots, the 'pathFile' function, the
> dozens
> of calls to 'basename', 'dirname', 'getwd', 'file.dir' etc...)
>
> Also your code is dirty and hard to read. Take this for example:
>
> "initialize.BaseClass" <-
> function(.Object, filename=character(), filedir=as.character(getwd()), ...)
> {
> print("--initialize:BaseClass--")
> print(paste("BaseClass:init:class(.Object) = ", class(.Object)))
>
> # .Object <- callNextMethod(.Object, ...);
>
>
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear Herve, dear Martin,
First I want to thank Herve very much for your continuous efforts. You can
not imagine, how relieved I was that you mangaged to reproduce this
behavior.
Just when I wanted to send my reply to Herve, I received Martin's comments:
As you mention, there were two problems in my example:
1. partial matching:
Thank you for your explanation, now I hope that I understand the behavior.
However, as Herve correctly mentioned, this is only a side issue.
2. lazy evaluation and validity methods:
This is the real problem, that I try to solve since three weeks, and I am
afraid, that I still do not know how to solve it.
Following Herve's example, I have managed to reduce my own example so that
it is only slightly larger than his example, however, now I had to expand
it again to make my point, see the final code below.
(For the moment I stick with my naming of the classes)
The result I get is the following:
> subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
nameB="MyNameB")
--initialize:SubSubClassB2--
--initialize:SubClassB--
--initialize:BaseClass--
BaseClass:init:filename = MyFileNameB2
--setValidity:BaseClass--
--initialize:SubClassB--
--initialize:BaseClass--
BaseClass:init:filename = ERROR_FileName
--setValidity:BaseClass--
--setValidity:SubClassB--
--setValidity:SubClassB--
--setValidity:SubSubClassB2--
SubSubClassB2:val:filename = MyFileNameB2
Although the final output gives the correct result "filename =
MyFileNameB2",
in the interim code, filename is set to "filename = ERROR_FileName".
In my real package the line "filename <- ERROR_FileName" is replaced by
a function. To take advantage of inheritance, I have defined "filename"
in BaseClass, and I want to check for its validity only once in BaseClass.
With the current information I have to re-evaluate my code in order to
avoid "lazy evaluation", since this might be the problem.
Thank you both for your extensive help.
Best regards
Christian
# - - - - - - - - - - - - - - - BEGIN - - - - - - - - - - - - - - - -
setClass("BaseClass",
representation(filename = "character", "VIRTUAL"),
prototype(filename = "DefaultFileName")
)
setClass("SubClassB",
representation(nameB = "character"),
contains=c("BaseClass"),
prototype(nameB = "NameB")
)
setClass("SubSubClassB2",
representation(nameB2 = "character"),
contains=c("SubClassB"),
prototype(nameB2 = "NameB2")
)
setMethod("initialize", "BaseClass",
function(.Object, filename="", ...) {
cat("--initialize:BaseClass--\n")
if (filename == "" || nchar(filename) == 0) filename <-
"ERROR_FileName"
cat("BaseClass:init:filename = ", filename, "\n", sep="")
.Object <- callNextMethod(.Object, filename=filename, ...)
[EMAIL PROTECTED] <- filename
.Object
}
)
setValidity("BaseClass",
function(object) {
cat("--setValidity:BaseClass--\n")
msg <- NULL
str <- [EMAIL PROTECTED]
if (!(is.character([EMAIL PROTECTED])))
msg <- cat("missing filename\n")
if (is.null(msg)) TRUE else msg
}
)
setMethod("initialize", "SubClassB",
function(.Object, nameB="", ...) {
cat("--initialize:SubClassB--\n")
.Object <- callNextMethod(.Object, nameB=nameB, ...)
}
)
setValidity("SubClassB",
function(object) {
cat("--setValidity:SubClassB--\n")
TRUE
}
)
setMethod("initialize", "SubSubClassB2",
function(.Object, ...) {
cat("--initialize:SubSubClassB2--\n")
.Object <- callNextMethod(.Object, ...)
}
)
setValidity("SubSubClassB2",
function(object) {
cat("--setValidity:SubSubClassB2--\n")
cat("SubSubClassB2:val:filename = ", [EMAIL PROTECTED], "\n", sep="")
TRUE
}
)
# - - - - - - - - - - - - - - - END - - - - - - - - - - - - - - - - -
Martin Morgan wrote:
> Christian, Herve --
>
> In the end, I think you're being caught by partial matching in
> function arguments:
>
>
>> f <- function(x1) cat("x1:", x1, "\n")
>> f(x="hello")
>>
> x1: hello
>
> In the functional call x gets matched to x1. In your initialization
> method for SubSubClassB2, nameB gets matched to nameB2 and so not
> passed as ... in the callNextMethod.
>
> The apparently extra calls to initialize with the wrong arguments come
> about because of the validity methods -- validity gets checked by
> coercing derived objects to their superclass, which involves a call to
> 'new' (hence initialize) followed by copying appropriate slots.
>
> The funny effect where class(object) seems to trigger construction of
> a new object is lazy evaluation -- the 'object' argument to
> setValidity is not evaluated until needed, i.e., until class(object)
> (anything would trigger this, including force(object)); only then do
> you see the attempt to create the new object of the previous
> paragraph.
>
> Without partial matching issues, the use of callNe
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear Herve
Although I am currently learning to use S4 classes, and thus I am
probably not the person
to comment on S4 classes, I completely agree with you.
Coming from C++ (most of my code is C++), this is what I have
intuitively expected,
although I was not able to formulate it. I am glad that you did.
At the moment I try to find out if there is a possibility to circumvent
this problem.
I do not know if there is a possibility to set an object to NULL
initially, and then
call: "if (!is.null(object)) do something"
Best regards
Christian
Herve Pages wrote:
> Martin,
>
> Martin Morgan wrote:
>
>> The funny effect where class(object) seems to trigger construction of
>> a new object is lazy evaluation -- the 'object' argument to
>> setValidity is not evaluated until needed, i.e., until class(object)
>> (anything would trigger this, including force(object)); only then do
>> you see the attempt to create the new object of the previous
>> paragraph.
>>
>
> The fact that you can't predict the number of times the "initialize"
> method will be called is problematic. Here is a simple example
> where "initialize-A" increments a global counter to keep track of the
> number of A-objects:
>
> A.GLOBALS <- new.env(parent=emptyenv())
> A.GLOBALS[["nobjs"]] <- 0L
>
> setClass("A",
> representation(a="character"),
> prototype(a="a0")
> )
> setMethod("initialize", "A",
> function(.Object, ...) {
> cat("--initialize:A--\n")
> A.GLOBALS[["nobjs"]] <- A.GLOBALS[["nobjs"]] + 1
> cat("A-object #", A.GLOBALS[["nobjs"]], "\n", sep="")
> callNextMethod()
> }
> )
> setValidity("A",
> function(object) {
> cat("--setValidity:A--\n")
> tmp <- class(object)
> TRUE
> }
> )
>
> setClass("B",
> contains="A",
> representation(b = "character")
> )
> setMethod("initialize", "B",
> function(.Object, ...) {
> cat("--initialize:B--\n")
> callNextMethod()
> }
> )
> setValidity("B",
> function(object) {
> cat("--setValidity:B--\n")
> TRUE
> }
> )
>
> Let's try it:
>
> > b1 <- new("B")
> --initialize:B--
> --initialize:A--
> A-object #1
> > A.GLOBALS[["nobjs"]]
> [1] 1
>
> > b1 <- new("B", b="hello")
> --initialize:B--
> --initialize:A--
> A-object #2
> --setValidity:A--
> --initialize:A--
> A-object #3
> --setValidity:B--
> > A.GLOBALS[["nobjs"]]
> [1] 3
>
> Shouldn't the "initializing" ("constructor" in other languages) code be
> executed
> exactly 1 time per object instanciation? Something that the programmer can
> simply
> rely on, whatever this code contains and whatever the internal subtilities of
> the
> programming lamguage are?
>
> Cheers,
> H.
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Bioc-devel] promptClass
Dear Martin
Thank you for sending the fast fix to the problem.
Best regards
Christian
Martin Morgan wrote:
> promptClass fails to identify methods associated with the class. Here
> is a fix:
>
> Index: promptClass.R
> ===
> --- promptClass.R (revision 41719)
> +++ promptClass.R (working copy)
> @@ -165,7 +165,7 @@
> if (nmeths > 0) {
> .meths.body <- " \\describe{"
> for (i in 1:nmeths) {
> - .sigmat <- sigsList(methnms[i], where)
> + .sigmat <- sigsList(methnms[i], where=whereClass)
> for (j in seq_along(.sigmat)) {
> if (!all(is.na(match(.sigmat[[j]],clName {
> methn.i <- escape(methnms[i])
> Index: RMethodUtils.R
> ===
> --- RMethodUtils.R (revision 41719)
> +++ RMethodUtils.R (working copy)
> @@ -621,7 +621,7 @@
> getMethodsMetaData <-
>## get the methods meta-data for function f on database where
>function(f, where = topenv(parent.frame())) {
> -mname <- mlistMetaName(f, where)
> +mname <- mlistMetaName(f, getPackageName(where))
> if(exists(mname, where = where, inherits = missing(where)))
> get(mname, where)
> else
>
> Seth Falcon <[EMAIL PROTECTED]> writes:
>
>
>> cstrato <[EMAIL PROTECTED]> writes:
>>
>>
>>> Dear all,
>>>
>>> What is the best way to write the docs for S4 classes?
>>>
>>> Concretely, is it possible to include the methods in the class
>>> documentation?
>>> For example, the documentation for class "AffyBatch" contains all methods.
>>> However, when I do:
>>>promptClass("AffyBatch")
>>> the relevant output of file "AffyBatch-class.Rd" is:
>>>\section{Methods}{
>>>No methods defined with class "AffyBatch" in the signature.
>>>}
>>>
>> promptClass used to provide more useful output. You might want to
>> report the issue on one of the R lists.
>>
>>
>>> Since PromptClass() contains a parameter "where" is it possible to use
>>> it, and how?
>>>
>> I'm not sure that is relevant here.
>>
>> One thing that can be useful here is showMethods(classes="AffyBatch").
>> The problem with static documentation for methods is that what methods
>> are available can change based on what packages are attached.
>>
>> If showMethods or a wrapper for it could be convinced to output a link
>> to a help file, then it might actually be a good way to go...
>>
>> + seth
>>
>> --
>> Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
>> http://bioconductor.org
>>
>> ___
>> [EMAIL PROTECTED] mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistent behavior of sQuote and dQuote
Dear all
When comparing sQuote("text") and dQuote("text") on MacOS X and Linux FC4
I get an inconsistent behavior (using the new release version R-2.6.0):
sQuote: On Mac I get the correct result "'text'", but on FC4 the
incorrect result "`text´".
dQuote: On Mac I get the correct result "\"text\"", but on FC4 the
incorrect result ""text"".
For this reason I cannot use these functions in my package.
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent behavior of sQuote and dQuote
Dear Duncan and Marc
Thank you for your comments, and please allow me to express my personal
opinion:
I have read the comments of Markus Kuhn mentioned in the help file to
sQuote:
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Since R is a programming language, the behavior should in my opinion be
consistent
for all platforms, and as default it should only rely on ASCII
characters, in this
case 0x22 and 0x27, so it is possible to pass these characters to other
programming
languages, in my case C++.
Since shQuote(string,type) has already a type option, I would suggest to
add
options to sQuote() and dQuote(), too, with default being ASCII behavior.
However, this is only my personal opinion.
Best regards
Christian
Marc Schwartz wrote:
> On Sun, 2007-10-14 at 11:56 -0400, Duncan Murdoch wrote:
>
>> On 14/10/2007 10:44 AM, cstrato wrote:
>>
>>> Dear all
>>>
>>> When comparing sQuote("text") and dQuote("text") on MacOS X and Linux FC4
>>> I get an inconsistent behavior (using the new release version R-2.6.0):
>>>
>>> sQuote: On Mac I get the correct result "'text'", but on FC4 the
>>> incorrect result "`text´".
>>>
>> Those both look correct to me (but not the same). What do you see?
>>
>>
>>> dQuote: On Mac I get the correct result "\"text\"", but on FC4 the
>>> incorrect result ""text"".
>>>
>> The second one looks wrong here (no escapes shown), but I suspect those
>> inner quotes aren't really the same as the outer quotes, and that's why
>> they're not escaped.
>>
>> If you don't want the fancyquotes at all, you can use
>> options(useFancyQuotes=FALSE). In a package, it would be polite to do
>> this only locally, i.e. have something like
>>
>> save <- options(useFancyQuotes=FALSE)
>> on.exit(options(save))
>>
>> in functions that call sQuote or dQuote, because options() belong to the
>> user, not to you.
>>
>
> FWIW, on F7 I get:
>
>
>> sQuote("text")
>>
> [1] "‘text’"
>
>
>> dQuote("text")
>>
> [1] "“text”"
>
>
> options(useFancyQuotes = FALSE)
>
>
>> sQuote("text")
>>
> [1] "'text'"
>
>
>> dQuote("text")
>>
> [1] "\"text\""
>
>
> The differing behavior between OS X and FC4 is perhaps due to the
> available character sets and the locales, presuming that they may not be
> the same. See the Details section of ?sQuote.
>
> I might also point out that FC4 has been EOL for some time. It would be
> prudent to consider updating to a more recent version. FC6 and F7 are
> the currently maintained releases, with F8 due to be released on
> November 8.
>
> HTH,
>
> Marc Schwartz
>
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compiler options for Makefile.win
Dear all, For certain reasons I have to compile the source code of my package on Windows XP using Microsoft Visual Studio 9.0, thus I had to create a "Makefile.win". Now I have a question regarding compiler options /MT vs /MD for Makefile.win. The following partial output shows that when building my package on Windows XP using "R CMD build --binary xps" with compiler option /MT everything is ok: - - - - - - - - running src/Makefile.win ... "C:\Programme\Microsoft Visual Studio 9.0\VC\bin/cl" /I"C:\root/include" /FIw32p ragma.h /MT /EHsc /Ox /D "MSVC" /D "WIN32" /c TStat.cxx Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. TStat.cxx Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,304 bytes Compression decreased file by 442,728 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ... OK * cleaning src Created c:\home\Rabbitus\temp\Rbuild210430099\xps\chm\xps.chm, 166,308 bytes Compression decreased file by 442,724 bytes. ** building package indices ... ** MD5 sums packaged installation of 'xps' as xps_1.3.8.zip * DONE (xps) - - - - - - - - As you see the package was built correctly. However, when I change the compiler option in "Makefile.win" to /MD the build stops at the following position: - - - - - - - - Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes Compression decreased file by 442,726 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ...Terminating on signal SIGINT(2) - - - - - - - - As you see I had to terminate the build process manually after 15 min . My question is now: Do you know why I can build my package w/o problems when using option /MT but not when using option /MD? As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded today. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiler options for Makefile.win
Dear Uwe, My problem is that this is the only mailing list I know where to ask this question, since this problem is definitely related to R. When I compile my source code as stand alone library using NMAKE then both compiler options, /MD and /MT, work fine and I can use the compiled library from a C++ program w/o any problems. Only compiling the source code from within R results in the error when using /MD. BTW, I forgot to mention that when "R CMD build" stops at: * DONE (xps) * creating vignettes ... I get the following "Microsoft Visual C++ Runtime Library" dialogbox: Runtime Error! Program: c:\Programme\R\R-2.9.0alpha\bin\Rterm.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information. Best regards Christian Uwe Ligges wrote: I fear the number of R users under Windows that make use of a non-gcc compiler and is reading this list is quite close to 0. Hence you will probably have to find it out yourself. Uwe Ligges cstrato wrote: Dear all, For certain reasons I have to compile the source code of my package on Windows XP using Microsoft Visual Studio 9.0, thus I had to create a "Makefile.win". Now I have a question regarding compiler options /MT vs /MD for Makefile.win. The following partial output shows that when building my package on Windows XP using "R CMD build --binary xps" with compiler option /MT everything is ok: - - - - - - - - running src/Makefile.win ... "C:\Programme\Microsoft Visual Studio 9.0\VC\bin/cl" /I"C:\root/include" /FIw32p ragma.h /MT /EHsc /Ox /D "MSVC" /D "WIN32" /c TStat.cxx Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. TStat.cxx Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,304 bytes Compression decreased file by 442,728 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ... OK * cleaning src Created c:\home\Rabbitus\temp\Rbuild210430099\xps\chm\xps.chm, 166,308 bytes Compression decreased file by 442,724 bytes. ** building package indices ... ** MD5 sums packaged installation of 'xps' as xps_1.3.8.zip * DONE (xps) - - - - - - - - As you see the package was built correctly. However, when I change the compiler option in "Makefile.win" to /MD the build stops at the following position: - - - - - - - - Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes Compression decreased file by 442,726 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ...Terminating on signal SIGINT(2) - - - - - - - - As you see I had to terminate the build process manually after 15 min . My question is now: Do you know why I can build my package w/o problems when using option /MT but not when using option /MD? As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded today. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Compiler options for Makefile.win
Dear Gabor,
Thank you for your suggestion.
I forgot to mention that the build process ended with the following
dialog box:
Runtime Error!
Program: c:\Programme\R\R-2.9.0alpha\bin\Rterm.exe
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contact the application's support team for more information.
Only after pressing OK there was no response of Rterm and I had to
terminate the build process manually. I am not sure if this means that
the build process got into an infinite loop.
Could you explain what you mean with running the vignette "by hand" line
by line?
How can I do this?
BTW, if the problem is within one of the vignettes, as you mention, I
assume that the problem may be at the following statements:
\begin{Sinput}
R> library(xps)
\end{Sinput}
<>=
library(xps)
@
I believe that the error occurs when trying to load "library(xps)".
Best regards
Christian
Gábor Csárdi wrote:
On Sun, Mar 29, 2009 at 9:31 PM, cstrato wrote:
[...]
- - - - - - - -
Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes
Compression decreased file by 442,726 bytes.
** building package indices ...
** MD5 sums
* DONE (xps)
* creating vignettes ...Terminating on signal SIGINT(2)
- - - - - - - -
As you see I had to terminate the build process manually after 15 min .
My question is now:
Do you know why I can build my package w/o problems when using option /MT
but not when using option /MD?
It seems that the building process got into an infinite loop while
creating the vignette. Some code in the vignette/package does not work
properly. Try running the vignette "by hand" line by line to see where
the problem is.
Gabor
As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded
today.
Thank you in advance.
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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] Package crashes R under Windows Vista
Errormodulename: "libCore.dll_unloaded") It is important to note that on both WinXP AND Vista library "xps.dll" compiled with option "/MD" does work perfectly fine when running from within ROOT! Please, can anybody tell me why Rterm on Vista crashes when running library(xps)? It seems that for option "/MD" Rterm is not able to load the ROOT core library "libCore.dll", why? Any help is greatly appreciated otherwise my package "xps" will not be able to run on Vista and more important, Windows 7. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package crashes R under Windows Vista
Dear Duncan,
I know that I am asking an unusual question, since MS VC++ is not
supported, and I have of course installed the Rtools. However, asking
support from MS is not an option for the following reason:
Looking at different VC forums everybody tells you that you should
compile all libraries with the same option and you should not mix
options /MD with /MT, and this is the answer I will get.
Furthermore, as I have already mentioned, library xps.dll compiled with
/MD works perfectly fine on WinXP and Vista when used independent from
R. The problem is that when calling library(xps) from within R, R can
load library xps.dll, but it cannot load the libraries which are called
from library xps.dll such as library libCore.dll.
Since the question is why can R not load a C++ library which is called
from library xps.dll, asking this question at R-devel seems for me to be
the only option.
Best regards
Christian
Duncan Murdoch wrote:
On 18/09/2009 6:12 PM, cstrato wrote:
Dear all,
Please, please I really need your help, since I am not able to solve
the problem myself:
It seems that until now most Windows users of my Bioconductor package
"xps" use Windows XP, but recently a user tried to use it on Windows
Vista where it crashed R immediately. Since I assume that some users
may migrate to the upcoming Windows 7 where the problem will be the
same, I would appreciate any help to be able to support Vista/Windows
7, thank you in advance.
You are requiring specific Microsoft tools to compile a package, which
fails on one Microsoft OS, but not another. Isn't this a question you
should address to Microsoft?
For the record:
We support compiling in the compiler listed in the R-admin manual,
which is available from www.murdoch-sutherland.com/Rtools. If you
choose to use a different compiler, you should seek support from its
supplier.
Duncan Murdoch
The problem ist that my package consists mainly of C++ code which I
must compile with Visual C++ (Express Edition 2008), since it depends
on the ROOT C++ framework. Windows users download and install first
the ROOT Windows binary compiled with VC9 and then install the
Windows binary of xps.
Thus package xps contains a "Makefile.win" where I use one of the
compiler options "/MT" or "/MD", respectively, see:
http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Since the Windows binary of ROOT is compiled with option "/MD" I
should in principle use this option, however, R does not accept this
option. Luckily, for Winodws XP I can compile xps with "/MT" and this
works perfectly fine.
The real problem is that neither option works on Windows Vista,
although I can run "R CMD INSTALL" in both cases. However, when
loading "library(xps)" using Rterm.exe I get the following two cases:
1, xps compiled on Vista with option "/MD":
new R session:
> library(xps,lib.loc="C:/home/Rabbitus/CRAN/myRlib")
Error in inDL(x, as.logical(local), as.logical(now), ...) :
cannot load shared library
'C:/home/CS/CRAN/myRlib/xps/libs/xps.dll':
LoadLibrary failure: A DLL-Initialisationroutine failed.
Then R crashes and Vista displays a Dialogbox with the following
message:
R for Windows terminal front-end does no longer function
Anwendungszeitstempel:4a928a5c
Fehlermodulname:libCore.dll_unloaded
Fehlermodulversion:0.0.0.0
Fehlermodulzeitstempel:4a4b94a1
Ausnahmecode:c005
Ausnahmeoffset:0413a6f0
Betriebsystemversion:6.0.6001.2.1.0.768.3
Gebietsschema-ID:1031
Zusatzinformation 1:b2be
Zusatzinformation 2:82109204b3973566ace818217390e302
Zusatzinformation 3:1563
Zusatzinformation 4:deee40b8797d25628c21b9ef47e8a50c
2, xps compiled on Vista with option "/MT":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
> scheme.test3 <-
root.scheme(paste(.path.package("xps"),"schemes/SchemeTest3.root",sep="/"))
> data.test3 <- import.data(scheme.test3, "DataTest3",
celdir=paste(.path.package("xps"),"raw",sep="/"))
==
=== STACKTRACE ===
==
==
= END STACKTRACE =
==
Then R crashes and Vista displays a Dialogbox with the following
message:
R for Windows terminal front-end does no longer function
Problemsignatur:
Problemereignisname:APPCRASH
Anwendungsname:Rterm.exe
Anwendungsversion:2.92.49384.0
Anwendungszeitstempel:4a928a5c
Fehlermodulname:ntdll.dll
Fehlermodulversion:6.0.6001.18000
Fehlermodulzeitstempel:4791a7a6
Ausnahmecode:c005
A
[Rd] Question when compiling source code with VC++
Dear Duncan, In your document "readme.packages.txt" you have a very helpful chapter on "Using Visual C++". Please allow me to ask you one question: Why do you propose the option "/MT" instead of option "/MD"? (To my knowledge usually option "/MD" is used when compiling programs with VC++.) Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question when compiling source code with VC++
Thank you for this clarification, neither did I know that it was written by Brian Ripley (although now this seems to be obvious) nor that the advice is already 10 years old. Thus please allow me to re-phrase my question: Dear Prof. Ripley: 1, Why did you propose the option "/MT" instead of option "/MD"? 2, Will the proposed settings to build the DLL still be valid for the upcoming Windows 7? Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ Duncan Murdoch wrote: On 15/10/2009 5:01 PM, cstrato wrote: Dear Duncan, In your document "readme.packages.txt" you have a very helpful chapter on "Using Visual C++". Please allow me to ask you one question: Why do you propose the option "/MT" instead of option "/MD"? (To my knowledge usually option "/MD" is used when compiling programs with VC++.) I didn't write that: I've got no experience with VC++. It was Brian Ripley who wrote it, and the log says he wrote it in 1999. So I'd guess that it isn't bad advice (having lasted 10 years without a change), but I guess it's possible that it is no longer optimal. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
