[Pythonmac-SIG] Using PIL/Compiling/_imagingtk
Howdie, I'm attempting to use the Python Imaging Library on a mac os x (panther 10.3.8) box with the standard python install, along with the macpython addons and the tcltkaqua packages. I first installed the macpython addons (http://ftp.cwi.nl/jack/python/mac/MacPython-Panther-2.3-2.dmg) for 10.3, then ran the package manager, which lead to a 404 error, and in-turn lead me to this post about the 10.3 package manager being unmaintained: http://mail.python.org/pipermail/pythonmac-sig/2005-February/013230.html I got the latest tclTkAqua-BI from: http://tcltkaqua.sourceforge.net/ (8.4.9.0) When I run python, I can now import Tkinter, and run a helloworld program to pop up a window, etc... The package manager, using Bob Ippolito's list http://undefined.org/python/pimp/darwin-7.2.0-Power_Macintosh.plist Specifies installing PIL from source, by hand... So, I got the latest 1.1.4 tgz from Pythonware, got through the ligImaging configure process but the make fails with: ... cc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _imagingtk.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o In file included from /Library/Frameworks/Tk.framework/Headers/tk.h:96, from _imagingtk.c:20: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o build/temp.darwin-7.8.0-Power_Macintosh-2.3/Tk/tkImaging.o -LlibImaging -lImaging -o build/lib.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 Very Very Annoying... Based on other similar posts, this appears to be some recent inconsistency between the builds. Where do the above routines live and what's the proper direction to follow in getting some patch back to the 1.1.4 Imaging release to make sure this compiles? - Colby ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: repackaging MacPython (was: Re: broken modules)
Bob wrote: If you named it carbon, it would definitely be the cause of headaches and confusion due to the default case insensitivity of HFS+ and the similarity to the existing namespace. 'lo-carb'? :) I wasn't exactly putting any thought into it; nit-picky details really aren't important here. To summarise: My main suggestion was that the whole Carbon package plus other Mac-specific modules might be moved out of the Python.framework distribution and into a separate 'MacAll' distribution (c.f. Win32All), leaving Python.framework as basically just a plain-vanilla framework build of the standard Python distribution. That'd allow the Mac community to evolve the Mac-specific stuff at its own rate, rather than being inextricably tied to the slower (and slowing?) upgrade cycle of standard Python. IOW, loosen the couplings between standard Python and Mac-specific extensions without changing any of the content or behaviour, because Loose Coupling = Better. I know Jack's mulled over this idea of repackaging MacPython (though I dunno to what extent) and I personally believe it has serious merit, even if this thread does seem to keep losing sight of it by sidetracking into nitpicky details (hey, mea-culpa, seeing as it's my thread:p). Anyway, I've probably said my bit about as well as I can and I'm off for the next week, so I'm going to leave it there and maybe someone else can run with the thought if they want to. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: OSA.so (was: Re: [Pythonmac-SIG] CFURL Pain)
Donovan Preston wrote: No, I wanted a Python OSA component. Different thing. The only person I know was asking for an OSA wrapper was Donovan, and he went off to work on Nevow yonks ago and AFAIK never did anything with it. I wanted an OSA module so that it would be possible to write a Python OSA component using a more inside out approach. There's basically two halves to OSA. One half is used to implement OSA language components. The other half allows client apps to use them. OSA.so implements the API for the second of these, allowing Python to load and execute scripts written in any OSA language. The Carbon equivalent to Cocoa's NSAppleScript, except with a much more powerful and much less friendly API. To implement a PythonOSA component, you need to write a C wrapper around the Python interpreter's C API [1]. That wrapper then exports a bunch of callbacks (UUPs to be precise) that OSA calls to compile/decompile/execute/load/store/etc a Python script on behalf of a client. I don't think there's anything in OSA.so that'd help with that. I've been looking at OSA.so recently as I'd like to implement attachability in a PyObjC-based app I'm writing and NSAppleScript is too limited for what I want to do. While I've occasionally given the PythonOSA problem a passing glance, it's not something I'm as interested in solving myself as I haven't had any personal need for it to date and my C isn't good enough anyway. I am still interested in producing a Python OSA component, hopefully with the OSA module, but unfortunately it is a lot more work than I have free time for at the moment. I lost my drive to work on it when it became clear that HAS was far more energetic in this space than I was, and HAS didn't seem willing to listen to what I had to say about the subject or collaborate with anybody. I do remember being very grateful for advice when I was starting out on appscript. Can't recall ever being anti-collaborative or that; I may be abrasive and critical and behave differently to other programmers, but then I'm from a different background so maybe there was some accidental culture clash? Apologies if any offence was caused; it certainly wasn't intentional. Cheers, has [1] It might be possible to write a smaller C wrapper that allows you to install Python functions as callbacks for handling the compile/decompile/execute/etc. stuff within Python using exec and friends rather than doing the whole lot in C, which might be a bit more convenient than doing everything in C. I don't know enough about how the Python interpreter works to say if this would be practical or not. -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Paul Berkowitz wrote: The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. Replacing (as of 10.3) a previous long, longstanding implementation bug where it was specified as a POSIX path string. :p I take it 'alias' is just a documentation error then, and the application will also accept a file spec/file url type identifying an existing/not-yet-created file. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there Presumably there's a POSIX path string-to-file object coercion introduced in 10.3 to maintain compatibility scripts written for Cocoa apps in 10.2, where 'save...in' took a POSIX path string instead of a file object. In aem's case at least, I'd be extremely reluctant simply to replace all use of Mac file objects with POSIX path strings. I've already tried this once and it just caused problems. I really would like an elegant, easy-to-use solution that respects AE file objects and provides user-friendly Python equivalents that hide as much of the underlying clumsiness without introducing any new problems. Might be a non-trivial task, but I think it'd be worth doing, especially if Python's to become a genuine replacement for AppleScript. In OS X, the coercion is now to fileURL, I believe. Whether this coercion takes place at a deep enough level (AppleEvent?) that it will work also for appscript and MacPython, I don't know. If you try it, what happens? I've tried supplying FileURLs to Tex-Edit Plus in 10.2 and it seemed to work ok. If CFURL worked properly I'd probably just sling in the code to coerce AEDescs of typeFSSpec and typeFSRef to typeFileURL and spit out CFURLs, then wait and see if anyone runs into problems. NSURL is an alternative, though I'm still a little uncomfortable about coupling aem to PyObjC just for the sake of one little type; I'll think about this a bit more. It would definitely be nice if the whole Mac file type muddle could be reduced - at least at the end-user level - to high-level, user-friendly FileURL and Alias classes. The only questions are: can we get there safely, and if so, how? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On 3/3/05 7:31 AM, has [EMAIL PROTECTED] wrote: Paul Berkowitz wrote: The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. Replacing (as of 10.3) a previous long, longstanding implementation bug where it was specified as a POSIX path string. :p Bo, that one was quite short-standing (OS 10.1 and 10.2) and only for TextEdit. Only TextEdit specified a POSIX path string for 'save' - it has now been changed to standard AppleScript colon-delimited paths to correspond with all other apps. I take it 'alias' is just a documentation error then, and the application will also accept a file spec/file url type identifying an existing/not-yet-created file. Yes. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there Presumably there's a POSIX path string-to-file object coercion introduced in 10.3 to maintain compatibility scripts written for Cocoa apps in 10.2, where 'save...in' took a POSIX path string instead of a file object. No, that's broken - it was only TextEdit in OS 10.1 and 10.2 that ever did the POSIX paths. ( 'save document 1 in /Volumes/PB G5 HD Panther/Users/berkowit/Desktop/TestDoc.rtf' saves the document in a file of that exact entire name - complete with forward slashes - on my root startup disk!!) Only colon-delimited paths work correctly now, not POSIX paths. I can't imagine that there are too many broken scripts since TextEdit's scriptability is so limited in the first place that there's not much you can do with it. -- Paul Berkowitz ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?
I ran some test code in the MacPython IDE and then from BBEdit (should be same as TextWrangle that some of you use). It runs in the Mac IDE, but I get this error in BBEdit: File Drive:Users:louispecora:Code:python:general:general.py; Line 132: AttributeError: 'file' object has no attribute '_buf' That line of code is this one import sys,Carbon sys.stdout._buf = say or '? ' # This line and the next print out the prompt 'say' -- bad line I cannot figure this one out. I'm suspecting it's some sort of Python path or multiple Python version problem, but I have no clue. I am running OS X 10.3.8 on a 1.25 GHz PB. I was really enjoying the BBEdit approach since it is a great code editor and seemed to run generic stuff well until I hit this problem. Maybe I need to run that Panther stuff that fixes the Mac version. Any help greatly appreciated. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?
On Mar 3, 2005, at 14:04, Louis Pecora wrote: I ran some test code in the MacPython IDE and then from BBEdit (should be same as TextWrangle that some of you use). It runs in the Mac IDE, but I get this error in BBEdit: File Drive:Users:louispecora:Code:python:general:general.py; Line 132: AttributeError: 'file' object has no attribute '_buf' That line of code is this one import sys,Carbon sys.stdout._buf = say or '? ' # This line and the next print out the prompt 'say' -- bad line I cannot figure this one out. I'm suspecting it's some sort of Python path or multiple Python version problem, but I have no clue. I am running OS X 10.3.8 on a 1.25 GHz PB. I was really enjoying the BBEdit approach since it is a great code editor and seemed to run generic stuff well until I hit this problem. Maybe I need to run that Panther stuff that fixes the Mac version. Any help greatly appreciated. Uh.. I have no idea where you got the idea to do that, but that _buf attribute is specific to the MacPython IDE. It works *nowhere else*. If you could explain what it does, I'm sure there's an alternative that works elsewhere. Leading underscores in Python typically mean don't touch this. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Hi Bob: Very few people care that undocumented modules don't work correctly. You have to look pretty hard to even notice their existence in the first place. I've never heard of a broken undocumented standard library module becoming a deal-breaker for someone new to Python. Looking at the Global module index http://python.org/doc/2.4/modindex.html it's hard not to notice the existence of the long list of Carbon.something modules in the left column. I think it would be a good idea to replace this with a single entry for Carbon, that explains that those modules are deprecated and one should use PyObjC instead. ciao Martina ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Getting stdin using TextWrangler or BBEdit, but not MacPython (was: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?)
Bob Ippolito wrote: As far as this code goes, you might be able to just get away with it if you do: # check for MacPython IDE if hasattr(sys.stdout, '_buf'): sys.stdout._buf = ... You're right this is a test that would shut off the _buf part of the code if I were not using MacPython. It really depends on what the rest of your code looks like. If it does sys.stdout.readline() for example, it's still going to be broken, because you can't normally read from stdout. The rawinput() function might do what you want everywhere else, though. I can't seem to get rawinput or raw_input() to work. Ignoring my previous code. I just want something that can take standard input so, for instance, when I prompt with print Input 2 ints and a float The program will wait until I type, say 2 5 5.476 (return) Then hand back the three numbers either as a string, a list, or individual int and float types so I can process them with my program. Sort of like int i1, i2; float f1; scanf( %d %d %e, i1, i2, f1); would do in C using stdin. Or even a gets() which I could then process to pull out the two ints and a float. I'm just looking for simple input of numbers and strings. I'd like to do this from BBEdit rather than MacPython. Anyone out there done this with TextWrangler? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: Getting stdin using TextWrangler or BBEdit, but not MacPython (was: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?)
On Mar 3, 2005, at 16:57, Louis Pecora wrote: Bob Ippolito wrote: As far as this code goes, you might be able to just get away with it if you do: # check for MacPython IDE if hasattr(sys.stdout, '_buf'): sys.stdout._buf = ... You're right this is a test that would shut off the _buf part of the code if I were not using MacPython. It really depends on what the rest of your code looks like. If it does sys.stdout.readline() for example, it's still going to be broken, because you can't normally read from stdout. The rawinput() function might do what you want everywhere else, though. I can't seem to get rawinput or raw_input() to work. Ignoring my previous code. I just want something that can take standard input so, for instance, when I prompt with print Input 2 ints and a float The program will wait until I type, say 2 5 5.476 (return) Then hand back the three numbers either as a string, a list, or individual int and float types so I can process them with my program. Sort of like int i1, i2; float f1; scanf( %d %d %e, i1, i2, f1); would do in C using stdin. Or even a gets() which I could then process to pull out the two ints and a float. I'm just looking for simple input of numbers and strings. I'd like to do this from BBEdit rather than MacPython. Anyone out there done this with TextWrangler? I don't know a damn thing about TextWrangler, but this works with any Python that has a working stdin: while True: text = raw_input(Input 2 ints and a float: ) try: i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), text.split())] except ValueError, e: print 'Invalid Entry: %s' % (e,) continue break -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython
Charles Hartman wrote: In TextWrangler something like this while 1: c = raw_input() if c == 'quit': break print c works fine, if you choose Run in Terminal or Run with Debugger. If you try to choose Output to New Window, it just quits immediately. But you can certainly run it from within TW. Yes, that works. Thank you. I would have liked using the Output to keep it all in BBEdit, but I may have to go with the TW. Better than nothing. Thanks again. Charles Hartman Professor of English, Poet in Residence ^^^ And you program computers. Cool. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython
Bob Ippolito wrote: I don't know a damn thing about TextWrangler, but this works with any Python that has a working stdin: while True: text = raw_input(Input 2 ints and a float: ) try: i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), text.split())] except ValueError, e: print 'Invalid Entry: %s' % (e,) continue break Yes, it works in a terminal. But it doesn't work in TextWrangler. Must be something about how that code editing app handles the Python I/O. But I can't expect you to fix that. :-) Thanks for your help. Will deal with the terminal approach. Muchas gracias. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython
Bob Ippolito wrote: I don't know a damn thing about TextWrangler, but this works with any Python that has a working stdin: while True: text = raw_input(Input 2 ints and a float: ) try: i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), text.split())] except ValueError, e: print 'Invalid Entry: %s' % (e,) continue break -bob I should add that calling raw_input() gives the following error: File Drive:Users:louispecora:Code:python:test_folder:junk.py; Line 12: EOFError: EOF when reading a line Not sure what that tells you, but it seems to be how TextWrangler is dealing with stdin. Almost sounds like it is expecting input to be right there when called and seeing none, just sees an EOF. Oh, well. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython
(Tried to answer before but it didn't go through) It works fine in TextWrangler if you choose (from TW's Run submenu) Run in Terminal; you're still doing your work in TW, just using Terminal for i/o. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Mar 3, 2005, at 5:34 PM, Louis Pecora wrote: Bob Ippolito wrote: I don't know a damn thing about TextWrangler, but this works with any Python that has a working stdin: while True: text = raw_input(Input 2 ints and a float: ) try: i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), text.split())] except ValueError, e: print 'Invalid Entry: %s' % (e,) continue break -bob I should add that calling raw_input() gives the following error: File Drive:Users:louispecora:Code:python:test_folder:junk.py; Line 12: EOFError: EOF when reading a line Not sure what that tells you, but it seems to be how TextWrangler is dealing with stdin. Almost sounds like it is expecting input to be right there when called and seeing none, just sees an EOF. Oh, well. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not?
Thanks. I'll have to check to see if that will work for my laptop. I have plenty of other stuff on my plate though, so this particular issue has sort of moved to the back burner... Bob If it runs 10.2, it'll run 10.3. You'll probably notice better Bob performance, too. Thanks. The check is in the mail... S ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
