[Pythonmac-SIG] Setting up locale on Mac - how should this been done?
I have a wxPython application (PySVN WorkBench) that is a bundle. When the app runs the environment does not contain any of the usual variables that would be used to into the locale, LANG, LC_ALL etc. What I can see in the environment is __CF_USER_TEXT_ENCODING. I have failed to find details of how to interpret the value of this environment variable which leads me to believe I should not do processing it directly. The trick that works on windows does not work. Windows init: locale.setlocale( locale.LC_ALL, '' ) $ python2.6 Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() (None, 'mac-roman') >>> locale.getlocale() (None, None) >>> locale.setlocale( locale.LC_ALL, '' ) 'C' >>> locale.getlocale() (None, None) >>> The default locale of (None, 'mac-roman') is useless as it does not say which locale the user has selected in System Preferences, Language and Text. How should I init the locale to the users choice? Barry ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Module build fails because distutils adds "-isysroot"
On 30 Sep, 2009, at 11:30, Patrick Näf wrote: Hi folks I'm currently writing a very simple Python module in C that provides an interface to libaprutil's MD5 routines. I compile my module using distutils, as per instructions in the "Building C and C++ Extensions with distutils" chapter of the official Python docs. Since Mac OS X has libaprutil pre-installed, it seems natural that I try to use the system version of the library. My Python module's .c file therefore contains the following #include directive: #include Everything works fine (module compiles and I can use it) as long as I use the system version of Python (2.5.1) to compile the module. The problem is that I *really* need to build the module with Python 2.6 or newer, and this is where my trouble starts. I have Python 3.1.1 installed in /Library/Frameworks/Python, and with this version of Python my module's build fails miserably, like this: tharbad:~ patrick$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1 ./ setup.py build_ext --inplace running build_ext building 'aprmd5' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/Frameworks/Python.framework/Versions/3.1/include/ python3.1 -c aprmd5.c -o build/temp.macosx-10.3-fat-3.1/aprmd5.o aprmd5.c:43:60: aprmd5.c:43:60: error: apr-1/apr_md5.h: No such file or directory [...] The problem here is that the gcc option "-isysroot" moves the root for system includes to the SDK directory (/Developer/SDKs/ MacOSX10.4u.sdk), away from the normal root (/). Unfortunately, the SDK does not contain the header , which causes the build to fail. Where does "-isysroot" come from? Not from my module, it's added automatically by distutils. I believe I have correctly diagnosed the problem, and I can certainly work around it *somehow* in my module, but since I am rather new to Python I have trouble deciding on a solution that is appropriate. I am therefore writing to this list, hoping someone reading this can give me some advice. 1) Is my problem a known situation for which there is a generally accepted, best-practice solution? If so, a pointer in the right direction would be most welcome. If not, what would seem to be a good solution? Make my own build of libaprutil using the MacOSX10.4u SDK? Rely on a third-party build of libaprutil (e.g. fink)? Force the compiler to use the system's libaprutil? The OSX installers are build to explicitly use the 10.4u SDK. That's mostly done to ensure that people on OSX 10.4 can build extensions out of the box. Python 2.6.3 (just released) contains some code that automaticly disables usage of the SDK when it is not present. You can disable usage of the 10.4u SDK by adding the following arguments to the definition of your Extension in setup.py: extra_compile_args=['-isysroot', '/'], extra_link_args=['- isysroot', '/'] Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Module build fails because distutils adds "-isysroot"
On 30 Sep, 2009, at 18:17, Dave Peterson wrote: Hi Patrick, Patrick Näf wrote: ... my module's build fails miserably, like this: tharbad:~ patrick$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1 ./ setup.py build_ext --inplace running build_ext building 'aprmd5' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/Frameworks/Python.framework/Versions/3.1/include/ python3.1 -c aprmd5.c -o build/temp.macosx-10.3-fat-3.1/aprmd5.o aprmd5.c:43:60: aprmd5.c:43:60: error: apr-1/apr_md5.h: No such file or directory [...] The problem here is that the gcc option "-isysroot" moves the root for system includes to the SDK directory (/Developer/SDKs/ MacOSX10.4u.sdk), away from the normal root (/). Unfortunately, the SDK does not contain the header , which causes the build to fail. Where does "-isysroot" come from? Not from my module, it's added automatically by distutils. The options distutils uses come from the file at / lib/python2.5/config/Makefile. I don't think there is any distutils API provided to override/change these, just ways to append to them when specifying your extension configuration. These options are used because they are the same ones used when building that Python distribution. So my first suggestion is that you try redefining the -isysroot option in the flags you can specify in your extension's config. There is a good chance the compiler will use the last specification on the line rather than doing something else when it gets two values. If that doesn't work, the only other thing I can think of is to temporarily edit the config/Makefile to remove / change the inclusion of the -isysroot option. Editing the Makefile is not necessary, distutils will automaticly do the right thing when you add '-isysroot' to the compile arguments in setup.py. It should in general never be necessary to edit the Makefile inside your Python installation. Please file an issue in the tracker at python.org if you run into a usecase where you do have to do edit the Makefile. BTW. I'd like to drop the usage of the 10.4u SDK for Python 2.7 and 3.2 and use the default system headers instead (except on 10.4, where we have to use the SDK to enable universal builds). That annoyingly requires some research, it turns out that building a binary on 10.5 with "-isysroot /" does not result in something that's fully usable on 10.4 :-( Ronald HTHs, -- Dave ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Setting up locale on Mac - how should this been done?
On 4 Oct, 2009, at 19:53, Barry Scott wrote:
I have a wxPython application (PySVN WorkBench) that is a bundle.
When the app runs the environment does not contain any of the usual
variables that would be used to into the locale, LANG, LC_ALL etc.
What I can see in the environment is __CF_USER_TEXT_ENCODING.
I have failed to find details of how to interpret the value of this
environment
variable which leads me to believe I should not do processing it
directly.
The trick that works on windows does not work. Windows init:
locale.setlocale( locale.LC_ALL, '' )
$ python2.6
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> locale.getlocale()
(None, None)
>>> locale.setlocale( locale.LC_ALL, '' )
'C'
>>> locale.getlocale()
(None, None)
>>>
The default locale of (None, 'mac-roman') is useless as it
does not say which locale the user has selected in
System Preferences, Language and Text.
How should I init the locale to the users choice?
That depends on the version of OSX you're running.
On my system (10.6.1):
>>> locale.setlocale(locale.LC_ALL, '')
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>>
This should also work in 10.5, but probably not 10.4.
The value of "__CF_USER_TEXT_ENCODING" is undocumented, you shouldn't
rely on that value. The only reliable way to get at the locale
settings from System Preferences is by using mac-specific API's from
CoreFoundation or Cocoa.
BTW. The usual approach for localizing an OSX app is to have language-
specific subbundles in the application bundle, for examples,
"Resources/English.lproj" for the english localization and "Resources/
nl.lproj" for the Dutch localization. Apple's APIs have specific
support for that structure, although I don't know if wxWidgets exposes
that.
Ronald
Barry
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PIL and Snow Leopard
Jerry LeVan wrote: Snow Leopard seems to have severely broken my WxPython Postgresql database browser tool... two or three queries and the app locks up or dies. I have been trying to 'spiff up' its parent, a Tkinter based browser, which still works except that I appear to have lost PIL, Image and Image-Tk some where along the way so I cannot view images stored in the database any more. I'm a little confused about which packages you are having trouble with: TkInter PIL wxPython. Clearly building PIL is an issue for you, but what about the other two? In particular, what wxPython issues are you having? I don't have Snow Leopard, but I'd like to know if there are wxPython issues for the future, and for when I distribute apps for others to run. By the way, if wxPyhon does work OK, it can do a fair bit of image loading/processing, so maybe you don't need PIL for your app. NOTE 2: if you get PIL building, it would be great if you could build a version that statically links the non-standard dependencies, and post it somewhere (preferably give it to Fredrik for him to put up on the PIL site. -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.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PIL and Snow Leopard
On 2009-10-04 15:19 PM, Christopher Barker wrote: Clearly building PIL is an issue for you, but what about the other two? In particular, what wxPython issues are you having? I don't have Snow Leopard, but I'd like to know if there are wxPython issues for the future, and for when I distribute apps for others to run. OS X's 64-bit subsystem, now standard in Snow Leopard, does not have Carbon for UIs, only Cocoa. wxPython is still built against Carbon. wxCocoa is still in development. 32-bit builds of Python can still work with wxPython on Snow Leopard, though. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] PIL and Snow Leopard
On Oct 2, 2009, at 7:40 PM, Bill Janssen wrote: Jerry LeVan wrote: Is building PIL on Snow Leopard 'easy' I have the apple python (32/64) installed and the python.org 2.6.2 (32 bit) version installed. Yes, I just build it with /usr/bin/python, and it works fine. Assuming you have Xcode 3.2 installed. Bill Ugh, this is getting messy... I think that I have built libfreetype.dylib and libjpeg.dylib as i386 and x86_64 libs...at least that is what the file command asserts. I then built the PIL package using the system python in 64 bit mode and installed the rascal in the Apple python. All of the libs appear to be multi-architecture ppc, i386 and x86_64 When I run apple python in 64 bit mode I can run the PIL demos... If I restrict apple python to 32 bit mode all of the programs fail with a bus error. * I then tried to build PIL using the 2.6.2 python from python.org. 1) It would not build under gcc-4.2 I had to define CC=gcc-4.0 the build appeared to succeed and I installed the PIL system. 2) All of the demos failed... I noticed that _imagingtk.so was dynamically linked against the ActiveState Tcl/Tk that is installed in /Library/Frameworks/ Tcl.framework [mbp:/Library/Python/2.6/site-packages/PIL]$ otool -L _imagingtk.so _imagingtk.so: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.4) /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.4) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1) I suppose that I could hide the ActiveState versions by renaming the Frameworks... But even if I did that, how could I force setup.py to use the apple 8.4 tcl/tk system instead of the 'current' 8.5 system? Any suggestions as to how I can get PIL to work when apple python is in 32 bit mode? Any suggestions as to how I can build PIL using the 2.6.2 version of Python from python.org? This is getting ugly...too many impedance mismatches. Jerry A little more success to report. .. I hid the activestate tcl/tk frameworks in /Library/Frameworks and set CC to gcc-4.0 and rebuilt PIL and otool showed that _imagingtk.so was linked against the apple 8.4 Tcl/Tk system. So I installed the build and "tada" Imaging appears to be working in python.org version of python (2.6.2). So this leaves only the "why does apple python (2.6.1) not work when run in 32 bit mode but does in 64 bit mode" question open... Has anyone had success with PIL in this case? Thanks Jerry When I run the Apple Python in 32 bit mode I get a bus error at the same place when I try to display an image using PIL . Here is part of the dump. Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0028 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.tcltk.tklibrary 0x13a1850b Tk_GetImageMasterData + 17 1 com.tcltk.tklibrary 0x13a20cab Tk_FindPhoto + 37 2 _imagingtk.so 0x007faacf PyImagingPhotoPut + 95 3 com.tcltk.tcllibrary 0x138d3d64 TclInvokeStringCommand + 101 4 com.tcltk.tcllibrary0x00489977 Tcl_CreateInterp + 4919 5 com.tcltk.tcllibrary0x0048a96c Tcl_EvalObjv + 72 6 _tkinter.so 0x001e449d Tkapp_CallDeallocArgs + 11750 7 org.python.python 0x0008b372 PyEval_EvalFrameEx + 16375 8 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 9 org.python.python 0x0008b591 PyEval_EvalFrameEx + 16918 10 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 11 org.python.python 0x0002ee2c PyClassMethod_New + 1823 12 org.python.python 0xc700 PyObject_Call + 101 13 org.python.python 0x0001c12e PyClass_New + 1603 14 org.python.python 0xc700 PyObject_Call + 101 15 org.python.python 0x0008677a PyEval_CallObjectWithKeywords + 171 16 org.python.python 0x0001ba58 PyInstance_New + 290 17 org.python.python 0xc700 PyObject_Call + 101 18 org.python.python 0x0008c802 PyEval_EvalFrameEx + 21639 19 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 20 org.python.python 0x0002ee2c PyClassMethod_New + 1823 21 org.python.python 0xc700 PyObject_Call + 101 22 org.python.python 0x0001c12e PyClass_New + 1603 23 org.python.python 0xc700 PyObject_Call + 101 24 org.python.python 0x0008677a PyEval_CallObjectWithKeywords + 171 25 org.python.python 0x0001ba58 PyInstance_New + 290 26 org.python.python 0xc700 PyObject_Call + 101 27 org.python.
[Pythonmac-SIG] PIL and Snow Leopard
On Oct 2, 2009, at 7:40 PM, Bill Janssen wrote: Jerry LeVan wrote: Is building PIL on Snow Leopard 'easy' I have the apple python (32/64) installed and the python.org 2.6.2 (32 bit) version installed. Yes, I just build it with /usr/bin/python, and it works fine. Assuming you have Xcode 3.2 installed. Bill Ugh, this is getting messy... I think that I have built libfreetype.dylib and libjpeg.dylib as i386 and x86_64 libs...at least that is what the file command asserts. I then built the PIL package using the system python in 64 bit mode and installed the rascal in the Apple python. All of the libs appear to be multi-architecture ppc, i386 and x86_64 When I run apple python in 64 bit mode I can run the PIL demos... If I restrict apple python to 32 bit mode all of the programs fail with a bus error. * I then tried to build PIL using the 2.6.2 python from python.org. 1) It would not build under gcc-4.2 I had to define CC=gcc-4.0 the build appeared to succeed and I installed the PIL system. 2) All of the demos failed... I noticed that _imagingtk.so was dynamically linked against the ActiveState Tcl/Tk that is installed in /Library/Frameworks/ Tcl.framework [mbp:/Library/Python/2.6/site-packages/PIL]$ otool -L _imagingtk.so _imagingtk.so: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.4) /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.4) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1) I suppose that I could hide the ActiveState versions by renaming the Frameworks... But even if I did that, how could I force setup.py to use the apple 8.4 tcl/tk system instead of the 'current' 8.5 system? Any suggestions as to how I can get PIL to work when apple python is in 32 bit mode? Any suggestions as to how I can build PIL using the 2.6.2 version of Python from python.org? This is getting ugly...too many impedance mismatches. Jerry A little more success to report. .. I hid the activestate tcl/tk frameworks in /Library/Frameworks and set CC to gcc-4.0 and rebuilt PIL and otool showed that _imagingtk.so was linked against the apple 8.4 Tcl/Tk system. So I installed the build and "tada" Imaging appears to be working in python.org version of python (2.6.2). So this leaves only the "why does apple python (2.6.1) not work when run in 32 bit mode but does in 64 bit mode" question open... Has anyone had success with PIL in this case? Thanks Jerry When I run the Apple Python in 32 bit mode I get a bus error at the same place when I try to display an image using PIL . Here is part of the dump. Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0028 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.tcltk.tklibrary 0x13a1850b Tk_GetImageMasterData + 17 1 com.tcltk.tklibrary 0x13a20cab Tk_FindPhoto + 37 2 _imagingtk.so 0x007faacf PyImagingPhotoPut + 95 3 com.tcltk.tcllibrary 0x138d3d64 TclInvokeStringCommand + 101 4 com.tcltk.tcllibrary0x00489977 Tcl_CreateInterp + 4919 5 com.tcltk.tcllibrary0x0048a96c Tcl_EvalObjv + 72 6 _tkinter.so 0x001e449d Tkapp_CallDeallocArgs + 11750 7 org.python.python 0x0008b372 PyEval_EvalFrameEx + 16375 8 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 9 org.python.python 0x0008b591 PyEval_EvalFrameEx + 16918 10 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 11 org.python.python 0x0002ee2c PyClassMethod_New + 1823 12 org.python.python 0xc700 PyObject_Call + 101 13 org.python.python 0x0001c12e PyClass_New + 1603 14 org.python.python 0xc700 PyObject_Call + 101 15 org.python.python 0x0008677a PyEval_CallObjectWithKeywords + 171 16 org.python.python 0x0001ba58 PyInstance_New + 290 17 org.python.python 0xc700 PyObject_Call + 101 18 org.python.python 0x0008c802 PyEval_EvalFrameEx + 21639 19 org.python.python 0x0008cf64 PyEval_EvalCodeEx + 1720 20 org.python.python 0x0002ee2c PyClassMethod_New + 1823 21 org.python.python 0xc700 PyObject_Call + 101 22 org.python.python 0x0001c12e PyClass_New + 1603 23 org.python.python 0xc700 PyObject_Call + 101 24 org.python.python 0x0008677a PyEval_CallObjectWithKeywords + 171 25 org.python.python 0x0001ba58 PyInstance_New + 290 26 org.python.python 0xc700 PyObject_Call + 101 27 org.python.pyth
