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

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

Re: [R-pkg-devel] implications of staged install for data processing packages

brilliant! thanks a lot, and yes, will come back with more in case I'm stuck. F On Fri, 28 Jun 2019 at 17:44, Tomas Kalibera wrote: > On 6/28/19 5:16 PM, Florian Oswald wrote: > > oh ok i see: so i will always be able to do > > > > clean(path = "~/data.csv") > > > > for example? in that case I

Re: [R-pkg-devel] implications of staged install for data processing packages

On 6/28/19 5:16 PM, Florian Oswald wrote: oh ok i see: so i will always be able to do clean(path = "~/data.csv") for example? in that case I completely misunderstood this and there must indeed be some system.file call buried somewhere. will check. thanks! In case it is hard to find manually,

Re: [R-pkg-devel] implications of staged install for data processing packages

oh ok i see: so i will always be able to do clean(path = "~/data.csv") for example? in that case I completely misunderstood this and there must indeed be some system.file call buried somewhere. will check. thanks! Florian On Fri, 28 Jun 2019 at 17:11, Georgi Boshnakov <

Re: [R-pkg-devel] implications of staged install for data processing packages

You need to give details what exactly gets you into trouble and about your use case, since any advice would be conditional on making assumptions about that. It is usually a bad a idea to have a function working on a hardcoded full filename. You will thank yourself later if you at least make it

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 &&

[R-pkg-devel] implications of staged install for data processing packages

Hi all I ran into trouble with the changes starting to come in with R3.6 stemming from the new staged installation, which checks and errors on hard coded paths in R code. I understand there is an opt out, but still want to know. here's the blog post:

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 >

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

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

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

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

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

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

[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