[R-pkg-devel] bit, bit64, ff and greeNsort

[Jens Oehlschlägel]

Dear package maintainers,

Dear users of packages `bit`, `bit64`, `ff`,

Everyone interested in sustainable sorting algorithms,

I submitted updated versions for the upcoming R 4.5.0. The are only 
minor changes (see the NEWS files) but there is one important change in 
bit64:


    o setting options(integer64_semantics="new")
  gives the better semantics suggested by Ofek Shilon.
  Downstream package authors: please test and adjust to the new 
semantics,

  we plan to make that the default.

After 25 years volunteer work for the R community, that was my last 
combined submission for packages `bit`, `bit64` and `ff`.


I learned S+ in 1996 and supported R's 1.0 release in 2000 with bug 
testing, a small code contribution to `pairs` and motivating the 
core-team to replace 'NA' with NA_character_.


In 2007 Daniel Adler and I published `ff`: the first R package allowing 
big out of memory data.frames was a nail in the coffin of SAS dominance 
and helped R into the big data era.


2009 and 2012 followed `bit`, `bit64` to enhance R's data types somewhat 
with `bit` vectors and signed `integer64`. Package `bit` supported 
efficient selection in `ff`. Package `bit64` was an emergency 
development in order to establish rather `integer64' than another 
`int64` package that had too expensive performance.


Since 2011 I work for an employer that does not use R, and maintenance 
of R packages is a little rewarded burden.


Since 2010 my priorities shifted to fighting global heating by 
developing more sustainable sorting algorithms that provide better 
trade-offs between memory investments, compute costs and adaptivity to 
easier input patterns. My R&D project was successfully completed 2024 
with theory and design of new symmetric sorting algorithms that can 
replace Quicksort, Mergesort and Timsort. Lots of info at greeNsort.org. 
I have an R package `greeNsort` on github with a research testbed that 
can measure RAM, CPU and RAPL energy for ≈150 equally tuned sorting 
algorithms on multiple test patterns.


Since 24.2.2022 my priorities are on strengthening resilience of 
European civil society.


Hence I happily accept the generous offer of Michael Chirico to carry 
forward the maintenance of packages `bit` and `bit64`. Please support 
him in the difficult task of developing very close to the core as a 
normal package author.


I will continue bug-fixing `ff` as time permits, although a modern C++ 
rewrite would be preferable, which


1) supports long vectors

2) avoids copying between Mapped Memory and R's memory

3) simplifies the package, particularly removes the "virtual window" 
complexity


All the best


Jens Oehlschlägel

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

Re: [R-pkg-devel] failing S3 dispatch

[Jens Oehlschlägel]

Thanks Duncan,

I finally found the reason for the mysterious dispatch-failure: I had an 
unwanted and unexported replicated definition of the 'clone' generic in 
ff's namespace (a left-over).


I still don't understand how this prevented the proper dispatch since 
the duplicate in ff's namespace it was *not* called. I further 
experimented and *any* non-exported object matching the name of the 
generic caused the problem. Scary, maybe worth a check!


Anyhow, removing the non-exported object solved the problem.

Best regards

Jens


On 20.10.21 13:43, Jens Oehlschlägel wrote:

Thank you Duncan,

bit NAMESPACE has

S3method(clone,default)
export(clone)

ff NAMESPACE has

import(bit)
# wish of CRAN maintainers: export another time here (now maintained 
and exported in bit)
# without this R CMD CHECK complained, but with it R CMD CHECK 
complains also, how to export again and why?

# clone
#,clone.default
 clone.ff
,clone.ffdf
S3method("clone",ff)
S3method(clone, ffdf)
# wish of CRAN maintainers: export another time here (now maintained 
and exported in bit)

#S3method(clone, default)

Best

Jens



On 20.10.21 11:02, Duncan Murdoch wrote:

On 19/10/2021 3:43 p.m., Jens Oehlschlägel wrote:

I didn't find an answer elsewhere:

My package 'bit' creates a S3 generic 'clone' and exports it.
Furthermore it registers a S3 method 'clone.default' (not exported).

My package 'ff' imports package 'bit' and exports and registers a 
new S3

method 'clone.ff'. However, calling 'clone(ffobj)' dispatches to
clone.default instead of clone.ff !? Why?


You should show us the NAMESPACE entries involving clone and clone.ff 
from ff.


Some comments that may or may not be relevant:

 - Normally you wouldn't export clone.ff, it's enough to register it 
using S3method().


 - You may have created a new generic named clone, and that's what 
clone.ff would attach itself to.  You can have bit::clone and 
ff::clone as different generics and that would cause problems.




What is the recommended way to create new S3-methods that get
dispatched? In earlier versions of the packages I simply exported
everything - that worked.


I import the generic and use S3method(generic, method).  I don't 
export the methods, so I wouldn't be able to call z <- clone.ff(a).


Duncan Murdoch



Best


Jens


  > require(ff)
  >
  > a <- as.ff(0:9)
  > class(x)
[1] "ff_vector" "ff"
  >
  > x <- clone(a)
  > y <- bit:::clone.default(a)
  > z <- clone.ff(a)
  >
  > # cloned ffobjects should have different filenames>

  > filename(a)  # original
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(x)  # unexpected equal (dispatch to clone.default)
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(y)  # expected equal
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(z)  # OK
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed551d3ee66.ff"

  > version
     _
platform   x86_64-pc-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  4
minor  1.1
year   2021
month  08
day    10
svn rev    80725
language   R
version.string R version 4.1.1 (2021-08-10)
nickname   Kick Things

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

Re: [R-pkg-devel] failing S3 dispatch

[Jens Oehlschlägel]

Thank you Duncan,

bit NAMESPACE has

S3method(clone,default)
export(clone)

ff NAMESPACE has

import(bit)
# wish of CRAN maintainers: export another time here (now maintained and 
exported in bit)
# without this R CMD CHECK complained, but with it R CMD CHECK complains 
also, how to export again and why?

# clone
#,clone.default
 clone.ff
,clone.ffdf
S3method("clone",ff)
S3method(clone, ffdf)
# wish of CRAN maintainers: export another time here (now maintained and 
exported in bit)

#S3method(clone, default)

Best

Jens



On 20.10.21 11:02, Duncan Murdoch wrote:

On 19/10/2021 3:43 p.m., Jens Oehlschlägel wrote:

I didn't find an answer elsewhere:

My package 'bit' creates a S3 generic 'clone' and exports it.
Furthermore it registers a S3 method 'clone.default' (not exported).

My package 'ff' imports package 'bit' and exports and registers a new S3
method 'clone.ff'. However, calling 'clone(ffobj)' dispatches to
clone.default instead of clone.ff !? Why?


You should show us the NAMESPACE entries involving clone and clone.ff 
from ff.


Some comments that may or may not be relevant:

 - Normally you wouldn't export clone.ff, it's enough to register it 
using S3method().


 - You may have created a new generic named clone, and that's what 
clone.ff would attach itself to.  You can have bit::clone and 
ff::clone as different generics and that would cause problems.




What is the recommended way to create new S3-methods that get
dispatched? In earlier versions of the packages I simply exported
everything - that worked.


I import the generic and use S3method(generic, method).  I don't 
export the methods, so I wouldn't be able to call z <- clone.ff(a).


Duncan Murdoch



Best


Jens


  > require(ff)
  >
  > a <- as.ff(0:9)
  > class(x)
[1] "ff_vector" "ff"
  >
  > x <- clone(a)
  > y <- bit:::clone.default(a)
  > z <- clone.ff(a)
  >
  > # cloned ffobjects should have different filenames>

  > filename(a)  # original
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(x)  # unexpected equal (dispatch to clone.default)
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(y)  # expected equal
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
  >
  > filename(z)  # OK
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed551d3ee66.ff"

  > version
     _
platform   x86_64-pc-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  4
minor  1.1
year   2021
month  08
day    10
svn rev    80725
language   R
version.string R version 4.1.1 (2021-08-10)
nickname   Kick Things

__
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] failing S3 dispatch

[Jens Oehlschlägel]

I didn't find an answer elsewhere:

My package 'bit' creates a S3 generic 'clone' and exports it. 
Furthermore it registers a S3 method 'clone.default' (not exported).


My package 'ff' imports package 'bit' and exports and registers a new S3 
method 'clone.ff'. However, calling 'clone(ffobj)' dispatches to 
clone.default instead of clone.ff !? Why?


What is the recommended way to create new S3-methods that get 
dispatched? In earlier versions of the packages I simply exported 
everything - that worked.


Best


Jens


> require(ff)
>
> a <- as.ff(0:9)
> class(x)
[1] "ff_vector" "ff"
>
> x <- clone(a)
> y <- bit:::clone.default(a)
> z <- clone.ff(a)
>
> # cloned ffobjects should have different filenames>

> filename(a)  # original
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
>
> filename(x)  # unexpected equal (dispatch to clone.default)
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
>
> filename(y)  # expected equal
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed54cbb5060.ff"
>
> filename(z)  # OK
[1] "/tmp/Rtmpk17JRZ/ff/clone1ed551d3ee66.ff"

> version
   _
platform   x86_64-pc-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  4
minor  1.1
year   2021
month  08
day    10
svn rev    80725
language   R
version.string R version 4.1.1 (2021-08-10)
nickname   Kick Things

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

Re: [R-pkg-devel] Rcpp with clang++ -stdlib=libc++ ?

[Dr . Jens Oehlschlägel]

Thank you Dirk and Kevin,

that was very helpful and

 >  sudo apt install libc++-dev libc++abi-dev

did the job!

Great, this was very important to me.
Thanks again

Jens



On 13.09.20 02:55, Kevin Ushey wrote:
> My understanding is that many Linux OSes package the clang compiler, the 
> libc++ standard library, and the headers used by the libc++ standard 
> library separately. To install those headers, you likely need (e.g. on 
> Ubuntu):
> 
>      sudo apt install libc++-dev libc++abi-dev
> 
> to be able to build and compile programs against libc++.
> 
> This also comes with the caveat that mixing programs built against 
> different standard library implementations is in general a bad idea, so 
> you may see issues if you mix libraries compiled with libstdc++ and 
> libc++ in the same R session. (This can come up with R packages that 
> link to other libraries installed on the system, which will typically be 
> built with and linked against the "default" system compiler + standard 
> library implementations.) I'm not sure if this will be an issue in 
> practice with what you're doing, but it's worth being aware of.
> 
> Best,
> Kevin
> 
> On Sat, Sep 12, 2020 at 5:50 AM Dirk Eddelbuettel  <mailto:e...@debian.org>> wrote:
> 
> 
> Hi Jens,
> 
> On 11 September 2020 at 21:00, Dr. Jens Oehlschlägel wrote:
> | I can compile a package under clang++ with -stdlib=libstdc++, but
> with -stdlib=libc++ I get
> |
> | "
> | In file included from
> 
> /home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/r/headers.h:67:
> |
> 
> /home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/platform/compiler.h:100:10:
> fatal error: 'cmath' file not found
> | #include 
> |  ^~~
> | 1 error generated.
> | "
> |
> | Is there any howto for using Rcpp with -stdlib=libc++ ?
> 
> That has zero to do with Rcpp.  You are lacking a C++ library header
> when
> switching the C++ standard library along with clang. Nothing that
> Rcpp ships,
> or governs, or selects.
> 
> I am forgetting the fine details here (and someone may hopefully fill in
> fuller details) but in short, "that is just the way it is".  I think we
> simply pivot back to the g++ standard C++ library even when using
> clang++.
> 
> Cheers from Chicago,  Dirk
> 
> | Greetings from Munich
> |
> | Jens Oehlschlägel
> |
> |
> | P.S.
> |
> | Package Makevars
> | CXX_STD = CXX17
> | PKG_CXXFLAGS=-O3 -march=native -pthread
> | PKG_LIBS=-latomic -pthread
> |
> | ~.R/Makevars
> | CXX17 = clang++ -stdlib=libc++
> | CXX17FLAGS = -fstack-protector-strong -D_FORTIFY_SOURCE=2 -g $(LTO)
> | CXX17STD = -std=c++17
> |
> | > packageVersion("Rcpp")
> | [1] ‘1.0.5’
> |
> | > version
> |    _
> | platform   x86_64-pc-linux-gnu
> | arch   x86_64
> | os linux-gnu
> | system x86_64, linux-gnu
> | status
> | major  4
> | minor  0.2
> | year   2020
> | month  06
> | day    22
> | svn rev    78730
> | language   R
> | version.string R version 4.0.2 (2020-06-22)
> | nickname   Taking Off Again
> |
> | __
> | R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> <mailto:e...@debian.org>
> 
> __
> R-package-devel@r-project.org <mailto: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] Rcpp with clang++ -stdlib=libc++ ?

[Dr . Jens Oehlschlägel]

I can compile a package under clang++ with -stdlib=libstdc++, but with 
-stdlib=libc++ I get

"
In file included from 
/home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/r/headers.h:67:
/home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/platform/compiler.h:100:10:
 fatal error: 'cmath' file not found
#include 
 ^~~
1 error generated.
"

Is there any howto for using Rcpp with -stdlib=libc++ ?
Greetings from Munich

Jens Oehlschlägel

 
P.S.

Package Makevars
CXX_STD = CXX17
PKG_CXXFLAGS=-O3 -march=native -pthread
PKG_LIBS=-latomic -pthread

~.R/Makevars
CXX17 = clang++ -stdlib=libc++
CXX17FLAGS = -fstack-protector-strong -D_FORTIFY_SOURCE=2 -g $(LTO)
CXX17STD = -std=c++17

> packageVersion("Rcpp")
[1] ‘1.0.5’

> version
   _  
platform   x86_64-pc-linux-gnu
arch   x86_64 
os linux-gnu  
system x86_64, linux-gnu  
status
major  4  
minor  0.2
year   2020   
month  06 
day    22 
svn rev    78730  
language   R  
version.string R version 4.0.2 (2020-06-22)
nickname   Taking Off Again

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

[R-pkg-devel] need help to identify ff error on r-oldrel-macos-x86_64

[Dr . Jens Oehlschlägel]

Dear Mac users,

Can someone of you identify the cause of the problem in

https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/ff-00check.html

I can't because I don't have access to a Mac.

It seems that gc() after rm(ffobject) does not remove the ff file in rows

(@test-zero_lengths.R#34)
(@test-zero_lengths.R#35)
(@test-zero_lengths.R#63)
(@test-zero_lengths.R#64)

so maybe the finalizer is not triggered? Does delete(ffobject) work?

Kind regards


Jens


 Forwarded Message 
Subject: Re: CRAN package ff
Date: Mon, 24 Aug 2020 08:23:24 +0100
From: Prof Brian Ripley 
Reply-To: c...@r-project.org
To: jens.oehlschlae...@truecluster.com
CC: c...@r-project.org

On 24/08/2020 08:19, Prof Brian Ripley wrote:
> Dear maintainer,
>
> Please see the problems shown on
> .
>
> Please correct before 2020-09-07 to safely retain your package on CRAN.
>
> The CRAN Team
>
I am seeing the macOS errors on all flavours: a more complete log is
installed.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

* using log directory ‘/Users/ripley/R/packages/tests-devel/ff.Rcheck’
* using R Under development (unstable) (2020-08-10 r79000)
* using platform: x86_64-apple-darwin17.7.0 (64-bit)
* using session charset: UTF-8
* using option ‘--no-stop-on-test-error’
* checking for file ‘ff/DESCRIPTION’ ... OK
* this is package ‘ff’ version ‘4.0.2’
* package encoding: UTF-8
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘ff’ can be installed ... [42s/55s] OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... [33s/44s] OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in shell scripts ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking pragmas in C/C++ headers and code ... OK
* checking compilation flags used ... OK
* checking compiled code ... OK
* checking installed files from ‘inst/doc’ ... OK
* checking examples ... [13s/18s] OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ...
  Running ‘testthat.R’
 ERROR
Running the tests in ‘tests/testthat.R’ failed.
Complete output:
  > library(testthat)
  > test_check("ff")
  Loading required package: ff
  Loading required package: bit
  
  Attaching package: 'bit'
  
  The following object is masked from 'package:base':
  
  xor
  
  Attaching package ff
  - 
getOption("fftempdir")=="/var/folders/gv/f60jb6tn7fxb9sz1yfr7d_vmgp/T//Rtmp8HK6B8/working_dir/Rtmp4HJlIg/ff"
  
  - getOption("ffextension")=="ff"
  
  - getOption("ffdrop")==TRUE
  
  - getOption("fffinonexit")==TRUE
  
  - getOption("ffpagesize")==65536
  
  - getOption("ffcaching")=="mmnoflush"  -- consider "ffeachflush" if your 
system stalls on large writes
  
  - getOption("ffbatchbytes")==16777216 -- consider a different value for 
tuning your system
  
  - getOption("ffmaxbytes")==536870912 -- consider a different value for tuning 
your system
  
  
  Attaching package: 'ff'
  
  The following objects are masked from 'package:utils':
  
  write.csv, write.csv2
  
  The following objects are masked from 'package:base':
  
  is.factor, is.ordered
  
  ── 1. Failure: file size is correct  when creating ff integer from 
scratch (@tes
  file.exists(f0) isn't false.
  
  ── 2. Fa

Re: [R-pkg-devel] Package can't be imported with Suggests

[Dr . Jens Oehlschlägel]

Dirk,

This sounds familiar: in package 'bit' for  

bit | bitwhich 

R did neither S3-dispatch to "|.bit" nor to "|.bitwhich" but nonsensically to 
the default method. 

It took me a while to reverse my class thinking enough to realize that I could 
get control by forcing dispatch to a common class 'booltype'.  So far this 
sounds harmless. But the truth is that to make this work 'booltype' must not be 
a common superclass but needs to be a subclass of 'bit' in bit-objects and 
needs to be a subclass of 'bitwhich' in bitwhich-objects. Only then the 
dispatch to "|.booltype" dominates and we get a seemingly conflict-free 
dispatch to "|.booltype" which then resolves possible conflicts. I hope using 
R's S3 class system upside-down does not introduce "another problem". Citing 
from "Beautiful Code":

"
it is worth bringing our discussion to an end by noting that Lampson attributes 
the aphorism that started our exploration (all problems in computer science can 
be solved by another level of indirection) to David Wheeler, the inventor of 
the subroutine. Significantly, Wheeler completed his quote with another phrase: 
"But that usually will create another problem."
"

Best

Jens



#
> Gesendet: Donnerstag, 06. August 2020 um 01:30 Uhr
> Von: "Dirk Eddelbuettel" 
> An: "William Dunlap" 
> Cc: "r-package-devel@r-project.org" 
> Betreff: Re: [R-pkg-devel] Package can't be imported with Suggests
>
> 
> On 5 August 2020 at 16:25, William Dunlap wrote:
> | You might make a second package that depends only on nimble and your
> | main package can then suggest that second package and JAGS.
> 
> Nice. "We can solve any problem by introducing an extra level of indirection."
> 
> See https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
> 
> Dirk
>  
> | Bill Dunlap
> | TIBCO Software
> | wdunlap tibco.com
> | 
> | On Wed, Aug 5, 2020 at 3:36 PM Simon Bonner  wrote:
> | >
> | > Hi all,
> | >
> | > I’m wondering if someone an offer advice on a problem I’m facing in 
> developing a package.
> | >
> | > My package essentially generates code and formats data for one of two 
> MCMC sampling engines, JAGS accessed via rjags or nimble (a native R 
> package), calls the engines, and then provides functions to access the 
> results. Since only one of the engines is needed I would like to include 
> rjags and nimble in Suggests in the DESCRIPTION and use requireNamespace() to 
> load the appropriate package when its functionality is needed.
> | >
> | > Unfortunately, nimble will not work with this mechanism. It relies on a 
> complex mechanism to compile C++ code to run the sampler, and some of the 
> functions cannot be found when the package is loaded in this way. I’ve been 
> in touch with the maintainers and they are aware of the issue but the current 
> fix is to include the package under Depends. However, this forces a user to 
> install nimble (which itself requires compiling lengthy C++ code) even if the 
> user intends to run the sampler in JAGS.
> | >
> | > I thought I’d solved the problem by including nimble in Suggests and then 
> loading it via library() so that all of its functions are attached. This 
> works, but produces a note during the check:
> | > ❯ checking dependencies in R code ... NOTE
> | >   'library' or 'require' call to ‘nimble’ in package code.
> | > Please use :: or requireNamespace() instead.
> | > See section 'Suggested packages' in the 'Writing R Extensions' manual
> | >
> | > What is the recommendation?
> | >
> | > I see two options:
> | >
> | >
> | >   1.  Include nimble in Depends and force user to install it.
> | >   2.  Ignore the note and explain the problem when I resubmit to CRAN.
> | >
> | > Am I missing anything?
> | >
> | > Thanks in advance!
> | >
> | > Simon
> | >
> | >
> | >
> | >
> | >
> | > Simon Bonner
> | > Assistant Professor of Environmetrics
> | > Department of Statistical and Actuarial Sciences
> | > University of Western Ontario
> | >
> | > Office: Western Science Centre rm 276
> | >
> | > Email: sbonn...@uwo.ca | Telephone: 519-661-2111 
> x88205 | Fax: 519-661-3813
> | > Twitter: @bonnerstatslab | Website: 
> http://simon.bonners.ca/bonner-lab/wpblog/
> | >
> | >
> | > [[alternative HTML version deleted]]
> | >
> | > __
> | > 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
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Dr . Jens Oehlschlägel]

Thank you for the advice Duncan,

But let's not get carried away here: we are talking about a *warning* that only 
arises if two packages are checked together that are never meant to be 
installed together.
The new packages contain weeks of improvement-work, and I am not going to add 
back-and-forth-trick-work just to circumvent some warnings that arise only at 
the point of switching from old to new.

If there is a problem when checking the new packages together that's a 
different story and worth taking care about. I didn't find such problems.

Kind regards


Jens



> Gesendet: Donnerstag, 02. Juli 2020 um 15:23 Uhr
> Von: "Duncan Murdoch" 
> An: "Dr. Jens Oehlschlägel" , 
> r-package-devel@r-project.org
> Betreff: Re: Aw: Re: Re: [R-pkg-devel] check cross-references error: Non-file 
> package-anchored link(s)
>
> On 02/07/2020 7:49 a.m., Dr. Jens Oehlschlägel wrote:
> > Duncan,
> > 
> >> One way is to make bit depend on a particular version of ff.  That may
> >> cause a deadlock if both are being updated at once, but I think CRAN
> >> should be able to deal with it if they are informed of the issue.
> > 
> > Exactly that I have done: I submitted all three packages bit/bit64/ff in 
> > version 4.0.2 and made them dependend on Version >= 4.0.0.
> > And yes, the maintainers have been informed about the issue.
> 
> I'm not sure that's what I meant, but I can't be sure, since I haven't 
> seen your source.  What I meant is a package dependency, i.e. the 
> existing ff on CRAN is version 2.2-14.2 and it depends on bit without 
> saying what version of bit is needed.  The existing bit is 1.1-15.2 with 
> no dependency on ff.
> 
> So you can force the new ff to use the new bit by giving the version 
> number, e.g.
> 
> Depends:  bit (>= 2.0)
> 
> but it's not so obvious how to make the new bit depend on the new ff.
> There's no way to say that the dependency is only to a help page, and 
> circular strong dependencies are messy, so I'd suggest you use one of 
> the other options I offered:  a dynamic link in the Rd file, or no link 
> at all.
> 
> Duncan Murdoch
>

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Dr . Jens Oehlschlägel]

Duncan,

> One way is to make bit depend on a particular version of ff.  That may
> cause a deadlock if both are being updated at once, but I think CRAN
> should be able to deal with it if they are informed of the issue.

Exactly that I have done: I submitted all three packages bit/bit64/ff in 
version 4.0.2 and made them dependend on Version >= 4.0.0.
And yes, the maintainers have been informed about the issue.

Best

Jens

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Dr . Jens Oehlschlägel]

Thanks Gabor and Duncan,

> It's actually in ff/man/clone.rd, not clone.ff.rd.  There is no 
> ff/man/clone.ff.rd file.

but there *is* clone.ff.rd in the >= 4.0.0 versions of the packages 
bit/bit64/ff.

Hence the check warning is a false alarm resulting from checking bit 4.0.2 
(GitHub.com/truecluster) against ff 2.2-14.2 (CRAN) instead of checking it 
against the also submitted ff 4.0.2 (GitHub.com/truecluster).

So all I can and will do is waiting that CRAN maintainers install and check 
again.

Best

Jens



> 
> Duncan Murdoch
> 
> > 
> > Best regards
> > 
> > Jens
> > 
> > 
> > 
> > 
> > On 16.06.20 22:31, Gábor Csárdi wrote:
> >> This is how to look up the filename. The first "sp" is the topic name,
> >> the second is the package name.
> >>
> >>> help("sp", "sp")[[1]]
> >> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
> >>
> >> So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}
> >>
> >> Gabor
> >>
> >> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford  
> >> wrote:
> >>>
> >>> Hi
> >>>
> >>> I got caught by this new test this week in trying to push an updated 
> >>> release of the loon package to CRAN.
> >>>
> >>> By following this thread, I corrected my cross-references to external 
> >>> packages but I got stymied by
> >>> the one I hoped to give to the  "sp" package for Spatial data
> >>>
> >>> _
> >>>
> >>> Here is the history:
> >>>
> >>> I tried
> >>>  \link[sp:sp]{sp}
> >>> which failed here:
> >>> Debian: 
> >>> 
> >>> Status: 1 WARNING
> >>>
> >>>
> >>> That was meant to correct an earlier attempt (it did for other links to 
> >>> "scales" for example) where I had tried
> >>> \link[sp]{sp}
> >>> and  failed here:
> >>> Debian: 
> >>> 
> >>> Status: 1 WARNING
> >>>
> >>>
> >>> So to complete the possibilities as I understand them,  I just now tried
> >>>  \link{sp}
> >>> which, as might be expected, failed here:
> >>> Debian: 
> >>> 
> >>> Status: 1 WARNING
> >>> As expected, error here was different:  "Missing  link"  as opposed to 
> >>> "Non-file package-anchored link"
> >>>
> >>> _
> >>>
> >>>
> >>> I am not sure whether I have missed a subtlety in WRE or that the 
> >>> peculiar circumstance
> >>> where the package, the topic, and the file name are all identical (sp) is 
> >>> some weird boundary case.
> >>>
> >>> Without further advice, I think I am just going to remove the link to 
> >>> "sp".
> >>> It really is just a courtesy link to the package description for "sp".
> >>>
> >>> Thanks in advance for your thoughts.
> >>>
> >>> Wayne
> >>>
> >>>
> >>>
> >>>
> >>> -Original Message-
> >>> From: R-package-devel  on behalf 
> >>> of Georgi Boshnakov 
> >>> Date: Tuesday, June 16, 2020 at 9:27 AM
> >>> To: Gábor Csárdi , Duncan Murdoch 
> >>> 
> >>> Cc: List r-package-devel 
> >>> Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
> >>> package-anchored link(s)
> >>>
> >>>   I think that the current behaviour is documented in WRE:
> >>>
> >>>   "...There are two other forms of optional argument specified as 
> >>> \link[pkg]{foo} and
> >>>   \link[pkg:bar]{foo} to link to the package pkg, to files foo.html 
> >>> and bar.html respectively.
> >>>   These are rarely needed, perhaps to refer to not-yet-installed 
> >>> packages (but there the HTML
> >>>   help system will resolve the link at run time) or in the normally 
> >>> undesirable event that more
> >>>   than one package offers help on a topic7 (in which case the present 
> >>> package has precedence so
> >>>   this is only needed to refer to other packages). They are currently 
> >>> only used in HTML help
> >>>   (and ignored for hyperlinks in LATEX conversions of help pages), 
> >>> and link to the file rather
> >>>   than the topic (since there is no way to know which topics are in 
> >>> which files in an uninstalled
> >>>   package) ...   Because they have been frequently misused, the HTML 
> >>> help system looks for topic foo in package pkg
> >>>   if it does not find file foo.html."
> >>>
> >>>   Unless I am missing something, it seems that it would be relatively 
> >>> painless to reverse the logic of the current behaviour of the help system,
> >>>   i.e. to start looking first for the topic and then for a file.
> >>>
> >>>   Georgi Boshnakov
> >>>
> >>>   -Original Message-
> >>>   From: R-package-devel  On 
> >>> Behalf Of Gábor Csárdi
> >>>   Sent: 16 June 2020 13:44
> >>>   To: Duncan Murdoch 
> >>>   Cc: List r-package-devel 
> >>>   Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
> >>> package-anchored link(s)
> >>>
> >>>   On Mon, Jun 15, 2020 at 5:30

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Dr . Jens Oehlschlägel]

Good evening,

My package bit 4.0.2 (https://github.com/truecluster/bit) is being 
rejected by CRAN checks with warning:


 >Check: Rd cross-references, Result: WARNING
 >  Non-file package-anchored link(s) in documentation object 'clone.Rd':
 >'[ff]{clone.ff}'
 >
 >  See section 'Cross-references' in the 'Writing R Extensions' manual.

although clone.ff is in clone.ff.rd as confirmed by

 > help("clone.ff","ff")[[1]]
[1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"

I asked the maintainers to explain what is wrong and what to do and got 
no answer. Does someone here can help?

Best regards

Jens




On 16.06.20 22:31, Gábor Csárdi wrote:
> This is how to look up the filename. The first "sp" is the topic name,
> the second is the package name.
> 
>> help("sp", "sp")[[1]]
> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
> 
> So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}
> 
> Gabor
> 
> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford  wrote:
>>
>> Hi
>>
>> I got caught by this new test this week in trying to push an updated release 
>> of the loon package to CRAN.
>>
>> By following this thread, I corrected my cross-references to external 
>> packages but I got stymied by
>> the one I hoped to give to the  "sp" package for Spatial data
>>
>> _
>>
>> Here is the history:
>>
>> I tried
>> \link[sp:sp]{sp}
>> which failed here:
>> Debian: 
>> 
>> Status: 1 WARNING
>>
>>
>> That was meant to correct an earlier attempt (it did for other links to 
>> "scales" for example) where I had tried
>>\link[sp]{sp}
>> and  failed here:
>> Debian: 
>> 
>> Status: 1 WARNING
>>
>>
>> So to complete the possibilities as I understand them,  I just now tried
>> \link{sp}
>> which, as might be expected, failed here:
>> Debian: 
>> 
>> Status: 1 WARNING
>> As expected, error here was different:  "Missing  link"  as opposed to 
>> "Non-file package-anchored link"
>>
>> _
>>
>>
>> I am not sure whether I have missed a subtlety in WRE or that the peculiar 
>> circumstance
>> where the package, the topic, and the file name are all identical (sp) is 
>> some weird boundary case.
>>
>> Without further advice, I think I am just going to remove the link to "sp".
>> It really is just a courtesy link to the package description for "sp".
>>
>> Thanks in advance for your thoughts.
>>
>> Wayne
>>
>>
>>
>>
>> -Original Message-
>> From: R-package-devel  on behalf of 
>> Georgi Boshnakov 
>> Date: Tuesday, June 16, 2020 at 9:27 AM
>> To: Gábor Csárdi , Duncan Murdoch 
>> 
>> Cc: List r-package-devel 
>> Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
>> package-anchored link(s)
>>
>>  I think that the current behaviour is documented in WRE:
>>
>>  "...There are two other forms of optional argument specified as 
>> \link[pkg]{foo} and
>>  \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and 
>> bar.html respectively.
>>  These are rarely needed, perhaps to refer to not-yet-installed packages 
>> (but there the HTML
>>  help system will resolve the link at run time) or in the normally 
>> undesirable event that more
>>  than one package offers help on a topic7 (in which case the present 
>> package has precedence so
>>  this is only needed to refer to other packages). They are currently 
>> only used in HTML help
>>  (and ignored for hyperlinks in LATEX conversions of help pages), and 
>> link to the file rather
>>  than the topic (since there is no way to know which topics are in which 
>> files in an uninstalled
>>  package) ...   Because they have been frequently misused, the HTML help 
>> system looks for topic foo in package pkg
>>  if it does not find file foo.html."
>>
>>  Unless I am missing something, it seems that it would be relatively 
>> painless to reverse the logic of the current behaviour of the help system,
>>  i.e. to start looking first for the topic and then for a file.
>>
>>  Georgi Boshnakov
>>
>>  -Original Message-
>>  From: R-package-devel  On Behalf 
>> Of Gábor Csárdi
>>  Sent: 16 June 2020 13:44
>>  To: Duncan Murdoch 
>>  Cc: List r-package-devel 
>>  Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
>> package-anchored link(s)
>>
>>  On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch 
>>  wrote:
>>  >
>>  > On 15/06/2020 12:05 p.m., Martin Maechler wrote:
>>  > >> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
>>  > >
>>  > >  > I agree with almost everything you wrote, except one thing:  
>> this isn't
>>  > >  > newly enforced, it has been enforced since the help 

[R-pkg-devel] cannot change value of locked binding for '*tmp*'

[Jens Oehlschlägel]

Hello R language experts,

I get an error I don't understand in an assigment function
of the form

deref(z[i]) <- v

Error in deref(z[1:5]) <- -deref(z[1:5]) :
  cannot change value of locked binding for '*tmp*'

*after* the assignment did what it should. I can workaround
using a standard function achieving the desired side-effects

refset(z[i], value=v)

Any explanation or idea how to make the standard notation working?

Context and replication code follows below.

Best

Jens


# I am trying to modernize package 'ref'
# which stems from the time of S+ and early R.
# Old package 'ref' (version 0.99) allows passing arguments by reference
# but has lost the ability to change parts of a vector
# without copying the complete vector since R version 1.8.

# I think we can restore performance if
# a new reference is not longer "an object name plus an environment"
# but is "an expression such as 'z' or 'z[i]' plus an environment"
# such that the ref-functions just become convenience wrappers to
# 'eval', 'substitute' and friends
ref <- function(expr, envir = parent.frame()){
  ret <- list(expr=substitute(expr), envir=envir)
  class(ret) <- "ref"
  ret
}

# get data at referenced expression
deref <- refget <- function(x, ...){
  # ensure that $ does the usual job once we define $.ref
  oldClass(x) <- NULL
  eval(x$expr, envir=x$envir)
}

# modify data at referenced expression
"deref<-" <- refset <- function(x, value){
  oldClass(x) <- NULL
  newexpr <- substitute(a <- b, list(a=x$expr, b=value))
  eval(newexpr, envir=x$envir)
  newexpr
}

# subscript referenced expression (without evaluating it)
"[.ref" <- function(x, ...){
  cl <- oldClass(x)
  oldClass(x) <- NULL
  newexpr <- sys.call()
  newexpr[[1]] <- call("[")[[1]]
  newexpr[[2]] <- x$expr
  x$expr <- newexpr
  oldClass(x) <- cl
  x
}

# some example data
n <- 1e1
x <- 1:n
# create a reference to it
z <- ref(x)

# using refget(z[i]) and refset(z[i], v)
# efficiently assignes to a referenced subset as desired
v <- refget(z[1:5])
refset(z[1:5], -v)
# so my code works
x[1:10]

# but doing it R-style
# with deref(z[i]) and deref(z[i]) <- v
# gives this error:
# Error in deref(z[1:5]) <- -deref(z[1:5]) :
#   cannot change value of locked binding for '*tmp*'
v <- deref(z[1:5])
deref(z[1:5]) <- -v
# anyhow the referenced vector has been changed !?
x[1:10]

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

[R-pkg-devel] Future location of Rtools?

[Jens Oehlschlägel]

Good morning, 

Duncan has announced that he steps back from the maintenance of Rtools. 
Where will I find the new Rtools toolchain that complements Microsofts 
R-version?

Kind regards

Jens


> Gesendet: Donnerstag, 28. September 2017 um 12:27 Uhr
> Von: "Duncan Murdoch" 
> An: r-annou...@r-project.org
> Betreff: Re: [R] R 3.4.2 is released
>
> I've just finished the Windows build of R 3.4.2.  It will make it to 
> CRAN and its mirrors over the next few hours.
> 
> This is the last binary release that I will be producing.  I've been 
> building them for about 15 years, and it's time to retire.  Builds using 
> different tools and scripts are available from 
> https://mran.microsoft.com/download/.  I'll be putting my own scripts on 
> CRAN soon in case anyone wants to duplicate them.
> 
> Nightly builds of R-patched and R-devel will continue to run on 
> autopilot for the time being, without maintenance.
> 
> I will also be retiring from maintenance of the Rtools collection.
> 
> Duncan Murdoch
> 
> ___
> r-annou...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-announce
>

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

Re: [R-pkg-devel] tibbles are not data frames

[Jens Oehlschlägel]

On 27.09.2017 01:00, Duncan Murdoch wrote:
I think R Core would not be interested in a vote, because you'd be 
voting to give them work to do, and that's really rude.


Voting about other people's work is indeed a problem. This is were I 
hope money from the R Consortium could help, assuming they are serious 
about contributing to the community (and serious about protecting their 
investments into interfacing R).


What would have a better chance of success would be for someone to 
write a short article describing the proposal in detail, and listing 
all changes to CRAN and Bioconductor packages that would be necessary 
to implement it.  That's a lot of work!  Do you have time to do it?


Specifying all the consequences of such a change in detail is a similar 
amount of work than actually doing it. Are you suggesting that I do the 
work alone? And predicting from past experience the chances that R-core 
would accept my suggestion: guess what I would do?


Such improvements of the language should be suggested by everyone who 
sees need, filtered through a voting process open to every user (flagged 
for package authors to get an early picture of their votes), the 
promising changes planned in detail by R Core (given a budget for 
implementation from the R-consortium), confirmed by a voting process of 
all package authors and then put on a sufficient long-term roadmap. So 
if R Consortium and R Core commit to such a process and you ask me if I 
am willing to compile a first list of suggestions for change: I don't 
have time but I would collect and consolidate input from this list. Any 
volunteers for organizing a voting system assuming the above commitments?


Best


Jens

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

Re: [R-pkg-devel] tibbles are not data frames

[Jens Oehlschlägel]

On 26.09.2017 23:08, Hadley Wickham wrote:
I'm not sure that democracy works for programming language design. 


Agree. The obstacle I hope to overcome by voting is not missing 
agreement on the fact of inconsistent design, the obstacle is the 
question whether a majority of contributers is willing to invest work to 
get rid of the inconsistency. Where 'majority' could be defined in terms 
of weighted voting using LOC of the respective author as a proxy for the 
work he would expect to do.


Jens

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

Re: [R-pkg-devel] tibbles are not data frames

[Jens Oehlschlägel]

On 26.09.2017 15:37, Hadley Wickham wrote:

I decided to make [.tibble type-stable (i.e. always return a data
frame) because this behaviour causes substantial problems in real data
analysis code. I did it understanding that it would cause some package
developers frustration, but I think it's better for a handful of
package maintainers to be frustrated than hundreds of users creating
dangerous code.g

Hadley



If that is right -- and I tend to believe it is right -- this change had 
better been done in R core and not on package level. I think the root of 
this evil is design inconsistencies of the language together with the 
lack of removing these inconsistencies. The longer we hesitated, the 
more packages such a change could break. The lack of addressing issues 
in R core drives people to try to solve issues on package level. But now 
we have two conflicting standards, i.e. a fork-within-the-language: Am I 
a member of the tidyverse or not? Am I writing a package for the 
tidyverse or for standard-R or for both. With a fork-of-the-language we 
would at least have a majority vote for one of the two and only the 
fitter would survive. But with a fork-within-the-language 'R' gets more 
and more complex, and working with it more and more difficult. There is 
not only the tidyverse, also the Rcppverse and I don't know how many 
other verses. If there is no extinction of inconsistencies in R, not 
sufficient evolution in R, but lots of evolution in Julia, evolution 
will extinct R together with all its foobarverses in favor of Julia (or 
Python). May be that's a good thing.


I think tibble should respect drop=TRUE and respect the work of all 
package authors who wrote defensive code and explicitly passed drop= 
instead of relying on the (wrong) default. Again: better would be a 
long-term clean-up roadmap of R itself and one simple standard called 
'data.frame'. Instead of forking or betting on any particular 
foobarverse: why not have direct democratic votes about certain critical 
features of such a long-term roadmap in such a big community?


Kind regards


Jens Oehlschlägel

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

[R-pkg-devel] Can roxygen2 export export() and S3method() to namespace?

[Jens Oehlschlägel]

Hi,

is there a way to have roxygen2 write both export(,)
and S3method(,) to the NAMESPACE file?

I tried

#' @rdname Summaries
#' @export
all.bit <- function(x, range=NULL, ...)

and only get

S3method(all,bit)

but not

export(all.bit)

Thanks for any help


Jens Oehlschlägel


P.S.


roxygen2 version 6.0.1


> version
   _
platform   x86_64-pc-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  3
minor  4.1
year   2017
month  06
day    30
svn rev    72865
language   R
version.string R version 3.4.1 (2017-06-30)
nickname   Single Candle

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

[R-pkg-devel] Fwd: CRAN packages maintained by you

[Jens Oehlschlägel]

Hi, I was asked by CRAN-maintainers to provide two versions of 
median.integer64, one with and one without a dots-argument.

However, doing so results in a code-documentation mismatch, because I have

\method{median}{integer64}(x, na.rm = FALSE)

and now also need

\method{median}{integer64}(x, na.rm = FALSE, \dots)

but selecting between both using \Sexpr{} seems not to be allowed in a 
Rd-usage-section.

Anyone knows the proper way to do this?


Jens Oehlschl�gel



 Forwarded Message 
Subject:CRAN packages maintained by you
Date:   Thu, 23 Mar 2017 18:08:18 +0100
From:   Kurt Hornik 
Reply-To:   c...@r-project.org
To: achim.zeil...@r-project.org, an...@signorell.net, clau...@unive.it, 
edzer.pebe...@uni-muenster.de, j.cur...@auckland.ac.nz, 
jens.oehlschlae...@truecluster.com, jo...@kerman.com, mx.he...@gmail.com
CC: c...@r-project.org



Dear maintainers,

This concerns the CRAN packages

   Bolstad DescTools RVAideMemoire bit64 circular rv units zoo

maintained by one of you:

   Achim Zeileis : zoo
   Andri Signorell : DescTools
   Claudio Agostinelli : circular
   Edzer Pebesma : units
   James Curran : Bolstad
   Jens Oehlschl�gel : bit64
   Jouni Kerman : rv
   Maxime Herv� : RVAideMemoire

You may already have noticed that under r-devel these have given
warnings like

* checking S3 generic/method consistency ... WARNING
median:
   function(x, na.rm, ...)
median.Bolstad:
   function(x, na.rm)

for some time now, following

  \item \code{median()} gains a formal \code{\dots} argument, so
   methods with extra arguments can be provided.

Could you please update your package code to eliminate these warnings,
ideally as quickly as possible?

In one package co-developed by me, I went for

if(is.na(match("...", names(formals(median) {
 median.tuple <- function(x, na.rm = FALSE) {
 x <- as.numeric(x)
 NextMethod()
 }
} else {
 median.tuple <- function(x, na.rm = FALSE, ...) {
 x <- as.numeric(x)
 NextMethod()
 }
}

which may be the "simplest" way forward ...

Best
-k


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Is a double dispatch possible with two S3 classes?

[Jens Oehlschlägel]

Leonardo,

I had a similar problem when I tried to implement reasonable behaviour for 
logical operators for classes .bit and .bitwhich in package 'bit'.

Part of your problem is that R refuses to dispatch to any of two incompatible 
classes and instead falls back to a meaningless default. 

In theory, *this* problem *should* be solved in S3 by having a common 
super-class 'foobar' for class(foo) <- c('foo','foobar') and  class(bar) <- 
c('bar','foobar'), but again, R does refuses to dispatch on the common 
super-class (it directly tries to dispatch on the most special subclasses it 
finds and does not check for a common class in the class hierarchy). 

However, it appears that by having a common sub-class 'foobar' for class(foo) 
<- c('foobar','foo') and  class(bar) <- c('foobar','bar') we can get a common 
dispatch and hence get control. I plan for my next release of package 'bit' a 
common subclass 'booltype' to which R can dispatch without conflict. If you can 
convince the author of 'foo' to use class(foo) <- c('foobar','foo') and base 
his dispatch on 'foo', then you can dispatch on 'foobar' with no conflict and 
use NextMethod to invoke his code for the foo-foo case, and your code for the 
other cases. If the author refuses for some reason, you can still provide a 
wrapper to convert class 'foo' into class c('foobar','foo'), or do more nasty 
things like patching his class generator, but at least you don't need to patch 
his methods! 

I admit, using a physical subclass as a logical superclass is ugly: instead of 
declaring 'apples' and 'oranges' as special cases of 'fruits', we tell R that 
'a fruit is an apple' and that 'a fruit is an orange', such that R dispatches 
to fruit-code for any combination of apples and oranges. Well ... the good 
thing is that NextMethod can invoke the original apple-code or orange-code, and 
we only need to write apple-orange-code and orange-apple-code to handle the new 
combinations. 

@R-devel: any comments or suggestions?

HTH


Jens Oehlschlägel


P.S. Example code and output follows


# If we try to have 'foo' and 'bar' as specializations of of a superclass 
'foobar'

f <- "fooobj"
oldClass(f) <- c('foo','foobar')
"+.foo" <- function(e1,e2){
  paste(e1,'+foo+',e2)
}

b <- "barobj"
oldClass(b) <- c('bar','foobar')
"+.bar" <- function(e1,e2){
  paste(e1,'+bar+',e2)
}

"+.foobar" <- function(e1,e2){
  if (inherits(e1,"foo") && inherits(e2,"bar"))
paste(e1,'+foobar+',e2)
  else if (inherits(e1,"bar") && inherits(e2,"foo"))
paste(e1,'+barfoo+',e2)
  else stop("should not be invoked for foo+foo or bar+bar (but it does)")
}

# Yes, this works
f + f
b + b
# but here R does not even dispatch on the common superclass 'foobar'
f + b
b + f


# However, it seems that we can trick R to do the right thing pretending that 
'foobar' is a subclass of both, 'foo' and 'bar'

oldClass(f) <- c('foobar','foo')
"+.foo" <- function(e1,e2){
  paste(e1,'+foo+',e2)
}

b <- "barobj"
oldClass(b) <- c('foobar','bar')
"+.bar" <- function(e1,e2){
  paste(e1,'+bar+',e2)
}

"+.foobar" <- function(e1,e2){
  if (inherits(e1,"foo") && inherits(e2,"bar"))
paste(e1,'+foobar+',e2)
  else if (inherits(e1,"bar") && inherits(e2,"foo"))
paste(e1,'+barfoo+',e2)
  else NextMethod(e1,e2)  # make sure we dispatch to foo+foo and bar+bar
}

# This works
f + f
b + b
# but R does not even dispatch on the common ground 'foobar'
f + b
b + f



> # If we try to have 'foo' and 'bar' as specializations of of a superclass 
> 'foobar'
> 
> f <- "fooobj"
> oldClass(f) <- c('foo','foobar')
> "+.foo" <- function(e1,e2){
+   paste(e1,'+foo+',e2)
+ }
> 
> b <- "barobj"
> oldClass(b) <- c('bar','foobar')
> "+.bar" <- function(e1,e2){
+   paste(e1,'+bar+',e2)
+ }
> 
> "+.foobar" <- function(e1,e2){
+   if (inherits(e1,"foo") && inherits(e2,"bar"))
+ paste(e1,'+foobar+',e2)
+   else if (inherits(e1,"bar") && inherits(e2,"foo"))
+ paste(e1,'+barfoo+',e2)
+   else stop("should