Get bigmemory to build for Travis-CI

[kaneplusplus]

We need to fix some documentation: https://travis-ci.org/kaneplusplus/bigmemory

[cdeterman]

The primary problem appears to be in the big.matrix.Rd file with the example

x <- big.matrix(10, 2, type='integer', init = -5)

Strangely this returns the error

Error: memory could not be allocated for instance of type big.matrix

where somehow CreateSharedMatrix is returning a null address. This is very odd as it works without a problem when run in the R console even when multiple big.matrix objects are created consecutively. The only way I have been able to reproduce the error is by rerunning R CMD CHECK or R --vanilla < bigmemory-Ex.R where bigmemory-Ex.R was previously produced by R CMD CHECK.

[kaneplusplus]

I have a hunch it's the check environment. A quick and dirty fix would be to put the examples in \dontrun. But we should see if we can figure this one out.

[cdeterman]

Another, although somewhat unsatisfactory, solution is to prepend each big.matrix definition in the examples with gc() beforehand. I have verified that this does remove the error but it is still a little unnerving that this memory error is popping up at all. Not quite sure how the memory is handled within the check environment that it doesn't error outside of it.

[cdeterman]

Did you have any other thoughts regarding the check environment? I petitioned the R community about the matter and the only thing that seems to work is adding the gc(). I couldn't find any issues with the system environment. If this solution is satisfactory to you I will create a push my local changes and set up a pull request so the package will at least build successfully on Travis and we can explore other more pertinent fixes and enhancements.

[phaverty]

I don't have any good ideas. Michael Lawrence (new R core member) is down
the hall. I'll see if he has any thoughts.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Wed, May 20, 2015 at 9:30 AM, Charles Determan notifications@github.com
wrote:

Did you have any other thoughts regarding the check environment? I
petitioned the R community about the matter and the only thing that seems
to work is adding the gc(). I couldn't find any issues with the system
environment. If this solution is satisfactory to you I will create a push
my local changes and set up a pull request so the package will at least
build successfully on Travis and we can explore other more pertinent fixes
and enhancements.

Reply to this email directly or view it on GitHub
#16 (comment)
.

[kaneplusplus]

Thanks Pete. I don't mind switching to \dontrun in the short term. However, we'll have to test to see if the check environment problem is inherited by packages importing bigmemory.

[phaverty]

Michael Lawrence suggested using valgrind to look for memory allocation
trouble. I still don't get what is special about the environment when
stuff is run under CHECK. bigmemoryExtras makes filebacked bigmatrices in
examples (indirectly) and passes fine (with bigmemory 4.4.6). I'll
experiment some.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Wed, May 20, 2015 at 11:05 AM, Michael Kane notifications@github.com
wrote:

Thanks Pete. I don't mind switching to \dontrun in the short term.
However, we'll have to test to see if the check environment problem is
inherited by packages importing bigmemory.

Reply to this email directly or view it on GitHub
#16 (comment)
.

[phaverty]

I added
x <- big.matrix(10, 2, type='integer', init = -5)
to an example in bigmemoryExtras. It checked fine with bigmemory 4.4.6.
I'll repeat with the current GitHub version. It would probably be useful to
dissect this down to .Call and then the bit of RCpp / C++ that does the
allocation. If it is a RCpp thing, likely someone else has hit the same
issue and StackOverflow will have the answer.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Thu, May 21, 2015 at 9:40 AM, Peter Haverty phaverty@gene.com wrote:

Michael Lawrence suggested using valgrind to look for memory allocation
trouble. I still don't get what is special about the environment when
stuff is run under CHECK. bigmemoryExtras makes filebacked bigmatrices in
examples (indirectly) and passes fine (with bigmemory 4.4.6). I'll
experiment some.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Wed, May 20, 2015 at 11:05 AM, Michael Kane notifications@github.com
wrote:

Thanks Pete. I don't mind switching to \dontrun in the short term.
However, we'll have to test to see if the check environment problem is
inherited by packages importing bigmemory.

Reply to this email directly or view it on GitHub
#16 (comment)
.

[phaverty]

bigmemoryExtras checks fine with
x <- big.matrix(10, 2, type='integer', init = -5)
as an example, for what that's worth.

bigmemory 4.5.1 gives me the same error, so the trouble is isolated to just
examples in bigmemory itself.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Thu, May 21, 2015 at 9:53 AM, Peter Haverty phaverty@gene.com wrote:

I added
x <- big.matrix(10, 2, type='integer', init = -5)
to an example in bigmemoryExtras. It checked fine with bigmemory 4.4.6.
I'll repeat with the current GitHub version. It would probably be useful to
dissect this down to .Call and then the bit of RCpp / C++ that does the
allocation. If it is a RCpp thing, likely someone else has hit the same
issue and StackOverflow will have the answer.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Thu, May 21, 2015 at 9:40 AM, Peter Haverty phaverty@gene.com wrote:

Michael Lawrence suggested using valgrind to look for memory allocation
trouble. I still don't get what is special about the environment when
stuff is run under CHECK. bigmemoryExtras makes filebacked bigmatrices in
examples (indirectly) and passes fine (with bigmemory 4.4.6). I'll
experiment some.

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Wed, May 20, 2015 at 11:05 AM, Michael Kane notifications@github.com
wrote:

Thanks Pete. I don't mind switching to \dontrun in the short term.
However, we'll have to test to see if the check environment problem is
inherited by packages importing bigmemory.

Reply to this email directly or view it on GitHub
#16 (comment)
.

[cdeterman]

@phaverty from my experiments I believe this error only comes up if a big.matrix object is created in multiple example files. For example, in the bigmemory examples if I have gc() present at the start of each example file, there is no problem. However, if I remove the gc() from the top of the write.big.matrix_examples.R file I receive the same error but with the

x <- as.big.matrix(matrix(1:10, 5, 2))

error instead. Can you confirm that bigmemoryExtras doesn't give the error if you create a big.matrix in two distinct examples?

[phaverty]

Confirmed. bigmemory passes check with two separate examples creating big.matrices using bigmemory 4.5.1.

[cdeterman]

Thanks Pete, hmm... this is really strange. Will need to dig some more in to why it is having issues only within bigmemory. At least this confirms that it is contained.

[kaneplusplus]

Hi all. Sorry about the radio silence. I broke my hip last Friday and got out of surgery on Monday. I'll try to get back to this in the next day or so.

[phaverty]

Whoa, that's quite an injury! I'm glad you are past the surgery and I hope
you heal up fast. Take your time with the code, of course.

Best wishes,

Pete

---

Peter M. Haverty, Ph.D.
Genentech, Inc.
phaverty@gene.com

On Thu, May 28, 2015 at 1:00 PM, Michael Kane notifications@github.com
wrote:

Hi all. Sorry about the radio silence. I broke my hip last Friday and got
out of surgery on Monday. I'll try to get back to this in the next day or
so.

Reply to this email directly or view it on GitHub
#16 (comment)
.

[cdeterman]

Sorry to hear about that. Glad you are on the mend. As Pete said, no rush here, just focus on healing up first.