Hi Aaron,
* Aaron Griffin on Monday, March 26, 2007 at 12:05:06 -0500:
> On 3/26/07, Christian Ebert <[EMAIL PROTECTED]> wrote:
>> * Aaron Griffin on Monday, March 26, 2007 at 10:39:24 -0500:
>>> Try the following in vim:
>>>
>>> :python import sys; print sys.version
>>
>> 2.5 (r25:51908, Dec 15 2006, 13:53:51)
>> [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)]
>
> Odd, I was hoping that was the issue. This line bothers me:
> /usr/local/lib/python2.5/lib-dynload/cStringIO.so undefined reference
> to _PyArg_ParseTuple expected to be defined in a dynamic image
>
> I don't have enough Mac-fu to track that down though (well, I don't
> have enough Mac, either, forget the -fu, heh).
>
> In a standard python interpreter instance, does importing cStringIO work
> fine?
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.
c
--
Vim plugin to paste current GNU Screen buffer in (almost) any mode:
<http://www.vim.org/scripts/script.php?script_id=1512>
