Re: [Pythonmac-SIG] converting Mac 'path' to file path in appscript?
On Jun 19, 2008, at 21:33 PM, Ned Deily wrote: One way: mactypes.File.makewithhfspath(u'wolfe:downloads').path http://appscript.sourceforge.net/py-appscript/doc/mactypes/ index.html mactypes is a very useful module, it is how I get the selection in the Finder via appscript whether using Python or PyObjC def getFinderSelection(): List of aliases of selected items in the Finder return [alias.path for alias in app(Finder).selection.get(resulttype=k.alias)] Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript and Firefox
On Jun 18, 2008, at 19:04 PM, Bill Janssen wrote:
I'm finally trying to learn appscript, and I thought I'd write a
little system monitor that goes around to my various open applications
and logs what files/URLs I'm looking at. For Safari, this is easy:
print app('Safari').windows.first.current_tab.URL()
but I can't figure out how to get the current URL for Firefox.
There's a bug report at
https://bugzilla.mozilla.org/show_bug.cgi?id=427448 which seems to
show that you can get the URL with the applescript fragment
set url to get class curl of window 1 as text
at least for older versions of Firefox.
But how do I write class curl in appscript?
In Safari URL is a property of the tab class so you can get that
property by indexing the windows and tab you want.
Generally, the double angle brackets indicate the application being
addressed doesn't recognize based on its dictionary so those symbols
are inserted in the script (from what I know--maybe someone smarter
than me can chime in)..
I just looked at the Firefox 3 Dictionary (with Script Debugger 4) and
I don't see a URL class nor even tab and windows elements to use to
select which URL you wanted from the browser.
There is a slip of a dictionary there, but not enough to do much as
far as I can tell.
Maybe it is planned for the future but not implemented. I even looked
at the menus to see if one could use System Events but nothing looked
easy.
It looks impossible from my perspective and knowledge, maybe someone
smarter has it figured out.
I am using this version:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/
2008051202 Firefox/3.0
Daniel
Bill
___
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] appscript and Firefox
On Jun 18, 2008, at 20:18 PM, Bill Janssen wrote: Thanks, Daniel. It looks impossible from my perspective and knowledge, maybe someone smarter has it figured out. Apparently someone has, from the scrap of Applescript I pointed to before (OK, here it is again: https://bugzilla.mozilla.org/show_bug.cgi?id=427448).You cannot I'll repeat: the angle brackets mean Applescript cannot find that class in the dictionary of the application you are addressing. that means you are asking the application for something it doesn't know about at least as far as Applescript can tell it directly. It's like trying to get the value of an undefined variable--it cannot be done because it does not exists. But you can enter raw apple events which is what you want to do. See here for and explanation of the brackets and how to enter them: http://developer.apple.com/documentation/AppleScript/Conceptual/AppleScriptLangGuide/conceptual/ASLR_raw_data.html How you'll find out which apple events to call without a dictionary is a task you'll have to figure out--they aren't defined in a dictionary like they should be. THey might be compiled into the resources in the bundle, but I don't have the time nor inclination to go down that road. Maybe you might ask the Adium developers how they found them. And as for why the Firefox developers would support raw events but not write a dictionary is not only a mystery, but also very, very bad form. But it's a question for them not me as to why they chose that path. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Applescript equivalent in appscript
On Jun 7, 2008, at 15:46 PM, Rajanikanth Jammalamadaka wrote: Thanks a lot for the links Jordan. Could you tell me why there is a u before some names in appscript for example: menus[u'Apple'] That's the Python code to designate a Unicode string. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Applescript equivalent in appscript
On Jun 7, 2008, at 11:48 AM, Rajanikanth Jammalamadaka wrote: Thanks for your reply Laurent. Also, could somebody tell me how to do this: Suppose the application pops up a window while its running and gives me two choices: Ok or Cancel how can I tell it to select the Ok option always? I don't have time to work up a demo right now, but you should be able to use System Events: Apple info: http://www.apple.com/applescript/uiscripting/ Daniel --- The secret of a life well-lived is not how many years you have in your life--it is how much life you put into your years -- from a Sierra Mountain Guides newsletter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] NewBie question: Building GUI for Mac
On Jun 5, 2008, at 23:42 PM, Abhiram Dwivedi wrote: Hello, I want to know if its possible to build a standalone GUI app for Mac using python. Yes it is. I need to build some application and still going through pythong tutorials. It seems Cocoa is the only option, Not true. wxPython, Tkinter, GTK, and others are all available. PyObjC/ Cocoa is Mac-only and the richest for a Mac-only app. There are trade- offs with every choice. but I want to be sure before moving away from python. Using PyObjC (or any GUI framework) is not moving away from Python--it is using a platform-specific GUI framework as a UI adjunct to Python and little different from wxPtyhon or Tkinter except in platform scope. I need to integrate it with RSS and growl notifications as well. I believe that can be done--try Googling for support: RSS is multi- platform while Growl is Mac-only. Thanks in advance. Abhiram Send instant messages to your online friends http://uk.messenger.yahoo.com ___ 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] Python-Cocoa with XCode 3 - external modules
On Tuesday, May 27, 2008, at 07:42AM, Steve Pike [EMAIL PROTECTED] wrote: Hello all, I hope this is the right place to ask such a question: I'm building a Python-Cocoa app in XCode 3, and it all works wonderfully except that I use the appscript module... And XCode doesn't include the module in the build. so, 2 things: - I was wondering if there is a way to make it do so - If not, I have been advised to use py2app, but again this seems not to work with the examples given on the site (crucially, it reports unable to load nib file: MainMenu (maybe because this is a xib file?) There is an Xcode-users mailing list which might be a better place to ask this question. Not a few Apple people monitor that list so you have a good chance of getting some good leads on a solution. Send Xcode-users mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.apple.com/mailman/listinfo/xcode-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python-Cocoa with XCode 3 - external modules (Cross posting a reply)
On May 27, 2008, at 14:01 PM, Orestis Markou wrote: Hey Steve, I hope this is the right place to ask such a question: FYI, Bill B replied on the Xcode list with pretty much the same advice I gave for those of you who want to know: -- Forwarded message -- From: Bill Bumgarner [EMAIL PROTECTED] To: Steve Pike [EMAIL PROTECTED] Date: Tue, 27 May 2008 13:23:58 -0700 Subject: Re: Python-Cocoa include external modules? On May 27, 2008, at 11:42 AM, Steve Pike wrote: Hello all, I'm building a Python-Cocoa app in XCode 3, and it all works wonderfully except that I use the appscript module... And XCode doesn't include the module in the build. So I was wondering if there is a way to make it do so - can it incorporate egg files for example? py2app can handle this automatically, but there are other issues with it right now. If it is just one or two modules, then add a copy files build phase to your project that copies the module into the appropriate spot within your application. b.bum ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python-Cocoa with XCode 3 - external modules
On May 27, 2008, at 14:01 PM, Orestis Markou wrote: XCode by default will use the system supplied python. I think if you want to use external modules you have to include them directly in your project. Pyobjc-devel users will know more. I sent Steve to the Xcode group for a reason: There are two camps IMHO for PyObjC development: 1) Xcode-Interface Builder and 2) Interface Builder - text editor - py2app He asked the question in a way that placed him in the first camp in my mind. Using Xcode and using Xcode is quite different from just using Interface Builder and py2app alone. I have abandoned Xcode itself for PyObjC because most of its great features are useless with PyObjC (like debugging) but to each his own. To the point: Xcode makes it pretty simple to add build phases to a target and one of the standard default phases is a file-copy phase which you could add to copy each resource you need (like an egg or other file). You can also add shell (or perl, python ruby) scripts as well to make pretty sophisticated builds and even save those as templates. The Xcode group would be best for advice for complex builds. If Orestis is right that adding the resources to the project auto-copies them, then that's great--haven't tried it myself--I thought that only happened for standard resources Xcode knew about. Apple has an example of using shell scripts to build a universal build of OpenSSL mostly using configure, make, and lipo via shell scripting. There are quite a few environment variables you can use which are documented in the Xcode 3.0 User Guide. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pystone numbers for different Macs...
I ran the test on my 1st Gen Quad Core ( 2 x Quad-core 3.0 GHz, 13GB RAM) and was a bit surprised to see little improvement over the Core Duo numbers. 63019.7 pystones/second I am assuming the GIL is limiting threading and therefore I am really running on one or two cores--hence the tangible improvement is just CPU speed: from 2.33 GHz to 3.0 GHz and a bit of the memory bandwidth increase as well. This is the 32-bit number, I'll find some time to try 64-bit--but first want to make sure it doesn't mess up my system as I am using Apple Python 2.5.1 exclusively right now and want to avoid the split brain problem. Daniel On Jan 20, 2008, at 1:27 AM, Ronald Oussoren wrote: On 19 Jan, 2008, at 21:43, [EMAIL PROTECTED] wrote: My Powerbook G4 is getting rather long-in-the-tooth. It's display is starting to act up, so I think I'm going to buy a new Mac something in the fairly near future, but I'm not yet sure what. To that end, I've started a table of pystone numbers for Macs on the Python wiki: http://wiki.python.org/moin/MacPython/MacModelPerformance If you could help by adding some rows to the table, especially for current MacBook, MacBook Pro or (in the near future, MacBook Air) models, I'd appreciate it. I've posted some numbers as well, which in itself doesn't warrent an e-mail. What is interesting though is the difference between 32-bit and 64-bit code: Python 2.5.2a0 (60124) 32-bit: 52083 64-bit: 60871 64-bit code is significantly faster here (all of this on a MacBook Pro 2.33Ghz/3GByte) Ronald Thanks, -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ The major difference between Democrats and Republicans is that Republicans don't know that Randy Newman's lyrics are full of sarcasm. ___ 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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pystone numbers for different Macs...
Jack, My bus is 1.33 GHz--I think the 2nd Gen Quad-cores are bumped to 1.5 GHz maybe. I'll see if there is anything I can do to bump the numbers. My system is just like yours but with a second Quad core chip that only a few apps can take advantage of. It helps me with Modo, Lightwave, Shake, Photoshop, and Final Cut Studio (which is why I got it in the first place) but not with Python and most other apps as well. Skip is right of course--the Global Interpreter Lock doesn't play here since the benchmark wasn't written to take advantage of multi-core machines--silly me I thought any good benchmark would be. In the end my error doesn't matter since, if one made the benchmark multi- threaded in the true sense of the term, the GIL would clamp down and limit the benefit anyway. Which is what I was alluding to and should have been more clear about. My point was that, as I understand it, thanks to the GIL--Python cannot easily take advantage of multi-cores period even when the program uses multiple threads--it it is a limitation of the implementation of the language interpreter. I guess that tells us we ought to write multi-core code in C/C++/ObjC instead. Either that or Python's implementation needs to embrace threading more expansively. Still Python is a great language as it is. No one language fits all-- as much as we'd like it to for simplicity's sake. Daniel On Jan 20, 2008, at 11:53 AM, Jack Jansen wrote: On 20-Jan-2008, at 19:23 , Daniel Lord wrote: I ran the test on my 1st Gen Quad Core ( 2 x Quad-core 3.0 GHz, 13GB RAM) and was a bit surprised to see little improvement over the Core Duo numbers. 63019.7 pystones/second I am assuming the GIL is limiting threading and therefore I am really running on one or two cores--hence the tangible improvement is just CPU speed: from 2.33 GHz to 3.0 GHz and a bit of the memory bandwidth increase as well. Interesting... My first generation quadcore at 2.6 Ghz clocks at 62578.2. So there's another limiting factor: from my machine to yours is a 15% speed bump, but only a 1% increase in pystone numbers. Somebody told me recently that MacOSX is not very good for fast task switching with multiprocessors, because apparently (his words, and possibly misrepresented by me) the implementation of semaphores sucks. This seems to corroborate that. Hmm, what is your bus speed? Mine is 1.33 Ghz, is yours that as well is it 1.5 Ghz? If the former it could be that semaphores somehow run at bus speed and semaphore overhead dwarves any processing done. If your bus runs at 1.5Ghz there must be yet another bottleneck... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On Dec 21, 2007, at 12:48 AM, Jack Jansen wrote: I think this would be a very good idea, even if only from a political point of view. Even though I've been an open source developer since long before the word existed I find that I'm getting sick and tired of the reinvent- the-world attitude that is far too common in the open source community. If I am new to Python on the Mac and I've played with Apple Python a little, but as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new (and not directly Apple-endorsed) I might just drop out. And at the very least it's mightily inconvenient. Also note that the chances that the distutils fix or the 64-bit fix are likely to affect me are exactly zero (the newcomer me from this paragraph, not the flesh and blood Jack me:-). There are many who can wax more eloquently than I, maybe even Stallman- or Raymond-esqe about cathedrals and bazaars, on the material differences in the drivers behind and goals of commercial and open source software projects, but Jack's points about the isolationist tendencies and the need for native Python support are well-stated and his suggestion should be given serious consideration. While this community has done very well with only tacit Apple support (though embedding PyObjC is a bit more than tacit), we would likely find more support by Apple if we expand our offering to cater to the left half and tail of the Python adoption normal distribution. This would have the effect of raising Apple's awareness of the importance of Python on the platform. For example: I should not have to tinker with path settings, or worse install another a complete other Python, to use Python in a scriptable high-end 3D graphics modeler and renderer where a perfectly good one is already installed. Better OpenOffice Python integration and native Appscript and Python OSA support are others. But this means providing a reasonably rich set of tools that is fully accessible from the stock Python installation for the neophytes and apprentices as much as journeymen. I am with you Jack. Daniel Lord ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Accessing Resource forks
Chris, I know you already asked this and got answers, so I did not at first understand why you asked again. Then I saw the date of the message. I think that in you search for a solution to handling antiquated resource forks, you might have discovered time travel as a side effect. Patent what ever you did and quickly ;-) Strange. Daniel On Jul 12, 2007, at 5:16 PM, Donna and Chris Barker wrote: HI all, Somehow over all these years, I've managed to use Python on MAcs without having it deal with resource forks and sll that -- but ironically, not that we're all OS-X all the time, I need to do ti now. What I'm trying to do is simple check for the existance of a resource fork, and if it's there, the size. This is what I've tried: import Carbon.File as File files = [junk.txt, junk_rsc.txt] for filename in files: f = File.FSRef(filename) print file path is:, f.FSRefMakePath() i = f.FSGetCatalogInfo(0) print logical size is:, i[0].rsrcLogicalSize print Physical size is:, i[0].rsrcPhysicalSize In this case, junk.txt was created at the command line, so it shouldn't have a resource fork. junk_rsc.txt I opened up in resedit, which should have given it a small resource fork. Runnign this script, I get: file path is: /Users/cbarker/temp/AFP-SMB/junk.txt logical size is: 65543 Physical size is: 30457855 file path is: /Users/cbarker/temp/AFP-SMB/junk_rsc.txt logical size is: -593231776 Physical size is: -210763775 The paths are right, so it looks like I've got the FSRef right, but rsrcLogicalSize and rsrcPhysicalSize make no sense. How should I be doing this -- the docs are sparse, to say the least! By the way, I might as well tell you the real goal, maybe one of you will have a better idea. We have a Windows file server that is about to be retired. over the years, people of have put files on it using both the AFP and SMB protocols (the server is running MS services for macintosh). These are all mixed up. However, any file put up with one protocol loses it's resource fork (and type and creator) if brought down with the other protocol. Our goal is to clean up this mess automatically. The idea at hand is that a file brought down with AFP will either: Have a nice resource fork, in which case it was put up with AFP, and we're happy Have no resource fork, in which case it never had one, and we dont' care what protocol was used, or it was put up with SMB, and we can then bring it down that way instead. The other obvious option is to look for the ._* files, which is where the resource fork is stored with the SMB protocol. However, we're concerned that that may not be reliable -- if a file were put up with SMB, then replaced with AFP, there may be a ._* file, but it won't work right. This actually seems pretty likely as while we have this mixed system, there have been a lot of that didn't work, please put the file back up with APF interations. Thanks for your thoughts. -Chris ___ 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] Trouble installing Python Imaging Library on Mac OS X
It's been some time since I worked through this for 2.4, but IIRC, one has to modify the PIL make to ensure it finds libjpeg after you have installed it. How I did that I cannot recall just now off the cuff, so when I have time at some point I can try to dig it up. But in the mean time, if you are industrious and read the build notes for PIL, those pesky details might still be in there somewhere and clue you in to set it up properly so libjpeg is found by PIL on the build. If even I was able to solve it, I have no doubt that, with application, you will also and in a shorter time than I. Daniel On Jul 23, 2007, at 9:22 PM, Ritesh Nadhani wrote: Hello So I want to install Python Imaging Library on my Mac OS X. I followed the tutorial steps by step. When I executed: IOError: decoder jpeg not available I got the error. Further Googling pointed me to the website: http://www.kyngchaos.com/macosx/install/libjpeg I downloaded the libtool updated linked there and unzipped it. It says that: Then, you need to update the libtool file in the source. Though I have no clue what does that mean. Unzipping it gave me two file ltconfig and ltconfig.sh. Running the sh file gave me libtool version mismatch error. Doing a search of system I found that there is another ltconfig in /usr/share/libtool. Assuming that this file needs to be updated with the one provided in the zip, I copied the original ltconfig.sh to ltconfig.sh.bak and copied the new one to the folder. The I followed the same steps as mentioned up there and the compilation and installation seems to have gone correctly. But again when I do selftest.py, I get: Exception raised: Traceback (most recent call last): File ./doctest.py, line 499, in _run_examples_inner exec compile(source, string, single) in globs File string, line 1, in module File ./selftest.py, line 22, in _info im.load() File PIL/ImageFile.py, line 180, in load d = Image._getdecoder(self.mode, d, a, self.decoderconfig) File PIL/Image.py, line 375, in _getdecoder raise IOError(decoder %s not available % decoder_name) IOError: decoder jpeg not available 1 items had failures: 1 of 57 in selftest.testimage ***Test Failed*** 1 failures. *** 1 tests of 57 failed. Moreover, sudo python setup.py build_ext -i, give me: PIL 1.1.6 BUILD SUMMARY version 1.1.6 platform darwin 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] --- TKINTER support ok --- JPEG support ok --- ZLIB (PNG/ZIP) support ok --- FREETYPE2 support ok To check the build, run the selftest.py script. So it seems that the libraries were correctly found. -- Ritesh http://www.riteshn.com ___ 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] Accessing Resource forks
On Jul 13, 2007, at 2:55 PM, Christopher Barker wrote: How should I be doing this -- the docs are sparse, to say the least! By the way, I might as well tell you the real goal, maybe one of you will have a better idea. RezDet command line utility perhaps? as in: [15:30:10] [EMAIL PROTECTED] ~/Pictures $RezDet f*.jpg f3390b9f2ff8e50fb6772ab5bc7c3b2f.jpg: File f3390b9f2ff8e50fb6772ab5bc7c3b2f.jpg; ### RezDet - The resource fork is empty and uninitialized. Perhaos use 'commands.getstatusoutput' to run it and search result string? It is listed as an MPW tool, but its still there in Tiger--just checked. http://developer.apple.com/tools/mpw-tools/commandref/rezdet.html Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac oriented Python book (was: no subject)
I am guessing that Victor is either interested in scripting Blender or Modo since those are the only higher-end 3D graphics modeling and rendering packages I know of that support Python scripting. I am ruling out Poser and Shade. The issue with those packages is that they use an embedded interpreter so standalone aspects of Python (PyObjC, py2app, wxPython) are useless in that context as far I have been able to determine. I use Modo but have only tinkered with using Python with it. On Jul 10, 2007, at 7:53, has wrote: Victor Merritt wrote: I am an Visual Effects artist in need of a good Mac oriented Python book. I have been reading the online materials, but I don't always have the time to sit in front of a computer, thus my need for a good Mac focused Python Book. Any suggestions would be very helpful. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Fwd: signal from itunes when song changes?
I forgot to copy the list ;-) Begin forwarded message: From: Daniel Lord [EMAIL PROTECTED] Date: May 9, 2007 10:30:41 PDT To: julien ricard [EMAIL PROTECTED] Subject: Re: [Pythonmac-SIG] signal from itunes when song changes? Growl does it, so there must be a way to register for state change notifications as a listener (I am speculating). Maybe check the Growl SDK and find out how their iTunes Growler works. Google for Growl and then access the developer information to get the SDK which should have the source code for the iTunes module. Someone better versed in this may chime in as well. Daniel On May 9, 2007, at 10:16, julien ricard wrote: hi, I'm building a kind of plugin for itunes using python and qt. In order to practice a bit, I've started with a very simple one: display the song currently played (no 'update' button). The problem is that I don't know how to get the signal from itunes when the song changes in order to update the song information in my qt app. I've done a loop checking when the name change, but it doesn't look very optimal... Anybody could help? thanks! jul ___ 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] StuffIt 10 can corrupt applications packaged with py2app
Shell script, Schmell script...do it in Python: I got this from someone somewhere long ago... import sys, os, os.path import commands if len(sys.argv) == 2: dir = sys.argv[1] print Creating disk image %s.dmg % (dir) status, output = commands.getstatusoutput(hdiutil create - volname %s -fs HFS+ -srcfolder %s %s.dmg % (dir,dir, dir)) else: sys.stderr.write(***ERROR: must provide folder to source.\n) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Interesting use of Python and Django on the Mac
This is the start of a trend we are going to see more and more of: the covergence of Web and Desktop or Web-top. Dashboard/Konfabulator were the first big step, with Slingshot and Apollo the next big one. Granted this is pre-alpha code, but one can start imagining the possibilities. http://jerakeen.org/blog/2007/03/djangokit/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ann] PyOSA 0.1.0, Appscript Installer 1.5.1 released
John Gruber couldn't have put it any better: Holy sh*t! (http:// daringfireball.net/) The MacPython world became a much friendlier place today. Great work and thank you very much. On Mar 27, 2007, at 2:49, has wrote: Hi all, Announcing the first release of PyOSA, a new OSA language component for Python. PyOSA allows you to write Python scripts in Script Editor and attach them to OSA-enabled applications such as Mail (Mail Rules), iTunes (Scripts menu) and System Events (Folder Actions). PyOSA is very much a work-in-progress at this point, but it's already sufficiently advanced to allow both experimental and real-world use (caveat a few bugs and limitations). Comments, criticisms and suggestions for improvements are very welcome. Also released is Appscript Installer 1.5.1, containing binary installers for appscript 0.17.2. This update fixes several minor bugs and is recommended for all Appscript Installer 1.5/appscript 0.17.0 users. PyOSA and Appscript Installer are available for download at: http://appscript.sourceforge.net/download.html Enjoy! has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ 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] [ann] PyOSA 0.1.0, Appscript Installer 1.5.1 released
On Mar 27, 2007, at 9:35, Kevin Walzer wrote: Announcing the first release of PyOSA, a new OSA language component for Python. PyOSA allows you to write Python scripts in Script Editor and attach them to OSA-enabled applications such as Mail (Mail Rules), iTunes (Scripts menu) and System Events (Folder Actions). has, I'm confused--how is this different from appscript? Kevin, note the included passage above. You can write Python scripts in Script Editor now. Unfortunately, I cannot seem to get ScriptDebugger to work, but it might be 'pilot error'. Still trying. daniel -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ 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] Unicode
Good article link, Thanks. On Mar 14, 2007, at 9:18 PM, Bob Ippolito wrote: Here's a very recent, well written and pertinent article: http://boodebr.org/main/python/all-about-python-and-unicode -bob ___ 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] How to make an apt except Drag and Drop
Christopher, I found an example in a wiki that works perfectly accepting objects before and after startup. http://wiki.wxpython.org/index.cgi/Optimizing_for_Mac_OS_X Towards the end there is a sample wxPython applications and a setup.py file. Be aware that you need to replace a line in the setup.py: change from setuptools import setup to from distutils.core import setup but with that one change it worked perfectly for me. My system is OS X 10.4.8 python 2.5 MacbookPro core 2 Duo Daniel On Mar 8, 2007, at 10:32, Christopher Barker wrote: Hi all, I'm working on making an app accept drag and drop of files. It appears to do that I need to put the right incantations into the plist in the app bundle. Py2app helps out a lot with that, but now I need to figure out what incantations I need. The case at hand is a text editor, so I want: - It should accept ALL text files for editing. - It shouldn't impose its icon on anything. - Maybe it should accept all files -- you never really know, and it really bugs me when an app won't accept a file that the OS thinks it doesn't know what to do with -- if I get Garbage, I get Garbage. This is what I've tried: Plist = dict(CFBundleDocumentTypes= [dict(CFBundleTypeExtensions= [*], CFBundleTypeRole=Editor), ] ) That does seem to allow it to accept all files. What if I did just want text? There's no way to specify all the possible extensions. I've noticed that there is: CFBundleTypeName Which I could set to: kUTTypeText would that do it? And is the ByndleTypeName and BundleTypeExtensions an AND or OR relationship? This is all a bit confusing, as I thought OS-X figured out file types from combination of extensions, old Type and creator codes, and the *nix file utility. I that case, couldn't I just set a Mime-type or something, and let the OS (or is the Finder?) figure out extensions, etc. Is that what CFBundleTypeName does? Is there anything else I should do? This is a wxPython App, by the way but I don't think that effects this issue. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [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] PyOSA preview
has, Thanks for all your hard work on this. I am going to work with it a bit when I get some time. I use Komodo a lot these days, it will be interesting to see if/how I can merge the two a bit. I saw Matt's article and I bookmarked for reading this weekend. Haven't tried Ruby yet, I should work with it a little also. I wish Apple would figure this out. Apple Event IPC is great, Applescript is pathetic for the reasons, skimming the article, Matt mentions. They need to take Ruby and Python and make them the core scripting languages for the Mac When I think of the time and resources they spent on Applescript Studio that could have been spent on PyObjC Studio, it saddens me. Apple should leave Applescript as a simple language functioning as Automator glue for non-programmers or quick tasks but open that to Ruby and Python too. Daniel On Mar 1, 2007, at 13:48, has wrote: Hi all, PyOSA, my second attempt at implementing a full Python OSA component, is starting to come together. This is an early version, may be buggy/ incomplete, use at own risk, etc. Most of the major features are working in the large - saving/loading (works on PPC, currently breaks on i386 due to OS bug), compiling, running, displaying results, event handling, appscript integration - so should give a good flavour of where it's going. You can grab the relevant files via subversion: - PyOSA (XCode project, readme, license and samples): svn checkout http://svn.macosforge.org/repository/appscript/py- osacomponent/trunk/ - py-appscript 0.17.2 unstable: svn checkout http://svn.macosforge.org/repository/appscript/py- appscript/branches/py-appscript-0.17.2-unstable/ See PyOSA's ReadMe file and sample scripts for more information. If Script Editor tries to compile your Python code as applescript (there are some known bugs in SE's language menu on 10.4), try setting the default language in SE's preferences. Failing that, osascript works just fine, or you could grab a demo copy of Script Debugger and temporarily use that. Enjoy, has p.s. For anyone interested in what's going on in the rest of the appscript world these days, Matt Neuburg's just done a very nice article at O'Reilly's MacDevCenter: http://www.macdevcenter.com/pub/ a/mac/2007/02/27/replacing-applescript-with-ruby.html. Not that you need to drop py-appscript and rush to the Dark Side - both bridges provide the same level of application scripting support - but it's great to see the word getting around. The ObjC port of appscript is also shaping up nicely; see my sig for the link. -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html ___ 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] appscript
My profile is close except I moved to Python 2.5:
Macbbok Pro Core 2 Duo, 2.33GHz, 2GB, 10.4.8
cannot reproduce, long pause while iTunes launches though...
[EMAIL PROTECTED] Thu Feb 22 11:44:38P [ 1 ]
~/ python
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.
from appscript import *
itunes = app(iTunes)
itunes.name.get()
u'iTunes'
More interestingly,
This begs the question: if I could figure out how to keep both 2.4
and 2.5 in the same system and playing nicely, I would and that would
make testing easier.
The best way would be able to run OS X in a VM but we all know _that_
isn't coming any time soon ;-(
I suppose I could install the OS on some external volumes to plug
into the Macbook and reboot.
If I install 2.4, then link the binary to /usr/bin/python24, then
overlay 2.5, tit seems simple, but the Devil is in the details.
Even if I invoke python2.4, the global environment points to Python
2.5 and things could get ugly fast I am guessing.
On Feb 22, 2007, at 7:04, has wrote:
Christian Bird wrote:
I just found out about appscript and am attempting to use it on my
macbook pro (OS X 10.4.8 and python 2.4.3). I installed appscript,
but the following is what I get when I try to test it out. [...]
The same error appears regardless of which
app I try to control (and yes, itunes is running when I tried this).
(aem.Application(u'/Applications/iTunes.app')): CommandError -600: no
eligible process with specified descriptor
Hmmm. This is the first time I've heard of such a problem, and I'm
unable to replicate the error here on my i386 test box (Core Solo
Mini, OS 10.4.6, Python 2.4.3, appscript 0.17.0):
[mini:~] has% python2.4
Python 2.4.3 (#1, Mar 30 2006, 11:02:16)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type help, copyright, credits or license for more information.
from appscript import *
a = app('itunes')
a
app(u'/Applications/iTunes.app')
a.name
app(u'/Applications/iTunes.app').name
Which Python distribution and appscript version are you using?
Also, could anyone else here who has a similar setup to Christian
please try the above and let us know if it works ok or not for them?
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html
___
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
[Pythonmac-SIG] Question about setup.py build
I admit to being a novice at this yet, but I couldn't find anything relevant to this issue on-line: I am trying to build a version of pysqlite that works with sqllite3 : 1. Apple's installed version doesn't work with the latest so I reinstalled 2. sqllite3 won't build shared libs for universal binaries (typical of a lot of linux/UNIX build since the developers never have that problem except on OS X) 3. so I built Intel-only but 4. pysqlite keeps trying to build a universal build (CFLAGS=-O -g - isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc; etc. etc.) with python setup.py build 5. But nowhere in the setup.py or setup.cfg is that set. I explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from there. So where is it being set? By the Python build? Where? I jsut need a little pointer or two and I'll do the rest. Thanks. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about setup.py build
Thanks Bob, coming through as always. Daniel On Jan 24, 2007, at 14:26, Bob Ippolito wrote: On 1/24/07, Daniel Lord [EMAIL PROTECTED] wrote: I admit to being a novice at this yet, but I couldn't find anything relevant to this issue on-line: I am trying to build a version of pysqlite that works with sqllite3 : 1. Apple's installed version doesn't work with the latest so I reinstalled 2. sqllite3 won't build shared libs for universal binaries (typical of a lot of linux/UNIX build since the developers never have that problem except on OS X) Why would you want shared libs anyway? I'm pretty sure the Mac build script that comes with Python 2.5 (Mac/BuildScript/build-installer.py) will automatically download SQLite and compile it universally as a static lib. Take a look in there. 3. so I built Intel-only but 4. pysqlite keeps trying to build a universal build (CFLAGS=-O -g - isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc; etc. etc.) with python setup.py build 5. But nowhere in the setup.py or setup.cfg is that set. I explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from there. So where is it being set? By the Python build? Where? I jsut need a little pointer or two and I'll do the rest. Thanks. The same place that everything else that distutils knows about is coming from, the Makefile in your Python library that was created when Python was built: lib/python2.4/config/Makefile -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about setup.py build
I realized I only copied Bob on this and to send it out to everyone might help someone else the build for PySQLite is poorly designed and ignores the state of '-- enable-shared' and looks for the dylib anyway so fails on static-only builds. I will have to hack it to get it to work. Shame, shame. On Jan 24, 2007, at 15:08, Daniel Lord wrote: Bob, Just so you know though, I was building the dynamic libs because the installer looks for them even if you disable shared libs. Bad design. So I'll have to 'hack' it to make it work. Not that that isn't business as usual with OS X ;-) [EMAIL PROTECTED] sudo make install Password: tclsh ./tclinstaller.tcl 3.3 couldn't open .libs/libtclsqlite3.dylib: no such file or directory while executing open $LIBFILE invoked from within set in [open $LIBFILE] (file ./tclinstaller.tcl line 23) make: *** [tcl_install] Error 1 [ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] gmpy universal build (static)?
IMHO this is the more important one for software that doesn't build out of the box, binary packages are nice to have but it should be possible to rebuild those without reinventing the wheel every time. What I'd like to see is a collection of binary packages that are created from a set of recipies (somewhat like what DarwinPorts does, but without sucking in a second installation of unix). That way it should be possible to (mostly) automaticly rebuild the binary packages when new versions of software are released, and when a new version of Python is released. In an ideal world we'd have the same set of software available for python 2.4, python 2.5 and Apple's python installation. The only way to get there is by using a toolset that does most of the work, manually building software and checking that everything still works is too much work. I use shell scripts to do such things even though there are far better tools. I like it because the shell is: ubiquitous, doesn't require special tools or configs, is easy to comprehend, and is easy to modify when things (as they always do) break as versions change. wishful-thinking It would be nice to have a set of tools like Fink does, only made for building software in place. /wishful-thinking Somewhere on the web should be good enough, Google should be able to find it then :-) I have a .Mac home page I _never_ really use. Sound like a project to go into the queue. That reminds me, I need to do this for my universal PIL build for 2.4 as well lest the formula become lost in antiquity ;-) On Jan 9, 2007, at 3:32, Ronald Oussoren wrote: On 9 Jan, 2007, at 12:04, Daniel Lord wrote: Ronald, Yes I will. You raise a very good point about reproducibility. I'll build a binary distro for those who want to keep it simple. But I will also include an archive containing instruction, shell scripts, env vars, and steps required to 'curl' the source and build it from scratch. IMHO this is the more important one for software that doesn't build out of the box, binary packages are nice to have but it should be possible to rebuild those without reinventing the wheel every time. What I'd like to see is a collection of binary packages that are created from a set of recipies (somewhat like what DarwinPorts does, but without sucking in a second installation of unix). That way it should be possible to (mostly) automaticly rebuild the binary packages when new versions of software are released, and when a new version of Python is released. In an ideal world we'd have the same set of software available for python 2.4, python 2.5 and Apple's python installation. The only way to get there is by using a toolset that does most of the work, manually building software and checking that everything still works is too much work. It requires just a bit of tweaking the CFLAGS and LDFLAGS ( for gmp) and a one-line patch for the gmpy distro in cvs (1.02) That would be an ideal things to also put in the Wiki were it not in such sorry state. I'd like to help with the Wiki, but I don't have the requisite time to learn is admin nor do the content justice right now. Somewhere on the web should be good enough, Google should be able to find it then :-) Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] gmpy update: gmp tests all pass, failure on 14 gmpy tests
I need some guidance here. On first blush it doesn't make sense that the gmp checks pass but 14 gmpy tests fail. Is that a problem with the API adaptation or a case of the gmp test not covering all functionality (not likely in my view) gmp is properly installed as a universal static binary and 'make check' passes completely. But gmpy fails 14 tests: ** 4 items had failures: 2 of 4 in gmpy_test_cvr 1 of 48 in gmpy_test_mpf.__test__.elemop 4 of 12 in gmpy_test_mpq.__test__.newdiv 7 of 25 in gmpy_test_rnd.__test__.rand 1072 tests in 34 items. 1058 passed and 14 failed. ***Test Failed*** 14 failures. I don't know enough about gmpy to venture a guess as to why. If anybody has any ideas, let me know.otherwise I'll shelve it until I get some more time to dig more deeply. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] gmpy universal build (static)?
gmpy universal build (static) I struggled with it for a while, but was finally able to build both gmp and then gmpy as static universal libraries on my Macbook Pro. Dynamic libs are still problematic but I'll try that next. Is this something new or is this 'old hat' and no one cares. The reason I asked is Alex Martelli told me he struggled with it briefly a while back (liek a year ago ;-) and gave up. I finally found some spare cycles (rare for me) and tackled it. I hope I didn't 'reinvent the wheel'. But even so, the exercise was fun fo someone who gets far too little time at development these days. Make check runs fine on the gmp build. The question I have for this what is available as a check for gmpy so I can test this out on Intel and PPC systems to make sure I built it right. Then I'll package it up for distribution. Unless of course, I have indeed 'reinvented the wheel'. In which case I'll just shuffle off quietly...never mind...move along...nothing to see here... ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] problem installing Python Image Library 2nd Post
I just tried the PIL build with the 2.5b version and it fails but the 2.4.3 version works fine...see below.My hunch is Ronald might have disabled some paths in order to keep the beta from interfering with the standard 2.4 install. Or not ;-)Ronald what say you?[[EMAIL PROTECTED]]$ python2.5Python 2.5b1 (r25b1:47038M, Jun 20 2006, 16:17:55) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwinType "help", "copyright", "credits" or "license" for more information. import ImageTraceback (most recent call last): File "stdin", line 1, in moduleImportError: No module named Image Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwinType "help", "copyright", "credits" or "license" for more information. import Image On Jul 26, 2006, at 4:08, Jörg Kantel wrote:Hi,today I tried to install the Python Image Library from this site http://pythonmac.org/packages/py24-fat/index.html and after the installer runs succesfully (it says) I got the following messageimport ImageImportError: No module named ImageIt happens when I'm running python from /usr/local/bin/ as well as from /usr/bin/Any suggestions?Thanks in advance (and excuse my bad (d)english)J"org -- J"org Kantel [EMAIL PROTECTED]Max-Planck-Institute for the History of ScienceComputer Department http://www.mpiwg-berlin.mpg.de/Boltzmannstr. 22 D-14195 Berlinfon: +4930-22667-220 fax: +4930-22667-299 ___Pythonmac-SIG maillist - Pythonmac-SIG@python.orghttp://mail.python.org/mailman/listinfo/pythonmac-sig "I have never won a debate with an ignorant person." -Ali ibn Abi Talib ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] problem installing Python Image Library
Are you using the Python 2.5 beta or the standard 2.4 install?the PIL build was made for the 2.4 installation and seemed to work fine with it, but I have not tested it with the 2.5 Beta.DanielOn Jul 26, 2006, at 4:08, Jörg Kantel wrote:Hi,today I tried to install the Python Image Library from this site http://pythonmac.org/packages/py24-fat/index.html and after the installer runs succesfully (it says) I got the following messageimport ImageImportError: No module named ImageIt happens when I'm running python from /usr/local/bin/ as well as from /usr/bin/Any suggestions?Thanks in advance (and excuse my bad (d)english)J"org -- J"org Kantel [EMAIL PROTECTED]Max-Planck-Institute for the History of ScienceComputer Department http://www.mpiwg-berlin.mpg.de/Boltzmannstr. 22 D-14195 Berlinfon: +4930-22667-220 fax: +4930-22667-299 ___Pythonmac-SIG maillist - Pythonmac-SIG@python.orghttp://mail.python.org/mailman/listinfo/pythonmac-sig "I have never won a debate with an ignorant person." -Ali ibn Abi Talib ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] problem installing Python Image Library 2nd Post
Bob, Of course that makes sense. One runs each setup.py with the python version intended to install the package under. Apologies to Ronald-- not that I thought he did anything incorrectly, I was just assuming he might have done something to protect us. What do you know, I learn something new every single day. In fact I have my 2.5 and 2.4 side-by-side so to speak and working quite independently it seems now that I look at it. That's the future gentlemen. What a fascinating modern age we live in. -- 'Lucky' Jack, Captain of HMS Surprise, Master and Commander, the Far Side of the World Daniel On Jul 26, 2006, at 10:39, Bob Ippolito wrote: On Jul 26, 2006, at 7:58 AM, Daniel Lord wrote: I just tried the PIL build with the 2.5b version and it fails but the 2.4.3 version works fine...see below. My hunch is Ronald might have disabled some paths in order to keep the beta from interfering with the standard 2.4 install. Or not ;-) Ronald what say you? Each Python installation has its own site-packages dir. Ronald didn't do anything to it, that's how Python works on every platform. It has to be that way, extensions and bytecode aren't compatible across minor versions. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PIL related crash?
On Jun 10, 2006, at 12:00, Jerry LeVan wrote: Hi, I am trying my hand at trying to build a simple image viewer for embedding into a larger application. The following code will display images ok on my linux box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 The same code crashes before the interface comes up on my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 and python 2.4.3, it looks like it is dying deep in the imaging code. Is this a know problem? Any suggestions? Your code works fine on my Macbook Pro although when I press the 'exit' button, it leaves the main tk window open so you need to clean up a bit better. I suggest you consider something is wrong uniquely with your system or installations of the components. Are you on a PPC or Intel? Showing the traceback would perhaps be more helpful. My system is: OS X 10.4.6 Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Tcl/Tk 8.4.13 Daniel Lord ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] FIXED: PIL related crash?
On Jun 10, 2006, at 17:16, Jerry LeVan wrote: I checked the PIL directory and noticed that the dates on the PIL files looked a bit old. I went back to pythonmac.org and downloaded the PIL that was available and all is well now :) Jerry Jerry, The PIL you just got is the one I am using if I recall correctly--ben a while since I built and installed it PIL. Glad it works for you too--you had me worried there for a while since I think that is the one I built ;-) Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Another report on py2app error with Xcode 2.3
I don't know if this helps at all, but here is the error I get...[[EMAIL PROTECTED]]$ python setup.py py2app -Arunning py2appTraceback (most recent call last): File "setup.py", line 30, in ? app = [app_data] File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 354, in run self.initialize_plist() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 427, in initialize_plist plist = self.get_default_plist() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 306, in get_default_plist version = find_version(target.script) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/util.py", line 13, in find_version ast = compiler.parseFile(fn) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 48, in parseFile return parse(src) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 52, in parse return Transformer().parsesuite(buf) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 129, in parsesuite return self.transform(parser.suite(text)) File "string", line 117 def magicNumber: ^SyntaxError: invalid syntax[[EMAIL PROTECTED]]$ This built fine under Xcode 2.2.3 though.I should note my environment is:OSX 10.4.6 i386 on Macbook ProXcode 2.3Python 2.4.3: Universal-MacPython-2.4.3-2006-04-07.dmgPyObjc: pyobjc-1.3.8a0-py2.4-macosx10.4.dmg "Ever tried. Ever failed. No matter. Try again. Fail again. Fail better." –Samuel Beckett ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] NEVER MIND! Re: Another report on py2app error with Xcode 2.3
Sheer stupidity on my part ;-)On May 29, 2006, at 15:49, Daniel Lord wrote:I don't know if this helps at all, but here is the error I get...[[EMAIL PROTECTED]]$ python setup.py py2app -Arunning py2appTraceback (most recent call last): File "setup.py", line 30, in ? app = [app_data] File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 354, in run self.initialize_plist() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 427, in initialize_plist plist = self.get_default_plist() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 306, in get_default_plist version = find_version(target.script) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/util.py", line 13, in find_version ast = compiler.parseFile(fn) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 48, in parseFile return parse(src) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 52, in parse return Transformer().parsesuite(buf) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/compiler/transformer.py", line 129, in parsesuite return self.transform(parser.suite(text)) File "string", line 117 def magicNumber: ^SyntaxError: invalid syntax[[EMAIL PROTECTED]]$ This built fine under Xcode 2.2.3 though.I should note my environment is:OSX 10.4.6 i386 on Macbook ProXcode 2.3Python 2.4.3: Universal-MacPython-2.4.3-2006-04-07.dmgPyObjc: pyobjc-1.3.8a0-py2.4-macosx10.4.dmg "Ever tried. Ever failed. No matter. Try again. Fail again. Fail better." –Samuel Beckett _______Pythonmac-SIG maillist - Pythonmac-SIG@python.orghttp://mail.python.org/mailman/listinfo/pythonmac-sig Daniel Lord[EMAIL PROTECTED]---"You will never regret getting up too early,and you'll always regret getting up too late,but sometimes you may regret giving up too late." -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Controlling Mail.app from Python
On May 27, 2006, at 21:26, Marcin Komorowski wrote: Is there a way to control Mail.app application from within Python the way it can be controlled using AppleScript? Explore the appscript module (http://freespace.virgin.net/ hamish.sanderson/appscript.html). I have found it to be powerful and very 'pythonic' once you understand the syntax which can be nearly every bit as arcane AppleScript itself since it must follow AppleScript. the site has a lot of examples and there is a wiki or sorts. I have successfully used it to control Mail, AddressBook, iTunes, BBEdit, and OminOutliner Pro. MS Excel has proven to be fairly problematic but I don't think it is appscript's fault--AE support is quite uneven and parochial from my experience--few outside of Apple implement it entirely correctly. Barebones, Late Night, Omnigroup, and Adobe seem to though. The one thing I haven't succeeded in doing was to create a pure Python mail filter. I had to write an AppleScript hack that used the last word in the mail filter title as the name of a Python script to run and pass it the rule name and message id on the command line. But that is more a limitation of Apple Mail's external script invocation capability than its AppleScript implementation. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Controlling Mail.app from Python
On May 28, 2006, at 10:58, David Warde-Farley wrote: Maybe for such complicated interactions a plugin would do the trick? (I'm not totally sure, I haven't explored their full capability). If you're interested see the tutorial at http://www.bazza.com/~eaganj/weblog/2006/03/29/demystifying-mail- app-plugins Coincidentally, the author uses Python. Thanks David. Just read through it. Its a cool hack, but unfortunately the author claims to uses a private API so it remains just a hack which may break suddenly with no deprecation warnings. I need to look at the GPG plugin since its open source to if its author used the private API as well. I want an official, non-hack if I can that won't break on me and I can run spam and other filters reliably . My ugly, coarse hack won't break with changes since it uses the official AppleScript method, it is just ugly and slow but how much mail do I filter at a time anyway? I could (big 'could' given all the other things to do) create a Python script to accept AE and send the message id and rule name as parameters via AE--cleaner and lighter in foot print perhaps particularly if I set the Python script up as a faceless background server that stays open as long as mail does once it is activated the first time. A project for a rainy day perhaps. Daniel Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 17, 2006, at 2:33, Piet van Oostrum wrote: Daniel Lord [EMAIL PROTECTED] (DL) wrote: DL Question for the group: if I modify the environment through os.environ DL ['PATH'], will Finder applications pick that up or is it just for the DL shell? Yes I need to RTFM and try it, but this is a stream-of- DL consciousness email over lunch and I have a full plate for this DL afternoon. Besides, what's a community for anyway? ;-) Changes to os.environ only apply to the process in which it will be executed and to its children. This applies to all changes to the environment variables, no matter how they are accomplished. So to set the environment for the Finder can only be done before (or while) launching the Finder. Piet thanks, but I knew that about environment UNIX inheritance my questions is bit more arcane and I'll have to research it myself because I am ignorant in this area (I suppsoe the documentation for Launch Services or something has the answer right up front): If I launch an app from the shell with the 'open' command , not by double-clicking in the FInder, which environment is used: the Finder's or the Shells or is there some combination of the two with some mapping and precedence scheme? That's what I meant to ask ;-) (the Real daniel, not 'just' a Dutch impostor ;-) Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 16, 2006, at 9:52, Christopher Barker wrote: Isn't there a way to tell XCode specifically what python you want it to use? I don't use XCode, so I have no idea. Since my impression is the XCode 'philosophy' to design it as a tool 'shell' using scripting to leverage command-line tools. I suspect one can go into the Python Xcode templates and modify the scripts. They are not always easy to locate through the IDE though there may be more straight-forward ways (for a UNIX developer anyway) to access and modify them. I'll take a look at this at some point, but I have not since the only part of the Xcode tool chain I use for Python/ObjC development is Interface Builder. XCode can integrate Ant for Java builds so I would think one can do it for. If worse came to worse, I suppose you could write a script to set the the Path in a shell and export it or in the OSX plist, , invoke XCode from the command line, 'do your business', and then reset everything if necessary with another script. A bit of a hack, but perhaps it could be made fairly painless. Question for the group: if I modify the environment through os.environ ['PATH'], will Finder applications pick that up or is it just for the shell? Yes I need to RTFM and try it, but this is a stream-of- consciousness email over lunch and I have a full plate for this afternoon. Besides, what's a community for anyway? ;-) Daniel Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 16, 2006, at 5:49, Marcin Komorowski wrote: Thanks Thorsten. OK, I think I will read the FAQ cover-to-cover so to speak before asking another question :). Now _that's_ good Mac Python Community citizenship. Nice to know some will actually read all that hard work of so many. Thanks ;-) Daniel I have never won a debate with an ignorant person. -Ali ibn Abi Talib ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 16, 2006, at 16:00, Bill Janssen wrote: OK, I think I will read the FAQ cover-to-cover so to speak before asking another question :). Now _that's_ good Mac Python Community citizenship. Of course, it's a Wiki, so the next question is: Have you read it lately? Bill I read it when I have a problem to solve. Maybe, you are hinting, I should read it like a newspaper on a regular schedule? Oh, would that I had the time, the time yes, the time. To devote one's life to all things Pythonic, now that would be something ;-) Daniel Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. –Samuel Beckett ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 16, 2006, at 17:43, Marcin Komorowski wrote: What do you than use for your Python/ObjC development on a Mac? Honestly, I use BBEdit as the overall text editor and I test complex Python non-GUI modules as 'stand-alone' modules using Komodo Professional (great debugger) or if they are C (rarely so far since performance is not key right now), then BBEdit/Make. I code Java as well using Ant/BBEdit. Eclipse is supposed to be great but its too much work to learn. The fable about the woodsman not stopping to sharpen his saw because he was too busy slowly cutting tress with a dull blade probably makes since and I should probably 'sharpen my saw' and learn Eclipse for Java. But I'll cling to my stone knives and bear skins a while longer if I can. So many trees and so little time ;-) Komodo is a commercial product I know but I bought Photoshop and I figured I get more use out of Komodo so I might as well buy it. No regrets. What Larry Wall says about his creation PERL: there's more than one way to do it. applies here (and that's about all the PERL I'll speak in this forum lest I be banished forever;-). Seriously, there is no 'right' way. For me, IDEs like Eclipse seem to get in my way and have to be 'bent' to work with Python in particular. While I am sure one can craft a very productive environment from those tools, I just keep it simple. I use BBEdit for XHTML/CSS also. It is familiar and I just like it. No Dreamweaver just an advanced text editor. That's why some use Emacs--its familiar, powerful enough, and they just like it. Just find what is most efficient for you. There is no 'right' answer as far as most choices in tools. Vive la difference. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 15, 2006, at 19:11, Marcin Komorowski wrote: Thanks to all who have replied with information, and especially to Bob for pointing me to a location where I can find a bunch of recent universal binary builds of python components. I have not found a link to this page on the Internet before, hopefully your post will help search engines find it. Here is a bit of extra information, what I got to work and the question I still have: - I am a recent Mac convertee (what took me so long?), and I am setting up PyObjC on my iMac for the first time - I originally tried PyObjC v1.3.7, the latest package I found at http://pyobjc.sourceforge.net/ and of course that did not work With the help of the wonderful people on this list: - I have checked out the latest PyObjC using subversion (here comes my CVS-to-subversion conversion) and built it with Python 2.3.5, which comes pre-installed with OS X 10.4 I have managed to do a build, install the package, and than used XCode to build a sample PyObjC application - awesome. Now, are there any side affects of switching the system over to use python 2.4? I have played around a bit with installing MacPython 2.4 (once again thanks to Bob's link) but I found that XCode picks up / bin/python (which is 2.3.5) and not /usr/local/bin/python, which is where MacPython 2.4 installs a link to its binary. Being new to Mac I must ask - is it safe to just point python binary links in /bin to match those found in /usr/local/bin or should I be weary of some side affects? Marcin, As Bill said _DON'T DO THIS_(TM). Please save yourself grief. The best thing to do is let the Third-Party Python installer put Python 2.4 in /usr/local/bin and then ensure your $PATH place /usr/ local/bin before /usr/bin sequentially thus causing the Python 2.4 to be found first when searching for the 'python' command. In this way, 'things' expecting to find Python 2.3 using absolute paths of /usr/ bin and Apple's installation don't break. While 'things' created to utilize Python 2.4 in /usr/local/bin function as expected. I, while no 'power-user', have been using this scheme successfully fr months now with no undesirable side effects so far. Daniel Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. –Samuel Beckett ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Status of PyObjC port to Intel OS X
On May 14, 2006, at 5:21, Marcin Komorowski wrote: Does anyone know what that status is of porting PyObjC to run on the new Intel Macs? I know that there has already been some amount of work done, but my attempts to run it on the new platform have failed. Should I be trying to be digging deeper into what I might be doing wrong, or is the port not complete? I have been able to my small projects on my Intel-based MacBook Pro without incident. So while that doesn't mean the port is perfect, it is fairly complete and solid. There are a few endian issue in a few dark corners of the port which are being found and fixed. A bit more specificity on the problems you are encountering on the Intel platform you didn't with the power-pc platform would be helpful. It is hard to address a general complaint/query without specifics. Further, remember, no port is perfect--there are always bugs which decline in number and the frequency with which they are encountered but some are always there they are just the more obscure ones. Daniel Lord [EMAIL PROTECTED] --- You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late. -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] ImportError: cannot import name PostponedException
On May 9, 2006, at 9:02, Christopher Barker wrote: Which brings up a question. Is it possible to build universal binaries with gcc 3.*? I'd love to see a Universal SciPy package! I haven't tried this, but it might hold promise: http://www.macosxhints.com/article.php?story=20060423105014540lsrc=osxh Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [OT] test, please ignore
I got a bounce from my .mac account as well. But only one, others went through. I might have been temporary. On May 2, 2006, at 14:45, Ronald Oussoren wrote: Please ignore this mail. I'm having errors posting using my .mac account, this is to check if this DNS flakeyness is to be blamed. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig Daniel Lord [EMAIL PROTECTED] --- You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late. -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] GMP bigot now chastened.
On Apr 26, 2006, at 22:45, Alex Martelli wrote: On Apr 26, 2006, at 8:19 PM, Daniel Lord wrote: Alex, Just so you and anyone who cares that our platform get fair treatment know. Turns out the Mac bigot was behaving badly again. GMP 4.2 doesn't compile on PPC macs either and he was blaming Apple's compilers. Turns out we figured out a fix involving PIC-- it seems Linux PPCs have the same problem. So it was gcc problem not an Apple one. I called him on and asked that he fix the site to avoid further embarassment ( i did that privately) but I publicly asked him to include the patches for Apple i386 and PPC in the source and wondered why they hadn't been adopted. That struck a nerve so he set my mail address to be moderated effectively quarantining me to stifle me. I figured this would happen and I didn't care--I got in a few licks and he's made a fool of himself. He took down the diatribe against Apple at least. In my life experience, I have found that appeasing such ignorant fools drunk with power only encourages them. It was a good fight, I accomplished what I wanted, and I feel no loss with the gmp list--I really only want it to work. Wow, thanks for the update -- that [[expletive deleted]] maintainer is most definitely doing GMP no favors (nor, any favors to the cause of open source, either). So, I guess, eventually we'll have to fork GMP, or something:-(. Ah well -- so the next minor 4.2.* is expected to build well -with- ppc on Mac both intel and PPC...? Well, that is if he actually follows through and checks in the changes. No telling what he'll do since he holds the keys to the repository and the forums--he can be a a magnaimous king or a repressive tyrant --his choice. We'll have to wait and see. they took down the diatribe against Apple assembler and have now a geenral comlaint about an increase in 'broken' gcc implementations that is platform agnostic. So IMHO, that is a big win for the Mac. What I'll do in the mean time, is put both patches up in the MacPython wiki so at least people 'googling' for a solution will find them. If we cannot work with him, we'll work around him as best we can. Jsut for posterity, here is the PPC one (thanks to Jack Howarth -- [EMAIL PROTECTED]) he is building GMP 2.4 on a G5 with Xcode 2.2.1: Daniel, My initial guess at the source of the problem turned out to be correct. I had thought the use of -fno-common to provide PIC code seemed suspect. If you rebuild gmp 4.2 on a G5 with... ./configure --enable-cxx CC='gcc -fPIC' CXX='g++ -fPIC' ...the resulting build passes make check fine. We ran into a lot of this in ppc-linux. Any shared libs built on ppc without -fPIC are subject to weird hard to debug crashes. I seriously doubt that -fno-common provides the same compiler behavior as -fPIC. Often on ppc compiles I have seen both used together. Jack Daniel Lord [EMAIL PROTECTED] --- You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late. -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Apple Tutorial on building Universal binaries from Open Source
This is fairly simple and uses Xcode, but really all Xcode is in this case is a wrapper for the shell scripts.I am going to try it with just commandline tools and scripts. Should work fine.http://developer.apple.com/opensource/buildingopensourceuniversal.htmlThe references at the end are good sources of more detailed info. These should help a lot of people in their struggles:Adopting Universal Binaries on Mac OS XUniversal Binary Programming GuidelinesPorting UNIX/Linux Applications to Mac OS XGCC Porting GuideThe GNU Compiler Collection on Mac OS XTechnical Note TN2137: Building Universal Binaries from configure-based Open Source Projects Daniel Lord[EMAIL PROTECTED]---"You will never regret getting up too early,and you'll always regret getting up too late,but sometimes you may regret giving up too late." -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] GMP bigot now chastened.
with exit status 1 brain:~/alex/gmpy alex$ Don't worry about the failure on the ppc branch, that's just because the .a is not universal and would presumably result in making a non- universal .so -- could be fixed later. I've tried with a nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. It's yet another TODO item, with lower priority than the biggie below. The biggie is the like: /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) I've tried (manually, i.e. with CFLAGS=... on the ./configure of GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume is what's the error's complaining about?) -- -fPIC, -fno-common, others; no luck so far. I've explored every mention on the web of this errorcode about local relocation entries in non-writable section, but, no luck so far. It may be trivial for people more deeply familiar with Apple's toolchain (ld most of all) than I am, and I do have several at work I can consult on that, but, as I said, I didn't yet have much time for followup. Once I understand how to fix it with CFLAGS=..., then I must understand how to embed the fix via autoconf/configure/libtools, which is scary (MY knowledge of that part being very scarce). Finally, there will be the political fight to make the maintainer accept the resulting patches. BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2 builds on those in a state which still doesn't let gmpy.so link (it may feel less urgent just because GMP 4.1.* does build fine;-). I've even tried using 4.1.* on mac-intel but it breaks in different ways and it seems to me that there's no point fighting with that one, I might well focus my limited time and energy on 4.2!-) BTW**2, any advice from ANYbody with better grasp of Apple's ld, the significance of -bundle vs -dylib, autoconf and friends, etc, etc, will be most welcome!-) Alex ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig Daniel Lord [EMAIL PROTECTED] --- You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late. -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New wiki entry on Universal libraries and extensions
On Apr 24, 2006, at 11:14, Christopher Barker wrote: My primary comment is that you're discussing building a Universal package, but keeping the external libs installed with the standard make install. I haven't tried your scheme yet, but usually that results in dynamic libs being built, sometimes by themselves, and sometimes along with the static libs. The trick here is that you can sometimes get the dynamic libs instead of the static ones when you link. Either way, it will work fine on your system, but there's really no point in building a Universal Package if you're not trying to distribute it (or a Py2App bundle built with it) Good point. In fact, though I was able to compile 'FAT' static libs, the shared libs are all just i386--I just now checked. BUt I linked against the static lib so things are fine this time, but more care in the future to ensure the shared libs are not found would be prudent and I'll take note of it. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 23, 2006, at 13:36, Jacob Rus wrote: has wrote: I could draw up a grinder or something in Illustrator, but it probably won't be for some days. If you can find something sooner, that's cool, otherwise let me know middle of next week and I'll see what I can do. Okay, this is kind of goofy, but might work. The second image is the drop state. Check out the zip to see it in action. PNG: http://hcs.harvard.edu/~jrus/python/py-grinder.png ZIP: http://hcs.harvard.edu/~jrus/python/py-grinder.zip As ling as you are convinced you want a grinder over a _blender_ (hint;-), then... That one is nicely done.d ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!
On Apr 22, 2006, at 9:50, Alex Martelli wrote: And GMP doesn't compile on Mac-tel and won't for some time: The current release is 4.2, released 2006-03-26. It fixes all bugs found in 4.1.4, as well as several portability problems. It also adds several new features. Note that we chose not to work around all new GCC bugs in this release. Never forget to do a make check after building the library to make likely it was not miscompiled! Issues with GMP 4.2: Miscompilation on several platforms using several different compilers. Remember to run make check! GMP does not build on MacInteltoch machines. Since Apple uses their own, creative assembly syntax, it is not trivial to fix this. Nope. The current maintainer of GMP is apparently Apple-hostile AND by his own admission no expert on autoconf/libtools and similar blackmagic -- and apparently unable to admit it when he's dead wrong. Apple's assembly syntax is totally irrelevant here. The reason make check fails is Apple's creative *ld semantics*: an object file inside a library file is NOT brought in if the only symbols it satisfies are DATA ones. Make check makes an executable with unresolved symbols because of this strange optimization in Apple's ld (I dimly remember from the past other linkers with this kind of strangeness), that's all. Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 which I had sent him -- it's a TINY patch (aparts from comments explaining why it exists, it's just *THREE* bedraggled lines...!!!): http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ patch-0001.obj Thanks Alex! I'll give this a try. I have to believe there is a way around this--we just need to find the right person at Apple. I know someone who might know someone... GMP's maintainer rejected it as THis is a too ugly patch for inclusion in GMP. (!!!). Given the importance of scientific and academic computing to Apple, someone at Apple should hear about this unacceptable and behavior and deal with it 'appropriately'. If not, I think Karl Rove has a little time on his hands before the election ;-) Volunteering for the role of maintainer is a role of stewardship that requires a reticence in the face of criticism and histrionics as well as a dedication to serve the community. But sometimes unfortunately, it is done more out of ego, a need to control, and a desire to mete out petty revenge on mere mortals from on high. If that's the case here, it would be a real shame--let's hope its not. Perhaps we just misunderstand his position and Apple can help with detente. I'll try to do what I can to help with gmpy though the inner workings of ld are probably too arcane and labyrinthine for me. Anyway, download and apply that patch, and make check passes with flying colors. Then, I had the deadline for the 2nd ed of the Nutshell, then a week's vacation at the Grand Canyon, and have been catching up on things, so I haven't done any further followthrough - yet. Once this idiocy is solved, there is another problem: I STILL can't link gmpy.so beause I can't make libgmp.a to build properly for linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS contents): brain:~/alex/gmpy alex$ python setup.py build_ext -i running build_ext building 'gmpy' extension creating build/temp.macosx-10.4-fat-2.4 creating build/temp.macosx-10.4-fat-2.4/src gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ gmpy.o -L/usr/local/lib -lgmp -o gmpy.so /usr/bin/ld: for architecture i386 /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) /usr/bin/ld: for architecture ppc /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it) collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or directory) error: command 'gcc' failed with exit status 1 brain:~/alex/gmpy alex$ Don't worry about the failure on the ppc branch, that's just because the .a is not universal and would presumably result in making a non- universal .so -- could be fixed later. I've tried with a nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. It's yet another TODO item, with lower priority than the biggie below. The biggie is the like: /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section
Re: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!
On Apr 22, 2006, at 12:36, Alex Martelli wrote: It's not just gmpy, but anything that needs to be linked as - bundle, whatever that means exactly. The workings of ld are slightly arcane -- I did already ask for advice from colleagues who I thought SHOULD know; for example, Matt Austern, who besides authoring Generic programming and the STL and shepherding library standards for the next generation of C++, led the gcc 4 group at Apple, focusing on many optimizations therefor... *he* easily admits that linking on MacOSX (as soon as dylibs, bundles, frameworks, and the interplay of their namespaces and constraints enters the picture) is something he never fully fathomed (no real need for him to delve into that, it appears). autoconf and friends are even scarier (to me, at least)...;-). Yup. Just ran into it with pcre (see below). Building pcre for i386 separately works, but trying the old ' -arch ppc -arch i386 ' CFLAGS trick is what appears to precipitate the failure. gcc -arch ppc -arch i386 -O2 -g -I. -Ipcre-6.6 -o .libs/pcretest pcretest.o ./.libs/libpcre.dylib ./.libs/libpcreposix.dylib /Users/ daniello/Project/Python-Builds/pcre/.libs/libpcre.dylib /usr/bin/ld: for architecture ppc /usr/bin/ld: warning ./.libs/libpcre.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: warning ./.libs/libpcreposix.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: warning /Users/daniello/Project/Python-Builds/ pcre/.libs/libpcre.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: Undefined symbols: _pcre_callout _pcre_compile _pcre_config _pcre_copy_substring _pcre_dfa_exec _pcre_exec _pcre_free _pcre_free_substring _pcre_free_substring_list _pcre_fullinfo _pcre_get_stringnumber _pcre_get_substring _pcre_get_substring_list _pcre_info _pcre_maketables _pcre_malloc _pcre_stack_free _pcre_stack_malloc _pcre_study _pcre_version collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccYAMG1B.out (No such file or directory) make: *** [pcretest] Error 1 So I did a little reading, and at least for my problem above the answer is in the man page for ld: UNIVERSAL FILE SUPPORT The link editor accepts ``universal'' (multiple- architecture) input files, but always creates a ``thin'' (single- architecture), standard Mach-O output file. The architecture is specified using the -arch arch_type option. If this option is not used, ld(1) attempts to deter- mine the output architecture by examining the first object file encoun- tered on the command line. If it is a ``thin'' file, its architecture determines that of the output file. If the first input file is a ``universal'' file, the ``best'' architecture for the host is used. (See the explanation of the -arch option, below.) The compiler driver cc(1) handles creating universal executables by calling ld(1) multiple times and using lipo(1) to create a ``univer- sal'' file from the results of the ld(1) executions. So the answer, IMHO and I could be wrong since I am very new to this, is one of two choices: 1) use 'ld' to produce two separate builds and then use 'lipo' to weld them together as a 'FAT' dylib or 2) To use 'cc' to build the dylibs and it takes care of teh seprate building and 'lipo-ing' Or maybe I have this wrong and the errros only seem the same and they are really dissimilar. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!
On Apr 22, 2006, at 14:51, Alex Martelli wrote: On Apr 22, 2006, at 1:51 PM, Daniel Lord wrote: ... So the answer, IMHO and I could be wrong since I am very new to this, is one of two choices: 1) use 'ld' to produce two separate builds and then use 'lipo' to weld them together as a 'FAT' dylib or 2) To use 'cc' to build the dylibs and it takes care of teh seprate building and 'lipo-ing' Or maybe I have this wrong and the errros only seem the same and they are really dissimilar. I'm pretty new at this too -- I've owned an intel Mac for less than a month, and it's been a busy time, little chance to learn or tweak much yet; and in particular I've not yet been able to build a fat- binary .so Python extension with the Universal MacPython 2.4.3 and any simple python setup.py build_ext -i approach. Ronald may hopefully understand these issues (and what if anything needs to be tweaked in distutils) a bit better... I just bought my Macbook Pro about 2 weeks ago so I am twice the newbie ;-) I just now wrote a quick and dirty test of making static 'FAT' lib that succeeded... At first I got these errors similar to what we've been seeing: [EMAIL PROTECTED] make -f Makefile cc -O2 -fno-common -c answer1.c cc -O2 -fno-common -c answer2.c ar crv libanswer.a answer1.o answer2.o a - answer1.o a - answer2.o ranlib libanswer.a cc -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ MacOSX10.4u.sdk -o static static.o -L. -lanswer /usr/bin/ld: for architecture ppc /usr/bin/ld: warning static.o cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) rch flag: ppc (can't load from it) /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccEO7pnk.out (No such file or directory) make: *** [static] Error 1 Then poking around the docs and Advanced OSX Programming, I found something to try: LDFLAGS = -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ MacOSX10.4u.sdk And that did it. Try it an let me know if that solves your problem...more later after I figure out the details ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 21, 2006, at 9:45, Christopher Barker wrote: Question: Do icons need to be associated with applications? Personally, I'd love to have all my *.py files have a nice python icon, but be able to choose what text editor or IDE I'd want them to open up with my default (and it won't be IDLE!). i.e. I want the python icon, NOT the BBedit icon, even though I usually use BBedit to edit python files. Chris, it is my experience that the Finder 'helpfully' replaces the file's icon with the 'appropriate' type of icon for the program that will open it. I will variously open files with more than one application depending on what I am doing (C/C++: Xcode/BBedit, Python: Komodo/BBEdit/Python) and I find it vexing to say the least but for neophytes it is probably a good thing that Apple chose to do it. So I suffer in silence. Riddle: When is a py not a py? Answer: when it is python source file you made with BBEdit. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 21, 2006, at 12:12, Christopher Barker wrote:Yeah, the way to do it is editing the app's Info.plist, and adding the icon to my.app/Contents/Resources. But wouldn't that make all BBedit associated files get the Python icon? Yes, I believe it would and, further, one would have to keep 'hacking' it with every update. I just 'right-click' on files and choose my application to open them. As I said it is inconvenient, but it is still better than Windows ;-) BTW I am working on a telepathic Services Menu Component and Finder injection component that will just _know_ which application you want associated with a given file each time you view it in the Finder but its been slow going any volunteers ;-)Daniel___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
As for applet icons. How about taking a different tack such as a variation on the icon used for Applescript applications: After all, a p2app application is still a script deep down. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 21, 2006, at 20:00, Jacob Rus wrote: Jacob Rus wrote: How's this then: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png Alright, 2 or 3 of the icons have since been updated, and that picture is new and improved. Are there any more suggested tweaks, or are the icons done so far ready to sail? Specifically, what do people think of the generic application icon as a default for apps created by py2app/py2applet? Also, is the pencil for the IDLE.app icon now okay, or can it still use work? The icons still needing to be done are one for py2applet, and one for BuildApplet.app. I'm thinking both of these can be stuffit-esque grinders, or similar, one with the applet icon coming out the bottom, and the other with the generic app icon coming out the bottom, and with python scripts going in the top. -Jacob I like them and I'll take them just as they are.. Thanks for all your hard work and putting up with all the detailed critiques. Your patience is exceeded only by your talent. Thank you for contributing to the Mac Python community. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 19, 2006, at 22:47, Jacob Rus wrote:Brendan Simons wrote: I like it, but Aqua has tuned down a lot its glassiness in recent years. I would tone down the difference between highlights and shadows myself, but I'm not going to argue about it :) You're probably right, but make sure you look at the actual icon files (in the zip files I linked to earlier) as well as the png files. There are some icc profile mismatch issues here, which I always seem to run into with png files (and it previews differently in Camino and Safari, for instance). The actual version may be duller than the preview you're seeing. Maybe I should post a screenshot instead of saving from photoshop. Jacob,I think your 'glassiness' is understated and fine. I never meant the extreme of the original colored iMac look.I think it adds a nice 3-D look especially in the smaller sizes and is under-stated enough to fit the Apple look of today with a little of a yellow and blue color Apple doesn't use. Could it be turned down a bit? Yeah I suppose. But there is a time to tweak and a time to move on when the diminishing returns of tweaking are vanishingly small and we can ignore subsequent terms in the series (flash-back to advanced engineering math ;-). Guess what time I think it is IMHO?Daniel___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 20, 2006, at 10:06, Charles Hartman wrote:On Apr 20, 2006, at 12:55 PM, Christopher Barker wrote: Perhaps the "snakes" logo should be larger, filling more of the icon, particularly at the smaller sizes. There isn't any real info in the "paper" background. FWIW, I agree with that. Me three.Daniel___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] HFS versus POSIX paths (changed from fixing the documentation)
I changed the topic so many can avoid it and we don't bore them to tears ;-)On Apr 20, 2006, at 2:02, has wrote:As for working with HFS paths (and a pox on scriptable apps that require them, btw, because they're fundamentally unreliable), you ought to be able to use Carbon.CF to translate between POSIX/Windows/HFS path styles. Unfortunately, I suspect getting in and out of there may be one of the areas that's broken.I am writing an app combining excel and python/appscript to fetch quotes from the web and value stock portfolios . But I give up on using appscript with Excel--some things just don't work because I think the terminology is seriously warped if no broken. Applescriptworks but appscript doesn't.I instead build a text Applescript from strings and use popen2 to invoke osascript like this example which reads in the stock symbols from a named range in an excel spreadsheet: def readSymbolList(self, workbook, worksheet, range): _getSymbolsScript = """tell app "Microsoft Excel" return Value of Range "%s" of Worksheet "%s" of Workbook "%s" end tell""" # read symbols from spreadsheet cout, cin = popen2.popen2( "/usr/bin/osascript -e \'%s\'" % \ (_getSymbolsScript % (range, worksheet, workbook))) symbols = cout.readline()[:-1] symbols = re.sub(",\s",",",symbols) if (self.DEBUG): print __module__, "::","symbols=", repr(symbols) # create symbolList symbolList = [] symbols = string.split(symbols, ",") if (self.DEBUG): print __module__, "::","stocks=", repr(symbols) for symbol in symbols: if (symbol != '0'): symbolList.append(symbol) cout.close() cin.close() return symbolList I wouldn't mind adding a makewithhfspath class method and hfspath instance method to macfile's Alias and File classes, but I'd want to be sure I had a correct implementation first, however, as it's not quite as trivial as it sounds on the surface (e.g. volume names are not a direct translation in either direction). If you really desire to you can but I just wrote a quick hack using re.sub() that correctly converts the paths I use so my needs are met.Daniel___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 20, 2006, at 20:11, Brendan Simons wrote: I've attached a few more mockups using Jacob's excellent aquified logo. Have a look here: http://www.flickr.com/photos/[EMAIL PROTECTED]/132185325/ In the spirit of open source, the layered psd files are available here: http://s65.yousendit.com/d.aspx?id=2CK5SUGTM74TH3OXH3WY6R8T66 I have to say: I really like these. Visually distinct, crisp, and clear. Great work to all of you who have put talents I wish I had in graphic design to work and produced an outstanding set of icons the Mac Python community should be proud of. I know I am. I am sure the tweaking will continue, but I think its 98 pct there. I'll let you all sort it out, but I am ready to take these now--of course I am one small meager vote ;-). ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app = newbie path confusion
On Apr 19, 2006, at 6:38, corporate user wrote: Many thanks to you Bob. You're a community treasure. Also note that the Image module probably isn't broken (don't have PIL installed at the moment, can't check). Constants don't automagically just insert themselves into your script. You should be able to reference it with Image.BICUBIC. yes, referencing Image.BICUBIC works correctly. As usual my problems lie with the scope. I'm forming the opinion that from XXX import * should be banned from all introduction, tutorial and example materials. It encourages naive assumptions about things automagically inserting themselves into your namespace. Everything seems simple when following the examples. But when you try paraphrasing them for your own work, it blows up in your face. It would be better to provide beginners an understanding of namespaces from the start. Most Python books do cover namespaces in the early chapters (at least the ones I read ;-). But 'from xxx import *' makes it too easy to forget them since it mashes the namespaces together. I've rarely encountered collisions but I try not to be that lazy. I try to use 'import ' and prefix the module name as often as practical fro that reason. Of course the downside is that if the module name or path structure internally change one has a lot of string subs to do in the source. TANSTAAFL. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 9:49, Christopher Barker wrote: My suggestion: A ExtraLibs.mpkg, right there with the packages on pythonmac.org that includes Universal shared libs required by some common packages. They could perhaps be installed in the Python Framework, so they won't interfere with anything else. a) is this possible? b) is this a good idea? I suggest the following libs: libfreetype libpng libjpeg Other common ones? I built Universal jpeg-6b, freetype2, and zlib for my current project of Universal PIL. I can add libpng in easily so I'll do it. So that makes jpeg, png, freetype, and zlib. What else? On the other topic... I have successfully packaged up a Universal PIL for 2.4 (thanks for the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am closer to releasing it. However, it isn't including the libs so I am studying py2app and bdist_mpkg nuances to figure out how to package them all in one installer. Once I get this done, I'll post it the instructions for hand building in the wiki and the all-in-one plus a separate Universal libs package on my iDisk. I am also trying to see if I can make a quick and dirty shell script using curl, sed, and toehr tools to create a one-button build and install but that is after the above. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fixing the documentation...
On Apr 19, 2006, at 9:14, Bill Janssen wrote: I'm still in favor of simply removing outdated and dangerous docs, but perhaps there's some effective way of thoroughly marking them as bad, instead. Put in doc sections entitled Deprecated and Obsolete and do the same for the web and wiki. I'll help at some point but I am busy with this PIL/Lib thing right now ;-) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app = newbie path confusion
On Apr 19, 2006, at 10:03, Zachery Bir wrote: On Apr 19, 2006, at 12:53 PM, Christopher Barker wrote: corporate user wrote: I'm forming the opinion that from XXX import * should be banned from all introduction, tutorial and example materials. Actually, it should be banned from virtually ALL user code! But tutorial and examples are a start! It has a strong place in PyObjC, where we're putting our natural inclination for multi-layered namespaces aside to fit in with the conventions of ObjC's single namespace. At least there (in PyObjC's context), it's a natural fit, and I'd much rather it continue to be presented as the convention. I know you said virtually, but given the fact this is the pythonmac mailing list, and PyObjC plays (at least for me) a very big part of the Python on Mac landscape, I'd hate to see a ban on what is arguably a harmless (and very timesaving!) use of from x import *. It is fine in modules where the scoping and namespaces are thoughtfully implemented. Banning is too strong a word. It kind like a hand grenade--really dangerous for the unskilled, but man when you need one, you really need one ;-) Beginner's should be cautioned and receive qualified instruction before using: i.e. it should be documented ;-) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 19, 2006, at 10:33, Jacob Rus wrote: There's the flat logo, but the logo I was pointing to was a version that's shaded a bit to look slightly raised and rounded. Were you looking for something more like [this][1]? -Jacob [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png Much better. In fact a great deal better--its looks worthy of the Mac. I could even say this is great. But, pushing the envelope a bit if you don't think I am being too demanding... Can you 'aqua-fy it' little-- give it that slightly transparent look that is the Apple trademark? ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 19, 2006, at 12:08, Jacob Rus wrote: [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png Much better. In fact a great deal better--its looks worthy of the Mac. I could even say this is great. But, pushing the envelope a bit if you don't think I am being too demanding... Can you 'aqua-fy it' little-- give it that slightly transparent look that is the Apple trademark? Well, that's what I was going for. Is [this][2] better? ([Folder][3] with icns file) I'm hardly an expert at drawing aqua icons, so my highlights might not be exactly right. Someone else may want to take a crack at it. In any case, even if a slightly more polished version of this is usable as a python document icon, what do we want to use for the other icons--drag-n-drop script runner, Editor/IDE, .pyc/.pyo files? pyc could just be the same but with PYC written at the bottom, I guess, but it could also have the paper background modified to signify compiled in some way. [2]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.png [3]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.zip I like it. But HAS is right--the icon on the www.python.org home page is more rounded. Now if you could take the new one and make it beveled and glassy liek you did the 'blocky' one I'd say we have a winner IMHO ;-) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fixing the documentation...
On Apr 19, 2006, at 12:52, Ronald Oussoren wrote: 2.1 macpath -- MacOS path manipulation functions Deprecate. Also note that the 2.4.3 documentation now says "It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform)." which is incorrect (it uses POSIX-style paths), so delete that sentence. I'm not a native english speaker, but I read this as "you can use this to manipulate OS9 style paths on any platform". Just like you can use ntpath to manipulate windows-style paths (c:\foo\bar.txt) on any platform. That's actually a useful feature. As I mentioned in another message this module might be useful to work with OS9-style paths as used by some Carbon API's. Good suggestion, Ronald. I was just tinkering around with appscript and MS Excel a few days ago (still cannot access some things like borders properly and others are just 'bass-ackwards' in the Excel terminology defs so I gave up) but Excel expects colon-separated paths in file paths (yes even in 2004 when they last updated it). SO keeping the OS9 path separator routines is a good idea. I didn't know about them and so wrote my own regex conversion functions (ugh!) as a workaround.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 13:04, Ronald Oussoren wrote:I'll post the script I'm using to build universal packages this weekend. I have recipes for the software I'm using and several other. That includes PIL (including jpeg, tif and freetype support).I'll put mine on my iDisk and send you a link. I'd like to see your scripts since I did it by hand and recorded it with bash typescript--to later script it using sed for the text editing. I have a Macbook Pro and PPC will be happy to test things. It is actually not very hard to build univeral libraries for most software.Yeah, if *I* can do it it cannot be too arcane ;-) I'd really prefer to ship addon packages as standalone eggs. AgreedDaniel___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 19, 2006, at 13:41, Jacob Rus wrote:Ok, got it. Well, I've now put more time into this than I wanted to, but I've got a glassy version of the correct python logo at full size, [here][4]. Let me know what you all think. If it looks good to everyone, I can make a .py icon like the one linked above, and an editor icon like Script Editor and TextEdit's, though someone will have to help me with the pen/pencil/whatever. I'm still not clear what the "drag-n-drop script runner" icon should look like. -Jacob [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png Awesome! Ya da man! This get's my vote.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Universal PIL for Python 2.4 on OS X 10.4 needs testing
I tested my Universal PIL installer for Python 2.4 on 10.4 on my MacbookPro but not PPC (my daughters refuse to quit Zoo Tycoon 2 and log off so I can tinker with it ;-) and it seems to work though I don't have a rigorous PIL test suite. The zip file is on my iDisk if anyone wants to give it a try. If it works, please somebody move it to a public host so I don't use up my bandwidth allotment like Ronald did ;-) http://homepage.mac.com/daniellord ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 15:53, Christopher Barker wrote: Bob Ippolito wrote: The libs should all be statically linked to the extensions, they shouldn't be separate in the installer. Ronald Oussoren wrote: I'd prefer to have fully self contained packages, and preferably eggs at that. Having a shared libary makes it *harder* to independendly update extensions using libpng or libfreetype. No one answered my question directly, but both Bob and Ronald have spoken: It's better for each package to statically link any libs it needs (unless Apple provides them), even though that means that a given python program may well end up using three copies of the same lib. Just to be totally clear: Is there any problem with the same program using three slightly different versions of the same lib? NOt as far as I can tell--the libraries are statically linked so don't even need to be on the platform after that. I'll have to package up my package build script one of these days ;-) What does it do? Something different than bdist_mpkg ? By build I by hand: curl, patch code by hand, make; sudo make install. The libs need their make components patched to compile FAT binaries and PIL needed to be patched to find the .a files to link into its binaries. And freetype uses a confusing Jam-based install which had me searching for where to change it. Daniel Lord wrote: I built Universal jpeg-6b, freetype2, and zlib for my current project of Universal PIL. I can add libpng in easily so I'll do it. So that makes jpeg, png, freetype, and zlib. What else? Those are the ones I need at the moment. Thanks! I guess a zip archive of the collection would be the best way to get it out there. I'll zip up the .a files and put them on my iDisk--will send you a URL when ready. I have successfully packaged up a Universal PIL for 2.4 (thanks for the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am closer to releasing it. Post a link to it here when you are ready so we can test it. Bob tested it and posted it already (see his email). More testing would be appropriate though. Maybe it would be helpful to have a standard way to link static libs with our packages. What I've done for matplotlib is create a StaticLibs directory at the same level as the setup./py, then hacked the setup.py to include it in the linking (and header) paths. That sound reasonable, but not what I did--I installed them in /usr/ local/lib include. I'll probably create one that has all of the above libs in it, then I can add a symlink to it for each package I'm trying to build. If anyone has any better ideas, I'd be glad to hear them. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [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
[Pythonmac-SIG] py2app argvemulation bug (or mis-configure) on i386 Python 2.4 on OS X 10.4
I decide to create a droplet from py2app in my copious spare time for
a few minutes earlier and I noticed some errors in the Console plus
the code is simply printing out all the strings in sys.argv plus, of
course given the error, the paths of the files dropped on it never
showed up in sys.argv[].
platform: Python 2.4 OS X 10.4 Universal MacbookPro i386
I did set: argv_emulation=True in the py2app options in setup.py
I this below a know error on Python 2.4 on Intel?
Console output:
Exception in AE event handler function
Traceback (most recent call last):
File /Library/Frameworks/Python.framework/Versions/2.4//lib/
python2.4/plat-mac/argvemulator.py, line 75, in callback_wrapper
raise 'Cannot happen: AE callback without handler', (_class, _type)
Cannot happen: AE callback without handler: ('tvea', 'codo')
AE error: (-1, 'queue element not found during deletion')
in High Level Event: '0x61657674' '0x6f636f64'
Traceback (most recent call last):
File /Library/Frameworks/Python.framework/Versions/2.4//lib/
python2.4/plat-mac/argvemulator.py, line 53, in lowlevelhandler
AE.AEProcessAppleEvent(event)
Error: (-1, 'queue element not found during deletion')
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
On Apr 19, 2006, at 21:41, Christopher Barker wrote: Well, a script is text, but a .pyc file is not Data. Maybe bytecode, which is too long, or bytes or code or .pyc or ??? I think it should be an Apple with a bite out of it--get it? Apple, snake, apple, byte grin. I kill myself ;-) Okay obviously I need to shut up and go away now...Bye. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Chris, I will do that but as it stands, one has to build this on the system it is going to run on, i.e. i386. I assume, but haven't gotten around to trying to build this on my PPC system since there is a valid build for that already. First, I am going to create a package for this for i386-based Macs and see if I can write a script to do the whole thing 'auto- magically'. Then I'll write the instructions up. Which leads me to a philosophical question for the community: which makes since for things like this as a standard practice for distribution (ranging from hardest to easiest) 1) to create a package with copies of the libraries used as Universal 'FAT' binaries (zlib, freetype2, jpeg-6b) not to mention PIL as well that will install correctly for PPC or i386 systems but include useless binary versions and take up space, 2) have two separate 'chunks' and have the installer select one based on the installation platform, or 3) just provide two separate packages--one for i386 and one for PPC? Daniel On Apr 18, 2006, at 13:22, Christopher Barker wrote: Daniel, It would be great if you could post this summary to: http://pythonmac.org/wiki/UniversalPackages thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac Python is DEAD...Long Live Python on the Mac
On Apr 18, 2006, at 16:46, Terry Jones wrote: | In my opinion, the problem is the term MacPython. Python is Python, | period, and we should just call it that, even if it's running on the Mac | platform. Perhaps this was different in the pre-OSX days, but not now. Make that 4 cents on dropping the Mac. The MacPython name is, to my ears, quite misleading. In fact, in my view, MacPython was the special build for OS 9 and earlier. I have never thought of the OS X distributions as 'MacPython' but rather Python for OS X just as Python for Red Hat Linux are still Python, just packaged and bundled as RPMs in order to install and work properly on the Red Hat Linux platform. I noticed the web information is trending in that direction, let's just make a clean break. Even if John Dvorak thinks Apple and OS X are doomed ;-) On another topic, we need to archive and keep available Jack Jansen's work. Jack made a great contribution to Python on the Mac, more than I think any other single individual, and one that should not be forgotten. Really. Link to it from the wiki and make it clear it is historical in nature and pioneering work by a key individual. IMHO MacPython _is_ dead (but not forgotten), Long live Python on the Mac./IMHO ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app = newbie path confusion
On Apr 18, 2006, at 22:05, Jim Tittsler wrote: BICUBIC = 3 ###Image module broke? so define it's constant here BICUBIC = Image.BICUBIC (And it's "its." :-) But you should find out why your PIL is broken. Hey, I am taking a break an a little so I'll 'nit pick' English:It isn't actually clear (to me) whether he's wrong or not: he could mean the contraction 'it is' as in 'so define [that] it is constant here' as opposed to the possessive "define it's constant" . If the former, his usage was correct, if the latter your correction was warranted. Just pointing out that the use is ambiguous to someone who has no idea whether this is Bicubic interpolation or B-splines or whatever. I'll settle down and go away now that I've had my fun--been that kind of day. I'll bet you _are_ right though ;-)___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] 2.3 vs 2.4
It is _not_ a good thing to remove Apple's Python. Don't panic though. First, let's stop this from happening to anybody else... Can you tell me where those instructions are that recommend that on Python.org? I believe they refer to a previous _MacPython_ that was installed which is not the same as _Apple's Python_ --perhaps that is what confused you? If so, please say so and tell me where the text is that confused you. (NOTE TO SELF: we might want to make that distinction more clear) There are applications (MotionBuilder is obviously one I now know) that look for Python, not on your environment path like IMHO they should, but instead embed the path. Someone with credulity (i.e. not me;-) should recommend Alias research adopt that practice. First let me try and help you: What did you do to remove it? If you just deleted symbolic links, great--put them back ;-). In the future, rather than removing things, try changing symbolic links in your path--that way recovery is rather simple. If you deleted files, the best thing to do is to to find another Mac running the same version of OS X you have and copy the Python framework back. If you cannot, I am not sure how to help. If you were successful in restoring things, then allow me to tell you what you should do in the future: The recommended approach (and it used to be the default on install for MacPython--I beleive it may still be but is optional now) is to install MacPython in /usr/local/bin leaving Apple's Python 2.3 intact. Then you put /usr/local/bin in your path ahead of /usr/bin (the location of the 2.3 python binary). then applications with hard links to /usr/bin/python don't break. Daniel On Apr 15, 2006, at 9:37, Robertson Holt wrote: Hi, I'm using 10.3.9 removed Python 2.3 as per instructions on python.org installed Python 2.4 and now can't launch some apps which reference 2.3 dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 PLE.app/Contents/MacOS/ple can't open library: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (No such file or directory, errno = 2) I tried making an alias of Python.Framework in /System/Library/Frameworks/Python.framework/ to point to /Library/Frameworks/Python.framework/ aliasing a fake /Versions/2.3 folder to the /Versions/2.4 but no luck. dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 PLE.app/Contents/MacOS/ple can't open library: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (Not a directory, errno = 20) Suggestions? Much appreciated. -- Robertson Holt http://www.electrogelly.com ___ 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] 2.3 vs 2.4
On Apr 15, 2006, at 14:10, Troy Rollins wrote:The thing I'm slightly unclear about is the best way to change my path on OSX. Changing things like ~/.profile and ~/.bash_profile change it for the shell, but do not change it systemwide. I've modified my ~/.MacOSX.environment.plist, which seems to do the job, but is it the right way to do it? Yes. It is the way to change it system wide for any applications the do not check the $PATH environment variable. And I think you meant ~/.MacOSX/environment.plist which is correct ;-)I only change the environment in those two ways (shell vars and environment.plist) and have no problems. And if I want a specific Python, /usr/bin/python or /usr/local/bin/python finds the one I intend to access. Maybe some of the more sage members of this community have more detailed or better advice, but that's what I recommend from my experience.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] wxPython -- some disappointment using it.
Personally I am with Bill, I like Jython but it unfortunately has fallen way behind in Python versions. But it has teh advantage that Java is supported on all main 'cross' platforms. On Apr 11, 2006, at 14:43, Louis Pecora wrote: I bought the wxPython in Action book and started trying the simple examples in Chap. 1. One thing I have run into is rather disappointing. Many errors (e.g. I typed return true, instead of return True) do not give the beloved Python tracback. That's one of the nice things that made me choose Python. Somehow once the app is launched if there is a bug it just quits without any information. I am now struggling to find out why example 3 (hello.py) won't work. I've been over it dozens of times checking indentation, spelling, etc. But the app never gets into OnInit (determined by the old fashion way of putting print's into the program at strategic stages). A window flashes open and then disappears. Process exited in the terminal. How are others using wxPython? Do you find you need to run in a debugger? Does that help? What do you recommend? Thanks for any suggestions. -- 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
[Pythonmac-SIG] appscript installer contents not Universal
I have discovered that the appscript installer from your site is not Universal, though building it from source using he new Universal Python build works. I have an Intel system and I built, installed, and tested it (somewhat with my own projects). If you send me the instruction to build the package (I have not built an OS X installer before so this would be a good chance to learn), I'll create a Universal installer as I have both PPC and i386 now to test on. Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison
;-( Thanks Ron--Not! kidding Now my 1.8 Dual really looks long in the tooth at 3.0 pystones. Guess I need to buy a MacBook now that it runs rings around my clunky old desktop. It would be interesting to see how the dual core G5 and Quad core do as well as the 2+ Ghz newer duals. I know the original G5s had a memory bottleneck and I am curious to see if the the DDR3 in the MacBook is what widened it or if the DDR2 and memory bus in the 2D Gen G5s removed it. On Apr 7, 2006, at 6:55 AM, Zachery Bir wrote: On Apr 7, 2006, at 9:33 AM, Ronald Oussoren wrote: I found some time to fire up the compiler. There's a new build of the 2.4.3 installer on my iDisk. If that works correctly I'll ask someone to replace the DMG on python.org. Please test if this fixes the speed issues and works in general, I haven't done any testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org is the addition of -O3 to the compile flags. *That's* mo' bettah (MacBook Pro 2.0GHz, 2GB RAM): [EMAIL PROTECTED] $ python2.4 -c from test.pystone import pystones; print pystones() (1.1199, 44642.857142857145) ~ [EMAIL PROTECTED] $ python2.4 -c from test.pystone import pystones; print pystones() (1.1499, 43478.260869565223) ~ [EMAIL PROTECTED] $ python2.4 -c from test.pystone import pystones; print pystones() (1.1199, 44642.857142857145) Zac ___ 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] 2.4.3 Python Universal Binary Pystone Comparison
Just for fun I got the svn source and compiled it on my 1.8Ghz Dual G5 running 10.4.6 to add a data point:daniello ~/WIP/Python-Builds/py-24 ./python.exe -c "from test.pystone import pystones; print pystones()"(1.6199, 30864.1975308642)Better than the 1.86 GHZ MacBookPro but surprisingly closer than I'd expect. Man for a laptop, that MacBook Pro sings! I'll bet the 2.16 Ghz might just tie my dual. Come to think of it, although it's three and a half years old, that's kind of depressing ;-(On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote:./python.exe -c "from test.pystone import pystones; print pystones()"___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 36
I prefer:import osos.environ['HOME']but I have no strong argument for that bias other than I sometimes use different environment variables and I standardized on the call.DanielOn Mar 19, 2006, at 3:00 AM, [EMAIL PROTECTED] wrote:From: "Stewart Midwinter" [EMAIL PROTECTED] Date: March 18, 2006 4:40:06 PM PST To: "Kent Quirk" [EMAIL PROTECTED] Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Question on user's directory ( ~ ) On 3/18/06, Kent Quirk [EMAIL PROTECTED] wrote: Try this: import os.path os.path.expanduser('~') you da man! That works perfectly. I mostly use Python on WinXP, so I haven't been familiar with that function up until now. thanks again S
PGP.sig
Description: This is a digitally signed message part
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] re Icon discussion
(deleted thread as it was getting too long) About this icon discussion, why don't we use a solution that maintains, reinforces, and capitalizes on the overall identity of cross-platform Python while distinguishing the OS X Mac-Python port by just taking the new Blue-Yellow Python logo and 'aquafying it' by beveling and 'glassing' it? As long as the Python logo caretakers don't think that dlitues the brand or trademark significantly that is. HAS has expressed concerns about regarding our deviating too much from the Python brand and I agree with him on that. Perhaps we could then get Active State, which has ported Komodo to OS X (which I use and fidn pretty good as cross platform IDE for Perl and Python) to maybe put it on their page. Yes, I know they do their own version but I also know their version doesn't include a lot this one does. But they are 'employee-owned' now and might agree that helping teh MacPython brand was in the community interest. Worth a try, but first you need to agree on a logo. (side note: Active State Python omits not only Apple stuff--they don't include SSL incredibly. I discovered this while creating a Gmail mailing script. Gmail requires TLS, but it failed to find SSL on my WIndows box because I was using Active State's Python--it was found once I removed it and installed the Python.org Windows port. Shame.) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 17
I agree with the main sentiments here. In addition, it depends not just on the volume being reasonable (a subjective word most of us intuitively understand), but also upon the quality of the firm and legitimacy of the offer. I personally find it interesting to see Pixar using Python and more interesting to guess what for. If not for the posting, I never would have known Pixar used Python.DanielOn Mar 7, 2006, at 1:32 PM, [EMAIL PROTECTED] wrote:From: Ronald Oussoren [EMAIL PROTECTED] Date: March 7, 2006 1:32:00 PM PST To: Kent Quirk [EMAIL PROTECTED] Cc: pythonmac-sig@python.org, Jack Jansen [EMAIL PROTECTED] Subject: Re: [Pythonmac-SIG] Job postings - allow or not?On 7-mrt-2006, at 22:23, Kent Quirk wrote: I think the occasional Python-related job posting is Just Fine. I'd be bugged if there were too many of them, but I wouldn't kick them to another list unless and until there were so many that they formed a measurable fraction of the list traffic. At which point I'd rejoice at Python's success. I agree. Unless there'd be a lot of job postings I don't mind. Ronald Kent -Original Message- From: pythonmac-sig-bounces+kquirk=[EMAIL PROTECTED] [mailto:pythonmac-sig-bounces+kquirk=[EMAIL PROTECTED]] On Behalf Of Jack Jansen Sent: Tuesday, March 07, 2006 4:18 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Job postings - allow or not? Folks, I've just let a job posting through to the list, after looking at it for a long time and unsure whether or not we want these. If you have a strong opinion (or a weak opinion, or anything resembling an opinion:-) on the matter: please let me know, then I'll use the collective feedback as a guidance in the future. ___ 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
[Pythonmac-SIG] Interesting Open Source Project: Cocoa Dialog
(Unless of course its been mentioned here before and then in the words of SNL's immortal Emily Latella: Never mind!) CocoaDialog seems to fill that gap between the command-line and PyObjC providing a 'quick and dirty' GUI interface for scripts (Python. Perl. Shell, Ruby, etc.) I just found it while 'googling up' up some AppKit NSTextContainer subtleties I was having trouble figuring out and I thought I'd pass it along. How Google put those two together I'll never know ;-) Clearly it doesn't replace PyObjC's power and breadth, but it might have a place in the toolbox for smaller projects. Kind of a Growl/ Display Dialog artifice. http://cocoadialog.sourceforge.net/documentation.html Daniel ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 69
On Feb 13, 2006, at 3:03 PM, [EMAIL PROTECTED] wrote:1. Monty Python related (to avoid the annoying offensive imagery arguments) Monty Python is copyrighted work. I would advise keeping a careful distance from anything commercially recognizable unless you put aside a significant settlement fund and lawyers fees for the settlement negotiation. But then you could gamble that Michael Palin et al are fans of open source software, want to contribute to the cause, and will let you use it gratis. Frankly, the language is named after a snake, a pretty noble beast actually, and I am not sure how Nature offends in this case. I think FORTRAN, PERL, C, Java, and C# are banal and unimaginitive in fact. Not that i think animals are good language names, but then what is? But the essence of naming is representation and memorability. I think Python is better than many in those respects. I suggest the collective community has 'bigger fish to fry' but since your are volunteers that is a suggestion.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59
On Feb 11, 2006, at 6:32 PM, [EMAIL PROTECTED] wrote:Ronald Oussoren wrote: Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. I think setuptools is going to be a great solution and definitely plan to more there eventually. For now though, the mpkg-based distribution provides a lower barrier to entry (one less thing to install first), and it's a familiar format to all Mac users. One of the obvious audiences for appscript is existing AppleScripters, who aren't always overly enthusiastic about approaching unfamiliar technology, so it keeps things simple for them. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ this is a personal opinion so I don't expect consensus. I _like_ appscript. A lot. HAS did a great job with it. And while I like the power of Apple Events, I do not like Applescript--the syntax is not standard by design--it varies from application to application which in theory means flexibility but in practice means entropy and chaos. And some application developers cannot even get the AETE right and so their scripting is broken or at least crippled. Applescript does not have decent control structures nor regular _expression_ support. Its file system syntax is horrific. I applaud the idea and the 'dream'--it just fell far short in practice. So using Python or Perl, whose syntax and language elements don't vary much from application to application is much better. The objects can vary--just not how to address them. I have used Mac::Glue with Perl, appscript with Python satisfactorily though I wish Apple would build in Apple Event support for those languages.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59
On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote: What they could do is offer better tools for creating scripting dictionaries, and more documentation on the topic, but that's about it. -bob BINGO! You win! That's the point. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59
On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote:On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote:On Feb 11, 2006, at 6:32 PM, [EMAIL PROTECTED] wrote:Ronald Oussoren wrote: Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. I think setuptools is going to be a great solution and definitely plan to more there eventually. For now though, the mpkg-based distribution provides a lower barrier to entry (one less thing to install first), and it's a familiar format to all Mac users. One of the obvious audiences for appscript is existing AppleScripters, who aren't always overly enthusiastic about approaching unfamiliar technology, so it keeps things simple for them.this is a personal opinion so I don't expect consensus. I _like_ appscript. A lot. HAS did a great job with it. And while I like the power of Apple Events, I do not like Applescript--the syntax is not standard by design--it varies from application to application which in theory means flexibility but in practice means entropy and chaos. And some application developers cannot even get the AETE right and so their scripting is broken or at least crippled. Applescript does not have decent control structures nor regular _expression_ support. Its file system syntax is horrific. I applaud the idea and the 'dream'--it just fell far short in practice. So using Python or Perl, whose syntax and language elements don't vary much from application to application is much better. The objects can vary--just not how to address them. I have used Mac::Glue with Perl, appscript with Python satisfactorily though I wish Apple would build in Apple Event support for those languages.That's irrelevant to appscript. If you're disappointed with the inconsistency of a given application's scripting dictionary then complain to the developer. Apple can't do a damn thing about it (unless of course they're the developer of the given app). Apple can't "build in support" for Python that would really be any different than what current solutions offer. What they could do is offer better tools for creating scripting dictionaries, and more documentation on the topic, but that's about it.-bob___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59
On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote:On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote:On Feb 11, 2006, at 6:32 PM, [EMAIL PROTECTED] wrote:Ronald Oussoren wrote: Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. I think setuptools is going to be a great solution and definitely plan to more there eventually. For now though, the mpkg-based distribution provides a lower barrier to entry (one less thing to install first), and it's a familiar format to all Mac users. One of the obvious audiences for appscript is existing AppleScripters, who aren't always overly enthusiastic about approaching unfamiliar technology, so it keeps things simple for them.this is a personal opinion so I don't expect consensus. I _like_ appscript. A lot. HAS did a great job with it. And while I like the power of Apple Events, I do not like Applescript--the syntax is not standard by design--it varies from application to application which in theory means flexibility but in practice means entropy and chaos. And some application developers cannot even get the AETE right and so their scripting is broken or at least crippled. Applescript does not have decent control structures nor regular _expression_ support. Its file system syntax is horrific. I applaud the idea and the 'dream'--it just fell far short in practice. So using Python or Perl, whose syntax and language elements don't vary much from application to application is much better. The objects can vary--just not how to address them. I have used Mac::Glue with Perl, appscript with Python satisfactorily though I wish Apple would build in Apple Event support for those languages.That's irrelevant to appscript. If you're disappointed with the inconsistency of a given application's scripting dictionary then complain to the developer. Apple can't do a damn thing about it (unless of course they're the developer of the given app). Apple can't "build in support" for Python that would really be any different than what current solutions offer. What they could do is offer better tools for creating scripting dictionaries, and more documentation on the topic, but that's about it.-bobAh but it is, I disagree. Apple is the OS and platform vendor. It is their decisions on frameworks, tools, and languages that constrain us. And with Applescript they boxed us in with a poorly-thought-out and insufficiently-defined concept for a language and platform that allows dabbling but little else in practice. It is a failure--even on a low-market share platform it has little penetration and for a good reason--it is 'crap shoot' to use. Poorly and inconsistently supported. Sure blame the docs. In the end, the documentation for a tool is as important or even _more_ important than the tool even when its structure is flawed. So fine. Let's agree to disagree. I'll let Applescript's adoption number speak for my side of the argument. When is it going to be ported to Linux or WIndows like Python and Perl have? Applescript could work with COM and .Net Why hasn't anyone done it if its so great? Res ipsa loquitur.___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 19
From: Charles Hartman [EMAIL PROTECTED]Date: 6 February 2006 06:43:48 GMT-08:00To: Louis Pecora [EMAIL PROTECTED]Cc: pythonmac-sig@python.orgSubject: Re: [Pythonmac-SIG] install again? Hence, yet again, a plea for newbies everywhere:I continue to believe that it really, really shouldn't be necessary for people who want to write programs in Python for the Mac to do all this. Great to learn as much as possible, yes, always -- but to require people, just to get started, to learn about shells and the Terminal, which they may never have dealt with before, even if they have a variety of Mac programming experience, is not to put Python on its best footing.You don't have to do this to get started. This only became necessary because the person installed a non-official Python release. Stick with the default version Apple ships and it is indeed simple--one need do none of this.I understand the frustration and confusion over having to delve into some of the technical details regarding command search ordering, but every operating system solves the problem in a technical way (even Windows) although it is transparent to the average user when it gives the expected results. Installing two version of Microsoft Words on Windows will cause the same problem--one has to be set to be the default and the other will take a little or even a lot of work to run. Microsoft will try to prevent two versions from being installed to avoid this problem. In fact, Windows annoys me often when launching non-Microsoft applications to ask if I wouldn't rather have Microsoft's application set as the default. In this case Microsoft is trying to keep the command searching straight for you--but only because these are end-user applications that are launched transparently without the command line. Microsoft WIndows provides no help when looking for commands from the DOS Shell either. In fact, there is a lot more information available on UNIX for free than for the inner working of WIndows.As for Apple and Python: Apple supports Python just fine-only one version of Python comes installed and it is always found from the command line. By installing 2.4, a user has installed a non-Apple-official version so the user has to take responsibility for setting it up properly. Apple has a rigorous testing process and releases software when they are ready for fully support it for their environment. Because 2.3 is the official Apple version, the creators of the 2.4 binary package did not want to overwrite 2.3 and assume the liability for the users system. Imagine how much more frustrated you'd be if that happened and then something broke? If one wants to 'push' the metaphorical envelope and run a non-official version of Python, one must accept the risk that one may make mistakes and also take on the additional burden of educating oneself to avoid problems. There is an assumption that when one is using development tools, one knows a bit more of the technical details on using the operating system. If one doesn't understand the PATH environment variable, then the concept of site-packages and module scope and precedence and searching fundamental to Python will be lost as well--they are very similar. There are many informative, well-written tutorials out on the web one can use to learn about the UNIX environment, the BASH shell and it is easy to create an environment where one can run both 2.3 and 2.4 safely. take a deep breath and devote 15 minutes to reading one. It will benefit you greatly I promise. Many Python books also describe setting up one's environment. But no one is forcing you to. If the added effort is not to your liking, I'd suggest you stay with 2.3 and keep it simple. But don't blame Python, Apple, or the great group of folks here who unselfishly keep Mac Python going. Daniel LordIntro to Shell variables and path: http://heather.cs.ucdavis.edu/~matloff/UnixAndC/Unix/ShellIntro.htmlLearn about these commands: which, echo $PATH, alias___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Non-obvious Question about PyObjC and Xcode
I am a neophyte when it comes to Cocoa and ObjC so forgive me if his question is nonsensical and the answer is obvious to you seasoned professionals. I decided to tackle a formidable task: learning Cocoa and Objective-C by approaching them through Python and Perl which I know and find better 'RAD' tools (though I do know C and C++ and have written some small Carbon applications using XCode and Code Warrior in the past). So I face a steep and formidable learning curve akin to soloing the Eiger in Winter perhaps. But here goes... I have to say I am a bit confused on the two very different sets of directions for using PyObjC and I want to use the tools a formal way to avoid as much obsolescence of my projects as possible: 1. The Tutorials on the SourceForge site present a somewhat traditional way of creating outlets and actions and linking them to an instantiated class in Interface Builder before executing py2app. However, unlike using the Camel Bones Perl ObjC Bridge, I have to run the external build tool outside of Xcode to make a build. I find the Camel Bones method much easier and it almost tempts me to go back to using Perl over Python (I said _almost_ ;-) $This means that once py2app is run though, I cannot change my nib files because the outlets and actions won't be 'bridged' or will they? 2. The Apple documentation describes an entirely different process which involves the Bindings tab of the Inspector in Interface Builder and I don't really understand it very well. What confuses me is this: 1) are they two different methods of achieving the same end and eventually will coalesce into some standard that fits Xcode better or 2) are they instead stark differences in philosophy and underlying architecture in accessing the PyObjC Bridge which will stay diverged with one eventually obviating the other? The advantage of the Apple-documented way is that I can use Xcode for building the application which is very convenient and consistent but I don't really 'get' the Binding tab just yet since I would think that it would show the bindings I make the traditional way with the Control-click graphic connections if the underlying architecture is consistent--and it doesn't. So they seem mutually exclusive and not consistent in Xcode. That worries me frankly--it makes them both seem more like hacks. It seems to be one way or another. I find this 'schizophenic' approach to development tools unsettling and it concerns me that I risk very fast obsolescence of my work if I pick the wrong build approach. Or worse: that both methods are just temporary and will disappear capriciously one OS revision without warning.So it begs the question: which method will be the 'main- stream' recommendation going forward? The SourceForge team is clearly a standard-setter but then again Apple has 'vendor power' when it comes to Cocoa and Objective-C. The Apple way is far better integrated with Xcode but seems strained and awkward when creating the outlets and actions because it doesn't use the 'standard' that Objective-C/Cocoa projects use and all the Cocoa tutorials use.. Or am I just confused because Cocoa and the Apple Tools is fairly opaque to me at this point? ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
