[issue13631] readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X
Zvezdan Petkovic added the comment: Ned, I just signed the contributor agreement form. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14073] allow per-thread atexit()
Changes by Zvezdan Petkovic zvez...@computer.org: -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13631] readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X
Zvezdan Petkovic zvez...@zope.com added the comment: I did not test against a readline build. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13631] readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X
New submission from Zvezdan Petkovic zvez...@zope.com: Problem === The changes in r87356 for py3k and r87358 for python-2.7 described in issue 9907 have broken parsing of the initialization file .editrc under editline emulation of readline on Mac OS X. Background == Both readline and editline allow settings customized per program. For example, .inputrc file for readline:: $if Python set editing-mode vi $endif will be applied only to Python processes. Similarly, .editrc file for editline:: python:bind -v python:bind ^I rl_complete will be applied only to Python processes on Mac OS X. This works fine on python-2.6. It's broken on 2.7 and 3.2 and later because the change in issue 9907 moved the rl_initialize() call towards the beginning of the setup function. Solution The rl_readline_name variable must be set to python **before** the call to rl_initialize(). Attached are patches for 2.7 and 3.2. -- assignee: ronaldoussoren components: Macintosh files: readline-2.7.patch keywords: patch messages: 149813 nosy: ronaldoussoren, zvezdan priority: normal severity: normal status: open title: readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24043/readline-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13631] readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X
Changes by Zvezdan Petkovic zvez...@zope.com: Added file: http://bugs.python.org/file24044/readline-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9033] cmd module tab misbehavior
Zvezdan Petkovic zvez...@zope.com added the comment: Does a translation really need to be in Python? I use .editrc file in my home directory with this content: python:bind ^I rl_complete and everything works fine. -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: ctypes: delay conversion from c_char_p to string
On Apr 21, 2010, at 6:29 PM, Brendan Miller wrote:
Here's the method I was using. Note that tmp_char_ptr is of type
c_void_p. This should avoid the memory leak, assuming I am
interpreting the semantics of the cast correctly. Is there a cleaner
way to do this with ctypes?
def get_prop_string(self, prop_name):
# Have to work with c_void_p to prevent ctypes from copying to a string
# without giving me an opportunity to destroy the original string.
tmp_char_ptr = _get_prop_string(self._props, prop_name)
prop_val = cast(tmp_char_ptr, c_char_p).value
_string_destroy(tmp_char_ptr)
return prop_val
Is this what you want?
=
import ctypes.util
libc = ctypes.CDLL(ctypes.util.find_library('libc'))
libc.free.argtypes = [ctypes.c_void_p]
libc.free.restype = None
libc.strdup.argtype = [ctypes.c_char_p]
libc.strdup.restype = ctypes.POINTER(ctypes.c_char)
def strdup_and_free(s):
s_ptr = libc.strdup(s)
print s_ptr.contents
i = 0
while s_ptr[i] != '\0':
print s_ptr[i],
i += 1
print
libc.free(s_ptr)
if __name__ == '__main__':
strdup_and_free('My string')
=
That is an equivalent of this C program:
=
#include stdio.h
#include stdlib.h
#include string.h
void
strdup_and_free(char *s)
{
char *s_ptr = strdup(s);
printf(%c\n, *s_ptr);
printf(%s\n, s_ptr);
free(s_ptr);
}
int
main(int argc, char *argv[])
{
strdup_and_free(My string);
return 0;
}
=
To prove that the pointer was actually freed try inserting one more
libc.free(s_ptr) at the end of the function.
You should get Abort trap because you are attempting to free storage that has
already been freed (I did on Mac OS X 10.6)
If you insert a second free(s_ptr) call in the C program you also get an Abort
trap:
strdup2(15785) malloc: *** error for object 0x100100080: pointer being freed
was not allocated
(Again, this is an error message on Mac OS X 10.6)
FWIW, this technique for getting pointer *is* mentioned in ctypes documentation.
Best regards,
Zvezdan
On Wed, Apr 21, 2010 at 3:15 PM, Brendan Miller catph...@catphive.net wrote:
I have a function exposed through ctypes that returns a c_char_p.
Since I need to deallocate that c_char_p, it's inconvenient that
ctypes copies the c_char_p into a string instead of giving me the raw
pointer. I believe this will cause a memory leak, unless ctypes is
smart enough to free the string itself after the copy... which I
doubt.
Is there some way to tell ctypes to return an actual c_char_p, or is
my best bet to return a c_void_p and cast to c_char_p when I'm reading
to convert to a string?
Thanks
Brendan
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: ctypes: delay conversion from c_char_p to string
On Apr 22, 2010, at 10:49 AM, Zvezdan Petkovic wrote: libc.strdup.argtype = [ctypes.c_char_p] Correcting my typo. This should be in plural: libc.strdup.argtypes = [ctypes.c_char_p] -- http://mail.python.org/mailman/listinfo/python-list
[issue8065] Memory leak in readline.get_current_history_length
Changes by Zvezdan Petkovic zvez...@zope.com: -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Ronald, That bit is not in the trunk, should it be forward ported to the trunk? Yes, that should be applied to trunk and 3.x to make it work on Mac OS X 10.5 (Leopard). I indicated that in msg98979. The explanation why that part is needed is given in msg98978 and msg98913. That ultimately points to re-declaration of completion_matches() inserted in a patch in issue4204 (see my comments in the last two messages there). We must *avoid* the duplicate declaration on Mac OS X, because the same declaration is already in /usr/include/readline/readline.h. Hence #if !defined(__APPLE__) is used. So, the readline-libedit-trunk.patch I attached yesterday should be applied to trunk (2.7) and 3.x. As that's not a critical change I've committed the fix1 patch as is in r78096. It seems that you forgot to svn add Lib/test/test_readline.py before committing. If you run svn status on that checkout I bet it will show with '?' in the left column. P.S. FWIW, you are right about #include stdlib.h. I removed it from the patch yesterday (notice attachment, removal, and a new attachment in the history). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: OK, so issue4204 patch is causing problems. As I mentioned before we could choose to #ifdef __FreeBSD__ or check whether __APPLE__ is not defined. I'm attaching a new patch for 2.6.5 (2.6 branch) that uses the __APPLE__ check. -- Added file: http://bugs.python.org/file16160/readline-libedit-2.6.5-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: The patch with the same correction against trunk is attached so that Meador can test it. -- Added file: http://bugs.python.org/file16161/readline-libedit-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Meador, I just looked at your patch (it seems we were posting patches at about the same time). That's a good fix too. Barry it's your call. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Changes by Zvezdan Petkovic zvez...@zope.com: Removed file: http://bugs.python.org/file16160/readline-libedit-2.6.5-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Changes by Zvezdan Petkovic zvez...@zope.com: Removed file: http://bugs.python.org/file16161/readline-libedit-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Changes by Zvezdan Petkovic zvez...@zope.com: Added file: http://bugs.python.org/file16162/readline-libedit-2.6.5-fix1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Changes by Zvezdan Petkovic zvez...@zope.com: Added file: http://bugs.python.org/file16163/readline-libedit-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7807] test_macostools fails on OS X 10.6: no attribute 'FSSpec'
Zvezdan Petkovic zvez...@zope.com added the comment:
This seems to be a 64-bit issue.
The 32-bit build passes this test.
echo ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
/Users/zvezdan/opt/snapshot/2.6.5/bin/python -E -tt
/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/test/test_macostools.py -l -uall
${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
test_copy (__main__.TestMacostools) ... ok
test_mkalias (__main__.TestMacostools) ... ok
test_mkalias_relative (__main__.TestMacostools) ... ok
test_touched (__main__.TestMacostools) ... ok
--
Ran 4 tests in 0.013s
OK
When 64-bit build is used:
echo ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
/Users/zvezdan/opt/snapshot/2.6.5-64/bin/python -E -tt
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py -l
-uall
${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
test_copy (__main__.TestMacostools) ... ERROR
test_mkalias (__main__.TestMacostools) ... ERROR
test_mkalias_relative (__main__.TestMacostools) ... ERROR
test_touched (__main__.TestMacostools) ... ok
==
ERROR: test_copy (__main__.TestMacostools)
--
Traceback (most recent call last):
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py,
line 65, in test_copy
macostools.copy(test_support.TESTFN, TESTFN2)
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py,
line 114, in copy
srcfss = File.FSSpec(src)
AttributeError: 'module' object has no attribute 'FSSpec'
==
ERROR: test_mkalias (__main__.TestMacostools)
--
Traceback (most recent call last):
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py,
line 73, in test_mkalias
macostools.mkalias(test_support.TESTFN, TESTFN2)
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py,
line 46, in mkalias
dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'
==
ERROR: test_mkalias_relative (__main__.TestMacostools)
--
Traceback (most recent call last):
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py,
line 88, in test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py,
line 46, in mkalias
dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'
--
Ran 4 tests in 0.016s
FAILED (errors=3)
Traceback (most recent call last):
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py,
line 101, in module
test_main()
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py,
line 97, in test_main
test_support.run_unittest(TestMacostools)
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_support.py, line
734, in run_unittest
_run_suite(suite)
File
/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_support.py, line
717, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred
--
nosy: +zvezdan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7807
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7852] [PATCH] Drop Computer from Apple Computer in plistlib
Zvezdan Petkovic zvez...@zope.com added the comment: How about this example from Mac OS X Reference Library Property List Programming Guide: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PropertyLists/QuickStartPlist/QuickStartPlist.html Perhaps the fact that Apple officially changed the name from Apple Computer to Apple back in 2007 also helps: http://www.macworld.com/article/54770/2007/01/applename.html This one had a short URL, you can search Google for apple computer changes name for more (Forbes, Information Week, etc.) Do you have a reference where Apple docs written after 2007 use Apple Computer? -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7852] [PATCH] Drop Computer from Apple Computer in plistlib
Zvezdan Petkovic zvez...@zope.com added the comment: Also, on a Mac computer: - start Xcode 3.2.1 and select Help-Developer Documentation - type in the search box in the top right corner property list - the second hit is Property List Programming Guide; click on it - the second page gives the same example as the URL I put in msg98905 - it uses DOCTYPE with /Apple/ only -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: This is a configuration bug: /Users/barry/projects/python/python26/Modules/readline.c -o build/temp.macosx-10.3-ppc-2.6 ... Why is it trying to build using macosx-10.3 target? I bet if you specify MACOSX_DEPLOYMENT_TARGET=10.5 on the ./configure line it will work fine. It worked for me when I used Leopard (until September 2009). This is a bug in configure.in -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Barry, I'm sorry, I only now noticed this line in your compilation on 10.5: /Users/barry/projects/python/python26/Modules/readline.c:41: error: conflicting types for 'completion_matches' This problem was introduced by a patch in issue4204. See my comments in msg82619 and msg92482. They've been ignored because the issue was closed, and I did not have a right to reopen it. Please notice that my original patch attached here (readline-trunk.patch) has this part in it, which is very important for 10.5: @@ -6,6 +6,7 @@ /* Standard definitions */ #include Python.h +#include stdlib.h #include setjmp.h #include signal.h #include errno.h Ronald has omitted that part when he was changing the patch and I completely forgot about its importance since I'm running 10.6 and did not have problems. Initially my first version of the patch was checking for __APPLE__ and avoided to re-define completion_matches on lines 35-36. I used that patch when 2.6.1 came out in my personal builds. Then I found out that including stdlib early avoided the problem. I really do not have a 10.5 machine to test on now. Can you please try inserting that include stdlib.h and see if 10.5 builds readline? If yes, I'd be glad to make a new patch against 2.6 branch and trunk/3.x branch (probably need the same include line). If not, then we need to make a choice of #ifdef __FreeBSD__ as I suggested in issue4204, or #ifndef __APPLE__ as I used in my first personal version of the patch. The problem with re-definition of completion_matches did not exist in 2.4 and 2.5 and is definitely introduced by a patch in issue 4204, which annoyed me because it broke a modern OS to support a very old version of FreeBSD (4.x). :-) aside note That said, I still think that configure.in should not treat 10.5 as 10.3 because Leopard was a big change to the UNIX 2003 specification and too many things are different between 10.3/10.4 and 10.5/10.6. We had a discussion on pythonmac-sig about it and people mostly agreed but I do not remember if any issue was opened in the tracker to act on it or not. /aside note -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment:
The readline-libedit-2.6.5.patch is attached.
The patch was applied and python built in several configurations on Mac
OS X 10.6 (Snow Leopard). There is no regression (details below).
Can somebody else test on Mac OS X 10.5 (Leopard)?
32-bit
==
Configuration with system libedit::
./configure --prefix=${HOME}/opt/snapshot/2.6.5 \
BASECFLAGS=-arch i386 \
CFLAGS=-arch i386 \
LDFLAGS=-arch i386 \
MACOSX_DEPLOYMENT_TARGET=10.6
Configuration with GNU readline 6.1::
./configure --prefix=${HOME}/opt/snapshot/gnurl/2.6.5 \
BASECFLAGS=-arch i386 \
CFLAGS=-arch i386 \
CPPFLAGS=-I/opt/local/include \
LDFLAGS=-arch i386 -L/opt/local/lib \
MACOSX_DEPLOYMENT_TARGET=10.6
Failed tests for both builds:
- test_asynchat
- test_smtplib
64-bit
==
Configuration with system libedit::
./configure --prefix=${HOME}/opt/snapshot/2.6.5-64 \
MACOSX_DEPLOYMENT_TARGET=10.6
Configuration with GNU readline 6.1::
./configure --prefix=${HOME}/opt/snapshot/gnurl/2.6.5-64 \
CPPFLAGS=-I/opt/local/include \
LDFLAGS=-L/opt/local/lib \
MACOSX_DEPLOYMENT_TARGET=10.6checking
Failed tests for both builds:
- test_asynchat
- test_macostools
- test_smtplib
Unexpected skips:
- test_dl
Universal
=
Configuration with system libedit::
./configure --prefix=${HOME}/opt/snapshot \
BASECFLAGS=-arch x86_64 -arch i386 \
CFLAGS=-arch x86_64 -arch i386 \
LDFLAGS=-arch x86_64 -arch i386 \
MACOSX_DEPLOYMENT_TARGET=10.6
Configuration with GNU readline 6.1::
./configure --prefix=${HOME}/opt/snapshot/gnurl \
BASECFLAGS=-arch x86_64 -arch i386 \
CFLAGS=-arch x86_64 -arch i386 \
CPPFLAGS=-I/opt/local/include \
LDFLAGS=-arch x86_64 -arch i386 -L/opt/local/lib \
MACOSX_DEPLOYMENT_TARGET=10.6
Failed tests for both builds:
- test_asynchat
- test_macostools
- test_smtplib
Unexpected skips:
- test_dl
when run as 64-bit or 32-bit executable.
Errors in both asynchat and smtplib are caused by the same issue in
asyncore.py. A typical error output::
error: uncaptured python exception, closing channel
test.test_asynchat.echo_client at 0x1b112b0
(class 'socket.error':[Errno 9]
Bad file descriptor
[/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/asyncore.py|
readwrite|107]
[/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/asyncore.py|
handle_expt_event|441]
[string|getsockopt|1]
[/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/socket.py|_dummy|165])
but this is not caused by readline patch.
--
Added file: http://bugs.python.org/file16136/readline-libedit-2.6.5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6877
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: I forgot to add that the patch for 2.6.5 is based on: http://svn.python.org/view?rev=74970view=rev -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: 2.6.4 Mac x86_64 ?
On Nov 13, 2009, at 3:58 PM, chris grebeldinger wrote: Hi All, I've been having some trouble getting a x86_64/i386 universal readline.so to build against libedit, on MacOS 10.5.6 as Apple does. Does anyone have any pointers about what changes I need to make to setup.py or readline.c to achive this? Has someone already done this and would like to share it? The fix for use of native editline (readline emulation) was done and is already implemented on the trunk (2.7). Please see: http://bugs.python.org/issue6877 You can find the patch in that tracker issue or here: http://svn.python.org/view?view=revrevision=74970 It was marked for a backport to a future 2.6.5 release too. Are there any plans to provide 64 bit support in future Mac OS 2.6.x releases? AFAIK, it is already supported. Perhaps you should specify the exact problems you have. I believe that a more appropriate place for that would be pythonmac-sig mailing list, though. Best regards, Zvezdan -- http://mail.python.org/mailman/listinfo/python-list
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Brett, what does this command return for you? otool -L /path/to/lib/python2.4/lib-dynload/readline.so -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Make that python2.6 in the command above. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: I assume you had to pass extra -I and -L flags when compiling with GNU readline. Right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Brett, IMO, your backtrace only implies that readline module was built believing it has libedit (i.e., include files were system ones from /usr/include). However, the following scenario is possible. Some packaging tools choose to divide library packages into a runtime part and a development part. If you had a copy of readline that was a runtime part only, it would have /usr/local/lib/* files but not /usr/local/include/* files (development part would have them). Because of the way setup.py stashes /usr/local/lib first in the path, the build could have used system /usr/include/* file and linked to your local copy of readline library. This is just a wild guess of course. That's why I was interested in the output of otool command on your build of readline module. That would tell us what it was linked to. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: The patch `readline-libedit.patch` has the following problems: - a typo causing an undefined variable error; - a missing #endif; - it doesn't refer to the new __APPLE__ specific doc string anywhere. It fails to compile `readline.c`. :: Modules/readline.c:1073: error: ‘using_libedit_emultation’ undeclared (first use in this function) Modules/readline.c:1059:1: error: unterminated #ifdef The fixed patch is attached as `readline-libedit-2.patch` above. Please review it. There are also a few minor stylistic nits I took a liberty to fix. In readline.c = Line 496 Formatted a block comment to a usual C style (used by other comments it the patch, FWIW). Line 505 The standard style in C (and C-like) languages is to *not* write a space between a variable and a unary operator (e.g., C++). Changed it to:: idx--; Lines 1085/86 Removed two unnecessary empty lines added by the first patch. There's already one empty line in the original code to space an if statement from the next line. Line 1070 Line was longer than 79 characters (violates PEP-7). Reformatted. In setup.py === Line 561 A comment block was indented in the first patch and had lines longer than 79 characters (violates PEP-8). I refactored the code to avoid repeating the same else statement twice. This obviated the need to indent the said comment block. *Please review whether you agree with the refactoring* Just out of curiosity: does anyone know why the first if statement that tests for 'darwin' uses ``platform`` and the second one uses ``sys.platform``? Couldn't we use ``platform`` in both of them? -- Added file: http://bugs.python.org/file14899/readline-libedit-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
New submission from Zvezdan Petkovic zvez...@zope.com: The attached patch enables compilation and use of the readline module on Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard). It utilizes the native editline library (used for emulation of the readline library on Mac). I used the patch for almost two years already with Python 2.4 and since December 2008 with Python 2.6. The only difference is that Python 2.4 did not need the setup.py changes. The patch is written in such a way that it does *not* affect the compilation on systems that use GNU readline library (e.g., Linux). However, I don't have access to any other system that uses editline emulation of readline library besides Mac. I believe it should work the same but some testing would be welcome if anyone is aware of such a system (NetBSD?). With the readline module compiled in, it is enough to put in .editrc python:bind -v and one gets a vi emulation in the python interactive interpreter. You can also try it directly from the shell: import readline readline.parse_and_bind(bind -v) # use editing features to change the lines above to import rlcompleter readline.parse_and_bind(bind ^I rl_complete) # now TAB offers the completions It would be nice if we could get this included into Python-2.6.3 release. -- components: Build files: readline-trunk.patch keywords: patch messages: 92480 nosy: zvezdan severity: normal status: open title: enable compilation of readline module on Mac OS X 10.5 and 10.6 type: compile error versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14871/readline-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Changed type to crash because compilation of readline module without this patch was causing Python to crash with BusError. -- type: compile error - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4204] Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
Zvezdan Petkovic zvez...@zope.com added the comment: I worked around the issue mentioned in msg82619. The readline patch (issue 6877) is not adversely affected by the patch applied in this issue. This issue can remain closed AFAIC. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment:
When testing the patch make sure that your readline module has been
actually linked against editline library rather then some copy of GNU
readline from MacPorts or Fink.
Assuming --prefix=${HOME}/opt, the output of
otool -L ~/opt/lib/python2.4/lib-dynload/readline.so
should contain /usr/lib/libedit.2.dylib.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6877
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6872] Support system readline on OS X 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: This patch could potentially break non-Mac OS X systems. Fortunately, I have a patch that works with systems that use GNU readline and systems that use editline emulation. See issue 6877. Unfortunately, I was lingering for over a year with opening a tracker issue for it. Last night I did the last testing session with the trunk checkout and I did not notice that this issue has been opened in the meantime. Sorry for opening the double issue. I think that the patch from issue 6877 should be used. -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6872] Support system readline on OS X 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: Also, the patch from issue 6877 changes setup.py in a way that enables build of the readline module on Leopard as well. Such build is used for about two years already (Python 2.4) by several people in my company and nobody noticed any issues on Mac OS X Leopard. AFAICT, it works the same now on Snow Leopard. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Zvezdan Petkovic zvez...@zope.com added the comment: It would also be nice if one could programmaticly detect if readline is linked to libedit There's this rl_library_version constant defined in editline/readline C libraries that the attached patch uses. Perhaps, if we can expose its value from the Python readline module, one could check whether the value startswith(EditLine wrapper) in ipython and similar programs. Regarding your comment about editline being broken on Leopard: The patch worked just fine for me and other people who used it in my company. We used line editing and history in interactive interpreter with both Python 2.4 and Python 2.6 on Leopard. One person used it with Python 2.4 and ipython. He did not have a readline functionality until he compiled with the patch. After applying the patch the line editing, history and TAB completion worked for him in ipython. He's now running Snow Leopard so we couldn't check one more time. Perhaps you meant it was broken on Tiger (10.4; Darwin 8). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Does Class implements Interface?
On Aug 27, 2009, at 9:16 AM, Emanuele D'Arrigo wrote: Are there resources such as tools, recipes, documents or strategies that could help me deal with these issues? I've already looked into the ABC module and the zope.interface. I'm just fishing for more things to look at. You say above that you looked at zope.interface. Did you look at zope.interface.verify? Specifically, verify.txt doctests state that: An object provides an interface if - either its class declares that it implements the interfaces, or the object declares that it directly provides the interface - the object defines all the methods required by the interface - all the methods have the correct signature - the object defines all non-method attributes required by the interface zope.interface.verify.verifyObject(I, obj) will check all of the above. Similarly, zope.interface.verify.verifyClass(I, C) will check the class. It is a good practice to call these functions in the regression tests. If this is not what you are looking for, sorry for the noise. Zvezdan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Image Library IOError - cannot find JPEG decoder?
On Feb 24, 9:34 am, Dario Traverso traver...@gmail.com wrote: I've been trying to install the Python Image Library (PIL) on my Mac OSX Leopard laptop, but have been running into some difficulties. ... I've followed all of the installation instructions exactly. The build summary reported everything was ok. What could be the problem here. Libjpeg-6b is not accessible? That would be my guess. It could be something obvious and something you have done, but it's worth asking: 1. Do you have the path to fink binaries, such as djpeg, in your shell PATH (e.g., /opt/local/bin for MacPorts)? 2. Did you set up the path to the libraries you linked with in the environment variable DYLD_LIBRARY_PATH? For example, DYLD_LIBRARY_PATH=/opt/local/lib for MacPorts 3. Did you execute your app with this variable available. $ env DYLD_LIBRARY_PATH=/opt/local/lib your-app Once you confirm what is missing you can write a Python wrapper to call your app with the right environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Battleship style game
On Feb 25, 2009, at 3:54 PM, Shawn Milochik wrote: It is true that it would be fewer lines of code with the same functionality, but it's better practice to have that framework in place so that any changes made in the future wouldn't break any of the code accessing my class. Obviously this is a fairly simple game that has a fixed set of rules, but I'm trying to cultivate good habits, and I don't think that doing it this way is anti-Pythonic. Well, they are trying to help you with the best practices. You offered the code for review and they reviewed it. Whether you'll accept what they say or deny it is your call, of course. FWIW, the Pythonic way would be: class Ship(object): ... def __init__(self, length): ... self._length = length ... @property ... def length(self): ... return self._length ... s = Ship(5) s.length 5 # notice how the property is read-only which is what you wanted s.length = 7 Traceback (most recent call last): File stdin, line 1, in module AttributeError: can't set attribute ^D Using @property decorator makes a read-only property. If you need a read/write property there are several ways to define setter and deleter methods with or without decorators. I hope you see that x = s.length s.position = y is a completely different style than x = s.get_length() s.set_position(y) Most of the people who program in Python prefer the first style above. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with environment variables and cx_Oracle
On Feb 24, 2009, at 4:34 PM, Brandon Taylor wrote: Here's my setup: OS X (10.5.6 - Intel), Oracle Instant Clinet 10_2, Python 2.6.1, Django trunk OS X is an important detail here. In my .bash_profile, I have ORACLE_HOME and LD_LIBRARY_PATH specified as: ORACLE_HOME=$HOME/Library/Oracle/instantclient_10_2 export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME export LD_LIBRARY_PATH Shouldn't this be DYLD_LIBRARY_PATH for Mac? -- http://mail.python.org/mailman/listinfo/python-list
[issue4204] Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
Zvezdan Petkovic zvez...@zope.com added the comment: Part of this patch committed in -r 67098 breaks Mac OS X 10.5, because the completion_matches() function is already declared in /usr/include/readline/readline.h and the new declaration conflicts with it. If the lack of this declaration is a problem for FreeBSD, then it will have to be conditionally declared for FreeBSD platform, and perhaps specific version of FreeBSD 4.x. Something along the lines of: #ifdef __FreeBSD__ /* perhaps a specific FreeBSD version condition here 4.x? */ extern char **completion_matches(char *, CPFunction *); #endif I have a patch of an off-by-one out-of-bounds error in readline.c, that enables building Python with Mac OS X native readline/editline emulation. There's no need for an external GNU readline port installation (unless one wants some features that editline perhaps doesn't have). That patch worked fine with Python 2.4 ad 2.5, but when I tried it with Python 2.6.1 the build failed because of the conflicting declaration introduced with this tracker issue. When the line extern char **completion_matches(char *, CPFunction *); is commented out, the readline module compiles and works OK. (Well, line 558 in setup.py needs to be uncommented to look like this: if platform == 'darwin' and os.uname()[2] '9.': to allow the use of Mac OS X readline/editline library) I can submit the readline.c patch for Mac OS X in a separate tracker issue, but the changes done in this issue should be fixed separately in my opinion. Please advise how to proceed. -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
