[Rd] A patchwork indeed
Let me be clear up front that I do not want to start any major discussions, merely to share some observations. We discussed at length what it would mean if R was extended to allow a plus sign to concatenate text when the operands were both of the right types that made sense for the purpose so that, as in a language like Python: "Hello " + "World!" would result in the obvious concatenation and not as an error. It might be a way to call perhaps a limited functionality of paste0() as an example. So, I was studying an R package called patchwork and looking at it from a perspective in that it slightly extends the way ggplot uses the plus sign when applied to objects of certain classes. Patchwork does allow something like some form of (many types) of graphic objects to be displayed left to right (or in a grid) by just typing p1 + p2 + p3 BUT it goes a bit nuts and overlays lots of operators so that: (p1 | p2) / p3 results in the first two taking up half each of a top row and the third in the next row and wide. You can of course make all kinds of adjustments but the point is that those symbols are in a sense overlaid from their default meanings. there is also a meaning (a tad obscure) for a unary negative sign as in - p1 And, without explanation here, the symbols * and & also are used in new ways. I note the obvious that the normal precedence rules in R for these symbols/operators are NOT changed so you often need to use extra levels of parentheses to guarantee the order of evaluation. Clearly anyone reading your code that has not thoroughly read the manual for the package will be even more mystified than people are about ggplot and the plus sign, or the pipe symbols used in the tidyverse and even the new one now in base R. But my point is that it looks like doing it is quite possible and small isolated worlds can benefit from the notational simplicity. Having said that, this package also allows you to bypass all of this and use more standard functions that generally get you the same results. Since manipulating graphs and subgraphs generally does not require combining the above symbols alongside their other normal usage, this may look harmless and if you come from languages that routinely allow operators to be overloaded or polymorphic, looks fine. I am providing this info, not to make a case for doing anything but to ask if it makes sense to document acceptable methods for others, perhaps using their own created objects, to do such effects. In case anyone is curious, start here for a sort of tutorial: https://patchwork.data-imaginist.com/ Again, not advocating, just providing an example, no doubt among many others, where R is used in an extended way that can be useful. But of course moving R to be fully object-oriented in the same way as some other specific language is not a valid goal. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "getOption(max.print) omitted %d entries" may be negative
On 1/3/22 6:15 PM, Martin Maechler wrote:
Hugh Parsonage
on Wed, 29 Dec 2021 00:36:51 +1100 writes:
> In src/main/printvector.c in the definition of printVector and
> printNamedVector (and elsewhere):
> Rprintf(" [ reached getOption(\"max.print\") -- omitted %d entries ]\n",
> n - n_pr);
> Though n - n_pr is of type R_xlen_t so may not be representable as
> int. In practice negative values may be observed for long vectors.
> Rprintf(" [ reached getOption(\"max.print\") -- omitted %lld entries
]\n",
> n - n_pr);
Thank you Hugh, for finding and reporting this,
including a proposed remedy.
At some point in time, I think the %lld format specifier was
not portable enough to all versions of C compiler / libraries
that were considered valid for compiling R.
See e.g.,
https://stackoverflow.com/questions/462345/format-specifier-for-long-long
which says that "it" does not work on Windows.
Maybe this has changed now that we require C99 and also that
since R version 4.0.0 (or 4.0.1) we also use a somewhat more
recent version of gcc also on Windows?
... ah, searching the R sources reveals uses of %lld
*plus*
#ifdef Win32
#include /* for %lld */
#endif
so it seems we can and should probably change this ...
UCRT on Windows supports the C99 format, so %lld works, but there is a
bug in GCC which causes a compilation warning to appear for %lld.
There is an open GCC bug report with a patch. It has not been adopted,
yet, but I got reviews from two people and patched the build of GCC in
Rtools42. So, %lld etc now works without a warning for us on Windows and
certainly can be used in package code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
For base R, as we have been using the trio remap to get rid of the
warning with %lld, it would make sense to keep doing this for
consistency. Eventually we might be able to remove the dependency on
trio, after checking that the other problems due to which we use it have
been resolved in UCRT.
Tomas
[Please, C compiler / library standard experts, chime in !]
Martin Maechler
ETH Zurich and R core team
__
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] "getOption(max.print) omitted %d entries" may be negative
> Hugh Parsonage
> on Wed, 29 Dec 2021 00:36:51 +1100 writes:
> In src/main/printvector.c in the definition of printVector and
> printNamedVector (and elsewhere):
> Rprintf(" [ reached getOption(\"max.print\") -- omitted %d entries ]\n",
> n - n_pr);
> Though n - n_pr is of type R_xlen_t so may not be representable as
> int. In practice negative values may be observed for long vectors.
> Rprintf(" [ reached getOption(\"max.print\") -- omitted %lld entries ]\n",
> n - n_pr);
Thank you Hugh, for finding and reporting this,
including a proposed remedy.
At some point in time, I think the %lld format specifier was
not portable enough to all versions of C compiler / libraries
that were considered valid for compiling R.
See e.g.,
https://stackoverflow.com/questions/462345/format-specifier-for-long-long
which says that "it" does not work on Windows.
Maybe this has changed now that we require C99 and also that
since R version 4.0.0 (or 4.0.1) we also use a somewhat more
recent version of gcc also on Windows?
... ah, searching the R sources reveals uses of %lld
*plus*
#ifdef Win32
#include /* for %lld */
#endif
so it seems we can and should probably change this ...
[Please, C compiler / library standard experts, chime in !]
Martin Maechler
ETH Zurich and R core team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Not receiving notice after valid push to conductor, how to check status
Once your package is accepted into Bioconductor it is no longer on the Single Package Builder for new submissions and therefore you will not get an on-demand build report. Packages accepted to Bioconductor are built once daily and the reports can be found at: http://bioconductor.org/checkResults/ Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of Jiping Wang Sent: Monday, January 3, 2022 11:56 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] Not receiving notice after valid push to conductor, how to check status Hi, Do we still receive the automatic notice after pushing package updates (with version bump) to Bioconductor? I recently submitted updates of RiboDiPA package, but I didn�t receive automatic report from bioc-issue-bot? Where should I check the status of it? In the past, I remember I receive automatic update on it from bioc-issue-bot. Something like following: �Received a valid push on git.bioconductor.org; starting a build for commit id: 93b588adba022eaf14549e97a53f45c89d19a8f9� from bioc-issue-...@bioconductor.org Thanks for help. Jiping Wang [[alternative HTML version deleted]] 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
[Bioc-devel] Not receiving notice after valid push to conductor, how to check status
Hi, Do we still receive the automatic notice after pushing package updates (with version bump) to Bioconductor? I recently submitted updates of RiboDiPA package, but I didn�t receive automatic report from bioc-issue-bot? Where should I check the status of it? In the past, I remember I receive automatic update on it from bioc-issue-bot. Something like following: �Received a valid push on git.bioconductor.org; starting a build for commit id: 93b588adba022eaf14549e97a53f45c89d19a8f9� from bioc-issue-...@bioconductor.org Thanks for help. Jiping Wang [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] trivial typo in NEWS file
> Ben Bolker
> on Mon, 3 Jan 2022 11:04:48 -0500 writes:
> Index: doc/NEWS.Rd
> ===
> --- doc/NEWS.Rd (revision 81435)
> +++ doc/NEWS.Rd (working copy)
> @@ -425,7 +425,7 @@
> data frames with default row names (Thanks to Charlie Gao's
> \PR{18179}).
> - \item \code{txtProgresBar()} now enforces a non-zero width for
> + \item \code{txtProgressBar()} now enforces a non-zero width for
> \code{char}, without which no progress can be visible.
> \item \code{dimnames(table(d))} is more consistent in the case where
Thank you, Ben!
I will take care of this with my next commit (dealing with R's
bugzilla PR#18272).
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Git recognizes me but denies access
Is this resolved Philipp? ‘destiny’ seems to be failing on windows still http://bioconductor.org/checkResults/release/bioc-LATEST/destiny/. Best, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute > On Dec 19, 2021, at 7:17 AM, Philipp A. wrote: > > Seems like I fixed it! Is there anything else I have to do? > > destiny is green now on your build bots (linux and mac, I don’t see windows > there but there seems to be a build artifact on destiny’s landing page). > > Seems like checking doesn’t use BiocCheck there, is that no longer used? If > it were used, it would break because it doesn’t consider my .ipynb files to > be vignettes. > > Best, Phil > > Am Mo., 13. Dez. 2021 um 19:55 Uhr schrieb Philipp A. : > >> Am Mo., 13. Dez. 2021 um 14:24 Uhr schrieb Kern, Lori < >> lori.sheph...@roswellpark.org>: >> >>> I don't see any changes on the RELEASE_3_14 branch. Please make sure to >>> push to the RELEASE_3_14 branch […] >>> >> >> Understood! Done, I cherry-picked all the commits over. >> >> Am Mo., 13. Dez. 2021 um 19:39 Uhr schrieb Hervé Pagès < >> hpages.on.git...@gmail.com>: >> >>> Just in case someone is watching this thread and wondering what we're >>> doing with the LaTeX environment on the build machines. >>> […] >>> All these installations are stock installations. >> >> >> That’s extremely weird, as I also use stock TexLive to locally build >> things, and everything works flawlessly. >> >> Well, I circumvented the problem by building HTML vignettes instead, which >> is probably more convenient for users anyway. >> > > [[alternative HTML version deleted]] > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Rd] trivial typo in NEWS file
Index: doc/NEWS.Rd
===
--- doc/NEWS.Rd (revision 81435)
+++ doc/NEWS.Rd (working copy)
@@ -425,7 +425,7 @@
data frames with default row names (Thanks to Charlie Gao's
\PR{18179}).
- \item \code{txtProgresBar()} now enforces a non-zero width for
+ \item \code{txtProgressBar()} now enforces a non-zero width for
\code{char}, without which no progress can be visible.
\item \code{dimnames(table(d))} is more consistent in the case where
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does lm() with the subset argument give a different answer than subsetting in advance?
> Ben Bolker > on Mon, 27 Dec 2021 09:43:42 -0500 writes: >I agree that it seems non-intuitive (I can't think of a > design reason for it to look this way), but I'd like to > stress that it's *not* an information leak; the > predictions of the model are independent of the > parameterization, which is all this issue affects. In a > worst case there might be some unfortunate effects on > numerical stability if the data-dependent bases are > computed on a very different set of data than the model > fitting actually uses. >I've attached a suggested documentation patch (I hope > it makes it through to the list, if not I can add it to > the body of a message.) It did make it through; thank you, Ben! ( After adding two forgotten '}' ) I've committed the help file additions to the R sources (R-devel) in svn r81434 . Thanks again and "Happy New Year" to all readers, Martin > On 12/26/21 8:35 PM, Balise, Raymond R wrote: >> Hello R folks, Today I noticed that using the subset >> argument in lm() with a polynomial gives a different >> result than using the polynomial when the data has >> already been subsetted. This was not at all intuitive for >> me. You can see an example here: >> https://stackoverflow.com/questions/70490599/why-does-lm-with-the-subset-argument-give-a-different-answer-than-subsetting-i >> >> If this is a design feature that you don’t think should >> be fixed, can you please include it in the documentation >> and explain why it makes sense to figure out the >> orthogonal polynomials on the entire dataset? This feels >> like a serous leak of information when evaluating train >> and test datasets in a statistical learning framework. >> >> Ray >> >> Raymond R. Balise, PhD Assistant Professor Department of >> Public Health Sciences, Biostatistics >> >> University of Miami, Miller School of Medicine 1120 >> N.W. 14th Street Don Soffer Clinical Research Center - >> Room 1061 Miami, Florida 33136 >> >> >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- > Dr. Benjamin Bolker Professor, Mathematics & Statistics > and Biology, McMaster University Director, School of > Computational Science and Engineering Graduate chair, > Mathematics & Statistics x[DELETED ATTACHMENT external: > BenB_lm-subset.patch, plain text] > __ > 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: [Bioc-devel] DeMixT Bioconductor maintainer
Hi Peng and Shuai, Happy new year. I’ve added Shuai as a maintainer to the package. Shuai, you need to activate your BiocCredentials account with the email you gave. https://git.bioconductor.org/BiocCredentials/account_activation. Once you activate and add your SSH keys, you’ll have access. Please change the maintainer once this happens on the DESCRIPTION file. Best, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute > On Dec 28, 2021, at 5:36 PM, Yang,Peng wrote: > > Hi Bioconductor team, > > I would like to change maintainer for our DeMixT package. > https://bioconductor.org/packages/release/bioc/html/DeMixT.html > > Below is the contact information. > maintainer: Shuai Guo > email: shuai@uth.tmc.edu (cc'd in this email) > > I will update the new maintainer information in DESCRIPTION, and push > to the Bioconductor (devel brunch) very soon. > > Thanks, > Peng ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object
On 12/27/21 4:04 PM, Ezra Tucker wrote: Hi Tomas, Thanks again for all your great info. One last question- and maybe it's a stupid one. You mention the JAGS package-- I've been using xml2 as my kind-of template. Installing it on linux for example will fail unless you have the libxml2-dev package installed (at least for debian-based), whereas for windows it just goes and downloads the dll as part of the install process. Why would/should this package NOT just perform this action for linux as well (namely, automatically download the precompiled .so from somewhere else and package it in so you don't need root privileges to install the package)? Is this just a difference in install philosophy between linux and windows? Hi Ezra, Dirk responded in detail re Unix. On Windows, static libraries (not dynamic) are used by R and are part of the toolchain (Rtools42 for R-devel and R 4.2), you just link the libraries from there via PKG_LIBS in your Makevars.ucrt or Makevars.win file. See for example rgdal for the recommended way how to do this, and [1] for a description. Best Tomas [1] https://developer.r-project.org/WindowsBuilds/winutf8/ucrt3/howto.html Thanks again! -Ezra On 12/23/21 17:20, Tomas Kalibera wrote: On 12/23/21 4:52 PM, Ezra Tucker wrote: Hi Tomas and Dirk, Thanks for your suggestions! Between the two, got it working. I didn't know Windows didn't do rpath, I think that you're right that setting the PATH would have helped. I haven't seen that in an R package before, so I did what was in the Rblpapi package, which was creating a couple of copies of the dll in question. Well it is very exceptional that packages link to an external DLL, only very few CRAN packages do (another example is packages linking to JAGS). I know about these as some of them caused trouble with staged installation and other with the switch to UCRT, they certainly make maintaining and improving R harder. They typically won't work correctly with encodings on Windows. The C++ interface is particularly tricky and fragile. So, one thing is getting this to work in your package you need another question is whether at all it should be published on CRAN, and if that was your plan that'd be best discussed with the CRAN repository maintainers. In some cases there is no other way thank linking to an external DLL, but the question is always whether such package should be on CRAN. On a related note, in Rblpapi Makevars.win line 47 it's downloading and extracting the compiled library from GitHub. My understanding is that one shouldn't include pre-compiled libraries in R packages for security reasons, at least not for submitting to CRAN. Is doing it this way a good way around that? No, those concerns apply and are unrelated in principle to using an external DLL. My understanding is that this was also an exception discussed with the CRAN repository maintainers, but I don't know the case specifically. Best Tomas Thanks again! -Ezra On 12/23/21 09:34, Dirk Eddelbuettel wrote: On 23 December 2021 at 11:07, Tomas Kalibera wrote: | You can have a look at CRAN package Rblpapi which is using an external DLL. Yes with one big caveat: You have to make sure the library follows what is the "hour-glass pattern": it needs to have an internal (the "narrow" part) C library covering the wider underlying library and offered via a wider header. Only C linkage works across different compiler families. You just cannot use a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++. But you can use C linkage. So some libraries (such as the Bloomberg API used in Rblpapi and the TileDB API used in the tiledb package (when not using a local build) can use a library following the hourglass pattern: - "wide" bottom layer (may be C++ or C) with the core implementation - "narrow" C layer accessing the bottom and priving an API providing via C which profits from C's portable foreign function interface - "wide" layer on top via a header-only C++ file accesssing the C and which the C++ compiler optimizes away so that the C API is used for linking Sounds complicated, but works great. Good detail is in a hour-long but not-too-technical talk here https://www.youtube.com/watch?v=PVYdHDm0q6Y and slides etc are here https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
