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 to
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 permissi
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 instructions
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
wrote:
>
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 J
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 k
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 kee
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 f735449d6796
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 sent to the maintainer.
If
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
and then the patchfile co
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 fork of the
> repository t
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 n
12 matches
Mail list logo