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

[Jonathan Carroll]

(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 Twitter [2] where I proposed the
following desired (in-principle) syntax

f <- function(col1, col2, new_col_name) {
mtcars %>% mutate(@new_col_name = @col1 + @col2)
}

or closer to home

x <- 1:10; y <- "x"
data.frame(z = @y)

where @ would be defined as a unary prefix operator which substitutes the
quoted variable name in-place, to allow more flexibility of NSE functions
within a programming context. This mechanism exists within MySQL [3] (and
likely other languages) and could potentially be extremely useful. Several
alternatives have been incorporated into packages (most recently work
on tidyeval) none of which appear to fully match the simplicity of the
above, and some of which cut a forceful path through the syntax tree.

The exact syntax isn't my concern at the moment (@ vs unquote() or other,
though the first requires user-supplied native prefix support within the
language, as per [1]) and neither is the exact way in which this would be
achieved (well above my pay grade). The practicality of @ being on the LHS
of `=` is also of a lesser concern (likely greater complexity) than the RHS.

I hear there exists (justified) reluctance to add new syntax to the
language, but I think this has sufficient merit (and a growing number of
workarounds) to warrant continued discussion.

With kindest regards,

- Jonathan.

[1] https://stat.ethz.ch/pipermail/r-devel/2017-March/073894.html
[2] https://twitter.com/carroll_jono/status/842142292253196290
[3] https://dev.mysql.com/doc/refman/5.7/en/user-variables.html

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Support for user defined unary functions

[Duncan Murdoch]

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 "a %chr% %chr% b" mean "%chr%(a, %chr% b)", or is 
it a syntax error (like typing "a %chr%(%chr%(b))" would be)?


Duncan Murdoch




On 16/03/2017 10:24 AM, Jim Hester wrote:

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
#> [1] "100"

%chr% 100 %identical% "100"
#> [1] TRUE

This seems a natural extension of the existing functionality and
requires only a minor change to the grammar. If this change seems
acceptable I am happy to provide a complete patch with suitable tests
and documentation.

[1]:
Index: src/main/gram.y
===
--- src/main/gram.y (revision 72358)
+++ src/main/gram.y (working copy)
@@ -357,6 +357,7 @@
|   '+' expr %prec UMINUS   { $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '!' expr %prec UNOT { $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '~' expr %prec TILDE{ $$ = xxunary($1,$2);
 setId( $$, @$); }
+   |   SPECIAL expr{ $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '?' expr{ $$ = xxunary($1,$2);
 setId( $$, @$); }

|   expr ':'  expr  { $$ =
xxbinary($2,$1,$3);  setId( $$, @$); }

__
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] release schedule

[Tyler Smith]

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 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
> 
> On 03/16/2017 02:53 PM, Tyler Smith wrote:
> > 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
> >
> 
> 
> 
> 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.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Support for user defined unary functions

[William Dunlap via R-devel]

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.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence
 wrote:
> 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 addressed (eventually) in the
> core language, and it looks like people are already able to experiment, so
> I'm not sure there's a significant impetus for this change.
>
> Michael
>
>
> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester 
> wrote:
>
>> 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 `f(1)` and infix
>> `1 + 1` operators, but we only provide a mechanism to create user
>> defined functional and infix operators.
>>
>> One could also argue that the user defined infix operators are also
>> ugly and could be replaced by `f(a, b)` calls as well; beauty is in
>> the eye of the beholder.
>>
>> The unquote example [1] shows one example where this gap in tooling
>> caused authors to co-opt existing unary exclamation operator, this
>> same gap is part of the reason the formula [2] and question mark [3]
>> operators have been used elsewhere in non standard contexts.
>>
>> If the language provided package authors with a native way to create
>> unary operators like it already does for the other operator types
>> these machinations would be unnecessary.
>>
>> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17
>> [2]: https://cran.r-project.org/package=ensurer
>> [3]: https://cran.r-project.org/package=types
>>
>> On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker 
>> wrote:
>> > Martin,
>> >
>> > Jim can speak directly to his motivations; I don't claim to be able to do
>> > so. That said, I suspect this is related to a conversation on twitter
>> about
>> > wanting an infix "unquote" operator in the context of the non-standard
>> > evaluation framework Hadley Wickham and Lionel Henry (and possibly
>> others)
>> > are working on.
>> >
>> > They're currently using !!! and !! for things related to this, but this
>> > effectively requires non-standard parsing, as ~!!x is interpreted as
>> > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others
>> and
>> > I pointed out this was less than desirable, but if something like it was
>> > going to happen it would hopefully happen in the language specification,
>> > rather than in a package (and also hopefully not using !! specifically).
>> >
>> > Like you, I actually tend to prefer the functional form myself in most
>> > cases. There are functional forms that would work for the above case
>> (e.g.,
>> > something like the .() that DBI uses), but that's probably off topic
>> here,
>> > and not a decision I'm directly related to anyway.
>> >
>> > Best,
>> > ~G
>> >
>> >
>> >
>> > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler
>> >  wrote:
>> >>
>> >> > 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 unary + and -. Yes, both of your
>> >> > examples are valid with this patch, here are the results and
>> quoted
>> >> > forms to see the precedence.
>> >>
>> >> > `%chr%` <- function(x) as.character(x)
>> >>
>> >>   [more efficient would be `%chr%` <- as.character]
>> >>
>> >> > `%identical%` <- function(x, y) identical(x, y)
>> >> > quote("100" %identical% %chr% 100)
>> >> > #>  "100" %identical% (`%chr%`(100))
>> >>
>> >> > "100" %identical% %chr% 100
>> >> > #> [1] TRUE
>> >>
>> >> > `%num%` <- as.numeric
>> >> > quote(1 + - %num% "5")
>> >> > #> 1 + -(`%num%`("5"))
>> >>
>> >> > 1 + - %num% "5"
>> >> > #> [1] -4
>> >>
>> >> > Jim
>> >>
>> >> I'm sorry to be a bit of a spoiler to "coolness", but
>> >> you may know that I like to  applaud Norm Matloff for his book
>> >> title "The Art of R Programming",
>> >> because for me good code should also be beautiful to some extent.
>> >>
>> >> I really very much prefer
>> >>
>> >>f(x)
>> >> to%f% 

Re: [Bioc-devel] release schedule

[Obenchain, Valerie]

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

On 03/16/2017 02:53 PM, Tyler Smith wrote:
> 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
>



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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Support for user defined unary functions

[Michael Lawrence]

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 addressed (eventually) in the
core language, and it looks like people are already able to experiment, so
I'm not sure there's a significant impetus for this change.

Michael


On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester 
wrote:

> 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 `f(1)` and infix
> `1 + 1` operators, but we only provide a mechanism to create user
> defined functional and infix operators.
>
> One could also argue that the user defined infix operators are also
> ugly and could be replaced by `f(a, b)` calls as well; beauty is in
> the eye of the beholder.
>
> The unquote example [1] shows one example where this gap in tooling
> caused authors to co-opt existing unary exclamation operator, this
> same gap is part of the reason the formula [2] and question mark [3]
> operators have been used elsewhere in non standard contexts.
>
> If the language provided package authors with a native way to create
> unary operators like it already does for the other operator types
> these machinations would be unnecessary.
>
> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17
> [2]: https://cran.r-project.org/package=ensurer
> [3]: https://cran.r-project.org/package=types
>
> On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker 
> wrote:
> > Martin,
> >
> > Jim can speak directly to his motivations; I don't claim to be able to do
> > so. That said, I suspect this is related to a conversation on twitter
> about
> > wanting an infix "unquote" operator in the context of the non-standard
> > evaluation framework Hadley Wickham and Lionel Henry (and possibly
> others)
> > are working on.
> >
> > They're currently using !!! and !! for things related to this, but this
> > effectively requires non-standard parsing, as ~!!x is interpreted as
> > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others
> and
> > I pointed out this was less than desirable, but if something like it was
> > going to happen it would hopefully happen in the language specification,
> > rather than in a package (and also hopefully not using !! specifically).
> >
> > Like you, I actually tend to prefer the functional form myself in most
> > cases. There are functional forms that would work for the above case
> (e.g.,
> > something like the .() that DBI uses), but that's probably off topic
> here,
> > and not a decision I'm directly related to anyway.
> >
> > Best,
> > ~G
> >
> >
> >
> > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler
> >  wrote:
> >>
> >> > 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 unary + and -. Yes, both of your
> >> > examples are valid with this patch, here are the results and
> quoted
> >> > forms to see the precedence.
> >>
> >> > `%chr%` <- function(x) as.character(x)
> >>
> >>   [more efficient would be `%chr%` <- as.character]
> >>
> >> > `%identical%` <- function(x, y) identical(x, y)
> >> > quote("100" %identical% %chr% 100)
> >> > #>  "100" %identical% (`%chr%`(100))
> >>
> >> > "100" %identical% %chr% 100
> >> > #> [1] TRUE
> >>
> >> > `%num%` <- as.numeric
> >> > quote(1 + - %num% "5")
> >> > #> 1 + -(`%num%`("5"))
> >>
> >> > 1 + - %num% "5"
> >> > #> [1] -4
> >>
> >> > Jim
> >>
> >> I'm sorry to be a bit of a spoiler to "coolness", but
> >> you may know that I like to  applaud Norm Matloff for his book
> >> title "The Art of R Programming",
> >> because for me good code should also be beautiful to some extent.
> >>
> >> I really very much prefer
> >>
> >>f(x)
> >> to%f% x
> >>
> >> and hence I really really really cannot see why anybody would prefer
> >> the ugliness of
> >>
> >>1 + - %num% "5"
> >> to
> >>1 + -num("5")
> >>
> >> (after setting  num <- as.numeric )
> >>
> >> Martin
> >>
> >>
> >> > On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker
> >>  wrote:
> >> >> 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
> >> 

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

[Gábor Csárdi]

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. (The package
> itself compiles correctly in either case.)

Interesting. Where are these files? igraph has had .pmt files in src/
for >10 years, and I never had any problems with them. They do not
show up in recent checks, either:
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/igraph-00check.html

Maybe you have them in a different directory?

Gabor

[...]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Pavel Krivitsky]

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.)

Pavel

> 
> 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 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 files. To give a minimal example, in the following two
> > header
> > files,
> > 
> > BEGIN foo1.h
> > 
> > #define BAR 1
> > #define BAZ(x) ((x)+BAR)
> > 
> > END foo1.h
> > 
> > BEGIN foo2.h
> > 
> > #define BAR 2
> > #define BAZ(x) ((x)+BAR)
> > 
> > END foo2.h
> > 
> > BAZ() macro has redundant definition. I'd like to get rid of the
> > code
> > duplication with the following three files:
> > 
> > BEGIN foo1.h
> > 
> > #define BAR 1
> > #include "foo_common.inc"
> > 
> > END foo1.h
> > 
> > BEGIN foo2.h
> > 
> > #define BAR 2
> > #include "foo_common.inc"
> > 
> > END foo2.h
> > 
> > BEGIN foo_common.inc
> > 
> > #define BAZ(x) ((x)+BAR)
> > 
> > END foo_common.inc
> > 
> > However, I get an R CMD check warning of the form
> > 
> > Subdirectory ‘src’ contains:
> >   foo_common.inc
> > 
> > Is there a way to tell R CMD check that .inc files are OK? Or,
> > should I
> > use a different extension? I don't want to use .c, because those
> > files
> > only contain macros and not anything that compiles to object code,
> > and
> > I don't want to use .h, because these are not meant to be included
> > as
> > header files by any C code.
> > 
> > Thank you in advance,
> > Pavel
> > 
> > --
> > Pavel Krivitsky
> > Lecturer in Statistics
> > National Institute of Applied Statistics Research Australia
> > (NIASRA)
> > School of Mathematics and Applied Statistics | Building 39C Room
> > 154
> > University of Wollongong NSW 2522 Australia
> > T +61 2 4221 3713
> > Web (NIASRA): http://niasra.uow.edu.au/index.html
> > Web (Personal): http://www.krivitsky.net/research
> > ORCID: -0002-9101-3362
> > 
> > NOTICE: This email is intended for the addressee named and may
> > contain
> > confidential information. If you are not the intended recipient,
> > please
> > delete it and notify the sender. Please consider the environment
> > before
> > printing this email.
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
-- 
Pavel Krivitsky
Lecturer in Statistics
National Institute of Applied Statistics Research Australia (NIASRA)
School of Mathematics and Applied Statistics | Building 39C Room 154
University of Wollongong NSW 2522 Australia
T +61 2 4221 3713
Web (NIASRA): http://niasra.uow.edu.au/index.html
Web (Personal): http://www.krivitsky.net/research
ORCID: -0002-9101-3362

NOTICE: This email is intended for the addressee named and may contain
confidential information. If you are not the intended recipient, please
delete it and notify the sender. Please consider the environment before
printing this email.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Bioc-devel] release schedule

[Tyler Smith]

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

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Gábor Csárdi]

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 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 files. To give a minimal example, in the following two header
> files,
>
> BEGIN foo1.h
>
> #define BAR 1
> #define BAZ(x) ((x)+BAR)
>
> END foo1.h
>
> BEGIN foo2.h
>
> #define BAR 2
> #define BAZ(x) ((x)+BAR)
>
> END foo2.h
>
> BAZ() macro has redundant definition. I'd like to get rid of the code
> duplication with the following three files:
>
> BEGIN foo1.h
>
> #define BAR 1
> #include "foo_common.inc"
>
> END foo1.h
>
> BEGIN foo2.h
>
> #define BAR 2
> #include "foo_common.inc"
>
> END foo2.h
>
> BEGIN foo_common.inc
>
> #define BAZ(x) ((x)+BAR)
>
> END foo_common.inc
>
> However, I get an R CMD check warning of the form
>
> Subdirectory ‘src’ contains:
>   foo_common.inc
>
> Is there a way to tell R CMD check that .inc files are OK? Or, should I
> use a different extension? I don't want to use .c, because those files
> only contain macros and not anything that compiles to object code, and
> I don't want to use .h, because these are not meant to be included as
> header files by any C code.
>
> Thank you in advance,
> Pavel
>
> --
> Pavel Krivitsky
> Lecturer in Statistics
> National Institute of Applied Statistics Research Australia (NIASRA)
> School of Mathematics and Applied Statistics | Building 39C Room 154
> University of Wollongong NSW 2522 Australia
> T +61 2 4221 3713
> Web (NIASRA): http://niasra.uow.edu.au/index.html
> Web (Personal): http://www.krivitsky.net/research
> ORCID: -0002-9101-3362
>
> NOTICE: This email is intended for the addressee named and may contain
> confidential information. If you are not the intended recipient, please
> delete it and notify the sender. Please consider the environment before
> printing this email.
> __
> 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

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

[Pavel Krivitsky]

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 files. To give a minimal example, in the following two header
files,

BEGIN foo1.h

#define BAR 1
#define BAZ(x) ((x)+BAR)

END foo1.h

BEGIN foo2.h

#define BAR 2
#define BAZ(x) ((x)+BAR)

END foo2.h

BAZ() macro has redundant definition. I'd like to get rid of the code
duplication with the following three files:

BEGIN foo1.h

#define BAR 1
#include "foo_common.inc"

END foo1.h

BEGIN foo2.h

#define BAR 2
#include "foo_common.inc"

END foo2.h

BEGIN foo_common.inc

#define BAZ(x) ((x)+BAR)

END foo_common.inc

However, I get an R CMD check warning of the form

Subdirectory ‘src’ contains:
  foo_common.inc

Is there a way to tell R CMD check that .inc files are OK? Or, should I
use a different extension? I don't want to use .c, because those files
only contain macros and not anything that compiles to object code, and
I don't want to use .h, because these are not meant to be included as
header files by any C code.

Thank you in advance,
Pavel

-- 
Pavel Krivitsky
Lecturer in Statistics
National Institute of Applied Statistics Research Australia (NIASRA)
School of Mathematics and Applied Statistics | Building 39C Room 154
University of Wollongong NSW 2522 Australia
T +61 2 4221 3713
Web (NIASRA): http://niasra.uow.edu.au/index.html
Web (Personal): http://www.krivitsky.net/research
ORCID: -0002-9101-3362

NOTICE: This email is intended for the addressee named and may contain
confidential information. If you are not the intended recipient, please
delete it and notify the sender. Please consider the environment before
printing this email.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Martin Morgan]

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 tokay2 BUILD SRC output.
Should I include these packages under Depends or Imports is fine ? Just to
make sure, my package uses NMF function from NMF package and another
function from cvxclustr package.

2. I have made some changes in my code (https://github.com/aayushraman/DASC)
and have changed the version to 0.1.1. I would like to know if I have to do
anything else to inform the Single Package Builder to rebuild and check my
package again.


note that versions of packages added to Contributions/issues should be 
0.99.0, 0.99.1, 0.99.2, 


Also, it is appropriate to ask questions specific to your package under 
the github issue associated with your package,


  https://github.com/Bioconductor/Contributions/issues/305

Martin



Thanks,
-Ar


On Thu, Mar 16, 2017 at 11:57 AM, Hervé Pagès  wrote:


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 and Windows. However, when
I
am checking it on linux, I am getting the following error:

"ERROR: dependencies ‘NMF’, ‘cvxclustr’ are not available for package
‘DASC’"

Although, I know the NMF and cvxclustr are not present in the linux
machine, I would like to know if it possible to build the package by
installing other packages that my package depends on ? I am already
mentioned it on DESCRIPTION file. Do I need to do anything else before
submitting my package ?



You have these packages listed in your Imports field so they will be
automatically installed by the Single Package Builder on the 3 build
machines if they are not already present.



2. After successfully building (using R CMD build) and checking (R CMD
check), I did a BiocCheck on my package. I got 2 warnings:

a. WARNING: Use FALSE instead of F (found in 1 files)

I am using a function called norm (from base package) where I need to
specify the type. The type I would like to use is Frobenius norm which is
specified by "F/f". How can I remove this warning ? or infom bioconductor
about this warning prior to their checks ?



I don't see this when I run Rbiocdev CMD BiocCheck DASC_0.1.1.tar.gz.
Have you addressed this already? Please note that the way to specify
the type in base::norm() is with a 1-letter *string* ("O", "I", "F",
"M", or "2"). This has nothing to do with the use of F (unquoted) for
specifying the single logical value FALSE.



b. WARNING: Add non-empty \value sections to the following man pages:
data.Rd:

data.Rd is a dataset that I will be uploading with our package. I would
like to know how can I remove this error ?



Man pages for data sets need a \format section instead of a \value
section. If you have one, and R CMD BiocCheck still complains about
the lack of a \value section, please ignore the warning.

Hope this helps,

H.



Any help or advice would be much appreciated.

Thanks,
-Ar

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
hz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt
84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Yi
ZGNUYd-khI-yvgitdzYaCkX0YYV4RafW040QHUJRo=-ddB-ch5A6i-pe7Q
zHb6mH7ARR6Rap0LnufSyE_Qjvg=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319



[[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...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Shepherd, Lori]

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 and then make another version bump in the DESCRIPTION file. See 
the instructions here:

https://github.com/Bioconductor/Contributions/blob/master/CONTRIBUTING.md#adding-a-web-hook




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Aayush Raman 

Sent: Thursday, March 16, 2017 1:56:15 PM
To: Herv� Pag�s
Cc: bioc-devel@r-project.org
Subject: 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 packages under Depends or Imports is fine ? Just to
make sure, my package uses NMF function from NMF package and another
function from cvxclustr package.

2. I have made some changes in my code (https://github.com/aayushraman/DASC)
and have changed the version to 0.1.1. I would like to know if I have to do
anything else to inform the Single Package Builder to rebuild and check my
package again.

Thanks,
-Ar


On Thu, Mar 16, 2017 at 11:57 AM, Herv� Pag�s  wrote:

> 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 and Windows. However, when
>> I
>> am checking it on linux, I am getting the following error:
>>
>> "ERROR: dependencies �NMF�, �cvxclustr� are not available for package
>> �DASC�"
>>
>> Although, I know the NMF and cvxclustr are not present in the linux
>> machine, I would like to know if it possible to build the package by
>> installing other packages that my package depends on ? I am already
>> mentioned it on DESCRIPTION file. Do I need to do anything else before
>> submitting my package ?
>>
>
> You have these packages listed in your Imports field so they will be
> automatically installed by the Single Package Builder on the 3 build
> machines if they are not already present.
>
>
>> 2. After successfully building (using R CMD build) and checking (R CMD
>> check), I did a BiocCheck on my package. I got 2 warnings:
>>
>> a. WARNING: Use FALSE instead of F (found in 1 files)
>>
>> I am using a function called norm (from base package) where I need to
>> specify the type. The type I would like to use is Frobenius norm which is
>> specified by "F/f". How can I remove this warning ? or infom bioconductor
>> about this warning prior to their checks ?
>>
>
> I don't see this when I run Rbiocdev CMD BiocCheck DASC_0.1.1.tar.gz.
> Have you addressed this already? Please note that the way to specify
> the type in base::norm() is with a 1-letter *string* ("O", "I", "F",
> "M", or "2"). This has nothing to do with the use of F (unquoted) for
> specifying the single logical value FALSE.
>
>
>> b. WARNING: Add non-empty \value sections to the following man pages:
>> data.Rd:
>>
>> data.Rd is a dataset that I will be uploading with our package. I would
>> like to know how can I remove this error ?
>>
>
> Man pages for data sets need a \format section instead of a \value
> section. If you have one, and R CMD BiocCheck still complains about
> the lack of a \value section, please ignore the warning.
>
> Hope this helps,
>
> H.
>
>
>> Any help or advice would be much appreciated.
>>
>> Thanks,
>> -Ar
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>> hz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt
>> 84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Yi
>> ZGNUYd-khI-yvgitdzYaCkX0YYV4RafW040QHUJRo=-ddB-ch5A6i-pe7Q
>> zHb6mH7ARR6Rap0LnufSyE_Qjvg=
>>
>>
> --
> Herv� Pag�s
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email 

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

[Aayush Raman]

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 packages under Depends or Imports is fine ? Just to
make sure, my package uses NMF function from NMF package and another
function from cvxclustr package.

2. I have made some changes in my code (https://github.com/aayushraman/DASC)
and have changed the version to 0.1.1. I would like to know if I have to do
anything else to inform the Single Package Builder to rebuild and check my
package again.

Thanks,
-Ar


On Thu, Mar 16, 2017 at 11:57 AM, Hervé Pagès  wrote:

> 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 and Windows. However, when
>> I
>> am checking it on linux, I am getting the following error:
>>
>> "ERROR: dependencies ‘NMF’, ‘cvxclustr’ are not available for package
>> ‘DASC’"
>>
>> Although, I know the NMF and cvxclustr are not present in the linux
>> machine, I would like to know if it possible to build the package by
>> installing other packages that my package depends on ? I am already
>> mentioned it on DESCRIPTION file. Do I need to do anything else before
>> submitting my package ?
>>
>
> You have these packages listed in your Imports field so they will be
> automatically installed by the Single Package Builder on the 3 build
> machines if they are not already present.
>
>
>> 2. After successfully building (using R CMD build) and checking (R CMD
>> check), I did a BiocCheck on my package. I got 2 warnings:
>>
>> a. WARNING: Use FALSE instead of F (found in 1 files)
>>
>> I am using a function called norm (from base package) where I need to
>> specify the type. The type I would like to use is Frobenius norm which is
>> specified by "F/f". How can I remove this warning ? or infom bioconductor
>> about this warning prior to their checks ?
>>
>
> I don't see this when I run Rbiocdev CMD BiocCheck DASC_0.1.1.tar.gz.
> Have you addressed this already? Please note that the way to specify
> the type in base::norm() is with a 1-letter *string* ("O", "I", "F",
> "M", or "2"). This has nothing to do with the use of F (unquoted) for
> specifying the single logical value FALSE.
>
>
>> b. WARNING: Add non-empty \value sections to the following man pages:
>> data.Rd:
>>
>> data.Rd is a dataset that I will be uploading with our package. I would
>> like to know how can I remove this error ?
>>
>
> Man pages for data sets need a \format section instead of a \value
> section. If you have one, and R CMD BiocCheck still complains about
> the lack of a \value section, please ignore the warning.
>
> Hope this helps,
>
> H.
>
>
>> Any help or advice would be much appreciated.
>>
>> Thanks,
>> -Ar
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>> hz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt
>> 84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Yi
>> ZGNUYd-khI-yvgitdzYaCkX0YYV4RafW040QHUJRo=-ddB-ch5A6i-pe7Q
>> zHb6mH7ARR6Rap0LnufSyE_Qjvg=
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Support for user defined unary functions

[Jim Hester]

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 `f(1)` and infix
`1 + 1` operators, but we only provide a mechanism to create user
defined functional and infix operators.

One could also argue that the user defined infix operators are also
ugly and could be replaced by `f(a, b)` calls as well; beauty is in
the eye of the beholder.

The unquote example [1] shows one example where this gap in tooling
caused authors to co-opt existing unary exclamation operator, this
same gap is part of the reason the formula [2] and question mark [3]
operators have been used elsewhere in non standard contexts.

If the language provided package authors with a native way to create
unary operators like it already does for the other operator types
these machinations would be unnecessary.

[1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17
[2]: https://cran.r-project.org/package=ensurer
[3]: https://cran.r-project.org/package=types

On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker  wrote:
> Martin,
>
> Jim can speak directly to his motivations; I don't claim to be able to do
> so. That said, I suspect this is related to a conversation on twitter about
> wanting an infix "unquote" operator in the context of the non-standard
> evaluation framework Hadley Wickham and Lionel Henry (and possibly others)
> are working on.
>
> They're currently using !!! and !! for things related to this, but this
> effectively requires non-standard parsing, as ~!!x is interpreted as
> ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others and
> I pointed out this was less than desirable, but if something like it was
> going to happen it would hopefully happen in the language specification,
> rather than in a package (and also hopefully not using !! specifically).
>
> Like you, I actually tend to prefer the functional form myself in most
> cases. There are functional forms that would work for the above case (e.g.,
> something like the .() that DBI uses), but that's probably off topic here,
> and not a decision I'm directly related to anyway.
>
> Best,
> ~G
>
>
>
> On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler
>  wrote:
>>
>> > 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 unary + and -. Yes, both of your
>> > examples are valid with this patch, here are the results and quoted
>> > forms to see the precedence.
>>
>> > `%chr%` <- function(x) as.character(x)
>>
>>   [more efficient would be `%chr%` <- as.character]
>>
>> > `%identical%` <- function(x, y) identical(x, y)
>> > quote("100" %identical% %chr% 100)
>> > #>  "100" %identical% (`%chr%`(100))
>>
>> > "100" %identical% %chr% 100
>> > #> [1] TRUE
>>
>> > `%num%` <- as.numeric
>> > quote(1 + - %num% "5")
>> > #> 1 + -(`%num%`("5"))
>>
>> > 1 + - %num% "5"
>> > #> [1] -4
>>
>> > Jim
>>
>> I'm sorry to be a bit of a spoiler to "coolness", but
>> you may know that I like to  applaud Norm Matloff for his book
>> title "The Art of R Programming",
>> because for me good code should also be beautiful to some extent.
>>
>> I really very much prefer
>>
>>f(x)
>> to%f% x
>>
>> and hence I really really really cannot see why anybody would prefer
>> the ugliness of
>>
>>1 + - %num% "5"
>> to
>>1 + -num("5")
>>
>> (after setting  num <- as.numeric )
>>
>> Martin
>>
>>
>> > On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker
>>  wrote:
>> >> 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 + - %num% "5"
>> >>
>> >> would also be legal (though quite ugly imo) and work?
>> >>
>> >> Best,
>> >> ~G
>> >>
>> >> On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester
>> 
>> >> wrote:
>> >>>
>> >>> 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%` <- 

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

[Charles Determan]

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 Windows systems
but I need somewhere to begin.  Basically I'm just looking how to switch
out the MinGW g++ with the VS cl compiler.  On a Linux system I can create
a .R/Makevars file to switch the CXX variable but I don't know how on
Windows.

Charles

On Thu, Mar 16, 2017 at 10:41 AM, Duncan Murdoch 
wrote:

> 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 because it doesn't require a special additional compiler and I can
>> build it across platforms with relative ease.  With CUDA, it requires the
>> 'nvcc' compiler.  This is where my problem comes in.  On Windows the
>> 'nvcc'
>> requires the use of the 'cl' compiler within Visual Studio and the
>> resulting object files, AFAIK, cannot be linked to object files created by
>> g++ (via Rtools).  Everything works great on Linux (where the same
>> compiler
>> is used for everything) but on a Windows system this is causing a lot of
>> headaches.
>>
>> So, at the moment, my conclusion is that it is simply not possible to
>> build
>> a CUDA package that can be installed on a Windows system.  To my
>> knowledge,
>> no CUDA based R package has a Windows installation functional (please
>> state
>> otherwise if I am wrong).
>>
>> My only thought would be if it would be possible to have the Windows build
>> use 'cl' for the entire build process.  Perhaps that would allow all the
>> files to be linked together and create the necessary shared object at the
>> end?  Obviously the preference is to use Rtools but until NVIDIA updates
>> their special compiler to support MinGW tools I don't think that is
>> possible.
>>
>
> In principle it should be possible to use cl.  In practice, it will
> require someone to work out the details of doing it and to maintain it (by
> testing R-devel regularly to make sure changes there don't cause trouble
> for it).  There aren't a lot of people who know how to do that (e.g. I
> don't).  If you are willing to volunteer to do this (or can recruit someone
> to do it), go ahead.  Assuming you do a good job, we can put your patches
> into the base code.
>
> Duncan Murdoch
>
>
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Hervé Pagès]

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 and Windows. However, when I
am checking it on linux, I am getting the following error:

"ERROR: dependencies ‘NMF’, ‘cvxclustr’ are not available for package
‘DASC’"

Although, I know the NMF and cvxclustr are not present in the linux
machine, I would like to know if it possible to build the package by
installing other packages that my package depends on ? I am already
mentioned it on DESCRIPTION file. Do I need to do anything else before
submitting my package ?


You have these packages listed in your Imports field so they will be
automatically installed by the Single Package Builder on the 3 build
machines if they are not already present.



2. After successfully building (using R CMD build) and checking (R CMD
check), I did a BiocCheck on my package. I got 2 warnings:

a. WARNING: Use FALSE instead of F (found in 1 files)

I am using a function called norm (from base package) where I need to
specify the type. The type I would like to use is Frobenius norm which is
specified by "F/f". How can I remove this warning ? or infom bioconductor
about this warning prior to their checks ?


I don't see this when I run Rbiocdev CMD BiocCheck DASC_0.1.1.tar.gz.
Have you addressed this already? Please note that the way to specify
the type in base::norm() is with a 1-letter *string* ("O", "I", "F",
"M", or "2"). This has nothing to do with the use of F (unquoted) for
specifying the single logical value FALSE.



b. WARNING: Add non-empty \value sections to the following man pages:
data.Rd:

data.Rd is a dataset that I will be uploading with our package. I would
like to know how can I remove this error ?


Man pages for data sets need a \format section instead of a \value
section. If you have one, and R CMD BiocCheck still complains about
the lack of a \value section, please ignore the warning.

Hope this helps,

H.



Any help or advice would be much appreciated.

Thanks,
-Ar

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YiZGNUYd-khI-yvgitdzYaCkX0YYV4RafW040QHUJRo=-ddB-ch5A6i-pe7QzHb6mH7ARR6Rap0LnufSyE_Qjvg=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Support for user defined unary functions

[Martin Maechler]

> 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 unary + and -. Yes, both of your
> examples are valid with this patch, here are the results and quoted
> forms to see the precedence.

> `%chr%` <- function(x) as.character(x)

  [more efficient would be `%chr%` <- as.character]

> `%identical%` <- function(x, y) identical(x, y)
> quote("100" %identical% %chr% 100)
> #>  "100" %identical% (`%chr%`(100))

> "100" %identical% %chr% 100
> #> [1] TRUE

> `%num%` <- as.numeric
> quote(1 + - %num% "5")
> #> 1 + -(`%num%`("5"))

> 1 + - %num% "5"
> #> [1] -4

> Jim

I'm sorry to be a bit of a spoiler to "coolness", but
you may know that I like to  applaud Norm Matloff for his book
title "The Art of R Programming",
because for me good code should also be beautiful to some extent.

I really very much prefer

   f(x)
to%f% x   

and hence I really really really cannot see why anybody would prefer
the ugliness of

   1 + - %num% "5"
to
   1 + -num("5")

(after setting  num <- as.numeric )

Martin


> On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker  
wrote:
>> 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 + - %num% "5"
>> 
>> would also be legal (though quite ugly imo) and work?
>> 
>> Best,
>> ~G
>> 
>> On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester 
>> wrote:
>>> 
>>> 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
>>> #> [1] "100"
>>> 
>>> %chr% 100 %identical% "100"
>>> #> [1] TRUE
>>> 
>>> This seems a natural extension of the existing functionality and
>>> requires only a minor change to the grammar. If this change seems
>>> acceptable I am happy to provide a complete patch with suitable tests
>>> and documentation.
>>> 
>>> [1]:
>>> Index: src/main/gram.y
>>> ===
>>> --- src/main/gram.y (revision 72358)
>>> +++ src/main/gram.y (working copy)
>>> @@ -357,6 +357,7 @@
>>> |   '+' expr %prec UMINUS   { $$ = xxunary($1,$2);
>>> setId( $$, @$); }
>>> |   '!' expr %prec UNOT { $$ = xxunary($1,$2);
>>> setId( $$, @$); }
>>> |   '~' expr %prec TILDE{ $$ = xxunary($1,$2);
>>> setId( $$, @$); }
>>> +   |   SPECIAL expr{ $$ = xxunary($1,$2);
>>> setId( $$, @$); }
>>> |   '?' expr{ $$ = xxunary($1,$2);
>>> setId( $$, @$); }
>>> 
>>> |   expr ':'  expr  { $$ =
>>> xxbinary($2,$1,$3);  setId( $$, @$); }
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
>> 
>> 
>> --
>> Gabriel Becker, PhD
>> Associate Scientist (Bioinformatics)
>> Genentech Research

> __
> 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] Support for user defined unary functions

[Jim Hester]

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 precedence.

`%chr%` <- function(x) as.character(x)
`%identical%` <- function(x, y) identical(x, y)
quote("100" %identical% %chr% 100)
#>  "100" %identical% (`%chr%`(100))

"100" %identical% %chr% 100
#> [1] TRUE

`%num%` <- as.numeric
quote(1 + - %num% "5")
#> 1 + -(`%num%`("5"))

1 + - %num% "5"
#> [1] -4

Jim

On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker  wrote:
> 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 + - %num% "5"
>
> would also be legal (though quite ugly imo) and work?
>
> Best,
> ~G
>
> On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester 
> wrote:
>>
>> 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
>> #> [1] "100"
>>
>> %chr% 100 %identical% "100"
>> #> [1] TRUE
>>
>> This seems a natural extension of the existing functionality and
>> requires only a minor change to the grammar. If this change seems
>> acceptable I am happy to provide a complete patch with suitable tests
>> and documentation.
>>
>> [1]:
>> Index: src/main/gram.y
>> ===
>> --- src/main/gram.y (revision 72358)
>> +++ src/main/gram.y (working copy)
>> @@ -357,6 +357,7 @@
>> |   '+' expr %prec UMINUS   { $$ = xxunary($1,$2);
>>  setId( $$, @$); }
>> |   '!' expr %prec UNOT { $$ = xxunary($1,$2);
>>  setId( $$, @$); }
>> |   '~' expr %prec TILDE{ $$ = xxunary($1,$2);
>>  setId( $$, @$); }
>> +   |   SPECIAL expr{ $$ = xxunary($1,$2);
>>  setId( $$, @$); }
>> |   '?' expr{ $$ = xxunary($1,$2);
>>  setId( $$, @$); }
>>
>> |   expr ':'  expr  { $$ =
>> xxbinary($2,$1,$3);  setId( $$, @$); }
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
> --
> Gabriel Becker, PhD
> Associate Scientist (Bioinformatics)
> Genentech Research

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Support for user defined unary functions

[Gabriel Becker]

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 + - %num% "5"

would also be legal (though quite ugly imo) and work?

Best,
~G

On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester 
wrote:

> 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
> #> [1] "100"
>
> %chr% 100 %identical% "100"
> #> [1] TRUE
>
> This seems a natural extension of the existing functionality and
> requires only a minor change to the grammar. If this change seems
> acceptable I am happy to provide a complete patch with suitable tests
> and documentation.
>
> [1]:
> Index: src/main/gram.y
> ===
> --- src/main/gram.y (revision 72358)
> +++ src/main/gram.y (working copy)
> @@ -357,6 +357,7 @@
> |   '+' expr %prec UMINUS   { $$ = xxunary($1,$2);
>  setId( $$, @$); }
> |   '!' expr %prec UNOT { $$ = xxunary($1,$2);
>  setId( $$, @$); }
> |   '~' expr %prec TILDE{ $$ = xxunary($1,$2);
>  setId( $$, @$); }
> +   |   SPECIAL expr{ $$ = xxunary($1,$2);
>  setId( $$, @$); }
> |   '?' expr{ $$ = xxunary($1,$2);
>  setId( $$, @$); }
>
> |   expr ':'  expr  { $$ =
> xxbinary($2,$1,$3);  setId( $$, @$); }
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Duncan Murdoch]

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 because it doesn't require a special additional compiler and I can
build it across platforms with relative ease.  With CUDA, it requires the
'nvcc' compiler.  This is where my problem comes in.  On Windows the 'nvcc'
requires the use of the 'cl' compiler within Visual Studio and the
resulting object files, AFAIK, cannot be linked to object files created by
g++ (via Rtools).  Everything works great on Linux (where the same compiler
is used for everything) but on a Windows system this is causing a lot of
headaches.

So, at the moment, my conclusion is that it is simply not possible to build
a CUDA package that can be installed on a Windows system.  To my knowledge,
no CUDA based R package has a Windows installation functional (please state
otherwise if I am wrong).

My only thought would be if it would be possible to have the Windows build
use 'cl' for the entire build process.  Perhaps that would allow all the
files to be linked together and create the necessary shared object at the
end?  Obviously the preference is to use Rtools but until NVIDIA updates
their special compiler to support MinGW tools I don't think that is
possible.


In principle it should be possible to use cl.  In practice, it will 
require someone to work out the details of doing it and to maintain it 
(by testing R-devel regularly to make sure changes there don't cause 
trouble for it).  There aren't a lot of people who know how to do that 
(e.g. I don't).  If you are willing to volunteer to do this (or can 
recruit someone to do it), go ahead.  Assuming you do a good job, we can 
put your patches into the base code.


Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Charles Determan]

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 and I can
build it across platforms with relative ease.  With CUDA, it requires the
'nvcc' compiler.  This is where my problem comes in.  On Windows the 'nvcc'
requires the use of the 'cl' compiler within Visual Studio and the
resulting object files, AFAIK, cannot be linked to object files created by
g++ (via Rtools).  Everything works great on Linux (where the same compiler
is used for everything) but on a Windows system this is causing a lot of
headaches.

So, at the moment, my conclusion is that it is simply not possible to build
a CUDA package that can be installed on a Windows system.  To my knowledge,
no CUDA based R package has a Windows installation functional (please state
otherwise if I am wrong).

My only thought would be if it would be possible to have the Windows build
use 'cl' for the entire build process.  Perhaps that would allow all the
files to be linked together and create the necessary shared object at the
end?  Obviously the preference is to use Rtools but until NVIDIA updates
their special compiler to support MinGW tools I don't think that is
possible.

Any insight would be appreciated,

Charles

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] Support for user defined unary functions

[Jim Hester]

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
#> [1] "100"

%chr% 100 %identical% "100"
#> [1] TRUE

This seems a natural extension of the existing functionality and
requires only a minor change to the grammar. If this change seems
acceptable I am happy to provide a complete patch with suitable tests
and documentation.

[1]:
Index: src/main/gram.y
===
--- src/main/gram.y (revision 72358)
+++ src/main/gram.y (working copy)
@@ -357,6 +357,7 @@
|   '+' expr %prec UMINUS   { $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '!' expr %prec UNOT { $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '~' expr %prec TILDE{ $$ = xxunary($1,$2);
 setId( $$, @$); }
+   |   SPECIAL expr{ $$ = xxunary($1,$2);
 setId( $$, @$); }
|   '?' expr{ $$ = xxunary($1,$2);
 setId( $$, @$); }

|   expr ':'  expr  { $$ =
xxbinary($2,$1,$3);  setId( $$, @$); }

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[J C Nash]

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
advertise Oracle R Technologies at
http://www.oracle.com/technetwork/database/database-technologies/r/r-technologies/r-offerings-1566363.html

but dates on that page are from 2014. Perhaps someone has contacts at Oracle 
and could at least raise
the possibility.

JN



On 2017-03-16 08:20 AM, Ben Bolker wrote:

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
 wrote:



On 15.03.2017 18:30, Ben Bolker wrote:




On 17-03-15 11:09 AM, J C Nash wrote:


Possibly tangential, but has there been any effort to set up a Sparc
testbed? It
seems we could use a network-available (virtual?) machine, since this
platform is
often the unfortunate one. Unless, of course, there's a sunset date.

For information, I mentioned SPARC at our local linux group, and
apparently there
are a couple of folk who have them running, but I didn't find out the
state of the
OS etc.

JN



  The virtual machine platforms I know of (admittedly not a complete
list!) only support Solaris on x86, e.g.



Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.

I take the opportunity to repeat why testing on *Sparc Solaris* gives many
benefits:

- this way we cover big- and little-endian platforms (i.e. for future
stability so that it works on what appear to be still esoteric such as ARM
based architectures or so)
- we cover one of the commercial unixes, i.e. we see
  + how stuff works on the the typically rather old toolchains
  + and what happens in on gnu/gcc-setups and how much GNUisms are used

Best,
Uwe Ligges





https://community.oracle.com/thread/2569292






On 2017-03-15 10:40 AM, Avraham Adler wrote:


Hello.

The Delaporte package works properly on all R-core platforms except
Solaris SPARC, where it  compiles properly but fails a number of its
tests [1]. Not having access to a SPARC testbed, I'm limited in what
kind of diagnostics I can do. One thing I have noticed is that a lot
of the failures occur when I am passing non-default logicals (like
lower tail or log). For example, the first failure at that link is
when "log = true" is supposed to be passed, but the SPARC answers are
the unlogged values. Of the 22 failed tests, 12 of them pass logicals.

I'll bring an example of how it is coded below, and if anyone
recognizes where SPARC specifically goes wrong, I'd appreciate. I
guess, if I absolutely had to, I could convert the logical to an
integer in C and pass the integer to Fortran which should work even
for SPARC, but I'd prefer not to if I could help it.

Thank you,

Avi

[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html

*Example Code*

R code:

ddelap <- function(x, alpha, beta, lambda, log = FALSE){
  if(!is.double(x)) {storage.mode(x) <- 'double'}
  if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
  if(!is.double(beta)) {storage.mode(beta) <- 'double'}
  if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
  if(any(x > floor(x))) {
warning("Non-integers passed to ddelap. These will have 0
probability.")
  }
  .Call(ddelap_C, x, alpha, beta, lambda, log)
}

C code:

void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
double *l, int nl,
  int *lg, double *ret);

extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
lg){
  const int nx = LENGTH(x);
  const int na = LENGTH(alpha);
  const int nb = LENGTH(beta);
  const int nl = LENGTH(lambda);
  SEXP ret;
  PROTECT(ret = allocVector(REALSXP, nx));
  ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
nl, LOGICAL(lg), REAL(ret));
  UNPROTECT(1);
  return(ret);
}

Fortran: (not posting ddelap_f_s as that doesn't handle the logging)

subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")

integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
logical(kind = c_bool), intent(in)   :: lg
! Log flag
integer  :: i
! Integer

!$omp parallel do default(shared) private(i)
do i = 1, nx
if (x(i) > floor(x(i))) then
pmfv(i) = ZERO
else
pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
  

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

[Martin Morgan]

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


This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Ben Bolker]

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
 wrote:
>
>
> On 15.03.2017 18:30, Ben Bolker wrote:
>>
>>
>>
>> On 17-03-15 11:09 AM, J C Nash wrote:
>>>
>>> Possibly tangential, but has there been any effort to set up a Sparc
>>> testbed? It
>>> seems we could use a network-available (virtual?) machine, since this
>>> platform is
>>> often the unfortunate one. Unless, of course, there's a sunset date.
>>>
>>> For information, I mentioned SPARC at our local linux group, and
>>> apparently there
>>> are a couple of folk who have them running, but I didn't find out the
>>> state of the
>>> OS etc.
>>>
>>> JN
>>
>>
>>   The virtual machine platforms I know of (admittedly not a complete
>> list!) only support Solaris on x86, e.g.
>
>
> Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.
>
> I take the opportunity to repeat why testing on *Sparc Solaris* gives many
> benefits:
>
> - this way we cover big- and little-endian platforms (i.e. for future
> stability so that it works on what appear to be still esoteric such as ARM
> based architectures or so)
> - we cover one of the commercial unixes, i.e. we see
>   + how stuff works on the the typically rather old toolchains
>   + and what happens in on gnu/gcc-setups and how much GNUisms are used
>
> Best,
> Uwe Ligges
>
>
>
>>
>> https://community.oracle.com/thread/2569292
>>
>>
>>
>>>
>>>
>>> On 2017-03-15 10:40 AM, Avraham Adler wrote:

 Hello.

 The Delaporte package works properly on all R-core platforms except
 Solaris SPARC, where it  compiles properly but fails a number of its
 tests [1]. Not having access to a SPARC testbed, I'm limited in what
 kind of diagnostics I can do. One thing I have noticed is that a lot
 of the failures occur when I am passing non-default logicals (like
 lower tail or log). For example, the first failure at that link is
 when "log = true" is supposed to be passed, but the SPARC answers are
 the unlogged values. Of the 22 failed tests, 12 of them pass logicals.

 I'll bring an example of how it is coded below, and if anyone
 recognizes where SPARC specifically goes wrong, I'd appreciate. I
 guess, if I absolutely had to, I could convert the logical to an
 integer in C and pass the integer to Fortran which should work even
 for SPARC, but I'd prefer not to if I could help it.

 Thank you,

 Avi

 [1] https://cran.r-project.org/web/checks/check_results_Delaporte.html

 *Example Code*

 R code:

 ddelap <- function(x, alpha, beta, lambda, log = FALSE){
   if(!is.double(x)) {storage.mode(x) <- 'double'}
   if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
   if(!is.double(beta)) {storage.mode(beta) <- 'double'}
   if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
   if(any(x > floor(x))) {
 warning("Non-integers passed to ddelap. These will have 0
 probability.")
   }
   .Call(ddelap_C, x, alpha, beta, lambda, log)
 }

 C code:

 void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
 double *l, int nl,
   int *lg, double *ret);

 extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
 lg){
   const int nx = LENGTH(x);
   const int na = LENGTH(alpha);
   const int nb = LENGTH(beta);
   const int nl = LENGTH(lambda);
   SEXP ret;
   PROTECT(ret = allocVector(REALSXP, nx));
   ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
 nl, LOGICAL(lg), REAL(ret));
   UNPROTECT(1);
   return(ret);
 }

 Fortran: (not posting ddelap_f_s as that doesn't handle the logging)

 subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
 name="ddelap_f")

 integer(kind = c_int), intent(in), value :: nx, na, nb, nl
 ! Sizes
 real(kind = c_double), intent(in), dimension(nx) :: x
 ! Observations
 real(kind = c_double), intent(out), dimension(nx):: pmfv
 ! Result
 real(kind = c_double), intent(in):: a(na), b(nb),
 l(nl)! Parameters
 logical(kind = c_bool), intent(in)   :: lg
 ! Log flag
 integer  :: i
 ! Integer

 !$omp parallel do default(shared) private(i)
 do i = 1, nx
 if (x(i) > floor(x(i))) then
 pmfv(i) = ZERO
 else
 pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
  b(mod(i - 1, nb) + 1), l(mod(i -
 1, nl) + 1))

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

[Aayush Raman]

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, I am getting the following error:

"ERROR: dependencies ‘NMF’, ‘cvxclustr’ are not available for package
‘DASC’"

Although, I know the NMF and cvxclustr are not present in the linux
machine, I would like to know if it possible to build the package by
installing other packages that my package depends on ? I am already
mentioned it on DESCRIPTION file. Do I need to do anything else before
submitting my package ?

2. After successfully building (using R CMD build) and checking (R CMD
check), I did a BiocCheck on my package. I got 2 warnings:

a. WARNING: Use FALSE instead of F (found in 1 files)

I am using a function called norm (from base package) where I need to
specify the type. The type I would like to use is Frobenius norm which is
specified by "F/f". How can I remove this warning ? or infom bioconductor
about this warning prior to their checks ?

b. WARNING: Add non-empty \value sections to the following man pages:
data.Rd:

data.Rd is a dataset that I will be uploading with our package. I would
like to know how can I remove this error ?

Any help or advice would be much appreciated.

Thanks,
-Ar

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel