|
From: | Christopher Hulbert |
Subject: | Re: Mex API changes for 64bit |
Date: | Sun, 3 Jun 2007 15:50:33 -0400 |
On 6/3/07, John W. Eaton <address@hidden> wrote:
On 3-Jun-2007, David Bateman wrote: | This is not that hard to add, for example mxGetIr would look something like | | #if SIZEOF_INT != SIZEOF_OCTAVE_IDX_TYPE | mwIndex * | mxGetIr_730 (const mxArray *ptr) | { | return ptr->get_ir (); | } | | int * | mxGetIr_700 (const mxArray *ptr) | { | [...] | } | | #if MX_COMPAT_32 | #define mxGetIr mxGetIr_700 | #else | #define mxGetIr mxGetIr_730 | #endif | | #else | mwIndex * | mxGetIr (const mxArray *ptr) | { | return ptr->get_ir (); | } | #endif | | and like that for every other function that is affected. My first impression is that we are not doing this for and if you want your code to work, then fix your code, or use a 32-bit version of Octave. OTOH, if someone did the work and submitted a nice clean patch I would consider it.
That's fine. I don't plan on trying any mex functions with octave, at least not for a while. I just thought I'd mention a couple of caveats I came across when Matlab made that change. Chris
| At this point 64bit octave is considered experimental in any case.. And it seems to me that there are a number of tasks for 64-bit support (and just for Octave itself) that have much higher priority. For example (and in no particular order): objects graphics large files single precision data type profiler debugger interpreter performance and that's just off the top of my head. jwe
[Prev in Thread] | Current Thread | [Next in Thread] |