[Pythonmac-SIG] OSX10.6/readline-6.1/python-2.6.5
Hi,
I'm compiling python and readline from source and getting a segmentation
fault in readline after two lines of input. Anybody seen this before or know
the fix? Summary of the problem follows.
% python
Python 2.6.5 (r265:3362, May 25 2010, 09:06:56)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type help, copyright, credits or license for more information.
a = 1
b = 2
Segmentation fault
The built python works fine if I compile without readline support. My
readline and python configuration steps look like this:
readline:
configure --prefix=${MY_PREFIX} CC=/usr/bin/gcc
python:
./configure --prefix=${MY_PREFIX} --enable-framework=${MY_PREFIX}
CFLAGS=-I${MY_PREFIX}/include LDFLAGS=-L${MY_PREFIX}/lib
--with-readline-dir=${MY_PREFIX}
Also, I've tried MACOSX_DEPLOYMENT_TARGET=10.3 and 10.6.
Running python in gdb shows the
% gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC
2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as x86_64-apple-darwin...Reading symbols for
shared libraries . done
(gdb) run
Starting program: /Users/cekees/src/proteus/darwin/bin/python
Reading symbols for shared libraries . done
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7fff5fc01028 in __dyld__dyld_start ()
(gdb) c
Continuing.
Reading symbols for shared libraries .. done
Python 2.6.5 (r265:3362, May 25 2010, 09:06:56)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type help, copyright, credits or license for more information.
Reading symbols for shared libraries ... done
a = 1
b = 2
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001003ee0a7 in call_readline (sys_stdin=value temporarily
unavailable, due to optimizations, sys_stdout=value temporarily
unavailable, due to optimizations, prompt=value temporarily unavailable,
due to optimizations) at
/Users/cekees/src/proteus/externalPackages/Python-2.6.5/Modules/readline.c:1037
1037 line = history_get(state-length)-line;
(gdb) back
#0 0x0001003ee0a7 in call_readline (sys_stdin=value temporarily
unavailable, due to optimizations, sys_stdout=value temporarily
unavailable, due to optimizations, prompt=value temporarily unavailable,
due to optimizations) at
/Users/cekees/src/proteus/externalPackages/Python-2.6.5/Modules/readline.c:1037
#1 0x000186e2 in PyOS_Readline (sys_stdin=0x7fff702be0c0,
sys_stdout=0x7fff702be158, prompt=0x10059cf24 ) at
Parser/myreadline.c:208
#2 0x0001a088 in tok_nextc (tok=0x100458310) at
Parser/tokenizer.c:784
#3 0x0001a81a in tok_get [inlined] () at
/Users/cekees/src/proteus/externalPackages/Python-2.6.5/Parser/tokenizer.c:1131
#4 0x0001a81a in PyTokenizer_Get (tok=0x100458310,
p_start=0x7fff5fbfe658, p_end=0x7fff5fbfe650) at Parser/tokenizer.c:1571
#5 0x000154da in parsetok (tok=0x100458310, g=value temporarily
unavailable, due to optimizations, start=value temporarily unavailable,
due to optimizations, err_ret=0x7fff5fbfe6b0, flags=0x7fff5fbfe6dc) at
Parser/parsetok.c:159
#6 0x0001000dd592 in orte_iof_base_setup_prefork () at
Python/pythonrun.c:1463
#7 0x0001000de7a3 in orte_ns_base_get_proc_name_string () at
Python/pythonrun.c:824
#8 0x0001000dea8e in PyRun_InteractiveLoopFlags (fp=0x7fff702be0c0,
filename=0x10011a988 stdin, flags=0x7fff5fbfe8e0) at
Python/pythonrun.c:764
#9 0x0001000df301 in PyRun_AnyFileExFlags (fp=0x7fff702be0c0,
filename=0x10011a988 stdin, closeit=0, flags=0x7fff5fbfe8e0) at
Python/pythonrun.c:733
#10 0x0001000ee697 in orte_rmaps_base_get_job_map () at
Modules/main.c:572
#11 0x00010f14 in ?? ()
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
On Tuesday, May 24, 2010, Aahz wrote: If you care about the Mac (particularly in terms of being able to use PyObjC and/or py2app), stick with 2.x for now. Otherwise, it doesn't matter much which exact version of 3.x you use. This brings up a question for me as to what the state of Python is on the Mac. Python 3.x has been a available for quite awhile. I see on Python.org that 3.1.2 is listed as the current download for the Mac. What exactly is the current state of this? What doesn't work on the Mac in Python 3 and what are current plans related to this? The Mac Python community seems pretty small. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. I know that various individuals on this list put a tremendous amount of work into porting and supporting various parts of Python on the Mac platform. But what is the overall state of Python here? Especially in regards to Python 3, which seems to definitely be the future of the language. I have looked at moving into Python several times over the years, but it always seems to be a second class language when it comes to producing programs to run on the Mac. At least outside of various command line tools. Is Python moving toward parity with the Windows and Unix world on the Macintosh? Thanks, -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] OSX10.6/readline-6.1/python-2.6.5
On May 25, 2010, at 10:25 AM, Chris Kees wrote:
Hi,
I'm compiling python and readline from source and getting a segmentation
fault in readline after two lines of input. Anybody seen this before or know
the fix? Summary of the problem follows.
% python
Python 2.6.5 (r265:3362, May 25 2010, 09:06:56)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type help, copyright, credits or license for more information.
a = 1
b = 2
Segmentation fault
I've seen this before if a Mac OS X native editline (readline emulation) is
used with Mac OS X version = 10.4. This was fixed and patched for 10.6 and
10.5 in Python 2.6.5 release.
You should be able to use a native editline (readline). There's no need for an
external readline library if you use Python 2.6.5 with Mac OS X 10.6 or 10.5.
The built python works fine if I compile without readline support. My
readline and python configuration steps look like this:
readline:
configure --prefix=${MY_PREFIX} CC=/usr/bin/gcc
python:
./configure --prefix=${MY_PREFIX} --enable-framework=${MY_PREFIX}
CFLAGS=-I${MY_PREFIX}/include LDFLAGS=-L${MY_PREFIX}/lib
--with-readline-dir=${MY_PREFIX}
It is better to use CPPFLAGS=-I${MY_PREFIX}/include to pass include path, not
CFLAGS. Using CPPFLAGS ensures that the order of include path parts is the
same as Python build intended it to be: -I. -IInclude ... are first and then
user's CPPFLAGS include path parts.
This is a configuration that worked for me with GNU readline from MacPorts (in
/opt/local/...)
./configure \
--prefix=${HOME}/opt \
LDFLAGS=-L/opt/local/lib \
CPPFLAGS=-I/opt/local/include \
MACOSX_DEPLOYMENT_TARGET=10.6
One can check that Python was linked against it using:
OPT_PYTHON=~/opt/bin/python2.6
MODULE_PATH=import readline; print readline.__file__
otool -L $(${OPT_PYTHON} -c ${MODULE_PATH})
It should return:
/opt/local/lib/libreadline.X.Y.dylib
Also, I've tried MACOSX_DEPLOYMENT_TARGET=10.3 and 10.6.
The default configuration for Intel-based Mac sets the deployment target to
10.4 (Tiger). For a PPC Mac, the default configuration sets the deployment
target to 10.3 (Panther).
As mentioned before, if you set the deployment target to 10.6, you don't need
an external copy of readline (unless you want specific GNU readline features).
This configuration builds a 64-bit Python 2.6 linked against the native
editline.
./configure \
--prefix=${HOME}/opt \
MACOSX_DEPLOYMENT_TARGET=10.6
The check with otool (see above) returns:
/usr/lib/libedit.2.dylib
(compatibility version 2.0.0, current version 2.11.0)
(Add more options for a universal build or a 32-bit only build.)
Now, let's see the gdb output ...
Running python in gdb shows the
% gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC
2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as x86_64-apple-darwin...Reading symbols for shared
libraries . done
(gdb) run
Starting program: /Users/cekees/src/proteus/darwin/bin/python
Reading symbols for shared libraries . done
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7fff5fc01028 in __dyld__dyld_start ()
(gdb) c
Continuing.
Reading symbols for shared libraries .. done
Python 2.6.5 (r265:3362, May 25 2010, 09:06:56)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type help, copyright, credits or license for more information.
Reading symbols for shared libraries ... done
a = 1
b = 2
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001003ee0a7 in call_readline (sys_stdin=value temporarily
unavailable, due to optimizations, sys_stdout=value temporarily
unavailable, due to optimizations, prompt=value temporarily unavailable,
due to optimizations) at
/Users/cekees/src/proteus/externalPackages/Python-2.6.5/Modules/readline.c:1037
1037 line = history_get(state-length)-line;
The line above should be executed for GNU readline.
However, for the native editline it causes a crash because of off-by-one array
access.
You should check what library is the readline module linked against using otool
as shown above. It seems that it's linked against libedit, but compiled in a
way that prevents it from using the code specific to libedit.
This line should be executed for libedit:
line = history_get(state-length - 1)-line;
Are you sure that Python can actually find your copy of readline?
What is the exact path to your copy of
Re: [Pythonmac-SIG] Which version to use??
Rodney Somerstein wrote: If you care about the Mac (particularly in terms of being able to use PyObjC and/or py2app), stick with 2.x for now. Otherwise, it doesn't matter much which exact version of 3.x you use. This brings up a question for me as to what the state of Python is on the Mac. Python 3.x has been a available for quite awhile. I see on Python.org that 3.1.2 is listed as the current download for the Mac. What exactly is the current state of this? What doesn't work on the Mac in Python 3 and what are current plans related to this? Honestly, I don't know if the Mac is in any poorer position with regard to Python 3 as any other platform. NONE of the major packages I use have been ported to Py3 on any platform: numpy, SciPy, wxPython. Many of those are well supported on the Mac, so I don't think there will be any issues there. The Mac Python community seems pretty small. There are a LOT of folks using Python on teh Mac -- the community that is pretty small is the community of folks doing mac-specific stuff -- PyObjC, for instance. It getting to be that the the fradction of development that is done for desktop apps is pretty small -- and that that is done is often done with cross-platfrom tools. The only folks that care about py2app are folks doing desktop development and the only folks that care about PyObjC are folks doing desktop development for Mac-only applications. If that is what you want to do, then you are right, the community is pretty small -- is there a larger one built around an open-source dynamic language? I have no idea. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. It does have first class support for scripting, command line stuff, web app development, etc -- one reason the there are so many more users of Python on the Mac than there are folks on this list is that all that stuff just works. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] OSX10.6/readline-6.1/python-2.6.5
On May 25, 2010, at 10:25 AM, Chris Kees wrote: I'm compiling python and readline from source and getting a segmentation fault in readline This approach worked for me: http://rh0dium.blogspot.com/2010/01/building-python-on-264-snow-leopard.html I believe there's a test or two that fails, but they've been noted in the Python issue tracker. HTH, Charles ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] PIL binaries -- please test
Hi folks, Much to my surprise, I had a little time to build some PIL binaries: http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip I'd really like folks to test them on as many different systems as possible. You can see these are for python 2.5 or 2.6, build with and for the python.org python binaries. They should have all dependencies statically linked. I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd love if someone could test and see if they do, however, I no longer have a 10.4 system to test on. I do expect them to work on 10.5 and 10.6, PPC and Intel. Please let me know if you test, whether it worked or not, and on what system/python. If these work well, I think Fredrik will put them on the PIL site. Thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] OSX10.6/readline-6.1/python-2.6.5
On May 25, 2010, at 2:40 PM, Charles Turner wrote: On May 25, 2010, at 10:25 AM, Chris Kees wrote: I'm compiling python and readline from source and getting a segmentation fault in readline This approach worked for me: http://rh0dium.blogspot.com/2010/01/building-python-on-264-snow-leopard.html This is exactly why I asked the OP in the previous post how his readline was compiled and where it was stored. You took care to compile it universal and for the same deployment target as your Python. That is very important. Additionally, you installed both into (a default) /usr/local/... which again may be important because it's in the default path for library search. I must point out, though, that you built Python 2.6.4 where compilation of GNU readline was the only option. Starting with Python 2.6.5, when the deployment target is 10.6 (or 10.5), the GNU readline is not needed at all. Python will link with the native editline and work just fine. The OP should be able to build it using your instructions with or without external GNU readline. Best regards, Zvezdan ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
On 25 May, 2010, at 18:18, Rodney Somerstein wrote: On Tuesday, May 24, 2010, Aahz wrote: If you care about the Mac (particularly in terms of being able to use PyObjC and/or py2app), stick with 2.x for now. Otherwise, it doesn't matter much which exact version of 3.x you use. This brings up a question for me as to what the state of Python is on the Mac. Python 3.x has been a available for quite awhile. I see on Python.org that 3.1.2 is listed as the current download for the Mac. What exactly is the current state of this? What doesn't work on the Mac in Python 3 and what are current plans related to this? Python 3.1.2 works fine on OSX. There is an issue with building extensions on OSX 10.6, but that will be fixed in 3.1.3. PyObjC in the repository works with python 3 and I'm working towards a release. I haven't looked into py2app yet. With some luck it will work without major changes. The Mac Python community seems pretty small. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. I know that various individuals on this list put a tremendous amount of work into porting and supporting various parts of Python on the Mac platform. But what is the overall state of Python here? Especially in regards to Python 3, which seems to definitely be the future of the language. Porting to py3k is an issue throughout the python community, mostly because cleanly porting non-trivial projects takes time. What hasn't helped is that a lot of project depend on setuptools and that didn't supported until pretty recently (and that only through the 'distribute' fork). As far as PyObjC is concerned port to py3k was a lot of work due to C-API changes and because PyObjC tries to provide seemless integration between Python and Cocoa, which means it is pretty sensitive to the large changes between python 2.x and 3.x. I have looked at moving into Python several times over the years, but it always seems to be a second class language when it comes to producing programs to run on the Mac. At least outside of various command line tools. Is Python moving toward parity with the Windows and Unix world on the Macintosh? What do you mean? Python on OSX is support as well as it is on Linux and Windows. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PIL binaries -- please test
How do you determine which version of Python to build for? I'm on 10.4 and I've got two versions of Python – python2.3 in /usr/bin/python and python2.5 in /opt/local/bin/python. python2.5 is my default (i.e. the one that shows when I run 'which python'), but the package installer doesn't seem to recognize it. It gives me an error saying You cannot install PIL 1.1.7 on this volume. PIL requires System Python 2.5 to install. Aditya On Tue, May 25, 2010 at 2:57 PM, Christopher Barker chris.bar...@noaa.govwrote: Hi folks, Much to my surprise, I had a little time to build some PIL binaries: http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip I'd really like folks to test them on as many different systems as possible. You can see these are for python 2.5 or 2.6, build with and for the python.org python binaries. They should have all dependencies statically linked. I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd love if someone could test and see if they do, however, I no longer have a 10.4 system to test on. I do expect them to work on 10.5 and 10.6, PPC and Intel. Please let me know if you test, whether it worked or not, and on what system/python. If these work well, I think Fredrik will put them on the PIL site. Thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG -- wefoundland.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
At 11:17 AM -0700 5/25/10, Christopher Barker wrote: Honestly, I don't know if the Mac is in any poorer position with regard to Python 3 as any other platform. NONE of the major packages I use have been ported to Py3 on any platform: numpy, SciPy, wxPython. Many of those are well supported on the Mac, so I don't think there will be any issues there. Thanks, Chris. This is the kind of thing I was trying to find out. After I asked the question I started reading the comp.lang.python newsgroup and see that lots of people seem to be in the same situation. There are a fair number of people wanting to USE Python 3.x - that is, develop WITH Python 3.x. However, the people that make all of the tools for those of us that want to use them are not porting or are at least not being very public about their ports. To someone like me, who is mostly looking in from the outside, Python seems like it has a lot of potential but the fragmentation of the development community is a bit problematic. Unless the powers that be decide to once and for all cease development of the 2.x branch of Python, I'm not sure that 3.x will ever end up having the support that it needs in terms of ported packages. If I had the ability to port something like wxPython, I would definitely do so. Unfortunately, that isn't the case. It seems kind of strange to start doing work with 2.7 when supposedly 3.1.2 is the current version. Does no one other than the maintainers of the language itself want 3.x to succeed? The Mac Python community seems pretty small. There are a LOT of folks using Python on teh Mac -- the community that is pretty small is the community of folks doing mac-specific stuff -- PyObjC, for instance. It getting to be that the the fradction of development that is done for desktop apps is pretty small -- and that that is done is often done with cross-platfrom tools. True. Unfortunately, the cross-platform tools like wxPython don't seem to be there for Python 3. I would love to use Python for some cross-platform application development. Packaging on the Mac, in particular, though, seems to be a bit iffy. Yes, there is on-going work on py2app. However, it seems to mostly be a one person project with work done as available. (A hazard of open source, I guess.) The only folks that care about py2app are folks doing desktop development and the only folks that care about PyObjC are folks doing desktop development for Mac-only applications. If that is what you want to do, then you are right, the community is pretty small -- is there a larger one built around an open-source dynamic language? I have no idea. I'm not sure that there is a larger Mac community built around an open-source dynamic language. However, I'm trying to figure out how viable Python is to develop applications on the Mac. That requires at least py2app for packaging and PyObjC for full access to Mac native controls, from what I can tell. wxPython may be a viable option, but the 3.x support seems MIA. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. It does have first class support for scripting, command line stuff, web app development, etc -- one reason the there are so many more users of Python on the Mac than there are folks on this list is that all that stuff just works. I suppose that is true. Maybe it is just application development where people want native applications for the various platforms that doesn't just work. It is possible that Python will never be that. I have been hoping for a long time that it would be moving in that direction. That is the main reason for my original questions here. Thanks, -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PIL binaries -- please test
Christopher Barker wrote: Much to my surprise, I had a little time to build some PIL binaries: http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip I'd really like folks to test them on as many different systems as possible. You can see these are for python 2.5 or 2.6, build with and for the python.org python binaries. They should have all dependencies statically linked. I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd love if someone could test and see if they do, however, I no longer have a 10.4 system to test on. I tried the py2.6 binary on OSX 10.4. The package installs fine but it can't really load an image. When I open a jpg, I can read its size but as soon as I try to load the data, I get an import error: ImportError: The _imaging C module is not installed When I try to import _imaging manually I get: ImportError: dlopen(./_imaging.so, 2): Symbol not found: _clock$UNIX2003 Referenced from: ./_imaging.so Expected in: dynamic lookup I don't know what that UNIX2003 means? Is that a special version of clock() that's not compatible with the one provided here on 10.4? Cheers, - Matthias - ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PIL binaries -- please test
aditya bhargava wrote: How do you determine which version of Python to build for? I'm on 10.4 and I've got two versions of Python – python2.3 in /usr/bin/python and python2.5 in /opt/local/bin/python. python2.5 is my default (i.e. the one that shows when I run 'which python'), but the package installer doesn't seem to recognize it. It gives me an error saying You cannot install PIL 1.1.7 on this volume. PIL requires System Python 2.5 to install. Apparently, you got your Python 2.5 from MacPorts (as it's in /opt/local). As far as I know, such installers as provided by Christopher only work with the Python version you can download on python.org (or the system Python probably) whereas if you want extension modules for your MacPorts Python you also have to use MacPorts to install them. Cheers, - Matthias - ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
Rodney Somerstein wrote: At 11:17 AM -0700 5/25/10, Christopher Barker wrote: Honestly, I don't know if the Mac is in any poorer position with regard to Python 3 as any other platform. NONE of the major packages I use have been ported to Py3 on any platform: numpy, SciPy, wxPython. Many of those are well supported on the Mac, so I don't think there will be any issues there. Thanks, Chris. This is the kind of thing I was trying to find out. After I asked the question I started reading the comp.lang.python newsgroup and see that lots of people seem to be in the same situation. There are a fair number of people wanting to USE Python 3.x - that is, develop WITH Python 3.x. However, the people that make all of the tools for those of us that want to use them are not porting or are at least not being very public about their ports. Another problem with porting packages to Python 3 is that Boost.Python or Pyrex are not yet available for Python 3 (Boost.Python is supposed to support Python 3 now, but it didn't work for me). These are used to write extension modules and as long as they are not ready, this will block all the packages that are based on those tools. development community is a bit problematic. Unless the powers that be decide to once and for all cease development of the 2.x branch of Python, I'm not sure that 3.x will ever end up having the support that it needs in terms of ported packages. If I had the ability to port something like wxPython, I would definitely do so. By the way, for doing cross-platform GUI development you could also have a look at PyQt. I think there's no binary around, but building for Python 3 went absolutely smooth in my case. Unfortunately, that isn't the case. It seems kind of strange to start doing work with 2.7 when supposedly 3.1.2 is the current version. I'm quite sure that Python 2.7 will still be around for quite a while. There's a growing number of commercial applications that use Python as their scripting language and I would imagine that in their case, it takes even longer until they move to Python 3, so the demand for Python 2.x packages will still be there for a while. Apart from that, they are not entirely different languages, so if you want to give Python a try, you could just as well begin with Python 2.6 or 2.7. If you write your programs with Python 3 in mind, then I think moving to Python 3 eventually won't be such a big issue. You can use the -3 option when running Python to get warnings when you use stuff that's incompatible with Python 3. Then there's the 2to3 tool that can convert a lot of stuff automatically. If you are using an IDE that has dedicated support for Python, you might also be able to tell it you are writing code for Python 3, so that it warns you when you are writing incompatible code. For example, in Eclipse/PyDev you can set the grammar version that should be used for checking the Python syntax (it constantly yells at me because I'm still not used to print being a function... ;) ) Cheers, - Matthias - ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
Rodney Somerstein wrote: Hopefully things will start to fall into place for Python 3.x. I see questions on comp.lang.python and elsewhere from people wanting to use Python 3.x as their main development language. I think many people, such as myself, are reluctant to jump into Python right now. My perception is that 2.x has a limited life span. Limited, yes, but long -- it is the primary version for most users now -- it will be maintained for a good while. best choice to jump into that right now when the 3.x branch of the language itself is where most work seems to be going on. However, as you noted, many packages aren't trivial to port and that seems to be going very slowly. Which contradicts your perception -- there are two types of work being done: - development of the language itself -- yes, that is the 3.x branch - development of third-party packages -- this is moving slowly to 3.x, but every one I'm involved with is making great effort to keep things 2.x compatible as they develop for 3.x - development of applications with python -- still mostly 2.x The 2 to 3 transition is a much bigger deal for extension packages -- ones that cal into the C runtime, than it is for application code. In short -- fire up 2.6.5, and code away -- I'm quite confident you will be supported as you move forward. How far away is Python 3 from being the main branch of the language? Are we talking another year? 2? 5? I'm going to guess about 2 years until it's the first choice for new projects, and 5 or more before most projects have ported to it -- and that is a totally uneducated guess! In part, due to the fact that packaging seems to be trickier for people to figure out with py2app than with py2exe I have gotten that impression. I've always found py2app to be easier to use, actually. The only thing really missing once that is done is a port of a good cross-platform UI library, such as wxWidgets, so that cross-platform apps can be developed easily. yup -- for me, I think wx will be the last one I rely on to get ported. Oh well. It's a big package! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] OSX10.6/readline-6.1/python-2.6.5
Thanks for explaining the situation with readline. As you suspected, what
was happening is that an older version of readline was installed in
/usr/local/lib that I had forgotten about. The GNU readline I had built as
a 2-way 32/64-bit and installed into ${MY_PREFIX} wasn't getting linked in.
After uninstalling the /usr/local/lib readline and the readline in
${MY_PREFIX} I get a working 2 way 32/64 bit python interpreter from:
./configure --prefix=${MY_PREFIX} --enable-framework=${MY_PREFIX}
--with-universal-archs=intel --enable-universalsdk=/
MACOSX_DEPLOYMENT_TARGET=10.6 CC=/usr/bin/gcc
CPPFLAGS=-I${MY_PREFIX}/include LD=/usr/bin/gcc
LDFLAGS=-L${MY_PREFIX}/lib
I haven't tried to get it working with GNU readline yet, but I think what
I'm going to do is use the readline module from pypi as a fallback on
systems where the default readline module doesn't build instead of carrying
around GNU readline in my stack. For future reference, the readline module
is here: http://pypi.python.org/pypi/readline/2.6.4
Thanks again for your help.
Chris
On Tue, May 25, 2010 at 3:00 PM, Zvezdan Petkovic zvez...@zope.com wrote:
On May 25, 2010, at 2:40 PM, Charles Turner wrote:
On May 25, 2010, at 10:25 AM, Chris Kees wrote:
I'm compiling python and readline from source and getting a segmentation
fault in readline
This approach worked for me:
http://rh0dium.blogspot.com/2010/01/building-python-on-264-snow-leopard.html
This is exactly why I asked the OP in the previous post how his readline
was compiled and where it was stored.
You took care to compile it universal and for the same deployment target as
your Python. That is very important.
Additionally, you installed both into (a default) /usr/local/... which
again may be important because it's in the default path for library search.
I must point out, though, that you built Python 2.6.4 where compilation of
GNU readline was the only option.
Starting with Python 2.6.5, when the deployment target is 10.6 (or 10.5),
the GNU readline is not needed at all. Python will link with the native
editline and work just fine.
The OP should be able to build it using your instructions with or without
external GNU readline.
Best regards,
Zvezdan
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PIL binaries -- please test
Matthias Baas wrote: Christopher Barker wrote: Much to my surprise, I had a little time to build some PIL binaries: http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd love if someone could test and see if they do, however, I no longer have a 10.4 system to test on. I tried the py2.6 binary on OSX 10.4. The package installs fine but it can't really load an image. When I open a jpg, I can read its size but as soon as I try to load the data, I get an import error: ImportError: The _imaging C module is not installed When I try to import _imaging manually I get: ImportError: dlopen(./_imaging.so, 2): Symbol not found: _clock$UNIX2003 Referenced from: ./_imaging.so Expected in: dynamic lookup Thanks for testing -- it's pretty much what I expected. I build libjpeg will macports, and it linked it against the 10.5 system libs. It's certainly possible to build libs that are 10.4 compatible, but it's a pain to do on a 10.5 machine. I don't have much time, so these will remain 10.5 and above binaries, unless someone steps up to build universal versions of the dependencies that work with 10.4. NOTE: it was trivial to build them with macports on 10.5. However, last time I tried on 10.4, I had trouble. But if you have a 10.4 system and want to give it a try: $ sudo port install jpeg +universal and see if it works -- if it does, try the other dependencies (I think it's freetype, zlib, and lcms -- see the PIL README) Fredrik -- it's up to you what you want to post on your site, but if we hear from some others that they work for them, you might want to post these, making it clear they work only for the python.org binaries and OS-X 10.5 and above. For what it's worth, I built these on an Intel 10.5 system and they work there and on my PPC 10.5 system, so that's a start. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] DESTDIR problem
Hi,
I'm having trouble with 'make install' trying to put or touch a few things
in /Applications even though I've set the prefix and framework directories
to be $MY_PREFIX as in
./configure --prefix=${MY_PREFIX} --enable-framework=${MY_PREFIX}
--disable-universalsdk MACOSX_DEPLOYMENT_TARGET=10.6
When running 'make install' I get:
OSError: [Errno 13] Permission denied: '/Applications/Python 2.6/Build
Applet.app/Contents/Info.plist'
Is there some additional option I need to set to MY_PREFIX to get everything
where I want it?
Thanks,
Chris
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Which version to use??
On 25 May, 2010, at 23:15, Rodney Somerstein wrote: At 10:08 PM +0200 5/25/10, Ronald Oussoren wrote: Python 3.1.2 works fine on OSX. There is an issue with building extensions on OSX 10.6, but that will be fixed in 3.1.3. PyObjC in the repository works with python 3 and I'm working towards a release. I haven't looked into py2app yet. With some luck it will work without major changes. Good to hear. Thanks for the hard work on PyObjC. Do you have specific plans to look into py2app for Python 3? I will look into py2app after the next release of PyObjC, which will happen before python 2.7rc2 is released. The Mac Python community seems pretty small. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. I know that various individuals on this list put a tremendous amount of work into porting and supporting various parts of Python on the Mac platform. But what is the overall state of Python here? Especially in regards to Python 3, which seems to definitely be the future of the language. Porting to py3k is an issue throughout the python community, mostly because cleanly porting non-trivial projects takes time. What hasn't helped is that a lot of project depend on setuptools and that didn't supported until pretty recently (and that only through the 'distribute' fork). As far as PyObjC is concerned port to py3k was a lot of work due to C-API changes and because PyObjC tries to provide seemless integration between Python and Cocoa, which means it is pretty sensitive to the large changes between python 2.x and 3.x. It's great to see dedicated people such as yourself continuing this kind of work. Hopefully things will start to fall into place for Python 3.x. I see questions on comp.lang.python and elsewhere from people wanting to use Python 3.x as their main development language. I think many people, such as myself, are reluctant to jump into Python right now. My perception is that 2.x has a limited life span. It seems not to be the best choice to jump into that right now when the 3.x branch of the language itself is where most work seems to be going on. However, as you noted, many packages aren't trivial to port and that seems to be going very slowly. 2.x has a limited life span indeed, but that's still a long time in Internet time: 2.7 will be maintained at least 2 years and longer when there is reason to do so. The current consensus is that there will be no 2.8 though, which means there will be no new features in 2.x after the release of 2.7 (later this summer). IMHO there is a chicken-and-egg problem: there aren't a lot of python 3 users and hence there is little uptake in porting libraries to python 3. However, the reason there aren't a lot of python 3 users is that a lot of libraries aren't available yet. Are you planning on focusing on 3.x from this point forward with only maintenance on the 2.x version of PyObjC? No. The C code for PyObjC contains lots of conditional code to be able to compile with both branches, while the Python code translates cleanly with 2to3. Having two development branches How far away is Python 3 from being the main branch of the language? Are we talking another year? 2? 5? Most new work in CPython is done in python 3, and when 2.7 is released all new features will only be 3.x. I have looked at moving into Python several times over the years, but it always seems to be a second class language when it comes to producing programs to run on the Mac. At least outside of various command line tools. Is Python moving toward parity with the Windows and Unix world on the Macintosh? What do you mean? Python on OSX is support as well as it is on Linux and Windows. I'm not trying to denigrate the hard work that you and others put into keeping Python functioning well on the Mac. In part, due to the fact that packaging seems to be trickier for people to figure out with py2app than with py2exe I have gotten that impression. Maybe most people are using py2app with very little trouble and I'm only seeing the problems and requests for help that get reported here. Py2app works at least as well as py2exe. The requests you see here are for the harder problems. IIRC two issues crop up reasonably often: (1) support for using py2app with a 64-bit build of python and (2) using py2app with libraries like Qt4 where the automatic detection of dependencies doesn't work. Support for 64-bit builds is relatively new, and full support requires some additional changes to py2app. As I'm the only developer on py2app and do all work in my free time it may take a while until I get around to publishing those changes. The second class of problem could be fixed by recipes in py2app, and
