[Rd] Fwd: help building very old R
Hi guys, Perhaps someone here can help. I am trying to build versions of R 1 for the rcheology package (just arrived on CRAN). For R prior to 1.5.0, I cannot configure support for tcl-tk. I am building on Debian Woody (provided by Docker debian/eol) and have the following packages installed: r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core I download R source from http://cran.r-project.org/src/base/R-1 and run ./configure --with-tcl-tk=yes --with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh --with-tk-config=/usr/lib/tk8.3/tkConfig.sh These are the locations for the relevant tkConfig.sh and tclConfig.sh files. This gives output as follows: R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local C compiler:gcc -g -O2 C++ compiler: c++ -g -O2 FORTRAN compiler: g77 -g -O2 X11 support: yes Gnome support: no Tcl/Tk support:no R profiling support: yes R as a shared library: no And config.log reveals: configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh configure:13204: checking for /usr/include/tcl8.3/tcl.h configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null 2>conftest.out configure:13313: checking for /usr/include/tk8.3/tk.h configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include -I/usr/include /tcl8.3 conftest.c >/dev/null 2>conftest.out configure:13319: /usr/include/tk8.3/tk.h: No such file or directory configure: failed program was: #line 13318 "configure" #include "confdefs.h" #include configure:13348: checking for /usr/include/tk.h configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include -I/usr/include /tcl8.3 conftest.c >/dev/null 2>conftest.out configure:13354: /usr/include/tk.h: No such file or directory configure: failed program was: #line 13353 "configure" #include "confdefs.h" #include configure:13385: checking for tk.h configure:13389: tk.h: No such file or directory In fact, tk.h is in /usr/include/tcl8.3/ , despite the failed program compilation report. R 1.5.0 and above work fine. Can anyone remember far back, if something changed in the configure script? Alternatively, those who are feeling brave can download the Docker image creation scripts from github.com/hughjonesd/rcheology . Cheers, David -- Sent from Gmail Mobile [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] apply with zero-row matrix
Forgive me if this has been asked many times before, but I couldn't find
anything on the mailing lists.
I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
rows.
In fact:
m <- matrix(NA, 0, 5)
apply(m, 1, function (x) {cat("Called...\n"); print(x)})
## Called...
## [1] FALSE FALSE FALSE FALSE FALSE
Similarly for apply(m, 2,...) if m has no columns.
Is there a reason for this? Could it be documented?
David
--
Sent from Gmail Mobile
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Handling larger data in vignette
Thanks Martin, I'll give the ExperimentHub package method a try then, if I can use it for vignette-only processed data. I think I was getting confused with annotationHub (which I gather is intended for useful-for-other-packages-or-applications raw data). Time should be ok - I just want to skip the long step on full-sized data. Sarah. On 27 July 2018 at 19:30, Martin Morgan wrote: > Remember also that there are overall evaluation time limits. > > One strategy might use existing stable publicly available SC data sets > from e.g., > > http://imlspenticton.uzh.ch:3838/conquer/ > https://hemberg-lab.github.io/scRNA.seq.datasets/ > > These could be downloaded using BiocFileCache as a first step in the > vignette ; the download cost would be 'paid' the first time, but subsequent > use would be from the locally cached data. > > A second approach would be to create an ExperimentHub package, and to use > that in your examples. > > http://bioconductor.org/packages/devel/ExperimentHub > > http://bioconductor.org/packages/devel/bioc/vignettes/Experi > mentHub/inst/doc/CreateAnExperimentHubPackage.html > > The submission process would start by submitting the EH package, and then > adding, once the kinks in the experiment data package are worked out, the > software package to the issue. The data and software packages would be > accepted together. > > Martin > > > On 07/27/2018 02:38 AM, Sarah Williams via Bioc-devel wrote: > >> Hi, >> >> I'm preparing a package for submission to bioconductor, but hitting the >> 4mb >> size limit due to examples in my vignette. >> >> I do have a demo toy sized dataset which I use for the bulk of the >> vignette. But I wanted to show real-data examples at the end because >> approach doesn't work well on toy-sized data. >> >> Conceivably everything except for the 'examples' section would make a >> 'complete' vignette (but probably not a very helpful one...). I'm >> wondering >> if I should static-ify just those examples? Might hit the 50% runnable >> code-chunk limit then though. Unfortunately its a rank-based approach so i >> can't really take the top 100 genes for these particuar objects. >> >> Not sure how best to solve this, any tips/suggestions? Thanks! >> >> (The problematic vignette is here: >> https://bioinformatics.erc.monash.edu/home/sarah.williams/pr >> ojects/cell_groupings/doco/celaref_doco.html >> ) >> >> NB: To make matters worse this is a tool for comparing datasets - so I >> have >> multiples! They are public datasets and I haven't done anything exciting >> with them (nor would anyone else want to reuse processed objects) - so I >> don't think that I should make a data package. >> >> NB: Using xz compression and some cleanup I got it down to 21mb, from 49mb >> - So its not huge but I don't think I can get to <4mb this way. >> >> [[alternative HTML version deleted]] >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> > > This email message may contain legally privileged and/or confidential > information. If you are not the intended recipient(s), or the employee or > agent responsible for the delivery of this message to the intended > recipient(s), you are hereby notified that any disclosure, copying, > distribution, or use of this email message is prohibited. If you have > received this message in error, please notify the sender immediately by > e-mail and delete this email message from your computer. Thank you. > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Possible To Enable Building R With Cairo But Without X11 Dependencies?
Thanks for the reply, Dirk. It sounds like xvfb-run is a great solution when you want R to assume an X window system is present but isn’t? I think what I'm trying to figure out, and propose for the community to possibly fix, is slightly different than would be solved by xvfb-run. I'm wondering if --with-cairo presents a design flaw (maybe an abstraction inversion https://en.wikipedia.org/wiki/Abstraction_inversion) wherein the window system is taken for granted to be X and there is no way to change it/use Cairo differently? This has at least two consequences that I understand: - Most importantly, it makes --with-cairo silently incompatible with --without-x. If this is really intended, I think it should at least raise a warning? - I think it also means, (as far as I know, but could well be wrong), that there is not a way to use R where you rely solely Cairo’s rendering abilities to replace the complexity of needing a specific window system present? (This is my use case -- use cairo so R can be agnostic about a window system). Given that the earlier conversations made a fix sound rather trivial (use cairo.h instead of cairo-xlib.h), I’m wondering if there is a path to getting that implemented? Thanks a lot, -Stephen Marsh On Wed, Jul 25, 2018 at 9:35 PM, Dirk Eddelbuettel wrote: > > On 25 July 2018 at 21:04, Stephen Marsh wrote: > | So the Homebrew community dropped support for --with-cairo which is a > shame > | because --without-x --with-cairo is an important combination for any > | environment that might need to generate graphics without X11 (or related) > | dependencies (macOS, headless linux servers). > > For headless use on Linux, just build as usual and run via `xvfb-run`. If > you > need to create cairo-based graphics, install one of the (at least two) > cairo > device packages from CRAN. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- stephenmarsh.co [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odd behavior of names
Bugzilla issue 16101 describes another first-list-name-printed-differently oddity with the Windows GUI version of R: > a <- "One is \u043E\u0434\u0438\u043D\nTwo is \u0434\u0432\u0430\n" > Encoding(a) # expect "UTF-8" [1] "UTF-8" > sapply(strsplit(a, "\n")[[1]], charToRaw)[c(1,1,2)] $`One is один` [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0 [13] b8 d0 bd $`One is ` [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0 [13] b8 d0 bd $`Two is ` [1] 54 77 6f 20 69 73 20 d0 b4 d0 b2 d0 [13] b0 > names(.Last.value) [1] "One is один" "One is один" [3] "Two is два" Bill Dunlap TIBCO Software wdunlap tibco.com On Sun, Jul 29, 2018 at 8:45 AM, David Winsemius wrote: > > > On Jul 29, 2018, at 6:31 AM, Gabor Grothendieck > wrote: > > > > The first component name has backticks around it and the second does > > not. Though not wrong, it seems inconsistent. > > > > list(a = 1, b = 2) > > ## $`a` > > ## [1] 1 > > ## > > ## $b > > ## [1] 2 > > > > R.version.string > > ## [1] "R version 3.5.1 Patched (2018-07-02 r74950)" > > Agree it would be unexpected. Unable to reproduce on Mac: > > list(a = 1, b = 2) > #-- > $a > [1] 1 > > $b > [1] 2 > > R.version.string > #[1] "R version 3.5.1 (2018-07-02)" > Platform: x86_64-apple-darwin15.6.0 (64-bit) > > > > > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > David Winsemius > Alameda, CA, USA > > 'Any technology distinguishable from magic is insufficiently advanced.' > -Gehm's Corollary to Clarke's Third Law > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odd behavior of names
> On Jul 29, 2018, at 6:31 AM, Gabor Grothendieck > wrote: > > The first component name has backticks around it and the second does > not. Though not wrong, it seems inconsistent. > > list(a = 1, b = 2) > ## $`a` > ## [1] 1 > ## > ## $b > ## [1] 2 > > R.version.string > ## [1] "R version 3.5.1 Patched (2018-07-02 r74950)" Agree it would be unexpected. Unable to reproduce on Mac: list(a = 1, b = 2) #-- $a [1] 1 $b [1] 2 R.version.string #[1] "R version 3.5.1 (2018-07-02)" Platform: x86_64-apple-darwin15.6.0 (64-bit) > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] odd behavior of names
The first component name has backticks around it and the second does not. Though not wrong, it seems inconsistent. list(a = 1, b = 2) ## $`a` ## [1] 1 ## ## $b ## [1] 2 R.version.string ## [1] "R version 3.5.1 Patched (2018-07-02 r74950)" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
