Re: [Rd] tools::package_native_routine_registration_skeleton?

Thanks Georgi and Duncan, exports are now specified explicitly and the new package is now on CRAN. Roger Koenker r.koen...@ucl.ac.uk Department of Economics, UCL London WC1H 0AX. On Jun 28, 2019, at 1:11 PM, Duncan Murdoch mailto:murdoch.dun...@gmail.com>> wrote:

Re: [Rd] R-Forge > GitHub?

Apparently your username/password are wrong. Can you clone/push from other repos? You do not need authorization when cloning a public repo, so even incorrect credentials may work (haven't tested this though). But for push you have to have that in order. I suggest you create ssh keys, upload tho

Re: [Rd] R-Forge > GitHub?

Thanks to Duncan, Henrik and Henrik, Brian, and Gábor:   I created a local copy of the new GitHub version using the following: git clone https://sbgraves237:mypassw...@github.com/sbgraves237/Ecdat.git   That worked in the sense that I got a local copy.  However, after I rolled the

Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error

> On 28 Jun 2019, at 16:03 , Martin Maechler wrote: > >> Henrik Bengtsson >>on Thu, 27 Jun 2019 16:00:39 -0700 writes: > >> Using: >> >> untrace(methods::conformMethod) >> at <- c(12,4,3,2) >> str(body(methods::conformMethod)[[at]]) >> ## language omittedSig <- omittedSig && (si

Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error

> Henrik Bengtsson > on Thu, 27 Jun 2019 16:00:39 -0700 writes: > Using: > > untrace(methods::conformMethod) > at <- c(12,4,3,2) > str(body(methods::conformMethod)[[at]]) > ## language omittedSig <- omittedSig && (signature[omittedSig] != "missing") > cc <- 0L > trace(methods::confor

Re: [Rd] R-Forge > GitHub?

Whereas it is true that one has to contact GitHub to detach a GitHub repository, it really is no problem (or at least was no problem in 2016). I wanted to do so when I took over the maintainer role of LaplacesDemon which only remained on GitHub as a fork on some other person's private account. So I

Re: [Rd] R-Forge > GitHub?

Re your point 3: Because you have managed to create a GitHub version of your repository that is not a fork of https://github.com/rforge/ecdat, but its own independent repository, contacting GitHub support might not be the right way forward. Note that https://github.com/rforge is simply a read-only

Re: [Rd] R-Forge > GitHub?

On 28/06/2019 6:26 a.m., Gábor Csárdi wrote: Instead, you can do as Duncan suggested, and put a README in your R-Forge repository, that points to *your* GitHub repositor(y/ies). Then the https://github.com/rforge/ecdat read only mirror will pick this up and will point there as well. Just for t

Re: [Rd] tools::package_native_routine_registration_skeleton?

On 28/06/2019 6:27 a.m., Koenker, Roger W wrote: Thanks, I was just coming to that conclusion and beginning to look for a way to make a list of exportable objects. After library(quantreg), ls("package:quantreg") will list all the names you currently export. So cat(ls("package:quantreg"),

Re: [Rd] R-Forge > GitHub?

Spencer, on your point 3. below, we took a different path in migrating several packages. After we migrated to github as the new master copy, we made new commits to the now orphaned R-Forge copies to include a new .onAttach function as so: .onAttach <- function(libname, pkgname) { repo <- "h

Re: [Rd] R-Forge > GitHub?

On Fri, Jun 28, 2019 at 6:01 AM Spencer Graves wrote: [...] > 1. Clone a copy of "https://github.com/sbgraves237/Ecdat"; > to my local computer and confirm that it works. > I suggest you put each package in its own repository, because our R tooling (e.g. Travis CI, etc.) works best

Re: [Rd] tools::package_native_routine_registration_skeleton?

Thanks, I was just coming to that conclusion and beginning to look for a way to make a list of exportable objects. Roger Koenker r.koen...@ucl.ac.uk Department of Economics, UCL London WC1H 0AX. On Jun 28, 2019, at 11:23 AM, Georgi Boshnakov mailto:georgi.boshna..

Re: [Rd] tools::package_native_routine_registration_skeleton?

> ... reports that the fortran names of all the registered fortran functions > are “undocumented objects”... Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 'exportPattern(".")'. Maybe it is a good time to remove that and export explicitly the symbols that are meant for

Re: [Rd] R-Forge > GitHub?

Henrik's advice is all good. I would say his idea of the final commit of a README pointer is better than deleting things at R-forge; there is likely old information out there somewhere pointing to R-forge as a location for Ecdat development, and any bug reports or discussion on R-forge will no

[Rd] tools::package_native_routine_registration_skeleton?

I’m trying to sort out the consequences of adding registration for my quantreg package. I’ve generated a quantreg_init.c file with the directive in the message title, and placed it in my src directory. The first issue is that 3 of the 20, or so registered functions have the same name in fortran