-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test running SINGE inside Octave Docker container #13
base: master
Are you sure you want to change the base?
Conversation
https://serverfault.com/questions/594281/how-can-i-override-cmd-when-running-a-docker-image had useful information on the order of |
There is still work to do, but this testing direction seems promising. There will be some compatibility issues. One example is:
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). |
This is possibly related to https://savannah.gnu.org/patch/?9633 |
The Docker container has Octave 4.2.2 and the post linked above claims the exit status was broken in that version. |
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. |
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 |
0c9d42c had the error
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
These do not appear to be fatal because |
@atuldeshpande can you please explore this warning in the latest build:
There is also an error related to the mex file
This MATLAB help page explains the function https://www.mathworks.com/help/matlab/apiref/mxcopyreal8toptr.html. It seems related to the 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/ |
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. |
@atuldeshpande can you please move these |
I received help from an Octave developer regarding this mex error. Octave does not implement the MATLAB Fortran mex interface, meaning In 2007, there was an initial attempt to create this translation layer, but was not completed. See #15 for an update from the author. |
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.