From Chris.Barker at noaa.gov Fri May 1 00:18:52 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 30 Apr 2009 15:18:52 -0700 Subject: [Pythonmac-SIG] py2app and ipython In-Reply-To: <43875141-6E49-4E8D-9004-B70B488BCB8C@cs.toronto.edu> References: <49F9E02C.4040903@noaa.gov> <8D4D601A-AAAF-4832-9971-9E07A99C8E7A@gmail.com> <43875141-6E49-4E8D-9004-B70B488BCB8C@cs.toronto.edu> Message-ID: <49FA23CC.7010405@noaa.gov> David Warde-Farley wrote: > You might also be interested in Nicolas Rougier's Glipy package, which > embeds IPython (and some other neat NumPy-related features) in an OpenGL > pseudo-terminal. I know the iPython folks have been doing a lot to make it embeddable in GUIs -- you could use the wxPython pyCrust, for example: http://www.wxpython.org/py.php not that I've tried any of this... -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.Barker at noaa.gov From hengist.podd at virgin.net Sat May 2 16:13:43 2009 From: hengist.podd at virgin.net (has) Date: Sat, 2 May 2009 15:13:43 +0100 Subject: [Pythonmac-SIG] py2app and ipython In-Reply-To: References: Message-ID: Thomas Robitaille wrote: > I am trying to use py2app to make a simple MacOS X application that > launches an ipython shell. Use AppleScript. Create a new script in Script Editor (/Applications/ AppleScript): tell application "Terminal" to do script "ipython" Save as 'Application Bundle' format. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From thomas.robitaille at gmail.com Sat May 2 16:52:18 2009 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 2 May 2009 10:52:18 -0400 Subject: [Pythonmac-SIG] py2app and ipython In-Reply-To: References: Message-ID: <33DFCE5B-0C17-40E9-B7EF-99AA40F95575@gmail.com> Hi, Thanks for the suggestion! The problem is that I want to be able to send this application to people who don't necessarily have python installed, which is why I was considering py2app in the first place. Script editor produces a 90k file which I doubt includes the necessary python dependencies! Cheers, Tom On 2 May 2009, at 10:13, has wrote: > Thomas Robitaille wrote: > >> I am trying to use py2app to make a simple MacOS X application that >> launches an ipython shell. > > > Use AppleScript. Create a new script in Script Editor (/Applications/ > AppleScript): > > tell application "Terminal" to do script "ipython" > > Save as 'Application Bundle' format. > > HTH > > has > > -- > Control AppleScriptable applications from Python, Ruby and ObjC: > http://appscript.sourceforge.net > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From eric.shain at gmail.com Sat May 2 17:27:47 2009 From: eric.shain at gmail.com (Eric Shain) Date: Sat, 2 May 2009 10:27:47 -0500 Subject: [Pythonmac-SIG] XCode 3 and newly installed Python version Message-ID: I'm new to this list (and lists in general) so please advise if I break any rules. I'm running OS X 10.5.6 and XCode 3. I've been advised to leave system's python installation alone and since I need to install packages, I've installed Python 2.6.2 which went in the ~/Library/Frameworks/Python.framework directory. I've also installed some packages there. While I can run Python scripts without a problem from Idle and Terminal, I'm having problems with XCode. I tried to build a Python - Cocoa application and did a Build and Go. I got the following error in the Console: *Traceback (most recent call last):* * File "main.py", line 10, in * * import objc* *ImportError: No module named objc* *2009-05-02 10:16:34.369 pyTest[1422:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '/Developer/Eric/pyTest/main.m:44 main() PyRun_SimpleFile failed with file '/Developer/Eric/pyTest/build/Debug/pyTest.app/Contents/Resources/main.py'. See console for errors.'* *2009-05-02 10:16:34.372 pyTest[1422:10b] Stack: (* * 2533839115,* * 2439867963,* * 2533838571,* * 2533838634* I'm assuming that the new version of Python is being used and that pyobjc isn't installed. Is the remedy to install pyobjc into the Python 2.6.2 installation? or are there other dependancies? Will "easy_install pyobjc" in terminal install the correct version (in the correct python)? Lastly, while I've a bit of experience in Python, I have little in XCode and Objective-C. I've worked through some tutorials, but I've not found a decent yet basic tutorial for doing a Python Cocoa application in XCode 3. Apple's tutorial is for XCode 2 and enough seems to have changed that I have trouble following it. All I really want to do now is create a simple UI, and receive a string from a text field and send result text to another text field or label. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From donmcgr17 at gmail.com Sun May 3 18:57:50 2009 From: donmcgr17 at gmail.com (Don McGuire) Date: Sun, 3 May 2009 12:57:50 -0400 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook Message-ID: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> Hi: I am attempting to build an application that uses the built-in Apple Help system to display my html help files. I'm getting a Mac OS Error -50, which corresponds to "Error in user parameter list." Here's what I've done thus far: 1. Info.plist has the following entries: CFBundleHelpBookFolder help CFBundleHelpBookName MyAppName Help My html files are in a directory called "help", and my top-level help doc has the Apple metatag "MyAppName Help". 2. In the initializing routine of my app, I have the following lines: from Carbon import AH app = os.path.dirname(os.path.dirname(sys.prefix)) AH.AHRegisterHelpBook(app) #This line causes Mac OS Error -50 The application is a wxpython gui and I'm using py2app to build it. Everything works like a champ, except for the help system. Thank you for your time, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From donmcgr17 at gmail.com Sun May 3 22:53:45 2009 From: donmcgr17 at gmail.com (Don McGuire) Date: Sun, 3 May 2009 16:53:45 -0400 Subject: [Pythonmac-SIG] AutoComplete in C++ Editor for Python In-Reply-To: <49FDED05.5080802@ieee.org> References: <49FDED05.5080802@ieee.org> Message-ID: <4bb0ef5b0905031353j366a6cdds6e9ac8a01d4efd58@mail.gmail.com> flamz3d at gmail.com wrote: > >> Hello, >> I am embedding python support in my C++ application and was looking at >> adding "Intellisense" or "AutoComplete" support. >> >> I found a way to do it using the "dir" function, but this creates a >> problem. Here's why. Let's say I have the following code in my editor: >> >> import sys >> x = sys >> >> >> Now, I would like to get all attributes of the object called 'x'. I >> can "instrument" the code and add "print dir(x)" at the end, >> temporarily redirect the python output to a string and execute the >> code. >> >> But this is not safe: I do NOT want to execute the code while the user >> is typing! >> >> Is there a way to "compile" the python code and get access to the >> symbol table from that compiled block? >> >> Did anybody ever implement AutoComplete in a editor for Python? >> >> cheers. >> > I implemented autocomplete in my application by using the exec() function to load a namespace. To demonstrate, type the following into the interpreter: txt = "x = 'hello'\nprint x" exec(txt) You will get "hello" to print out. Not good. How about this? txt = "def say_hello():\n\tx = 'hello'\n\tprint x" exec(txt) Nothing happens. Because the print statement is inside the function say_hello(), exec() just loads the function into the globals() namespace. Now type: say_hello() "Hello" prints out. To answer your question, executing code is not necessarily a bad thing. Calling exec() on our function just loaded it into the globals namespace, where you can use introspection on the objects contained therein. None of the statements in the function were executed. My autocomplete system uses exec() on the user scripts to load a namespace. But before that occurs, the system checks for top-level statements that would execute. Assignment statements are usually pretty safe: exec("x = 42") is a pretty safe statement. Top-level calls to functions are bad: exec('launch_missiles()') would in fact launch the missiles. Remove any lines that have top-level function calls. Or you can create your own mini-parser, which I considered but thought it would be too much work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kw at codebykevin.com Sun May 3 23:23:26 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 03 May 2009 17:23:26 -0400 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> <49FE05AA.6030005@codebykevin.com> <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> Message-ID: <49FE0B4E.80008@codebykevin.com> Don McGuire wrote: > > I checked the Python 3.0 docs: all Carbon modules are removed, as you > stated. So to launch the Help viewer nowadays, are you making calls to > Cocoa? Or are you just launching the default web browser and skipping the > Help viewer altogether? > User help is one of the trickiest things to get right, I've found. Both Apple's help viewer and the browser present issues. My own solution is documented here: http://www.codebykevin.com/blosxom.cgi/2009/03/09#user-help Not all parts of this are relevant, since I'm using Tkinter and bumping up against Tk's limited support for displaying HTML, but it will give you an idea of the issues. Since you're using wxPython, can't you just call either the wxHelp API (a bit complicated if I recall correctly) or simply create a simple HTML viewer? I think something like that is in the wxPython demo code. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From kw at codebykevin.com Sun May 3 23:29:36 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 03 May 2009 17:29:36 -0400 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> <49FE05AA.6030005@codebykevin.com> <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> Message-ID: <49FE0CC0.1060402@codebykevin.com> Don McGuire wrote: > I checked the Python 3.0 docs: all Carbon modules are removed, as you > stated. So to launch the Help viewer nowadays, are you making calls to > Cocoa? Or are you just launching the default web browser and skipping the > Help viewer altogether? > You can also open the Help Viewer directly with something like this: os.system('open -a Help Viewer.app /path/to/help.html') -- Kevin Walzer Code by Kevin http://www.codebykevin.com From kw at codebykevin.com Sun May 3 22:59:22 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 03 May 2009 16:59:22 -0400 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> Message-ID: <49FE05AA.6030005@codebykevin.com> Don McGuire wrote: > Hi: > > I am attempting to build an application that uses the built-in Apple Help > system to display my html help files. I'm getting a Mac OS Error -50, which > corresponds to "Error in user parameter list." Here's what I've done thus > far: > > 1. Info.plist has the following entries: > CFBundleHelpBookFolder > help > CFBundleHelpBookName > MyAppName Help > > My html files are in a directory called "help", and my top-level help doc > has the Apple metatag "MyAppName Help". > > 2. In the initializing routine of my app, I have the following lines: > from Carbon import AH > app = os.path.dirname(os.path.dirname(sys.prefix)) > AH.AHRegisterHelpBook(app) #This line causes Mac OS Error -50 > > The application is a wxpython gui and I'm using py2app to build it. > Everything works like a champ, except for the help system. > > Thank you for your time, > Don > I used to use this function in my Python apps, but moved away from it after it became clear that the MacOS/Carbon bits were being deprecated. I believe they have been removed altogether from 3.0. Searching for AH.AHRegisterHelpBook() on codesearch.google.com yields some useful hits. I based my code on some snippets used there (the PythonIDE stuff, in particular). -- Kevin Walzer Code by Kevin http://www.codebykevin.com From Chris.Barker at noaa.gov Mon May 4 18:33:00 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 04 May 2009 09:33:00 -0700 Subject: [Pythonmac-SIG] AutoComplete in C++ Editor for Python In-Reply-To: <4bb0ef5b0905031353j366a6cdds6e9ac8a01d4efd58@mail.gmail.com> References: <49FDED05.5080802@ieee.org> <4bb0ef5b0905031353j366a6cdds6e9ac8a01d4efd58@mail.gmail.com> Message-ID: <49FF18BC.5040002@noaa.gov> Don McGuire wrote: >>> Is there a way to "compile" the python code and get access to the >>> symbol table from that compiled block? >>> >>> Did anybody ever implement AutoComplete in a editor for Python? You might want to try the pyXIDEs list -- this certainly isn't a Mac-specific question: pyxides at googlegroups.com An anycase, there are some open-source tools that do AutoComplete, I"d look for them and look at their code. And you can compile to code to .pyc files without running it, and there are tools to examine the results. I've never done any of that, you might want to try comp.lang.python. In the meantime, check out these functions and modules: compile() compiler code codeop HTH, -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.Barker at noaa.gov From Chris.Barker at noaa.gov Mon May 4 18:38:45 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 04 May 2009 09:38:45 -0700 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <49FE0B4E.80008@codebykevin.com> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> <49FE05AA.6030005@codebykevin.com> <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> <49FE0B4E.80008@codebykevin.com> Message-ID: <49FF1A15.60300@noaa.gov> Kevin Walzer wrote: > Not all parts of this are relevant, since I'm using Tkinter and bumping > up against Tk's limited support for displaying HTML, but it will give > you an idea of the issues. > > Since you're using wxPython, can't you just call either the wxHelp API > (a bit complicated if I recall correctly) or simply create a simple HTML > viewer? I think something like that is in the wxPython demo code. With wx, there are two good options for doing your own HTML help: use wxHTML -- this is simple and fast, and I think there is a help-browsing app built in wxPython already, for the wxPython help. The downside is that it does not support modern HTML (i.e. CSS, etc). If you want full-on HTML, you can embed the system browser -- on the Mac, that's the webkitctrl -- it works pretty well. In the future, I hope wxWebKit will be robust enough to use -- it may be now for things like basic help -- that would give you full cross platform control over the browser component. Of course, just pointing the system browser at your help is quick and easy. -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.Barker at noaa.gov From Chris.Barker at noaa.gov Mon May 4 19:51:52 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 04 May 2009 10:51:52 -0700 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <49FF1A15.60300@noaa.gov> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> <49FE05AA.6030005@codebykevin.com> <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> <49FE0B4E.80008@codebykevin.com> <49FF1A15.60300@noaa.gov> Message-ID: <49FF2B38.4090303@noaa.gov> Christopher Barker wrote: > use wxHTML -- this is simple and fast, and I think there is a > help-browsing app built in wxPython already, here it is: wx.html.HtmlHelpController -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.Barker at noaa.gov From ronaldoussoren at mac.com Wed May 6 17:13:21 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 06 May 2009 17:13:21 +0200 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: <49FF1A15.60300@noaa.gov> References: <4bb0ef5b0905030957u6bf54970wed732928dff4b948@mail.gmail.com> <49FE05AA.6030005@codebykevin.com> <4bb0ef5b0905031412t5f51c4b9ha3d4310ebb7ef4cb@mail.gmail.com> <49FE0B4E.80008@codebykevin.com> <49FF1A15.60300@noaa.gov> Message-ID: On 4 May, 2009, at 18:38, Christopher Barker wrote: > Kevin Walzer wrote: >> Not all parts of this are relevant, since I'm using Tkinter and >> bumping up against Tk's limited support for displaying HTML, but it >> will give you an idea of the issues. >> Since you're using wxPython, can't you just call either the wxHelp >> API (a bit complicated if I recall correctly) or simply create a >> simple HTML viewer? I think something like that is in the wxPython >> demo code. > > With wx, there are two good options for doing your own HTML help: > > use wxHTML -- this is simple and fast, and I think there is a help- > browsing app built in wxPython already, for the wxPython help. The > downside is that it does not support modern HTML (i.e. CSS, etc). > > If you want full-on HTML, you can embed the system browser -- on the > Mac, that's the webkitctrl -- it works pretty well. > > In the future, I hope wxWebKit will be robust enough to use -- it > may be now for things like basic help -- that would give you full > cross platform control over the browser component. > > Of course, just pointing the system browser at your help is quick > and easy. Another option is PyObjC, it definitly allows you to integrate with the native Cocoa help API's. Ronald > > -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.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Thu May 7 20:13:36 2009 From: hengist.podd at virgin.net (has) Date: Thu, 7 May 2009 19:13:36 +0100 Subject: [Pythonmac-SIG] Using AHRegisterHelpBook In-Reply-To: References: Message-ID: <03F49B4E-580A-4263-A0A4-BE4B88D97F04@virgin.net> Ronald Oussoren wrote: > Another option is PyObjC, it definitly allows you to integrate with > the native Cocoa help API's. Out of interest, does PyObjC play nicely with wxPython/Tkinter? A further option, if it hasn't already been suggested, would be to call AHRegisterHelpBook directly via ctypes. Just because Python's Mac modules have all been deprecated and removed doesn't mean that all of the underlying OS X APIs have done the same. Some have (e.g. QuickTime, QuickDraw, and anything GUI-related are best avoided) but others are still fully supported. Or, if futzing with ctypes is too much hassle, consider grabbing the source for the Carbon.AH extension and repackage it as part of the project. This is what I did with Carbon.AE when developing appscript, for example. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From kw at codebykevin.com Thu May 7 23:53:53 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Thu, 07 May 2009 17:53:53 -0400 Subject: [Pythonmac-SIG] Leaning PyObjC Message-ID: <4A035871.70909@codebykevin.com> Hi all, What's the current "best practice" for learning PyObjC? I've been developing in Python/Tkinter for quite some time, and I've learned enough Objective-C/Cocoa to create a small extension that calls into some Cocoa methods (it's actually a Tcl extension that I can call, via Tkinter, to change my app's dock icon). I'm planning to work through some samples in the latest Hillegass book to get familiar with the full Cocoa toolchain, i.e. Xcode, IB, etc.) I'm finding myself a bit lost, however, in how to download, build, and play with PyObjC itself. Based on what I've gathered from the PyObjC site, I can do the following: 1. Download version 2.0 from SVN or use easy_install 2.2b. 2. Build as outlined in the instructions. 3. Follow the "Creating your first PyObjc application" tutorial, which requires PyObjC 1.3.1. I'm especially curious about the tutorial--is it up to date? I've read a lot about changes between PyObjC 1.x and 2.x, but it's not clear to me what those changes are. I do know that the differences between older Cocoa tutorials (pre-Leopard) and new tutorials are big enough to make it hard to learn from the old ones, owing especially to big changes in Interface Builder. My strong preference is to keep my Python toolchain reasonably close to what I'm doing already, i.e. doing my development outside of Xcode and using py2app for bundling, rather than using Xcode. Does this sound like a good approach, or am I missing something glaringly obvious? What do others who are shipping PyObjC apps do? --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From janssen at parc.com Fri May 8 00:24:21 2009 From: janssen at parc.com (Bill Janssen) Date: Thu, 7 May 2009 15:24:21 PDT Subject: [Pythonmac-SIG] Leaning PyObjC In-Reply-To: <4A035871.70909@codebykevin.com> References: <4A035871.70909@codebykevin.com> Message-ID: <15823.1241735061@parc.com> Kevin Walzer wrote: > My strong preference is to keep my Python toolchain reasonably close > to what I'm doing already, i.e. doing my development outside of Xcode > and using py2app for bundling, rather than using Xcode. I found crossing this bridge a bit tricky, until I embraced Xcode. Start a Python-Cocoa project with Xcode. Look at the framework it builds for you. Go on and edit your app delegate, not necessarily using Xcode. Hit the "Build and Run" button in Xcode. See what happens. Repeat. After you've successfully built a couple of Python apps this way, you'll be better prepared to get into the whole py2app thing. The major problem there is that the folks who build and maintain it are overworked, and have little to no time to update documentation. So there are lots of out-of-date documentation pages and examples, which will mislead you mightily unless you have some other grounding to fall back on to see if they make sense. Even then, I have to admit I still don't know how to build a PreferencePane from scratch. I've got one working, but I had to take the example, and hack it into shape. Oh, and read Will Larson's series: http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/ all the way through. Bill From ed_hartley at mac.com Fri May 8 12:07:00 2009 From: ed_hartley at mac.com (Edward Hartley) Date: Fri, 08 May 2009 11:07:00 +0100 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 73, Issue 7 In-Reply-To: References: Message-ID: <188D85C9-0CD5-499C-B924-1E58ADEC3DE5@mac.com> On 8 May 2009, at 11:00, pythonmac-sig-request at python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request at python.org > > You can reach the person managing the list at > pythonmac-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. Re: Using AHRegisterHelpBook (has) > 2. Leaning PyObjC (Kevin Walzer) > 3. Re: Leaning PyObjC (Bill Janssen) > > From: has > Date: 7 May 2009 19:13:36 BST > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Using AHRegisterHelpBook > > > Ronald Oussoren wrote: > >> Another option is PyObjC, it definitly allows you to integrate with >> the native Cocoa help API's. > > > Out of interest, does PyObjC play nicely with wxPython/Tkinter? > You obviously can't mix GUI toolkits but you can use other PyObjC API's with Tkinter and wxPython. However the GIL needs consideration. Also I found some of the older bridging API's defunct when I tried to use them, particularly quicktime. But it has been a while since I looked at this. > A further option, if it hasn't already been suggested, would be to > call AHRegisterHelpBook directly via ctypes. Just because Python's > Mac modules have all been deprecated and removed doesn't mean that > all of the underlying OS X APIs have done the same. Some have (e.g. > QuickTime, QuickDraw, and anything GUI-related are best avoided) but > others are still fully supported. > > Or, if futzing with ctypes is too much hassle, consider grabbing the > source for the Carbon.AH extension and repackage it as part of the > project. This is what I did with Carbon.AE when developing > appscript, for example. > > HTH > > has > -- > Control AppleScriptable applications from Python, Ruby and ObjC: > http://appscript.sourceforge.net > > > > > > From: Kevin Walzer > Date: 7 May 2009 22:53:53 BST > To: pythonmac-sig at python.org > Subject: [Pythonmac-SIG] Leaning PyObjC > Reply-To: kw at codebykevin.com > > > Hi all, > > What's the current "best practice" for learning PyObjC? I've been > developing in Python/Tkinter for quite some time, and I've learned > enough Objective-C/Cocoa to create a small extension that calls into > some Cocoa methods (it's actually a Tcl extension that I can call, > via Tkinter, to change my app's dock icon). I'm planning to work > through some samples in the latest Hillegass book to get familiar > with the full Cocoa toolchain, i.e. Xcode, IB, etc.) > > I'm finding myself a bit lost, however, in how to download, build, > and play with PyObjC itself. Based on what I've gathered from the > PyObjC site, I can do the following: > > 1. Download version 2.0 from SVN or use easy_install 2.2b. > 2. Build as outlined in the instructions. > 3. Follow the "Creating your first PyObjc application" tutorial, > which requires PyObjC 1.3.1. > > I'm especially curious about the tutorial--is it up to date? I've > read a lot about changes between PyObjC 1.x and 2.x, but it's not > clear to me what those changes are. I do know that the differences > between older Cocoa tutorials (pre-Leopard) and new tutorials are > big enough to make it hard to learn from the old ones, owing > especially to big changes in Interface Builder. > > My strong preference is to keep my Python toolchain reasonably close > to what I'm doing already, i.e. doing my development outside of > Xcode and using py2app for bundling, rather than using Xcode. > > Does this sound like a good approach, or am I missing something > glaringly obvious? What do others who are shipping PyObjC apps do? > > --Kevin > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > > > > From: Bill Janssen > Date: 7 May 2009 23:24:21 BST > To: kw at codebykevin.com > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Leaning PyObjC > > > Kevin Walzer wrote: > >> My strong preference is to keep my Python toolchain reasonably close >> to what I'm doing already, i.e. doing my development outside of Xcode >> and using py2app for bundling, rather than using Xcode. > > I found crossing this bridge a bit tricky, until I embraced Xcode. > Start a Python-Cocoa project with Xcode. Look at the framework it > builds for you. Go on and edit your app delegate, not necessarily > using > Xcode. Hit the "Build and Run" button in Xcode. See what happens. > Repeat. > > After you've successfully built a couple of Python apps this way, > you'll > be better prepared to get into the whole py2app thing. The major > problem there is that the folks who build and maintain it are > overworked, and have little to no time to update documentation. So > there are lots of out-of-date documentation pages and examples, which > will mislead you mightily unless you have some other grounding to fall > back on to see if they make sense. > > Even then, I have to admit I still don't know how to build a > PreferencePane from scratch. I've got one working, but I had to take > the example, and hack it into shape. > > Oh, and read Will Larson's series: > > http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/ > > all the way through. > > Bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed May 13 18:41:56 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 13 May 2009 09:41:56 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed Message-ID: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian From janssen at parc.com Wed May 13 19:39:31 2009 From: janssen at parc.com (Bill Janssen) Date: Wed, 13 May 2009 10:39:31 PDT Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> Message-ID: <5402.1242236371@parc.com> The Mac comes with a Framework build of Python pre-installed (and with PyObjC pre-installed, which you also need). Just use /usr/bin/python, and you'll be fine. It's the default way that Python builds on a Mac, too. Bill Brian Granger wrote: > Hi, > > I seem to recall that a Framework build of Python is needed if you > want to do anything with the native Mac GUI. Is my understanding > correct? If so, is this requirement documented somewhere? > > Thanks! > > Brian > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed May 13 22:34:37 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 13 May 2009 13:34:37 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <5402.1242236371@parc.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> Message-ID: <4A0B2EDD.6070403@noaa.gov> > Brian Granger wrote: >> I seem to recall that a Framework build of Python is needed if you >> want to do anything with the native Mac GUI. Is my understanding >> correct? Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. The Framework build supplies that. Technically, the use of a framework is independent for this requirement, but using a Framework build is the easiest way to satisfy it. Do you have a reason for not wanting to use a Framework build? -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.Barker at noaa.gov From ellisonbg.net at gmail.com Thu May 14 00:23:49 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 13 May 2009 15:23:49 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <4A0B2EDD.6070403@noaa.gov> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> <4A0B2EDD.6070403@noaa.gov> Message-ID: <6ce0ac130905131523m7c4002e9i18816fd6dad37eb9@mail.gmail.com> > Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac > application bundle. The Framework build supplies that. Technically, the use > of a framework is independent for this requirement, but using a Framework > build is the easiest way to satisfy it. OK. > Do you have a reason for not wanting to use a Framework build? Some people I am working with feel that doing a framework build is a bit of a hassle. It means they/we have to support custom build logic on OS X compared to linux/unix, which I agree is a pain. But there are no fundamental reasons we are opposed to a Framework build. Just a bit more work for us. Cheers, Brian From janssen at parc.com Thu May 14 01:03:16 2009 From: janssen at parc.com (Bill Janssen) Date: Wed, 13 May 2009 16:03:16 PDT Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <4A0B2EDD.6070403@noaa.gov> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> <4A0B2EDD.6070403@noaa.gov> Message-ID: <15498.1242255796@parc.com> Christopher Barker wrote: > > > Brian Granger wrote: > > >> I seem to recall that a Framework build of Python is needed if you > >> want to do anything with the native Mac GUI. Is my understanding > >> correct? > > Pretty much -- to access the Mac GUI, an app needs to be in a proper > Mac application bundle. But there's no pressing reason Python has to supply that bundle. You could build your own app using PyObjC to access the Cocoa GUI, using Python without a Python app bundle. The two things are logically separate, aren't they? You can have a framework build of Python without having a Python application bundle. I suspect that the default build of PyObjC assumes that Python is a framework build, too. But I don't know if you could build a non-framework Python and non-framework PyObjC, and use those together to write Python programs that could access Cocoa. I suspect you could, but I also suspect it would be a lot of work. Bill From nad at acm.org Thu May 14 02:57:37 2009 From: nad at acm.org (Ned Deily) Date: Wed, 13 May 2009 17:57:37 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> <4A0B2EDD.6070403@noaa.gov> <6ce0ac130905131523m7c4002e9i18816fd6dad37eb9@mail.gmail.com> Message-ID: In article <6ce0ac130905131523m7c4002e9i18816fd6dad37eb9 at mail.gmail.com>, Brian Granger wrote: > > Do you have a reason for not wanting to use a Framework build? > Some people I am working with feel that doing a framework build is a > bit of a hassle. It means they/we have to support custom build logic > on OS X compared to linux/unix, which I agree is a pain. But there > are no fundamental reasons we are opposed to a Framework build. Just > a bit more work for us. FWIW, if you are building and installing python modules and/or C extensions, distutils or setuptools should generally be able to transparently handle the framework-specific details for you. -- Ned Deily, nad at acm.org From nad at acm.org Thu May 14 03:06:54 2009 From: nad at acm.org (Ned Deily) Date: Wed, 13 May 2009 18:06:54 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> <4A0B2EDD.6070403@noaa.gov> <15498.1242255796@parc.com> Message-ID: In article <15498.1242255796 at parc.com>, Bill Janssen wrote: > I suspect that the default build of PyObjC assumes that Python is a > framework build, too. But I don't know if you could build a > non-framework Python and non-framework PyObjC, and use those together to > write Python programs that could access Cocoa. I suspect you could, but > I also suspect it would be a lot of work. FWIW, fink uses a "unix shared" library build rather than a framework build for its pythons (at least the 2.5 version I have) and has PyObjC packages for them. I haven't tried to install them and have no idea how well they work. -- Ned Deily, nad at acm.org From janssen at parc.com Thu May 14 04:31:25 2009 From: janssen at parc.com (Bill Janssen) Date: Wed, 13 May 2009 19:31:25 PDT Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> Message-ID: <19405.1242268285@parc.com> I think this depends on what you think the "native Mac GUI" is, and what you want to do with it. For instance, a non-framework build, combined with Xlib (http://python-xlib.sourceforge.net/) works quite well with the Apple X11 server, which in turn uses the native Mac GUI. Bill Brian Granger wrote: > Hi, > > I seem to recall that a Framework build of Python is needed if you > want to do anything with the native Mac GUI. Is my understanding > correct? If so, is this requirement documented somewhere? > > Thanks! > > Brian > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Thu May 14 09:19:03 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 14 May 2009 09:19:03 +0200 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <15498.1242255796@parc.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <5402.1242236371@parc.com> <4A0B2EDD.6070403@noaa.gov> <15498.1242255796@parc.com> Message-ID: <6B4A9DED-0F83-4085-8271-D4056C81C12A@mac.com> On 14 May, 2009, at 1:03, Bill Janssen wrote: > Christopher Barker wrote: > >> >>> Brian Granger wrote: >> >>>> I seem to recall that a Framework build of Python is needed if you >>>> want to do anything with the native Mac GUI. Is my understanding >>>> correct? >> >> Pretty much -- to access the Mac GUI, an app needs to be in a proper >> Mac application bundle. > > But there's no pressing reason Python has to supply that bundle. You > could build your own app using PyObjC to access the Cocoa GUI, using > Python without a Python app bundle. The two things are logically > separate, aren't they? You can have a framework build of Python > without > having a Python application bundle. > > I suspect that the default build of PyObjC assumes that Python is a > framework build, too. But I don't know if you could build a > non-framework Python and non-framework PyObjC, and use those > together to > write Python programs that could access Cocoa. I suspect you could, > but > I also suspect it would be a lot of work. And more importantly: most other users use a framework, as well as all py2app and pyobjc developers. That means that you're more likely to run into problems using a non-framework installation of Python, and that you'll get less help when you do. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Thu May 14 09:23:41 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 14 May 2009 09:23:41 +0200 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <19405.1242268285@parc.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> Message-ID: On 14 May, 2009, at 4:31, Bill Janssen wrote: > I think this depends on what you think the "native Mac GUI" is, and > what > you want to do with it. For instance, a non-framework build, combined > with Xlib (http://python-xlib.sourceforge.net/) works quite well with > the Apple X11 server, which in turn uses the native Mac GUI. This is totally off-topic, but I don't think an X11 based UI is a "native Mac GUI". Anything that's a native GUI should at least conform to the usual UI conventions of OSX, such as a per-application menu instead of per windows menu's. And to be honest, I even have doubts about a toolkit such as Tk which uses native widgets but has a rather un-mac feeling unless the developer really knows what he's doing. That explains why IDLE looks ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib doesn't even ship with all components that are needed to get a proper native L&F with Tkinter. Ronald > > Bill > > Brian Granger wrote: > >> Hi, >> >> I seem to recall that a Framework build of Python is needed if you >> want to do anything with the native Mac GUI. Is my understanding >> correct? If so, is this requirement documented somewhere? >> >> Thanks! >> >> Brian >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From kw at codebykevin.com Thu May 14 14:15:15 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Thu, 14 May 2009 08:15:15 -0400 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> Message-ID: <4A0C0B53.9060904@codebykevin.com> Ronald Oussoren wrote: > And to be honest, I even have doubts about a toolkit such as Tk which > uses native widgets but has a rather un-mac feeling unless the developer > really knows what he's doing. That explains why IDLE looks ugly on OSX, > I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib > doesn't even ship with all components that are needed to get a proper > native L&F with Tkinter. > Ronald, You've done terrific work getting IDLE to work with OS X. A lot of the work that needs to be done with IDLE modernizing its interface simply can't be done at a platform-specific level. There are two interesting developments that will affect Tkinter in the near future: 1. The ttk themed widgets will now be part of the Python standard library starting with 2.7 and 3.1 (http://gpolo.ath.cx:81/projects/pyttk/). Guilherme Polo did this as a GSoC project. I believe IDLE will be using the new widgets as well. That will help a great deal. 2. A port of Tk to run on top of Cocoa instead of Carbon by Tk-Aqua's maintainer, Daniel Steffen (with support from Apple), is now substantially complete: see http://github.com/das/tcltk/tree/de-carbon-8-5. It's still currently a fork/branch of the main Tk development, and probably won't be committed to the main line until later (perhaps Tk 8.6, which may not be out for another year), but it works beautifully. I'm currently testing a four-way universal build of Python and Tk-Cocoa. IDLE looks a bit weird because of some menu layout issues (there are a few differences between Tk-Carbon and Tk-Cocoa), but those can be adjusted with some patches--I may work some up at the appropriate time. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From janssen at parc.com Thu May 14 17:53:17 2009 From: janssen at parc.com (Bill Janssen) Date: Thu, 14 May 2009 08:53:17 PDT Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> Message-ID: <24088.1242316397@parc.com> Ronald Oussoren wrote: > On 14 May, 2009, at 4:31, Bill Janssen wrote: > > > I think this depends on what you think the "native Mac GUI" is, and > > what > > you want to do with it. For instance, a non-framework build, combined > > with Xlib (http://python-xlib.sourceforge.net/) works quite well with > > the Apple X11 server, which in turn uses the native Mac GUI. > > This is totally off-topic, but I don't think an X11 based UI is a > "native Mac GUI". Anything that's a native GUI should at least conform > to the usual UI conventions of OSX, such as a per-application menu > instead of per windows menu's. > > And to be honest, I even have doubts about a toolkit such as Tk which > uses native widgets but has a rather un-mac feeling unless the > developer really knows what he's doing. That explains why IDLE looks > ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK > Python's stdlib doesn't even ship with all components that are needed > to get a proper native L&F with Tkinter. Yes, I agree with all that -- anything non-Cocoa isn't "real". I was just wondering what the OP meant by "native Mac GUI". Though we could have lots of fun arguing about whether the X11 server provides access to the native Mac GUI... :-). Bill From Chris.Barker at noaa.gov Thu May 14 19:14:13 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 14 May 2009 10:14:13 -0700 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <24088.1242316397@parc.com> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> <24088.1242316397@parc.com> Message-ID: <4A0C5165.7010901@noaa.gov> Brian Granger wrote: > Some people I am working with feel that doing a framework build is a > bit of a hassle. It means they/we have to support custom build logic > on OS X compared to linux/unix, which I agree is a pain. no matter how you slice, it you will have to do some custom support for OS-X if you want anything resembling a native Mac app. I suspect the framework build will be the least of it. You may not have to build your own Python anyway, and as was pointed out, extensions should be built with distutils, which will work the same on all platforms. The far bigger hassles come from trying to support Universal binaries, if you need to do that, and depend on other libs not supplied by Apple. Bill Janssen wrote: > But there's no pressing reason Python has to supply that bundle. > could build your own app using PyObjC to access the Cocoa GUI, using > Python without a Python app bundle. Can you? Isn't a PyObjC app using the Python executable as the "main" app, just like any other python program? You could write a ObjC app, and embed python, if that's what you mean, but that's harder, too. > The two things are logically > separate, aren't they? You can have a framework build of Python without > having a Python application bundle. yes, they are, but I think if you do a standard unix build, you don't get the application bundle -- not that you couldn't' create it yourself somehow, but the point here was to make it easier, no harder.... > I suspect that the default build of PyObjC assumes that Python is a > framework build, too. I'm not sure it's relevant, but it won't work without out it. I'm no PyObjC expert, but, for instance, you can run wxPython with the non-bundle python, it just won't work (the point being that there is no difference in wxPython itself). That's why there used to be two pythons: "python" and "pythonw", "pythonw" being required for GUI access. Ned Deily wrote: > FWIW, fink uses a "unix shared" library build rather than a framework > build for its pythons (at least the 2.5 version I have) and has PyObjC > packages for them. I haven't tried to install them and have no idea how > well they work. A few years back, you could only do X11 GUIs with fink python -- maybe they have changed that? Bill Janssen wrote: > I think this depends on what you think the "native Mac GUI" is, and what > you want to do with it. For instance, a non-framework build, combined > with Xlib (http://python-xlib.sourceforge.net/) works quite well with > the Apple X11 server, which in turn uses the native Mac GUI. That's because it's the X11 server that is accessing the "native Mac GUI", not your app directly. But I don't think anyone is thinking X when they say "native" Mac GUI -- in fact, I think the entire point of using the term native is to distinguish between X and Carbon/Cocoa. Ronald Oussoren wrote: > And to be honest, I even have doubts about a toolkit such as Tk which > uses native widgets but has a rather un-mac feeling I don't think TK does use native widgets -- it certainly didn't used to. It was originally built for X11, and got ported to other platforms by emulating the X11 drawing calls, still drawing its own widgets. I know they've added support for native standard dialogs, like the file dialog, but I think a great deal is still self drawn. As opposed to wx, that does use the native widgets wherever possible. > doesn't even ship with all components that are needed to get a proper > native L&F with Tkinter. I think a proper native L&F is simple impossible with Tk Kevin Walzer wrote: > You've done terrific work getting IDLE to work with OS X. A lot of the > work that needs to be done with IDLE modernizing its interface simply > can't be done at a platform-specific level. but wouldn't making it more OS-Xish require platform specific modification? Or do you mean the the toolkit itself has to support that level of platform customization? Anyway, it's nice to see TK getting attention, particularly on the Mac. Bill Janssen wrote: > Yes, I agree with all that -- anything non-Cocoa isn't "real". I think Carbon is still real -- though it is on its way out... -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.Barker at noaa.gov From janssen at parc.com Thu May 14 19:48:15 2009 From: janssen at parc.com (Bill Janssen) Date: Thu, 14 May 2009 10:48:15 PDT Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <4A0C5165.7010901@noaa.gov> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> <24088.1242316397@parc.com> <4A0C5165.7010901@noaa.gov> Message-ID: <26583.1242323295@parc.com> Christopher Barker wrote: > > could build your own app using PyObjC to access the Cocoa GUI, using > > Python without a Python app bundle. > > Can you? Isn't a PyObjC app using the Python executable as the "main" > app, just like any other python program? Yes, using the Python executable. But if you start with Xcode, and create a Python-Cocoa application, what you get is a separate app that's composed of a shim layer in Objective-C which starts up an embedded Python interpreter and runs "main.py" in that interpreter. That's what I was talking about. > You could write a ObjC app, > and embed python, if that's what you mean, but that's harder, too. Not when Xcode does it for you. > > The two things are logically > > separate, aren't they? You can have a framework build of Python without > > having a Python application bundle. > > yes, they are, but I think if you do a standard unix build, you don't > get the application bundle That's right. > > I suspect that the default build of PyObjC assumes that Python is a > > framework build, too. > > I'm not sure it's relevant, but it won't work without out it. I'm no > PyObjC expert, but, for instance, you can run wxPython with the > non-bundle python, it just won't work (the point being that there is > no difference in wxPython itself). That's why there used to be two > pythons: "python" and "pythonw", "pythonw" being required for GUI > access. At the very least, you'd probably have to re-build wxPython against the non-framework Python, which seems like a lot of work. > Bill Janssen wrote: > > I think this depends on what you think the "native Mac GUI" is, and what > > you want to do with it. For instance, a non-framework build, combined > > with Xlib (http://python-xlib.sourceforge.net/) works quite well with > > the Apple X11 server, which in turn uses the native Mac GUI. > > That's because it's the X11 server that is accessing the "native Mac > GUI", not your app directly. But I don't think anyone is thinking X > when they say "native" Mac GUI -- in fact, I think the entire point of > using the term native is to distinguish between X and Carbon/Cocoa. Even Carbon's not native, IMO! But X does draw on its windows using Carbon -- it's just at arm's reach :-). > Ronald Oussoren wrote: > > And to be honest, I even have doubts about a toolkit such as Tk > > which uses native widgets but has a rather un-mac feeling > > I don't think TK does use native widgets -- it certainly didn't used > to. It was originally built for X11, and got ported to other platforms > by emulating the X11 drawing calls, still drawing its own widgets. I > know they've added support for native standard dialogs, like the file > dialog, but I think a great deal is still self drawn. The Tk canvas has alway seemed to me a nice appropriation of Joel Bartlett's most excellent ezd system (http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.html). But it's really 80's technology, so far as GUI toolkits go. > Bill Janssen wrote: > > Yes, I agree with all that -- anything non-Cocoa isn't "real". > > I think Carbon is still real -- though it is on its way out... We could have a holy war about that :-). Bill From kw at codebykevin.com Thu May 14 23:46:55 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Thu, 14 May 2009 17:46:55 -0400 Subject: [Pythonmac-SIG] Why is Framework build of Python needed In-Reply-To: <4A0C5165.7010901@noaa.gov> References: <6ce0ac130905130941u6b6352b0hb3eab5f7f85339e6@mail.gmail.com> <19405.1242268285@parc.com> <24088.1242316397@parc.com> <4A0C5165.7010901@noaa.gov> Message-ID: <4A0C914F.5010601@codebykevin.com> Christopher Barker wrote: > > I don't think TK does use native widgets -- it certainly didn't used to. > It was originally built for X11, and got ported to other platforms by > emulating the X11 drawing calls, still drawing its own widgets. I know > they've added support for native standard dialogs, like the file dialog, > but I think a great deal is still self drawn. > > As opposed to wx, that does use the native widgets wherever possible. Tk does use an X11 emulation layer for things like window management, drawing of graphics (such as polygons on the canvas widget), keyboard events, etc., but these functions are all mapped to native API's (CoreGraphics, Carbon, etc.). As well, core widgets such as the menu, buttons, scrollbars, etc. are mapped to native API's. In some cases, widgets are composites, using platform-native drawing primitives for their components but having their behavior implemented at the script level. > >> doesn't even ship with all components that are needed to get a proper >> native L&F with Tkinter. > > I think a proper native L&F is simple impossible with Tk I disagree with this, but it's partly a matter of opinion and partly a matter of how much attention the developer pays to platform specifics. It's true that out-of-the-box, Tk doesn't look especially native, especially if it's an application that has been ported from Windows or other Unix platforms. However, with some attention to platform details, such as spacing, colors, icons, etc., I think Tk can look pretty good. Certainly my own application with a *lot* of Mac-specific tweaking, strive to meet platform-specific conventions. To a lesser degree, this is true of any cross-platform toolkit. I've seen some wxPython apps that look awful on the Mac, and some wxWidgets wrappings of Mac widgets--such as a combox--don't look correct at all. On the other hand, a wxPython app like Editra, which really pays attention to the way it's implemented on the Mac, looks great. > > Kevin Walzer wrote: >> You've done terrific work getting IDLE to work with OS X. A lot of the >> work that needs to be done with IDLE modernizing its interface simply >> can't be done at a platform-specific level. > > but wouldn't making it more OS-Xish require platform specific > modification? Or do you mean the the toolkit itself has to support that > level of platform customization? Some of both. The awful notebook widget that IDLE uses in its preferences window could be swapped out with the more modern themed notebook widget that uses Mac-native tabs on OS X. That's toolkit-level customization, and it's what Guillhereme has added with his port of ttk to the standard library. Platform-specific customization is the kind of stuff that Ronald's done with keyboard shortcuts, placement of items in the menu, etc. > > Anyway, it's nice to see TK getting attention, particularly on the Mac. I strongly agree here. I was beginning to look around at different toolkits, but when I discovered Tk was being ported to Cocoa, I stopped. It means that Tk remains viable on the Mac. I've posted a bit more about Tk-Cocoa here: http://www.codebykevin.com/blosxom.cgi/2009/03/07#tk-cocoa-at-last > > Bill Janssen wrote: >> Yes, I agree with all that -- anything non-Cocoa isn't "real". > > I think Carbon is still real -- though it is on its way out... > I agree with Chris here. If Carbon isn't real, then the Finder isn't real, iTunes, etc....but it is definitely on the way out. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From chris.van.bael at gmail.com Sat May 16 08:54:28 2009 From: chris.van.bael at gmail.com (Chris Van Bael) Date: Sat, 16 May 2009 08:54:28 +0200 Subject: [Pythonmac-SIG] Python PyGame GTK SQLAlchemy on Leopard In-Reply-To: <5465ee790903221237o1384fe86v6af78e5c602a74fc@mail.gmail.com> References: <5465ee790903131239y25b7b916o571df55ffd05bae5@mail.gmail.com> <49BE8037.5000305@noaa.gov> <5465ee790903161228p3a2dc2e8ie0f2e0f9eff7453a@mail.gmail.com> <49BEAB6B.2070301@noaa.gov> <5465ee790903170118n4f6abfbi465964c8d3438507@mail.gmail.com> <49BFCE08.6020409@noaa.gov> <5465ee790903220622m7897dfcch7e8d838e6b4292bc@mail.gmail.com> <5465ee790903221237o1384fe86v6af78e5c602a74fc@mail.gmail.com> Message-ID: <5465ee790905152354p67e35a89ref0e50b2fa0cf6b0@mail.gmail.com> Hi all, it's been a while since my last question, but unfortunately I didn't make much progress. The problem I'm facing now is that PyGTK is not installed correct. I installed python 2.5 from Python.org. So if I do cd //Library/Frameworks/Python.framework/Versions/Current/bin/ and python, I get the following Python prompt: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> But if I go to the System Python cd //System/Library/Frameworks/Python.framework/Versions/Current/bin/ I get exactly the same Python prompt. Is that correct? Then I went to the PyGame website and installed pygame-1.8.1release-py2.5-macosx10.5.zip They say it is for the Python.org python. If I do "import PyGame" it works on both the Python.org and System Python. I was confused that it would also work on the System Python. Then I wanted to install PyGTK, for which I followed the instructions on http://live.gnome.org/GTK%2B/OSX/BuildInstructions When finally finished, I tried to "import pygtk", but >>> import pygtk Traceback (most recent call last): File "", line 1, in ImportError: No module named pygtk This on both the System Python as the Python.org python. So now I'm completely stuck! To me, it looks like Python.org and System Python are the same And PyGTK is not installed. I must say I tried the same commands to install PyGTK before and then it worked in the System Python. But I have no idea what was different now. Any help would be greatly appreciated! Chris From nad at acm.org Sat May 16 18:04:56 2009 From: nad at acm.org (Ned Deily) Date: Sat, 16 May 2009 09:04:56 -0700 Subject: [Pythonmac-SIG] Python PyGame GTK SQLAlchemy on Leopard References: <5465ee790903131239y25b7b916o571df55ffd05bae5@mail.gmail.com> <49BE8037.5000305@noaa.gov> <5465ee790903161228p3a2dc2e8ie0f2e0f9eff7453a@mail.gmail.com> <49BEAB6B.2070301@noaa.gov> <5465ee790903170118n4f6abfbi465964c8d3438507@mail.gmail.com> <49BFCE08.6020409@noaa.gov> <5465ee790903220622m7897dfcch7e8d838e6b4292bc@mail.gmail.com> <5465ee790903221237o1384fe86v6af78e5c602a74fc@mail.gmail.com> <5465ee790905152354p67e35a89ref0e50b2fa0cf6b0@mail.gmail.com> Message-ID: In article <5465ee790905152354p67e35a89ref0e50b2fa0cf6b0 at mail.gmail.com>, Chris Van Bael wrote: > it's been a while since my last question, but unfortunately I didn't > make much progress. > The problem I'm facing now is that PyGTK is not installed correct. > > I installed python 2.5 from Python.org. > So if I do cd //Library/Frameworks/Python.framework/Versions/Current/bin/ > and python, I get the following Python prompt: > Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) > [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> > > But if I go to the System Python cd > //System/Library/Frameworks/Python.framework/Versions/Current/bin/ > I get exactly the same Python prompt. > Is that correct? Well, no, that's not right. But just to make sure we're talking apples to Apples, make sure you are really invoking the pythons you think you are. Just cd'ing to a directory doesn't automatically add that directory to $PATH. So, if you just type "python", you're likely getting the same python each time. Instead, do the cd to the two "bin" directories but type "./python" instead. Beyond that, the python.org installers create symlinks at /usr/local/bin/python and /usr/local/bin/python2.n while OSX creates a symlink at /usr/bin/python to the system python, so you should be able to invoke the desired python by using those absolute paths. The Sep 19 2006 date indicates you are most likely using the python.org 2.5(.0) python, which, by the way, is out-of-date: the current python.org 2.5 is 2.5.4 and 2.6 is already at 2.6.2: > Then I went to the PyGame website and installed > pygame-1.8.1release-py2.5-macosx10.5.zip > They say it is for the Python.org python. > If I do "import PyGame" it works on both the Python.org and System Python. > I was confused that it would also work on the System Python. > > Then I wanted to install PyGTK, for which I followed the instructions > on http://live.gnome.org/GTK%2B/OSX/BuildInstructions > > When finally finished, I tried to "import pygtk", but > >>> import pygtk > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named pygtk IIUC, those instructions just install the underlying GTK+ libraries. You would still need to install PyGTK, the python wrappers to those libraries: http://www.pygtk.org/downloads.html -- Ned Deily, nad at acm.org From chris.van.bael at gmail.com Sun May 17 11:21:19 2009 From: chris.van.bael at gmail.com (Chris Van Bael) Date: Sun, 17 May 2009 11:21:19 +0200 Subject: [Pythonmac-SIG] Python PyGame GTK SQLAlchemy on Leopard In-Reply-To: References: <5465ee790903131239y25b7b916o571df55ffd05bae5@mail.gmail.com> <5465ee790903161228p3a2dc2e8ie0f2e0f9eff7453a@mail.gmail.com> <49BEAB6B.2070301@noaa.gov> <5465ee790903170118n4f6abfbi465964c8d3438507@mail.gmail.com> <49BFCE08.6020409@noaa.gov> <5465ee790903220622m7897dfcch7e8d838e6b4292bc@mail.gmail.com> <5465ee790903221237o1384fe86v6af78e5c602a74fc@mail.gmail.com> <5465ee790905152354p67e35a89ref0e50b2fa0cf6b0@mail.gmail.com> Message-ID: <5465ee790905170221l159b9462p4e06f3c08664eda5@mail.gmail.com> On Sat, May 16, 2009 at 6:04 PM, Ned Deily wrote: > Well, no, that's not right. ?But just to make sure we're talking apples > to Apples, make sure you are really invoking the pythons you think you > are. ?Just cd'ing to a directory doesn't automatically add that > directory to $PATH. ?So, if you just type "python", you're likely > getting the same python each time. ?Instead, do the cd to the two "bin" > directories but type "./python" instead. Ned, you're absolutely right! cd //Library/Frameworks/Python.framework/Versions/Current/bin/ ./Python gives: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pygame >>> import pygtk Traceback (most recent call last): File "", line 1, in ImportError: No module named pygtk cd //System/Library/Frameworks/Python.framework/Versions/Current/bin/ ./python gives Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pygame Traceback (most recent call last): File "", line 1, in ImportError: No module named pygame >>> import pygtk So the user python is indeed working and has PyGame installed. But unfortunately PyGTK is installed in the system Python, but I want it in my user python. I forgot to mention that I also did "jhbuild build pygtk" after that tutorial. So it installs PyGTK, only in the wrong Python. How can I solve that? Do I need to change a configuration file that jhbuild uses as input or can I copy the build GTK+PyGTK to my user Python? Thanks for the help! Chris From nad at acm.org Sun May 17 21:45:52 2009 From: nad at acm.org (Ned Deily) Date: Sun, 17 May 2009 12:45:52 -0700 Subject: [Pythonmac-SIG] Python PyGame GTK SQLAlchemy on Leopard References: <5465ee790903131239y25b7b916o571df55ffd05bae5@mail.gmail.com> <5465ee790903161228p3a2dc2e8ie0f2e0f9eff7453a@mail.gmail.com> <49BEAB6B.2070301@noaa.gov> <5465ee790903170118n4f6abfbi465964c8d3438507@mail.gmail.com> <49BFCE08.6020409@noaa.gov> <5465ee790903220622m7897dfcch7e8d838e6b4292bc@mail.gmail.com> <5465ee790903221237o1384fe86v6af78e5c602a74fc@mail.gmail.com> <5465ee790905152354p67e35a89ref0e50b2fa0cf6b0@mail.gmail.com> <5465ee790905170221l159b9462p4e06f3c08664eda5@mail.gmail.com> Message-ID: In article <5465ee790905170221l159b9462p4e06f3c08664eda5 at mail.gmail.com>, Chris Van Bael wrote: > So the user python is indeed working and has PyGame installed. > But unfortunately PyGTK is installed in the system Python, but I want > it in my user python. > > I forgot to mention that I also did "jhbuild build pygtk" after that tutorial. > So it installs PyGTK, only in the wrong Python. > How can I solve that? > > Do I need to change a configuration file that jhbuild uses as input or > can I copy the build GTK+PyGTK to my user Python? Sorry, I don't have any experience with PyGTK or jhbuild. But, in general, if jhbuild is using the standard way of installing python modules and extensions, you probably just need to make sure it finds the "user" python first. If it has a hard-wired path to the system python (/usr/bin/python), you may have to edit something somewhere (for instance, to /usr/local/bin/python). It may be possible to move or copy the installed pygtk module from the system python to the user python but that's really not a good idea: it may not work and you'll likely run into the problem again. For the record, for the system python, you'll probably find (most of) it installed in: /Library/Python/2.5/site-packages For the user python, it needs to be in: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pack ages There appears to be an active PyGTK mailing list. You might want to check its archives or ask over there. Good luck! -- Ned Deily, nad at acm.org From kw at codebykevin.com Tue May 19 03:51:40 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 18 May 2009 21:51:40 -0400 Subject: [Pythonmac-SIG] Patch to IDLE Message-ID: <4A1210AC.8070407@codebykevin.com> I'm trying to patch IDLE to work better with the Cocoa fork of Tcl/Tk. With Tk-Cocoa, in order to correctly set up the Apple/Application menu, you have to call the equivalent of 'self.configure(menu=menubar)' after everything else is set up. Otherwise the hard-coded "About Tcl/Tk" menu item remains, and the menu override is moved to the very end of the menu, after "Help." (So there are two "IDLE" menus under this scenario.) In macosxSupport.py, in the function overrideRootMenu(), there is a call to root.configure(menu=menubar); I thought moving this to the end of the function would work. However, no matter where this line is set, it has no effect; the overridden IDLE menu still sits at the end of the menubar. My question is, where in idlelib would be the best place to call this configuration option to ensure that the entire menu is built before it is bound/set to the root menu? There are many calls to macosxSupport.py in idlelib, and that's the "root" for overriding the Tk menu, so I thought that was where it should be done...but I'm not sure. Advice is appreciated. If I get this resolved, I'll submit a patch to support Tk 8.6, when Cocoa will move from a fork to trunk in Tk development. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ronaldoussoren at mac.com Tue May 19 13:07:09 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 19 May 2009 13:07:09 +0200 Subject: [Pythonmac-SIG] Patch to IDLE In-Reply-To: <4A1210AC.8070407@codebykevin.com> References: <4A1210AC.8070407@codebykevin.com> Message-ID: <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> On 19 May, 2009, at 3:51, Kevin Walzer wrote: > I'm trying to patch IDLE to work better with the Cocoa fork of Tcl/ > Tk. With Tk-Cocoa, in order to correctly set up the Apple/ > Application menu, you have to call the equivalent of > 'self.configure(menu=menubar)' after everything else is set up. > Otherwise the hard-coded "About Tcl/Tk" menu item remains, and the > menu override is moved to the very end of the menu, after > "Help." (So there are two "IDLE" menus under this scenario.) > > In macosxSupport.py, in the function overrideRootMenu(), there is a > call to root.configure(menu=menubar); I thought moving this to the > end of the function would work. However, no matter where this line > is set, it has no effect; the overridden IDLE menu still sits at the > end of the menubar. My question is, where in idlelib would be the > best place to call this configuration option to ensure that the > entire menu is built before it is bound/set to the root menu? There > are many calls to macosxSupport.py in idlelib, and that's the "root" > for overriding the Tk menu, so I thought that was where it should be > done...but I'm not sure. > > Advice is appreciated. If I get this resolved, I'll submit a patch > to support Tk 8.6, when Cocoa will move from a fork to trunk in Tk > development. I would have thought that overrideRootMenu is the right location for your change, that function should be called (by setupApp in the same function) by the time everything is set up (PyShell calls setApp just before opening the console window). The IDLE codebase can be annoyingly hard to understand at times, which makes creating patches unnecesserily hard at times. I'm afraid the only way to find the correct location for a patch is by trial and error, first try to hardcode a fix inline and when that works move the code to a function in macosxSupport.py. Ronald > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From kw at codebykevin.com Tue May 19 17:14:21 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Tue, 19 May 2009 11:14:21 -0400 Subject: [Pythonmac-SIG] Patch to IDLE In-Reply-To: <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> References: <4A1210AC.8070407@codebykevin.com> <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> Message-ID: <4A12CCCD.4000301@codebykevin.com> Ronald Oussoren wrote: > I would have thought that overrideRootMenu is the right location for > your change, that function should be called (by setupApp in the same > function) by the time everything is set up (PyShell calls setApp just > before opening the console window). > > The IDLE codebase can be annoyingly hard to understand at times, which > makes creating patches unnecesserily hard at times. > > I'm afraid the only way to find the correct location for a patch is by > trial and error, first try to hardcode a fix inline and when that works > move the code to a function in macosxSupport.py. Ronald, You are right, the codebase is complex. Setting aside the application/apple menu for the moment, I've run into another issue. With Tk-Cocoa, the "help" menu automagically adds a menu entry for an Apple help book, and pops up a dialog saying "Help isn't available for Foo.app." I think PyObjC does something similar; it's the default behavior for the help menu in Cocoa. However, if the app defines its own help command (as IDLE does), then you have two "help" commands under the help menu--the useless Cocoa command and the IDLE-defined one. The workaround is to rename the "help" menu to something else, i.e. "helpdocs"; this avoids the empty Cocoa help command. I've tried this at various points in the IDLE code (Bindings.py, EditorWindow.py), and it seems to work. However, I'm not sure if doing this would break IDLE on other platforms. Simply re-naming the "help" menu to something else is preferable and simpler to wrapping the menu_specs dict in a lot of platform-specific logic: I've tried adding some "if macosxSupport.runningAsOSXApp():" lines to the code, but that crashes IDLE at various points. Any advice here? --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ronaldoussoren at mac.com Tue May 19 19:06:34 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 19 May 2009 19:06:34 +0200 Subject: [Pythonmac-SIG] Patch to IDLE In-Reply-To: <4A12CCCD.4000301@codebykevin.com> References: <4A1210AC.8070407@codebykevin.com> <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> <4A12CCCD.4000301@codebykevin.com> Message-ID: <891E74EA-30B0-486E-B347-5CE8A5E61E58@mac.com> On 19 May, 2009, at 17:14, Kevin Walzer wrote: > Ronald Oussoren wrote: > >> I would have thought that overrideRootMenu is the right location >> for your change, that function should be called (by setupApp in the >> same function) by the time everything is set up (PyShell calls >> setApp just before opening the console window). >> The IDLE codebase can be annoyingly hard to understand at times, >> which makes creating patches unnecesserily hard at times. >> I'm afraid the only way to find the correct location for a patch is >> by trial and error, first try to hardcode a fix inline and when >> that works move the code to a function in macosxSupport.py. > > Ronald, > > You are right, the codebase is complex. > > Setting aside the application/apple menu for the moment, I've run > into another issue. With Tk-Cocoa, the "help" menu automagically > adds a menu entry for an Apple help book, and pops up a dialog > saying "Help isn't available for Foo.app." I think PyObjC does > something similar; it's the default behavior for the help menu in > Cocoa. However, if the app defines its own help command (as IDLE > does), then you have two "help" commands under the help menu--the > useless Cocoa command and the IDLE-defined one. > > The workaround is to rename the "help" menu to something else, i.e. > "helpdocs"; this avoids the empty Cocoa help command. I've tried > this at various points in the IDLE code (Bindings.py, > EditorWindow.py), and it seems to work. However, I'm not sure if > doing this would break IDLE on other platforms. > > Simply re-naming the "help" menu to something else is preferable and > simpler to wrapping the menu_specs dict in a lot of platform- > specific logic: I've tried adding some "if > macosxSupport.runningAsOSXApp():" lines to the code, but that > crashes IDLE at various points. Any advice here? File bugs with the Tk-Cocoa developers. I'd consider both the addition of an unwanted help menu and the, yet again, changed way to surpress the default application menu bugs in Tk. We could continue to add more and more workarounds to IDLE, but it might be early enough to get this fixed in Tk itself. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From dwf at cs.toronto.edu Tue May 19 21:29:07 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Tue, 19 May 2009 15:29:07 -0400 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? Message-ID: Howdy, I was wondering if anyone has successfully built wxMac/wxPython in 64- bit mode for use with a 64-bit universal (or 4-way universal) Python. So far I've had limited success - even though wxMac has an --enable- universal flag for configure, I get complaints about multiple arch flags. Regards, David From ronaldoussoren at mac.com Tue May 19 22:19:37 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 19 May 2009 22:19:37 +0200 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? In-Reply-To: References: Message-ID: <9C1F9B69-F757-4E55-AF34-7040ED0284C9@mac.com> David, On 19 May, 2009, at 21:29, David Warde-Farley wrote: > Howdy, > > I was wondering if anyone has successfully built wxMac/wxPython in > 64-bit mode for use with a 64-bit universal (or 4-way universal) > Python. So far I've had limited success - even though wxMac has an -- > enable-universal flag for configure, I get complaints about multiple > arch flags. wxMac is build on top of the Carbon framework and hence won't work in 64-bit mode. There is an experimental wxCocoa port as well, that might work in 64-bit mode. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From dwf at cs.toronto.edu Wed May 20 00:15:30 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Tue, 19 May 2009 18:15:30 -0400 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? In-Reply-To: <9C1F9B69-F757-4E55-AF34-7040ED0284C9@mac.com> References: <9C1F9B69-F757-4E55-AF34-7040ED0284C9@mac.com> Message-ID: Hi Ron, On 19-May-09, at 4:19 PM, Ronald Oussoren wrote: > wxMac is build on top of the Carbon framework and hence won't work > in 64-bit mode. There is an experimental wxCocoa port as well, that > might work in 64-bit mode. Thanks for the quick response. I now recall reading about 64-bit support for Carbon being dropped. D'oh. I'm really only interested in it for the sake of wxPython GUIs on top of numpy/scipy stuff; I don't need 64-bit wx per se... Am I correct in assuming there's no way to get 32-bit wxMac to play nice with 64-bit Python? From what i'm reading the Cocoa port is more- or-less dead. David From kw at codebykevin.com Wed May 20 00:17:30 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Tue, 19 May 2009 18:17:30 -0400 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? In-Reply-To: References: <9C1F9B69-F757-4E55-AF34-7040ED0284C9@mac.com> Message-ID: <4A132FFA.3000907@codebykevin.com> David Warde-Farley wrote: > > Am I correct in assuming there's no way to get 32-bit wxMac to play nice > with 64-bit Python? From what i'm reading the Cocoa port is more-or-less > dead. > No, that's not quite right; wxCocoa is being merged into wxMac and the new branch is called wxOSX. I'm not sure it's been integrated into wxPython yet, and certainly there are no officially supported 64-bit builds of wxPython, but perhaps soon. See this blog entry: http://wiki.wxwindows.org/Development:_wxMac -- Kevin Walzer Code by Kevin http://www.codebykevin.com From kw at codebykevin.com Wed May 20 02:50:57 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Tue, 19 May 2009 20:50:57 -0400 Subject: [Pythonmac-SIG] Patch to IDLE In-Reply-To: <891E74EA-30B0-486E-B347-5CE8A5E61E58@mac.com> References: <4A1210AC.8070407@codebykevin.com> <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> <4A12CCCD.4000301@codebykevin.com> <891E74EA-30B0-486E-B347-5CE8A5E61E58@mac.com> Message-ID: <4A1353F1.80204@codebykevin.com> Ronald Oussoren wrote: > File bugs with the Tk-Cocoa developers. I'd consider both the addition > of an unwanted help menu and the, yet again, changed way to surpress the > default application menu bugs in Tk. We could continue to add more and > more workarounds to IDLE, but it might be early enough to get this fixed > in Tk itself. Mailing list traffic has yielded some documented workarounds, which I will attempt to implement in IDLE. I don't think patching Tk for this is in the cards. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From csomor at advancedconcepts.ch Wed May 20 09:01:51 2009 From: csomor at advancedconcepts.ch (Stefan Csomor) Date: Wed, 20 May 2009 09:01:51 +0200 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? In-Reply-To: <4A132FFA.3000907@codebykevin.com> Message-ID: > No, that's not quite right; wxCocoa is being merged into wxMac and the > new branch is called wxOSX. I'm not sure it's been integrated into > wxPython yet, and certainly there are no officially supported 64-bit > builds of wxPython, but perhaps soon. > > See this blog entry: http://wiki.wxwindows.org/Development:_wxMac Thanks Kevin for clarifying :-) yes that's correct, I'm pretty much done with all the important steps (a few things like sheet dialogs have to wait for 2.9.1), 2.9.0 has just had its RC3 and because of a linkage problem on fedora we will have to make a RC4 but then 2.9.0 should be ready, having both osx_carbon and osx_cocoa, and the latter works in 64 bit as well. I don't know about Robin's schedule right now, but we've always tried to make sure his things still build properly during the last few months. Best, Stefan From dwf at cs.toronto.edu Wed May 20 10:28:23 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Wed, 20 May 2009 04:28:23 -0400 Subject: [Pythonmac-SIG] 64-bit wxMac/wxPython? In-Reply-To: References: Message-ID: <5CB01723-D316-4352-9C1C-2C1A6C28C6F7@cs.toronto.edu> On 20-May-09, at 3:01 AM, Stefan Csomor wrote: > Thanks Kevin for clarifying :-) yes that's correct, I'm pretty much > done > with all the important steps (a few things like sheet dialogs have > to wait > for 2.9.1), 2.9.0 has just had its RC3 and because of a linkage > problem on > fedora we will have to make a RC4 but then 2.9.0 should be ready, > having > both osx_carbon and osx_cocoa, and the latter works in 64 bit as > well. I > don't know about Robin's schedule right now, but we've always tried > to make > sure his things still build properly during the last few months. Hi Stefan, That's fantastic. Is the path to a wxPython fairly straightforward once wx 2.9 is nailed down? Regards, and thanks for all your efforts! David From dwf at cs.toronto.edu Wed May 20 23:30:43 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Wed, 20 May 2009 17:30:43 -0400 Subject: [Pythonmac-SIG] building 4-way framework build with readline? Message-ID: <9A46C89E-F4AB-4D0D-80D0-972264BDCF02@cs.toronto.edu> I've had success building the 4-way framework build using Ron's instructions, but I can't seem to get it building with readline linked in. I built a static readline 6.0 so that libreadline.a and libhistory.a are both 4-architecture fat binaries, and configured python with ./configure --with-framework-name=Python64 --with-universal-archs=all --enable-framework --enable-universalsdk=/ --with-libs='-lexpat - lreadline -lncurses' --with-readline=$HOME/readline MACOSX_DEPLOYMENT_TARGET=10.5 LD_LIBRARY_PATH=/Users/dwf/readline/lib but alas it still doesn't seem to build with readline. Any hints on how to get this working? The relevant info seems to be checking how to link readline libs... -lreadline checking for rl_callback_handler_install in -lreadline... yes rm: conftest.dSYM: is a directory checking for rl_pre_input_hook in -lreadline... yes checking for rl_completion_display_matches_hook in -lreadline... yes checking for rl_completion_matches in -lreadline... no rm: conftest.dSYM: is a directory checking for broken nice()... no and during make: Failed to find the necessary bits to build these modules: _bsddb dl gdbm imageop linuxaudiodev ossaudiodev readline spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Thanks, David From kw at codebykevin.com Thu May 21 00:33:48 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 20 May 2009 18:33:48 -0400 Subject: [Pythonmac-SIG] Patch to IDLE In-Reply-To: <891E74EA-30B0-486E-B347-5CE8A5E61E58@mac.com> References: <4A1210AC.8070407@codebykevin.com> <68B346CD-D0E9-4B0F-BCBD-5E1864ED9443@mac.com> <4A12CCCD.4000301@codebykevin.com> <891E74EA-30B0-486E-B347-5CE8A5E61E58@mac.com> Message-ID: <4A14854C.7070304@codebykevin.com> Ronald Oussoren wrote: > > File bugs with the Tk-Cocoa developers. I'd consider both the addition > of an unwanted help menu and the, yet again, changed way to surpress the > default application menu bugs in Tk. We could continue to add more and > more workarounds to IDLE, but it might be early enough to get this fixed > in Tk itself. > Daniel Steffen, the maintainer of Tk/Aqua, has committed some changes to make modifying the help and application menus simpler. Based on these commits (which will be included in Tk 8.6 and are also backported to Tk 8.5.7 in a fork hosted at Github), I have uploaded some patches to make IDLE play nice regardless of whether Tk is built on Carbon or Cocoa: http://bugs.python.org/issue6075 -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ronaldoussoren at mac.com Thu May 21 09:53:01 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 21 May 2009 09:53:01 +0200 Subject: [Pythonmac-SIG] bdist_mpkg 0.4.4 released Message-ID: <1F335A43-EAF1-41A4-8D1A-F6326FC1D1B0@mac.com> Hi, I've just uploaded dist_mpkg 0.4.4 to PyPI. The only change w.r.t. the previous release is that this version also works on Leopard. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Thu May 21 10:03:02 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 21 May 2009 10:03:02 +0200 Subject: [Pythonmac-SIG] building 4-way framework build with readline? In-Reply-To: <9A46C89E-F4AB-4D0D-80D0-972264BDCF02@cs.toronto.edu> References: <9A46C89E-F4AB-4D0D-80D0-972264BDCF02@cs.toronto.edu> Message-ID: <8ECE3E3E-5AF0-48FE-9E9C-1B70E26F0C01@mac.com> On 20 May, 2009, at 23:30, David Warde-Farley wrote: > I've had success building the 4-way framework build using Ron's > instructions, but I can't seem to get it building with readline > linked in. > > I built a static readline 6.0 so that libreadline.a and libhistory.a > are both 4-architecture fat binaries, and configured python with > > ./configure --with-framework-name=Python64 --with-universal- > archs=all --enable-framework --enable-universalsdk=/ --with-libs='- > lexpat -lreadline -lncurses' --with-readline=$HOME/readline > MACOSX_DEPLOYMENT_TARGET=10.5 LD_LIBRARY_PATH=/Users/dwf/readline/lib > > but alas it still doesn't seem to build with readline. Any hints on > how to get this working? > > The relevant info seems to be Not quite, you've removed the bit where the build process tries to compile the readline extension. > > checking how to link readline libs... -lreadline > checking for rl_callback_handler_install in -lreadline... yes > rm: conftest.dSYM: is a directory > checking for rl_pre_input_hook in -lreadline... yes > checking for rl_completion_display_matches_hook in -lreadline... yes > checking for rl_completion_matches in -lreadline... no > rm: conftest.dSYM: is a directory > checking for broken nice()... no > > and during make: > > Failed to find the necessary bits to build these modules: > _bsddb dl gdbm > imageop linuxaudiodev ossaudiodev > readline spwd sunaudiodev > To find the necessary bits, look in setup.py in detect_modules() for > the module's name. The easiest way to build a 4-way universal binary with readline support is to use my release script: cd $PYTHONSRC/Mac/BuildScript $ ./build-installer.py --dep-target=10.5 --universal-args=all This should work with Python 2.6.2 and later (it definitely works with the current version of the 2.6 branch in subversion, as well as the trunk and 3.x branch) Ronald > > > > Thanks, > > David > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From Chris.Barker at noaa.gov Fri May 22 18:11:11 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 22 May 2009 09:11:11 -0700 Subject: [Pythonmac-SIG] bdist_mpkg 0.4.4 released In-Reply-To: <1F335A43-EAF1-41A4-8D1A-F6326FC1D1B0@mac.com> References: <1F335A43-EAF1-41A4-8D1A-F6326FC1D1B0@mac.com> Message-ID: <4A16CE9F.3080204@noaa.gov> Ronald Oussoren wrote: > I've just uploaded dist_mpkg 0.4.4 to PyPI. Thanks Ronald, I really appreciate your keeping this stuff up to date! -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.Barker at noaa.gov From dwf at cs.toronto.edu Fri May 22 20:38:34 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Fri, 22 May 2009 14:38:34 -0400 Subject: [Pythonmac-SIG] bdist_mpkg 0.4.4 released In-Reply-To: <4A16CE9F.3080204@noaa.gov> References: <1F335A43-EAF1-41A4-8D1A-F6326FC1D1B0@mac.com> <4A16CE9F.3080204@noaa.gov> Message-ID: <0EDCA4B6-F6DF-426C-BE87-9097C3B7CEBD@cs.toronto.edu> +1. I mostly lurk here but I am quite aware of all the work you do to make Python on the Mac better, you have my sincerest gratitude. David On 22-May-09, at 12:11 PM, Christopher Barker wrote: > Ronald Oussoren wrote: >> I've just uploaded dist_mpkg 0.4.4 to PyPI. > > Thanks Ronald, I really appreciate your keeping this stuff up to date! > > -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.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kelsolaar_fool at hotmail.com Mon May 25 00:11:55 2009 From: kelsolaar_fool at hotmail.com (Kel Solaar) Date: Sun, 24 May 2009 22:11:55 +0000 Subject: [Pythonmac-SIG] Py2App And Python 2.6.2 Message-ID: Hello :) I'm coding an application with PyQt, QT 4.5 and Python 2.6.2, I would like to package/freeze it with py2app ( It was working with 2.5 before ) but I'm encountering some problems :First : Why is Py2App using Python 2.5 by default ? Here is an explicit part of my building log : *** byte compile python files *** byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/py2app/bootstrap/argv_emulation.py to argv_emulation.pyc I'm launching the build with : sIBL_GUI_App_Setup.py py2app --includes "sip"Of course when I launch a Python Interpreter in a shell I'm in 2.6.2. That lead me to another problem I will encounter if I can't build with 2.6.2 : How can I install Sip, PyQt on the Python 2.5 Framework, since it's installed on the 2.6.2 ? I'm getting an Import Error : File "/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/modulegraph/modulegraph.py", line 431, in find_head_package raise ImportError, "No module named " + qname ImportError: No module named sip That's make sense since Sip and PyQt are installed for the 2.6.2 Python Framework... So I explicitely launched the build from my 2.6.2 python :/Library/Frameworks/Python.framework/Versions/2.6/bin/./python sIBL_GUI_App_Setup.py py2app --includes "sip" I'm now getting that error : DistutilsFileError: can't copy '/Library/Frameworks/Python.framework/Versions/2.6/Resources/version.plist': doesn't exist or not a regular file I did copied / modified the "version.plist" of System Python 2.5 Framework, but that's a bit odd... BuildVersion 4 CFBundleShortVersionString 2.6 CFBundleVersion 2.6 ProjectName python SourceVersion 300103 I of course don't know what to put for BuildVersion and SourceVersion, anyway the Application is builded this time, and when I launch it this is what I get : May 25 00:07:36 Lilith [0x0-0x1e81e8].org.pythonmac.unspecified.sIBL_GUI[4730]: ImportError: '/Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Resources/lib/python2.5/lib-dynload/PyQt4/QtCore.so' not found Again Py2App is looking for something in python2.5 whereas in lib there is a python2.6 directory. Since it was late I stopped searching, but if somebody has an idea, I'll be really happy :) _________________________________________________________________ Vous voulez savoir ce que vous pouvez faire avec le nouveau Windows Live?? Lancez-vous ! http://www.microsoft.com/windows/windowslive/default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.newman at ualberta.ca Mon May 25 01:34:36 2009 From: john.newman at ualberta.ca (John Newman) Date: Sun, 24 May 2009 17:34:36 -0600 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 Message-ID: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> Apologies if my question is ridiculously trivial - I'm not a developer, just a relatively new user of Python 3.0.1 on Mac OS 10.4.11. and I have only just now joined the list. When I read in a Chinese text in the Python 3 IDLE GUI on Windows XP I see all the Chinese glyphs displayed properly. On my Mac, about one third of the Chinese characters are not displayed correctly (just empty or black boxes in place of glyphs). It doesn't matter whether I save/open texts as utf-8, utf-16, etc. [The glyphs display fine in TextEdit, JEdit, Word etc.] And the same kind of problem occurs when I scroll through the list of font names in Preferences in IDLE: the names in Chinese glyphs have a number of white or black boxes instead of the glyphs. I just assume that this has something to do with the locale settings in IDLE? On my machine: >>> locale.getpreferredencoding() 'mac-roman' >>> locale.getlocale() (None, None) In my Windows XP, the locale settings are (English, '1252') and I presume that this difference is relevant to understanding the different effects I get opening Chinese texts in my Windows XP and my Mac. 'mac-roman' would not be my natural choice of encoding if I am looking at Chinese text! I need an encoding which can handle the range of glyphs we find in GB 18030, say. Am I being naive in thinking that all I have to do in Python is somehow change the locale settings in some way which will display Chnese glyphs? I'm at a loss to know what I should do in order to display Chinese glyphs properly on the Mac. I tried experimenting with "setlocale" but couldn't make progress. Any suggestions would be very welcome. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan.stocks at gmail.com Mon May 25 02:00:08 2009 From: nathan.stocks at gmail.com (Nathan) Date: Sun, 24 May 2009 18:00:08 -0600 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> Message-ID: <96c9d6a80905241700w237a8e3dybf762d7b26ddea5b@mail.gmail.com> On Sun, May 24, 2009 at 5:34 PM, John Newman wrote: > Apologies if my question is ridiculously trivial - I'm not a developer, just > a relatively new user of Python 3.0.1 on Mac OS 10.4.11. and I have only > just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE GUI on Windows XP I see > all the Chinese glyphs displayed properly. On my Mac, about one third of the > Chinese characters are not displayed correctly (just empty or black boxes in > place of glyphs). It doesn't matter whether I save/open texts as utf-8, > utf-16, etc. [The glyphs display fine in TextEdit, JEdit, Word etc.]? And > the same kind of problem occurs when I scroll through the list of font names > in Preferences in IDLE: the names in Chinese glyphs have a number of white > or black boxes instead of the glyphs. > > I just assume that this has something to do with the locale settings in > IDLE? On my machine: > >>>> locale.getpreferredencoding() > 'mac-roman' >>>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, '1252') and I presume > that this difference is relevant to understanding the different effects I > get opening Chinese texts in my Windows XP and my Mac. 'mac-roman' would not > be my natural choice of encoding if I am looking at Chinese text! I need an > encoding which can handle the range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do in Python is somehow > change the locale settings in some way which will display Chnese glyphs? > I'm at a loss to know what I should do in order to display Chinese glyphs > properly on the Mac. I tried experimenting with "setlocale" but couldn't > make progress. > > Any suggestions would be very welcome. > > John I don't have any experience with IDLE, but perhaps the font it is using simply doesn't contain those glyphs? I would try changing the font to one you know for sure contains the glyphs you are using. ~ Nathan From ronaldoussoren at mac.com Mon May 25 07:37:42 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 25 May 2009 07:37:42 +0200 Subject: [Pythonmac-SIG] Py2App And Python 2.6.2 In-Reply-To: References: Message-ID: On 25 May, 2009, at 0:11, Kel Solaar wrote: > Hello :) > > I'm coding an application with PyQt, QT 4.5 and Python 2.6.2, I > would like to package/freeze it with py2app ( It was working with > 2.5 before ) but I'm encountering some problems : > First : Why is Py2App using Python 2.5 by default ? You haven't installed py2app for python2.6 yet. "Easy_install-2.6 py2app" should do the trick. If you don't use a setup.py you should then ensure that you run the right py2app commandline tool. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Mon May 25 07:48:04 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 25 May 2009 07:48:04 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> Message-ID: <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> John, On 25 May, 2009, at 1:34, John Newman wrote: > Apologies if my question is ridiculously trivial - I'm not a > developer, just a relatively new user of Python 3.0.1 on Mac OS > 10.4.11. and I have only just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE GUI on Windows XP > I see all the Chinese glyphs displayed properly. On my Mac, about > one third of the Chinese characters are not displayed correctly > (just empty or black boxes in place of glyphs). It doesn't matter > whether I save/open texts as utf-8, utf-16, etc. [The glyphs display > fine in TextEdit, JEdit, Word etc.] And the same kind of problem > occurs when I scroll through the list of font names in Preferences > in IDLE: the names in Chinese glyphs have a number of white or black > boxes instead of the glyphs. > > I just assume that this has something to do with the locale settings > in IDLE? On my machine: > > >>> locale.getpreferredencoding() > 'mac-roman' > >>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, '1252') and I > presume that this difference is relevant to understanding the > different effects I get opening Chinese texts in my Windows XP and > my Mac. 'mac-roman' would not be my natural choice of encoding if I > am looking at Chinese text! I need an encoding which can handle the > range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do in Python is > somehow change the locale settings in some way which will display > Chnese glyphs? I'm at a loss to know what I should do in order to > display Chinese glyphs properly on the Mac. I tried experimenting > with "setlocale" but couldn't make progress. > > Any suggestions would be very welcome. > This might be a font issue, although the default font (Courier) seems to be capable of displaying unicode text and therefore saving as UTF-8 should work. Another possible souce for this problem is the GUI framework used by IDLE. Could you post an example of a file that shows the problem? Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Mon May 25 19:30:46 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 25 May 2009 19:30:46 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> Message-ID: <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> On 25 May, 2009, at 16:36, John Newman wrote: > Ronald > > See the attachment, where most of the Chinese glyphs are correctly > displayed, but not all. > > When I copy and paste these glyphs from Python 3 to JEdit, all the > glyphs display correctly, so the correct unicode code points are > there underlying the glyphs. I've tried most of the fonts available > to me in the GUI and I still can't get them all to display properly. > Could you post the actual text-file as well? Ronald > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Sun 5/24/2009 11:48 PM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > John, > > On 25 May, 2009, at 1:34, John Newman wrote: > > > Apologies if my question is ridiculously trivial - I'm not a > developer, just a relatively new user of Python 3.0.1 on Mac OS > 10.4.11. and I have only just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE GUI on > Windows XP I see all the Chinese glyphs displayed properly. On my > Mac, about one third of the Chinese characters are not displayed > correctly (just empty or black boxes in place of glyphs). It doesn't > matter whether I save/open texts as utf-8, utf-16, etc. [The glyphs > display fine in TextEdit, JEdit, Word etc.] And the same kind of > problem occurs when I scroll through the list of font names in > Preferences in IDLE: the names in Chinese glyphs have a number of > white or black boxes instead of the glyphs. > > I just assume that this has something to do with the locale > settings in IDLE? On my machine: > > >>> locale.getpreferredencoding() > 'mac-roman' > >>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, '1252') > and I presume that this difference is relevant to understanding the > different effects I get opening Chinese texts in my Windows XP and > my Mac. 'mac-roman' would not be my natural choice of encoding if I > am looking at Chinese text! I need an encoding which can handle the > range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do in Python > is somehow change the locale settings in some way which will display > Chnese glyphs? I'm at a loss to know what I should do in order to > display Chinese glyphs properly on the Mac. I tried experimenting > with "setlocale" but couldn't make progress. > > Any suggestions would be very welcome. > > > > This might be a font issue, although the default font (Courier) > seems to be capable of displaying unicode text and therefore saving > as UTF-8 should work. Another possible souce for this problem is > the GUI framework used by IDLE. > > Could you post an example of a file that shows the problem? > > Ronald > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From john.newman at ualberta.ca Mon May 25 21:24:49 2009 From: john.newman at ualberta.ca (John Newman) Date: Mon, 25 May 2009 13:24:49 -0600 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> Message-ID: <4344CD9CDCB75542A60FC99F20E9800AD70240@artsml.arts.ualberta.ca> Here's the original text (I hope it comes through OK): ? ? ? ? ? ? ? ? ? ? ? ? ? , ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ( P h i l a d e l p h i a ) , ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 ? 2 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 4 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 5 0 ? , ? ? ? ? ? ? ? ? ? ? ? ? ? , ? ? ? ? ? ? ? ? ? John -----Original Message----- From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] Sent: Mon 5/25/2009 11:30 AM To: John Newman Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 On 25 May, 2009, at 16:36, John Newman wrote: > Ronald > > See the attachment, where most of the Chinese glyphs are correctly > displayed, but not all. > > When I copy and paste these glyphs from Python 3 to JEdit, all the > glyphs display correctly, so the correct unicode code points are > there underlying the glyphs. I've tried most of the fonts available > to me in the GUI and I still can't get them all to display properly. > Could you post the actual text-file as well? Ronald > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Sun 5/24/2009 11:48 PM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > John, > > On 25 May, 2009, at 1:34, John Newman wrote: > > > Apologies if my question is ridiculously trivial - I'm not a > developer, just a relatively new user of Python 3.0.1 on Mac OS > 10.4.11. and I have only just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE GUI on > Windows XP I see all the Chinese glyphs displayed properly. On my > Mac, about one third of the Chinese characters are not displayed > correctly (just empty or black boxes in place of glyphs). It doesn't > matter whether I save/open texts as utf-8, utf-16, etc. [The glyphs > display fine in TextEdit, JEdit, Word etc.] And the same kind of > problem occurs when I scroll through the list of font names in > Preferences in IDLE: the names in Chinese glyphs have a number of > white or black boxes instead of the glyphs. > > I just assume that this has something to do with the locale > settings in IDLE? On my machine: > > >>> locale.getpreferredencoding() > 'mac-roman' > >>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, '1252') > and I presume that this difference is relevant to understanding the > different effects I get opening Chinese texts in my Windows XP and > my Mac. 'mac-roman' would not be my natural choice of encoding if I > am looking at Chinese text! I need an encoding which can handle the > range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do in Python > is somehow change the locale settings in some way which will display > Chnese glyphs? I'm at a loss to know what I should do in order to > display Chinese glyphs properly on the Mac. I tried experimenting > with "setlocale" but couldn't make progress. > > Any suggestions would be very welcome. > > > > This might be a font issue, although the default font (Courier) > seems to be capable of displaying unicode text and therefore saving > as UTF-8 should work. Another possible souce for this problem is > the GUI framework used by IDLE. > > Could you post an example of a file that shows the problem? > > Ronald > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelsolaar_fool at hotmail.com Tue May 26 00:35:33 2009 From: kelsolaar_fool at hotmail.com (Kel Solaar) Date: Mon, 25 May 2009 22:35:33 +0000 Subject: [Pythonmac-SIG] Py2App / Strip Not Correctly Working On .dSYM Directories Message-ID: Hello :) Py2App seems to fail stripping my .dSYM directories. This one for example is currently around 210 mo and bundled every time : MyApp.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM I have those related messages : /usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/QtGui_debug (for architecture ppc) /usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/QtGui_debug (for architecture i386) /usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/DWARF/QtCore_debug (for architecture ppc) /usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/DWARF/QtCore_debug (for architecture i386) stripping saved 25755260 bytes (208239343 / 233994603) Anyone have an idea ? _________________________________________________________________ T?l?phonez gratuitement ? tous vos proches avec Windows Live Messenger? !? T?l?chargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.newman at ualberta.ca Tue May 26 02:27:15 2009 From: john.newman at ualberta.ca (John Newman) Date: Mon, 25 May 2009 18:27:15 -0600 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> Message-ID: <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> Sorry, pasting the Chinese text into email wasn't very clever. I've attached a txt file with the Chinese saved as utf-8. John -----Original Message----- From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] Sent: Mon 5/25/2009 11:30 AM To: John Newman Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 On 25 May, 2009, at 16:36, John Newman wrote: Ronald See the attachment, where most of the Chinese glyphs are correctly displayed, but not all. When I copy and paste these glyphs from Python 3 to JEdit, all the glyphs display correctly, so the correct unicode code points are there underlying the glyphs. I've tried most of the fonts available to me in the GUI and I still can't get them all to display properly. Could you post the actual text-file as well? Ronald John -----Original Message----- From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] Sent: Sun 5/24/2009 11:48 PM To: John Newman Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 John, On 25 May, 2009, at 1:34, John Newman wrote: Apologies if my question is ridiculously trivial - I'm not a developer, just a relatively new user of Python 3.0.1 on Mac OS 10.4.11. and I have only just now joined the list. When I read in a Chinese text in the Python 3 IDLE GUI on Windows XP I see all the Chinese glyphs displayed properly. On my Mac, about one third of the Chinese characters are not displayed correctly (just empty or black boxes in place of glyphs). It doesn't matter whether I save/open texts as utf-8, utf-16, etc. [The glyphs display fine in TextEdit, JEdit, Word etc.] And the same kind of problem occurs when I scroll through the list of font names in Preferences in IDLE: the names in Chinese glyphs have a number of white or black boxes instead of the glyphs. I just assume that this has something to do with the locale settings in IDLE? On my machine: >>> locale.getpreferredencoding() 'mac-roman' >>> locale.getlocale() (None, None) In my Windows XP, the locale settings are (English, '1252') and I presume that this difference is relevant to understanding the different effects I get opening Chinese texts in my Windows XP and my Mac. 'mac-roman' would not be my natural choice of encoding if I am looking at Chinese text! I need an encoding which can handle the range of glyphs we find in GB 18030, say. Am I being naive in thinking that all I have to do in Python is somehow change the locale settings in some way which will display Chnese glyphs? I'm at a loss to know what I should do in order to display Chinese glyphs properly on the Mac. I tried experimenting with "setlocale" but couldn't make progress. Any suggestions would be very welcome. This might be a font issue, although the default font (Courier) seems to be capable of displaying unicode text and therefore saving as UTF-8 should work. Another possible souce for this problem is the GUI framework used by IDLE. Could you post an example of a file that shows the problem? Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Chinese.txt URL: From ronaldoussoren at mac.com Tue May 26 08:16:01 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 08:16:01 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> Message-ID: <4BD7A952-D864-4034-AE1E-95414DFBAC20@mac.com> John, The good news is that I can reproduce your problem. The bad news is that I don't know yet what's going wrong here. I'm filing a bugreport at bugs.python.org to ensure that this issue isn't forgotten, and hopefully someone that knows more about tkinter will chime in. My gut feeling is that this is an issue with the Tk framework, but with some luck it is possible to work around this issue. You'll see the same bad rendering if you open the preferences and scroll to the 'Osaka' font the font list. Ronald On 26 May, 2009, at 2:27, John Newman wrote: > Sorry, pasting the Chinese text into email wasn't very clever. I've > attached a txt file with the Chinese saved as utf-8. > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Mon 5/25/2009 11:30 AM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > > On 25 May, 2009, at 16:36, John Newman wrote: > > > Ronald > > See the attachment, where most of the Chinese glyphs are > correctly displayed, but not all. > > When I copy and paste these glyphs from Python 3 to JEdit, > all the glyphs display correctly, so the correct unicode code points > are there underlying the glyphs. I've tried most of the fonts > available to me in the GUI and I still can't get them all to display > properly. > > > Could you post the actual text-file as well? > > Ronald > > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Sun 5/24/2009 11:48 PM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > John, > > On 25 May, 2009, at 1:34, John Newman wrote: > > > Apologies if my question is ridiculously trivial - > I'm not a developer, just a relatively new user of Python 3.0.1 on > Mac OS 10.4.11. and I have only just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE > GUI on Windows XP I see all the Chinese glyphs displayed properly. > On my Mac, about one third of the Chinese characters are not > displayed correctly (just empty or black boxes in place of glyphs). > It doesn't matter whether I save/open texts as utf-8, utf-16, etc. > [The glyphs display fine in TextEdit, JEdit, Word etc.] And the > same kind of problem occurs when I scroll through the list of font > names in Preferences in IDLE: the names in Chinese glyphs have a > number of white or black boxes instead of the glyphs. > > I just assume that this has something to do with the > locale settings in IDLE? On my machine: > > >>> locale.getpreferredencoding() > 'mac-roman' > >>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, > '1252') and I presume that this difference is relevant to > understanding the different effects I get opening Chinese texts in > my Windows XP and my Mac. 'mac-roman' would not be my natural choice > of encoding if I am looking at Chinese text! I need an encoding > which can handle the range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do > in Python is somehow change the locale settings in some way which > will display Chnese glyphs? I'm at a loss to know what I should do > in order to display Chinese glyphs properly on the Mac. I tried > experimenting with "setlocale" but couldn't make progress. > > Any suggestions would be very welcome. > > > > This might be a font issue, although the default font > (Courier) seems to be capable of displaying unicode text and > therefore saving as UTF-8 should work. Another possible souce for > this problem is the GUI framework used by IDLE. > > Could you post an example of a file that shows the problem? > > Ronald > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue May 26 08:56:53 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 08:56:53 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> Message-ID: I've filed this as issue 6109 at the python bugtracker (http://bugs.python.org/issue6109 ). I haven't uploaded your example file yet, would you mind if I did upload the file to the tracker? Ronald On 26 May, 2009, at 2:27, John Newman wrote: > Sorry, pasting the Chinese text into email wasn't very clever. I've > attached a txt file with the Chinese saved as utf-8. > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Mon 5/25/2009 11:30 AM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > > On 25 May, 2009, at 16:36, John Newman wrote: > > > Ronald > > See the attachment, where most of the Chinese glyphs are > correctly displayed, but not all. > > When I copy and paste these glyphs from Python 3 to JEdit, > all the glyphs display correctly, so the correct unicode code points > are there underlying the glyphs. I've tried most of the fonts > available to me in the GUI and I still can't get them all to display > properly. > > > Could you post the actual text-file as well? > > Ronald > > > John > > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Sun 5/24/2009 11:48 PM > To: John Newman > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 > > John, > > On 25 May, 2009, at 1:34, John Newman wrote: > > > Apologies if my question is ridiculously trivial - > I'm not a developer, just a relatively new user of Python 3.0.1 on > Mac OS 10.4.11. and I have only just now joined the list. > > When I read in a Chinese text in the Python 3 IDLE > GUI on Windows XP I see all the Chinese glyphs displayed properly. > On my Mac, about one third of the Chinese characters are not > displayed correctly (just empty or black boxes in place of glyphs). > It doesn't matter whether I save/open texts as utf-8, utf-16, etc. > [The glyphs display fine in TextEdit, JEdit, Word etc.] And the > same kind of problem occurs when I scroll through the list of font > names in Preferences in IDLE: the names in Chinese glyphs have a > number of white or black boxes instead of the glyphs. > > I just assume that this has something to do with the > locale settings in IDLE? On my machine: > > >>> locale.getpreferredencoding() > 'mac-roman' > >>> locale.getlocale() > (None, None) > > In my Windows XP, the locale settings are (English, > '1252') and I presume that this difference is relevant to > understanding the different effects I get opening Chinese texts in > my Windows XP and my Mac. 'mac-roman' would not be my natural choice > of encoding if I am looking at Chinese text! I need an encoding > which can handle the range of glyphs we find in GB 18030, say. > > Am I being naive in thinking that all I have to do > in Python is somehow change the locale settings in some way which > will display Chnese glyphs? I'm at a loss to know what I should do > in order to display Chinese glyphs properly on the Mac. I tried > experimenting with "setlocale" but couldn't make progress. > > Any suggestions would be very welcome. > > > > This might be a font issue, although the default font > (Courier) seems to be capable of displaying unicode text and > therefore saving as UTF-8 should work. Another possible souce for > this problem is the GUI framework used by IDLE. > > Could you post an example of a file that shows the problem? > > Ronald > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue May 26 09:03:11 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 09:03:11 +0200 Subject: [Pythonmac-SIG] Py2App / Strip Not Correctly Working On .dSYM Directories In-Reply-To: References: Message-ID: <13A9A84B-B14B-4632-B33F-F30A2734830A@mac.com> That is indeed annoying. As a workaround you could remove the .dsym directories manually. This should obviously be fixed in py2app itself, when it strips debug symbols from executable files it should also remove .dsym directories. I've added this to my list, but wouldn't mind if someone would send me a patch before I get to that ;-) Ronald On 26 May, 2009, at 0:35, Kel Solaar wrote: > Hello :) > > Py2App seems to fail stripping my .dSYM directories. This one for > example is currently around 210 mo and bundled every time : > > MyApp.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM > > I have those related messages : > > /usr/bin/strip: input object file stripped: /Users/KelSolaar/ > Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/ > Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/ > QtGui_debug (for architecture ppc) > /usr/bin/strip: input object file stripped: /Users/KelSolaar/ > Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/ > Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/ > QtGui_debug (for architecture i386) > /usr/bin/strip: input object file stripped: /Users/KelSolaar/ > Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/ > Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/ > DWARF/QtCore_debug (for architecture ppc) > /usr/bin/strip: input object file stripped: /Users/KelSolaar/ > Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/ > Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/ > DWARF/QtCore_debug (for architecture i386) > stripping saved 25755260 bytes (208239343 / 233994603) > > Anyone have an idea ? > > Votre correspondant a choisi Hotmail et profite d'un stockage > quasiment illimit?. Cr?ez un compte Hotmail gratuitement ! > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From kelsolaar_fool at hotmail.com Tue May 26 09:07:13 2009 From: kelsolaar_fool at hotmail.com (Kel Solaar) Date: Tue, 26 May 2009 07:07:13 +0000 Subject: [Pythonmac-SIG] Py2App / Strip Not Correctly Working On .dSYM Directories In-Reply-To: <13A9A84B-B14B-4632-B33F-F30A2734830A@mac.com> References: <13A9A84B-B14B-4632-B33F-F30A2734830A@mac.com> Message-ID: Hi ! That's what I finally did, I tried to find why those debug libraries are included but didn't succeeded. Anyway my bunddle is now of a much better size :p Hope there is a clean solution coming Thomas CC: pythonmac-sig at python.org From: ronaldoussoren at mac.com To: kelsolaar_fool at hotmail.com Subject: Re: [Pythonmac-SIG] Py2App / Strip Not Correctly Working On .dSYM Directories Date: Tue, 26 May 2009 09:03:11 +0200 That is indeed annoying. As a workaround you could remove the .dsym directories manually. This should obviously be fixed in py2app itself, when it strips debug symbols from executable files it should also remove .dsym directories. I've added this to my list, but wouldn't mind if someone would send me a patch before I get to that ;-) Ronald On 26 May, 2009, at 0:35, Kel Solaar wrote:Hello :) Py2App seems to fail stripping my .dSYM directories. This one for example is currently around 210 mo and bundled every time : MyApp.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM I have those related messages : /usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/QtGui_debug (for architecture ppc)/usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtGui.framework/QtGui_debug.dSYM/Contents/Resources/DWARF/QtGui_debug (for architecture i386)/usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/DWARF/QtCore_debug (for architecture ppc)/usr/bin/strip: input object file stripped: /Users/KelSolaar/Documents/Developement/sIBL/src/dist/sIBL_GUI.app/Contents/Frameworks/QtCore.framework/QtCore_debug.dSYM/Contents/Resources/DWARF/QtCore_debug (for architecture i386)stripping saved 25755260 bytes (208239343 / 233994603) Anyone have an idea ? Votre correspondant a choisi Hotmail et profite d'un stockage quasiment illimit?. Cr?ez un compte Hotmail gratuitement ! _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig _________________________________________________________________ In?dit ! Des Emotic?nes D?jant?es! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Tue May 26 11:59:31 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 11:59:31 +0200 Subject: [Pythonmac-SIG] New beta release for pyobjc: 2.2b2 Message-ID: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> Hi, I've just pushed out a new beta release for PyObjC 2.2. This version should install without problems using "easy_install pyobjc==2.2b2", and fixes some other smallish issues as well. Support for OSX 10.4 is still fairly minimal: pyobjc-core and a number of framework wrappers do build on Tiger, but there are a lot of test failures (although a large subset of those are caused by issues in the test framework). Support for OSX 10.6 is non-existant for now due to the obvious reason ;-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue May 26 17:20:16 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 17:20:16 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> Message-ID: <1384089C-6076-40E8-A062-2534EFD55FCC@mac.com> I've found the source of this bug: Tcl/Tk's rendering of Unicode data is broken on OSX. Luckily this is fixed on Tcl/Tk 8.5, but that doesn't help you very much because the Python installers all link to the (system install of) Tcl/Tk 8.4 and that version is not binary compatible with the later version. Which brings the question: is there anyone on the list that would like to look into providing two copies of Tkinter in the binary installers on OSX? This would preferably install both copies of the tkinter extension and magicly select the right copy to use at runtime. That way Tkinter, and more importantly IDLE, would work out of the box and anyone that would need a better version of Tk can use that by installing Tk themself. I don't have time to work on this myself though. Ronald On 26 May, 2009, at 8:56, Ronald Oussoren wrote: > I've filed this as issue 6109 at the python bugtracker (http://bugs.python.org/issue6109 > ). I haven't uploaded your example file yet, would you mind if I did > upload the file to the tracker? > > Ronald > > On 26 May, 2009, at 2:27, John Newman wrote: > >> Sorry, pasting the Chinese text into email wasn't very clever. I've >> attached a txt file with the Chinese saved as utf-8. >> >> John >> >> >> -----Original Message----- >> From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] >> Sent: Mon 5/25/2009 11:30 AM >> To: John Newman >> Cc: pythonmac-sig at python.org >> Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 >> >> >> On 25 May, 2009, at 16:36, John Newman wrote: >> >> >> Ronald >> >> See the attachment, where most of the Chinese glyphs are >> correctly displayed, but not all. >> >> When I copy and paste these glyphs from Python 3 to JEdit, >> all the glyphs display correctly, so the correct unicode code >> points are there underlying the glyphs. I've tried most of the >> fonts available to me in the GUI and I still can't get them all to >> display properly. >> >> >> Could you post the actual text-file as well? >> >> Ronald >> >> >> John >> >> >> -----Original Message----- >> From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] >> Sent: Sun 5/24/2009 11:48 PM >> To: John Newman >> Cc: pythonmac-sig at python.org >> Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 >> >> John, >> >> On 25 May, 2009, at 1:34, John Newman wrote: >> >> >> Apologies if my question is ridiculously trivial - >> I'm not a developer, just a relatively new user of Python 3.0.1 on >> Mac OS 10.4.11. and I have only just now joined the list. >> >> When I read in a Chinese text in the Python 3 IDLE >> GUI on Windows XP I see all the Chinese glyphs displayed properly. >> On my Mac, about one third of the Chinese characters are not >> displayed correctly (just empty or black boxes in place of glyphs). >> It doesn't matter whether I save/open texts as utf-8, utf-16, etc. >> [The glyphs display fine in TextEdit, JEdit, Word etc.] And the >> same kind of problem occurs when I scroll through the list of font >> names in Preferences in IDLE: the names in Chinese glyphs have a >> number of white or black boxes instead of the glyphs. >> >> I just assume that this has something to do with >> the locale settings in IDLE? On my machine: >> >> >>> locale.getpreferredencoding() >> 'mac-roman' >> >>> locale.getlocale() >> (None, None) >> >> In my Windows XP, the locale settings are (English, >> '1252') and I presume that this difference is relevant to >> understanding the different effects I get opening Chinese texts in >> my Windows XP and my Mac. 'mac-roman' would not be my natural >> choice of encoding if I am looking at Chinese text! I need an >> encoding which can handle the range of glyphs we find in GB 18030, >> say. >> >> Am I being naive in thinking that all I have to do >> in Python is somehow change the locale settings in some way which >> will display Chnese glyphs? I'm at a loss to know what I should do >> in order to display Chinese glyphs properly on the Mac. I tried >> experimenting with "setlocale" but couldn't make progress. >> >> Any suggestions would be very welcome. >> >> >> >> This might be a font issue, although the default font >> (Courier) seems to be capable of displaying unicode text and >> therefore saving as UTF-8 should work. Another possible souce for >> this problem is the GUI framework used by IDLE. >> >> Could you post an example of a file that shows the problem? >> >> Ronald >> >> >> >> >> >> >> >> >> >> >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From Chris.Barker at noaa.gov Tue May 26 18:27:28 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 26 May 2009 09:27:28 -0700 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4BD7A952-D864-4034-AE1E-95414DFBAC20@mac.com> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> <4BD7A952-D864-4034-AE1E-95414DFBAC20@mac.com> Message-ID: <4A1C1870.3060307@noaa.gov> Ronald Oussoren wrote: > My gut feeling is that this is an issue with the Tk framework, ... >> The glyphs >> display fine in TextEdit, JEdit, Word etc.] As you stated you were a newbie, I thought I'd make it clear -- there is no need to use IDLE to do Python. It's just one of many options. at a minimum, all you need is a text editor and the command line. An editor that has good Python support is best.. there are lots of those, as well as a number of other IDEs. I'd pick one and get rolling with Python! Also, Python 3 is indeed the latest and greatest, but it is not in very wide use yet, so you will encounter these frustrations. If you just want to get something done with Python, 2.6 may be a better bet at this point -- much of what you learn will be transferable. -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.Barker at noaa.gov From ronaldoussoren at mac.com Tue May 26 19:34:29 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 19:34:29 +0200 Subject: [Pythonmac-SIG] [Pyobjc-dev] New beta release for pyobjc: 2.2b2 In-Reply-To: <87ABF26C-7017-4A17-ADA5-D91090BAEBF8@flownet.com> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> <87ABF26C-7017-4A17-ADA5-D91090BAEBF8@flownet.com> Message-ID: On 26 May, 2009, at 19:29, Ron Garret wrote: > > On May 26, 2009, at 2:59 AM, Ronald Oussoren wrote: > >> Hi, >> >> I've just pushed out a new beta release for PyObjC 2.2. This >> version should install without problems using "easy_install >> pyobjc==2.2b2", and fixes some other smallish issues as well. >> >> Support for OSX 10.4 is still fairly minimal: pyobjc-core and a >> number of framework wrappers do build on Tiger, but there are a lot >> of test failures (although a large subset of those are caused by >> issues in the test framework). >> >> Support for OSX 10.6 is non-existant for now due to the obvious >> reason ;-) > > It still doesn't work for me (on an Macbook Pro (Intel) running > 10.5.7): > > [ron at mickey:~]$ sudo easy_install pyobjc==2.2b2 > Searching for pyobjc==2.2b2 > Best match: pyobjc 2.2b2 > Processing pyobjc-2.2b2-py2.6.egg > pyobjc 2.2b2 is already the active version in easy-install.pth > > Using /Library/Frameworks/Python.framework/Versions/2.6/lib/ > python2.6/site-packages/pyobjc-2.2b2-py2.6.egg > Processing dependencies for pyobjc==2.2b2 > Searching for pyobjc-framework-ScreenSaver==2.2b2 > Reading http://pypi.python.org/simple/pyobjc-framework-ScreenSaver/ > Reading http://pyobjc.sourceforge.net > Best match: pyobjc-framework-ScreenSaver 2.2b2 > Downloading http://pypi.python.org/packages/source/p/pyobjc-framework-ScreenSaver/pyobjc-framework-ScreenSaver-2.2b2.tar.gz#md5 > =bff19c85e265409701c684f463e16c78 > Processing pyobjc-framework-ScreenSaver-2.2b2.tar.gz > Running pyobjc-framework-ScreenSaver-2.2b2/setup.py -q bdist_egg -- > dist-dir /var/folders/nT/nTiypn-v2RatkU+BYncrKU+++TI/-Tmp-/ > easy_install-1khDIF/pyobjc-framework-ScreenSaver-2.2b2/egg-dist-tmp- > Sy04w1 > /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ > distutils/dist.py:266: UserWarning: Unknown distribution option: > 'options' > warnings.warn(msg) > ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libTIFF.dylib, > file is not of required architecture for architecture ppc > collect2: ld returned 1 exit status > lipo: can't open input file: /var/folders/nT/nTiypn-v2RatkU+BYncrKU++ > +TI/-Tmp-//ccNC2XJP.out (No such file or directory) > error: Setup script exited with error: command 'gcc' failed with > exit status 1 You have non-universal libraries in /usr/local, but I don't understand why this is a problem because that library shouldn't be used at all. What's even more odd is that python tries to compile at all, there are binary eggs available for python2.6. Ronald > > rg > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue May 26 20:34:06 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 20:34:06 +0200 Subject: [Pythonmac-SIG] [Pyobjc-dev] New beta release for pyobjc: 2.2b2 In-Reply-To: <299EE4F4-C9E3-451C-A382-9D2DCC11273D@flownet.com> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> <87ABF26C-7017-4A17-ADA5-D91090BAEBF8@flownet.com> <299EE4F4-C9E3-451C-A382-9D2DCC11273D@flownet.com> Message-ID: <8CAB7868-A58E-41A6-9BB9-FD3C65FD9912@mac.com> On 26 May, 2009, at 20:25, Ron Garret wrote: > > On May 26, 2009, at 10:34 AM, Ronald Oussoren wrote: > >> >> On 26 May, 2009, at 19:29, Ron Garret wrote: >> >>> >>> On May 26, 2009, at 2:59 AM, Ronald Oussoren wrote: >>> >>>> Hi, >>>> >>>> I've just pushed out a new beta release for PyObjC 2.2. This >>>> version should install without problems using "easy_install >>>> pyobjc==2.2b2", and fixes some other smallish issues as well. >>>> >>>> Support for OSX 10.4 is still fairly minimal: pyobjc-core and a >>>> number of framework wrappers do build on Tiger, but there are a >>>> lot of test failures (although a large subset of those are caused >>>> by issues in the test framework). >>>> >>>> Support for OSX 10.6 is non-existant for now due to the obvious >>>> reason ;-) >>> >>> It still doesn't work for me (on an Macbook Pro (Intel) running >>> 10.5.7): >>> >>> [ron at mickey:~]$ sudo easy_install pyobjc==2.2b2 >>> Searching for pyobjc==2.2b2 >>> Best match: pyobjc 2.2b2 >>> Processing pyobjc-2.2b2-py2.6.egg >>> pyobjc 2.2b2 is already the active version in easy-install.pth >>> >>> Using /Library/Frameworks/Python.framework/Versions/2.6/lib/ >>> python2.6/site-packages/pyobjc-2.2b2-py2.6.egg >>> Processing dependencies for pyobjc==2.2b2 >>> Searching for pyobjc-framework-ScreenSaver==2.2b2 >>> Reading http://pypi.python.org/simple/pyobjc-framework-ScreenSaver/ >>> Reading http://pyobjc.sourceforge.net >>> Best match: pyobjc-framework-ScreenSaver 2.2b2 >>> Downloading http://pypi.python.org/packages/source/p/pyobjc-framework-ScreenSaver/pyobjc-framework-ScreenSaver-2.2b2.tar.gz#md5 >>> =bff19c85e265409701c684f463e16c78 >>> Processing pyobjc-framework-ScreenSaver-2.2b2.tar.gz >>> Running pyobjc-framework-ScreenSaver-2.2b2/setup.py -q bdist_egg -- >>> dist-dir /var/folders/nT/nTiypn-v2RatkU+BYncrKU+++TI/-Tmp-/ >>> easy_install-1khDIF/pyobjc-framework-ScreenSaver-2.2b2/egg-dist- >>> tmp-Sy04w1 >>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ >>> distutils/dist.py:266: UserWarning: Unknown distribution option: >>> 'options' >>> warnings.warn(msg) >>> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/ >>> libTIFF.dylib, file is not of required architecture for >>> architecture ppc >>> collect2: ld returned 1 exit status >>> lipo: can't open input file: /var/folders/nT/nTiypn-v2RatkU+BYncrKU >>> +++TI/-Tmp-//ccNC2XJP.out (No such file or directory) >>> error: Setup script exited with error: command 'gcc' failed with >>> exit status 1 >> >> >> You have non-universal libraries in /usr/local, but I don't >> understand why this is a problem because that library shouldn't be >> used at all. >> >> What's even more odd is that python tries to compile at all, there >> are binary eggs available for python2.6. >> >> Ronald > > I'm not quite sure what to make of this response. It seems to me > that if a Python library is trying to find a PPC binary on an Intel > machine that's a bug in the Python library. Also it's looking in > the MacOSX10.4u.sdk directory, but this machine is running 10.5 (. > 7), which seems like another bug. The compiler isn't that smart. If the linker looks for a library and stops at the first filename that matches without looking if it is for the right architecture. That means that if you happen to have a PPC library in /usr/local/lib and the compiler was actually looking for an intel one the search stops at the PPC library and you get a link error. If you have installed Python using the installer from the python.org site the situation is slightly more complicated: that installs a universal binary, which is a fat binary that contains both intel and ppc versions of the code. This means that all libraries that get linked into extensions must also be universal binaries and if they aren't you'll get link errors. > > So... is this a bug, or am I doing something stupid? If it's a bug, > am I the only person encountering it? Can I do anything to help fix > it? Can you manually download the source archive of pyobjc-framework- ScreenSaver from pypi.python.org and sent me the result of "python2.6 setup.py install. I'd also like to see the output of "file /usr/local/ lib/libTIFF.dylib", "python2.6 -c 'import distutils.util; print distutils.util.get_platform()' and 'python2.6 -V'. And finally: how did you install python, from source or using a binary installer? Please sent this information off-list because it isn't relevant for most readers. Ronald > > rg > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From dwf at cs.toronto.edu Tue May 26 21:50:29 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Tue, 26 May 2009 15:50:29 -0400 Subject: [Pythonmac-SIG] New beta release for pyobjc: 2.2b2 In-Reply-To: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> Message-ID: <59070696-EFEA-4655-8278-1A953FC6C302@cs.toronto.edu> On 26-May-09, at 5:59 AM, Ronald Oussoren wrote: > Support for OSX 10.4 is still fairly minimal: pyobjc-core and a > number of framework wrappers do build on Tiger, but there are a lot > of test failures (although a large subset of those are caused by > issues in the test framework). Am I right in assuming that for full support you need something built against the "10.5" SDK? I know I had problems building pyobjc2 against universal macpython 2.5. David From ronaldoussoren at mac.com Tue May 26 23:24:39 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 26 May 2009 23:24:39 +0200 Subject: [Pythonmac-SIG] New beta release for pyobjc: 2.2b2 In-Reply-To: <59070696-EFEA-4655-8278-1A953FC6C302@cs.toronto.edu> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> <59070696-EFEA-4655-8278-1A953FC6C302@cs.toronto.edu> Message-ID: <716CEA2E-7492-41A5-B54D-DD047A6A7540@mac.com> On 26 May, 2009, at 21:50, David Warde-Farley wrote: > On 26-May-09, at 5:59 AM, Ronald Oussoren wrote: > >> Support for OSX 10.4 is still fairly minimal: pyobjc-core and a >> number of framework wrappers do build on Tiger, but there are a lot >> of test failures (although a large subset of those are caused by >> issues in the test framework). > > Am I right in assuming that for full support you need something > built against the "10.5" SDK? I know I had problems building pyobjc2 > against universal macpython 2.5. I recently fixed a number of issues and PyObjC now builds out of the box with the Python.org distribution of python2.6. The setup.py files for pyobjc automaticly link to the right SDK, which is the 10.5 SDK when building on a 10.5 system. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From kw at codebykevin.com Wed May 27 00:14:49 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Tue, 26 May 2009 18:14:49 -0400 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <1384089C-6076-40E8-A062-2534EFD55FCC@mac.com> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> <1384089C-6076-40E8-A062-2534EFD55FCC@mac.com> Message-ID: <4A1C69D9.3070101@codebykevin.com> Ronald Oussoren wrote: > > Which brings the question: is there anyone on the list that would like > to look into providing two copies of Tkinter in the binary installers on > OSX? This would preferably install both copies of the tkinter extension > and magicly select the right copy to use at runtime. That way Tkinter, > and more importantly IDLE, would work out of the box and anyone that > would need a better version of Tk can use that by installing Tk themself. > What do you mean here, versions that link to 8.5 and 8.4? Is this feasible? Perhaps this should be directed to Benjamin Peterson, who builds the OS X installers. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From nad at acm.org Wed May 27 00:40:14 2009 From: nad at acm.org (Ned Deily) Date: Tue, 26 May 2009 15:40:14 -0700 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> <1384089C-6076-40E8-A062-2534EFD55FCC@mac.com> <4A1C69D9.3070101@codebykevin.com> Message-ID: In article <4A1C69D9.3070101 at codebykevin.com>, Kevin Walzer wrote: > Ronald Oussoren wrote: > > Which brings the question: is there anyone on the list that would like > > to look into providing two copies of Tkinter in the binary installers on > > OSX? This would preferably install both copies of the tkinter extension > > and magicly select the right copy to use at runtime. That way Tkinter, > > and more importantly IDLE, would work out of the box and anyone that > > would need a better version of Tk can use that by installing Tk themself. > > > What do you mean here, versions that link to 8.5 and 8.4? Is this feasible? > > Perhaps this should be directed to Benjamin Peterson, who builds the OS > X installers. Actually, Ronald does - usually - and is the core developer for the OS X port. It seems feasible, though probably a bit tricky, to produce a build process that would have the equivalent of two _tkinter.so's, one each linked with 8.4 and 8.5. In the worst case, one would have to do two loads, tweaking the /Library/Frameworks/{Tck/Tk} frameworks before each. The more interesting part would be initialization glue code at run time that looks at the run environment to see which Tk is installed and then loads and sets up all calls to the appropriate _tkinter.so. -- Ned Deily, nad at acm.org From santagada at gmail.com Wed May 27 05:16:17 2009 From: santagada at gmail.com (Leonardo Santagada) Date: Wed, 27 May 2009 00:16:17 -0300 Subject: [Pythonmac-SIG] New beta release for pyobjc: 2.2b2 In-Reply-To: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> Message-ID: <4F663BDF-D2D8-4BC9-A8CB-9EEE6A40380D@gmail.com> On May 26, 2009, at 6:59 AM, Ronald Oussoren wrote: > Hi, > > I've just pushed out a new beta release for PyObjC 2.2. This version > should install without problems using "easy_install pyobjc==2.2b2", > and fixes some other smallish issues as well. > > Support for OSX 10.4 is still fairly minimal: pyobjc-core and a > number of framework wrappers do build on Tiger, but there are a lot > of test failures (although a large subset of those are caused by > issues in the test framework). > > Support for OSX 10.6 is non-existant for now due to the obvious > reason ;-) > > Ronald It would be nice if the packager of pyobjc for macports posts here when the portfile is released so we (macports users) can know when this is avaliable to us. -- Leonardo Santagada santagada at gmail.com From ronaldoussoren at mac.com Wed May 27 07:48:30 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 27 May 2009 07:48:30 +0200 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 In-Reply-To: <4A1C69D9.3070101@codebykevin.com> References: <4344CD9CDCB75542A60FC99F20E9800AD7023D@artsml.arts.ualberta.ca> <269EC72F-3E7C-4AC6-9077-597B83092557@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD7023F@artsml.arts.ualberta.ca> <4A8BF11A-1149-4193-9374-1B734F22E176@mac.com> <4344CD9CDCB75542A60FC99F20E9800AD70242@artsml.arts.ualberta.ca> <1384089C-6076-40E8-A062-2534EFD55FCC@mac.com> <4A1C69D9.3070101@codebykevin.com> Message-ID: <26A3C104-1A90-4557-B04B-4675F87B34B0@mac.com> On 27 May, 2009, at 0:14, Kevin Walzer wrote: > Ronald Oussoren wrote: > >> Which brings the question: is there anyone on the list that would >> like to look into providing two copies of Tkinter in the binary >> installers on OSX? This would preferably install both copies of the >> tkinter extension and magicly select the right copy to use at >> runtime. That way Tkinter, and more importantly IDLE, would work >> out of the box and anyone that would need a better version of Tk >> can use that by installing Tk themself. > What do you mean here, versions that link to 8.5 and 8.4? Is this > feasible? It should be possible to have a "_tkinter84.so" and "_tkinter85.so" that are the same extension sources linked to two different versions of tk, then have a stub _tkinter.py module do something like: try: from _tkinter85 import * except ImportError: from _tkinter84 import * It should be able to arrange for this in build-installer.py script without having to change the global standard library. > > Perhaps this should be directed to Benjamin Peterson, who builds the > OS X installers. Benjamin is the release manager for python 2.7 and 3.1, he doesn't build the OSX installers. I, however, do build them ;-) Ronald > > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From hengist.podd at virgin.net Tue May 26 20:47:15 2009 From: hengist.podd at virgin.net (has) Date: Tue, 26 May 2009 19:47:15 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] New beta release for pyobjc: 2.2b2 In-Reply-To: References: Message-ID: Ronald Oussoren wrote: >> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libTIFF.dylib, >> file is not of required architecture for architecture ppc >> collect2: ld returned 1 exit status >> > You have non-universal libraries in /usr/local, but I don't > understand why this is a problem because that library shouldn't be > used at all. Guessing it's a Carbon dependency, which in turn is a Cocoa dependency. I've had similar reports from appscript users. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From geert at nznl.com Wed May 27 12:14:26 2009 From: geert at nznl.com (Geert Dekkers) Date: Wed, 27 May 2009 12:14:26 +0200 Subject: [Pythonmac-SIG] Python Core Graphics Question Message-ID: <79CBD871-06F5-4290-9F90-C8A89A61D2D3@nznl.com> Hi all Below is a piece of code that I found over in the quartz-dev list. I've been using this function unchanged in a batch processor, and it appears to leak memory quite substantially. So much so that my test machine (1Gb memory) , a mac mini, and my production xserve (2 Gb memory) both crashed using it. My dev machine, an imac (4Gb memory) slowed, but stayed up. I think I have the problem down to "croppedimg = srcimg.createWithImageInRect(cliprect)". If used with an image of suffient size, it quickly sucks up all available memory. Has anyone experienced similar problems using this method? Its Obj-C name is "CGContextCreateWithImageInRect". And I should think that one would only see something bad happening in some sort of batch processing. Incidentally, my workaround was to lower the size of the source image. But the process is still quite unstable. It brought down my xserve after processing 7000 of the 7600 odd items. I've pasted the original post below. And sorry for any cross - posting. Cheers, Geert ---------------------------------------------------------------------------------------------- Geert Dekkers Web Studio | 2e Keucheniusstraat 8HS 1051VR Amsterdam | +31(0)627224301 | http://nznl.net ---------------------------------------------------------------------------------------------- >> Thanks for you detailed reply Glen - much appreciated. >> You helped me to solve what i was trying to do by using >> CGImageCreateWithImageinRect as suggested. >> >> For anyone else interested here is some simple python code for >> making cropped thumbnails of any proportion and not loosing the >> aspect ratio of the original image. >> ...and its damn fast! >> >> ----------- #!/usr/bin/python >> >> from __future__ import division import CoreGraphics >> >> def resizeimage(srcimage,targetimage, tw, th): >> >> srcimg = >> CoreGraphics >> .CGImageImport >> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >> >> sw = srcimg.getWidth() >> sh = srcimg.getHeight() >> >> aspect = tw/th >> >> widthfactor = tw/sw >> heightfactor = th/sh >> >> if widthfactor < heightfactor: >> #src height stays the same >> #src width gets cropped >> cropwidth = sh * aspect >> x1 = ((sw-cropwidth)/2) >> y1 = 0 >> x2 = sw-((sw-cropwidth)) >> y2 = sh >> else: >> #src height gets cropped >> #src width stays the same >> cropheight = sw / aspect >> x1 = 0 >> y1 = ((sh-cropheight)/2) >> x2 = sw >> y2 = sh-((sh-cropheight)) >> >> cliprect = CoreGraphics.CGRectMake(x1, y1, x2, y2) >> croppedimg = srcimg.createWithImageInRect(cliprect) >> >> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >> c = CoreGraphics.CGBitmapContextCreateWithColor(tw, th, cs, >> (0,0,0,0)) >> >> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >> newRect = CoreGraphics.CGRectMake(0, 0, tw, th) >> c.drawImage(newRect, croppedimg) >> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >> >> resizeimage("/users/adam/Desktop/bootlogo4pa8.jpg", "/users/adam/ >> Desktop/aaaaa.jpg" , 80,80) >> >> >> >> >> >> >> >>> On Aug 12, 2008, at 3:41 AM, Glenn Cole wrote: >>> >>> Hi, Adam -- >>> >>> I'm no expert, but until others more knowledgeable respond, here's >>> my understanding. >>> >>> First, I suspect the fact that you're using Python won't matter at >>> all here. (It does in other circumstances, but I don't think so >>> here.) >>> >>> It sounds like you're looking for more support from Quartz for >>> your task than what's really there. In the end, I think it's going >>> to be more a choice of algorithm on your part. >>> >>> For example, given different aspect ratios, the new image could >>> either: >>> >>> 1. ignore the difference (i.e., the current behaviour) >>> 2. show the entire original image within the new target, >>> respecting the aspect ratio >>> 3. clip the original image to match the new aspect ratio >>> >>> For #2, you could shrink the target rect to match the aspect ratio >>> of the original image. >>> >>> For #3 (your goal), you could clip the original image to match the >>> target aspect ratio. However, page 250 of the outstanding >>> Programming With Quartz notes a few downsides to this, and >>> suggests using CGImageCreateWithImageInRect instead (first >>> available in Tiger) to define a "subimage" of the original image. >>> Again, though, you would need to determine yourself that the >>> subimage should ignore 100 pixels from the left and right sides of >>> the original image. >>> >>> At least, that's my take on things. We'll see what others say >>> (though they've tended to ignore Python questions in the past). >>> >>> Incidentally, the subject line says "Core Image resize question." >>> The code below has no reference to Core Image, and I'm pretty sure >>> that Core Image need not be involved in this task at all. (Perhaps >>> you mentioned Core Image because of the existence of its CICrop >>> filter, but I think that's not the best direction for the task at >>> hand.) >>> >>> --Glenn >>> >>> >>> On Aug 11, 2008, at 5:33 AM, Adam Jones wrote: >>> >>> Hi there i am wondering if someone can help me with this. Below is >>> the code i am using to resize and save a jpeg image. >>> >>> It works mint as but it obviously scales the image with no respect >>> for the aspect ratio. >>> >>> i want to be able to take an image and scale it proportionaly to a >>> square thumbnail. so for example a 800x600 image scaled to 80x80 >>> would need to loose 100pixels off the left and 100 pixels on the >>> right before scaling. >>> >>> Does any one know how to crop using python quartz or can i draw >>> the rec with the image off the canvas to achieve the same? >>> >>> Thanks Adam >>> >>> >>> ----------- #!/usr/bin/python >>> >>> import CoreGraphics >>> >>> def resizeimage(srcimage,targetimage, w, h): >>> >>> origImage = CoreGraphics .CGImageImport >>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >>> >>> origwidth = origImage.getWidth() # not used yet but will be once i >>> work out how to crop >>> origheight = origImage.getHeight() # not used yet but will be once >>> i work out how to crop >>> >>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >>> c = CoreGraphics.CGBitmapContextCreateWithColor(w, h, cs, (0,0,0,0)) >>> >>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >>> newRect = CoreGraphics.CGRectMake(0, 0, w, h) >>> c.drawImage(newRect, origImage) >>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >>> >>> >>> resizeimage(uploadedfile, "/svr/data/images/listings/%s/ >>> %s_160x90.jpg" % (str(listing_id), newimagename), 160,90) >>> >>> ------------- >>> >>> >>> _______________________________________________ Do not post admin >>> requests to the list. They will be ignored. Quartz-dev mailing >>> list (email at hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartz-dev/email at hidden >>> >>> This email sent to email at hidden >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Wed May 27 14:28:12 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 27 May 2009 08:28:12 -0400 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 Message-ID: <200905271228.n4RCSCEi021872@penicillin.media.mit.edu> --===============1820434273== Content-type: multipart/signed; boundary=Apple-Mail-82-903528184; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-82-903528184 Content-Type: multipart/alternative; boundary=Apple-Mail-81-903528086 --Apple-Mail-81-903528086 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I've found the source of this bug: Tcl/Tk's rendering of Unicode data is broken on OSX. Luckily this is fixed on Tcl/Tk 8.5, but that doesn't help you very much because the Python installers all link to the (system install of) Tcl/Tk 8.4 and that version is not binary compatible with the later version. Which brings the question: is there anyone on the list that would like to look into providing two copies of Tkinter in the binary installers on OSX? This would preferably install both copies of the tkinter extension and magicly select the right copy to use at runtime. That way Tkinter, and more importantly IDLE, would work out of the box and anyone that would need a better version of Tk can use that by installing Tk themself. I don't have time to work on this myself though. Ronald On 26 May, 2009, at 8:56, Ronald Oussoren wrote: > I've filed this as issue 6109 at the python bugtracker (http://bugs.python.org/issue6109 > ). I haven't uploaded your example file yet, would you mind if I did > upload the file to the tracker? > > Ronald > > On 26 May, 2009, at 2:27, John Newman wrote: > >> Sorry, pasting the Chinese text into email wasn't very clever. I've >> attached a txt file with the Chinese saved as utf-8. >> >> John >> >> >> -----Original Message----- >> From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] >> Sent: Mon 5/25/2009 11:30 AM >> To: John Newman >> Cc: pythonmac-sig at python.org >> Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 >> >> >> On 25 May, 2009, at 16:36, John Newman wrote: >> >> >> Ronald >> >> See the attachment, where most of the Chinese glyphs are >> correctly displayed, but not all. >> >> When I copy and paste these glyphs from Python 3 to JEdit, >> all the glyphs display correctly, so the correct unicode code >> points are there underlying the glyphs. I've tried most of the >> fonts available to me in the GUI and I still can't get them all to >> display properly. >> >> >> Could you post the actual text-file as well? >> >> Ronald >> >> >> John >> >> >> -----Original Message----- >> From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] >> Sent: Sun 5/24/2009 11:48 PM >> To: John Newman >> Cc: pythonmac-sig at python.org >> Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3 >> >> John, >> >> On 25 May, 2009, at 1:34, John Newman wrote: >> >> >> Apologies if my question is ridiculously trivial - >> I'm not a developer, just a relatively new user of Python 3.0.1 on >> Mac OS 10.4.11. and I have only just now joined the list. >> >> When I read in a Chinese text in the Python 3 IDLE >> GUI on Windows XP I see all the Chinese glyphs displayed properly. >> On my Mac, about one third of the Chinese characters are not >> displayed correctly (just empty or black boxes in place of glyphs). >> It doesn't matter whether I save/open texts as utf-8, utf-16, etc. >> [The glyphs display fine in TextEdit, JEdit, Word etc.] And the >> same kind of problem occurs when I scroll through the list of font >> names in Preferences in IDLE: the names in Chinese glyphs have a >> number of white or black boxes instead of the glyphs. >> >> I just assume that this has something to do with >> the locale settings in IDLE? On my machine: >> >> >>> locale.getpreferredencoding() >> 'mac-roman' >> >>> locale.getlocale() >> (None, None) >> >> In my Windows XP, the locale settings are (English, >> '1252') and I presume that this difference is relevant to >> understanding the different effects I get opening Chinese texts in >> my Windows XP and my Mac. 'mac-roman' would not be my natural >> choice of encoding if I am looking at Chinese text! I need an >> encoding which can handle the range of glyphs we find in GB 18030, >> say. >> >> Am I being naive in thinking that all I have to do >> in Python is somehow change the locale settings in some way which >> will display Chnese glyphs? I'm at a loss to know what I should do >> in order to display Chinese glyphs properly on the Mac. I tried >> experimenting with "setlocale" but couldn't make progress. >> >> Any suggestions would be very welcome. >> >> >> >> This might be a font issue, although the default font >> (Courier) seems to be capable of displaying unicode text and >> therefore saving as UTF-8 should work. Another possible souce for >> this problem is the GUI framework used by IDLE. >> >> Could you post an example of a file that shows the problem? >> >> Ronald >> >> >> >> >> >> >> >> >> >> >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig --Apple-Mail-81-903528086 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

I've found = the source of this bug: Tcl/Tk's rendering of Unicode data is broken on = OSX. Luckily this is fixed on Tcl/Tk 8.5, but that doesn't help you very = much because the Python installers all link to the (system install of) = Tcl/Tk 8.4 and that version is not binary compatible with the later = version.

Which brings the question: is there = anyone on the list that would like to look into providing two copies of = Tkinter in the binary installers on OSX? This would preferably install = both copies of the tkinter extension and magicly select the right copy = to use at runtime. That way Tkinter, and more importantly IDLE, would = work out of the box and anyone that would need a better version of Tk = can use that by installing Tk themself. =  

I don't have time to work on this myself = though.

Ronald

On = 26 May, 2009, at 8:56, Ronald Oussoren wrote:

I've filed this as issue 6109 = at the python bugtracker (http://bugs.python.org/issue6109= ). I haven't uploaded your example file yet, would you mind if I did = upload the file to the = tracker?

Ronald

On 26 May, = 2009, at 2:27, John Newman wrote:

=

Sorry, = pasting the Chinese text into email wasn't very clever. I've attached a = txt file with the Chinese saved as utf-8.

John


= -----Original Message-----
From: Ronald Oussoren [mailto:ronaldoussoren at mac.com]<= br> Sent: Mon 5/25/2009 11:30 AM
To: John Newman
Cc: pythonmac-sig at python.org
= Subject: Re: [Pythonmac-SIG] Chinese glyphs in Python 3


On = 25 May, 2009, at 16:36, John Newman wrote:


=         Ronald
=        
=         See the attachment, where = most of the Chinese glyphs are correctly displayed, but not all.
=        
=         When I copy and paste these = glyphs from Python 3 to JEdit, all the glyphs display correctly, so the = correct unicode code points are there underlying the glyphs. I've tried = most of the fonts available to me in the GUI and I still can't get them = all to display properly.
=        

Could you post the = actual text-file as well?

Ronald

=        
=         John
=        
=        
=         -----Original = Message-----
        From: Ronald = Oussoren [mailto:ronaldoussoren at mac.com]<= br>         Sent: Sun 5/24/2009 11:48 = PM
        To: John Newman
=         Cc: pythonmac-sig at python.org
=         Subject: Re: [Pythonmac-SIG] = Chinese glyphs in Python 3
=        
=         John,
=        
=         On 25 May, 2009, at 1:34, = John Newman wrote:
       
=        
=         =         Apologies if my question is = ridiculously trivial - I'm not a developer, just a relatively new user = of Python 3.0.1 on Mac OS 10.4.11. and I have only just now joined the = list.
        =       
=         =         When I read in a Chinese text = in the Python 3 IDLE GUI on Windows XP I see all the Chinese glyphs = displayed properly. On my Mac, about one third of the Chinese characters = are not displayed correctly (just empty or black boxes in place of = glyphs). It doesn't matter whether I save/open texts as utf-8, utf-16, = etc. [The glyphs display fine in TextEdit, JEdit, Word etc.]  And = the same kind of problem occurs when I scroll through the list of font = names in Preferences in IDLE: the names in Chinese glyphs have a number = of white or black boxes instead of the glyphs.
=         =       
=         =         I just assume that this has = something to do with the locale settings in IDLE? On my machine:
=         =       
=         =         >>> = locale.getpreferredencoding()
=         =         'mac-roman'
=         =         >>> = locale.getlocale()
        =         (None, None)
=         =       
=         =         In my Windows XP, the locale = settings are (English, '1252') and I presume that this difference is = relevant to understanding the different effects I get opening Chinese = texts in my Windows XP and my Mac. 'mac-roman' would not be my natural = choice of encoding if I am looking at Chinese text! I need an encoding = which can handle the range of glyphs we find in GB 18030, say.
=         =       
=         =         Am I being naive in thinking = that all I have to do in Python is somehow change the locale settings in = some way which will display Chnese glyphs?  I'm at a loss to know = what I should do in order to display Chinese glyphs properly on the Mac. = I tried experimenting with "setlocale" but couldn't make progress.
=         =       
=         =         Any suggestions would be very = welcome.
        =       
=        
=        
=         This might be a font issue, = although the default font (Courier) seems to be capable of displaying = unicode text and therefore saving as UTF-8 should work.  Another = possible souce for this problem is the GUI framework used by IDLE.
=        
=          Could you post an = example of a file that shows the problem?
=        
=         Ronald
=        
=        
=        
=        

=         <glyphs.jpg>

=


= <Chinese.txt>

_= ______________________________________________
Pythonmac-SIG maillist =  -  Pythonmac-SIG at python.org
<= a = href=3D"http://mail.python.org/mailman/listinfo/pythonmac-sig">http://mail= .python.org/mailman/listinfo/pythonmac-sig

<= /body>= --Apple-Mail-81-903528086-- --Apple-Mail-82-903528184 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPzCCBTsw ggMjoAMCAQICAwQdWTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNzEwMDQxNDQ3MjhaFw0w OTEwMDMxNDQ3MjhaMEExGDAWBgNVBAMTD1JvbmFsZCBPdXNzb3JlbjElMCMGCSqGSIb3DQEJARYW cm9uYWxkb3Vzc29yZW5AbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOwe sF7LDCvCwKd+kX0mG+60zixF28kOCZ6NDlTMUTNmaGTTpPypY4DjZIWRKrcKhnwN9m7Qe4kIRq8W sNw6KGO1hg2xXspOmA19gadEMILN41Zi4UFPLt3DJv36kTE4ZEZPn3lJtLL0/1kK2Qrnfo16Rnoo wfh4E4qBO9xdbUVXhbsC4Ou5YSC9oGfRveDR6ondmVcToM1oGS9ycPleJx0JgOPKBpDFG8xMdMD1 bnBolVof+19yIdKcuQKTWgayrrqHzpnhe2Ue2+6XJNgXEs92hSjBKtMr+xCppM38OesTpyzFxvMb iAVEzyWkRrKL4yuTmoSR4LOPAmm/CCPdQB8CAwEAAaOCAQIwgf8wDAYDVR0TAQH/BAIwADBWBglg hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3Zl ciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsG AQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMCEGA1UdEQQaMBiBFnJvbmFsZG91c3NvcmVu QG1hYy5jb20wDQYJKoZIhvcNAQEFBQADggIBAHvpWk6DZ6OGMDcyOWPlYhuXNVftnlz8jZNUKzDh b+zLKNd40GC2nN2sZltZ2NJLItN1DblSpWh7Y151e3mYJEYnWWtpiDUB0C6J8lS7R1BS1IY6NJNj FC/i4FRc8f/TlMizcNUipB2qXDPUQxb4IIlTq8T12lHeSlbUzueiJaEIqnWxV1PZPD7gLJKo+x+g j5cjk1KHiQgHgKcuS4E6O+eiVlijJ/I3+QF6q+hcHdGS+Uo5VVUjFVxsVQ7Zatumq/Gyj1ly8yr9 KQAO9swqEutHF6CfzKQ5cGNvBiYWuOc2XbRIElRNVgvnYz/ysaVGLqssj3iNN3+h8F0EI+EpUMt3 TMDYo78GZGe6no0VizOz34uHvIu0hH8CDet6ZzCy2iodGCyyzGQx51XO0g2r3BYbhY39JfbyJU7m W3QK33yKHW8gACAARNuIwJOJiydyGbAkmsg7csHcxAk9ICrgPW8xWWmswOhPYG2sBkVtRFoZ5MT0 h8oIMUY3T0GFpTwvtKBJcNjPjloSR9FlwlgbxvcaypqFnT/FrPX0N9lCZCzSu8tUjiqns1vjOEgF x5RUY9ouAsmOdXrHNC3lfiwfD2pAKvDYSgEM5cJAqQjiUDdL7Y3P6M3rVjuUYdSPvS5zU3hCQtm+ dTb5q2QNhgHq1PI35MQfaT+mXF8Yn9LsyK2tMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9v dCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwQdWTAJ BgUrDgMCGgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w OTA1MjYxNTIwMTdaMCMGCSqGSIb3DQEJBDEWBBQ02hYFbyiYRkO/sASF7AbFuAYV4TCBkQYJKwYB BAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMEHVkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMEHVkwDQYJKoZIhvcNAQEBBQAEggEACfPwp+iJU2R3YKA2FdnaCImcXwIwfiQ++OMwryxCuJ2/ G6CsyhS/nBVPQBjG7lYyqcD87bmA2cg/PLTQAdRMUTI5drM76LE+Cfw7c8tw/khAtHnAm8yuQu2L XVcbNslIPPNJzfkogki3KFU3Y0mhLylrZ/K6BSl0MKPAZTXFx26LtPvoWMT817GF/+yosqUGJbJK ZThCDV4figJNR8JEj+GO+/FQMKlAurk/zJck48eDy3SmvHwBr1xTbIXTNI9NO4AuH3PXlkKS/wq5 pNDp3dicn5ZXkotUdRGwhBS6iwUbRCKMmiCmBSjY85xHaZA3qaU4StGErw6U9+A5y3ME0wAAAAAA AA== --Apple-Mail-82-903528184-- --===============1820434273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --===============1820434273==-- From rowen at u.washington.edu Wed May 27 21:18:54 2009 From: rowen at u.washington.edu (Russell E. Owen) Date: Wed, 27 May 2009 12:18:54 -0700 Subject: [Pythonmac-SIG] Chinese glyphs in Python 3 References: <200905271228.n4RCSCEi021872@penicillin.media.mit.edu> Message-ID: In article <200905271228.n4RCSCEi021872 at penicillin.media.mit.edu>, Ronald Oussoren wrote: > I've found the source of this bug: Tcl/Tk's rendering of Unicode data > is broken on OSX. Luckily this is fixed on Tcl/Tk 8.5, but that > doesn't help you very much because the Python installers all link to > the (system install of) Tcl/Tk 8.4 and that version is not binary > compatible with the later version. If this bug is fixed in Tcl/Tk 8.4.19 then it would suffice to build the MacOS X python in such a way that it can use a 3rd-party installed Tcl/Tk 8.4. Unfortunately that is not the case of the recent python.org MacOS X binary installers (at least those that I tried); this is an issue I'd be happy to help with if I can do anything. (I can build Python in such a way at it is compatible, but I don't know how to package it into an installer.) > Which brings the question: is there anyone on the list that would like > to look into providing two copies of Tkinter in the binary installers > on OSX? This would preferably install both copies of the tkinter > extension and magicly select the right copy to use at runtime. That > way Tkinter, and more importantly IDLE, would work out of the box and > anyone that would need a better version of Tk can use that by > installing Tk themself. An intriguing idea, though it sounds a bit dangerous to me that it would work automatically because of the significant differences between the two (or at least the significant enhancements in 8.5). Might it make sense to provide a separate installer that would replace _tkinter with an 8.5 version, but the user would run that explicitly only if they had installed 8.5? -- Russell P.S. is there any public news or rumors if Snow Leopard has Tcl/Tk 8.5? From ron at flownet.com Tue May 26 19:29:28 2009 From: ron at flownet.com (Ron Garret) Date: Tue, 26 May 2009 10:29:28 -0700 Subject: [Pythonmac-SIG] [Pyobjc-dev] New beta release for pyobjc: 2.2b2 In-Reply-To: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> Message-ID: <87ABF26C-7017-4A17-ADA5-D91090BAEBF8@flownet.com> On May 26, 2009, at 2:59 AM, Ronald Oussoren wrote: > Hi, > > I've just pushed out a new beta release for PyObjC 2.2. This version > should install without problems using "easy_install pyobjc==2.2b2", > and fixes some other smallish issues as well. > > Support for OSX 10.4 is still fairly minimal: pyobjc-core and a > number of framework wrappers do build on Tiger, but there are a lot > of test failures (although a large subset of those are caused by > issues in the test framework). > > Support for OSX 10.6 is non-existant for now due to the obvious > reason ;-) It still doesn't work for me (on an Macbook Pro (Intel) running 10.5.7): [ron at mickey:~]$ sudo easy_install pyobjc==2.2b2 Searching for pyobjc==2.2b2 Best match: pyobjc 2.2b2 Processing pyobjc-2.2b2-py2.6.egg pyobjc 2.2b2 is already the active version in easy-install.pth Using /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ site-packages/pyobjc-2.2b2-py2.6.egg Processing dependencies for pyobjc==2.2b2 Searching for pyobjc-framework-ScreenSaver==2.2b2 Reading http://pypi.python.org/simple/pyobjc-framework-ScreenSaver/ Reading http://pyobjc.sourceforge.net Best match: pyobjc-framework-ScreenSaver 2.2b2 Downloading http://pypi.python.org/packages/source/p/pyobjc-framework-ScreenSaver/pyobjc-framework-ScreenSaver-2.2b2.tar.gz#md5 =bff19c85e265409701c684f463e16c78 Processing pyobjc-framework-ScreenSaver-2.2b2.tar.gz Running pyobjc-framework-ScreenSaver-2.2b2/setup.py -q bdist_egg -- dist-dir /var/folders/nT/nTiypn-v2RatkU+BYncrKU+++TI/-Tmp-/ easy_install-1khDIF/pyobjc-framework-ScreenSaver-2.2b2/egg-dist-tmp- Sy04w1 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ distutils/dist.py:266: UserWarning: Unknown distribution option: 'options' warnings.warn(msg) ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libTIFF.dylib, file is not of required architecture for architecture ppc collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/nT/nTiypn-v2RatkU+BYncrKU++ +TI/-Tmp-//ccNC2XJP.out (No such file or directory) error: Setup script exited with error: command 'gcc' failed with exit status 1 rg From ron at flownet.com Tue May 26 20:25:33 2009 From: ron at flownet.com (Ron Garret) Date: Tue, 26 May 2009 11:25:33 -0700 Subject: [Pythonmac-SIG] [Pyobjc-dev] New beta release for pyobjc: 2.2b2 In-Reply-To: References: <4C59A930-97E0-4193-A582-6F457656AC20@mac.com> <87ABF26C-7017-4A17-ADA5-D91090BAEBF8@flownet.com> Message-ID: <299EE4F4-C9E3-451C-A382-9D2DCC11273D@flownet.com> On May 26, 2009, at 10:34 AM, Ronald Oussoren wrote: > > On 26 May, 2009, at 19:29, Ron Garret wrote: > >> >> On May 26, 2009, at 2:59 AM, Ronald Oussoren wrote: >> >>> Hi, >>> >>> I've just pushed out a new beta release for PyObjC 2.2. This >>> version should install without problems using "easy_install >>> pyobjc==2.2b2", and fixes some other smallish issues as well. >>> >>> Support for OSX 10.4 is still fairly minimal: pyobjc-core and a >>> number of framework wrappers do build on Tiger, but there are a >>> lot of test failures (although a large subset of those are caused >>> by issues in the test framework). >>> >>> Support for OSX 10.6 is non-existant for now due to the obvious >>> reason ;-) >> >> It still doesn't work for me (on an Macbook Pro (Intel) running >> 10.5.7): >> >> [ron at mickey:~]$ sudo easy_install pyobjc==2.2b2 >> Searching for pyobjc==2.2b2 >> Best match: pyobjc 2.2b2 >> Processing pyobjc-2.2b2-py2.6.egg >> pyobjc 2.2b2 is already the active version in easy-install.pth >> >> Using /Library/Frameworks/Python.framework/Versions/2.6/lib/ >> python2.6/site-packages/pyobjc-2.2b2-py2.6.egg >> Processing dependencies for pyobjc==2.2b2 >> Searching for pyobjc-framework-ScreenSaver==2.2b2 >> Reading http://pypi.python.org/simple/pyobjc-framework-ScreenSaver/ >> Reading http://pyobjc.sourceforge.net >> Best match: pyobjc-framework-ScreenSaver 2.2b2 >> Downloading http://pypi.python.org/packages/source/p/pyobjc-framework-ScreenSaver/pyobjc-framework-ScreenSaver-2.2b2.tar.gz#md5 >> =bff19c85e265409701c684f463e16c78 >> Processing pyobjc-framework-ScreenSaver-2.2b2.tar.gz >> Running pyobjc-framework-ScreenSaver-2.2b2/setup.py -q bdist_egg -- >> dist-dir /var/folders/nT/nTiypn-v2RatkU+BYncrKU+++TI/-Tmp-/ >> easy_install-1khDIF/pyobjc-framework-ScreenSaver-2.2b2/egg-dist-tmp- >> Sy04w1 >> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ >> distutils/dist.py:266: UserWarning: Unknown distribution option: >> 'options' >> warnings.warn(msg) >> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libTIFF.dylib, >> file is not of required architecture for architecture ppc >> collect2: ld returned 1 exit status >> lipo: can't open input file: /var/folders/nT/nTiypn-v2RatkU+BYncrKU+ >> ++TI/-Tmp-//ccNC2XJP.out (No such file or directory) >> error: Setup script exited with error: command 'gcc' failed with >> exit status 1 > > > You have non-universal libraries in /usr/local, but I don't > understand why this is a problem because that library shouldn't be > used at all. > > What's even more odd is that python tries to compile at all, there > are binary eggs available for python2.6. > > Ronald I'm not quite sure what to make of this response. It seems to me that if a Python library is trying to find a PPC binary on an Intel machine that's a bug in the Python library. Also it's looking in the MacOSX10.4u.sdk directory, but this machine is running 10.5 (.7), which seems like another bug. So... is this a bug, or am I doing something stupid? If it's a bug, am I the only person encountering it? Can I do anything to help fix it? rg From trhaynes at gmail.com Thu May 28 23:02:16 2009 From: trhaynes at gmail.com (Tom Haynes) Date: Thu, 28 May 2009 17:02:16 -0400 Subject: [Pythonmac-SIG] py2app and OpenGL, "No module named util" in ctypes Message-ID: <904f086b0905281402k26f84583y4fc318eaa4849652@mail.gmail.com> I'm trying to use py2app to package an OpenGL app, so first I tried to build the example here http://svn.pythonmac.org/py2app/py2app/trunk/examples/PyOpenGL/ and I get the error: > File "/opt/local/lib/python2.5/site-packages/PyOpenGL-3.0.0c1-py2.5.egg/OpenGL/p latform/darwin.py", line 24, in > import ctypes, ctypes.util >ImportError: No module named util >2009-05-28 13:55:06.819 lesson5[19965:10b] lesson5 Error >2009-05-28 13:55:06.821 lesson5[19965:10b] lesson5 Error >An unexpected error has occurred during execution of the main script >ImportError: No module named util But when I open up my python interactive interpreter and "import ctypes.util", it works fine (using lesson5.app/Contents/MacOS/python, too). Thanks for the help. -tom From mysterytramp at yahoo.com Sun May 31 16:12:31 2009 From: mysterytramp at yahoo.com (M Tramp) Date: Sun, 31 May 2009 07:12:31 -0700 (PDT) Subject: [Pythonmac-SIG] Gtk issues Message-ID: <786164.38114.qm@web57207.mail.re3.yahoo.com> [A bit of a noob here, running Tiger on a Mac mini] Spent well over an hour last night with MacPorts, installing modules necessary to run gramps. The software needs several modules, particularly Gtk. For the past couple of weeks, I've tried several methods of installing Gtk, including Fink and trying to compile it myself, and while I get few/no errors, gramps each time burps on the line: import gtk and replies: "No module named gtk" The relevant batch of code ... >> try: import pygtk pygtk.require('2.0') except ImportError: pass import gtk from gtk import glade import gobject << I add the pygtk info because the error exception doesn't appear to check for much, so I'm wondering if that isn't a cause of the gtk problem. If I type: port installed gtk2 I get: gtk2 @2.16.1_4+darwin_8+x11 (active) If I type: port installed py25-gtk I get: py25-gtk @2.14.1_0 (active) My hunch is that this is a sys.path problem. But if so, I don't know what file to look for so that I can add the path to sys.path. There are several files with "gtk" in the name on my hard drive, "_gtk.so"? mt From beegee63 at gmail.com Sun May 31 20:24:12 2009 From: beegee63 at gmail.com (beegee beegee) Date: Sun, 31 May 2009 23:54:12 +0530 Subject: [Pythonmac-SIG] where do I store my Python programs Message-ID: <7122b8730905311124h7a75753fi5dcde8f130c47ee3@mail.gmail.com> Hi All, I have a mac mini mac os 10.4.11. I also have aquamac for an editor. I have some simple programs stored in text files. and I try to run them using aquamac, but I get the following error message steps taken: launch aquamacs File -> new buffer in new window File ->new buffer in mode python Python-> start interpreter >>> python first.py File "", line 1 python first.py ^ SyntaxError: invalid syntax >>> I would like to know if this is a case of files not being seen by the python interpreter or what could be done Regards From janssen at parc.com Sun May 31 20:29:43 2009 From: janssen at parc.com (Bill Janssen) Date: Sun, 31 May 2009 11:29:43 PDT Subject: [Pythonmac-SIG] crankd for monitoring OS X Message-ID: <85528.1243794583@parc.com> I ran across this project yesterday, and thought I'd point it out to others: http://code.google.com/p/pymacadmin/ "A collection of Python utilities for Mac OS X system administration." In particular, check out "crankd", a Python program for monitoring various kinds of OS X events. Bill From beegee63 at gmail.com Sun May 31 20:33:31 2009 From: beegee63 at gmail.com (beegee beegee) Date: Mon, 1 Jun 2009 00:03:31 +0530 Subject: [Pythonmac-SIG] Whats the invalid syntax about Message-ID: <7122b8730905311133g4c5cccaejf771d0a9b4477043@mail.gmail.com> Hello, I have a mac mini mac os 10.4.11 aquamacs 22.3.1. I wrote this program (please see below) after i got a python prompt (this was after starting the interpreter in aquamacs) please suggest what could have gone wrong here why am i getting a syntax error some_list = [3,6,2,5] i=1 while i < 3: print some_list[i], ";" i=i+1 print some_list[3] >>> File "", line 4 print some_list[3] ^ SyntaxError: invalid syntax >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Sun May 31 20:34:20 2009 From: janssen at parc.com (Bill Janssen) Date: Sun, 31 May 2009 11:34:20 PDT Subject: [Pythonmac-SIG] question about garbage collection with NSApplication.run() Message-ID: <85617.1243794860@parc.com> I'm writing a Python program that has a main that looks like this: application = NSApplication.sharedApplication() # set up handler for network change notification SCDynamicStoreSetNotificationKeys(DYNSTORE, None, [NETWORK_KEY,]) # Get a CFRunLoopSource for our store session and add it to the application's runloop: CFRunLoopAddSource( NSRunLoop.currentRunLoop().getCFRunLoop(), SCDynamicStoreCreateRunLoopSource(None, DYNSTORE, 0), kCFRunLoopCommonModes ) # add a timer for application scan events timer = NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_( periodicity, scanner, objc.selector(scanner.scan, signature="v@:"), None, True) # using an NSRunLoop avoids Activity Monitor complaining about "not responding" application.run() Do I need to do anything about NSAutoreleasePools? My understanding is that this is single-threaded, and that NSApplication.run will handle periodic drainage of the default main thread release pool. Bill From skip at pobox.com Sun May 31 21:09:43 2009 From: skip at pobox.com (skip at pobox.com) Date: Sun, 31 May 2009 14:09:43 -0500 Subject: [Pythonmac-SIG] Whats the invalid syntax about In-Reply-To: <7122b8730905311133g4c5cccaejf771d0a9b4477043@mail.gmail.com> References: <7122b8730905311133g4c5cccaejf771d0a9b4477043@mail.gmail.com> Message-ID: <18978.54775.129462.922452@montanaro.dyndns.org> >> please suggest what could have gone wrong here why am i getting a >> syntax error It's a quirk of the interactive interpreter. To terminate a loop you need a blank input line: >>> some_list = [3,6,2,5] >>> i = 1 >>> while i < 3: ... print some_list[i], ";" ... i = i + 1 ... 6 ; 2 ; >>> print some_list[3] 5 -- Skip Montanaro - skip at pobox.com - http://www.smontanaro.net/ America's vaunted "free press" notwithstanding, story ideas that expose the unseemly side of actual or potential advertisers tend to fall by the wayside. Not quite sure why. -- Jim Thornton From piet at cs.uu.nl Sun May 31 22:53:38 2009 From: piet at cs.uu.nl (Piet van Oostrum) Date: Sun, 31 May 2009 22:53:38 +0200 Subject: [Pythonmac-SIG] where do I store my Python programs In-Reply-To: <7122b8730905311124h7a75753fi5dcde8f130c47ee3@mail.gmail.com> (beegee beegee's message of "Sun\, 31 May 2009 23\:54\:12 +0530") References: <7122b8730905311124h7a75753fi5dcde8f130c47ee3@mail.gmail.com> Message-ID: >>>>> beegee beegee (bb) wrote: >bb> Hi All, I have a mac mini mac os 10.4.11. I also have aquamac for an editor. >bb> I have some simple programs stored in text files. and I try to run >bb> them using aquamac, but I get the following error message >bb> steps taken: >bb> launch aquamacs >bb> File -> new buffer in new window >bb> File ->new buffer in mode python >bb> Python-> start interpreter >bb> >>> python first.py >bb> File "", line 1 >bb> python first.py >bb> ^ >bb> SyntaxError: invalid syntax >>>>> >bb> I would like to know if this is a case of files not being seen by the >bb> python interpreter or what could be done The Python interpreter expects a Python statement or expression, like 2+3 or print "Hello world". `python first.py' is not a python command nor an expression but a shell command. So you have to issue this in a shell. You can create a shell in Aquamacs by typing `ESC x shell' (without the quotes). Another possibility, after Python-> start interpreter, is Python->Execute Buffer. For small snippets of code this may be easier, but for complete programs the shell method may be better. A shell can also be run outside of Aquamacs with the Terminal application. -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From njriley at uiuc.edu Sun May 31 22:54:45 2009 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun, 31 May 2009 15:54:45 -0500 Subject: [Pythonmac-SIG] Can't get ASDictionary to work (py2app problems?) Message-ID: <20090531205445.GA27703@uiuc.edu> Hi, I'm trying to use appscript on my MacBook Pro running OS X 10.5.7 and the stock Apple Python. It's never had appscript installed before. However, I can't get the binary ASDictionary I downloaded to run: Traceback (most recent call last): File "/Developer/Applications/appscript/ASDictionary.app/Contents/Resources/__boot__.py", line 31, in _run('ASDictionary.py') File "/Developer/Applications/appscript/ASDictionary.app/Contents/Resources/__boot__.py", line 28, in _run execfile(path, globals(), globals()) File "/Developer/Applications/appscript/ASDictionary.app/Contents/Resources/ASDictionary.py", line 17, in import osax, appscript, mactypes File "build/bdist.macosx-10.3-i386/egg/osax.py", line 38, in File "build/bdist.macosx-10.3-i386/egg/aem/aemsend.py", line 82, in send aem.aemsend.EventError: Command failed: Application could not handle this command. (-1708) 2009-05-31 15:42:43.946 ASDictionary[4551:10b] ASDictionary Error 2009-05-31 15:42:43.948 ASDictionary[4551:10b] ASDictionary Error An unexpected error has occurred during execution of the main script EventError: Command failed: Application could not handle this command. (-1708) So I tried building newer versions of everything, which helped in the past. I did run into a problem with modulegraph and newer versions of setuptools but that was easily fixed. Now I seem to be having issues with py2app. First, if I try to use the bundled PyObjC, py2app doesn't pick it up, so I get an error trying to import 'objc'. Next, I tried installing the current PyObjC, but now I get a truly weird error running the built ASDictionary: Traceback (most recent call last): File "/Users/nicholas/src/ASDictionary/src/dist/ASDictionary.app/Contents/Resources/__boot__.py", line 31, in _run('ASDictionary.py') File "/Users/nicholas/src/ASDictionary/src/dist/ASDictionary.app/Contents/Resources/__boot__.py", line 28, in _run execfile(path, globals(), globals()) File "/Users/nicholas/src/ASDictionary/src/dist/ASDictionary.app/Contents/Resources/ASDictionary.py", line 11, in import objc File "objc/__init__.pyc", line 22, in File "objc/__init__.pyc", line 19, in _update File "objc/_objc.pyc", line 18, in File "objc/_objc.pyc", line 15, in __load ImportError: '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/objc/_objc.so' not found 2009-05-31 15:47:49.610 ASDictionary[4560:10b] ASDictionary Error 2009-05-31 15:47:49.612 ASDictionary[4560:10b] ASDictionary Error An unexpected error has occurred during execution of the main script ImportError: '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/objc/_objc.so' not found Why is it trying to look for _objc.so *there*? It's actually in /Library/Python/2.5/site-packages/pyobjc_core-2.2b2-py2.5-macosx-10.5-i386.egg/objc/_objc.so. If I build ASDictionary with py2app -A, I'm back to the old error about not being able to import objc: Traceback (most recent call last): File "/Users/nicholas/src/ASDictionary/src/dist/ASDictionary.app/Contents/Resources/__boot__.py", line 58, in _run(('\x00\x00\x00\x00\x01(\x00\x02\x00\x00\x04Babs\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc1V\xc6\x82H+\x00\x00\x01-\xf1\xbf\x0fASDictionary.py\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01-\xf2\x03\xc6HIk\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00I \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x08\x00\x00\xc1W\x0c\xd2\x00\x00\x00\x11\x00\x08\x00\x00\xc6H\x8f\xbb\x00\x00\x00\x0e\x00 \x00\x0f\x00A\x00S\x00D\x00i\x00c\x00t\x00i\x00o\x00n\x00a\x00r\x00y\x00.\x00p\x00y\x00\x0f\x00\n\x00\x04\x00B\x00a\x00b\x00s\x00\x12\x003Users/nicholas/src/ASDictionary/src/ASDictionary.py\x00\x00\x13\x00\x01/\x00\x00\x15\x00\x02\x00\x0f\xff\xff\x00\x00', '/Users/nicholas/src/ASDictionary/src/ASDictionary.py')) File "/Users/nicholas/src/ASDictionary/src/dist/ASDictionary.app/Contents/Resources/__boot__.py", line 54, in _run execfile(path, globals(), globals()) File "/Users/nicholas/src/ASDictionary/src/ASDictionary.py", line 11, in import objc ImportError: No module named objc 2009-05-31 15:49:24.391 ASDictionary[4605:10b] ASDictionary Error 2009-05-31 15:49:24.394 ASDictionary[4605:10b] ASDictionary Error An unexpected error has occurred during execution of the main script ImportError: No module named objc despite the fact that there is not one but *two* copies of PyObjC installed. (Everything works fine if I just 'import objc' from a script, of course.) Help? I just wanted to write a quick script to tag some PDFs and I'm now over two hours into this... it's almost driving me to AppleScript! Thanks, -- Nicholas Riley