Re: [Rd] Packages not found
> 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/
This is also blocking R CMD check --as-cran
$ R CMD check --as-cran fastR_0.7-1.tar.gz
* using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
* using R Under development (unstable) (2013-08-19 r63623)
* using platform: x86_64-apple-darwin11.4.2 (64-bit)
* using session charset: UTF-8
* checking for file ‘fastR/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘fastR’ version ‘0.7-1’
* checking CRAN incoming feasibility ...Warning in
url(sprintf("%s/web/packages/packages.rds", CRAN), "rb") :
cannot open: HTTP status was '404 Not Found'
Error in url(sprintf("%s/web/packages/packages.rds", CRAN), "rb") :
cannot open the connection
Execution halted
--
View this message in context:
http://r.789695.n4.nabble.com/Packages-not-found-tp4674862p4674884.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Big Integer Support in JSON-to-R Conversion
I have come across an issue converting a JSON string in R (with either the
package 'rjson' or 'RJSONIO') when big integers are included in the JSON
string.
A simple example of the problem is:
> options(scipen=999) # To prevent representing the answer in scientific
notation
> json.str <- '{"bigInt":123456789123456789}' # Sample JSON string with
big integer
Using the RJSONIO package:
> fromJSON(json.str) # From package 'RJSONIO'
bigInt
123456789123456784
Using the rjson package:
> fromJSON(json.str) # From package 'rjson'
$bigInt
[1] 123456789123456784
Notice the difference in the last digit (4 vs. 9).
In my research, I have come across various ways to handle big integers in R
(the 'int64' package, for example), but I don't believe this helps with the
numeric representation/interpretation that occurs inside of the rjson and
RJSONIO packages.
It is not important in my application for numeric nodes in the JSON to be
preserved as a numeric class - if everything came back as a string, that
would be acceptable. Therefore, I was hoping the 'handler' or 'stringFun'
arguments within the RJSONIO package would allow me to specify a character
representation for all nodes inside the JSON string, such that:
> fromJSON(json.str)
would result in:
$bigInt
[1] "123456789123456789"
However, it looks like the 'stringFun' is only applied to the character
string nodes within the JSON:
>
fromJSON('{"bigInt1":123456789123456789,"bigInt2":"123456789123456789"}',stringFun=function(x)
class(x))
$bigInt1
[1] 123456789123456784
$bigInt2
[1] "character"
I think there might be some promise to the 'handler' object, but I'm having
trouble interpreting how to implement it effectively.
Thank you in advance for any solutions/suggestions/references that you may
be able to provide!
Regards,
Trannon
__
Trannon Mosher
Data Modeling Analyst
Clear Capital
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages not found
Is it possible to set the CRAN mirror at the command line when doing R CMD
check --as-cran (which also breaks currently)?
$ R CMD check --as-cran fastR_0.7-1.tar.gz
* using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
* using R Under development (unstable) (2013-08-19 r63623)
* using platform: x86_64-apple-darwin11.4.2 (64-bit)
* using session charset: UTF-8
* checking for file ‘fastR/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘fastR’ version ‘0.7-1’
* checking CRAN incoming feasibility ...Warning in
url(sprintf("%s/web/packages/packages.rds", CRAN), "rb") :
cannot open: HTTP status was '404 Not Found'
Error in url(sprintf("%s/web/packages/packages.rds", CRAN), "rb") :
cannot open the connection
Execution halted
--
View this message in context:
http://r.789695.n4.nabble.com/Packages-not-found-tp4674862p4674888.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ::: inside the package
> You only need ::: from outside the package. In some cases I have had difficulties to evaluate non-exported/hidden R functions from C code without ::: (inside the package). But that's a different story and not any serious problem at all. Probably there is also some easy workaround, but I haven't even tried to search for any other solutions as ::: works fine. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Type annotations for R function parameters.
Hello. One of my clients asked if it would be possible to have an IDE which could use type discovery for R functions to make flow-like construction of an R program. Something like a LabView graphical composition of processing elements. They called this type of program composition a "workflow". I looked at some of this programs, like: * Orange http://orange.biolab.si/ * RedR http://www.red-r.org/ * Rattle http://rattle.togaware.com/ * Rpad https://code.google.com/p/rpad/ and all of them did type introspection (they made mapping between R functions and their IDE's visual framework) by hand for each function of supported packages which is time and resource consuming. So, to reduce an amount of code to be written for adapters between R and IDE some kind of annotations could be introduced over parameters and return values. Those could be optional and will help to discover type information for support of dynamic composition of programs. Do you have any suggestions on the topic? Best regards, Artem Oboturov [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Type annotations for R function parameters.
On 13-08-30 5:19 AM, Оботуров Артем wrote: Hello. One of my clients asked if it would be possible to have an IDE which could use type discovery for R functions to make flow-like construction of an R program. Something like a LabView graphical composition of processing elements. They called this type of program composition a "workflow". I looked at some of this programs, like: * Orange http://orange.biolab.si/ * RedR http://www.red-r.org/ * Rattle http://rattle.togaware.com/ * Rpad https://code.google.com/p/rpad/ and all of them did type introspection (they made mapping between R functions and their IDE's visual framework) by hand for each function of supported packages which is time and resource consuming. So, to reduce an amount of code to be written for adapters between R and IDE some kind of annotations could be introduced over parameters and return values. Those could be optional and will help to discover type information for support of dynamic composition of programs. Do you have any suggestions on the topic? It's very common for R functions to accept many different types for the same argument on input, and somewhat common for the type of output to depend on the inputs, so this looks hard: that's why those front ends need work by hand. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Type annotations for R function parameters.
On Fri, Aug 30, 2013 at 2:49 PM, Оботуров Артем wrote: > Hello. > > One of my clients asked if it would be possible to have an IDE which could > use type discovery for R functions to make flow-like construction of an R > program. Something like a LabView graphical composition of processing > elements. > > They called this type of program composition a "workflow". > > I looked at some of this programs, like: > * Orange http://orange.biolab.si/ > * RedR http://www.red-r.org/ > * Rattle http://rattle.togaware.com/ > * Rpad https://code.google.com/p/rpad/ > > and all of them did type introspection (they made mapping between R > functions and their IDE's visual framework) by hand for each function of > supported packages which is time and resource consuming. > > So, to reduce an amount of code to be written for adapters between R and > IDE some kind of annotations could be introduced over parameters and return > values. Those could be optional and will help to discover type information > for support of dynamic composition of programs. > > Do you have any suggestions on the topic? See http://bioconductor.org/packages/2.12/bioc/html/TypeInfo.html -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Type annotations for R function parameters.
On 13-08-30 7:22 AM, Оботуров Артем wrote:
This essentially locks up the version of each package at the time of
writing an adapter. This makes you to make review of changes before
introducing an updated version of those packages into the system.
Yes, that's why I said this is hard.
Also there could a register of converters written by package developers
to cope with diversity of types.
Converters aren't sufficient. For example, many functions that take
input from files accept a filename as a character string or a connection
object for the input parameter. The character string is converted to a
connection using file() (sometimes "" is converted to stdin() or
stdout()), but often other things are done as well, e.g. code to close
the connection at the end of the function call.
For example, here is the code that examines the "con" argument to the
readLines() function:
if (is.character(con)) {
con <- file(con, "r")
on.exit(close(con))
}
The cat() function is a little more complicated, and the parse()
function has much more extensive calculations involving its "file"
argument, because it needs to set debugging information and produce
diagnostic messages.
Duncan Murdoch
On Friday, August 30, 2013, Duncan Murdoch wrote:
On 13-08-30 5:19 AM, Оботуров Артем wrote:
Hello.
One of my clients asked if it would be possible to have an IDE
which could
use type discovery for R functions to make flow-like
construction of an R
program. Something like a LabView graphical composition of
processing
elements.
They called this type of program composition a "workflow".
I looked at some of this programs, like:
* Orange http://orange.biolab.si/
* RedR http://www.red-r.org/
* Rattle http://rattle.togaware.com/
* Rpad https://code.google.com/p/__rpad/
Re: [Rd] "False" warning on "replacing previous import" when re-exporting identical object
This is related to the recent thread on correct NAMESPACE approach when writing S3 methods. If your methods are S4 I think pkgB does not need to export the generic. Just export the method and everything works magically and your problem disappears. For S3 methods there seems to be the difficultly you describe. Of course, the difference between S3 and S4 on this appears somewhat bug like. (I have not tested all this very carefully so I may have something wrong.) Paul Henrik Bengtsson wrote: >Hi, > >SETUP: >Consider three packages PkgA, PkgB and PkgC. > >PkgA defines a generic function foo() and exports it; > >export(foo) > >PkgB imports PkgA::foo() and re-exports it; > >importFrom(PkgA, foo) >export(foo) > >PkgC imports everything from PkgA and PkgB: > >imports(PkgA, PkgB) > > >PROBLEM: >Loading or attaching the namespace of PkgC will generate a warning: > > replacing previous import by 'PkgA::foo' when loading 'PkgC' > >This in turn causes 'R CMD check' on PkgC to generate a WARNING (no-go at >CRAN): > >* checking whether package 'PkgC' can be installed ... WARNING >Found the following significant warnings: > Warning: replacing previous import by 'PkgA::foo' when loading >'CellularAutomaton' > > >FALSE? >Isn't it valid to argue that this is a "false" warning, because >identical(PkgB::foo, PkgA::foo) is TRUE and therefore has no effect? > > >/Henrik > >PS. The above can be avoided by using explicit importFrom() on PkgA >and PkgB, but that's really tedious. In my case this is out of my >reach, because I'm the author of PkgA and PkgB but not many of the >PkgC packages. > >__ >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] Type annotations for R function parameters.
The type constraints in lambda.r make this relatively easy. The idea is to add
a declaration before a function that provides static typing on the function
arguments. The type constraint also specifies the return type, so it would be
straightforward to construct a graph. Where a type variable is used, then there
would need to be a run-time determination for the actual types as happens in
Haskell. Obviously to have a complete graph of a program would require the
whole program to be written using lambda.r.
For example you can decorate two separate function clauses each with their own
type constraint.
slice(x, pivot, inclusive) %::% a : numeric : logical : list
slice(x, pivot, inclusive=FALSE) %as% {
left <- x[1:pivot]
right <- x[(pivot+as.numeric(!inclusive)):length(x)]
list(left, right)
}
slice(x, expression) %::% a : logical : list
slice(x, expression) %as% {
left <- x[expression]
right <- x[!expression]
list(left, right)
}
This calls the first clause since the second argument is numeric.
> x <- rnorm(10)
> slice(x, 4)
[[1]]
[1] 1.2468112 -0.2795106 0.5775026 1.0521653
[[2]]
[1] -1.0493246 -2.0634126 0.0368455 -1.8431248 -0.3630197 0.1015901
This calls the second clause since x < 0 is logical.
> slice(x, x < 0)
[[1]]
[1] -0.2795106 -1.0493246 -2.0634126 -1.8431248 -0.3630197
[[2]]
[1] 1.2468112 0.5775026 1.0521653 0.0368455 0.1015901
This fails since no clause of the function accepts a character as the second
argument.
> slice(x, 'a')
Error in UseFunction(slice, "slice", ...) :
No valid function for
'slice(c(1.24681120969809,-0.279510617209735,0.577502630574721,1.05216534148533,
...),a)'
Warm Regards,
Brian
On Aug 30, 2013, at 5:19 AM, Оботуров Артем wrote:
> Hello.
>
> One of my clients asked if it would be possible to have an IDE which could
> use type discovery for R functions to make flow-like construction of an R
> program. Something like a LabView graphical composition of processing
> elements.
>
> They called this type of program composition a "workflow".
>
> I looked at some of this programs, like:
> * Orange http://orange.biolab.si/
> * RedR http://www.red-r.org/
> * Rattle http://rattle.togaware.com/
> * Rpad https://code.google.com/p/rpad/
>
> and all of them did type introspection (they made mapping between R
> functions and their IDE's visual framework) by hand for each function of
> supported packages which is time and resource consuming.
>
> So, to reduce an amount of code to be written for adapters between R and
> IDE some kind of annotations could be introduced over parameters and return
> values. Those could be optional and will help to discover type information
> for support of dynamic composition of programs.
>
> Do you have any suggestions on the topic?
>
> Best regards,
>
> Artem Oboturov
>
> [[alternative HTML version deleted]]
>
> __
> 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)
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. :-)
Regards,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
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)
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
>
> 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 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)
On 30/08/2013 3: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/?
Is this done by Sweave()?
No.
Duncan Murdoch
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)
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,
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] "False" warning on "replacing previous import" when re-exporting identical object
On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
wrote:
> Hi.
>
> On Fri, Aug 30, 2013 at 6:58 AM, Paul Gilbert wrote:
>> This is related to the recent thread on correct NAMESPACE approach when
>> writing S3 methods. If your methods are S4 I think pkgB does not need to
>> export the generic. Just export the method and everything works magically
>> and your problem disappears. For S3 methods there seems to be the
>> difficultly you describe. Of course, the difference between S3 and S4 on
>> this appears somewhat bug like. (I have not tested all this very carefully
>> so I may have something wrong.)
>
> For the record, you're referring to R-devel thread 'Correct NAMESPACE
> approach when writing an S3 method for a generic in another package'
> started on Aug 24, 2013
> [https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
> Yes, it's closely related or possibly the same issue. However, I do
> not find it odd that the S3 generic function needs to be exported
> from/available via the namespace. Hence it needs to be export():ed by
> at least one package/namespace.
>
> The real issue is when two package needs to export a generic function
> with the same name, e.g. foo(). If the two generic functions are
> defined differently (e.g. different arguments/signatures), they will
> be in conflict with each other. If they are identical, this should
> not be a problem, but here I might be wrong. However, there is also
> the special case where one package reexports the generic function from
> another package, e.g. PkgB::foo() exports PkgA:foo(). In this case,
> the object 'foo' does actually not existing in the name space of
> package PkgB - instead it provides a "redirect" to it, e.g.
>
>> PkgA::foo
> function (...)
> UseMethod("foo")
>
>
>> PkgB::foo
> function (...)
> UseMethod("foo")
>
>
>> exists("foo", envir=getNamespace("PkgB"), inherits=FALSE)
> [1] FALSE
>
>> exists("foo", envir=getNamespace("PkgB"), inherits=TRUE)
> [1] TRUE
>
>> identical(PkgB::foo, PkgA::foo)
> [1] TRUE
>
>
> The warning on "replacing previous import by 'PkgA::foo' when loading
> 'PkgC'" that occurs due to import(PkgA, PkgB) is generated in
> base::namespaceImportFrom()
> [http://svn.r-project.org/R/trunk/src/library/base/R/namespace.R],
> simply because it detects that "foo" (=n) has already been imported to
> PkgC' namespace (=impenv):
>
> if (exists(n, envir = impenv, inherits = FALSE)) {
> if (.isMethodsDispatchOn() && methods:::isGeneric(n, ns)) {
> ## warn only if generic overwrites a function which
> ## it was not derived from
> ...
> }
> warning(sprintf(msg, sQuote(paste(nsname, n, sep = "::")),
> sQuote(from)), call. = FALSE, domain = NA)
> }
>
> Note how there is already code for avoiding "false" warnings on S4
> generic function. This is what we'd like to have also for S3 generic
> functions, but it's much harder to test for such since they're not
> formally defined. However, I'd argue that it is safe to skip the
> warning *when the variable to be imported does not actually exist in
> the package being imported* (e.g. when just rexported), i.e.
>
>>svn diff namespace.R
> Index: namespace.R
> ===
> --- namespace.R (revision 63776)
> +++ namespace.R (working copy)
> @@ -871,6 +871,10 @@
> }
> for (n in impnames)
> if (exists(n, envir = impenv, inherits = FALSE)) {
> +## warn only if imported variable actually exists in the
> +## namespace imported from, which is not the case if
> +## the variable is rexported from another namespace
> +if (!exists(n, envir = ns, inherits = FALSE)) next
> if (.isMethodsDispatchOn() && methods:::isGeneric(n, ns)) {
> ## warn only if generic overwrites a function which
> ## it was not derived from
Ok, if import(PkgA, PkgB) and PkgB reexports a *different* foo() than
PkgA::foo(), say PkgZ::foo so identical(PkgB::foo, PkgA::foo) is
FALSE, then there is indeed a conflict. An alternative patch:
>svn diff namespace.R
Index: namespace.R
===
--- namespace.R (revision 63776)
+++ namespace.R (working copy)
@@ -871,6 +871,11 @@
}
for (n in impnames)
if (exists(n, envir = impenv, inherits = FALSE)) {
+## warn only if imported variable is non-identical to
+## the one already imported
+getImp <- get(n, envir = impenv)
+obj <- get(n, envir = ns)
+if (identical(obj, getImp)) next
if (.isMethodsDispatchOn() && methods:::isGeneric(n, ns)) {
## warn only if generic overwrites a function which
## it was not derived from
/Henrik
>
> I'm planning to propose ("wishlist / enhancement"; it may even be a
> bug) this over at https://bugs.r-project.org/.
>
> Comments, anyone?
>
> /Henrik
>
>
>> Paul
>>
>>
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
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
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)
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] "False" warning on "replacing previous import" when re-exporting identical object
Hi.
On Fri, Aug 30, 2013 at 6:58 AM, Paul Gilbert wrote:
> This is related to the recent thread on correct NAMESPACE approach when
> writing S3 methods. If your methods are S4 I think pkgB does not need to
> export the generic. Just export the method and everything works magically and
> your problem disappears. For S3 methods there seems to be the difficultly you
> describe. Of course, the difference between S3 and S4 on this appears
> somewhat bug like. (I have not tested all this very carefully so I may have
> something wrong.)
For the record, you're referring to R-devel thread 'Correct NAMESPACE
approach when writing an S3 method for a generic in another package'
started on Aug 24, 2013
[https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
Yes, it's closely related or possibly the same issue. However, I do
not find it odd that the S3 generic function needs to be exported
from/available via the namespace. Hence it needs to be export():ed by
at least one package/namespace.
The real issue is when two package needs to export a generic function
with the same name, e.g. foo(). If the two generic functions are
defined differently (e.g. different arguments/signatures), they will
be in conflict with each other. If they are identical, this should
not be a problem, but here I might be wrong. However, there is also
the special case where one package reexports the generic function from
another package, e.g. PkgB::foo() exports PkgA:foo(). In this case,
the object 'foo' does actually not existing in the name space of
package PkgB - instead it provides a "redirect" to it, e.g.
> PkgA::foo
function (...)
UseMethod("foo")
> PkgB::foo
function (...)
UseMethod("foo")
> exists("foo", envir=getNamespace("PkgB"), inherits=FALSE)
[1] FALSE
> exists("foo", envir=getNamespace("PkgB"), inherits=TRUE)
[1] TRUE
> identical(PkgB::foo, PkgA::foo)
[1] TRUE
The warning on "replacing previous import by 'PkgA::foo' when loading
'PkgC'" that occurs due to import(PkgA, PkgB) is generated in
base::namespaceImportFrom()
[http://svn.r-project.org/R/trunk/src/library/base/R/namespace.R],
simply because it detects that "foo" (=n) has already been imported to
PkgC' namespace (=impenv):
if (exists(n, envir = impenv, inherits = FALSE)) {
if (.isMethodsDispatchOn() && methods:::isGeneric(n, ns)) {
## warn only if generic overwrites a function which
## it was not derived from
...
}
warning(sprintf(msg, sQuote(paste(nsname, n, sep = "::")),
sQuote(from)), call. = FALSE, domain = NA)
}
Note how there is already code for avoiding "false" warnings on S4
generic function. This is what we'd like to have also for S3 generic
functions, but it's much harder to test for such since they're not
formally defined. However, I'd argue that it is safe to skip the
warning *when the variable to be imported does not actually exist in
the package being imported* (e.g. when just rexported), i.e.
>svn diff namespace.R
Index: namespace.R
===
--- namespace.R (revision 63776)
+++ namespace.R (working copy)
@@ -871,6 +871,10 @@
}
for (n in impnames)
if (exists(n, envir = impenv, inherits = FALSE)) {
+## warn only if imported variable actually exists in the
+## namespace imported from, which is not the case if
+## the variable is rexported from another namespace
+if (!exists(n, envir = ns, inherits = FALSE)) next
if (.isMethodsDispatchOn() && methods:::isGeneric(n, ns)) {
## warn only if generic overwrites a function which
## it was not derived from
I'm planning to propose ("wishlist / enhancement"; it may even be a
bug) this over at https://bugs.r-project.org/.
Comments, anyone?
/Henrik
> Paul
>
> Henrik Bengtsson wrote:
>
>>Hi,
>>
>>SETUP:
>>Consider three packages PkgA, PkgB and PkgC.
>>
>>PkgA defines a generic function foo() and exports it;
>>
>>export(foo)
>>
>>PkgB imports PkgA::foo() and re-exports it;
>>
>>importFrom(PkgA, foo)
>>export(foo)
>>
>>PkgC imports everything from PkgA and PkgB:
>>
>>imports(PkgA, PkgB)
>>
>>
>>PROBLEM:
>>Loading or attaching the namespace of PkgC will generate a warning:
>>
>> replacing previous import by 'PkgA::foo' when loading 'PkgC'
>>
>>This in turn causes 'R CMD check' on PkgC to generate a WARNING (no-go at
>>CRAN):
>>
>>* checking whether package 'PkgC' can be installed ... WARNING
>>Found the following significant warnings:
>> Warning: replacing previous import by 'PkgA::foo' when loading
>>'CellularAutomaton'
>>
>>
>>FALSE?
>>Isn't it valid to argue that this is a "false" warning, because
>>identical(PkgB::foo, PkgA::foo) is TRUE and therefore has no effect?
>>
>>
>>/Henrik
>>
>>PS. The above can be avoided by using explicit importFrom() on PkgA
>>and PkgB, but that's really tedious. In my case this is out of my
>>reach, because I'm the author of PkgA and PkgB but not ma
Re: [Rd] Problem with texi2pdf(..,clean=TRUE)
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?
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
[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
