Print

Print


Hello Guillaume and Melanni,

I already had liboctave-dev installed. 
I reinstalled it and ran the commands, and still have the same issue.

Best,
-Arnold

On Tue, Nov 6, 2018 at 6:28 AM Flandin, Guillaume <[log in to unmask]> wrote:
Hi Arnold and Melanni,

I still cannot make sense of the errors you report. In order to compile
MEX files for Octave, you indeed need to install liboctave-dev, which
will provide the mkoctfile command.

In a terminal (not within Octave), do the following:
* cd PALM/fileio/@file_array/private/
* rm *.mex*
* mkoctfile --mex file2mat.c
  mkoctfile --mex mat2file.c
  mkoctfile --mex init.c
This should have created three files with a .mex extension.

Run Octave/PALM and let us know what happens.

Best regards,
Guillaume.


On 01/11/2018 18:50, melanni nanni wrote:
> Hi Arnold,
>
> I also observed that it was a mkoctfile dependent on the version of gcc
> in my case, I installed liboctave-dev, then compile it from terminal.
>
> Best,
>
> Melanni
>
> ------------------------------------------------------------------------
> *De:* FSL - FMRIB's Software Library <[log in to unmask]> en nombre de
> Arnold Evia <[log in to unmask]>
> *Enviado:* jueves, 1 de noviembre de 2018 07:19 p. m.
> *Para:* [log in to unmask]
> *Asunto:* Re: [FSL] Error in mat2file using Palm
>  
> I am compiling for Octave on Ubuntu 16.04. When I compiled the file for
> Octave in the terminal, compilation completed with no errors or
> warnings, and I still had the problem.
> I also tried compiling without the 'platform=octave' tag, hoping to get
> some information on what could be going wrong.
>
> -Arnold
>
>
> On Thu, Nov 1, 2018 at 7:28 AM Flandin, Guillaume <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>     Hi Arnold,
>
>     Are you compiling for MATLAB or Octave? The issue observed by Melanni
>     was with Octave. Here you are compiling with mex from the terminal, so
>     it is aiming at compiling for MATLAB (*.mexa64).
>     Also, which version of Ubuntu are you using?
>
>     Best regards,
>     Guillaume.
>
>
>     On 31/10/2018 19:59, Arnold Evia wrote:
>     > Compiling the file using terminal didn't make a difference.
>     > Still observe the same behavior.
>     >
>     > I tried compiling without the platform tags, and  got the
>     following result:
>     >
>     > rm -f file2mat.mexa64 mat2file.mexa64 init.mexa64
>     > mex -O -largeArrayDims file2mat.c
>     > Building with 'gcc'.
>     > Warning: You are using gcc version '5.5.0'. The version of gcc is not
>     > supported. The version currently supported with MEX is '6.3.x'. For a
>     > list of currently supported compilers see:
>     > https://www.mathworks.com/support/compilers/current_release
>     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mathworks.com%2Fsupport%2Fcompilers%2Fcurrent_release&data=02%7C01%7C%7C9bbc52f66f2b4b02446108d640268c98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766931638843783&sdata=Ox1tpl%2BJnhPz9imCFSqVX0Vi%2BSeP%2B6xdkc6cdZabFdM%3D&reserved=0>.
>     > MEX completed successfully.
>     > mex -O -largeArrayDims mat2file.c
>     > Building with 'gcc'.
>     > Warning: You are using gcc version '5.5.0'. The version of gcc is not
>     > supported. The version currently supported with MEX is '6.3.x'. For a
>     > list of currently supported compilers see:
>     > https://www.mathworks.com/support/compilers/current_release
>     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mathworks.com%2Fsupport%2Fcompilers%2Fcurrent_release&data=02%7C01%7C%7C9bbc52f66f2b4b02446108d640268c98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766931638843783&sdata=Ox1tpl%2BJnhPz9imCFSqVX0Vi%2BSeP%2B6xdkc6cdZabFdM%3D&reserved=0>.
>     > MEX completed successfully.
>     > mex -O -largeArrayDims init.c
>     > Building with 'gcc'.
>     > Warning: You are using gcc version '5.5.0'. The version of gcc is not
>     > supported. The version currently supported with MEX is '6.3.x'. For a
>     > list of currently supported compilers see:
>     > https://www.mathworks.com/support/compilers/current_release
>     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mathworks.com%2Fsupport%2Fcompilers%2Fcurrent_release&data=02%7C01%7C%7C9bbc52f66f2b4b02446108d640268c98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766931638843783&sdata=Ox1tpl%2BJnhPz9imCFSqVX0Vi%2BSeP%2B6xdkc6cdZabFdM%3D&reserved=0>.
>     > MEX completed successfully.
>     >
>     > Is mkoctfile dependent on the version of gcc?
>     > If so, then I will try again after updating gcc.
>     >
>     > Arnold M. Evia, Ph.D.
>     > Senior Research Associate
>     > Department of Biomedical Engineering
>     > Medical Imaging Research Center
>     > Illinois Institute of Technology
>     > http://www.iit.edu/~mri/
>     <https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.iit.edu%2F~mri%2F&data=02%7C01%7C%7C9bbc52f66f2b4b02446108d640268c98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766931638843783&sdata=JhxZ6Y0BLpowwAZsauK6yOmJj%2FfMD2wWCPDUhPQYxvY%3D&reserved=0>
>     >
>     >
>     > On Wed, Oct 31, 2018 at 7:37 AM Flandin, Guillaume
>     <[log in to unmask] <mailto:[log in to unmask]>
>     > <mailto:[log in to unmask] <mailto:[log in to unmask]>>> wrote:
>     >
>     >     Hi Arnold,
>     >
>     >     Thanks, we went down the same road with Melanni last week,
>     and, while I
>     >     am still trying to understand what the problem is (somehow
>     related to
>     >     memory alignment), the issue was disappearing if the MEX file were
>     >     compiled from a terminal:
>     >       mkoctfile --mex mat2file.c
>     >     instead of invoking mex() within octave:
>     >       mex mat2file.c
>     >     It shouldn't make any difference (check the source code of
>     mex.m) but
>     >     apparently it does... I would be curious if you can reproduce
>     the same
>     >     phenomenon.
>     >
>     >     Best regards,
>     >     Guillaume.
>     >
>     >
>     >     On 30/10/2018 21:33, Arnold Evia wrote:
>     >     > Hello Guillaume and Melanni,
>     >     >
>     >     > I am also having the same issue as Melanni using PALM in Ubuntu.
>     >     > I tried the commands that you suggested, and got the same output
>     >     as Melanni.
>     >     >
>     >     > After some debugging, I may have found a clue as to what's
>     happening.
>     >     > In mat2file.c, I placed a few print statements for some
>     variables
>     >     right before the error message (line 252):
>     >     >
>     >     >     printf("code = %d\n",map->dtype->code);
>     >     >     printf("bits = %d\n",map->dtype->bits);
>     >     >     printf("channels = %d\n",map->dtype->channels);
>     >     >
>     >     >     if (map->dtype == NULL)        mexErrMsgTxt("Unrecognised
>     >     'dtype' value.");
>     >     >     if (map->dtype->bits % 8)      mexErrMsgTxt("Can not yet
>     write
>     >     logical data.");
>     >     >     if (map->dtype->channels != 1) mexErrMsgTxt("Can not yet
>     write
>     >     complex data.");
>     >     >
>     >     > The program returned unusual numbers:
>     >     >
>     >     > code = 16
>     >     > bits = 32726
>     >     > channels = 7
>     >     > Error using subsasgn>subfun
>     >   
>      ([log in to unmask]:168)
>     >     > mat2file: Can not yet write logical data.
>     >     >
>     >     > Running the program again with the same parameters, values for
>     >     code and channels stays constant, but the value for bits would
>     change:
>     >     >
>     >     > code = 16
>     >     > bits = 32696
>     >     > channels = 7
>     >     > Error using subsasgn>subfun
>     >   
>      ([log in to unmask]:168)
>     >     > mat2file: Can not yet write complex data.
>     >     >
>     >     > As you can see, sometimes bits will be divisible by 8, and the
>     >     program returns a different error.
>     >     > There is a table in the script that defines the values for bits,
>     >     and channels for a specific code.
>     >     > In this case, bits should be 32, and channels should be 1.
>     >     > I don't know why bits and channels are being set to incorrect
>     >     values, and I hope this sheds some light.
>     >     >
>     >     > -Arnold Evia
>     >     >
>     >
>     >     --
>     >     Guillaume Flandin, PhD
>     >     Wellcome Centre for Human Neuroimaging
>     >     UCL Queen Square Institute of Neurology
>     >     London WC1N 3BG
>     >
>
>     --
>     Guillaume Flandin, PhD
>     Wellcome Centre for Human Neuroimaging
>     UCL Queen Square Institute of Neurology
>     London WC1N 3BG
>
>
> ------------------------------------------------------------------------
>
> To unsubscribe from the FSL list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DFSL%26A%3D1&data=02%7C01%7C%7C9bbc52f66f2b4b02446108d640268c98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636766931638843783&sdata=ks03dYN%2Bj1P45qMWUDiuI4h3JMCJzp8vk2Gpn3HWI9o%3D&reserved=0>
>
>
>
> ------------------------------------------------------------------------
>
> To unsubscribe from the FSL list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1
>

--
Guillaume Flandin, PhD
Wellcome Centre for Human Neuroimaging
UCL Queen Square Institute of Neurology
London WC1N 3BG

########################################################################

To unsubscribe from the FSL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1


To unsubscribe from the FSL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1