Test running SINGE inside Octave Docker container

[agitter]

This is an attempt to run SCINGE on Travis CI inside an Octave Docker container (#4). It initially uses https://hub.docker.com/r/openmicroscopy/octave and examples from https://github.com/openmicroscopy/octave-docker.

[agitter]

https://serverfault.com/questions/594281/how-can-i-override-cmd-when-running-a-docker-image had useful information on the order of docker run commands when changing the entrypoint.

[agitter]

There is still work to do, but this testing direction seems promising. There will be some compatibility issues. One example is:

error: 'verLessThan' undefined near line 95 column 4
error: called from
    GLG_Instance>isfilecomp at line 95 column 1

We can work around those if we want. The biggest issue is that the Octave errors are not propagating to Docker. Octave can stop running the code when it encounters an error but still return an exit code of 0 to Docker so the Travis CI build passes. The problem is likely with Octave because if I force bash to exit with code 1, Docker recognizes that (c880cb6).

[agitter]

This is possibly related to https://savannah.gnu.org/patch/?9633

[agitter]

The Docker container has Octave 4.2.2 and the post linked above claims the exit status was broken in that version.

[agitter]

This container builds the current development version of Octave and could be useful https://hub.docker.com/r/mtmiller/octave-snapshot I tried it in 03dc7ae and now the build correctly fails if Octave encounters an error, which is a huge improvement.

If we want to use this as a base, we may need to use it as a starting point for our own container. It seems like this project is only intended to provide the current snapshot, and we don't want the underlying version of Octave to keep changing as we work to maintain our code.

[agitter]

The current Docker container has gfortran so it should be possible to compile new mex files for Octave inside the container. I am using this mex reference even though our version of Octave is much newer.

The Glmnex Linux 64 instructions don't provide the command line mex call so I am initially adapting it from the Windows 32 instructions. We'll need to debug the call.

The initial plan is to run ./install_glmnet_docker.sh inside the Docker container to download and compile Glmnet. If this works, we could pre-configure it inside our own Docker container.

[agitter]

0c9d42c had the error

glmnetMex.F:1:0: fatal error: fintrf.h: No such file or directory
 #include "fintrf.h"
 ^
compilation terminated.

which was resolved by downloading the header from https://github.com/SheffieldML/GPmat/blob/master/kern/mex/fintrf.h

There are still many warnings like

glmnetMex.F:132.33:
         call getinteger(temp_pr,task,1)                                
                                 1
Warning: Rank mismatch in argument 'x' at (1) (rank-1 and scalar)

These do not appear to be fatal because glmnetMex.mex is written.

[agitter]

@atuldeshpande can you please explore this warning in the latest build:

warning: function name 'dropZeroSamples' does not agree with function filename '/SCINGE/code/dropSamples.m'

There is also an error related to the mex file

error: glmnetControl: /SCINGE/glmnet_matlab/glmnetMex.mex: failed to load: /SCINGE/glmnet_matlab/glmnetMex.mex: undefined symbol: mxcopyreal8toptr_

This MATLAB help page explains the function https://www.mathworks.com/help/matlab/apiref/mxcopyreal8toptr.html. It seems related to the fintrf.h file. That file is also available from Intel.

This third party project discussed this function with Octave: http://lasp.colorado.edu/cism/CISM_DX/code/CISM_DX-0.50/required_packages/octave-forge/extra/mex/

[agitter]

The octave-snapshots image has been deprecated, but now I found containers for stable releases. This example shows how to run a test in multiple versions of Octave.

[agitter]

@atuldeshpande can you please move these GLG_Instance.m and parseParams.m changes to a new branch? It is likely that we will not be able to resolve the Fortran-Octave mex interface issues and will not merge this pull request. It's okay to keep these changes in this branch because they will help our future testing if we attempt to get this to work.

[agitter]

I received help from an Octave developer regarding this mex error. Octave does not implement the MATLAB Fortran mex interface, meaning mx* functions from MATLAB like mxCopyPtrToReal8 and mxCopyReal8ToPtr are not available. We would need to write a translation layer in C or C++.

In 2007, there was an initial attempt to create this translation layer, but was not completed. See #15 for an update from the author.