On 3/26/07, Christian Ebert <[EMAIL PROTECTED]> wrote:
Yes.Apparently there is a problem with vim and the *.so libs in /usr/local/lib/python2.5/lib-dynload/. I can't import them inside vim. Whereas something like the following works fine in Vim: :py import StringIO; fp=StringIO.StringIO(); fp.write('hello'); print fp.getvalue() Unfortunately I've no idea about this whole library stuff, so forgive my vagueness: On MacOS X dynamically loaded libraries have a *.dylib suffix, probably Python has it's own mechanism to load the *.so libs, but it fails for this kind of "plugin" mechanism? A typical library file set looks like this: $ ls -l /usr/local/lib/libavcodec.* -rwxr-xr-x 1 root staff 3548764 26 Mar 16:19 /usr/local/lib/libavcodec.51.40.1.dylib lrwxr-xr-x 1 root staff 24 26 Mar 16:19 /usr/local/lib/libavcodec.51.dylib -> libavcodec.51.40.1.dylib -rw-r--r-- 1 root staff 12913944 26 Mar 16:19 /usr/local/lib/libavcodec.a lrwxr-xr-x 1 root staff 24 26 Mar 16:19 /usr/local/lib/libavcodec.dylib -> libavcodec.51.40.1.dylib So "normally" you don't have *.so files.
Hmmm, well, I don't really know what to say w.r.t. all that. The best I can do is push a new pythoncomplete out that isn't dependent on cStringIO. I think it may have been a pre-optimization anyway. I'll make a note of it and see what happens tonight.
