Re: [Rd] optional package dependency
Jeff Ryan writes: Hi Ross, The quantmod package makes available routines from a variety of contributed packages, but gets around your issues with a bit of, um, trickery. Take a look here (unless your name is Kurt ;-) ): But Kurt will we happy to tell you that you can turn off forcing suggested packages for checking by setting _R_CHECK_FORCE_SUGGESTS_=false in your environment. The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. -k http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367root=quantmodview=markup It would be nice to have Suggests really mean suggests to check, but I am sure there is a good reason it doesn't. HTH Jeff On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan r...@biostat.ucsf.edu wrote: I have a package that can use rmpi, but works fine without it. None of the automatic test code invokes rmpi functionality. (One test file illustrates how to use it, but has quit() as its first command.) What's the best way to handle this? In particular, what is the appropriate form for upload to CRAN? When I omitted rmpi from the DESCRITPION file R CMD check gave quote * checking R code for possible problems ... NOTE alldone: no visible global function definition for ‘mpi.bcast.Robj’ alldone: no visible global function definition for ‘mpi.exit’ quote followed by many more warnings. When I add Suggests: Rmpi in DESCRIPTION the check stops if the package is not installed: quote * checking package dependencies ... ERROR Packages required but not available: Rmpi /quote Rmpi is not required, but I gather from previous discussion on this list that suggests basically means required for R CMD check. NAMESPACE seems to raise similar issues; I don't see any mechanism for optional imports. Also, I have not used namespaces, and am not eager to destabilize things so close to release. At least, I hope I'm close to release :) Thanks for any advice. Ross Boylan P.S. Thanks, Duncan, for your recent advice on my help format problem with R 2.7. I removed the nested \description, and now things look OK. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ 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] optional package dependency
How about using: Enhances: Rmpi ? b On Fri, Jan 15, 2010 at 6:00 AM, Ross Boylan r...@biostat.ucsf.edu wrote: I have a package that can use rmpi, but works fine without it. None of the automatic test code invokes rmpi functionality. (One test file illustrates how to use it, but has quit() as its first command.) What's the best way to handle this? In particular, what is the appropriate form for upload to CRAN? When I omitted rmpi from the DESCRITPION file R CMD check gave quote * checking R code for possible problems ... NOTE alldone: no visible global function definition for ‘mpi.bcast.Robj’ alldone: no visible global function definition for ‘mpi.exit’ quote followed by many more warnings. When I add Suggests: Rmpi in DESCRIPTION the check stops if the package is not installed: quote * checking package dependencies ... ERROR Packages required but not available: Rmpi /quote Rmpi is not required, but I gather from previous discussion on this list that suggests basically means required for R CMD check. NAMESPACE seems to raise similar issues; I don't see any mechanism for optional imports. Also, I have not used namespaces, and am not eager to destabilize things so close to release. At least, I hope I'm close to release :) Thanks for any advice. Ross Boylan P.S. Thanks, Duncan, for your recent advice on my help format problem with R 2.7. I removed the nested \description, and now things look OK. __ 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] adapt package missing because of licensing issue: fix?
On 14.01.2010 23:25, Ben Bolker wrote: I think this is probably known by someone, but I wanted to ask/comment: The 'adapt' package has been removed from CRAN because of an 'unclear' license. That makes sense, but it actually took a bit of digging for me to discover that, and if I had been a student I might not have figured it out. The package is simply missing from the CRAN compiled packages page; I did find information in the check summaries; but I didn't get a clear indication until I found http://cran.r-project.org/web/packages/adapt/index.html by googling (which also gave me a handy link to the archives). https://stat.ethz.ch/pipermail/r-sig-fedora/2009-June/78.html http://packages.debian.org/changelogs/pool/main/a/adapt/adapt_1.0-4-3/r-cran-adapt.copyright give a little more information. library(findFn); sos(multidimensional+integration) found the cubature package for me, which looks like a pretty good replacement but which I haven't tried out yet. My real question: has anyone actually tried to contact the authors and find out if they are willing to put the code under a suitably redistributable license? I can't find anything that suggests that they *don't* want it redistributed ... ? Would it be helpful if I did this, or is this the sort of thing the package maintainer should do? Ben, the package maintainer is the one who decides about the license under the given restrictions. I guess you meant the CRAN maintainer? Anyway, be sure that the package maintainer has been notified about the license problem by the CRAN maintainers. The CRAN maintainers do not remove a package without asking the corresponding package maintainer (most often more than once) to fix open issues. Best wishes, Uwe Mike Meyer: mi...@andrew.cmu.edu Alan Genz: g...@gauss.math.wsu.edu cheers Ben Bolker __ 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] Using multicore with an open pdf device results in corrupt pdf (PR#14186)
The attached code produces corrupted pdfs (test2.pdf, test4.pdf and
test5.pdf). The resulting pdf depends on how many cores are available on
the machine.
I don't see why there should be any difference between the pdfs (exept for
the timestamp). Doing many operations involving mclapply can increase the
size of the resulting pdf by ten times!
Thank you for checking this.
require(multicore)
pdf('test.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 3)
pdf('test2.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
pdf('test3.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 2)
pdf('test4.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 8)
pdf('test5.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
--please do not edit the information below--
Version:
platform = x86_64-unknown-linux-gnu
arch = x86_64
os = linux-gnu
system = x86_64, linux-gnu
status =
major = 2
minor = 10.1
year = 2009
month = 12
day = 14
svn rev = 50720
language = R
version.string = R version 2.10.1 (2009-12-14)
Locale:
LC_CTYPE=de_CH.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=de_CH.UTF-8;LC_MONETARY=C;LC_MESSAGES=de_CH.UTF-8;LC_PAPER=de_CH.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_CH.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:skewt, package:rgl, package:ggplot2, package:reshape,
package:plyr, package:proto, package:VGAM, package:stats4, package:splines,
package:latticeExtra, package:RColorBrewer, package:doMC, package:multicore,
package:foreach, package:codetools, package:iterators, package:abind,
package:seqinr, package:mvbutils, mvb.session.info, package:tools,
package:robust, package:rrcov, package:pcaPP, package:mvtnorm,
package:robustbase, package:MASS, package:glmmML, package:playwith,
package:grid, package:gWidgetsRGtk2, package:cairoDevice, package:lattice,
package:gWidgets, package:graphics, package:grDevices, package:datasets,
package:fortunes, package:sfsmisc, package:stats, package:utils,
package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
On 1/15/10 12:19 AM, Kurt Hornik wrote: Jeff Ryan writes: Hi Ross, The quantmod package makes available routines from a variety of contributed packages, but gets around your issues with a bit of, um, trickery. Take a look here (unless your name is Kurt ;-) ): I believe another option is: pkg - somePkg pkgAvail - require(pkg, character.only = TRUE) if (pkgAvail) ... else ... But Kurt will we happy to tell you that you can turn off forcing suggested packages for checking by setting _R_CHECK_FORCE_SUGGESTS_=false in your environment. The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. Unless the public repositories such as CRAN and Bioconductor decide to set this option, it provides no solution for anyone who maintains or plans to make available a package through a public R repository such as CRAN or Bioconductor. There is a real need (of some kind) here. Not all packages work on all platforms. For example, the multicore package provides a mechanism for running parallel computations on a multi-cpu box, but it is not available on Windows. A package that _is_ available on all platforms should be able to optionally make use of multicore on non-Windows. I don't think there is a way to do that now and pass check without resorting to tricks as above. These tricks are bad as they make it harder to programmatically determine the true suggests. And NAMESPACE brings up another issue in that being able to do conditional imports would be very useful for these cases, otherwise you simply can't make proper use of name spaces for any optional functionality. I'm willing to help work on and test a solution if we can arrive at some consensus as to what the solution looks like. Best, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
On Jan 15, 2010, at 10:22 , Seth Falcon wrote: On 1/15/10 12:19 AM, Kurt Hornik wrote: Jeff Ryan writes: Hi Ross, The quantmod package makes available routines from a variety of contributed packages, but gets around your issues with a bit of, um, trickery. Take a look here (unless your name is Kurt ;-) ): I believe another option is: pkg - somePkg pkgAvail - require(pkg, character.only = TRUE) if (pkgAvail) ... else ... That is not an option - that is the code you usually use with Suggests: (except for the pkg assignment which is there I presume to obscure things). But Kurt will we happy to tell you that you can turn off forcing suggested packages for checking by setting _R_CHECK_FORCE_SUGGESTS_=false in your environment. The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. Unless the public repositories such as CRAN and Bioconductor decide to set this option, it provides no solution for anyone who maintains or plans to make available a package through a public R repository such as CRAN or Bioconductor. There is a real need (of some kind) here. Not all packages work on all platforms. For example, the multicore package provides a mechanism for running parallel computations on a multi-cpu box, but it is not available on Windows. A package that _is_ available on all platforms should be able to optionally make use of multicore on non-Windows. I don't think there is a way to do that now ... there are 10 packages on CRAN that officially suggest multicore and there is no issue with their checks. I suspect you are making up an issue here that doesn't really exist ... As Kurt pointed out the checking is optional and makes sense to test the optional capability. You'd have to ask him but I don't think Kurt refuses packages because they suggest something that is not available everywhere ... and pass check without resorting to tricks as above. These tricks are bad as they make it harder to programmatically determine the true suggests. Hence I don't see why your should even pst them ;). Cheers, Simon And NAMESPACE brings up another issue in that being able to do conditional imports would be very useful for these cases, otherwise you simply can't make proper use of name spaces for any optional functionality. I'm willing to help work on and test a solution if we can arrive at some consensus as to what the solution looks like. Best, + seth __ 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] optional package dependency
On 15.01.2010 16:22, Seth Falcon wrote: On 1/15/10 12:19 AM, Kurt Hornik wrote: Jeff Ryan writes: Hi Ross, The quantmod package makes available routines from a variety of contributed packages, but gets around your issues with a bit of, um, trickery. Take a look here (unless your name is Kurt ;-) ): I believe another option is: pkg- somePkg pkgAvail- require(pkg, character.only = TRUE) if (pkgAvail) ... else ... But Kurt will we happy to tell you that you can turn off forcing suggested packages for checking by setting _R_CHECK_FORCE_SUGGESTS_=false Seth, the Windows checks for CRAN run with that setting, i.e. _R_CHECK_FORCE_SUGGESTS_=false Hence the multicore issue mentioned below actually does not exist. Best, Uwe in your environment. The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. Unless the public repositories such as CRAN and Bioconductor decide to set this option, it provides no solution for anyone who maintains or plans to make available a package through a public R repository such as CRAN or Bioconductor. There is a real need (of some kind) here. Not all packages work on all platforms. For example, the multicore package provides a mechanism for running parallel computations on a multi-cpu box, but it is not available on Windows. A package that _is_ available on all platforms should be able to optionally make use of multicore on non-Windows. I don't think there is a way to do that now and pass check without resorting to tricks as above. These tricks are bad as they make it harder to programmatically determine the true suggests. And NAMESPACE brings up another issue in that being able to do conditional imports would be very useful for these cases, otherwise you simply can't make proper use of name spaces for any optional functionality. I'm willing to help work on and test a solution if we can arrive at some consensus as to what the solution looks like. Best, + seth __ 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] optional package dependency
On Fri, 15 Jan 2010, Seth Falcon wrote: There is a real need (of some kind) here. Not all packages work on all platforms. For example, the multicore package provides a mechanism for running parallel computations on a multi-cpu box, but it is not available on Windows. A package that _is_ available on all platforms should be able to optionally make use of multicore on non-Windows. I don't think there is a way to do that now and pass check without resorting to tricks as above. These tricks are bad as they make it harder to programmatically determine the true suggests. And NAMESPACE brings up another issue in that being able to do conditional imports would be very useful for these cases, otherwise you simply can't make proper use of name spaces for any optional functionality. I'm willing to help work on and test a solution if we can arrive at some consensus as to what the solution looks like. Seth, In the case of multicore it seems to work to put it in 'Suggests' and to use require() to load it. That's what I did with the survey package, and it didn't cause problems on CRAN. I didn't run CMD check on Windows myself, only on Mac and Linux. A more difficult issue is providing methods for a generic in another package that might not be available. I wanted to provide methods on survey objects for generics in odfWeave, and I couldn't find out how to do that without making it required. I ended up creating a new odfWeave.survey package that depends on odfWeave and survey, but this seems like the sort of thing that should be able to be done with Enhances or Suggests. -thomas Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote: The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. This might be the nub of the problem. There are different audiences, even for R CMD check. The maintainer probably wants to check all functionality. Even then, there is an issue if functionality differs by platform. CRAN probably wants to check all functionality. An individual user just wants to check the functionality they use. For example, if someone doesn't want to run my package distributed, but wants to see if it works (R CMD check), they need to be able to avoid the potentially onerous requirement to install MPI. Ross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
On Jan 15, 2010, at 12:18 , Ross Boylan wrote: On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote: The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. This might be the nub of the problem. There are different audiences, even for R CMD check. The maintainer probably wants to check all functionality. Even then, there is an issue if functionality differs by platform. CRAN probably wants to check all functionality. An individual user just wants to check the functionality they use. For example, if someone doesn't want to run my package distributed, but wants to see if it works (R CMD check), they need to be able to avoid the potentially onerous requirement to install MPI. ... that what's why you can decide to run check without forcing suggests - it's entirely up to you / the user as Kurt pointed out ... Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using multicore with an open pdf device results in corrupt pdf (PR#14186)
How is this a bug in R? First, multicore is not R. Second, you're
running multicore with GUI code loaded which it explicitly tells you
that it won't work. Third, the code you provided does produce correct
PDFs (tested on the same platform you provided) in a clean session
(unsurprisingly).
Cheers,
Simon
On Jan 15, 2010, at 9:15 , kolle...@stat.math.ethz.ch wrote:
The attached code produces corrupted pdfs (test2.pdf, test4.pdf and
test5.pdf). The resulting pdf depends on how many cores are
available on
the machine.
I don't see why there should be any difference between the pdfs
(exept for
the timestamp). Doing many operations involving mclapply can
increase the
size of the resulting pdf by ten times!
Thank you for checking this.
require(multicore)
pdf('test.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 3)
pdf('test2.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
pdf('test3.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 2)
pdf('test4.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 8)
pdf('test5.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
--please do not edit the information below--
Version:
platform = x86_64-unknown-linux-gnu
arch = x86_64
os = linux-gnu
system = x86_64, linux-gnu
status =
major = 2
minor = 10.1
year = 2009
month = 12
day = 14
svn rev = 50720
language = R
version.string = R version 2.10.1 (2009-12-14)
Locale:
LC_CTYPE
=
de_CH
.UTF
-8
;LC_NUMERIC
=
C
;LC_TIME
=
en_US
.UTF
-8
;LC_COLLATE
=
de_CH
.UTF
-8
;LC_MONETARY
=
C
;LC_MESSAGES
=
de_CH
.UTF
-8
;LC_PAPER
=
de_CH
.UTF
-8
;LC_NAME
=
C
;LC_ADDRESS
=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_CH.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:skewt, package:rgl, package:ggplot2,
package:reshape, package:plyr, package:proto, package:VGAM,
package:stats4, package:splines, package:latticeExtra,
package:RColorBrewer, package:doMC, package:multicore,
package:foreach, package:codetools, package:iterators,
package:abind, package:seqinr, package:mvbutils, mvb.session.info,
package:tools, package:robust, package:rrcov, package:pcaPP,
package:mvtnorm, package:robustbase, package:MASS, package:glmmML,
package:playwith, package:grid, package:gWidgetsRGtk2,
package:cairoDevice, package:lattice, package:gWidgets,
package:graphics, package:grDevices, package:datasets,
package:fortunes, package:sfsmisc, package:stats, package:utils,
package:methods, Autoloads, package:base
__
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] optional package dependency (enhances)
On Fri, 2010-01-15 at 10:48 +, Benilton Carvalho wrote: How about using: Enhances: Rmpi ? b The main reason is that enhances seems a peculiar way to describe the relation between a package that (optionally) uses a piece of infrastructure and the infrastructure. Similarly, I would not say that a car enhances metal. The example given in the R extension documentation (e.g., by providing methods for classes from these packages) seems more in line with the usual meaning of enhance. A secondary reason is that I can not tell from the documentation exactly what putting a package in enhances does. The example of adding functionality to a class suggests that packages that are enhanced are required. However, clearly one could surround code that enhanced a class from another package with a conditional, so that if the code was skipped if the enhanced package was absent. Even that logic isn't quite right if the enhanced package is added later. My package only loads/verifies the presence of rmpi if one attempts to use the distributed features, so the relation is at run time, not load time. Ross On Fri, Jan 15, 2010 at 6:00 AM, Ross Boylan r...@biostat.ucsf.edu wrote: I have a package that can use rmpi, but works fine without it. None of the automatic test code invokes rmpi functionality. (One test file illustrates how to use it, but has quit() as its first command.) What's the best way to handle this? In particular, what is the appropriate form for upload to CRAN? When I omitted rmpi from the DESCRITPION file R CMD check gave quote * checking R code for possible problems ... NOTE alldone: no visible global function definition for ‘mpi.bcast.Robj’ alldone: no visible global function definition for ‘mpi.exit’ quote followed by many more warnings. When I add Suggests: Rmpi in DESCRIPTION the check stops if the package is not installed: quote * checking package dependencies ... ERROR Packages required but not available: Rmpi /quote Rmpi is not required, but I gather from previous discussion on this list that suggests basically means required for R CMD check. NAMESPACE seems to raise similar issues; I don't see any mechanism for optional imports. Also, I have not used namespaces, and am not eager to destabilize things so close to release. At least, I hope I'm close to release :) Thanks for any advice. Ross Boylan P.S. Thanks, Duncan, for your recent advice on my help format problem with R 2.7. I removed the nested \description, and now things look OK. __ 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] optional package dependency (suggestions/wishes)
On Fri, 2010-01-15 at 12:34 -0500, Simon Urbanek wrote: On Jan 15, 2010, at 12:18 , Ross Boylan wrote: On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote: The idea is that maintainers typically want to fully check their functionality, suggesting to force suggests by default. This might be the nub of the problem. There are different audiences, even for R CMD check. The maintainer probably wants to check all functionality. Even then, there is an issue if functionality differs by platform. CRAN probably wants to check all functionality. An individual user just wants to check the functionality they use. For example, if someone doesn't want to run my package distributed, but wants to see if it works (R CMD check), they need to be able to avoid the potentially onerous requirement to install MPI. ... that what's why you can decide to run check without forcing suggests - it's entirely up to you / the user as Kurt pointed out ... Cheers, Simon This prompts a series of increasing ambitious suggestions: 1. DOCUMENTATION CHANGE I suggest this info about _R_CHECK_FORCE_SUGGESTS_=false be added to R CMD check --help. Until Kurt's email I was unaware of the facility, and it seems to me the average package user will be even less likely to know. My concern is that they would run R CMD check; it would fail because a package such as rmpi is absent; and the user will throw up their hands and give up. I did find a Perl variable with similar name in section 1.3.3 of Writing R Extensions, but that section does not mention environment variables. It would also be unnatural for a package user to refer to it. Considering there are many variables, maybe the interactive help should just note that customizing variables (without naming particular ones) are available, and point to appropriate documentation 2. NEW BEHAVIOR/OPTIONS On even more exotic wish would be to allow a list of suggested packages to check. That way, someone use some, but not all, optional facilities could check the ones of interest. Again, even with better documentation it seems likely most people would be unaware of the feature. 3. SIGNIFICANTLY CHANGED BEHAVIOR I think the optimal behavior would be for the check environment to attempt to load all suggested packages, but continue even if some are missing. It would then be up to package authors to code appropriate conditional tests for the presence or absence of suggested packages; actually, that's probably true even now. Ross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using multicore with an open pdf device results in corrupt pdf (PR#14186)
Well I guess there's no point in starting a discussion here. I can also do all
calculations, gather the plots in a list before starting the pdf device and
plot them later. But just to prove my point: the attached pdfs (generated in a
clean session, on the system used to generate the bug report) are not
identical. They might display fine with some pdf viewers, but at least Adobe
Reader 9.3.0 on OS X refuses to display test4.pdf.
Regards,
Manuel
On 15.01.2010, at 18:48, Simon Urbanek wrote:
How is this a bug in R? First, multicore is not R. Second, you're running
multicore with GUI code loaded which it explicitly tells you that it won't
work. Third, the code you provided does produce correct PDFs (tested on the
same platform you provided) in a clean session (unsurprisingly).
Cheers,
Simon
On Jan 15, 2010, at 9:15 , kolle...@stat.math.ethz.ch wrote:
The attached code produces corrupted pdfs (test2.pdf, test4.pdf and
test5.pdf). The resulting pdf depends on how many cores are available on
the machine.
I don't see why there should be any difference between the pdfs (exept for
the timestamp). Doing many operations involving mclapply can increase the
size of the resulting pdf by ten times!
Thank you for checking this.
require(multicore)
pdf('test.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 3)
pdf('test2.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
pdf('test3.pdf')
y - unlist(lapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 2)
pdf('test4.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
options(cores = 8)
pdf('test5.pdf')
y - unlist(mclapply(1:50, identity))
plot(y)
print(y)
dev.off()
--please do not edit the information below--
Version:
platform = x86_64-unknown-linux-gnu
arch = x86_64
os = linux-gnu
system = x86_64, linux-gnu
status =
major = 2
minor = 10.1
year = 2009
month = 12
day = 14
svn rev = 50720
language = R
version.string = R version 2.10.1 (2009-12-14)
Locale:
LC_CTYPE=de_CH.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=de_CH.UTF-8;LC_MONETARY=C;LC_MESSAGES=de_CH.UTF-8;LC_PAPER=de_CH.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_CH.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:skewt, package:rgl, package:ggplot2, package:reshape,
package:plyr, package:proto, package:VGAM, package:stats4, package:splines,
package:latticeExtra, package:RColorBrewer, package:doMC, package:multicore,
package:foreach, package:codetools, package:iterators, package:abind,
package:seqinr, package:mvbutils, mvb.session.info, package:tools,
package:robust, package:rrcov, package:pcaPP, package:mvtnorm,
package:robustbase, package:MASS, package:glmmML, package:playwith,
package:grid, package:gWidgetsRGtk2, package:cairoDevice, package:lattice,
package:gWidgets, package:graphics, package:grDevices, package:datasets,
package:fortunes, package:sfsmisc, package:stats, package:utils,
package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
!DSPAM:4b50aa7856519769714416!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] order() fails on a chr object of class AsIs with \265 in it
Here's an example (session info at the end).
tmpv - c('\265g/L','Bq/L')
order(tmpv)
[1] 2 1
tmpv - I(tmpv)
order(tmpv)
Error in if (xi xj) 1L else -1L : missing value where TRUE/FALSE needed
foov - gsub('\265','',tmpv)
order(foov)
[1] 2 1
str(tmpv)
Class 'AsIs' chr [1:2] \265g/L Bq/L
str(foov)
Class 'AsIs' chr [1:2] g/L Bq/L
I can easily work around this in my scripts, but shouldn't order()
succeed with such an object?
(I suppose this could be Mac-specific, but I'm assuming it's not...)
For context:
The character \265 causes the Greek letter mu to be displayed in
various output devices. For example, the character vector eventually
gets written to an html file, which when displayed in Firefox (Mac)
is displayed as Greek mu. Also in Excel 2004 (Mac).
I first wrote these scripts 6 years ago, when \265 was a way I
could find to display the Greek mu in output text files of various
kinds. They worked as recently as 3 months ago. Maybe there's a
better way now to display a mu in text-based contexts?
sessionInfo()
R version 2.10.1 (2009-12-14)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order() fails on a chr object of class AsIs with \265 in it
On Fri, 15 Jan 2010, Don MacQueen wrote:
Here's an example (session info at the end).
tmpv - c('\265g/L','Bq/L')
order(tmpv)
[1] 2 1
tmpv - I(tmpv)
order(tmpv)
Error in if (xi xj) 1L else -1L : missing value where TRUE/FALSE needed
foov - gsub('\265','',tmpv)
order(foov)
[1] 2 1
str(tmpv)
Class 'AsIs' chr [1:2] \265g/L Bq/L
str(foov)
Class 'AsIs' chr [1:2] g/L Bq/L
I can easily work around this in my scripts, but shouldn't order() succeed
with such an object?
Not in the C locale. There is no pre-defined ordering for non-ASCII
characters in that locale and the string is invalid in a strict C
locale.
(I suppose this could be Mac-specific, but I'm assuming it's not...)
No, but the handling of invalid strings in C is OS-specific.
For context:
The character \265 causes the Greek letter mu to be displayed in various
output devices. For example, the character vector eventually gets written to
an html file, which when displayed in Firefox (Mac) is displayed as Greek mu.
Also in Excel 2004 (Mac).
I first wrote these scripts 6 years ago, when \265 was a way I could find
to display the Greek mu in output text files of various kinds. They worked as
recently as 3 months ago. Maybe there's a better way now to display a mu in
text-based contexts?
Use UTF-8 and Unicode \u03BC
(http://www.alanwood.net/unicode/greek.html).
The issue is that you need a xtfrm method for 'AsIs': it falls back to
comparisons via .gt and those (correctly) fail.
xtfrm.AsIs - function(x) xtfrm(unclass(x))
would keep get you going until you fix the scripts.
sessionInfo()
R version 2.10.1 (2009-12-14)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
