Turns out that the 64-bit issues are a little more complicated than I realised.
In plplot PLINT is now defined as int32_t. It was formerly defined as long, and the comments still refer to this. Unfortunately the python bindings still define PLINT as long in plplotcmodule.i. This isn't a problem on most 32-bit architectures since at least for gcc int and long are both 32-bit. Unfortunately for 64-bit architectures int is still 32-bit but long is 64-bit. The second complication is that the default integer type for python is long, and so all the integers and arrays in the examples are 64-bit. Previously the bindings worked for all but arrays of integers because of the mistaken definition of PLINT in plplotcmodule.i . I think the only real solution is to explicitly cast the python integers to PLINT in the swig bindings, both for scalars and arrays, on 64-bit platforms. This seems the only way to ensure backwards compatibility and make sure all code is 64-bit clean. As an aside, looking at the java bindings it appears that plplotjavac.i suffers from the same mis-definition of PLINT. I will investigate that one as well. Andrew ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
