Re: [Rd] Why R should never move to git

For what it's worth, this is my workflow: 1. Get a fork. 2. From the master branch, create a new branch called fix-[something]. 3. Put together the stuff there, commit, push and open a PR. 4. Checkout master and repeat from 2 to submit another patch. Sometimes, I forget the step of creating the

Re: [Bioc-devel] not all bioc packages visible on github?

Paul, My understanding was that the Bioconductor github repos were going to die, and it was up to the maintainer where the source was, and a public source need not be available. I asked about this previously, and there was too much confusion between the official Bioconductor repos and developers

[Bioc-devel] not all bioc packages visible on github?

By example: https://github.com/Bioconductor/KEGGREST-> github project homepage displays https://github.com/Bioconductor/BrowserViz -> 404 Yet this works fine: git clone g...@git.bioconductor.org:packages/BrowserViz.git Is visibility at github.com/Bioconductor therefore conditional?

Re: [Rd] Why R should never move to git

On Thu, Jan 25, 2018 at 12:43 AM, Duncan Murdoch wrote: [...] > But that's only half the battle. If I did that and emailed the diff to a > maintainer, I'm guessing I'd be told I should put together a PR instead. > And as I found out, that's not easy, if I already have a

Re: [Rd] Why R should never move to git

On 24/01/2018 7:29 PM, Gábor Csárdi wrote: On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch wrote: [...] Thanks, those instructions appear to have worked. For comparison purposes, the equivalent steps in svn would be svn diff -r PREV:HEAD --internal-diff > patchfile

Re: [Rd] Why R should never move to git

On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch wrote: [...] > Thanks, those instructions appear to have worked. > > For comparison purposes, the equivalent steps in svn would be > > svn diff -r PREV:HEAD --internal-diff > patchfile > > and then the patchfile could be

Re: [Rd] Why R should never move to git

On 24/01/2018 7:04 PM, Gábor Csárdi wrote: You need to create a branch from the original master, if you do git log master then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366 So create that branch off that and switch to the new branch: git branch keepclassx

Re: [Rd] Why R should never move to git

You need to create a branch from the original master, if you do git log master then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366 So create that branch off that and switch to the new branch: git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366 git checkout

Re: [Rd] Why R should never move to git

On 24/01/2018 6:35 PM, Gábor Csárdi wrote: When you create a branch for your bug fix, don't create it off the previous fix. Create it off the original, forked state of the repo. Branches keepclass2 through to keepclass5 are my attempts to do that. As far as I can see they are all the same as

Re: [Rd] Why R should never move to git

I think the problem you're experiencing is not uncommon but has a solution. FWIW, I prefer git, but I think the best version control system for R is whatever R-core prefers. If they were 2% more productive working in an MS Word documents with Track Changes than git, so much worse for git. On 25

Re: [Rd] Why R should never move to git

When you create a branch for your bug fix, don't create it off the previous fix. Create it off the original, forked state of the repo. Are the two commits here your fixes? https://github.com/dmurdoch/manipulateWidget/commits/master Gabor On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch

[Rd] Why R should never move to git

Lately I've been doing some work with the manipulateWidget package, which lives on Github at https://github.com/rte-antares-rpackage/manipulateWidget/. Last week I found a bug, so being a good community member, I put together a patch. Since the package lives on Github, I followed

Re: [Bioc-devel] Duplicate Commits in ASSIGN Package

Hi David, I can take a look at your package later today on your Github and update the version on Bioconductor if everything looks good. The reason you are not able to push is because we prevent “force” pushes on the bioconductor git server from maintainers. Give me sometime and I’ll get back

[Bioc-devel] NanoStringDiff package update

I’m one of the maintainers of NanoStringDiff package on Bioconductor. Now I want to update this package and add some useful functions. I’m using SVN, but when committing, it gives me this error: The new canonical location for Bioconductor software and data experiment packages is

Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest

Hey, I am not a laywer but their terms are quite explicitly prohibiting redistribution of their data without written consent. Now you might build a package that does not collect, store and redistributes the data but only allows to access the data provided there 'live' via some convenience

[Rd] R-3.4.3 frequently segfaults on HP-UX 11.31

I've built R-3.4.3 on HP-UX 11.31 with GCC-4.9.2.  However, it segfaults frequently, and I can't clearly understand why. Some things work, like > 1+2 [1] 3 > sum(c(1,2)) [1] 3 > var(c(1,2,3)) [1] 1 Some don't: > pgamma(1,Inf,Inf) *** caught segfault *** address d065, cause 'invalid

[Bioc-devel] Duplicate Commits in ASSIGN Package

Hi All, I’m the maintainer of the ASSIGN package. It’s currently failing the devel build and when I tried to push a fix for that I noticed that we have a lot of duplicate commits in the history from a while back, I think from the git-svn bridge. I rebased and removed all of the duplicate

[Rd] fix potential integer overflow in mantelhaen.test ?

Someone who was running into an integer overflow warning (and downstream error) with mantelhaen.test() on a large data set asked about it on StackOverflow: https://stackoverflow.com/questions/48422398/na-nan-inf-in-foreign-function-error-with-mantelhaen-test/48428596#48428596 Coercing ntot

Re: [Bioc-devel] Permission denied when fetching from BioC GitHub repository

Hi Nitesh, thanks a lot for your message. It makes perfect sense. Best wishes, Federico > On 24 Jan 2018, at 17:33, Turaga, Nitesh > wrote: > > Hi > > Only packages maintained by Bioconductor are at that location > gitHub.com/Bioconductor. Your package is

Re: [Bioc-devel] Permission denied when fetching from BioC GitHub repository

Hi Valerie, the ssh key has now been setup and it works. I had some issues with merging but at the end I decided to force BioC master to GitHub master (following https://bioconductor.org/developers/how-to/git/abandon-changes/#force-bioconductor--to-github-

Re: [R-pkg-devel] Working with R-devel

On 24 January 2018 at 07:55, William Dunlap wrote: | On Linux you can trace all the getenv calls with ltrace. It only | works on ELF files, not sh scripts: | | % R CMD ltrace -e getenv `R RHOME`/bin/*/R | libR.so->getenv("R_HOME") |= "/home/R/R-3.4.3/lib64/R" |

Re: [R-pkg-devel] Working with R-devel

On Linux you can trace all the getenv calls with ltrace. It only works on ELF files, not sh scripts: % R CMD ltrace -e getenv `R RHOME`/bin/*/R libR.so->getenv("R_HOME") = "/home/R/R-3.4.3/lib64/R" libR.so->getenv("R_TRANSLATIONS") = nil

Re: [R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?

The advice at the link you cite ([1] https://stackoverflow.com/a/8638902/1664978) is not quite right: > I believe it is a requirement that if package A imports package B, and > package B lists package C in Depends: then package A must also list > package C in Depends: > A popular stackoverflow

Re: [R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?

This is implicitly OK: If A suggests B and B depends on some R version, then B is only available if you are running that R version anyway, hence the additional declaration is not needed. The typical cause of trouble is as follows: A depends on B and B suggests C. Then A has to suggest C in

Re: [R-pkg-devel] Working with R-devel

On 24 January 2018 at 07:03, luke-tier...@uiowa.edu wrote: | If you are picking up an R 3.4.x that is trying to load a package | built by R-devel you should also see a warning that the package was | built under R version 3.5.0 Yes, I am of course very aware of the issue. But we had to separate

[R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?

I believe it is a requirement that if package A imports package B, and package B lists package C in Depends: then package A must also list package C in Depends: A popular stackoverflow answer states this.[1] I can't find any other source but it makes sense. What if package B is suggested by

Re: [R-pkg-devel] Working with R-devel

On Wed, 24 Jan 2018, Uwe Ligges wrote: On 24.01.2018 12:00, Martin Maechler wrote: Uwe Ligges on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my

Re: [R-pkg-devel] FIXED -- Working with R-devel

Thanks to Martin, my 'RD' script now points to ~/.R/check.Renviron-Rdevel in which I also set (or re-set) R_LIBS="/usr/local/lib/R-devel/site-library/" after having added this (for good measure) to my 'RD' script: unset R_PROFILE R_RENVIRON R_LIBS export

Re: [R-pkg-devel] Working with R-devel

On 24 January 2018 at 12:00, Martin Maechler wrote: | > Uwe Ligges | > I guess you actually pick up anotehr version of R. | > Carefully check what is on your PATH and perhaps some Renviron files | > that may be around? I did, a million times,

Re: [R-pkg-devel] Working with R-devel

On 24.01.2018 12:00, Martin Maechler wrote: Uwe Ligges on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my way. I used to have means to >> build

Re: [R-pkg-devel] Working with R-devel

> Uwe Ligges > on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my way. I used to have means to >> build R-devel (still do) and use it for local

Re: [R-pkg-devel] Working with R-devel

On 24.01.2018 03:20, Dirk Eddelbuettel wrote: I am going in circles here and have lost my way. I used to have means to build R-devel (still do) and use it for local testing (no longer do). - Fresh build of R-devel - One entry in .libPaths() - I can install Rcpp, it ends up in that