[Rd] RFC: (in-principle) native unquoting for standard evaluation

(please be gentle, it's my first time) I am interested in discussions (possibly reiterating past threads -- searching didn't turn up much) on the possibility of supporting standard evaluation unquoting at the language level. This has been brought up in a recent similar thread here [1] and on

Re: [Rd] Support for user defined unary functions

I don't have a positive or negative opinion on this yet, but I do have a question. If I define both unary and binary operators with the same name (in different frames, presumably), what would happen? Is "a %chr% b" a syntax error if unary %chr% is found first? If both might be found, does

Re: [Bioc-devel] release schedule

Ok, thanks. I nearly missed the last one, and had a sudden panic this afternoon when I realised it was almost time for the next :-) Best, Tyler -- plantarum.ca On Thu, Mar 16, 2017, at 06:55 PM, Obenchain, Valerie wrote: > Hi Tyler, > > Yes, there is another release coming up. We

Re: [Rd] Support for user defined unary functions

I am biased against introducing new syntax, but if one is experimenting with it one should make sure the precedence feels right. I think the unary and binary minus-sign operators have different precedences so I see no a priori reason to make the unary and binary %xxx% operators to be the same.

Re: [Bioc-devel] release schedule

Hi Tyler, Yes, there is another release coming up. We usually release a day or two after R does so we don't set a date until R has announced theirs. As soon as we know the R schedule we'll make an announcement on bioc-devel and the support site. I'll also post the new release schedule. Valerie

Re: [Rd] Support for user defined unary functions

I guess this would establish a separate "namespace" of symbolic prefix operators, %*% being an example in the infix case. So you could have stuff like %?%, but for non-symbolic (spelled out stuff like %foo%), it's hard to see the advantage vs. foo(x). Those examples you mention should probably be

Re: [R-pkg-devel] R CMD check warning about .inc files.

On Thu, Mar 16, 2017 at 10:12 PM, Pavel Krivitsky wrote: > On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote: >> I different extension is fine I think. I use .pmt (poor man's >> templates) for something very similar. > > No, both .pmt and .inc produce an R CMD check warning.

Re: [R-pkg-devel] R CMD check warning about .inc files.

On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote: > I different extension is fine I think. I use .pmt (poor man's > templates) for something very similar. No, both .pmt and .inc produce an R CMD check warning. (The package itself compiles correctly in either case.)

[Bioc-devel] release schedule

Hi, Is there a deadline for for updates to packages for the next release yet? The webpage hasn't been updated since October (http://bioconductor.org/developers/release-schedule/), but I think there is another release in April? Best, Tyler -- plantarum.ca

Re: [R-pkg-devel] R CMD check warning about .inc files.

I different extension is fine I think. I use .pmt (poor man's templates) for something very similar. Gabor On Thu, Mar 16, 2017 at 9:11 PM, Pavel Krivitsky wrote: > Dear All, > > Since some C header files in a package I maintain have identical macro > definitions (which have a

[R-pkg-devel] R CMD check warning about .inc files.

Dear All, Since some C header files in a package I maintain have identical macro definitions (which have a different meanings, since other macro definitions differ), I tried to reduce code duplication to split the common macros into their own files, which don't get #included directly by any C

Re: [Bioc-devel] Question on the build and biocheck of the package

On 03/16/2017 01:56 PM, Aayush Raman wrote: Hello Hervé Thanks for a quick reply. I have some more questions: 1. This the report of the build of package from Bioconductor: http://bioconductor.org/spb_reports/DASC_buildreport_20170306051600.html. Here, you will see *dependencies error* in the

Re: [Bioc-devel] Question on the build and biocheck of the package

Hello, 1. Please ignore the dependency ERROR on tokay2 for now. Some of this is on our end and we are in the process of correcting. 2. You have to make sure the webhook is set up for your package to automatically build on version bumps. If you have not set up the webhook, please do so

Re: [Bioc-devel] Question on the build and biocheck of the package

Hello Hervé Thanks for a quick reply. I have some more questions: 1. This the report of the build of package from Bioconductor: http://bioconductor.org/spb_reports/DASC_buildreport_20170306051600.html. Here, you will see *dependencies error* in the tokay2 BUILD SRC output. Should I include these

Re: [Rd] Support for user defined unary functions

I used the `function(x)` form to explicitly show the function was being called with only one argument, clearly performance implications are not relevant for these examples. I think of this mainly as a gap in the tooling we provide users and package authors. R has native prefix `+1`, functional

Re: [R-pkg-devel] Windows specific compiler for CUDA builds

Thanks Duncan, You say there aren't a lot of people that no how to do that. Do you know of anyone who would? I assume Dirk would be a likely person given the use of Rtools with Rcpp. I am happy to try and work at this as I have a vested interest in getting CUDA packages to become functional on

Re: [Bioc-devel] Question on the build and biocheck of the package

Hi Ar, On 03/15/2017 12:57 AM, Aayush Raman wrote: Hello Everyone, I have developed a Bioconductor package and submit the issue to build and check. I have some questions regarding on the build and BioCheck of the package. Here are the questions: 1. It has passed the build and check on Mac OS

Re: [Rd] Support for user defined unary functions

> Jim Hester > on Thu, 16 Mar 2017 12:31:56 -0400 writes: > Gabe, > The unary functions have the same precedence as normal SPECIALS > (although the new unary forms take precedence over binary SPECIALS). > So they are lower precedence than

Re: [Rd] Support for user defined unary functions

Gabe, The unary functions have the same precedence as normal SPECIALS (although the new unary forms take precedence over binary SPECIALS). So they are lower precedence than unary + and -. Yes, both of your examples are valid with this patch, here are the results and quoted forms to see the

Re: [Rd] Support for user defined unary functions

Jim, This seems cool. Thanks for proposing it. To be concrete, he user-defined unary operations would be of the same precedence (or just slightly below?) built-in unary ones? So "100" %identical% %chr% 100 would work and return TRUE under your patch? And with %num% <- as.numeric, then 1 + -

Re: [R-pkg-devel] Windows specific compiler for CUDA builds

On 16/03/2017 11:00 AM, Charles Determan wrote: Greetings, Not sure if this should be on the Rcpp list but it isn't strictly related to Rcpp but to package building involving Rcpp so I am posting it here. I am often working on GPU packages that use either OpenCL or CUDA. OpenCL is nice

[R-pkg-devel] Windows specific compiler for CUDA builds

Greetings, Not sure if this should be on the Rcpp list but it isn't strictly related to Rcpp but to package building involving Rcpp so I am posting it here. I am often working on GPU packages that use either OpenCL or CUDA. OpenCL is nice because it doesn't require a special additional compiler

[Rd] Support for user defined unary functions

R has long supported user defined binary (infix) functions, defined with `%fun%`. A one line change [1] to R's grammar allows users to define unary (prefix) functions in the same manner. `%chr%` <- function(x) as.character(x) `%identical%` <- function(x, y) identical(x, y) %chr% 100

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

FWIW it appears that QEMU has an admittedly slow implementation that supports some architectures beyond x86/amd64 and that there is recent activity. See http://wiki.qemu-project.org/Documentation/Platforms/SPARC An alternative might be to persuade Oracle to provide a Sparc-builder, since they

[Bioc-devel] Conference: BioC 2017: Where Software and Biology Connect, July 26 - 28, Boston MA

Developers! Please join us at our annual conference https://bioconductor.org/BioC2017 Consider contributing by proposing a user-oriented workshop or community-building birds-of-a-feather session; applications are on the conference web site. See you in Boston! Martin Morgan Bioconductor

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

I completely agree that testing on SPARC Solaris is valuable, however much of a nuisance it is. But I also agree that it would be great if we could find a way to provide a publicly accessible SPARC Solaris testing framework. On Thu, Mar 16, 2017 at 6:49 AM, Uwe Ligges

[Bioc-devel] Question on the build and biocheck of the package

Hello Everyone, I have developed a Bioconductor package and submit the issue to build and check. I have some questions regarding on the build and BioCheck of the package. Here are the questions: 1. It has passed the build and check on Mac OS and Windows. However, when I am checking it on linux,