cyptes problem on MacOS X

I've been trying out ctypes (from MacPython 2.5) on MacOS X
on a PPC Mac 
and have run into a problem. I hope I'm just doing something
stupid, but 
it seems to match the tutorial so I'm really puzzled:

import ctypes
libc = ctypes.CDLL("libc.dylib")
libc.printf("int=%d float=%f double=%fn",
ctypes.c_int(1), 
ctypes.c_float(2.0), ctypes.c_double(3.0));

results in:
int=1 float=-1.996124 double=0.000000

I realize the docs doesn't actually claim to handle dylib
files, but 
I've seen at least some info on the web that claims it
works. One site 
suggested the need for ctypes.RTLD_GLOBAL to CDLL but adding
it made no 
difference.

On a related subject...assuming I can get this to
work...does anyone 
have any idea how the speed of ctypes relates to programming
a python C 
extension or using SWIG? This is mostly for use with NumPy
and 
interfacing python to C/C++-based heavy duty astronomical
image 
processing code.

Other suggestions are welcome. We'll mostly be interfacing
to C++ so 
I've considered trying out Boost, but it hasn't had an
update in years 
which worries me. Robustness, ease of use and speed are all
major 
requirements. Linux and MacOS X are the main platforms.

-- Russell

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

At 2:39 PM -0600 2006-12-11, Perry Smith wrote:
>I don't use floats and double much.  But the printf man
page implies that all
>floats are actually passed as doubles.  I vaguely recall
that to be the case.
>
>But I doubt if the python thingy knows that.  Try not
passing 
>floats.  You might
>also have problems trying to pass char's and short's
(since they are promoted
>to int's).

You're right. I should not have passed floats to printf. But
the 
example also showed doubles being mishandled. Here is a more

extensive example:

import ctypes as ct
libc = ct.CDLL("libc.dylib")
libc.printf("int=%d  double=%fn", ct.c_int(1),
ct.c_double(3.0))
libc.printf("int=%d  double=%f  double=%fn",
ct.c_int(1), 
ct.c_double(3.0), ct.c_double(3.0))

On MacOS X this prints:
int=1  double=-1.996155
int=1  double=-1.996140  double=0.000000

On a linux box, with a suitably modified ct.CDLL statement,
this 
produces the more reasonable:
int=1  double=3.000000
int=1  double=3.000000  double=3.000000

I am totally mystified by the MacOS X results.

-- Russell
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Russell E. Owen wrote:
> I've been trying out ctypes (from MacPython 2.5) on
MacOS X on a PPC Mac 
> and have run into a problem.

I'm no help here.

> On a related subject...assuming I can get this to
work...does anyone 
> have any idea how the speed of ctypes relates to
programming a python C 
> extension or using SWIG?

probably a bit better performance for ctypes -- swig does
put a fair bit 
  between C and Python.

> This is mostly for use with NumPy and 
> interfacing python to C/C++-based heavy duty
astronomical image 
> processing code.

In this case, you'll mostly  be passing large arrays back
and forth -- I 
doubt the overhead of any wrapping technique will be
noticeable.

That being the case, what you want is whatever is most
comfortable for 
you.

> We'll mostly be interfacing to C++ so 
> I've considered trying out Boost, but it hasn't had an
update in years 
> which worries me.

I'm pretty sure that someone has updated the boost array
code for numpy, 
but I'm not sure where to find that out. I'd ask on the
numpy list - if 
no one there is using it, I'd call it risky. You might also
look at the 
C++-sig -- there's been discussion of this there recently.

pyrex is another candidate worth looking at. There should be
examples on 
the scipy Wiki.

This has been my way of thinking:

If you have a substantial existing C/C++ library,
particularly one that 
is undergoing continued development and needs to be used
with both c/C++ 
and Python code: use SWIG (or maybe SIP, but I've never
heard of that 
being used with numpy)

If you have a single dll (or *.so, etc) or small lib, use
ctypes.

If you have ONLY the dll, and not source code, definitely
use ctypes!

If you're developing extensions just for use with Python,
use pyrex or 
boost. Prefer pyrex is it's C, boost if it's C++. Boost gets
even more 
compelling if you are using other boost libs for your C++
stuff.

Cxx maybe worth a look-see. I think it's being used for
matplotlib, so 
there must be a way to so numpy with it.

http://sourcefor
ge.net/projects/cxx/

It would be great it we could put a note like this, with
more detail, on 
the Scipy Wiki. Maybe you could do that when you learn more.

(oh, and be sure to check the Scipy Wiki. there is some
stuff there already)

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barkernoaa.gov
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

On Dec 11, 2006, at 9:20 PM, Russell E. Owen wrote:

> I've been trying out ctypes (from MacPython 2.5) on
MacOS X on a  
> PPC Mac
> and have run into a problem. I hope I'm just doing
something  
> stupid, but
> it seems to match the tutorial so I'm really puzzled:

I can reproduce this on an intel system as well.  You might
want to  
ask about this on the ctypes list (https://lists.sourcefo
rge.net/ 
lists/listinfo/ctypes-users), maybe you're using ctypes
incorrectly.

Ronald

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Russel,

Sorry I have been away from this list a while.  I have been
using  
ctypes on Mac OSX with both PPC and Intel for about a year
and a half  
now.  They work great, as I am regularly interfacing with
Quicktime,  
CoreVideo, and CoreImage, as well as the OpenGL and OpenAL  
frameworks.  We have even been working with the Freetype2
libraries,  
and some various 3rd party vendor libraries.

I think the problem you are having is more about interfacing
with C  
var-args in the printf function, and less a platform
problem.  (None  
of the APIs I work with use varargs)  We are having great
success  
interfacing with system libraries using ctypes.  Numpy makes
a great  
ally when working with large quantities of data.

The hardest part of your work will be interfacing with C++
code,  
mainly because C++ name mangling for methods is not
standardized.   
Your best bet is to look for their external facing API,
which are  
usually exposed in non-name-mangled C.  The GCCXML (compiled
from  
latest source) project does a pretty good job of finding
mangled C++  
entry points for various compiler toolchains, but your
milage may vary.

Hope that helps a bit,
-Shane Holloway

On Dec 11, 2006, at 1:20 PM, Russell E. Owen wrote:

> I've been trying out ctypes (from MacPython 2.5) on
MacOS X on a  
> PPC Mac
> and have run into a problem. I hope I'm just doing
something  
> stupid, but
> it seems to match the tutorial so I'm really puzzled:
>
> import ctypes
> libc = ctypes.CDLL("libc.dylib")
> libc.printf("int=%d float=%f double=%fn",
ctypes.c_int(1),
> ctypes.c_float(2.0), ctypes.c_double(3.0));
>
> results in:
> int=1 float=-1.996124 double=0.000000
>
> I realize the docs doesn't actually claim to handle
dylib files, but
> I've seen at least some info on the web that claims it
works. One site
> suggested the need for ctypes.RTLD_GLOBAL to CDLL but
adding it  
> made no
> difference.
>
> On a related subject...assuming I can get this to
work...does anyone
> have any idea how the speed of ctypes relates to
programming a  
> python C
> extension or using SWIG? This is mostly for use with
NumPy and
> interfacing python to C/C++-based heavy duty
astronomical image
> processing code.
>
> Other suggestions are welcome. We'll mostly be
interfacing to C++ so
> I've considered trying out Boost, but it hasn't had an
update in years
> which worries me. Robustness, ease of use and speed are
all major
> requirements. Linux and MacOS X are the main platforms.
>
> -- Russell
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig