Re: [Bioc-devel] BiocStyle issue

[Yu, Guangchuang]

I found the issue was filed by yihui half month ago on github,
https://github.com/Bioconductor/BiocStyle/issues/18, and the solution is
quite intuitive by removing those un-supported paramters (self_contained,
lib_dir, output_dir). Hope it will be fixed soon.


On Wed, Nov 23, 2016 at 2:25 PM, Leonardo Collado Torres 
wrote:

> Guangchuang, you can see at
> https://github.com/Bioconductor/BiocStyle/issues/19 (the main github
> repo for this package) that this issue is already been reported and
> will be addressed asap by BiocStyle's maintainer.
>
> On Tue, Nov 22, 2016 at 9:46 PM, Yu, Guangchuang 
> wrote:
> >
> > Dear all,
> >
> > I recompile my package and it throw the following error when building
> > vignettes:
> >
> > unused arguments (self_contained, lib_dir, output_dir)
> >
> > I search  ?opts_knit, and couldn't find these parameters.
> >
> > In ?opts_knit, I find *self.contained* instead of *self_contained*.
> >
> > I remove the dependency of BiocStyle and recompile my package and it
> works.
> >
> >
> > I search the source code of BiocStyle, and find the issue in
> >
> > https://github.com/Bioconductor-mirror/BiocStyle/
> blob/master/R/html_document.R#L66-L70
> >
> > Now rmarkdown:::pandoc_html_highlight_args (in latest release version
> 1.2)
> > only accepts template and highlight parameters.
> >
> > This will fail the compilation of many Bioconductor packages. Please fix
> it.
> >
> > Using ::: is not recommended by Bioconductor and will not passed by
> > BiocCheck (if I remember it correctly). But I find several packages by
> > Bioconductor core team use it.
> >
> > Best wishes,
> > Guangchuang
> > --
> > --~--~-~--~~~---~--~~
> > Guangchuang Yu, PhD Candidate
> > State Key Laboratory of Emerging Infectious Diseases
> > School of Public Health
> > The University of Hong Kong
> > Hong Kong SAR, China
> > www: https://guangchuangyu.github.io
> > -~--~~~~--~~--~--~---
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
--~--~-~--~~~---~--~~
Guangchuang Yu, PhD Candidate
State Key Laboratory of Emerging Infectious Diseases
School of Public Health
The University of Hong Kong
Hong Kong SAR, China
www: https://guangchuangyu.github.io
-~--~~~~--~~--~--~---

[[alternative HTML version deleted]]

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

[Bioc-devel] Rgraphviz on ppc64le needs updated config.{sub, guess}

[Daniel Axtens]

Hi,

I haven't been able to find a way to report a bug on a package directly,
so I'm hoping this is the best way to report a bug, and my apologies in
advance if it isn't.

Rgraphviz fails to install on little-endian, 64-bit PowerPC (ppc64le).

Attempting to install leads to this error message:

...
checking whether gcc -std=gnu99 accepts -g... yes
checking for gcc -std=gnu99 option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: Preparing to compile Graphviz.
configure: Configuring bundled Graphviz.
checking build system type... config/config.guess: unable to guess system type

This script, last modified 2009-11-20, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (config/config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to  in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-11-20

uname -m = ppc64le
uname -r = 4.4.0-47-generic
uname -s = Linux
uname -v = #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016

/usr/bin/uname -p = 
/bin/uname -X = 

hostinfo   = 
/bin/universe  = 
/usr/bin/arch -k   = 
/bin/arch  = 
/usr/bin/oslevel   = 
/usr/convex/getsysinfo = 

UNAME_MACHINE = ppc64le
UNAME_RELEASE = 4.4.0-47-generic
UNAME_SYSTEM  = Linux
UNAME_VERSION = #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016
configure: error: cannot guess build type; you must specify one
make: *** No rule to make target 'install'.  Stop.
...

I've seen a number of similar errors in various non-R packages: it's
because ppc64le is quite a modern platform and 7-year-old config.guess
doesn't know about it.

It's really easy to fix: just update the bundled config.sub and
config.guess, either from the URLs suggested in the excerpt above, or
with autotools.

I'd be more than happy to test any patches, or to supply a patch if that
would be more helpful.

Regards,
Daniel

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

Re: [Bioc-devel] BiocStyle issue

[Leonardo Collado Torres]

Guangchuang, you can see at
https://github.com/Bioconductor/BiocStyle/issues/19 (the main github
repo for this package) that this issue is already been reported and
will be addressed asap by BiocStyle's maintainer.

On Tue, Nov 22, 2016 at 9:46 PM, Yu, Guangchuang  wrote:
>
> Dear all,
>
> I recompile my package and it throw the following error when building
> vignettes:
>
> unused arguments (self_contained, lib_dir, output_dir)
>
> I search  ?opts_knit, and couldn't find these parameters.
>
> In ?opts_knit, I find *self.contained* instead of *self_contained*.
>
> I remove the dependency of BiocStyle and recompile my package and it works.
>
>
> I search the source code of BiocStyle, and find the issue in
>
> https://github.com/Bioconductor-mirror/BiocStyle/blob/master/R/html_document.R#L66-L70
>
> Now rmarkdown:::pandoc_html_highlight_args (in latest release version 1.2)
> only accepts template and highlight parameters.
>
> This will fail the compilation of many Bioconductor packages. Please fix it.
>
> Using ::: is not recommended by Bioconductor and will not passed by
> BiocCheck (if I remember it correctly). But I find several packages by
> Bioconductor core team use it.
>
> Best wishes,
> Guangchuang
> --
> --~--~-~--~~~---~--~~
> Guangchuang Yu, PhD Candidate
> State Key Laboratory of Emerging Infectious Diseases
> School of Public Health
> The University of Hong Kong
> Hong Kong SAR, China
> www: https://guangchuangyu.github.io
> -~--~~~~--~~--~--~---
>
> [[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

[Bioc-devel] BiocStyle issue

[Yu, Guangchuang]

Dear all,

I recompile my package and it throw the following error when building
vignettes:

unused arguments (self_contained, lib_dir, output_dir)

I search  ?opts_knit, and couldn't find these parameters.

In ?opts_knit, I find *self.contained* instead of *self_contained*.

I remove the dependency of BiocStyle and recompile my package and it works.


I search the source code of BiocStyle, and find the issue in

https://github.com/Bioconductor-mirror/BiocStyle/blob/master/R/html_document.R#L66-L70

Now rmarkdown:::pandoc_html_highlight_args (in latest release version 1.2)
only accepts template and highlight parameters.

This will fail the compilation of many Bioconductor packages. Please fix it.

Using ::: is not recommended by Bioconductor and will not passed by
BiocCheck (if I remember it correctly). But I find several packages by
Bioconductor core team use it.

Best wishes,
Guangchuang
-- 
--~--~-~--~~~---~--~~
Guangchuang Yu, PhD Candidate
State Key Laboratory of Emerging Infectious Diseases
School of Public Health
The University of Hong Kong
Hong Kong SAR, China
www: https://guangchuangyu.github.io
-~--~~~~--~~--~--~---

[[alternative HTML version deleted]]

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

Re: [Rd] shared libraries: missing soname

[Joseph Mingrone]

Dirk Eddelbuettel  writes:

> On 22 November 2016 at 00:02, Joseph Mingrone wrote:
> | These are also not fatal errors on FreeBSD, where everything, for now, also 
> just
> | works.  ...until a library's interface changes.  You seem to be arguing that
> | sonmaes are pointless.  We disagree.

> You are putting words in my mouth. In my very first reply to you, I pointed
> out that (for non-BSD systems at least) the sonames do not matter as R loads
> the libraries itself, rather than via ldd.  No more, no less.

Let me restate.  You seem to be arguing that, because R itself doesn't consume
it's shared libraries via ldd(), sonames serve no purpose, in this case.  Please
correct me if I'm putting words in your mouth.

> | I can't say for certain (I'm not an rkward user), but looking at the build

> Why did _you_ then bring up rkward as an example? That was your suggestion.

Because you asked, "Yes, well, but are there other customers?"  Also, I'm trying
to put myself in the perspective of package users.

Is this a more appropriate example?

# ldd /usr/local/lib/R/library/tseries/libs/tseries.so | grep libR
libRblas.so => /usr/local/lib/R/lib/libRblas.so (0x80120c000)
libR.so => /usr/local/lib/R/lib/libR.so (0x801c0)


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

Re: [Bioc-devel] still issues with ggplot2/ggproto in Mac OS X, stable

[Hervé Pagès]

Hi Ramon,

All packages (including ggrepel) were re-installed from scratch after we
updated R on the release build machines one week ago. However it seems
that re-installing ggrepel on Mac doesn't help. On morelia:

> install.packages("ggrepel")
--- Please select a CRAN mirror for use in this session ---
HTTPS CRAN mirror

 1: 0-Cloud [https] 2: Algeria [https]
 3: Australia (Melbourne) [https]   4: Australia (Perth) [https]
 5: Austria [https] 6: Belgium (Ghent) [https]
 7: Brazil (RJ) [https] 8: Brazil (SP 1) [https]
 9: Bulgaria [https]   10: Canada (MB) [https]
11: Chile [https]  12: China (Beijing) [https]
13: China (Hefei) [https]  14: China (Lanzhou) [https]
15: Colombia (Cali) [https]16: Czech Republic [https]
17: Denmark [https]18: France (Lyon 1) [https]
19: France (Lyon 2) [https]20: France (Marseille) [https]
21: France (Montpellier) [https]   22: France (Paris 2) [https]
23: Germany (Falkenstein) [https]  24: Germany (Münster) [https]
25: Iceland [https]26: India [https]
27: Ireland [https]28: Italy (Padua) [https]
29: Japan (Tokyo) [https]  30: Malaysia [https]
31: Mexico (Mexico City) [https]   32: New Zealand [https]
33: Norway [https] 34: Philippines [https]
35: Russia (Moscow) [https]36: Serbia [https]
37: Spain (A Coruña) [https]   38: Spain (Madrid) [https]
39: Switzerland [https]40: Taiwan (Chungli) [https]
41: Turkey (Denizli) [https]   42: UK (Bristol) [https]
43: UK (Cambridge) [https] 44: UK (London 1) [https]
45: USA (CA 1) [https] 46: USA (IA) [https]
47: USA (IN) [https]   48: USA (KS) [https]
49: USA (MI 1) [https] 50: USA (TN) [https]
51: USA (TX) [https]   52: USA (WA) [https]
53: (HTTP mirrors)

Selection: 52
trying URL 
'https://cran.fhcrc.org/bin/macosx/mavericks/contrib/3.3/ggrepel_0.6.3.tgz'

Content type 'unknown' length 802187 bytes (783 KB)
==
downloaded 783 KB


The downloaded binary packages are in
	/var/folders/1c/_5ks0mjd3gvf_dq14g3thsr4gn/T//RtmpMwsaS 
/downloaded_packages

> library(ggrepel)
Loading required package: ggplot2
> GeomTextRepel
Error: GeomTextRepel was built with an incompatible version of ggproto.
Please reinstall the package that provides this extension.

So it looks like the Mac binary itself is broken. Note that the CRAN
check results for ggrepel are OK:

  http://cran.fhcrc.org/web/checks/check_results_ggrepel.html

but that's because 'R CMD check' cannot detect a stale binary package
because it is run on the source package.

The timestamp for ggrepel_0.6.3.tgz can be seen here:

  http://cran.fhcrc.org/bin/macosx/mavericks/contrib/3.3/

It indicates that the binary was made on 21-Oct-2016 which predates the
latest change in ggplot2 (2016-11-11) that is supposedly the culprit.

That means the ggrepel Mac binary would need to be re-generated.
Someone would need to contact the CRAN people about this with Cc the
ggrepel people. Probably the best solution is for the ggrepel people to
bump the version of their package otherwise people who already have the
old broken binary installed on their machine won't get the new binary
when doing update.packages().

Note that the Windows binary doesn't have this problem because it was
generated on 20-Nov-2016 i.e. after the change in ggplot2:

  http://cran.fhcrc.org/bin/windows/contrib/3.3/

Finally note that we could work around the problem on morelia by
re-installing ggrepel from source but that would just put a lid on
the problem: the end user would still see the problem on his/her
machine.

Cheers,
H.


On 11/22/2016 02:14 PM, Ramon Diaz-Uriarte wrote:

Dear All,

Sorry to return to this issue, but on Morelia (Mac OS X, stable), we are
still seeing packages break during build with this message

"GeomTextRepel was built with an incompatible version of ggproto.
Please reinstall the package that provides this extension.
Execution halted"


that affects many (all?) packages that depend on ggrepel or other packages
that depend on ggplot2/ggproto.

Best,

R.





--
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: [Bioc-devel] Coverage test badge not updating

[Obenchain, Valerie]

Thanks Leo. This should be fixed now - the url format needed to be updated.

Valerie


On 11/18/2016 08:17 AM, Leonardo Collado Torres wrote:
> Hi Valerie,
>
> Thanks! I do see the badges now but the percent reported seems off.
> Particularly:
>
> * http://bioconductor.org/packages/release/bioc/html/recount.html
> shows a 65% badge with a link
> to https://codecov.io/github/Bioconductor-mirror/recount?branch=release-3.4
> which has a 97% coverage
> * http://bioconductor.org/packages/devel/bioc/html/recount.html shows
> the correct percent in the badge
> (matching https://codecov.io/github/Bioconductor-mirror/recount?branch=master
> )
>
> It could be related to recount failing the latest build report on
> release. Or maybe it's another alphabetical bug because the derfinder*
> packages look ok.
>
> Best,
> Leo
>
> On Fri, Nov 18, 2016 at 9:12 AM, Obenchain, Valerie
>  > wrote:
>
> Coverage is now up and running for the release packages. I think all
> looks well... let me know if you see any problems.
>
> Valerie
>
>
> On 11/01/2016 03:14 PM, Hervé Pagès wrote:
> > Hi Leo,
> >
> > I can confirm that while Bioc 3.4 was in devel, package coverage was
> > computed only for the devel version of packages. When we released
> > BioC 3.4, I moved the compute_coverage script that used to run on
> > zin1 (which used to be the central build node for BioC 3.4 for
> months)
> > to malbec2, which is the central build node for BioC 3.5.
> >
> > So yes, package coverage is still only computed for devel packages
> > at the moment. We'll see if we can restore package coverage for
> > release. If, for whatever reason, this is not possible or is too
> > complicated, we'll remove the badges from the release landing pages.
> >
> > Thanks for the reminder!
> >
> > Cheers,
> > H.
> >
> > On 11/01/2016 12:18 PM, Leonardo Collado Torres wrote:
> >> Hi,
> >>
> >> I know that there are several old threads about the coverage badges
> >> including this thread. Basically, while Bioc 3.4 was in devel, the
> >> coverage badges didn't work for Bioc release (3.3). However,
> now that
> >> 3.4 has been released, the badges for Bioc-release (3.4) are
> still not
> >> working and they only work for Bioc-devel (3.5).
> >>
> >> In one of the threads, Dan mentioned that something at codecov had
> >> changed and that he was going to ask for advice on how to
> proceed. I'm
> >> just curious if there are any updates on this issue. If it's only
> >> possible to have the coverage badges work for one branch, then it
> >> might be best to leave them in Bioc-devel (given Jim's arguments
> >> earlier) and remove them from Bioc-release.
> >>
> >> Best,
> >> Leo
> >>
> >> On Mon, Nov 23, 2015 at 4:25 PM, Leonardo Collado Torres
> >> > wrote:
> >>> Thank you for fixing this Jim! I noticed it working now on devel.
> >>> However, I believe that is still not working for the release
> branch.
> >>>
> >>> Cheers,
> >>> Leo
> >>>
> >>> On Fri, Nov 20, 2015 at 3:37 PM, Jim Hester
> > wrote:
>  The coverage tests were inadvertently not running, but they
> are now
>  re-enabled.
> 
>  Please let us know if you notice any other problems
> 
>  Jim
> 
>  On Tue, Nov 17, 2015 at 12:16 PM, Leonardo Collado Torres
> >
>  wrote:
> > Hi,
> >
> > In my packages I enabled testing (via testthat) a few weeks
> ago. I did
> > so as can be seen in
> >
> >
> 
> https://github.com/leekgroup/derfinderHelper/commit/26d9d5543d9082f85bbb2d0ae9f02c5c309b9a48
> 
> 
> > for the changes to tests/test-all.R You can see that the
> tests are
> > actually being run at
> >
> >
> 
> http://bioconductor.org/checkResults/devel/bioc-LATEST/derfinderHelper/zin2-checksrc.html
> 
> 
> > Specifically at the lines:
> >
> > * checking tests ...
> >   Running ‘test-all.R’ [3s/13s]
> >  [3s/14s] OK
> >
> > I'm wondering if the coverage tests are only run at a less
> frequent
> > pace (say once per month) or if my tests/test-all.R file is
> still
> > posing problems to covr.
> >
> > Thanks,
> > Leo
> >
> > ___
> > Bioc-devel@r-project.org 

[Bioc-devel] still issues with ggplot2/ggproto in Mac OS X, stable

[Ramon Diaz-Uriarte]

Dear All,

Sorry to return to this issue, but on Morelia (Mac OS X, stable), we are
still seeing packages break during build with this message

"GeomTextRepel was built with an incompatible version of ggproto.
Please reinstall the package that provides this extension.
Execution halted"


that affects many (all?) packages that depend on ggrepel or other packages
that depend on ggplot2/ggproto.

Best,

R.



-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

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

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

[Gabriel Becker]

Martin et al.,




On Tue, Nov 22, 2016 at 2:12 AM, Martin Maechler  wrote:

>
> Note that my premise was really to get *away* from inheriting
> too much from 'test'.
> Hence, I have *not* been talking about replacing ifelse() but
> rather of providing a new  ifelse2()
>
>[ or if_else()  if Hadley was willing to ditch the dplyr one
>in favor of a base one]
>
> > Specifically, based on an unrelated discussion with Henrik Bengtsson
> on
> > Twitter, I wonder if preserving the recycling behavior test is
> longer than
> > yes, no, but making the case where
>
> > length( test ) < max(length( yes ), length( no ))
>
> > would simplify usage for userRs in a useful way.
>

That was a copyediting bug on my part, it seems I hit send with my message
only half-edited/proofread. Apologies.

 That should have said that making the case where test is the one that will
be recycled (because it is shorter than either yes or no) an error. My
claim is that the fact that test itself can be recycled, rather than just
yes or no, is confusing to many R users. If we are writing an ifelse2 we
might want to drop that feature and just throw an error in that case.
(Users could still use the original ifelse if they understand and
specifically want that behavior).

Does that make more sense?



>
> > Also, If we combine a stricter contract that the output will always
> be of
> > length with the suggestion of a specified output class
>
>
Here, again, I was talking about the restriction that the output be
guaranteed to be the length of test, regardless of the length of yes and
no. That, combined with a specific, guaranteed output class would make a
much narrower/more restricted but also (I argue) much easier to understand
function. Particularly for beginning and intermediate users.

I do hear what you're saying about silent conversion, though, so what I'm
describing might be a third function (ifelse3 for lack of a better name for
now), as you pointed out.


> that was not my intent here but would be another interesting
> extension. However, I would like to keep  R-semantic silent coercions
> such as
>   logical < integer < double < complex
>
> and your pseudo code below would not work so easily I think.
>
> > the pseudo code could be
>
> (I'm changing assignment '=' to  '<-' ...  [please!] )
>
> > ifelse2 <- function(test, yes, no, outclass) {
> >   lenout  <- length(test)
> >   out <- as( rep(yes, length.out <- lenout), outclass)
> >   out[!test] <- as(rep(no, length.out = lenout)[!test], outclass)
> >   # handle NA stuff
> >   out
> > }
>
>
> > NAs could be tricky if outclass were allowed to be completely
> general, but
> > doable, I think? Another approach  if we ARE fast-passing while
> leaving
> > ifelse intact is that maybe NA's in test just aren't allowed in
> ifelse2.
> > I'm not saying we should definitely do that, but it's possible and
> would
> > make things faster.
>
> > Finally, In terms of efficiency, with the stuff that Luke and I are
> working
> > on, the NA detection could be virtually free in certain cases, which
> could
> > give a nice boost for long vectors  that don't have any NAs (and
> 'know'
> > that they don't).
>
> That *is* indeed a very promising prospect!
> Thank you in advance!
>
> > Best,
> > ~G
>
> I still am bit disappointed by the fact that it seems nobody has
> taken a good look at my ifelse2() proposal.
>

I plan to look at it soon. Thanks again for all your work.

~G


>
> I really would like an alternative to ifelse() in *addition* to
> the current ifelse(), but hopefully in the future being used in
> quite a few places instead of ifelse()
> efficiency but for changed semantics, namely working for considerably
> more "vector like" classes of  'yes' and 'no'  than the current
> ifelse().
>
> As I said, the current proposal works for objects of class
>"Date", "POSIXct", "POSIXlt", "factor",  "mpfr" (pkg 'Rmpfr')
> and hopefully for "sparseVector" (in a next version of the 'Matrix' pkg).
>
> Martin
>
> > On Tue, Nov 15, 2016 at 3:58 AM, Martin Maechler <
> maech...@stat.math.ethz.ch
> >> wrote:
>
> >> Finally getting back to this :
> >>
> >> > Hadley Wickham 
> >> > on Mon, 15 Aug 2016 07:51:35 -0500 writes:
> >>
> >> > On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
> >> >  wrote:
> >> >>> >> One possibility would also be to consider a
> >> >>> "numbers-only" or >> rather "same type"-only {e.g.,
> >> >>> would also work for characters} >> version.
> >> >>>
> >> >>> > I don't know what you mean by these.
> >> >>>
> >> >>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
> >> >>> which is very relevant, thank you Bob!
> >> >>>
> >> >>> As I have found, that actually works in such a "same
> 

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

[Martin Maechler]

> Gabriel Becker 
> on Tue, 15 Nov 2016 11:56:04 -0800 writes:

> All,
> Martin: Thanks for this and all the other things you are doing to both
> drive R forward and engage more with the community about things like this.

> Apologies for missing this discussion the first time it came around and if
> anything here has already been brought up, but I wonder what exactly you
> mean when you want recycling behavior.

Thank you, Gabe.

Note that my premise was really to get *away* from inheriting
too much from 'test'.
Hence, I have *not* been talking about replacing ifelse() but
rather of providing a new  ifelse2()

   [ or if_else()  if Hadley was willing to ditch the dplyr one
   in favor of a base one]

> Specifically, based on an unrelated discussion with Henrik Bengtsson on
> Twitter, I wonder if preserving the recycling behavior test is longer than
> yes, no, but making the case where

> length( test ) < max(length( yes ), length( no ))

> would simplify usage for userRs in a useful way.

I'm sorry I don't understand the sentence above.

> I suspect it's easy to
> forget that the result is not guaranteed to be the length of  test, even
> for intermediate and advanced users familiar with ifelse and it's
> strengths/weaknesses.

> I certainly agree (for what that's worth...) that

> x = rnorm(100)

> y = ifelse2(x > 0, 1L, 2L)

> should continue to work.

(and give a a length 10 result).
Also
ifelse2(x > 0, sqrt(x), 0L)

should work even though  class(sqrt(x)) is "numeric" and the one
of 0L is "integer", and I'd argue

ifelse2(x < 0, sqrt(x + 0i), sqrt(x))

should also continue to work as with ifelse().

> Also, If we combine a stricter contract that the output will always be of
> length with the suggestion of a specified output class 

that was not my intent here but would be another interesting
extension. However, I would like to keep  R-semantic silent coercions
such as
  logical < integer < double < complex

and your pseudo code below would not work so easily I think.

> the pseudo code could be

(I'm changing assignment '=' to  '<-' ...  [please!] )

> ifelse2 <- function(test, yes, no, outclass) {
>   lenout  <- length(test)
>   out <- as( rep(yes, length.out <- lenout), outclass)
>   out[!test] <- as(rep(no, length.out = lenout)[!test], outclass)
>   # handle NA stuff
>   out
> }


> NAs could be tricky if outclass were allowed to be completely general, but
> doable, I think? Another approach  if we ARE fast-passing while leaving
> ifelse intact is that maybe NA's in test just aren't allowed in ifelse2.
> I'm not saying we should definitely do that, but it's possible and would
> make things faster.

> Finally, In terms of efficiency, with the stuff that Luke and I are 
working
> on, the NA detection could be virtually free in certain cases, which could
> give a nice boost for long vectors  that don't have any NAs (and 'know'
> that they don't).

That *is* indeed a very promising prospect!
Thank you in advance! 

> Best,
> ~G

I still am bit disappointed by the fact that it seems nobody has
taken a good look at my ifelse2() proposal.

I really would like an alternative to ifelse() in *addition* to
the current ifelse(), but hopefully in the future being used in
quite a few places instead of ifelse()
efficiency but for changed semantics, namely working for considerably
more "vector like" classes of  'yes' and 'no'  than the current
ifelse().

As I said, the current proposal works for objects of class
   "Date", "POSIXct", "POSIXlt", "factor",  "mpfr" (pkg 'Rmpfr')
and hopefully for "sparseVector" (in a next version of the 'Matrix' pkg).

Martin

> On Tue, Nov 15, 2016 at 3:58 AM, Martin Maechler 
> wrote:

>> Finally getting back to this :
>> 
>> > Hadley Wickham 
>> > on Mon, 15 Aug 2016 07:51:35 -0500 writes:
>> 
>> > On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
>> >  wrote:
>> >>> >> One possibility would also be to consider a
>> >>> "numbers-only" or >> rather "same type"-only {e.g.,
>> >>> would also work for characters} >> version.
>> >>>
>> >>> > I don't know what you mean by these.
>> >>>
>> >>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
>> >>> which is very relevant, thank you Bob!
>> >>>
>> >>> As I have found, that actually works in such a "same
>> >>> type"-only way: It does not try to coerce, but gives an
>> >>> error when the classes differ, even in this somewhat
>> >>> debatable case :
>> >>>
>> >>> > dplyr::if_else(c(TRUE, FALSE), 2:3, 0+10:11) Error:
>> >>> `false` has type 'double' not 'integer'
>> >>> >
>> >>>
>> >>> As documented,