Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)
Looks like someone forgot to update the DISTFILES (specifically the HEADERS) in src/main/Makefile.in... -pd On 19 Jul 2015, at 09:42 , Rainer Hurling rhur...@gwdg.de wrote: Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it still seems to be missing in the devel tarballs. (At least until R-devel_2015-07.18.tar.gz) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use cairo fallback resolution greater than 72dpi in cairo_pdf and cairo_ps in grDevices
On 18/07/2015 09:09, Prof Brian Ripley wrote: The 'at a minimum' information requested by the posting guide is missing. According to their documentation the cairo default fallback resolution is now 300dpi, and when I run your example on Fedora 21 that is what the emitted postscript says it is. You can easily alter the R code to set it to something different: see http://cairographics.org/manual/cairo-cairo-surface-t.html for the call you would need to add. I've added the ability to set the fallback resolution in R-devel, mainly because it seems to be system-specific (I still recommend using a bitmap format such as PNG directly). However, I would suggest that you generate a bitmap directly and use that, as PostScript does not support semi-transparency. On 14/07/2015 12:03, Tom Wenseleers wrote: Dear all, In grDevices R functions cairo_pdf and cairo_ps it is mentioned that when transparency (alpha channels) are used in vector output, it will rasterize the PDF or postscript exported graph at a resolution of 72 dpi : https://stat.ethz.ch/R-manual/R-devel/library/grDevices/html/cairo.html You can see the problem if you try library(ggplot2) cairo_ps(file = test.eps,onefile = FALSE) qplot(Sepal.Length, Petal.Length, data = iris, color = Species, size = Petal.Width, alpha = I(0.7)) dev.off() as in the output (here zoomed in) the plot symbols are heavily pixelated then, showing it is only using 72 dpi. I was wondering how the fallback resolution could be increased to 600 dpi? In library(RGtk2) there is a command cairoSurfaceSetFallbackResolution, which I think is what is relevant here, but I would not know how to make grDevices use that parameter. Any thoughts? Using postscript() btw also doesn't work, since that doesn't support transparency, and returns the error semi-transparency is not supported on this device: reported only once per page. I know I can use svg or pdf instead and that this would solve the problem, but problem is the journal (PloS) I would like to submit to only accepts EPS. So is there any solution to increase the quality in EPS, without having to rasterize everything to PNG? best regards, Tom Wenseleers [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)
Am 16.07.2015 um 14:08 schrieb Martin Maechler: Gábor Csárdi csardi.ga...@gmail.com on Thu, 16 Jul 2015 07:18:00 -0400 writes: ... making array.d from array.c array.c:33:23: fatal error: duplicate.h: No such file or directory compilation terminated. ... https://travis-ci.org/metacran/r-builder/builds/71225331#L7405 Yes. That's what R-devel is: in development and so, human errors do happen. ... and are corrected. ... already more than half an hour ago. Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it still seems to be missing in the devel tarballs. (At least until R-devel_2015-07.18.tar.gz) No need to trumpet to the world... I think (R-core would have been sufficient (and unnecessary this time)). ?? I also would have reported it on R-devel. Is this a special case with special handling? Sorry, when I have missed something. Best wishes, Rainer Hurling Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.packages(checkBuilt=TRUE, ask=FALSE): possible bug
On 19 Jul 2015, at 06:05 , Jose Claudio Faria joseclaudio.fa...@gmail.com wrote: Hello, version _ platform x86_64-w64-mingw32 arch x86_64 os mingw32 system x86_64, mingw32 status Patched major 3 minor 2.1 year 2015 month 07 day16 svn rev68681 language R version.string R version 3.2.1 Patched (2015-07-16 r68681) nickname World-Famous Astronaut I have the options below: options(pkgType='binary') options(install.packages.check.source='no') For some, but not allI repositories I get the error message below: Error in install.packages(update[instlib == l, Package], l, contriburl = contriburl, : specifying 'contriburl' or 'available' requires a single type, not type = both Is it a bug? Possibly, but I think you need to give a more reproducible example. In particular, which repositories and which packages? There is a fair amount of combinations to try... -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)
An updated tarball should be available in $CRAN/src/base/pre-release soon. (For CRAN=https://cran.r-project.org, immediately. Other mirrors need mirroring.) -pd On 19 Jul 2015, at 10:01 , peter dalgaard pda...@gmail.com wrote: Looks like someone forgot to update the DISTFILES (specifically the HEADERS) in src/main/Makefile.in... -pd On 19 Jul 2015, at 09:42 , Rainer Hurling rhur...@gwdg.de wrote: Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it still seems to be missing in the devel tarballs. (At least until R-devel_2015-07.18.tar.gz) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)
Am 19.07.2015 um 10:19 schrieb peter dalgaard: An updated tarball should be available in $CRAN/src/base/pre-release soon. (For CRAN=https://cran.r-project.org, immediately. Other mirrors need mirroring.) Wow, that's fast! Many thanks for the update. Greetings, Rainer Hurling -pd On 19 Jul 2015, at 10:01 , peter dalgaard pda...@gmail.com wrote: Looks like someone forgot to update the DISTFILES (specifically the HEADERS) in src/main/Makefile.in... -pd On 19 Jul 2015, at 09:42 , Rainer Hurling rhur...@gwdg.de wrote: Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it still seems to be missing in the devel tarballs. (At least until R-devel_2015-07.18.tar.gz) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 149, Issue 17
Thanks for your message! I am out of office until August 10, 2015. Your message will be answered after I return to office on August 11, 2015. Thank you in advance for your kind patience! Best regards, Ulrich Bodenhofer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.packages(checkBuilt=TRUE, ask=FALSE): possible bug
Dear Peter, I managed to reproduce the error in multiple repositories ( http://cran.at.r-project.org/, http://cran-r.c3sl.ufpr.br/, etc.). However, after rebooting the computer it was no longer possible to reproduce it. I'll be monitoring ... Best, ///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\ Jose Claudio Faria Estatistica UESC/DCET/Brasil joseclaudio.faria at gmail.com Telefones: 55(73)3680.5545 - UESC 55(73)9966.9100 - VIVO 55(73)9100.7351 - TIM 55(73)8817.6159 - OI 55(73)8129.9942 - CLARO ///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\ On Sun, Jul 19, 2015 at 4:50 AM, peter dalgaard pda...@gmail.com wrote: On 19 Jul 2015, at 06:05 , Jose Claudio Faria joseclaudio.fa...@gmail.com wrote: Hello, version _ platform x86_64-w64-mingw32 arch x86_64 os mingw32 system x86_64, mingw32 status Patched major 3 minor 2.1 year 2015 month 07 day16 svn rev68681 language R version.string R version 3.2.1 Patched (2015-07-16 r68681) nickname World-Famous Astronaut I have the options below: options(pkgType='binary') options(install.packages.check.source='no') For some, but not allI repositories I get the error message below: Error in install.packages(update[instlib == l, Package], l, contriburl = contriburl, : specifying 'contriburl' or 'available' requires a single type, not type = both Is it a bug? Possibly, but I think you need to give a more reproducible example. In particular, which repositories and which packages? There is a fair amount of combinations to try... -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Bioc-devel] changes to igraph break many Bioconductor packages (in release and devel)
Hello, The igraph package (in CRAN) recently had a major API change. The changes are detailed in its NEWS file: https://cran.r-project.org/web/packages/igraph/news.html The changes cause many Bioconductor packages to break in both release and devel. If you are the maintainer of one of the following packages, please see our build report (release: http://bioconductor.org/checkResults/release/bioc-LATEST/ ; devel: http://bioconductor.org/checkResults/devel/bioc-LATEST/ ) for a report of the error and fix it right away in release (if your package is in release) and devel. You should increment the package version number as well in order to cause your changes to propagate. BioNet CausalR facopy FEM * FGNet * geNetClassifier GenomicInteractions GenoView HTSanalyzeR netbiov * - these packages also need to be sure to import (in DESCRIPTION and NAMESPACE) the graph package. If you have any questions, please send them to the bioc-devel mailing list. Thanks, Dan ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] renaming a package
On 19/07/2015 6:19 PM, Jonathan Callahan wrote: We are developing a suite of three packages related to seismology. As I was dealing with 64 bit compilation issues that became apparent from a previous submission attempt, another package with the name 'seismic' was accepted to CRAN. This brings up two issues: 1) CRAN might wish to have better package naming guidelines than short and sweet, first come, first served. As the number of packages continues to rise, it might be useful to have java style *OrganizationPackage* naming. In our case, we are now going to release the core seismic data package as 'IRISSeismic'. I don't see a need for this. If you want to do it for your packages, go ahead. 2) What is the best practice for renaming a package that has already been accepted to CRAN? We had previously released a 'seismicRoll' package that we may now wish to rename 'IRISSeismicRoll'. Rename it and submit it. In your message to CRAN, mention that you are renaming it from seismicRoll, and say why the name seismicRoll is no longer appropriate. Don't do this too often, but there's no problem doing it occasionally, when there's a good reason to do so. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] renaming a package
On 20.07.2015 00:53, Duncan Murdoch wrote: On 19/07/2015 6:19 PM, Jonathan Callahan wrote: We are developing a suite of three packages related to seismology. As I was dealing with 64 bit compilation issues that became apparent from a previous submission attempt, another package with the name 'seismic' was accepted to CRAN. This brings up two issues: 1) CRAN might wish to have better package naming guidelines than short and sweet, first come, first served. As the number of packages continues to rise, it might be useful to have java style *OrganizationPackage* naming. In our case, we are now going to release the core seismic data package as 'IRISSeismic'. I don't see a need for this. If you want to do it for your packages, go ahead. 2) What is the best practice for renaming a package that has already been accepted to CRAN? We had previously released a 'seismicRoll' package that we may now wish to rename 'IRISSeismicRoll'. Rename it and submit it. In your message to CRAN, mention that you are renaming it from seismicRoll, and say why the name seismicRoll is no longer appropriate. Don't do this too often, but there's no problem doing it occasionally, when there's a good reason to do so. Thanks, and yes, CRAN will allow renaming in case there is a really good reason. Note that package names, once a package got renamed, cannot be used by others any more, hence we are allowing such a change only in rare cases with very good reasons... In the past not many maintainers succeeded to get us convinced... Best, Uwe Ligges Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
